Estado de prueba de fraude en la capa L2 de Ethereum

Le doy mucha importancia a esto. A partir del próximo año, solo mencionaré en público en blogs, conferencias y otros eventos aquellos proyectos que hayan alcanzado el nivel 1 o superior de L2. Tal vez haya un breve período de gracia para algunos proyectos nuevos e interesantes.

Ya sea que yo invierta o no, o si eres o no mi fren, debemos alcanzar la primera fase, de lo contrario no se considerará.

El sistema de 'etapas' de Rollup es un marco para evaluar aproximadamente su nivel de seguridad, desde la etapa 0 hasta la etapa 2. En los Rollup más populares de hoy, solo Arbitrum y Optimism han alcanzado la etapa 1, mientras que la mayoría de los Optimistic Rollup todavía se encuentran en la etapa 0.

En esta situación, surgieron algunos problemas:

Desde que se lanzó Optimistic Rollup hace tres años, ¿por qué todavía no ha habido ningún proyecto que alcance la etapa 2 más alta?
¿Cuándo se puede esperar que Optimistic Rollup alcance la fase 2?

Este artículo tiene como objetivo responder a estas preguntas mediante el análisis de la prueba de fraude y el mecanismo de desafío de Optimistic Rollup, y explorar cómo cada proyecto se esfuerza por lograr la Fase 2. Además, este artículo también analizará el futuro desarrollo de Optimistic Rollup y el sistema de prueba de fraude.

1.2. Comparación entre Optimistic Rollup y ZK Rollup

Como es bien sabido, la velocidad de Ethereum es lenta y el blanqueo de capitales es alto. Los investigadores y desarrolladores de la comunidad de Ethereum han estado trabajando arduamente para resolver este problema. Después de explorar soluciones como Fragmentación (sharding) y plasma, la comunidad finalmente ha determinado que Rollup es el enfoque principal para lograr la escalabilidad. Como resultado, han surgido múltiples Rollup, como Arbitrum, Optimism y zkSync. Según los datos de L2Beat, actualmente hay aproximadamente 40 Rollup en funcionamiento, además de otras soluciones como Validium y Optimium que utilizan el enfoque alt-DA para lograr una mayor escalabilidad, con un total de aproximadamente 41 soluciones. Además, se espera que se lancen alrededor de 80 nuevas cadenas de Rollup.

