En agosto del año pasado lanzamosZeth, el primer zkEVM de Tipo-1 construido utilizando el zkVM RISC Zero, que permitió a los desarrolladores consagrar la ejecución de EVM en ZK. Luego este añoen mayo actualizamos Zethpara apoyar rollups optimistas como parte de laRFP de la Fundación Optimism , permitiendo a los desarrolladores generar pruebas de validez que consagren la derivación de rollup en conocimiento cero.

Hoy anunciamos Kailua, un conjunto de software para actualizar rollups optimistas a rollups ZK híbridos, con su primera implementación respaldada por Optimism’s.Konamáquina de transición de estado rollup. ¡Kailua no solo ejecuta de forma transparente Kona sin modificaciones en el zkVM, sino que también introduce su propio juego novedoso a prueba de fallos que avanza el estado actual de la técnica en la resolución de disputas al reducir los requisitos de garantía y los retrasos en la finalización!

Kailua

No confundir con la ciudad en el distrito hawaiano de Kona, Kailua es un conjunto de herramientas y contratos para migrar rollups de sistemas de prueba de falla interactivos largos a pruebas de falla ZK no interactivas cortas generadas utilizando el RISC Zero zkVM. Sus principales componentes son:

1. Un conjunto de contratos para disputas en ZK, actualmente compatible solo con rollups de OP Stack.
2. Una herramienta CLI para migrar automáticamente los rollups a pruebas de fallos de ZK.
3. Un agente proponente del estado que avanza el estado de rollup bajo las reglas del juego ZK.
4. Un agente validador de rollup que desafía y demuestra cualquier fallo de transición de estado en ZK.

Nota: La versión mínima de la pila OP requerida para usar Kailua es V1.4 porque utiliza el contrato DisputeGameFactory en lugar del contrato L2OutputOracle obsoleto.

Kailua Solves Core Rollup Problems

El juego de disputa de Kailua combina la demostración de conocimiento cero con el paradigma de rollup optimista en un novedoso sistema híbrido que mejora la seguridad y el rendimiento, al tiempo que reduce los costos operativos y los retrasos en la finalización. ¡Esto se resume en la tabla a continuación:

Ahorra en costos de prueba

A diferencia de ZK Rollups, el paradigma híbrido de Kailua permite que los rollups funcionen normalmente sin preocuparse por los costos y tiempos constantes de prueba, y también alivia a sus usuarios de cualquier costo adicional por la prueba, que se acumulan y se vuelven no despreciables en casos donde:

• Los rollups que subvencionan las tarifas de transacción para sus usuarios podrían no querer el costo adicional.
• Los rollups que experimentan bloques vacíos frecuentes podrían encontrar la carga adicional de demostración insostenible.
• Los rollups con tiempos de bloque muy bajos exacerbarían ambos problemas mencionados anteriormente.
• Los rollups con contratos previos personalizados requieren esfuerzos de ingeniería especializados adicionales para una prueba acelerada.

En el diseño innovador de Kailua, los costos para resolver una disputa utilizando ZK son completamente asumidos por las partes deshonestas, ya sea un proponente o validador defectuoso.

Reduce los requisitos de participación

¡Un rollup usando Kailua puede mantener su seguridad de manera segura mientras subcontrata cualquier carga de trabajo de pruebas! Esto se debe a que los validadores de Kailua aún pueden emitir las transacciones de desafío necesarias para garantizar la seguridad de sus rollups incluso antes de haber calculado las pruebas para justificarlos. En consecuencia, esto significa que en lugar de preocuparse por configurar una infraestructura de pruebas potencialmente compleja y costosa, los Rollups Híbridos de Kailua pueden depender de una infraestructura descentralizada de mercado de pruebas comoRISC Zero’s Boundless¡en momentos de necesidad con garantías de seguridad y de vivacidad para sus solicitudes de prueba!

Reduce los costos de garantía existentes de rollup

¡Los costos operativos de funcionamiento reducidos en comparación con ZK Rollups son excelentes, pero mejora! ¡Kailua también reduce los costos de garantía necesarios para ejecutar un rollup de “lineal en el número de propuestas/desafíos” a constante! ¡Esto significa que incluso bajo períodos largos de finalidad, el mínimo de garantía requerido por las partes honestas para sostener la seguridad y la vitalidad del sistema puede reducirse en órdenes de magnitud, de decenas de miles a cientos (en USD)!

ELI5: El juego a prueba de fallos de Kailua Fault

