Como es bien sabido, las pruebas de fraude son una solución técnica ampliamente utilizada en el espacio de la cadena de bloques. Surgieron en la comunidad de Ethereum y fueron adoptadas por soluciones conocidas de Capa 2 de Ethereum como Arbitrum y Optimism. Después del auge del ecosistema de Bitcoin en 2023, Robin Linus propuso una solución llamada BitVM, que, basada en tecnologías existentes de Bitcoin como Taproot, se centra en las pruebas de fraude y proporciona un nuevo modelo de seguridad para la Capa 2 de Bitcoin o puentes.

BitVM ha lanzado varias versiones teóricas, desde la primera BitVM0, que utilizaba circuitos de compuertas lógicas como primitivas, hasta versiones posteriores como BitVM2, que se centraba en Pruebas de Fraude ZK y circuitos de verificación Groth16. Los caminos de implementación técnica relacionados con BitVM han ido evolucionando y madurando, atrayendo la atención de muchos profesionales de la industria. Proyectos como Bitlayer, Citrea, BOB, Fiamma y Goat Network utilizan todos BitVM como una de sus tecnologías centrales, implementando diferentes versiones basadas en esta base.

Dada la escasez y complejidad de explicaciones públicas disponibles sobre BitVM, hemos lanzado una serie de artículos destinados a popularizar el conocimiento de BitVM. Teniendo en cuenta la conexión arraigada entre BitVM y la prueba de fraude, este artículo se centrará en las pruebas de fraude y las Pruebas de Fraude ZK, utilizando un lenguaje simple y comprensible para explicar estos conceptos.

(Mecanismo de prueba de fraude interactiva del Principio de Optimismo)

OutputRoot y StateRoot

Optimism es un proyecto de Optimistic Rollup bien conocido, y su infraestructura consta de un secuenciador (con módulos principales que incluyen op-node, op-geth, op-batcher y op-proposer) y contratos inteligentes en la cadena de Ethereum.

Después de que el secuenciador procesa un lote de datos de transacción, estos datos DA se enviarán a Ethereum. Si eres capaz de ejecutar un cliente de nodo de Optimism, puedes descargar los datos cargados por el secuenciador en tu máquina local. Luego puedes ejecutar estas transacciones localmente y calcular el hash del conjunto de estado actual de Optimism (incluyendo, pero no limitado al saldo actual de cada cuenta, etc.).

Si el secuenciador carga un hash de conjunto de estado incorrecto en Ethereum, el hash de conjunto de estado que calculas localmente será diferente. En este caso, puedes plantear un desafío a través del sistema de prueba de fraude. Según el juicio, el sistema impondrá restricciones o penalidades al secuenciador o no tomará ninguna acción.

Al mencionar el término “conjunto de estados”, las blockchains basadas en EVM comúnmente utilizan una estructura de datos similar a un árbol de Merkle para registrar el conjunto de estados, llamado Trie del Estado Mundial. Después de que se ejecute una transacción, el estado de ciertas cuentas cambiará, y el Trie del Estado Mundial también cambiará, lo que resultará en un cambio en su hash final. Ethereum se refiere al hash final del Trie del Estado Mundial como el StateRoot, que representa los cambios en el conjunto de estados.

El siguiente diagrama ilustra la estructura de stateRoot de Ethereum. Como podemos ver, los saldos de las diferentes cuentas, el hash del código asociado con las cuentas de contratos inteligentes y otros datos se agregan todos al World State Trie, a partir del cual se calcula el stateRoot.

El sistema de cuentas y la estructura de datos de Optimism son generalmente consistentes con los de Ethereum, utilizando también el campo StateRoot para representar los cambios en el conjunto de estados. El secuenciador OP carga periódicamente un campo clave llamado OutputRoot en Ethereum, que se calcula en función del StateRoot y otros dos campos.

Volviendo a la pregunta inicial, cuando ejecutas el cliente nodo OP y calculas el StateRoot y el OutputRoot actual localmente, si encuentras que los resultados que calculaste no coinciden con los que cargó el secuenciador OP, puedes iniciar una prueba de fraude. Entonces, ¿cuál es el mecanismo específico detrás de esto? A continuación, introduciremos secuencialmente la verificación de estado de la máquina virtual MIPS y las pruebas interactivas de fraude.

Máquina virtual MIPS y árbol Merkle de memoria