(Estado actual de L2 | Fuente: 01928374656574839201L2Beat）

El concepto central de Rollup es realizar transacciones fuera de la cadena, solo enviando datos de transacciones y el estado raíz de los resultados a la red Ethereum, logrando así escalabilidad. Los usuarios pueden depositar fondos en un contrato puente específico en la red Ethereum, transferir los fondos al interior de Rollup y realizar transacciones dentro de Rollup. Debido a que los datos de transacciones se envían a la red Ethereum y una vez confirmados no se pueden cambiar sin comprometer la seguridad de la red Ethereum, se considera que Rollup "hereda la seguridad de la red Ethereum".

Pero, ¿es esto realmente cierto? ¿Y si el proponente que maneja las transacciones dentro de Rollup es malicioso? El proponente malicioso podría alterar el saldo de Alice, transferirlo a su propia cuenta, y luego extraerlo a Ethereum, efectivamente robando los fondos de Alice.

Para evitar esta situación, se requiere un mecanismo de seguridad adicional al retirar de Rollup a la cadena ETH. La transacción de retiro solo se completa si se proporciona una prueba al contrato de puente ETH que demuestre que la transacción de retiro se ha procesado correctamente y se ha incluido en la cadena L2.

El método más sencillo, que también es adoptado por cada Rollup, es comparar el hash de la transacción de retiro con la raíz del estado del Rollup para demostrar que la transacción de retiro ha sido incluida correctamente en el estado del Rollup. Esto requiere que la transacción de retiro y la raíz del estado se envíen juntas al contrato de puente de Ethereum. Los usuarios envían sus transacciones de retiro, mientras que los validadores calculan y envían la raíz del estado.

Sin embargo, si los validadores del estado raíz presentan un comportamiento malicioso y envían un estado raíz incorrecto, podría poner en peligro la seguridad de los fondos de los usuarios. Para mitigar este riesgo, se han propuesto dos mecanismos principales que diferencian a Optimistic Rollup y ZK Rollup.

**ZK Rollup **ZK Rollup no solo requiere que los validadores presenten una raíz de estado, sino también que proporcionen una prueba de conocimiento cero (ZK) para verificar la corrección del cálculo de la raíz de estado. Si los validadores presentan una raíz de estado incorrecta, la prueba de conocimiento cero (ZK) no pasará la verificación del contrato de verificación L1, lo que impedirá la presentación de raíces de estado maliciosas.
**Optimistic Rollup **Optimistic Rollup allows specified validadores to submit state roots without additional guarantees, based on the assumption that the submissions are honest. However, if the submitted state root is incorrect, anyone can raise a challenge and prevent the use of that state root in the withdrawal process. The challenger must submit evidence to ETH坊 to prove the state root is incorrect, which is called prueba de fraude (Fraud Proof).

Para garantizar la resolución segura de ataques como L1审查等攻击的之意, el tiempo de retiro de Optimistic Rollup suele retrasarse aproximadamente una semana para evitar la latencia.

1.3. ¿Por qué se necesita prueba de fraude?

A diferencia de ZK Rollup, los validadores de Optimistic Rollup pueden enviar raíces de estado incorrectas e intentar manipular las transacciones de retiro. Prueba de Fraude lo previene de manera efectiva, garantizando la seguridad de los fondos en el contrato de Puente.

Si no hay un mecanismo de prueba de fraude sólido, Optimistic Rollup no puede heredar completamente la seguridad de Ethereum. Por ejemplo, en el sistema de validadores con licencia de Arbitrum actual, si todos los validadores conspiran, podrían robar todos los fondos en el contrato de puente. Del mismo modo, en Rollup basados en pilas OP como Base, debido a que aún no se ha implementado un mecanismo de prueba de fallos sin licencia en Mainnet, un solo validador malintencionado también podría robar fondos.

Por lo tanto, la prueba de fraude juega un papel crucial en la seguridad de Optimistic Rollup, y cualquier sistema que carezca de un mecanismo de prueba de fraude sólido representa un riesgo para los activos de los usuarios.

Este artículo evaluará los riesgos que enfrentan varias implementaciones de Optimistic Rollup y examinará la implementación y ventajas y desventajas de sus mecanismos de prueba de fraude.

1.4. Avanzando hacia la Etapa 2: 'Eliminar las ruedas de entrenamiento'

El sistema de prueba de fraude desempeña un papel clave en ayudar a Optimistic Rollup a lograr el proceso de 'Fase 2'. El marco propuesto por Vitalik, actualmente operado por L2Beat, se utiliza para evaluar el nivel de seguridad de Rollup.

En el ecosistema de Ethereum, este marco de etapa a menudo se compara con aprender a andar en bicicleta. El Rollup de la etapa 0 depende de suposiciones de confianza máxima, que se comparan con una bicicleta de tres ruedas con ruedas de entrenamiento, mientras que el Rollup de la etapa 2, que hereda completamente la seguridad de Ethereum, se compara con una bicicleta de dos ruedas sin ruedas de entrenamiento.

A continuación se detallan los estándares detallados de cada una de las etapas, desde la Etapa 0 hasta la Etapa 2:

Como se mencionó anteriormente, para lograr la Fase 1 o Fase 2 de Optimistic Rollup, es crucial implementar un sistema adecuado de prueba de fraude y mecanismo de desafío. Teniendo en cuenta estos estándares, el sistema de prueba de fraude que cumpla con los requisitos de la Fase 2 debería tener las siguientes características:

El sistema funciona bien, no hay defectos conocidos y tiene la característica "1-de-N".
Este es un sistema sin licencia y cualquier persona puede presentar pruebas.
Si se encuentra una vulnerabilidad en el sistema de prueba, debería poder ser demostrada on-chain.

En la segunda parte de este artículo, exploraremos cómo varios protocolos intentan lograr estas funciones.

2. prueba de fraude - 概念与误解

2.1. ¿Cómo se implementa la prueba de fraude?

La prueba de fraude proporciona evidencia verificable on-chain de que la raíz de estado presentada es incorrecta, lo que significa que una función de transición de estado específica en L2 no se ejecutó correctamente. Un método simple es generar pruebas de todos los bloques L2 desde la raíz de estado confirmada anteriormente hasta la raíz de estado actual, demostrando así que la raíz de estado es incorrecta. Sin embargo, este método es costoso y consume mucho tiempo.

Por lo tanto, para generar una prueba de fraude válida, primero es necesario reducirla a una transición de estado incorrecta específica y luego generar una prueba para esa parte. La mayoría de los protocolos de prueba de fraude siguen este enfoque.

La prueba de fraude y cuestionamiento del protocolo generalmente incluyen los siguientes pasos:

Los validadores（提出者）presentan periódicamente a la red ETH salidas (o declaraciones) que contienen la raíz del estado L2.
Si los validadores (quienes cuestionan) no están de acuerdo con la salida, ellos presentarán una objeción.
Los proponentes y los cuestionadores identifican las partes en desacuerdo mediante un proceso llamado bifurcación o descomposición, y las refinan a nivel de instrucción o nivel de Bloquear (ZK Rollup).
El cuestionador presenta prueba de fraude en la cadena, demostrando las partes incorrectas. Por lo general, protocolos como Arbitrum y Optimism ejecutarán instrucciones sospechosas en la cadena para su verificación.
Si la prueba de fraude pasa la verificación, las salidas incorrectas serán eliminadas o reemplazadas. Según el protocolo cuestionado, el proponente puede ser castigado y el cuestionador será recompensado.

2.2. 常见误解：prueba de fraude与质疑不会Retroceso链

Es importante tener en cuenta que, incluso en caso de prueba de fraude y cuestionamientos, la cadena no se revertirá. La prueba de fraude garantiza que los fondos en el contrato de puente no sean extraídos maliciosamente, y no implica un retroceso de la transición de estado incorrecta.

La principal razón de no Retroceso es que no es necesario. Cuando ocurre una transición de estado incorrecta en Rollup, el problema central es que un actor malintencionado podría robar los fondos de los usuarios del puente. Para evitar esto, solo se debe garantizar que la raíz de estado enviada a L1 sea correcta. Este proceso no tiene nada que ver con el Retroceso de la cadena, siempre y cuando se evite la confirmación final de una raíz de estado malintencionada, la prueba de fraude y el mecanismo de cuestionamiento son suficientes.

Además, si el proponente del estado raíz y el ordenador de bloques L2 son entidades diferentes, no es necesario utilizar el mecanismo de Retroceso.

Por lo tanto, incluso si se resuelven con éxito las dudas, la cadena L2 no será Retroceso; solo el estado raíz (salida o declaración) presentado a L1 será eliminado o reemplazado. Si la prueba de fraude y el mecanismo de dudas funcionan correctamente, la seguridad de los fondos puente del usuario puede estar garantizada.

2.3. Caso real: Cuestionamiento a Kroma en abril de 2024

A través de casos de interrogación prácticos, se puede ver que toda la cadena Rollup no será Retroceso, solo se reemplazarán o eliminarán las raíces de salida. Hasta ahora, el único caso exitoso de interrogación conocido en Mainnet ocurrió en abril de 2024 en Kroma, que es un Rollup híbrido basado en OP Stack que utiliza pruebas de falla ZK.

Kroma es un Rollup basado en OP Stack, con su propio sistema de prueba de fallas ZK y un sistema de validadores sin permiso. El 1 de abril de 2024, hubo un problema en la fuente L1 del ordenador Kroma, lo que llevó a que el ordenador generara un Bloquear incorrecto. Además, los validadores que observaron esta situación presentaron una raíz de salida incorrecta. Poco después de presentar la raíz de salida, 12 cuestionadores cuestionaron la salida.

Uno de los críticos logró llamar a la función proveFault y eliminó la salida incorrecta.

El cuestionador ha ejecutado exitosamente la función proveFault | Fuente:etherscan

Este es el primer caso exitoso de cuestionamiento en la historia de la Mainnet de ETH Rollup. También es el primer caso en el que se verifica y cuestiona con éxito una prueba de falla en el entorno de Mainnet desde el lanzamiento del primer Optimistic Rollup (Arbitrum) en mayo de 2021, aproximadamente tres años después. Para obtener una descripción detallada de esta cuestión, consulte el artículo escrito por Kroma en https://blog.kroma.network/about-the-first-successful-challenge-on-kroma-mainnet-aeca715b05d7. En este caso, la cadena de Kroma no ha retrocedido, solo se eliminó la raíz de salida incorrecta.

免责声明：prueba de fraude还是故障证明？

La prueba de fraude también se conoce como prueba de fallo. En particular, en las cadenas de Optimism y OP Stack, se utiliza el término 'prueba de fallo', mientras que en proyectos como Arbitrum, Cartesi y L2Beat se utiliza el término 'prueba de fraude'.

Teniendo en cuenta los casos de cuestionamiento de Kroma mencionados anteriormente, se puede inferir que las dudas a menudo provienen de un "error" en lugar de un intento malicioso de manipular retiros. En el caso mencionado, la razón principal fue la anomalía observada por los validadores de Kroma en el cliente L1. En otras palabras, a veces las dudas surgen simplemente debido a errores o parches inadecuados de los validadores. En este caso, el término "prueba de fallas" podría ser más apropiado.

Sin embargo, el término que refleja mejor su propósito es "prueba de fraude". Todos los mecanismos introducidos hasta ahora, y los que se introducirán en el futuro, están destinados a verificar los "actos fraudulentos" que intentan robar los fondos dentro del puente.

El punto es que, aunque el objetivo es prevenir el fraude, en realidad las dudas pueden ser causadas por errores. En este artículo, usaré "prueba de fraude", un término más ampliamente utilizado en el ecosistema.

¡Ataque de Hacker! - Utilizando el mecanismo de prueba de fraude

3.1. Diseño de controversias económicas protocolo

Cada Optimistic Rollup implementa su propio prueba de fraude y mecanismo de cuestionamiento para proteger los fondos de los usuarios. El objetivo común de estos mecanismos es "mantener la seguridad del protocolo siempre y cuando haya al menos un participante honesto". La prueba de fraude es una prueba de que la función de transición de estado programada se ha ejecutado correctamente, y a través del proceso de verificación, resulta en la victoria del participante honesto.

Sin embargo, esto no siempre es cierto. De hecho, incluso con la presencia de participantes honestos, puede haber situaciones en las que el protocolo esté en peligro. Por ejemplo, debido a la complejidad de la prueba de fraude, pueden surgir vulnerabilidades inesperadas, y los participantes maliciosos pueden obtener una ventaja económica sobre los participantes honestos debido a la falta de alineación de los incentivos, lo que resulta en retiros significativamente retrasados o fondos robados.

Por lo tanto, diseñar pruebas de fraude y mecanismos de cuestionamiento es una tarea muy difícil. Especialmente, para convertirse en un Rollup de fase 2, el mecanismo de cuestionamiento debe ser perfecto y debe tener contramedidas contra varios vectores de ataque y vulnerabilidades.

En otras palabras, cada prueba de fraude y mecanismo de cuestionamiento debe tener en cuenta cómo hacer frente a los vectores de ataque. Sin comprender cada vector de ataque, no se puede entender por qué el protocolo debe diseñarse de esta manera.

Por lo tanto, en esta sección, primero examinaremos los siguientes vectores de ataque y exploraremos cómo los protocolos se enfrentan a estos ataques:

Ataques provocados por vulnerabilidades en el juego en disputa;
Ataque de latencia, prolonga el tiempo de retiro del usuario más de 7 días;
Ataques Sybil que consumen los fondos y recursos de los participantes honestos;
Ataque desencadenado por validadores de L1.
Ataque lanzado a través de vulnerabilidades en la Máquina virtual prueba de fraude.

Atención: Todos los Vector de ataque discutidos a continuación son públicos y conocidos, y no afectarán la seguridad de ninguna Mainnet.

En los siguientes capítulos, analizaremos los diversos protocolos y sus características individuales de la siguiente manera:

3.2. Vector de ataque #1: Utilizando juegos de disputas económicas

La mayoría de los rollups optimistas que implementan el mecanismo de prueba de fraude requieren una búsqueda binaria para encontrar el primer punto de divergencia. El protocolo debe proporcionar incentivos para fomentar la honestidad de los participantes, lo cual es muy importante.

Una de las formas más simples de lograr este objetivo es hacer que los participantes apuesten una cierta cantidad de fondos (Margen) al tomar medidas, y serán penalizados con slashing Margen si se considera que actúan maliciosamente.

Desde la perspectiva de la teoría de juegos, el protocolo debe asegurarse de que el capital gastado por los participantes maliciosos en un ataque sea mayor que el capital gastado por los participantes honestos en defensa. Sin embargo, esto es muy difícil de lograr.

La clave aquí radica en que, en un entorno de juego, antes de que se complete el cuestionamiento, no se puede saber de antemano quién es el jugador malintencionado. En otras palabras, el afirmante que presenta la salida puede ser malintencionado, y el cuestionador de la salida también puede ser malintencionado. Por lo tanto, el protocolo debe diseñarse bajo la suposición de que cualquiera de las partes puede ser malintencionada. Además, debido a la posibilidad de varios vectores de ataque, el diseño del protocolo se vuelve extremadamente complicado.

Debido a que cada protocolo utiliza mecanismos diferentes, es necesario definir un Vector de ataque y un modelo de incentivos para cada método correspondiente. Además, se debe diseñar un modelo de seguridad económica para garantizar la seguridad incluso cuando se combinan estos modelos.

Este tema todavía está en discusión continua. En esta sección, analizaremos los posibles Vector de ataque que pueden ocurrir comúnmente, y los incentivos de los participantes en estos escenarios. Además, discutiremos cómo cada protocolo responde a estos ataques y en qué medida limitan dichos incentivos.

3.2.1. Vector de ataque #1-1: latencia攻击

El ataque de latencia se refiere a una entidad malintencionada que no tiene la intención de robar fondos de Rollup, sino de bloquear o retrasar la confirmación en L1. Este tipo de ataque puede ocurrir en la mayoría de los Rollup Optimistas actuales, aumentando el tiempo adicional de retiro, lo que hace que los usuarios tengan que esperar más de una semana para retirar fondos de L1.

Esto difiere ligeramente de un ataque provocado por la revisión de validadores L1, que se discutirá más adelante. La revisión impide que los participantes honestos tomen medidas en la cadena ETH, lo que permite que la raíz del estado malicioso se confirme finalmente. Por otro lado, un ataque de latencia puede confirmar la raíz del estado incluso cuando los participantes honestos están activamente involucrados. En este caso, no solo es posible que se retrase la retirada de los usuarios, sino que si el atacante posee más fondos que el defensor, la raíz del estado malicioso puede confirmarse finalmente, lo que resulta en el robo de los fondos de los usuarios.

Una de las formas más simples de prevenir los ataques de latencia es exigir que los participantes del sistema cuestionen una cantidad determinada de fondos o margen, si se considera que causan latencia, se puede confiscar ese margen.

Sin embargo, hay que tener en cuenta algunos factores. ¿Qué sucede si un atacante todavía intenta un ataque de latencia si no tiene miedo de que sus fondos sean cortados?

Este Vector de ataque es bastante complicado. Esta es también la razón por la que el sistema de prueba de fraude de Arbitrum actualmente funciona en una estructura con licencia.

El mecanismo de prueba de fraude aplicado a Arbitrum One y Arbitrum Classic utiliza un modelo de fork. En lugar de simplemente permitir a los participantes cuestionar declaraciones incorrectas, cada participante puede presentar sus propias declaraciones correctas junto con una cantidad específica de fondos, que se considerarán un 'fork' en la cadena. Las declaraciones también se pueden ver como puntos de verificación en el estado de la cadena.

El modelo de bifurcación de Arbitrum

En Arbitrum Classic, los participantes presentarán declaraciones y ramificaciones de cadena que consideren correctas, y mediante cuestionamientos se irán eliminando gradualmente las ramificaciones incorrectas hasta confirmar la declaración correcta.

Sin embargo, una única pregunta no puede determinar quién tiene la razón. Dos participantes malintencionados pueden utilizar un enfoque erróneo de la división binaria al definir puntos irrelevantes como puntos de discrepancia, excluyendo así la declaración correcta. Por lo tanto, Arbitrum asegura que la pregunta continúe hasta que ningún participante apueste fondos en una declaración específica, garantizando que si al menos hay un participante honesto, la pregunta pueda resolverse con éxito.

Esto puede ser explotado maliciosamente para llevar a cabo ataques de latencia. Supongamos que hay un participante honesto y N-1 atacantes maliciosos que apuestan fondos en la declaración correcta, mientras que un atacante apuesta fondos en la declaración incorrecta. Si los atacantes logran siempre enviar sus transacciones antes que los participantes honestos, pueden plantear un desafío primero. En el peor de los casos, si dividen erróneamente su consenso en lugar de su parte inconsistente, pueden presentar una prueba de fraude en la parte incorrecta. Naturalmente, esto será aprobado, lo que resultará en el fracaso de la parte que apostó fondos en la declaración correcta.

Debido a que cada interrogante puede tomar hasta 7 días, un atacante puede extender el tiempo de latencia del protocolo a 7 * (N-1) días.

Ataque de latencia de Arbitrum Classic | Fuente: L2Beat Medium

El problema de este mecanismo es que el costo del ataque de latencia es lineal con el tiempo de protocololatencia subir. Si un atacante encuentra que este tipo de ataque es rentable, querrán prolongar el tiempo de latencia del protocolo tanto como sea posible, y el tiempo total de latencia estará en proporción directa con el monto total de fondos del atacante, lo que puede resultar en un tiempo de latencia muy largo para los retiros de los usuarios.

En resumen, un protocolo de prueba de fraude que puede defender eficazmente contra los ataques de latencia debe diseñarse de tal manera que limite el tiempo máximo de latencia dentro de un rango determinado, o que el costo de ejecución de la latencia siga un mecanismo de aumento exponencial en el tiempo, de modo que el costo de ejecución de un ataque sea mayor que el incentivo para atacar.

3.2.2. Vector de ataque #1-2: Ataque Sybil (ataque de agotamiento de recursos)

Otro Vector de ataque es el ataque Sybil (ataque de agotamiento de recursos, ataque de Ballena). Esto ocurre cuando los fondos o recursos computacionales del atacante superan a los del defensor. El atacante puede seguir presentando salidas incorrectas o creando desafíos sin sentido, agotando los fondos o recursos computacionales del defensor. En algún momento, el defensor agotará sus fondos o recursos computacionales disponibles, dejándolo sin capacidad de defensa, y el atacante finalmente confirmará la salida incorrecta y robará los fondos.

Por lo general, los Vector de ataque mencionados anteriormente pueden ocurrir en sistemas sin licencia de las siguientes dos maneras:

Enviar sistemáticamente resultados incorrectos. Digamos que el atacante Bob tiene más dinero que los participantes honestos (defensores) Alice, Charlie y David juntos. En este caso, Bob sigue enviando raíces de salida incorrectas. Los participantes honestos Alice, Charlie y David se las arreglarán pagando tarifas de gas y garantías, y en un cierto umbral, los fondos de los participantes honestos se agotarán antes que Bob. En este punto, Bob presenta otro resultado incorrecto que se finalizará sin ser cuestionado, ya que no quedan más participantes honestos en la red con fondos. De esta manera, Bob puede robar dinero de los rollups optimistas.
Presentar múltiples objeciones honestas. Por el contrario, los participantes malintencionados pueden atacar a los participantes honestos presentando múltiples objeciones. Del mismo modo, el ataque continuará hasta que los participantes honestos agoten todos los fondos utilizados para el gas y el depósito, momento en el cual el atacante malintencionado presentará una salida incorrecta y robará fondos de los usuarios del puente.

Para prevenir este tipo de ataques, es necesario diseñar de manera razonable la ventaja del defensor sobre el atacante. En todos los casos, el defensor debe tener una ventaja suficiente sobre el atacante. Una forma de lograr esto es diseñar cuidadosamente el depósito; dado que el ataque de Sybil está relacionado con la cantidad total de fondos disponibles para cada participante, si el depósito se establece adecuadamente, debería poder determinarse que el 'sistema es seguro siempre y cuando el capital total del atacante no supere N veces el capital total del defensor'.

Otra forma conocida de prevenir los ataques de Sybil es implementar un protocolo de resistencia a Sybil. En los próximos capítulos, presentaremos más detalles sobre Cartesi Dave.

Veamos cómo cada protocolo aborda estos problemas de latencia y ataques de Sybil a través de su diseño respectivo.

3.3. Solución #1: Juego de disputas económicas saludables

1） Arbitrum BoLD

BoLD en base al modelo de ramificación de Arbitrum Classic, ha introducido los siguientes tres elementos para prevenir vulnerabilidades de latencia ataque:

Todos contra todos los mecanismos de cuestionamiento. En BoLD, el cuestionamiento ya no se realiza por pares, sino que se utiliza un sistema de todos contra todos en el que todos los participantes pueden apostar fondos en la rama en la que están de acuerdo. Esto evita la latencia y el vector de ataque producidos por el cuestionamiento uno a uno anterior y garantiza que no puedan haber múltiples cuestionamientos independientes sobre la misma disputa.
La prueba calculada en el estado correcto previene la bifurcación maliciosa (compromiso histórico). El problema en Arbitrum Classic es que los participantes malintencionados pueden bifurcar de manera incorrecta, causando intencionalmente latencia, marcando la parte indiscutible como un punto de disputa. Por lo tanto, BoLD requiere una prueba de presentación, junto con la raíz del estado, para verificar que la raíz del estado se haya calculado correctamente durante el proceso de bifurcación, asegurando que no haya ocurrido una bifurcación maliciosa.

En BoLD, los participantes deben presentar pruebas y raíces de estado durante el proceso de bifurcación. Esta prueba verifica si la raíz de estado actual se ha calculado correctamente en base a la raíz de estado presentada anteriormente. Si un participante malintencionado intenta presentar cualquier raíz arbitraria que no esté relacionada con la raíz de estado previamente presentada durante el proceso de bifurcación, la verificación de la prueba fallará, lo que resultará en el fallo de la transacción de bifurcación. Esto efectivamente garantiza que cada declaración solo puede dar lugar a un tipo de bifurcación.

Por lo tanto, si un atacante quiere bifurcar repetidamente una declaración honesta en BoLD, debe presentar varias declaraciones.

Sin embargo, generar esta prueba requiere que los validadores utilicen una cantidad considerable de recursos computacionales. Internamente, generar esta prueba implica generar un hash para todos los estados en la partición binaria, lo cual en Arbitrum se estima que requiere aproximadamente 270 hashes (aproximadamente 1.18 x 10²¹). Para abordar este problema, BoLD divide las disputas en tres niveles, reduciendo la cantidad de hashes que se deben calcular a 226 (aproximadamente 6.71 x 10⁷).

（Esta figura supone un total de 269 instrucciones, los datos reales pueden variar）

Restringir el tiempo de stake a través del mecanismo de reloj de ajedrez.

En Arbitrum Classic anteriormente, la duración de la controversia no tenía límite de tiempo, lo que permitía a los participantes maliciosos demorar el proceso indefinidamente siempre y cuando tuvieran suficiente financiamiento. BoLD ha introducido un mecanismo de reloj de ajedrez que limita efectivamente la duración de la controversia.

Supongamos que dos participantes presentan declaraciones diferentes. Cada participante tiene un cronómetro (reloj de ajedrez) con un tiempo de 6.4 días. Cuando le toca a un participante presentar una bifurcación o una prueba, el cronómetro comienza a contar atrás y se detiene cuando el participante completa la tarea.

Dado que cada participante tiene un tiempo máximo de latencia de 6.4 días, el tiempo máximo de latencia de un solo participante en el proceso es de 6.4 días. Por lo tanto, en BoLD, la duración máxima de una pregunta es de 12.8 días (en algunos casos, se agrega un tiempo extra de 2 días cuando el comité de seguridad interviene).

A través de estos mecanismos, Arbitrum BoLD limita eficazmente la latencia causada por las dudas. El tiempo máximo de duda es de dos semanas y la latencia adicional máxima que puede experimentar un usuario es de aproximadamente una semana.

Sin embargo, esto podría ser aprovechado para llevar a cabo ataques de latencia. Los participantes malintencionados pueden crear una impugnación y conspirar con los validadores de L1 para revisar a los validadores honestos en Arbitrum, lo que resulta en una latencia de retiro de hasta una semana para los usuarios de Arbitrum. En este escenario, los usuarios que soliciten retiros durante este período podrían enfrentar costos de oportunidad debido a la retención de fondos. Aunque este no es un ataque en el que el atacante obtenga directamente ganancias de los fondos, aún debe prevenirse debido al costo de oportunidad que implica para los usuarios. Arbitrum BoLD está abordando este problema al establecer depósitos en garantía lo suficientemente altos para crear una impugnación, como un medio disuasorio para este tipo de ataques.

Arbitrum en el documento económico en negrita calculó esta cantidad. El principal motivo de la protocolo de latencia es la revisión de validadores L1. En caso de un ataque de latencia, la situación se desarrollará de la siguiente manera:

El atacante presenta una declaración N' en Arbitrum que no coincide con la declaración N existente.
Los defensores intentaron enviar una transacción bifurcada, pero la operación falló porque los validadores de L1 estaban revisando la transacción cuestionada de los defensores.
Debido a que se supone que la revisión de BoLD no puede durar más de 7 días, esto puede resultar en la confirmación final de la declaración N en un máximo de una semana.

Los beneficios del atacante provienen del costo de oportunidad generado al solicitar retiros a los usuarios que cuestionan las salidas. En el peor de los casos, todos los fondos en Arbitrum se solicitan en una salida, y el costo de oportunidad para los usuarios se calcula de la siguiente manera, suponiendo que el TVL de Arbitrum One sea de $15.4 mil millones y el APY sea del 5%:

El costo de oportunidad = 15,400,000 x (1.051/52 - 1) = $14,722,400

Debido a que la presentación de declaraciones inexactas puede acarrear costos de oportunidad tan altos, a los presentadores de declaraciones en BoLD se les pide que proporcionen un depósito de un nivel similar. Actualmente, se ha fijado un depósito de aproximadamente 3600 ETH para la presentación de declaraciones en BoLD, que equivale a unos 940 millones de dólares.

Esto se hace para prevenir que los atacantes causen grandes pérdidas al sistema a través de la latencia. Dado que los atacantes perderían su depósito en caso de disputa, podrían causar un costo de oportunidad de hasta 1470 millones de dólares, pero perderían alrededor de 940 millones de dólares. Por lo tanto, BoLD suprime los ataques de latencia al exigir un depósito que sea considerablemente igual al costo de oportunidad en el peor de los casos.

Sin embargo, el depósito de garantía de 3600 ETH no se establece únicamente debido al ataque de latencia. Para defenderse de los ataques de Sybil, Arbitrum BoLD puede garantizar que el sistema se mantenga seguro hasta que los fondos totales del atacante sean 6.5 veces los fondos totales del defensor, que es la base para determinar el monto del depósito de garantía de 3600 ETH.

Desde la perspectiva del ataque Sybil, se pueden producir los siguientes escenarios de ataque en Arbitrum BoLD. El sistema de cuestionamiento de BoLD consta de tres niveles, y los usuarios deben bloquear fondos para presentar sus declaraciones que consideran correctas.

Supongamos que el participante honesto Alice presenta una declaración válida por una cantidad de X ETH. El participante malicioso Bob, que posee 3600 ETH, puede crear múltiples declaraciones maliciosas. En este caso, Alice necesita bloquear Y ETH en la capa inferior por cada declaración de Bob.

En el modelo de bifurcación de Arbitrum, bloquear fondos significa acordar el estado de la cadena desde el génesis hasta la declaración. Esta característica permite a los participantes mover los fondos que han hipotecado desde la declaración A hacia sus subdeclaraciones A' y A''. Por lo tanto, Alice transfiere sus X ETH inicialmente hipotecados a la capa inferior y bloquea Y ETH para cada declaración maliciosa de Bob.

Si Bob tiene claramente más fondos que Alice, ¿qué sucederá? Bob puede generar innumerables declaraciones maliciosas hasta que los fondos de Alice se agoten y no pueda seguir bloqueándolos. En ese momento, Alice no podrá seguir dividiendo, lo que permitirá a Bob confirmar declaraciones incorrectas.

En última instancia, este problema se reduce al grado en que el defensor debería tener una ventaja sobre el atacante en el juego.

Arbitrum llama a este indicador la proporción de recursos. Esto muestra el grado de ventaja de los participantes honestos en comparación con los participantes maliciosos. Esta proporción se representa mediante la relación entre las tarifas de gas (G) y la cantidad de depósito (S) que cada participante debe pagar, como se muestra a continuación:

El sistema de cuestionamiento de BoLD se divide en tres niveles, manteniendo esta proporción de recursos en cada nivel para garantizar que el defensor siempre tenga una ventaja N veces mayor que el atacante en todo el sistema. Arbitrum calcula la cantidad de garantía necesaria en el nivel superior y traza gráficos en función de esta proporción de recursos.

（Costo de colateralización de capa superior frente a la proporción de recursos de Arbitrum BoLD | Fuente：Desmos）

Según el gráfico, cuando la relación de recursos es 100 veces, el depósito requerido en la parte superior supera los 1 millón de ETH (más de 4 billones de dólares). Aunque una proporción de recursos más alta hace que el sistema sea más seguro contra ataques Sybil, el monto del depósito es tan alto que prácticamente nadie puede participar en el sistema, lo que lo hace no diferente de un sistema centralizado con solo un validador presentando afirmaciones.

Por lo tanto, en BoLD, la proporción de recursos se establece en 6.5 veces, lo que hace que la garantía en la capa superior sea de 3600 ETH, mientras que las garantías en el primer y segundo nivel se establecen en 555 ETH y 79 ETH respectivamente.

En resumen, BoLD asegura que los defensores tienen 6.5 veces más ventaja sobre los atacantes mediante el cálculo de la proporción de recursos y el establecimiento de la cantidad de garantía para prevenir los ataques de Sybil.

2）Cartesi Dave

Dave de Cartesi presentó por primera vez en 2022 en un documento titulado '非许可评审锦标赛' antes del primer White Paper de BoLD. Su objetivo es mantener la ventaja de los participantes honestos en recursos computacionales y fondos sobre los atacantes. La estructura de Dave es similar a la de BoLD y tiene dos características clave:

Evita la bifurcación maliciosa mediante el cálculo de la prueba de estado correcto (compromiso histórico).

Al igual que BoLD, Dave requiere que los participantes generen pruebas durante el proceso de bifurcación para demostrar que realizaron los cálculos correctamente, evitando así formas maliciosas de bifurcación. Por lo tanto, el sistema de interrogación de Dave también se divide en varios niveles para ahorrar recursos de validadores.

En la estructura del torneo se utiliza un mecanismo de cuestionamiento de uno a uno en secuencia.

El cuestionamiento de Dave no se realizó de una sola vez, sino en forma de torneo, como se muestra en la siguiente imagen.

La imagen de arriba muestra cómo se cuestiona la red cuando un atacante malintencionado presenta siete declaraciones incorrectas. Debido a la naturaleza de los compromisos históricos, los participantes honestos que respaldan las declaraciones correctas (representadas en verde) se agrupan para formar un equipo. En Dave, están organizados en forma de torneo y se colocan según lo ilustrado, con cada participante desafiando a otro. Los desafíos en la misma etapa se llevan a cabo en paralelo, y después de una semana, cuando se completa el cuestionamiento, el ganador avanza a la siguiente etapa. En la imagen, el equipo de participantes honestos debe pasar por tres rondas de cuestionamiento para ganar el torneo.

Esta característica es muy efectiva para prevenir ataques Sybil. En primer lugar, el atacante debe crear múltiples declaraciones para llevar a cabo el ataque Sybil, cada una de las cuales consumirá significativamente los recursos computacionales y financieros del atacante.

El paper de Cartesi demuestra que, en cualquier escenario, el defensor mantiene una ventaja exponencial sobre el atacante. En otras palabras, Dave asegura que puede defenderse de los ataques de Sybil con recursos logarítmicos en comparación con la cantidad de atacantes. Esto hace que sea muy difícil llevar a cabo un ataque de Sybil en Dave, por lo que la cantidad de depósito de Dave se establece en un mínimo de 1 ETH, mucho menor que la cantidad en BoLD.

Sin embargo, Dave es muy susceptible a los ataques de latencia. Cada fase del torneo consume una unidad de tiempo de duda (una semana), por lo que cuanto más maliciosas sean las declaraciones, más larga será la protocololatencia. El tiempo necesario para resolver completamente una duda en Dave se puede representar con la siguiente fórmula:

Td = 7 x log2(1 + NA)(天数)

Donde NAN_ANA representa la cantidad de declaraciones maliciosas. Sin embargo, la duda de Dave puede estar compuesta por varios niveles para generar compromisos históricos de manera efectiva. Aquí, los participantes malintencionados pueden generar NAN_ANA declaraciones maliciosas en cada nivel de duda, lo que aumentará el tiempo total de latencia, como se muestra a continuación:

Td = 7 x [log2(1 + NA)]L(días)

Donde LLL representa la cantidad de niveles en cada objeción. Si, como se muestra en la imagen anterior, hay siete objeciones maliciosas y L=2, la resolución completa de las objeciones podría llevar hasta 9 semanas, y los usuarios experimentarían una latencia adicional de 2 meses en los retiros. Si aumenta la cantidad de niveles o la cantidad de objeciones maliciosas, la latencia podría extenderse a varios meses.

Cartesi tiene como objetivo abordar este problema utilizando pruebas de conocimiento cero (ZK), que se discutirán en detalle en la sección 4, 'Mejoras factibles'.

3）乐观故障证明（Optimism Fault Proof, OPFP）

OPFP es un protocolo de permissionless, actualmente en la aplicación Mainnet de OP, con las siguientes características:

Todos los mecanismos de duda concurrentes de todos contra todos utilizando árboles de juegos

OPFP permite a cualquier persona presentar una salida (declaración de raíz) en cualquier momento. Los validadores que no estén de acuerdo con la salida presentada pueden cuestionarla mediante un proceso de bifurcación.

Arquitectura de árbol de juego OPFP y proceso de partición binaria | Fuente: Archivo de optimismo

El proceso de bifurcación se lleva a cabo de manera concurrente en el árbol de juego que se muestra arriba. Las hojas del árbol representan el estado de L2, y cada Nodo en el árbol corresponde a un estado en L2, la hoja más a la derecha representa el estado más reciente de L2. Por ejemplo, presentar una declaración en el Nodo 1 es equivalente a presentar un estado en el Nodo 31.

Esta estructura permite representar la bifurcación. Por ejemplo, si un validadores no está de acuerdo con la declaración de la raíz (Nodo 1), presentarán una declaración en Nodo 2, Nodo 2 corresponde al Nodo 23 en el árbol, ya que es el punto medio entre el Nodo 16 y el Nodo 31. El remitente de Nodo 1 luego verificará el estado L2 de Nodo 23, si está de acuerdo, enviará Nodo 6 (Nodo 27); si no está de acuerdo, enviará Nodo 4 (Nodo 19), y continuará este proceso hasta encontrar una divergencia.

Incluso si hay múltiples direcciones de bifurcación en un juego, pueden ocurrir simultáneamente y cualquier persona puede participar en el proceso de bifurcación, no solo el remitente de la salida.

Estructura completa del árbol de juego OPFP | Fuente: Archivo OP

El árbol de juegos utilizado en OPFP es una estructura anidada, donde el árbol superior maneja la bifurcación a nivel de Bloquear, mientras que los subárboles inferiores manejan la bifurcación a nivel de instrucción.

A diferencia de BoLD o Dave, OPFP no hace cumplir la bifurcación correcta mediante promesas históricas, ya que los costos de generar y presentar dichas promesas fuera/de la cadena son altos.

Juego de controversia personalizable basado en módulos Actualmente, OP Mainnet solo ha lanzado dos tipos de juegos de disputas (no autorizados/autorizados). Optimism tiene como objetivo introducir eventualmente varios tipos de juegos de disputas y ha implementado una interfaz mínima que respalda este objetivo. Se pueden crear juegos de disputas personalizados siguiendo los nombres y parámetros de funciones especificados.
A través del reloj de ajedrez para limitar el tiempo de cuestionamiento

En OPFP, cuando se plantea una pregunta, tanto el proponente como el cuestionador reciben un reloj que se asigna para dividir el tiempo. Cada vez que se presenta una declaración, el reloj comienza a contar hacia el otro. Optimism lo llama 'reloj heredado del abuelo'.

Lo interesante es que cada participante tiene 3.5 días en lugar de 7 días, lo que significa que si nadie cuestiona la salida, será confirmada definitivamente en 3.5 días.

Sin embargo, esto no permite el retiro inmediato. Después de que se haya confirmado la salida final, OPFP tiene un período de custodia de 3.5 días, durante el cual la comisión de seguridad puede intervenir y, si es necesario, invalidar salidas incorrectas.

Proceso de retiro de fondos del usuario en el "Happy Path" | Fuente: OP Labs Blog

Basándose en estos mecanismos, OPFP y otros rollups optimistas, garantizan a los usuarios que podrán retirar fondos al menos 7 días después de la presentación. Sin embargo, si surge una disputa, es posible que los usuarios necesiten más de 7 días para retirar los fondos a través de esa salida. El modelo de reloj de ajedrez de OPFP limita el tiempo que cada participante puede gastar en el proceso de bifurcación, pero no limita estrictamente el tiempo total antes de que se resuelva la disputa.

Esto plantea una pregunta: ¿Es posible que los retiros de los usuarios en OPFP sean latencia durante más de una semana, similar a la situación de BoLD? La respuesta es 'sí'. A diferencia de BoLD o Dave, Optimism ofrece a los usuarios opciones para enfrentar situaciones de cuestionamiento, basadas en las características únicas del protocolo.

OPFP opera bajo la suposición de que "los participantes que presenten declaraciones incorrectas perderán su Margen". Sin embargo, en OPFP existe un caso límite que rompe esta suposición, conocido como "declaración de viaje gratis". Esta situación puede ocurrir en los siguientes escenarios:

Alice presentó una declaración con la raíz de estado correcta.
Bob presentó una contra-declaración, mientras que Alice tomó medidas para defender su declaración original.
Bob espera hasta que su reloj casi se agote (3.5 días) y luego cuestiona su propia declaración.

En este punto, Alice debería responder y reclamar el Margen de Bob, pero heredó el tiempo restante en el reloj de Bob, lo que puede no ser suficiente para refutar su declaración. Por lo tanto, Bob puede evitar perder su Margen presentando una 'declaración de viaje gratuito'.

Declaración de free-riding en Optimism Fault Proof | Fuente:L2Beat

Aunque esto no impide que las dudas se resuelvan correctamente, sí representa una situación en la que se "presenta una declaración incorrecta pero no se realiza el slashing Margen", desde el punto de vista del incentivo, esta situación debería evitarse.

Por lo tanto, si el tiempo restante del proponente o cuestionador es inferior a 3 horas, OPFP resuelve este problema restableciendo el reloj a 3 horas. Esto garantiza que haya suficiente tiempo para refutar las declaraciones de aprovechamiento. Sin embargo, si no se toma ninguna acción durante el próximo período de dos minutos en un plazo de más de 3 horas, la objeción finalizará.

Podemos imaginar una escena en la que este mecanismo se utiliza para llevar a cabo un ataque de latencia. Supongamos que el participante honesto Alice presenta una salida correcta, desde el momento en que Alice presenta, el reloj del cuestionador comienza a contar. El participante malicioso Bob espera hasta 1 segundo antes de que expire el reloj del cuestionador para presentar una salida incorrecta. En este punto, las reglas de OPFP extenderán el tiempo de Bob a 3 horas. Alice responderá, y Bob seguirá aprovechando las 3 horas adicionales proporcionadas para cada bifurcación.

Esto podría plantear dudas sobre la latencia. Bob puede latencia durante un máximo de 3.5 días + 3 horas × el número máximo de divisiones. MAX_GAME_DEPTH de OPFP es 73, lo que significa que Bob puede latencia el proceso durante 3.5 días + 3 horas × 36 = 8 días. Si Alice también toma medidas similares para cuestionar la latencia, el proceso de división podría tardar 16 días.

¿Significa esto que los usuarios no pueden retirar fondos en 16 días? En realidad, no es así, ya que la lógica de retiro de Optimism hace que esta situación no sea válida. A diferencia de Arbitrum, que requiere que los retiros demuestren estar incluidos en un bloque L2 específico, OP Stack utiliza un mecanismo de almacenamiento de prueba, donde las solicitudes de retiro se registran en el contrato L2ToL1MessagePasser en L2. Esto significa que incluso si el tiempo de cuestionamiento de una salida específica es largo, los usuarios aún pueden esperar a que se complete la siguiente salida y retirar fondos según la raíz de almacenamiento del contrato incluida en esa salida. Por lo tanto, incluso si el bloque de retiro específico es cuestionado, los usuarios no tienen que experimentar largas latencias, ya que pueden usar la siguiente salida.

Sin embargo, todo esto solo es válido si el usuario actúa rápidamente. En la mayoría de los casos, es posible que los usuarios aún experimenten una latencia de varios días. Esto se debe al proceso de retiro en la pila OP, que consta principalmente de los siguientes tres pasos:

Inicie retiros en L2 (initiateWithdrawal)
Probar la transacción de retiro en L1 (proveWithdrawalTransaction), que incluye las salidas del retiro.
Esperar una semana para que la prueba de latencia madure y luego completar finalmente la transacción de retiro (finalizeWithdrawalTransaction).

El punto clave es que, desde la demostración de retiro hasta la finalización del retiro, el usuario debe esperar una semana. Si Alice demuestra su retiro en la salida B y surge una objeción, puede enviar otra demostración para la salida C y completar la retirada una semana después. En este caso, Alice solo experimentará la latencia entre las salidas B y C.

Por lo tanto, aquellos usuarios que no estén al tanto de las dudas planteadas o que respondan tarde pueden experimentar hasta 9 días adicionales de latencia en los retiros.

Además, en OPFP hay un Vector de ataque de latencia adicional, es decir, cada salida se cuestiona continuamente. En este caso, los usuarios no pueden evitar la latencia al demostrar en la siguiente salida, lo que resulta en que toda la protocolo está afectada por la latencia. OPFP aborda esto al requerir que los participantes hagan stake Margen en cada nivel binario, el monto de Margen aumenta exponencialmente, como se muestra en la siguiente imagen.

OPFP Monto de Margen | Fuente: Optimism documento

En otras palabras, cuanto más tiempo intente el atacante cuestionar la latencia en OPFP, mayor será el costo de Margen requerido, ya que la exigencia de Margen es exponencial, lo que reduce el incentivo para realizar ataques de latencia con el tiempo. Además, dado que la salida en OPFP se puede presentar en cualquier momento, es difícil para el atacante evaluar los recursos necesarios para llevar a cabo un ataque de latencia. El Margen inicial se establece en 0.08 ETH, mientras que el total del Margen requerido para un cuestionamiento completo asciende a ~700 ETH.

En resumen, OPFP deja la duración de latencia en manos de los usuarios en caso de una única pregunta y utiliza un requisito de Margen exponencial para compensar los ataques de latencia causados por preguntas continuas. Sin embargo, OPFP es susceptible a ataques de Sybil. En OPFP, si el atacante tiene más fondos que el defensor, puede ocurrir un ataque de Sybil.

En OPFP puede haber los siguientes vectores de ataque de Sybil, todos los cuales pueden resultar en el robo de fondos de los usuarios:

El atacante crea varias dudas, lo que hace que el defensor utilice todos los fondos en Margen y tarifas de Gas.
Los atacantes continúan enviando salidas incorrectas, obligando a los defensores a responder hasta que se agoten sus fondos en margen y tarifas de gas.

Esto es posible en OPFP, ya que durante todo el proceso de cuestionamiento, la cantidad total de Margen necesaria tanto para el atacante como para el defensor es casi la misma, y los recursos utilizados por el defensor (por ejemplo, tarifas de Gas o Potencia computacional) no son significativamente menores que las del atacante.

Sin embargo, esto no significa que los fondos de los usuarios en la Mainnet de OP estén en riesgo. OPFP todavía está en la fase 1 y el Comité de Seguridad tiene el poder de corregir cualquier resultado incorrecto. Por lo tanto, incluso en caso de un ataque de este tipo, el Comité de Seguridad puede intervenir y proteger los fondos de los usuarios en el puente de la Mainnet de OP.

Sin embargo, para llevar OPFP a la Fase 2, Optimism debe modificar el mecanismo para asegurar que el defensor tenga una ventaja mayor sobre el atacante. Optimism está preparando el juego controvertido V2 para abordar este problema, y más detalles se presentarán en la sección 4 'Mejoras viables'.

4) Prueba de fallo Kroma ZK (Kroma ZKFP)

