En el núcleo de todos los Optimistic Rollups, existe una suposición clave: las propuestas de estado enviadas son válidas por defecto hasta que se demuestre que son incorrectas. Sin embargo, esta suposición solo se sostiene si el Rollup cuenta con un sólido mecanismo de prueba de fraude. Las cadenas que carecen de este mecanismo se vuelven inmediatamente inseguras una vez que un estado inválido no es cuestionado o cuando el proceso de liquidación se ve bloqueado debido a desafíos maliciosos.
La carga de la prueba de fraude
Para respaldar la hipótesis anterior, el L2 de Optimistic debe soportar un mecanismo de prueba de fraude (también conocido como protocolo de resolución de disputas), que permite a los validadores (desafiantes) impugnar propuestas de estado potencialmente erróneas presentadas por el ordenante (proponente). Este mecanismo debe garantizar dos características clave:
Todas las propuestas de estado erróneo pueden ser identificadas,
Un desafío incorrecto nunca tendrá éxito.
Desde un punto de vista técnico, este mecanismo incluye dos componentes centrales:
Subprotocolo de desafío: maneja las disputas sobre propuestas de estado individuales.
Mecanismo de torneo: Cuando hay múltiples propuestas de estado competitivo en el mismo bloque, se utiliza para seleccionar la única propuesta correcta.
Cada propuesta de estado es una declaración sobre el resultado de la ejecución de un conjunto de transacciones, que generalmente contiene tres partes:
Estado inicial: El estado L2 de Ethereum que fue confirmado por última vez recientemente;
Carga de transacciones: Una serie de transacciones L2 que han ocurrido desde ese estado;
Estado final: El proponente afirma el resultado obtenido tras la ejecución de estas transacciones.
Por lo tanto, una propuesta completa está esencialmente diciendo:
"Supongamos que el estado inicial actual es A, al ejecutar la siguiente lista de transacciones (payload), creo que el estado final debería ser X."
Podemos visualizar esta estructura en la forma de la siguiente imagen:
En este momento, la función del subprotocolo de desafío es verificar si esa afirmación es correcta. Si es incorrecta, el desafío debe tener éxito y la propuesta debe ser rechazada.
Prueba de fallo interactivo (Juego de desafío de bifurcación)
En la mayoría de los sistemas de Optimistic Rollup actuales y populares, se utiliza un protocolo interactivo: hay un intercambio de desafíos entre el retador y el proponente.
Una vez que se plantea una disputa, ambas partes llevarán a cabo una división binaria de los resultados intermedios del proceso de cálculo (los resultados de cada paso de ejecución que reclama el proponente), reduciendo gradualmente el rango en el que podría haber ocurrido un error. Este proceso se recursará continuamente hasta que ambas partes identifiquen un único paso de cálculo erróneo (por ejemplo, una transacción que se ejecutó incorrectamente).
Una vez que se haya determinado el error específico, este paso será ejecutado nuevamente en la red principal de ETH para determinar si realmente existe un comportamiento fraudulento.
Pero este mecanismo presenta varios problemas:
Alta latencia: Cada interacción requiere iniciar una transacción en la cadena de Ethereum. Un proceso completo de manejo de disputas puede tardar horas o incluso días, especialmente en momentos de congestión de la red o cuando está sujeto a censura;
Requisitos altos para el proponente: incluso si el proponente es honesto y el desafío carece de fundamento, aún debe participar en todo el proceso de disputa, incurriendo en un costo considerable de computación e interacción en la cadena;
Fácil de ser explotado maliciosamente: Los desafiantes maliciosos pueden presentar constantemente desafíos infundados, obligando a los proponentes honestos a perder repetidamente tiempo y costos de gas para defender el estado correcto.
En la realidad, las pruebas de fraude interactivas son costosas, son vulnerables bajo alta carga y son propensas a abusos.
Prueba de fraude no interactiva (Modelo de desafío ZK)
MegaETH adopta un enfoque completamente diferente: requiere que el retador solo genere una prueba de conocimiento cero (ZKP) sencilla que demuestre que el estado final declarado por el proponente es inválido.
En concreto, esta prueba ZK indica que la ejecución de la secuencia de transacciones desde el estado inicial no dará como resultado el estado final que el proponente afirma. Este mecanismo se construirá sobre el zkVM de RISC Zero y tomará como referencia la arquitectura híbrida de prueba de fraude no interactiva de OP Kailua para su implementación.
Esta prueba se envía a Ethereum a través de una única transacción, y el contrato de validadores en la cadena confirmará su validez. El presentador de la prueba no necesita participar en ningún trabajo, no puede interferir en todo el proceso y tampoco participa en disputas.
Por supuesto, generar una prueba ZK no es tarea fácil — requiere ejecutar completamente el proceso de cálculo en disputa en la máquina virtual zk, lo que se estima que consumirá alrededor de 100 mil millones de ciclos de cálculo, con un costo en el peor de los casos de aproximadamente 100 dólares. Sin embargo, este costo solo ocurre cuando se demuestra el fraude, y según el diseño, será asumido por la parte deshonesta. Este modelo alivia enormemente la presión de capital sobre los desafiantes honestos y elimina fundamentalmente el riesgo de sabotaje malicioso en el mecanismo de división.
ZK para pruebas de fraude, no para la validez del estado
En el ámbito de las criptomonedas, "conocimiento cero (ZK)" a menudo se entiende de manera simplificada como sinónimo de ZK Rollup, es decir, un sistema que utiliza pruebas ZK para validar las transiciones de estado fuera de la cadena y luego publicarlas en la cadena. Sin embargo, esta comprensión solo abarca la mitad del potencial de ZK.
El propósito de MegaETH al usar pruebas de cero conocimiento no es verificar la corrección del estado, sino probar comportamientos fraudulentos. Esto nos permite, manteniendo la eficiencia y escalabilidad de Optimistic Rollup, agregar un mecanismo sin confianza y no interactivo para detectar y desafiar las transiciones de estado inválidas.
Llamamos a este enfoque híbrido prueba de fraude ZK, que introduce un modelo de confianza esencialmente diferente.
La ventana de detección permanece igual, el tiempo de finalización se reduce drásticamente
Por razones de seguridad y prudencia, MegaETH seguirá manteniendo una ventana de desafío de 7 días típica de cadenas Optimistic, lo que significa que cualquier participante tiene exactamente una semana para impugnar un determinado estado raíz. Pero la verdadera diferencia ocurre después de que se presenta la impugnación, en el modelo interactivo, si se presenta un desafío en el día 7, puede que se necesiten algunos días adicionales para completar la resolución de la disputa. Durante este tiempo, la finalización de la cadena en la red principal de Ethereum se congelará, el progreso del protocolo se interrumpirá y la actividad de la cadena también se verá afectada.
En el caso de usar pruebas de fraude ZK, todo el proceso de disputa se completará en aproximadamente 1 hora. El retador genera la prueba ZK, la envía a la red principal de Ethereum, y después de la verificación, entra en vigor de inmediato, obteniendo la finalización del estado de la cadena rápidamente. Esto efectivamente contrarresta un vector de ataque clave: retadores malintencionados que inician repetidamente disputas falsas para obstaculizar la finalización de la cadena.
Garantía de disponibilidad de datos proporcionada por EigenDA
Para garantizar la integridad del proceso de prueba de fraude, el retador debe poder acceder de manera fácil y confiable a los datos del bloque original para reproducir el proceso de cálculo en cuestión.
Esta es precisamente la razón por la que utilizamos el modelo de fraude ZK junto con EigenDA (una capa de disponibilidad de datos descentralizada y de alto rendimiento).
A través de esta estructura, todo el proceso se ha simplificado a la forma más segura y eficiente:
El ordenante publica los datos del bloque en EigenDA, mientras que solo envía un pequeño resumen de los datos a Ethereum. La garantía criptográfica proporcionada por EigenDA asegura que se pueda generar una prueba de fraude en cualquier momento, y que el ordenante no puede "ocultar" datos para evadir la supervisión;
Cualquier observador puede recuperar datos de bloques de EigenDA, reconstruir bloques completos y ejecutarlos en zkVM;
Una vez que se detecte el fraude, el observador podrá generar pruebas de fraude ZK concisas, que se enviarán al contrato de verificación en Ethereum; el ordenante será penalizado y su propuesta inválida será rechazada.
Un modelo de confianza que cuenta con garantías criptográficas y es escalable
MegaETH utiliza pruebas de fraude ZK no interactivas y simplificadas en lugar de los engorrosos juegos de fraude interactivos. Este enfoque elimina el riesgo de ataques de acoso, reduce significativamente el tiempo de confirmación final y asegura que las disputas puedan resolverse de manera eficiente y escalable.
Con la capacidad de cálculo verificable proporcionada por RiscZero y el apoyo de @eigen_da para el acceso a los datos originales, cada propuesta de estado cuenta con:
Reconstitución, verificabilidad, posibilidad de ser desafiado por cualquiera — sin importar la escala.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
La batalla final: ¿Cómo protegemos la seguridad de MegaETH con tecnología ZK?
Autor: MegaETH Fuente: @megaeth_labs Traducción: Shan Oppa, Jinse Caijing
En el núcleo de todos los Optimistic Rollups, existe una suposición clave: las propuestas de estado enviadas son válidas por defecto hasta que se demuestre que son incorrectas. Sin embargo, esta suposición solo se sostiene si el Rollup cuenta con un sólido mecanismo de prueba de fraude. Las cadenas que carecen de este mecanismo se vuelven inmediatamente inseguras una vez que un estado inválido no es cuestionado o cuando el proceso de liquidación se ve bloqueado debido a desafíos maliciosos.
La carga de la prueba de fraude
Para respaldar la hipótesis anterior, el L2 de Optimistic debe soportar un mecanismo de prueba de fraude (también conocido como protocolo de resolución de disputas), que permite a los validadores (desafiantes) impugnar propuestas de estado potencialmente erróneas presentadas por el ordenante (proponente). Este mecanismo debe garantizar dos características clave:
Desde un punto de vista técnico, este mecanismo incluye dos componentes centrales:
Cada propuesta de estado es una declaración sobre el resultado de la ejecución de un conjunto de transacciones, que generalmente contiene tres partes:
Por lo tanto, una propuesta completa está esencialmente diciendo:
"Supongamos que el estado inicial actual es A, al ejecutar la siguiente lista de transacciones (payload), creo que el estado final debería ser X."
Podemos visualizar esta estructura en la forma de la siguiente imagen:
En este momento, la función del subprotocolo de desafío es verificar si esa afirmación es correcta. Si es incorrecta, el desafío debe tener éxito y la propuesta debe ser rechazada.
Prueba de fallo interactivo (Juego de desafío de bifurcación)
En la mayoría de los sistemas de Optimistic Rollup actuales y populares, se utiliza un protocolo interactivo: hay un intercambio de desafíos entre el retador y el proponente.
Una vez que se plantea una disputa, ambas partes llevarán a cabo una división binaria de los resultados intermedios del proceso de cálculo (los resultados de cada paso de ejecución que reclama el proponente), reduciendo gradualmente el rango en el que podría haber ocurrido un error. Este proceso se recursará continuamente hasta que ambas partes identifiquen un único paso de cálculo erróneo (por ejemplo, una transacción que se ejecutó incorrectamente).
Una vez que se haya determinado el error específico, este paso será ejecutado nuevamente en la red principal de ETH para determinar si realmente existe un comportamiento fraudulento.
Pero este mecanismo presenta varios problemas:
En la realidad, las pruebas de fraude interactivas son costosas, son vulnerables bajo alta carga y son propensas a abusos.
Prueba de fraude no interactiva (Modelo de desafío ZK)
MegaETH adopta un enfoque completamente diferente: requiere que el retador solo genere una prueba de conocimiento cero (ZKP) sencilla que demuestre que el estado final declarado por el proponente es inválido.
En concreto, esta prueba ZK indica que la ejecución de la secuencia de transacciones desde el estado inicial no dará como resultado el estado final que el proponente afirma. Este mecanismo se construirá sobre el zkVM de RISC Zero y tomará como referencia la arquitectura híbrida de prueba de fraude no interactiva de OP Kailua para su implementación.
Esta prueba se envía a Ethereum a través de una única transacción, y el contrato de validadores en la cadena confirmará su validez. El presentador de la prueba no necesita participar en ningún trabajo, no puede interferir en todo el proceso y tampoco participa en disputas.
Por supuesto, generar una prueba ZK no es tarea fácil — requiere ejecutar completamente el proceso de cálculo en disputa en la máquina virtual zk, lo que se estima que consumirá alrededor de 100 mil millones de ciclos de cálculo, con un costo en el peor de los casos de aproximadamente 100 dólares. Sin embargo, este costo solo ocurre cuando se demuestra el fraude, y según el diseño, será asumido por la parte deshonesta. Este modelo alivia enormemente la presión de capital sobre los desafiantes honestos y elimina fundamentalmente el riesgo de sabotaje malicioso en el mecanismo de división.
ZK para pruebas de fraude, no para la validez del estado
En el ámbito de las criptomonedas, "conocimiento cero (ZK)" a menudo se entiende de manera simplificada como sinónimo de ZK Rollup, es decir, un sistema que utiliza pruebas ZK para validar las transiciones de estado fuera de la cadena y luego publicarlas en la cadena. Sin embargo, esta comprensión solo abarca la mitad del potencial de ZK.
El propósito de MegaETH al usar pruebas de cero conocimiento no es verificar la corrección del estado, sino probar comportamientos fraudulentos. Esto nos permite, manteniendo la eficiencia y escalabilidad de Optimistic Rollup, agregar un mecanismo sin confianza y no interactivo para detectar y desafiar las transiciones de estado inválidas.
Llamamos a este enfoque híbrido prueba de fraude ZK, que introduce un modelo de confianza esencialmente diferente.
La ventana de detección permanece igual, el tiempo de finalización se reduce drásticamente
Por razones de seguridad y prudencia, MegaETH seguirá manteniendo una ventana de desafío de 7 días típica de cadenas Optimistic, lo que significa que cualquier participante tiene exactamente una semana para impugnar un determinado estado raíz. Pero la verdadera diferencia ocurre después de que se presenta la impugnación, en el modelo interactivo, si se presenta un desafío en el día 7, puede que se necesiten algunos días adicionales para completar la resolución de la disputa. Durante este tiempo, la finalización de la cadena en la red principal de Ethereum se congelará, el progreso del protocolo se interrumpirá y la actividad de la cadena también se verá afectada.
En el caso de usar pruebas de fraude ZK, todo el proceso de disputa se completará en aproximadamente 1 hora. El retador genera la prueba ZK, la envía a la red principal de Ethereum, y después de la verificación, entra en vigor de inmediato, obteniendo la finalización del estado de la cadena rápidamente. Esto efectivamente contrarresta un vector de ataque clave: retadores malintencionados que inician repetidamente disputas falsas para obstaculizar la finalización de la cadena.
Garantía de disponibilidad de datos proporcionada por EigenDA
Para garantizar la integridad del proceso de prueba de fraude, el retador debe poder acceder de manera fácil y confiable a los datos del bloque original para reproducir el proceso de cálculo en cuestión.
Esta es precisamente la razón por la que utilizamos el modelo de fraude ZK junto con EigenDA (una capa de disponibilidad de datos descentralizada y de alto rendimiento).
A través de esta estructura, todo el proceso se ha simplificado a la forma más segura y eficiente:
Un modelo de confianza que cuenta con garantías criptográficas y es escalable
MegaETH utiliza pruebas de fraude ZK no interactivas y simplificadas en lugar de los engorrosos juegos de fraude interactivos. Este enfoque elimina el riesgo de ataques de acoso, reduce significativamente el tiempo de confirmación final y asegura que las disputas puedan resolverse de manera eficiente y escalable.
Con la capacidad de cálculo verificable proporcionada por RiscZero y el apoyo de @eigen_da para el acceso a los datos originales, cada propuesta de estado cuenta con:
Reconstitución, verificabilidad, posibilidad de ser desafiado por cualquiera — sin importar la escala.