Como se mencionó anteriormente, supongamos que descubres que el OutputRoot enviado por el secuenciador OP es incorrecto y deseas iniciar un "desafío". El proceso de desafío requiere completar una serie de interacciones en cadena, después de lo cual los contratos inteligentes relevantes determinarán si el secuenciador OP cargó un OutputRoot incorrecto.

Para verificar la corrección de OutputRoot en la cadena utilizando contratos inteligentes, el método más simple sería implementar un cliente de nodo OP en la cadena Ethereum, utilizando los mismos parámetros de entrada que el secuenciador OP, ejecutando el mismo programa y comprobando si el resultado calculado coincide. Este enfoque se llama un Programa de Prueba de Fallas. Si bien es relativamente fácil de implementar fuera de la cadena, es muy difícil de ejecutar en la cadena de Ethereum debido a dos problemas:

1. Los contratos inteligentes en Ethereum no pueden obtener automáticamente los parámetros de entrada necesarios para las pruebas de fraude.

2. El límite de gas de bloque de Ethereum está limitado y no admite tareas computacionales altamente complejas. Por lo tanto, no podemos implementar completamente el cliente de nodo OP en cadena.

El primer problema es equivalente a requerir que el contrato inteligente en cadena lea datos fuera de la cadena, lo cual se puede resolver utilizando una solución similar a un oráculo. OP ha implementado el contrato PreimageOracle en la cadena de Ethereum, y los contratos relacionados con la prueba de fraude pueden leer los datos necesarios de este contrato. Teóricamente, cualquiera puede cargar datos en este contrato, pero el sistema de prueba de fraude de OP tiene una forma de verificar si los datos son necesarios, aunque este proceso no se detallará aquí, ya que no es crucial para el tema principal de este artículo.

Para el segundo problema, el equipo de desarrollo de OP escribió una máquina virtual MIPS en Solidity para implementar algunas de las funciones del cliente de nodo OP que son suficientes para el sistema de prueba de fraude. MIPS es una arquitectura de conjunto de instrucciones de CPU común, y el código del secuenciador de OP está escrito en lenguajes de nivel superior como Golang/Rust. Podemos compilar los programas de Golang/Rust en programas MIPS y procesarlos a través de la máquina virtual MIPS en la cadena Ethereum.

El equipo de desarrollo de OP escribió un programa simplificado en Golang para la prueba de fraude, que básicamente imita los módulos en el nodo de OP que ejecutan transacciones, generan bloques y producen el OutputRoot. Sin embargo, este programa simplificado aún no puede "ejecutarse por completo". En otras palabras, cada bloque de OP contiene muchas transacciones. Después de procesar este lote de transacciones, se genera un OutputRoot. Aunque sepas que el OutputRoot de la altura del bloque es incorrecto, sería irrealista ejecutar todas las transacciones de ese bloque en cadena para demostrar que el OutputRoot correspondiente es incorrecto. Además, durante la ejecución de cada transacción, una serie de opcodes MIPS se procesan en secuencia. Sería poco práctico ejecutar toda esta serie de opcodes en la máquina virtual MIPS implementada en un contrato en cadena, ya que la sobrecarga computacional y el consumo de gas serían demasiado grandes.

(Principio de funcionamiento del conjunto de instrucciones MIPS)

Para abordar esto, el equipo de Optimism diseñó un sistema interactivo a prueba de fraude destinado a analizar profundamente el flujo de procesamiento de transacciones de OP. Observando todo el proceso de cálculo de OutputRoot, el sistema identifica en qué opcode MIPS el OP sequencer hizo un error en la máquina virtual MIPS. Si se confirma un error, se puede concluir que el OutputRoot proporcionado por el sequencer es inválido.

Así, el problema queda claro: el proceso de empaquetar transacciones del secuenciador OP en bloques se puede descomponer en el procesamiento ordenado de un gran número de opcodes MIPS. Después de que se ejecuta cada opcode MIPS, el hash del estado de la máquina virtual cambia. Estos registros se pueden agregar en un árbol de Merkle.

En el proceso interactivo a prueba de fraude, el objetivo es determinar después de qué opcode MIPS el hash del estado de la máquina virtual del secuenciador OP se volvió incorrecto, y luego reproducir el estado de la máquina virtual MIPS en la cadena, ejecutando el opcode y observando si el hash del estado resultante coincide con el enviado por el secuenciador. Dado que solo se ejecuta un opcode MIPS en la cadena, la complejidad es baja y el proceso de cálculo se puede completar en la cadena de Ethereum. Sin embargo, para lograr esto, necesitamos cargar la información del estado de la máquina virtual MIPS, como datos parciales de memoria, en la cadena.