Kroma es una capa 2 basada en OP Stack. Antes de la introducción de OPFP, lanzó un sistema ZK sin permiso en su Mainnet en septiembre de 2023. Kroma ZKFP tiene características similares a OPFP, pero se destaca por generar pruebas a nivel de bloque utilizando ZK y utiliza descomposición en lugar de división binaria, lo que reduce significativamente la cantidad de interacciones necesarias en el proceso de desafío. Las principales características de Kroma ZKFP se resumen a continuación:

A través de ZK y descomposición para reducir la frecuencia de interacción

Kroma ZKFP permite a los participantes encontrar puntos de divergencia dentro de cuatro interacciones. Cuando se plantea una pregunta, Kroma ZKFP maneja la pregunta en 1,800 Bloquear, desde la salida anterior hasta la salida actual. A diferencia del método de la bisección, donde el rango se divide por la mitad, en la descomposición, el proponente y el cuestionador dividen el rango en N partes. El proceso es el siguiente:

Una vez que cada participante ha presentado dos transacciones, se determinará el Bloquear en el que difieren, los que cuestionen pueden generar una prueba de fallo ZK para demostrar que la afirmación del proponente es incorrecta. En Kroma ZKFP, el tiempo de espera binario se establece en 1 hora, mientras que el tiempo de espera para generar la prueba ZK es de 8 horas.