Primero, repasemos el mecanismo principal detrás de los juegos de disputa de rollup actuales. El juego de partición de Truebit introdujo la capacidad de resolver disputas sobre el resultado de una larga computación determinística a través de rondas repetidas de interacciones de desafío-respuesta. Este mecanismo ha sido la base de seguridad en rollups optimistas, que otorgan una oportunidad sensible al tiempo para jugar el juego y garantizar la integridad del libro de contabilidad de segundo nivel. La sensibilidad al tiempo garantiza la viabilidad del rollup, pero conlleva un riesgo para su seguridad, ya que los jugadores honestos en el juego de partición pueden no realizar sus movimientos a tiempo o pueden no tener suficientes fondos para jugar tantas instancias del juego como pueden los jugadores deshonestos. Sin embargo, sus suposiciones criptográficas subyacentes son mínimas, lo que lo convierte en una opción muy práctica.

Retrasos de finalización

Las reglas para jugar juegos de disputas basadas en la disección implican varios tipos de períodos de “tiempo de espera” concedidos a los jugadores para realizar movimientos. Los dos más notables son:

1. El tiempo de espera antes de que un resultado indiscutible sea final y ya no se pueda dividir en dos.
2. El tiempo de espera antes de que se resuelva una disputa abierta y los jugadores ya no puedan participar.

Estos dos tiempos de espera contribuyen a lo que comúnmente se conoce como el “Período de Finalización”. En los diseños actuales, un atacante podría sacrificar su propio colateral para activar el último tiempo de espera varias veces, incluso agotando los recursos de los defensores. Este vector de ataque ha sido fundamental para la seguridad de los rollups, incluido Arbitrum, que actualmente está adoptando un nuevo protocolo de disputa (BoLD) que tiene como objetivo establecer de manera comprobable un límite superior constante de ~6.3 días en el tiempo de espera para disputas abiertas.

¡Atención! Kailua reduce este tiempo de espera a solo una hora. ¡Y elimina la posibilidad de ataques de agotamiento de recursos!

Introducir ZK de propósito general

Las pruebas de conocimiento cero se pueden utilizar en lugar del juego de bisección como un mecanismo no interactivo para resolver cualquier disputa sobre el estado del rollup. ¡La naturaleza de una sola vez significa que el tiempo asignado para la resolución de disputas se puede reducir considerablemente al tiempo necesario para demostrar un solo bloque!

Híbrido es lo mejor de ambos mundos

Si bien este cambio en la mecánica podría parecer razonable, ¡todavía no es una introducción óptima de ZK en el juego de disputa optimista! En lugar de requerir pruebas solo para demostrar que un estado de rollup propuesto es inválido, también se podrían aprovechar las pruebas zk para demostrar validez, ¡incluso en un entorno optimista! Con la dualidad de las pruebas en mente, Kailua solo requiere que los impugnadores señalen su ‘intención’ de impugnar una propuesta, evitando la finalización de esa propuesta hasta que se presente una prueba de falla o validez para refutar al impugnador o al proponente y eliminar sus respectivas acciones del juego. En consecuencia, esto permite a Kailua liberar el rollup de preocuparse por demostrar tiempos que potencialmente no sean tan cortos como el tiempo de espera posterior.

Menos (mucho menos) requisitos de garantía

Pero Kailua no solo elimina los largos retrasos en la finalidad debido a las transacciones interactivas de desafío-respuesta, sino que también elimina gran parte de la garantía necesaria para mantener los rollups. Los jugadores en el juego de la bisección tienen que apostar piezas separadas de garantía en cada instancia del juego que juegan. Esto se debe principalmente al hecho de que un jugador puede perder en una instancia del juego debido simplemente a no responder a tiempo, lo que no dice nada de su honestidad en general. ¡Sorprendentemente, Kailua supera esta limitación con las disputas de ZK! En Kailua, si un jugador desafía una propuesta, y luego se demuestra que esa propuesta es válida, ¡entonces Kailua descalifica a ese jugador debido a su deshonestidad comprobada! Este simple cambio significa que los retadores ahora solo necesitan poner una garantía para asumir el papel de un retador, y luego lanzar tantos desafíos como sea necesario, en lugar de poner una garantía separada por desafío o juego. Sorprendentemente, la misma reducción de garantías también se aplica de manera segura a los proponentes debido al mismo razonamiento sin temor a ser atacado por un proponente rico que puede enviar spam al sistema.

De gas a humos