En cuanto a la implementación del código, los contratos inteligentes en la cadena de Ethereum relacionados con la prueba de fraude completarán el proceso de ejecución final del código de operación MIPS a través de una función llamada Step:

Los parámetros en la función anterior, _stateData y _proof, representan los elementos de datos dependientes para la ejecución de un solo opcode de MIPS, como el estado del registro de la máquina virtual MIPS, el hash del estado de la memoria, etc. El diagrama se muestra a continuación:

Podemos ingresar estos parámetros del entorno de la máquina virtual MIPS a través de _stateData y _proof, ejecutar una sola instrucción MIPS en cadena y obtener un resultado autoritativo. Si el resultado autoritativo obtenido en cadena difiere del resultado presentado por el secuenciador, indica que el secuenciador es malicioso.

Generalmente nos referimos al hash de _stateData como statehash, que se puede entender aproximadamente como el hash de todo el estado de la máquina virtual MIPS. Entre los varios campos en _stateData, memRoot es el diseño más ingenioso. Como sabemos, durante la ejecución de un programa, se utiliza una gran cantidad de memoria, y la CPU interactúa con datos en ciertas direcciones de memoria mediante lectura y escritura. Por lo tanto, cuando ejecutamos un opcode MIPS en cadena a través de la función VM.Step, necesitamos proporcionar datos de ciertas direcciones de memoria en la máquina virtual MIPS.

OP utiliza una arquitectura de 32 bits para la máquina virtual MIPS, y su memoria contiene 2^27 direcciones, que pueden organizarse en un árbol de Merkle binario de 28 niveles. Los nodos hoja en el nivel más bajo son 2^27, con cada hoja registrando los datos de una dirección de memoria específica de la máquina virtual. El hash calculado a partir de todos los datos en las hojas es memRoot. El diagrama a continuación muestra la estructura del árbol de Merkle que registra los datos de memoria de la máquina virtual MIPS:

Necesitamos proporcionar el contenido de ciertas direcciones de memoria, y este contenido se carga en la cadena de Ethereum a través del campo _proof en la función de paso. Además, se debe cargar una prueba de Merkle basada en el árbol de Merkle de memoria para demostrar que los datos que usted (o el secuenciador) proporcionó realmente existen en el árbol de Merkle de memoria, en lugar de ser fabricados.

Prueba de Fraude Interactiva

En la sección anterior, abordamos el segundo problema completando la ejecución en cadena de los códigos de operación MIPS y la verificación del estado de la máquina virtual. Pero, ¿cómo pueden el impugnador y el secuenciador señalar la instrucción específica del código de operación MIPS en disputa?

Muchas personas pueden haber leído explicaciones simples de pruebas de fraude interactivas en línea y haber oído hablar del enfoque de búsqueda binaria detrás de ellas. El equipo de OP ha desarrollado un protocolo llamado el Juego de Disputa de Fallas (FDG). El protocolo FDG incluye dos roles: el retador y el defensor.

Si descubrimos que la OutputRoot presentada por el secuenciador en cadena es incorrecta, podemos actuar como el retador en el FDG, mientras que el secuenciador actúa como el defensor. Para ayudar a localizar el opcode MIPS que necesita ser procesado en cadena, el protocolo FDG requiere que los participantes construyan localmente un árbol de Merkle llamado GameTree, cuya estructura específica es la siguiente:

Podemos ver que el GameTree es bastante complejo, con una estructura jerárquica anidada, compuesta por un árbol de primer nivel y subárboles de segundo nivel. En otras palabras, los nodos hoja del árbol de primer nivel contienen un subárbol.

Como se mencionó anteriormente, cada bloque generado por el secuenciador contiene un OutputRoot, y los nodos hoja del árbol de primer nivel en GameTree representan los OutputRoots de diferentes bloques. El impugnador y el defensor necesitan interactuar dentro del árbol de Merkle formado por los OutputRoots para determinar cuál OutputRoot del bloque está en disputa.

Una vez identificado el bloque en disputa, nos adentramos en el segundo nivel del GameTree. El árbol de segundo nivel también es un árbol de Merkle, con sus nodos hoja siendo los hashes de estado de la máquina virtual MIPS, como se introdujo anteriormente. En el escenario de prueba de fraude, el retador y el defensor tendrán inconsistencias en los nodos hoja del GameTree que construyen localmente. El hash de estado después de procesar un opcode en particular será diferente.