Lograr la descentralización de los validadores a través de un mecanismo de incentivos

BoLD y OPFP proporcionan incentivos a los ganadores cuestionados, pero no proporcionan incentivos específicos para los remitentes de salidas; de hecho, cualquier persona que desee retirar fondos puede enviar salidas y convertirse en validadores. Sin embargo, para los usuarios que deseen retirar, operar el cliente validadores por sí mismos es poco práctico, y debe haber alguien que envíe salidas de forma regular para mantener la actividad. Dado que esta es una tarea intensiva en recursos, se requiere pagar tarifas de gas para enviar salidas y operar el cliente validadores, por lo que sin incentivos adecuados, es posible que solo unos pocos participen como validadores, lo que podría resultar en centralización y una respuesta insuficiente en escenarios de fallo.

Para esto, Kroma modificó el OP Stack, asignando la mitad de las tarifas de gas generadas en la cadena a los validadores que envían las salidas. Además, Kroma planea trasladar este mecanismo de recompensa a su token nativo KRO después de la TGE, y tiene como objetivo introducir un sistema de validadores similar a DPoS para permitir que los usuarios normales contribuyan a la seguridad y la actividad de la cadena sin ejecutar su propio cliente.

La cantidad de Margen en Kroma actualmente se establece en 0.2 ETH para garantizar que sea mayor que el costo de generar pruebas de conocimiento cero (ZK) y realizar la partición binaria. Este Margen se convertirá en una apuesta de KRO en el sistema de validadores futuro.

