ZKBase es un ZK-Rollup de alto rendimiento basado en ZK Stack y un probador de múltiples gpu. Esta solución mejora la capacidad de procesamiento de transacciones y proporciona una experiencia de red rentable. Su ventaja clave radica en la adopción de la tecnología de prueba de conocimiento cero (ZKP), que permite verificar y confirmar rápidamente las transacciones fuera de la cadena mientras se mantiene la privacidad de las transacciones y la integridad de los datos. Dado que todas las pruebas de validez se verifican en Ethereum, los usuarios pueden disfrutar de las mismas garantías de seguridad que en L1. ZKBase opera de manera similar a Ethereum pero con mayor rendimiento y tarifas más bajas. Los contratos inteligentes están escritos en Solidity/Vyper y pueden invocarse utilizando los mismos clientes que otras cadenas compatibles con EVM. Este artículo presentará la ingeniería central y la implementación técnica de ZKBase. 1. Componentes clave de ZKBase : estos componentes utilizan RocksDB para mantener copias locales del árbol de almacenamiento L2. La base de datos permanece sincronizada con el último hash raíz del estado, reflejando continuamente el estado actual del sistema. Tree y TreeBackup : ejecuta transacciones y almacena de forma segura los bloques adjuntos en la base de datos local de RocksDB, lo que garantiza la integridad de los datos y las actualizaciones de estado continuas. StateKeeper/VM : Implementados en la red principal de Ethereum, estos contratos inteligentes verifican las pruebas de conocimiento cero (ZKP) enviadas fuera de la cadena. Tras una verificación exitosa, estos contratos actualizan los estados de la cuenta en la red Ethereum. Contrato inteligente : una tecnología ZK-Rollup que garantiza una verificación de transacciones segura y eficiente a través de pruebas sin conocimiento. Cuando se produce un lote de transacciones fuera de la red principal de Ethereum, el sistema de agregación ZK comprime múltiples transacciones en una única "prueba de validez" calculada por el Prover, lo que demuestra la exactitud del lote. Luego, esta prueba se envía a la red Ethereum, lo que permite la confirmación rápida y segura de un gran volumen de transacciones que se realizan fuera de la cadena. GPU Prover : ZKBase proporciona un mecanismo puente para transferir activos de forma segura entre ZKBase y la red principal de Ethereum, garantizando la interoperabilidad y la liquidez de activos entre las dos plataformas. Puente 2. Flujo de trabajo de ZKBase Los usuarios pueden iniciar solicitudes L2 a través de una interfaz de programación de aplicaciones (API) o mediante contratos implementados en L1. Una vez enviadas, estas solicitudes ingresan a un mempool, en espera de ejecución. En particular, las transacciones que se originan en L1 (como los depósitos) se almacenan en una cola de prioridad L1 dedicada para garantizar que se procesen con prontitud. La estructura de almacenamiento de mempool es un btreeset (un conjunto implementado por un btree). La estructura de indexación es la siguiente: Aquí, fee_data no participa en el cálculo de la puntuación real, pero ayuda a filtrar las transacciones que no cumplen con los requisitos de la tarifa. La puntuación se ordena por marca de tiempo y, si las marcas de tiempo son idénticas, por dirección. Las transacciones en mempool son administradas por el componente de recuperación de mempool dentro de State Keeper. A excepción de las transacciones vencidas, las transacciones estándar se obtienen del mempool en el orden definido por el recorrido del btree y se registran en la base de datos. Luego son procesados por State Keeper/VM, ejecutados y utilizados para actualizar el árbol de estado. El diagrama de diseño de bloques muestra la organización de las transacciones dentro de un bloque y la disposición de los bloques L2 dentro de un lote L1. Para iniciar cada lote L1, el operador debe ingresar detalles clave: la marca de tiempo del lote, su posición en la secuencia y el valor hash del lote anterior. El hash de raíz del árbol Merkle sirve como hash de raíz fundamental en este proceso para garantizar la validez del lote y la autenticidad de las transacciones. Al mismo tiempo, el encargado del estado tiene la autoridad para decidir cuándo finalizar un bloque L2 específico o un lote L1 específico, determinando así su estado. Esta decisión se rige por un conjunto de criterios predefinidos gestionados por el módulo conditional_sealer. Estos criterios incluyen parámetros como el recuento de transacciones, los límites de tamaño y los umbrales de uso de gas. Después de procesar una transacción, el Encargado del Estado verifica qué condición de sellado se cumple. conditional_sealer mantiene un registro SealCriteria que incluye: Límites de recuento de transacciones, Límites de gas L2, Límites superiores a la cantidad de datos publicados, entre otras regulaciones. Hay cuatro escenarios de decisión: NoSeal, IncludeAndSeal, ExcludeAndSeal y Unexecutable. En los dos primeros casos, el proceso es el mismo, actualizándose el estado posterior a la ejecución en State Keeper. ExcludeAndSeal maneja las transacciones que exceden los límites de lotes predefinidos al revertir la ejecución de la transacción y colocarla nuevamente en la cola para incluirla en el siguiente bloque L2. Si ocurre una situación inejecutable, la transacción no se podrá ejecutar y será rechazada. Al final de cada lote, el gestor de arranque genera un bloque L2 de marcador de posición para completar las transacciones y prepararse para el siguiente ciclo. Aunque está casi vacío, este bloque es crucial para las operaciones internas e incluye un registro de eventos de transferencia para registrar los movimientos de tarifas entre el gestor de arranque y el operador. Para garantizar la precisión del tiempo, las marcas de tiempo del lote y del último subbloque se verifican con el marco de tiempo L1 esperado para mejorar la resiliencia del sistema ante problemas relacionados con el tiempo. Una vez finalizado un lote, el probador genera una prueba criptográfica para verificar la ejecución del bloque. En ZKBase, la responsabilidad del probador es demostrar la ejecución precisa de la máquina virtual Ethereum (EVM) de ZKBase. Luego, esta prueba se verifica mediante un contrato inteligente en la red Ethereum. Una vez que se genera la prueba, el probador la empaqueta en una transacción L1 y la envía a ETH_Sender. ETH_Sender reenvía la transacción al contrato ZKBase implementado en la red principal de Ethereum para su posterior procesamiento. La red principal de Ethereum verifica la exactitud de la prueba y, tras la verificación exitosa, actualiza el estado en consecuencia. A lo largo del proceso, EthWatcher monitorea continuamente eventos L1 específicos, como depósitos y actualizaciones del sistema, para garantizar la sincronización con la red principal de Ethereum. 3. Arquitectura de probador de múltiples GPU La arquitectura aprovecha una base de datos de Postgres para compartir datos, lo que permite el cálculo paralelo entre múltiples GPU Provers para mejorar la eficiencia de la generación de pruebas. Los componentes clave incluyen: : El servidor que proporciona servicios de Capa 2. Operador : módulo de comunicación que conecta al operador con el subsistema de prueba. Prover Gateway : genera tareas de cálculo de pruebas y almacena artefactos intermedios. Generador de testigos : agrega todas las tareas de cálculo en un formato vectorial adecuado para el cálculo de GPU y las envía a los probadores. Generador de vectores Realiza el cálculo real y la verificación de las pruebas. Prover: comprime la prueba final en forma SNARK. Compresor: Flujo de trabajo de generación de pruebas : el operador recopila transacciones y genera un nuevo lote. Generación de lotes : Prover Gateway recupera el nuevo lote del operador y comienza a prepararse para generar la prueba de conocimiento cero. Recepción de lotes : Prover Gateway inserta la información del lote en la base de datos de Postgres. El procesamiento de datos posterior interactúa directamente con la base de datos, recuperando datos de las tablas de entrada correspondientes y colocando los datos procesados en las tablas de salida relevantes. Inserción de base de datos : Esta etapa inicial ocurre cuando un usuario inicia una transacción generando un testigo. El testigo prueba la validez de la transacción basándose en las reglas de consenso de la red sin revelar ningún detalle de la transacción. Los nuevos testigos de transacciones se recopilan y procesan en lotes. Cada lote se somete a los siguientes procesos: Generación de Testigos Circuitos BásicosGenerador de Testigos LeafAggregationWitnessGenerador Agregación de nodos Programador : el Generador de vectores consolida circuitos para producir vectores testigo, optimizando el uso de la potencia computacional de la GPU. Generación de vectores : los probadores utilizan GPU para calcular las pruebas de conocimiento cero, verificando la exactitud de los cálculos de prueba. Computación de prueba : el módulo Compressor comprime la prueba para reducir el tamaño de los datos y los transforma en formato SNARK. Compresión 4. Conclusión ZKBase, construido sobre ZK Stack y Multi-GPU Prover, logra escalabilidad de Capa 2 de alto rendimiento. Sin embargo, la solución de escalado de Ethereum ZK-Rollup todavía enfrenta numerosos desafíos técnicos. En el futuro, ZKBase continuará investigando y explorando la implementación de secuenciación descentralizada y una red de energía computacional ZK descentralizada.