Sin embargo, rara vez tantas ventajas vienen gratis! En comparación con los rollups optimistas, en este diseño híbrido hay un costo adicional de publicación de datos que es necesario para eliminar las interacciones requeridas en un juego de disección. ¡Hemos diseñado Kailua para que este costo DA sea insignificante en comparación con los costos de la demostración completa en un ZK Rollup, lo que lleva a que el costo por transacción en Kailua esté inversamente relacionado con TPS!

En un rollup de Kailua donde un desafío/prueba se refiere a una secuencia de bloques de rollup K, el proponente de Kailua tiene que publicar como máximo N/K hashes como “datos de checkpoint” al proponer una transición de estado que hace avanzar el rollup por N bloques. K es el número de bloques no vacíos cubiertos por cada desafío/prueba, y es un parámetro configurable que determina los costos de disputa. Decimos como máximo N/K, porque el número de checkpoints requeridos puede reducirse en gran medida si hay muchos bloques vacíos en una propuesta.

En caso de un rollup relativamente activo con muy pocos bloques vacíos, la sobrecarga anterior sería insignificante, ya que sería un costo adicional de publicar solo 32/K bytes adicionales por bloque. Con K=1, por ejemplo, para la mainnet de Optimism, esto equivale a publicar un solo blob cada 2 horas y 15 minutos, lo cual es comparable contasa de propuesta existente en la red principal de OP, y muy por debajo delLos costos de DA para tal período. ¡Con el TPS actual y un costo de $3 por blob, eso es menos de $0.0001 por tx!

Sin embargo, en el caso de un rollup que experimenta una utilidad de espacio de bloque baja (por ejemplo, debido a tiempos de bloque muy bajos), la sobrecarga de publicar ingenuamente hashes N/K puede ser poco práctica, ¡pero Kailua no es ingenua! En este caso, la condición para crear un punto de control puede utilizar un segundo parámetro, E, que denota el número máximo de bloques vacíos que puede cubrir el punto de control. A continuación, se requiere un punto de control de 32 bytes (hash de bloque/estado) para cubrir una secuencia de bloques que contengan como máximo E bloques vacíos o K bloques no vacíos. Afortunadamente, E puede ser un número significativamente mayor que K, dependiendo de lo barato que sea probar bloques vacíos.

Usando Kailua hoy

Kailua está experimentando un rápido desarrollo y solo es adecuado para entornos de prueba y no para producción. Continuaremos mejorando y evolucionando Kailua agregando nuevas características, optimizando costos y rendimiento, ¡y posiblemente admitiendo más stacks de rollup! Kailua es un proyecto completamente de código abierto publicado bajo RISC Zero’s.Github.

¡Es fácil!

El Kailua CLI te permite implementar fácilmente un OP devnet local y actualizarlo para usar pruebas de fallas de ZK con solo unos pocos comandos. Después, puedes usar el CLI para lanzar el proponente y el validador, e interactuar con tu devnet local como normalmente lo harías. Si estás interesado en probar el juego de disputas real en caso de fallas, puedes usar el CLI para en cambio interactuar de manera anormal como normalmente no lo harías, e inducir algunas propuestas defectuosas y observar al validador desafiarlas y derribarlas ¡usando el RISC Zero zkVM!

Es práctico

Finalmente, esta no sería una publicación de blog de RISC Zero sobre una nueva versión sin algunos recuentos de ciclos. La tabla a continuación muestra algunos referentes de OP Mainnet, que vienen con algunas advertencias.

1. Estos números difieren de Zeth porque el motor de derivación y ejecución subyacente se basa únicamente en el Kona de Optimism, que está diseñado teniendo en cuenta algunas abstracciones de alto nivel que beneficiarán nuestras optimizaciones planificadas para adaptarlo al RISC Zero zkVM.
2. Cada prueba es para la derivación y ejecución de un solo bloque L2. La prueba en lotes de una secuencia de varios bloques se puede optimizar para obtener un recuento de ciclos significativamente menor por bloque mediante el uso compartido de los costos de derivación de datos, que son relativamente significativamente mayores.
3. Pronto integraremos una línea de aceleradores criptográficos con el zkVM, lo que reducirá significativamente los costos del ciclo de Kailua.

A pesar del aumento de casi cuatro veces en los recuentos de ciclos en comparación con op-zeth, los costos de prueba por transacción en esta tabla son dos a cinco veces mejores debido a las mejoras en el probador RISC Zero.

Descargo de responsabilidad：

1. Este artículo se reproduce de [ gate risczero], Todos los derechos de autor pertenecen al autor original [Rami Khalil]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.