Sistema de desafío 1 contra 1 simultáneo

Para garantizar una distribución justa y consistente de incentivos, Kroma fija el intervalo de presentación de propuestas en 1 hora y selecciona al azar validadores de la colección preinscrita de validadores como proponentes. Esto evita la competencia excesiva que conduce al desperdicio de tarifas de gas y evita el monopolio de los constructores de bloques que poseen el derecho de ordenar transacciones.

Debido a este mecanismo, Kroma ZKFP opera un sistema de cuestionamiento 1 a 1 concurrente. Cuando los validadores seleccionados al azar presentan una salida, cualquiera puede plantear una objeción, limitada a solo el presentador de la salida y el objetante. Múltiples objeciones pueden ocurrir simultáneamente, y el primer objetante que presente una prueba ZK válida ganará la objeción.

El límite de tiempo estrictamente establecido significa que incluso los malintencionados que intenten realizar un ataque de latencia deben completar todas las operaciones de bifurcación y generación de pruebas dentro de las 10 horas. Además, como los cuestionadores están obligados a completar todas las operaciones dentro de los 6 días (excluyendo el período de custodia de 1 día), no es posible llevar a cabo un ataque de latencia general en Kroma.

Sin embargo, si el atacante tiene más fondos que el defensor, Kroma ZKFP seguirá siendo vulnerable a un ataque de Sybil, similar a OPFP. En Kroma ZKFP, el escenario de un ataque Sybil puede ser el siguiente:

Los atacantes siguen cuestionando las salidas válidas hasta que el financiador de las salidas se agote, momento en el cual el atacante presenta una prueba de conocimiento cero (ZK) para ganar la disputa.

Al igual que OPFP, Kroma ZKFP eliminará las salidas correspondientes después de una exitosa impugnación. Por lo tanto, si ocurre dicho ataque, la latencia de extracción de fondos del usuario puede llegar a ser de 1 hora. Si el ataque continúa, todos los validadores honestos pueden quedarse sin fondos, lo que resultaría en la confirmación de salidas incorrectas y permitiría al atacante robar los fondos del usuario.

Además, Kroma ZKFP todavía está en la fase 0 y su sistema de prueba no está completamente desarrollado por las siguientes razones:

El punto de partida de la bifurcación se basa en la salida enviada por última vez, no en la salida confirmada por última vez.

En OPFP, el punto de partida para la bifurcación suele ser la última salida confirmada hace aproximadamente una semana. Sin embargo, en Kroma ZKFP, el punto de partida es la salida enviada más recientemente, que se envió hace aproximadamente 1 hora, y el proceso de bifurcación se lleva a cabo en 1.800 Bloquear.

Esto puede permitir que los cuestionadores ganen en caso de que se hayan eliminado las salidas anteriores debido a cuestionamientos. En este caso, la bifurcación se basará en la información de salida anterior presentada por el cuestionador, y si manipulan maliciosamente esta información, podrían ganar el cuestionamiento.

No se ha verificado si cada validadores cuestiona sobre los datos de lote correctos.

Aunque Kroma ZKFP utiliza ZK para asegurar que si no hay vulnerabilidades en el circuito ZK, no es posible confirmar un cambio de estado incorrecto, Kroma ZKFP no verifica si la generación de pruebas ZK se basa en los datos de lote correctos. Esto significa que incluso si se excluyen algunas transacciones o se incluyen transacciones incorrectas en el lote, las pruebas ZK aún pueden ser verificadas.

Por lo tanto, es posible ganar cuestionamiento utilizando pruebas de conocimiento cero basadas en datos incorrectos, y si las transacciones de retiro de los usuarios se excluyen del lote, sus retiros podrían experimentar latencia.

Sin embargo, en la práctica, el comité de seguridad puede intervenir para retirar los resultados de las dudas incorrectas o eliminar las salidas inválidas, por lo que estos Vectores de ataque no afectarán los fondos de los usuarios de Kroma Mainnet. Sin embargo, para alcanzar la fase 2, Kroma ZKFP debe implementar mecanismos de defensa contra estas vulnerabilidades. Kroma ha propuesto mejoras para abordar estos problemas, que se describirán en detalle en la sección 4 'Mejoras factibles'.

3.4 Vector de ataque #2: L1 Auditoría

Anteriormente mencionamos que Rollup hereda la seguridad de Ethereum. Esto significa que si la seguridad de Ethereum se ve comprometida, Rollup también se verá afectado.

Dos situaciones en las que la situación de Ethereum puede afectar la seguridad de Rollup:

Los validadores de la red Ethereum examinan las transacciones de prueba de fraude de Rollup. **Si los validadores o constructores de ETH fingen colaborar y envían raíces de salida maliciosas en Optimistic Rollup, al mismo tiempo que revisan todas las transacciones relacionadas con la prueba de fraude, ¿qué sucederá? Si la disputa no se resuelve dentro del plazo establecido, la salida se confirmará y los fondos de los usuarios podrían correr riesgos. Esto se conoce como una auditoría débil. En el caso de Optimistic Rollup, si esta auditoría continúa durante más tiempo del establecido (generalmente 7 días), los fondos del usuario podrían estar en riesgo.
**Ethereum ha sufrido un ataque del 51%, lo que ha llevado a la revisión de todas las transacciones de prueba de fraude. **Este escenario implica dos posibles vías de ataque:

En primer lugar, una entidad puede obtener más del 2/3 de la participación total de ETH en Ethereum, lo que les permitiría confirmar Bloquear a su antojo. En este caso, el atacante podría revisar las transacciones de prueba de fraude e incluso generarlas a su antojo.
El segundo método implica a un participante que posee más del 1/3 del stake total de Ethereum para llevar a cabo un ataque 'encubierto'. Esto se describe en la investigación 'Ataque de censura no atribuible a base de prueba de fraude en protocolos de capa 2' en el artículo '针对基于prueba de fraude的 L2 protocolo的不可归因审查攻击'. En este escenario, el atacante con el 1/3 del stake de Ethereum puede bloquear la confirmación de cualquier Bloquear que no les guste. Si el atacante continúa votando por los Bloquear normales mientras mantiene silencio sobre los Bloquear que contienen prueba de fraude, podrían confirmar una raíz maliciosa, lo que les permitiría robar fondos del Optimistic Rollup. Esto se conoce como ataque de censura no atribuible a base de prueba de fraude en capa 2. Este tipo de ataque es más difícil de detectar que simplemente obtener más del 2/3 del stake y controlar todos los Bloquear de Ethereum.

Estos ataques basados en revisión son difíciles de abordar a nivel de Rollup, ya que ocurren en la capa de protocolo de Ethereum y requieren mejoras en Ethereum en sí. Sin embargo, durante este tiempo, Rollup puede adoptar algunas estrategias.

Solución 3.5: Retiro de fondos en 7 días latencia y recuperación de ataques del 51% semiautomatizados

Para hacer frente a estos vectores de ataque, Optimistic Rollup ha implementado actualmente una latencia de retiro de 7 días. Estos 7 días fueron propuestos inicialmente por Vitalik como una idea de que son "suficientes" para hacer frente a los ataques de revisión.

Veamos si el período de cuestionamiento de 7 días de Optimistic Rollup es suficiente para resistir los ataques de censura, considerando dos tipos de censura: censura débil y censura fuerte.

Para el primer tipo de auditoría débil, podemos utilizar cálculos de probabilidad para ver si un período de 7 días le da a Optimistic Rollup la capacidad de resistir ataques de auditoría. Esto implica calcular la probabilidad de éxito al cuestionar el fraude cuando algunos validadores cuestionan las transacciones Rollup.

Aquí, hay que considerar dos factores:

Para tener éxito en la disputa dentro de los 7 días, se deben haber realizado varias transacciones exitosas.

En la mayoría de los protocolos, si solo se incluye una transacción de un participante honesto durante esta semana, la duda no tendrá éxito. Por lo tanto, necesitamos calcular la probabilidad de que se incluyan todas las transacciones necesarias para presentar una prueba de fraude en 7 días.

Es necesario hacer una suposición razonable sobre la proporción de validadores involucrados en la revisión. Actualmente, la mayoría de los constructores de bloques de la comunidad ETH (conocidos por ser centralizados) no han sido validados, considerando la proporción de validadores individuales en la comunidad ETH, la posibilidad de que la gran mayoría (por ejemplo, el 99,9%) de los validadores coludan para validar es casi nula.

(Revisión de los principales constructores de Bloquear de Ethereum | Fuente: tweet de Justin Drake)

Teniendo en cuenta estos dos puntos, si asumimos que el 99.5% de los validadores (todavía es una suposición demasiado extrema) participan en la revisión y calculamos la probabilidad de que los participantes honestos tengan éxito al enviar 30 a 40 intercambios cuestionando el protocolo (como BoLD u OPFP), entonces en todos los casos, la probabilidad de éxito es cercana al 100%. Además, con la aparición de futuras soluciones (como la inclusión en listas o múltiples proponentes concurrentes, como BRAID, APS + FOCIL), la capacidad de resistir la revisión podría aumentar aún más, lo que podría Soltar el riesgo de pérdida de fondos de usuario de Optimistic Rollup debido a una revisión débil.

Entonces, ¿es suficiente con 7 días bajo la supervisión estricta? El ataque del 51% mencionado anteriormente solo se puede resolver a través de un fork social. Los ataques de censura no atribuibles son especialmente difíciles de detectar y no se pueden prevenir mediante soluciones diseñadas para la censura débil (como listas).

Una propuesta es desarrollar una herramienta de recuperación de ataques del 51% semiautomática en el software del cliente, basada en la estructura propuesta por Vitalik. Los investigadores de ETH desarrollaron aún más esta solución de detección de revisión en dos pasos:

cliente ligero监控内存池，检测某些交易在 Bloquear中未被包含的时间是否过长。
Si una transacción específica permanece en la memoria pool durante un día sin ser incluida en un bloque, se activará el botón '¿Estás de acuerdo en realizar un fork social?' para permitir a la comunidad iniciar un fork duro basado en este consenso.

Suponiendo que esta herramienta detecte un ataque del 51%, el siguiente paso sería realizar un fork social y trasladarse a una nueva cadena on-chain, lo que invalidaría los fondos del atacante.

