Prueba de fraude y enfoque de implementación de ZK Fraud Proof
La prueba de fraude es una solución técnica ampliamente utilizada en el ámbito de blockchain, que se originó en la comunidad de Ethereum y fue adoptada por proyectos de Layer2 como Arbitrum y Optimism. Tras el surgimiento del ecosistema de Bitcoin en 2023, Robin Linus propuso el esquema BitVM, que tiene como núcleo la prueba de fraude, proporcionando un nuevo modelo de seguridad para las capas secundarias o puentes sobre la base tecnológica existente de Bitcoin.
BitVM ha pasado por múltiples versiones, desde la versión inicial BitVM0 basada en compuertas lógicas, hasta la posterior BitVM2, que se centra en ZK Fraud Proof y circuitos de verificación Groth16, con un camino tecnológico en constante maduración. Varios proyectos como Bitlayer, Citrea y BOB han realizado diferentes implementaciones basadas en la tecnología BitVM.
Este artículo tomará como ejemplo el esquema de prueba de fraude de Optimism, analizará su solución basada en la máquina virtual MIPS y la prueba de fraude interactiva, así como las principales ideas detrás de la prueba de fraude ZK.
OutputRoot y StateRoot
Optimism es un conocido proyecto de Optimistic Rollup, cuya infraestructura está compuesta por un secuenciador y contratos inteligentes en la cadena de Ethereum. Después de que el secuenciador procesa las transacciones, envía los datos a Ethereum. Ejecutar el cliente de nodo de Optimism permite descargar estos datos y ejecutarlos localmente, calculando el hash del conjunto de estados actual.
Si el secuenciador sube un hash de conjunto de estados incorrecto, los resultados de cálculo local serán diferentes; en este caso, se puede iniciar una disputa a través del sistema de prueba de fraude.
Las blockchains del tipo EVM suelen utilizar la estructura de datos Merkle Tree para registrar el conjunto de estados, conocido como World State Trie. Después de la ejecución de una transacción, el World State Trie cambia y su hash final también se actualiza. Ethereum denomina a este hash StateRoot, que se utiliza para representar los cambios en el conjunto de estados.
El sistema de cuentas de Optimism es similar al de Ethereum y también utiliza el campo StateRoot. El secuenciador sube regularmente el OutputRoot a Ethereum, que se calcula a partir del StateRoot y otros dos campos.
Máquina Virtual MIPS y Árbol Merkle de Memoria
Para verificar la corrección de OutputRoot en la cadena, la forma más sencilla es implementar un cliente de nodo OP en Ethereum, pero existen dos problemas:
Los contratos inteligentes no pueden obtener automáticamente los parámetros de entrada necesarios para la prueba de fraude.
El límite de Gas de Ethereum es limitado, no soporta tareas de cálculo complejas
El primer problema se puede resolver a través del contrato PreimageOracle. Para el segundo problema, el equipo de OP escribió una máquina virtual MIPS en Solidity, implementando parte de las funciones de los nodos OP.
El equipo de desarrollo de OP escribió un programa simplificado en Golang, cuya funcionalidad es básicamente consistente con la ejecución de transacciones por el nodo OP, la generación de bloques y el módulo OutputRoot. Sin embargo, debido a que el costo de cálculo es demasiado alto, no se puede ejecutar todas las transacciones completamente en la cadena.
Para ello, Optimism ha diseñado un sistema de prueba de fraude interactivo, que descompone el proceso de manejo de transacciones en un procesamiento ordenado de códigos de operación MIPS. Después de que se ejecuta cada código de operación, el hash del estado de la máquina virtual cambia, y estos registros se consolidan en un árbol de Merkle.
En la prueba de fraude interactiva, es necesario determinar qué código de operación MIPS provocó un error en el hash del estado de la máquina virtual, luego reproducir el estado en la cadena y ejecutar ese código de operación, observando si los resultados son consistentes. Esto requiere subir parte de la información del estado de la máquina virtual MIPS a la cadena.
Los contratos relacionados con la prueba de fraude en la cadena se completan mediante la función Step para la ejecución de los códigos de operación MIPS:
_stateData y _proof contienen datos de dependencia de la ejecución de un único código de operación MIPS, como el estado de los registros, el hash del estado de la memoria, etc.
OP utiliza una arquitectura MIPS de 32 bits, la memoria puede organizarse en un árbol de Merkle binario de 28 niveles, con 2^27 registros de hojas que representan los datos de las direcciones de memoria. El hash de todos los datos de las hojas resumidos es memRoot.
Prueba de fraude interactiva
Para localizar los códigos de operación MIPS en disputa, el equipo OP desarrolló el protocolo Fault Dispute Game(FDG). FDG incluye dos roles: el retador y el defensor, y ambas partes deben construir el GameTree localmente.
GameTree está compuesto por dos niveles de árbol: el primer nivel tiene las hojas que son las OutputRoot de diferentes bloques, y el segundo nivel tiene las hojas que son el hash del estado de la máquina virtual MIPS. Las partes en disputa interactúan múltiples veces en la cadena, finalmente localizando el código de operación MIPS que necesita ser ejecutado en la cadena.
En resumen, la prueba de fraude interactiva contiene dos mecanismos centrales:
Código de operación MIPS y la información del estado de la VM que requieren ejecución en la cadena para la localización de FDG.
Ejecutar el código de operación en la máquina virtual MIPS en la cadena de Ethereum para obtener el resultado final.
Prueba de fraude ZK
La interacción tradicional de prueba de fraude es compleja y presenta los siguientes problemas:
La interacción múltiple genera altos costos de gas
El proceso de interacción es largo, durante el cual Rollup no puede ejecutar transacciones correctamente.
La dificultad de desarrollar una VM específica en la cadena es alta
Para resolver estos problemas, Optimism propuso el concepto de prueba de fraude ZK. La clave es especificar las transacciones que deben ser reproducidas al desafiar, el secuenciador proporciona la prueba ZK, que es validada por el contrato de Ethereum.
En comparación con la prueba de fraude interactiva, la prueba de fraude ZK convierte múltiples interacciones en una sola generación y verificación de prueba ZK, ahorrando tiempo y costos. En comparación con ZK Rollup, el OP Rollup basado en prueba de fraude ZK solo genera pruebas cuando se desafía, reduciendo los costos computacionales.
La idea de prueba de fraude ZK también ha sido adoptada por BitVM2. Proyectos que utilizan BitVM2, como Bitlayer, Goat Network, etc., implementan programas de verificación de ZK Proof a través de scripts de Bitcoin, y han reducido enormemente el tamaño del programa en la cadena.
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.
Explicación detallada de la prueba de fraude: desde soluciones interactivas hasta la evolución técnica de la prueba de fraude ZK
Prueba de fraude y enfoque de implementación de ZK Fraud Proof
La prueba de fraude es una solución técnica ampliamente utilizada en el ámbito de blockchain, que se originó en la comunidad de Ethereum y fue adoptada por proyectos de Layer2 como Arbitrum y Optimism. Tras el surgimiento del ecosistema de Bitcoin en 2023, Robin Linus propuso el esquema BitVM, que tiene como núcleo la prueba de fraude, proporcionando un nuevo modelo de seguridad para las capas secundarias o puentes sobre la base tecnológica existente de Bitcoin.
BitVM ha pasado por múltiples versiones, desde la versión inicial BitVM0 basada en compuertas lógicas, hasta la posterior BitVM2, que se centra en ZK Fraud Proof y circuitos de verificación Groth16, con un camino tecnológico en constante maduración. Varios proyectos como Bitlayer, Citrea y BOB han realizado diferentes implementaciones basadas en la tecnología BitVM.
Este artículo tomará como ejemplo el esquema de prueba de fraude de Optimism, analizará su solución basada en la máquina virtual MIPS y la prueba de fraude interactiva, así como las principales ideas detrás de la prueba de fraude ZK.
OutputRoot y StateRoot
Optimism es un conocido proyecto de Optimistic Rollup, cuya infraestructura está compuesta por un secuenciador y contratos inteligentes en la cadena de Ethereum. Después de que el secuenciador procesa las transacciones, envía los datos a Ethereum. Ejecutar el cliente de nodo de Optimism permite descargar estos datos y ejecutarlos localmente, calculando el hash del conjunto de estados actual.
Si el secuenciador sube un hash de conjunto de estados incorrecto, los resultados de cálculo local serán diferentes; en este caso, se puede iniciar una disputa a través del sistema de prueba de fraude.
Las blockchains del tipo EVM suelen utilizar la estructura de datos Merkle Tree para registrar el conjunto de estados, conocido como World State Trie. Después de la ejecución de una transacción, el World State Trie cambia y su hash final también se actualiza. Ethereum denomina a este hash StateRoot, que se utiliza para representar los cambios en el conjunto de estados.
El sistema de cuentas de Optimism es similar al de Ethereum y también utiliza el campo StateRoot. El secuenciador sube regularmente el OutputRoot a Ethereum, que se calcula a partir del StateRoot y otros dos campos.
Máquina Virtual MIPS y Árbol Merkle de Memoria
Para verificar la corrección de OutputRoot en la cadena, la forma más sencilla es implementar un cliente de nodo OP en Ethereum, pero existen dos problemas:
El primer problema se puede resolver a través del contrato PreimageOracle. Para el segundo problema, el equipo de OP escribió una máquina virtual MIPS en Solidity, implementando parte de las funciones de los nodos OP.
El equipo de desarrollo de OP escribió un programa simplificado en Golang, cuya funcionalidad es básicamente consistente con la ejecución de transacciones por el nodo OP, la generación de bloques y el módulo OutputRoot. Sin embargo, debido a que el costo de cálculo es demasiado alto, no se puede ejecutar todas las transacciones completamente en la cadena.
Para ello, Optimism ha diseñado un sistema de prueba de fraude interactivo, que descompone el proceso de manejo de transacciones en un procesamiento ordenado de códigos de operación MIPS. Después de que se ejecuta cada código de operación, el hash del estado de la máquina virtual cambia, y estos registros se consolidan en un árbol de Merkle.
En la prueba de fraude interactiva, es necesario determinar qué código de operación MIPS provocó un error en el hash del estado de la máquina virtual, luego reproducir el estado en la cadena y ejecutar ese código de operación, observando si los resultados son consistentes. Esto requiere subir parte de la información del estado de la máquina virtual MIPS a la cadena.
Los contratos relacionados con la prueba de fraude en la cadena se completan mediante la función Step para la ejecución de los códigos de operación MIPS:
solidez función step( bytes memory _stateData, bytes memory _proof ) retornos públicos (bytes32) { // ... }
_stateData y _proof contienen datos de dependencia de la ejecución de un único código de operación MIPS, como el estado de los registros, el hash del estado de la memoria, etc.
OP utiliza una arquitectura MIPS de 32 bits, la memoria puede organizarse en un árbol de Merkle binario de 28 niveles, con 2^27 registros de hojas que representan los datos de las direcciones de memoria. El hash de todos los datos de las hojas resumidos es memRoot.
Prueba de fraude interactiva
Para localizar los códigos de operación MIPS en disputa, el equipo OP desarrolló el protocolo Fault Dispute Game(FDG). FDG incluye dos roles: el retador y el defensor, y ambas partes deben construir el GameTree localmente.
GameTree está compuesto por dos niveles de árbol: el primer nivel tiene las hojas que son las OutputRoot de diferentes bloques, y el segundo nivel tiene las hojas que son el hash del estado de la máquina virtual MIPS. Las partes en disputa interactúan múltiples veces en la cadena, finalmente localizando el código de operación MIPS que necesita ser ejecutado en la cadena.
En resumen, la prueba de fraude interactiva contiene dos mecanismos centrales:
Prueba de fraude ZK
La interacción tradicional de prueba de fraude es compleja y presenta los siguientes problemas:
Para resolver estos problemas, Optimism propuso el concepto de prueba de fraude ZK. La clave es especificar las transacciones que deben ser reproducidas al desafiar, el secuenciador proporciona la prueba ZK, que es validada por el contrato de Ethereum.
En comparación con la prueba de fraude interactiva, la prueba de fraude ZK convierte múltiples interacciones en una sola generación y verificación de prueba ZK, ahorrando tiempo y costos. En comparación con ZK Rollup, el OP Rollup basado en prueba de fraude ZK solo genera pruebas cuando se desafía, reduciendo los costos computacionales.
La idea de prueba de fraude ZK también ha sido adoptada por BitVM2. Proyectos que utilizan BitVM2, como Bitlayer, Goat Network, etc., implementan programas de verificación de ZK Proof a través de scripts de Bitcoin, y han reducido enormemente el tamaño del programa en la cadena.