Después de múltiples interacciones en cadena, las partes finalmente identifican el opcode en disputa exacto, determinando el opcode MIPS específico que debe ejecutarse en cadena.

En este punto, hemos completado todo el proceso de prueba de fraude interactiva. Para resumir, los dos mecanismos principales de la prueba de fraude interactiva son:

1. El FDG (Fault Dispute Game) primero localiza el opcode de MIPS que necesita ser ejecutado en cadena, junto con la información del estado de la VM en ese momento;

2. La máquina virtual MIPS implementada en la cadena Ethereum ejecuta el opcode, dando como resultado final.

Prueba de Fraude ZK

Prueba de fraude ZK Como podemos ver, el enfoque tradicional de prueba de fraude implica interacciones muy complejas, requiriendo múltiples rondas de interacción en el proceso FDG y reproduciendo instrucciones individuales en cadena. Sin embargo, esta solución tiene varios desafíos:

Se deben desencadenar múltiples rondas de interacción en la cadena de Ethereum, lo que resulta en decenas de interacciones que conllevan costos significativos de gas. 2. El proceso interactivo de prueba de fraude lleva mucho tiempo y, una vez que comienza la interacción, el Rollup no puede procesar transacciones normalmente. 3. Implementar un VM específico en la cadena para reproducir instrucciones es bastante complejo, con una alta dificultad de desarrollo.

Para abordar estos problemas, Optimism introdujo el concepto de Prueba de Fraude ZK. La idea principal es que cuando un desafiante plantea un desafío, especifica la transacción que cree que debe ser reproducida en cadena. El secuenciador de Rollup proporciona una prueba ZK para la transacción desafiada, que luego es verificada por un contrato inteligente en la cadena de Ethereum. Si la verificación es exitosa, se concluye que no hubo errores en el procesamiento de la transacción y que el nodo de Rollup no tiene la culpa.

En el diagrama, el Retadorse refiere a la parte que plantea el desafío, y el Defensores el secuenciador OP. En circunstancias normales, el secuenciador OP genera bloques basados en transacciones recibidas y presenta los compromisos de estado de diferentes bloques a Ethereum. Estos compromisos de estado pueden ser simplemente vistos como los valores hash de los bloques. El Retador puede desafiar basándose en el hash del bloque. Después de aceptar el desafío, el Defensor genera una prueba de conocimiento cero (ZK proof) para demostrar que los resultados de generación de bloques son correctos. En el diagrama, BonsaiEn realidad, es una herramienta de generación de pruebas ZK. En comparación con las pruebas de fraude interactivas, la mayor ventaja de ZK Fraud Proof es que reemplaza múltiples rondas de interacción con una sola ronda de generación de pruebas ZK y verificación en cadena. Esto ahorra significativamente tiempo y reduce los costos de gas. Además, a diferencia de los ZK Rollups, los OP Rollups basados en ZK Fraud Proof no requieren generar pruebas cada vez que se produce un bloque. En cambio, solo generan una prueba ZK temporalmente cuando se desafían, lo que también reduce los costos computacionales para los nodos de Rollup.

El concepto de ZK Prueba de Fraude también es adoptado por BitVM2. Los proyectos que utilizan BitVM2, como Bitlayer, Goat Network, ZKM y Fiama, implementan el programa de verificación de Prueba ZK a través de scripts de Bitcoin, simplificando significativamente el tamaño de los programas que deben llevarse a la cadena. Debido a limitaciones de espacio, este artículo no entrará en más detalles sobre este tema. ¡Estén atentos a nuestro próximo artículo sobre BitVM2 para obtener una comprensión más profunda de su camino de implementación!

Descargo de responsabilidad:

1. Este artículo es reproducido de [GodRealmX]], los derechos de autor pertenecen al autor original [Shew & Noah], si tiene alguna objeción al reimpresión, por favor contacte al Gate Learnequipo, y el equipo lo manejará tan pronto como sea posible de acuerdo con los procedimientos relevantes.

2. Descargo de responsabilidad: Las opiniones expresadas en este artículo representan únicamente las opiniones personales del autor y no constituyen ningún consejo de inversión.

3. Otras versiones del artículo en otros idiomas son traducidas por el equipo de Gate Learn y no se mencionan.Gate.io, el artículo traducido no puede ser reproducido, distribuido o plagiado.