En este caso, los fondos afectados por un ataque del 51% deben permanecer bloqueados hasta que se complete el fork social. Durante el hard fork de The DAO, ocurrió una situación similar donde los fondos del Hacker quedaron bloqueados en un sub-DAO durante 27 días hasta que pudieron retirarlos. Durante este tiempo, la comunidad de Ethereum realizó con éxito un hard fork, impidiendo que el Hacker pueda hacer efectivo sus fondos (para más detalles, consulta el post de Vitalik en Reddit).

En otras palabras, incluso si ocurre un ataque del 51%, los fondos deben permanecer bloqueados hasta que se realice un fork social. En este caso, el período de retiro de 7 días en Optimistic Rollup actúa como un buffer. Si no se realiza un fork social durante esta semana, los fondos de los usuarios en Optimistic Rollup podrían ser robados, retirados a un intercambio centralizado o mezclados a través de Tornado Cash, lo que dificulta que los fondos regresen a los usuarios después de un fork social.

En resumen, aunque el período de retiro de 7 días en Optimistic Rollup fue originalmente diseñado para hacer frente a la escasa vigilancia, en realidad, la probabilidad de que ocurra una escasa vigilancia es baja, y este período de 7 días sirve como tiempo de amortiguación en caso de que sea necesaria una bifurcación social bajo una estricta vigilancia.

Desde esta perspectiva, algunos critican que OPFP haya acortado este plazo a 3.5 días, lo que lo hace más susceptible a ataques de auditoría exhaustiva. Sin embargo, esta crítica carece de fundamento. Dado que Optimism todavía está en la fase 1, los guardianes tienen suficiente tiempo de amortiguación para verificar la corrección de la raíz del estado, y los retiros solo pueden realizarse después de que finalice el período adicional de custodia de 3.5 días. Por lo tanto, incluso en caso de un ataque de auditoría exhaustiva, el atacante aún tendría que esperar 7 días para realizar un retiro. Además, el atacante también debe revisar todas las transacciones relacionadas con preguntas durante toda una semana para tener éxito, ya que los guardianes también deben ser revisados para evitar que interrumpan la confirmación de salidas maliciosas.

Sin embargo, la clave es que Ethereum debe asegurarse de que puede manejar el fork social en 7 días. Esto significa que las herramientas para detectar ataques del 51% deben estar listas y se requiere investigación y simulación exhaustivas para determinar si es posible implementar el fork social en 7 días. Solo en este caso, la latencia de retiro de 7 días en Optimistic Rollup se considera una garantía efectiva.

3.6 Vector de ataque #3: Aprovechando las vulnerabilidades en el sistema de prueba de fraude

La mayoría de las dudas sobre el protocolo se resuelven al hacer que los participantes encuentren un punto específico (instrucción o bloque) en el que sus opiniones difieren, y luego generen una prueba de que la afirmación del otro participante es incorrecta. La Máquina virtual utilizada para generar esta prueba de fraude se llama Máquina virtual de prueba de fraude, y el software utilizado en esta Máquina virtual para generar la prueba se llama programa. Cada protocolo utiliza una Máquina virtual de prueba de fraude y un programa diferentes, como se muestra a continuación:

Cada sistema de prueba de fraude está diseñado para demostrar que un resultado de ejecución específico en la Máquina virtual EVM es correcto en la cadena. Pero, ¿qué sucede si hay vulnerabilidades en ese sistema (ya sea en la Máquina virtual o en el programa)?

Este problema puede ser explorado a través del Vector de ataque descubierto por Yoav Weiss en OVM (https://medium.com/infinitism/optimistic-time-travel-6680567f1864). Debido a una vulnerabilidad en la función de Retroceso de OVM, los ataques son posibles, pero la creación de transacciones fraudulentas es crucial para su implementación. Las transacciones fraudulentas son aquellas que se ejecutan normalmente en Rollup, pero dan lugar a resultados diferentes cuando se cuestionan con la Máquina virtual y el programa de prueba de fraude. La capacidad de crear transacciones fraudulentas significa que hay una vulnerabilidad en el sistema de prueba de fraude, ya que se espera que genere los mismos resultados que EVM.

Yoav descubrió varias vulnerabilidades en el sistema de prueba de fraude de OVM y pudo simular este ataque generando transacciones fraudulentas. El ejemplo de ataque simple que encontró fue que en el StateManager de OVM, los costos de gas de las operaciones SSTORE y SLOAD (utilizadas para almacenar y leer el estado) se registraron incorrectamente. Esto significa que cualquier transacción que almacene o lea valores en contratos (casi todas las transacciones, excepto las transferencias sencillas de ETH) será marcada como una transacción fraudulenta durante el proceso de cuestionamiento, incluso si se ejecuta correctamente en Rollup.

En resumen, si hay vulnerabilidades en el sistema, los cambios de estado que se ejecutan correctamente pueden ser marcados incorrectamente como inválidos durante el período de cuestionamiento, lo que resulta en que las salidas presentadas por los participantes honestos sean marcadas como incorrectas.

Esta también es una de las razones por las cuales OP Mainnet recientemente cambió su sistema de prueba de fraude de un modo sin licencia a un modo en el que solo los participantes autorizados pueden unirse. Después de que OPFP se aplicara a Mainnet, una auditoría de seguridad reveló varias vulnerabilidades en el sistema de prueba de fraude (Cannon y op-program) y en el protocolo de desafío de juego en disputa. Para evitar que el sistema sea explotado, Optimism anunció el 17 de agosto que cambiará a un sistema de permisos.

Por supuesto, aprovechar las vulnerabilidades de la Máquina virtual puede no tener un gran impacto en los Rollup en la fase 0 o 1, ya que el comité de seguridad puede intervenir en cualquier momento para corregir los resultados cuestionados. Este es el punto de vista que OP Labs propuso anteriormente. De hecho, OP Labs compartió su marco de auditoría en el Foro de Optimism, describiendo los estándares para la realización de auditorías externas en ciertas situaciones.

(OP Labs Audit Framework | Fuente: Optimism Forum)

En este marco, la situación más reciente se encuadra en el cuadrante 4: "Prueba de fracaso en la fase secundaria". Si bien estas situaciones están relacionadas con la seguridad de la cadena, no afectan directamente a los fondos de los usuarios y, por lo tanto, no se incluyen en el alcance de la auditoría. Esto significa que incluso si se explota la vulnerabilidad, el comité de seguridad aún puede corregir los resultados.

Sin embargo, una vez que se han identificado las vulnerabilidades, es necesario resolver estos problemas. Optimism ha solucionado estos problemas en su actualización de red Granite, permitiendo que OP Mainnet se recupere en la Fase 1.

Por otro lado, las vulnerabilidades en el sistema pueden ser mortales en el Rollup de la fase 2. En la fase 2, el comité de seguridad solo puede intervenir en caso de vulnerabilidades que puedan ser probadas en la cadena. Dado que es casi imposible probar en la cadena que los resultados de las objeciones son incorrectos debido a vulnerabilidades en el sistema, si ocurre una vulnerabilidad en el Rollup de la fase 2, los fondos de los usuarios podrían estar en riesgo.

3.7 Solución #3: Prueba múltiple

Para prevenir este tipo de problemas, es crucial realizar una auditoría completa antes de implementar el código en producción. Sin embargo, las pruebas de fraude, la Máquina virtual y los programas son sistemas de software complejos, y cuanto más complejo es el sistema, mayor es la posibilidad de que surjan vulnerabilidades. Por lo tanto, incluso después de una auditoría rigurosa, es posible que surjan vulnerabilidades. Necesitamos explorar estrategias adicionales más allá de la auditoría.

Un método es utilizar múltiples sistemas de prueba en el mismo sistema. Durante el proceso de cuestionamiento, el sistema no solo utiliza un único sistema para generar una prueba de fraude, sino que puede utilizar simultáneamente diferentes máquinas virtuales y programas para generar múltiples pruebas de fraude, y luego comparar los resultados. Esto creará un sistema seguro incluso en caso de vulnerabilidad.

Por ejemplo, imagina un sistema de múltiples pruebas que utiliza simultáneamente el cañón de Optimism y ZK de asterisc pruebas de fallas en la Máquina virtual (usando Risc-V). En caso de duda, ocurrirán las siguientes situaciones:

Si se detecta una salida incorrecta, el que cuestiona genera una duda y lanza el método de eliminación binaria.
Una vez que se encuentra el Bloquear de divergencia a través del método de bifurcación, se producirán simultáneamente dos sub-juegos:

El subjuego de Cannon que utiliza el método tradicional OPFP. Generar subjuegos de prueba de fallos ZK usando Asterisc.

Después de completar los dos juegos, se verificará esta prueba de fraude diferente.

Si ambas pruebas son validadas, el cuestionador gana; si ambas pruebas no son validadas, el cuestionador fracasa. Sin embargo, si una es validada y la otra no, esto indica que ha habido un fallo inesperado en una Máquina virtual o programa durante el proceso de generación de pruebas.

En este caso, entidades como el Comité de Seguridad intervendrán para ajustar los resultados cuestionados. Esto garantiza que el sistema pueda permanecer sin vulnerabilidades, sin violar la condición de que el Comité de Seguridad solo puede intervenir en situaciones de vulnerabilidades demostrables en la cadena (on-chain).

Este es uno de los esfuerzos continuos para lograr la Fase 2 de Optimism. Para respaldar esto, el juego controvertido de OPFP implica la creación de sistemas modulares que permiten la implementación de múltiples sistemas de prueba de fraude y definen una interfaz mínima para respaldar esto.

4. Mejoras viables

En los capítulos anteriores, discutimos el diseño del protocolo Optimistic Rollup y las posibles vulnerabilidades en su proceso de verificación de cuestionamiento y prueba de fraude. En esta sección, discutiremos los problemas y soluciones de cada protocolo, así como el sistema de prueba de fraude y las perspectivas futuras de Optimistic Rollup.

4.1 Espacio para mejoras en cada protocolo

1) Arbitrum BoLD

BoLD tiene un sólido protocolo de economía, ya que limita la latencia del protocolo al máximo a una semana y garantiza una efectiva prevención de ataques Sybil antes de que los fondos del atacante superen 6.5 veces los del defensor. Sin embargo, BoLD tiene dos problemas significativos:

La proporción de recursos de 6.5 veces es demasiado pequeña para la ventaja del defensor.
El depósito para presentar una declaración raíz es de 3,600 ETH, lo cual es una cantidad demasiado grande.

El primer problema puede ser resuelto mediante la tecnología ZK. BoLD divide las objeciones en varios niveles para reducir los recursos necesarios para calcular los compromisos históricos. Con ZK, esto puede reducirse a un solo nivel.

Este concepto es similar a la propuesta BoLD++ de Gabriel de Cartesi. Cuanto más se dividen las dudas en diferentes niveles, el aumento de la proporción de recursos dará lugar a un aumento exponencial en el tamaño del depósito de nivel más alto. Sin embargo, cuando se utiliza un único nivel, es más fácil incrementar la proporción de recursos, lo que hace que el protocolo sea más resistente a los ataques Sybil.

El segundo problema, que requiere un depósito de 3.600 ETH, es aún más difícil de resolver. El tamaño del depósito de BoLD no solo es para hacer frente a los ataques de Sybil, sino también para disuadir los ataques de latencia. El tamaño del depósito es una función del TVL (valor total bloqueado) y no se puede reducir significativamente incluso con ZK. Para resolver este problema, BoLD está implementando un mecanismo de depósito de grupo que permite a varios participantes asumir conjuntamente el depósito.

2）Cartesi Dave

Dave ha abordado efectivamente los ataques de Sybil a través de su estructura de torneo, pero como se mencionó anteriormente, es susceptible a ataques de latencia. El tiempo máximo de latencia es una función que incluye la cantidad de declaraciones maliciosas NA y la cantidad de niveles de stake L, su fórmula de cálculo es: Td = 7 x [log2(1 + NA)]L(días)

Si NA = 7 y L = 3, el protocolo podría enfrentar una latencia de hasta cuatro meses, lo que causaría inconvenientes y pérdidas significativas a los usuarios, ya que los retiros estarán sujetos a latencia.

ZK puede ayudar a aliviar este problema. Al fijar el nivel L en 1 (como en la línea BoLD++), el tiempo máximo de latencia puede reducirse a: Td = 7 x log2(1 + NA)(天数)

Según informes, Cartesi está utilizando la tecnología ZK de RISC Zero para esta mejora. Sin embargo, persisten preocupaciones sobre si esta mejora es suficiente para prevenir por completo los ataques de latencia. Si NA = 7, el protocolo aún podría enfrentar una latencia adicional de hasta dos semanas, mientras que el costo para el atacante sería solo un depósito de 7 ETH, más gastos de gas y costos de compromisos históricos fuera de la cadena. Para cadenas con un valor de Posición de bloqueo más alto, esta sanción puede no ser suficiente para disuadir los ataques de latencia.

(Dave: Mecanismo de subcuestionamiento con estilo BoLD | Fuente: L2Beat Medium)

Hay una sugerencia para que Dave adopte un mecanismo de interrogación en estilo BoLD, con 8 participantes compitiendo en cada ronda en lugar de enfrentamientos individuales, similar a un torneo tradicional. En este caso, la fórmula de cálculo de la latencia es:

Td = 7 x log8(1 + NA)(天数)

En esta estructura, el atacante necesita proporcionar al menos 64 ETH de margen para cuestionar la latencia durante más de dos semanas, con un requisito total de margen de 64 ETH y una gran cantidad de costos en cadena y fuera de cadena.

Sin embargo, la desventaja de este método es que debilita la ventaja del defensor frente a un ataque Sybil. Aunque BoLD proporciona una estructura en la que el defensor tiene una ventaja N veces mayor que el atacante, Dave ha creado una ventaja exponencialmente mayor para el defensor sobre el atacante.

En resumen, Dave puede limitar efectivamente el vector de ataque de latencia al utilizar ZK prueba de fraude. Si bien las estructuras de aplicación similares a BoLD pueden mejorar la capacidad de resistir los ataques de latencia, esto puede llevar a una ventaja en la defensa contra los ataques de Sybil.

3）Optimismo Prueba de Fallos (OPFP)

Una desventaja de OPFP es que es susceptible a ataques de Sybil porque el costo para atacantes y defensores es igual. OP Labs propuso una solución a este problema en Dispute Game V2.

A diferencia de OPFP original, este último requiere que se presente Margen en cada bifurcación, mientras que el juego en disputa V2 solo requiere que los participantes presenten Margen al comienzo de la bifurcación. Además, el juego en disputa V2 introduce la bifurcación, lo que permite a los participantes presentar múltiples solicitudes al mismo tiempo en el punto de bifurcación, reduciendo así la cantidad de interacciones en la mayoría de los casos.

（Declaración de bifurcación en el juego controvertido V2 | Fuente: Optimism Specs GitHub）

En OPFP anterior, los vectores de ataque de Sybil incluyen:

Crear una gran cantidad de dudas para agotar los fondos de defensa de Margen y las tarifas de Gas de los defensores.
Continuamente presentando salidas falsas, obligando a los defensores a responder y agotar sus recursos.

La introducción de declaraciones de bifurcación resuelve ambos problemas de vectores. En primer lugar, los participantes honestos no necesitan depositar Margen adicional durante el proceso de bifurcación, mientras que los cuestionadores maliciosos deben depositar una garantía por cada nueva duda que creen. Si el monto de la garantía se establece adecuadamente, la creación masiva de dudas por parte de los atacantes se vuelve insostenible.

En segundo lugar, en el juego en disputa V2, la cantidad de Margen de nivel superior es mayor, por lo tanto, el costo de enviar constantemente salidas falsas es mayor para el atacante que para el defensor.

Por lo tanto, OPFP puede hacer frente eficazmente a los ataques de Sybil mediante la introducción de declaraciones de bifurcación en el juego en disputa V2.

4) Kroma ZK Fault Proof (Kroma ZKFP)

Kroma ZKFP se enfrenta a dos desafíos: la vulnerabilidad de los ataques Sybil y un sistema de prueba imperfecto. Para avanzar a la etapa 1, Kroma ZKFP debe resolver los siguientes dos problemas:

El punto de partida del método de bisección se basa en la salida de la última presentación, no en la salida final determinada.
Los validadores cuestionan si la validación no se basa en lotes de datos correctos.

Kroma tiene planes de cambiar de Halo2 zkEVM de Scroll a Succinct SP1 zkVM para resolver estos dos problemas y avanzar a la etapa 1.

Kroma tiene previsto modificar su proceso de disputa para que se alinee con la interfaz de juego controvertida de Optimism. Este ajuste se detalla en el estándar de Kroma y permitirá que el punto de inicio de la bifurcación se desplace a la última salida confirmada hace una semana, resolviendo así el primer problema.

Para el segundo problema, Kroma utilizará la deducción sin confianza basada en ZK. El funcionamiento concreto es el siguiente:

(Derivación completa sin confianza para el juego de disputa de conocimiento cero utilizando ZK | Fuente: Lightscale Notion)

Imagínese que queremos demostrar que un Bloquear T específico de L2 se ejecuta correctamente. Antes de generar la prueba de conocimiento cero (ZK), debemos verificar si los datos de transacción de Bloquear T se construyen correctamente sobre los datos agrupados de L1.

Aquí, Kroma tiene la intención de verificar mediante ZK si los datos en bloque se extrajeron correctamente de L1. Si los datos se obtienen solo a través de un RPC confiable externo al programa ZK, no se puede confirmar si los datos en bloque se han manipulado. Se puede verificar si el programa accede al bloque correcto y extrae los datos en bloque generando una prueba de conectividad ZK con hash de bloque. Estos bloques van desde el bloque O (fuente L1 del bloque T de L2) hasta el bloque C (bloque L1 en el que se plantea la objeción). Si el impugnador construye un bloque T de L2 incorrecto basado en datos en bloque incorrectos, el hash de bloque del bloque L1 al que se hace referencia en la extracción de datos en bloque será diferente del hash del bloque L1 que contiene los datos en bloque reales (incluido T1), y tampoco estará conectado al bloque C. Por lo tanto, siempre que no haya conflictos de hash, la verificación de la conectividad del bloque L1 a través de ZK puede demostrar que el impugnador ha construido el bloque L2 a partir de los datos en bloque correctos.

El plan de Kroma es usar ZK para verificar la precisión de los datos en bloque, lo que puede verificar la conectividad de hash en bloque desde L1 hasta C. Si un cuestionador construye un bloque L2 T basado en datos en bloque incorrectos, el hash de bloque L1 al que hacen referencia será diferente al bloque L1 que contiene los datos en bloque correctos y no se conectará al bloque C. Debido a la falta de conflictos de hash, este método se puede utilizar para verificar los datos en bloque correctos en el proceso de cuestionamiento.

Con estas mejoras, Kroma ZKFP podrá ingresar a la fase 1. Sin embargo, para alcanzar la fase 2, Kroma necesita soluciones adicionales para prevenir ataques Sybil, lo que incluye cambiar el protocolo cuestionado por All-vs-All y rediseñar el mecanismo de margen.

4.2. Resumen

5. El futuro de prueba de fraude

5.1. Fase 2 Rollup - Su fondo es seguro

Como se mencionó anteriormente, Optimistic Rollups está avanzando hacia la Fase 2. Arbitrum está trabajando arduamente en la implementación de la Fase 2 basada en BoLD. El plan de implementación de BoLD ha sido publicado en el Foro de Gobernanza y ha recibido un gran apoyo, actualmente se ha implementado en la red de prueba. Si no se encuentran problemas de seguridad importantes, es probable que Arbitrum implemente la Fase 2 con BoLD antes de finales de este año.

Optimism también está trabajando en la implementación de la Fase 2. Para que OP Mainnet alcance la Fase 2, se debe completar el Juego de Disputas V2 y se requiere el respaldo de múltiples mecanismos de prueba. Aunque los estándares aún están en desarrollo, el Juego de Disputas V2 resuelve de manera efectiva las debilidades del OPFP existente, proporcionando una sólida protección contra ataques Sybil y acercándose más a la Fase 2. Además, varios equipos, incluyendo OP Labs, Succinct, Kroma y Kakarot, están desarrollando activamente múltiples pruebas y dedicando muchos recursos de investigación y desarrollo para crear una diversidad de formas de prueba en el Stack de OP. Por lo tanto, a menos que surjan problemas importantes, se espera que Optimism avance hacia la Fase 2 en la primera mitad del próximo año.

La transición de estos dos Rollups a la Fase 2 podría tener un impacto significativo en el ecosistema de Rollup. Arbitrum y Optimism tienen sus propios marcos de Rollup, llamados Arbitrum Orbit y OP Stack, respectivamente. La transición a la Fase 2 significa que todos los Rollups que utilizan estos marcos también pueden migrar a la Fase 2.

Por lo tanto, desde finales de este año hasta el próximo, se espera que los principales Rollup con una gran base de usuarios, como Arbitrum, OP Mainnet y Base, hagan la transición a la Fase 2, heredando la seguridad completa de Ethereum. Esto probablemente calmará las críticas de que 'Rollup es simplemente una firma múltiple' o 'Rollup puede llevarse su dinero en cualquier momento'.

5.2. ZK prueba de fraude es el futuro

La mayoría de los protocolos discutidos pueden beneficiarse de la implementación de ZK prueba de fraude. Por ejemplo, aplicar ZK a Arbitrum BoLD puede mejorar la relación de recursos y hacerlo más resistente a ataques de Sybil, mientras que Cartesi Dave puede hacerlo menos susceptible a ataques de latencia. OPFP también está investigando la integración de ZK para respaldar sistemas de prueba múltiple, lo que podría reducir los montos de margen y mejorar la seguridad del protocolo.

Es importante tener en cuenta que ZK prueba de fraude no solo significa reducir la interacción entre los validadores. Menos interacción significa una significativa reducción de recursos requeridos por los validadores, lo que permite soltar el margen y permitir que más participantes se unan al protocolo. Además, esto también reduce la latencia máxima posible y mejora la seguridad general del protocolo.

De esta manera, ZK prueba de fraude desempeña un papel clave en la seguridad y la descentralización de Optimistic Rollup.

5.3. ¿Cómo se desempeña ZK Rollup? ¿prueba de fraude会变弱吗？

En este momento, algunos lectores pueden preguntar: Si la prueba de fraude y el mecanismo de cuestionamiento son tan complicados, ¿los ZK Rollups serían una mejor opción? Hasta cierto punto, esto es correcto. En rollups ZK, alcanzar la fase 2 no requiere considerar factores económicos complejos, los fondos de los usuarios no enfrentan riesgo de robo en el evento de revisión L1, y los usuarios pueden retirar fondos en cuestión de horas.

La transición de Optimistic Rollups a ZK Rollups podría ser más rápida de lo esperado. Esto se debe a que la principal desventaja de ZK Rollups, los altos costos y tiempos de generación de pruebas, está mejorando rápidamente. Recientemente, Succinct Labs presentó OP Succinct, una versión de ZK basada en OP Stack que proporciona un marco fácil para iniciar ZK Rollups.

OP Succinct 简介 | 来源：Succinct 博客

Sin embargo, todavía hay varios factores a considerar. En primer lugar, el costo. En OP Succinct, el costo de generar un certificado Bloquear es de aproximadamente $0.005-$0.01, mientras que se estima que el costo mensual de ejecución del verificador está entre $6,480 y $12,960. Si el volumen de transacciones por segundo (TPS) de la cadena es alto, estos costos podrían aumentar aún más.

（各网络证明成本Indicador de referencia | Fuente: Blog de Succinct）

Por ejemplo, en la red Base de OP Succinct, el costo promedio de generación de prueba por cada bloque es de aproximadamente $0.62. Según este número, los costos mensuales alcanzarán los $803,520. Estos son costos adicionales que Optimistic Rollups no tiene, incluso si los costos de Soltar ZK y los costos operativos de ZK Rollups son siempre más altos que los de Optimistic Rollups.

La segunda consideración es el impacto en la Descentralización. En ZK Rollups, los validadores necesitan ejecutar verificadores, lo que es más difícil y costoso que ejecutar programas de prueba de fraude en Optimistic Rollups. Además, debido a que la generación de pruebas en el sistema ZK es lenta, los usuarios no pueden verificar las transacciones en tiempo real. Aunque estándares de hardware más altos pueden acelerar la generación de pruebas para igualar la velocidad de ejecución de transacciones, esto significa que los verificadores necesitan un entorno informático de alto estándar. Idealmente, cualquiera debería poder ejecutar un Nodo para garantizar la seguridad de la cadena, pero ZK aún no ha alcanzado este nivel.

Finalmente, ZK Rollups, basado en matemáticas y criptografía altamente complejas, esta complejidad está más allá del alcance de la prueba de fraude y la duda del protocolo. Por lo tanto, antes de que se pueda utilizar de forma segura en producción, el sistema ZK necesita ser ampliamente probado.

Arbitrum está buscando un protocolo híbrido que combine los métodos ZK y Optimistic como su objetivo final. Este protocolo funciona principalmente como Optimistic Rollup, generando pruebas ZK solo cuando se necesita retirar fondos rápidamente. Esto es muy útil para escenarios que requieren reequilibrar rápidamente los fondos entre cadenas (como intercambio o puentes cross-chain), y también ayuda a lograr la interoperabilidad entre cadenas.

En resumen, actualmente el método Optimistic Rollup parece ser efectivo, al mismo tiempo que se implementa ZK como una solución híbrida. Sin embargo, a medida que continúan mejorando el costo y la velocidad de generación de pruebas ZK, es posible que en el futuro más Optimistic Rollups consideren seriamente cambiar a ZK.

5.4. ¿La prueba de fraude solo se aplica a Rollup?

Ya hemos estudiado los Optimistic Rollups de Ethereum y su mecanismo de prueba de fraude. ¿Qué otros escenarios de prueba de fraude existen?

再stakeprotocolo La prueba de fraude se puede utilizar de manera activa en el protocolo de stake. Tomemos Eigenlayer como ejemplo, este es un servicio de stake representativo en la red de Ether.

Eigenlayer es un servicio que permite asegurar la seguridad de ETH al volver a poner en juego los activos. En Eigenlayer, los operadores pueden depositar ETH o LST de los usuarios según los contratos de delegación en Eigenlayer y participar en la validación seleccionando varios Servicios de Validación Activa (AVS). Con Eigenlayer, los protocolos pueden construir fácilmente AVS y reducir los costos iniciales de guiar a los validadores.

Como cualquier otra cadena de bloques, AVS recompensará a los operadores que verifiquen con éxito y deberá castigarlos si actúan maliciosamente. Aquí es donde se puede usar la prueba de fraude en el proceso de slashing.

Ejemplo de slashing de AVS | Fuente: Eigenlayer GitHub

Tomando como ejemplo puente AVS. El requisito previo de puente AVS es que los fondos del usuario se transfieran correctamente a la cadena de destino, y cualquier operador que manipule maliciosamente la transacción debe ser objeto de slashing. Si ocurre esta manipulación, un cuestionador que descubre una conducta inapropiada puede crear una objeción con prueba de fraude en el contrato de resolución de controversias, alegando que el operador no actuó correctamente en la operación de puente. Si se considera que la prueba de fraude es válida, AVS puede invocar el contrato de slashing en Eigenlayer y suspender cualquier recompensa del operador.

A pesar de que la función de slashing aún no se ha implementado en Eigenlayer, recientemente anunciaron el modelo de seguridad compartido, con planes de incluir la función de slashing en la próxima versión. Esto permitirá que la prueba de fraude se utilice para slashing.

Capa de disponibilidad de datos** **prueba de fraude también se puede utilizar en la capa de disponibilidad de datos (DA). Un ejemplo representativo es la prueba de fraude propuesta e implementada por Celestia. Celestia tiene una tecnología que permite a los nodos ligeros verificar si los datos se almacenan correctamente mediante un muestreo de disponibilidad de datos. Vamos a examinar este concepto en detalle.

El cliente ligero debería poder verificar un bloque sin descargar todos los datos de la cadena de bloques y obtener la aprobación de la mayoría (más del 67%) de los validadores. Sin embargo, es difícil para el cliente ligero verificar todas las firmas de los validadores para cada bloque, y con el aumento del número de validadores, esto se vuelve casi imposible.

En este sentido, Celestia presenta un concepto interesante. En Celestia, incluso si la mayoría de los validadores son maliciosos, propone un método que permite a un solo Nodo completo honesto informar al cliente ligero para rechazar Bloquear defectuosos. Este único Nodo completo honesto puede garantizar su 'honestidad' a través de la prueba de fraude.

En Celestia hay dos tipos de prueba de fraude:

Estado de transición de prueba de fraude

Primero, el funcionamiento de prueba de fraude de los datos es el siguiente: Celestia permite a los nodos ligeros verificar si los validadores poseen los datos correctos sin descargar directamente todos los datos dentro de los bloques. Para lograr esto, Celestia utiliza una técnica llamada Muestreo de Disponibilidad de Datos (Data Availability Sampling, DAS).

Muestreo de disponibilidad de datos de Celestia | Fuente: Documento de Celestia

Los validadores de Celestia estructuran los datos de transacciones en una matriz k x k, luego los expanden a una matriz 2k x 2k utilizando la técnica llamada codificación 2D Reed-Solomon. Luego calculan un total de 4k raíces de Merkle para cada fila y columna, y los resultados de hash de estas raíces de Merkle se incluyen en el encabezado de bloque y se propagan.

Solo con la información de la Merkle Root en el Encabezado de bloque, un nodo ligero puede validar si los validadores de Celestia tienen los datos correctos. El nodo ligero solicita datos de puntos aleatorios en una matriz de 2k x 2k, y obtiene la Merkle Root correspondiente de los validadores para la fila y columna correspondiente. Si estos datos pueden ser validados con el valor en el Encabezado de bloque, entonces se puede confiar en que estos validadores tienen los datos correctos.

Sin embargo, ha surgido un factor importante a considerar: ¿qué pasa si los validadores ejecutan maliciosamente el código Reed-Solomon? Celestia aborda este problema mediante la implementación de un mecanismo llamado 'prueba de fraude de codificación incorrecta'. Si un Nodo completo de Celestia encuentra una codificación incorrecta durante el proceso de recuperación del bloque, generará una prueba de fraude que contiene la altura del bloque, la parte de codificación incorrecta y la prueba de falla, y la propagará al nodo ligero. El nodo ligero verifica esta prueba para confirmar que los datos están realmente codificados incorrectamente y deja de utilizar los datos incorrectos.

Además, Celestia también propone un mecanismo de prueba de fraude de transición de estado.

La arquitectura de Celestia Bloquear | Fuente: Contribution DAO 博客

La estructura de Bloquear de Celestia incluye datos de seguimiento de transacciones en varios intervalos de tiempo. Esto permite que el Nodo completo construya fácilmente prueba de fraude, y el nodo ligero pueda detectar transiciones de estado incorrectas sin ejecutar todo el Bloquear. Sin embargo, debido a problemas de complejidad, este mecanismo aún no se ha implementado en Celestia Mainnet.

En resumen, la prueba de fraude en la capa de disponibilidad de datos puede filtrar datos incorrectos y cambios de estado sin depender del consenso.

Aprendizaje automático La inteligencia artificial y la cadena de bloques se han convertido en temas populares en 2024, y se ha realizado una gran cantidad de investigación y desarrollo en este campo. Uno de los aspectos más destacados es la combinación de la cadena de bloques y el aprendizaje automático.

La razón principal de aplicar el aprendizaje automático a la cadena de bloques es la siguiente:

数据可靠性： La cadena de Bloquear gestiona los datos de forma Descentralización, y todas las transacciones se registran de manera abierta y transparente. Si un modelo de aprendizaje automático aprende de los datos de la cadena de Bloquear, la fuente de datos es confiable, lo que reduce la posibilidad de manipulación.
Transparencia y verificabilidad del modelo：Cuando el modelo de aprendizaje automático se ejecuta en la cadena de bloques, las actualizaciones y los resultados del modelo se registran en la cadena, lo que permite su verificación. Esto evita la manipulación o el sesgo de los resultados que podrían ocurrir en un entorno centralizado.

Los factores clave aquí son verificar si los modelos de aprendizaje automático están correctamente entrenados. Sin embargo, los cálculos de aprendizaje automático son altamente intensivos, lo que hace que sea casi imposible ejecutar completamente estos cálculos en el entorno de Bloquear. Por lo tanto, surgen marcos como opML y zkML para verificar eficazmente el entrenamiento de modelos de aprendizaje automático en el entorno de la cadena Bloquear. opML adopta un enfoque optimista para el entrenamiento de modelos, registra los resultados en la cadena Bloquear y corrige errores a través de un mecanismo de cuestionamiento.

Echemos un vistazo más detallado al método propuesto por ORA, un proyecto que proporciona infraestructura de inteligencia artificial en blockchain. El proceso de desafío de opML es muy similar al proceso de desafío de rollup y consta de tres componentes clave:

Máquina virtual de prueba de fraude (Fraud Proof VM): Esta máquina virtual realiza inferencias de aprendizaje automático y tiene funciones similares a WAVM de Arbitrum o Cannon de Optimism.
opML Contrato inteligente: Este contrato verifica prueba de fraude, similar a Optimism's MIPS.sol contrato.
Juego de validación: Los validadores que plantean preguntas interactúan con el servidor mediante el método binario para identificar errores individuales en la Máquina virtual y generar una prueba de fraude para ese paso, que luego se envía al contrato opML.

Juego de verificación en ORA opML | Fuente: Archivo ORA

A través de este mecanismo de prueba de fraude, opML utiliza la seguridad y confiabilidad de la cadena de bloques para proporcionar un entorno rentable para el entrenamiento y la verificación de modelos de aprendizaje automático.

6. conclusión

Optimistic Rollup está poniendo mucho esfuerzo en mejorar la prueba de fraude y cuestionar el protocolo para heredar más de la seguridad de Ethereum y crear una cadena con menos confianza. Se espera que Arbitrum llegue a la Fase 2 a través de BoLD a finales de este año, y Optimism también está trabajando hacia la Fase 2, confiando en el controvertido juego V2 y en mecanismos de prueba múltiple. Para el próximo año, los usuarios de Optimistic Rollup podrán interactuar con la red con mayor seguridad sin preocuparse de que "Rollup pueda tomar sus fondos". Además, Vitalik menciona en su blog que se espera que el número de rollups en la Fase 1 y superior también aumente.

Sin embargo, cada protocolo aún tiene espacio para mejoras, y muchos aspectos pueden ser fortalecidos mediante la prueba de fraude ZK. Kroma ha avanzado en su protocolo sobre esta base, y otros protocolos como Arbitrum, Optimism y Cartesi también pueden mantenerse de manera más segura y descentralizada utilizando la prueba de fraude ZK.

En el campo de la prueba de fraude, no solo Rollup, sino también otros protocolos, están invirtiendo una gran cantidad de recursos de investigación y desarrollo. En combinación con ZK, la prueba de fraude puede ayudar a construir una arquitectura de cadena de bloques de bloque mínimo de confianza bajo la premisa de "solo se requiere un participante honesto", cuyo impacto finalmente se convertirá en una realidad tangible para nosotros.

7. Referencias

(https://l2beat.com/scaling/summary)[L2Beat]

prueba de fraude战争 | Luca Donnoh en L2Beat

Archivo Optimism 文

BoLD: Resolución rápida y económica de controversias

BoLD Economics

¿Por qué el período de desafío de Optimistic Rollup es de 7 días? | Kelvin Fichter en OP Labs

prueba de fraude已崩溃 | Gabriel Coutinho de Paula at Cartesi

Viaje en el tiempo optimista | Yoav Weiss

Introducción sobre el primer desafío exitoso en Kroma Mainnet

解读基线 Descentralización的进展 | OP Labs

Ataque de censura no atribuible a protocolos de capa 2 basados en prueba de fraude

OP Labs 审计框架

无信任的推导 | Kroma

Introducción a OP Succinct: prueba de validez completa en la pila OP | Succinct

Descargo de responsabilidad:

Este artículo es una reproducción de [research.2077], todos los derechos de autor pertenecen al autor original [sm-stack y BTC Penguin]. Si tiene alguna objeción a esta reproducción, póngase en contacto con el equipo de Gate Learn, ellos la resolverán rápidamente.
Descargo de responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente los del autor y no constituyen ninguna recomendación de inversión.
El equipo de Gate Learn traduce los artículos a otros idiomas. A menos que se indique lo contrario, está prohibido copiar, distribuir o plagiar los artículos traducidos.

ETH-1.32%

ARB-0.8%

OP-1.2%

CTSI-0.57%

Ver originales

Recompensa
Me gusta
2
Compartir

Comentar

Sin comentarios

Tema
#BTC#
98k publicaciones
#GateioInto11#
63k publicaciones
#ETH#
57k publicaciones
4#ContentStar#
56k publicaciones
5#BOME#
53k publicaciones
6#SLERF#
46k publicaciones
7#PIGCOIN#
44k publicaciones
8#比特币#
43k publicaciones
9#NADA#
39k publicaciones
10#HotTopicDiscussion#
39k publicaciones