Saltar al contenido
Financial Context Wiki

Prueba de fallo (prueba de fraude)

Guía vinculada al despliegue sobre pruebas de fallo optimistas, afirmaciones impugnadas, bisección de trazas, verificación de un paso, relojes, fianzas, disponibilidad de datos, finalidad de retiros y verificación operativa.

Actualizado

Solo con fines educativos; no constituye asesoramiento ni recomendación de inversión. Las inversiones pueden ocasionar pérdidas.

Respuesta directa

Una prueba de fallo, también llamada prueba de fraude, es el proceso protocolario para impugnar una afirmación optimista sobre un cálculo o estado. El proponente no demuestra cada transición antes de que se acepte: un impugnador habilitado puede presentar una traza contradictoria dentro de los plazos definidos y el contrato de liquidación resuelve el desacuerdo mediante un verificador especificado. Muchos diseños interactivos reducen repetidamente una traza larga hasta una instrucción controvertida y ejecutan ese caso base on-chain.

El nombre no demuestra que el sistema desplegado sea abierto, esté operativo o sea seguro. Se requieren los datos exactos de derivación, al menos un impugnador correcto que reconstruya la afirmación y actúe a tiempo, acceso y gas suficientes en la cadena de liquidación, programas y contratos correctos, y una gobernanza que no pueda eludir el resultado. Que una afirmación sobreviva a su juego puede autorizar un retiro conforme a ese despliegue; no prueba retroactivamente cada transacción L2, declaración del frontend o resultado económico.

1
Secuenciar

El secuenciador ordena transacciones L2 y publica datos o compromisos.

Cómo funciona

  1. Fijar el despliegue: identificadores L1 y L2, versiones del rollup y del sistema de pruebas, hashes de bloque, fábrica, portal o bridge, programa de prueba, VM, tipo de juego, implementaciones y administradores, permisos, fianzas, profundidad máxima, relojes, demoras, pausa y política de finalidad. La etiqueta fraud proof no es una especificación común a todos los rollups.
  2. Reconstruir la afirmación desde entradas autenticadas. Registrar estado ancla, cabecera L1, bloque L2 o raíz de salida disputados, datos del lote y blobs, configuración, preestado, raíz de retiros y reglas exactas de derivación. Una raíz de estado no basta y la falta de datos puede inutilizar una vía de impugnación abierta.
  3. Verificar que el juego fue creado y puede afectar al objeto previsto. Comprobar afirmación raíz, proponente, bloque y hora de creación, tipo, estado respetado o bloqueado, fianza, elegibilidad y regla real del portal. Separar afirmación pendiente, resultado del juego y salida apta para retiros.
  4. Reejecutar con nodo e implementación independientes. Comparar la traza correcta con cada afirmación y conservar preimágenes, testigos y versiones. En un juego interactivo, atacar o defender el intervalo correcto hasta aislar una instrucción y presentar el testigo base al verificador VM on-chain.
  5. Seguir el reloj de cada equipo y cada transacción. Registrar tiempo restante, extensiones, inclusión y reorganización L1, calldata, gas, reemplazos, fianzas, afirmaciones paralelas y responsable de responder. La duración real no siempre es una sola cuenta atrás; incluso una posición correcta puede perder por demora o censura.
  6. Vincular la resolución con sus consecuencias. Determinar qué afirmaciones quedan refutadas, qué equipo gana, cómo se distribuyen fianzas y costes, si se excluye una salida inválida y qué salidas, pruebas o retiros deben reconstruirse. Una fianza confiscada incentiva, pero no indemniza toda pérdida de bridge.
  7. Conciliar por separado finalidad y retiros. Verificar resolución, demoras de maduración y posteriores, tipo de juego respetado, listas de bloqueo y pausas, prueba de inclusión del retiro, recibo de finalización y finalidad L1. Archivar datos y ensayar impugnación, inclusión forzada, nueva prueba y salida de emergencia.

Ejemplos desarrollados

  • Bisección de traza. Una traza didáctica contiene 1,048,576 = 2^20 instructions. Si cada ronda sin oposición divide el intervalo por dos, 20 bisections aíslan una instrucción porque 2^20 / 2^20 = 1. Los juegos reales pueden dividir trazas distintas, ramificarse en un DAG o exigir movimientos adicionales; no es un número universal de rondas.
  • Relojes independientes. Un juego hipotético concede 84 hours a cada equipo. El defensor consume 30 hours y el impugnador 22 hours, por lo que quedan 54 hours y 62 hours. El tiempo transcurrido no es simplemente 84 hours: solo avanza el reloj aplicable y las extensiones, demoras de inclusión y afirmaciones paralelas alteran el límite.
  • Registro de fianza y gas. Bajo una regla expresamente hipotética, una raíz inválida lleva una fianza de 2 ETH. El ganador depositó 0.5 ETH, recupera ese principal y recibe 1.4 ETH, tras gastar 0.08 ETH en gas L1; 0.6 ETH va a tesorería. Su ganancia neta es 1.4 - 0.08 = 1.32 ETH; los 0.5 ETH devueltos no son beneficio y 1.4 + 0.6 = 2 ETH. Destinatarios y tratamiento de oportunistas dependen del contrato.
  • Relojes de retiro. El retiro se prueba el 2026-08-01 12:00 UTC, la maduración es 7 days, el juego resuelve el 2026-08-06 18:00 UTC y la espera posterior es 1 day. Las puertas terminan el 2026-08-08 12:00 UTC y el 2026-08-07 18:00 UTC; la primera hora que cumple ambas es 2026-08-08 12:00 UTC. Con 20 minutes adicionales de finalidad L1, la conclusión económica es 2026-08-08 12:20 UTC, si no hay pausa, bloqueo, nueva prueba o reorganización.

Riesgos

  • Auditar una L1, L2, despliegue, tipo de juego o versión incorrectos.
  • Reconstruir desde un ancla o cabecera obsoleta, no canónica o errónea.
  • Carecer de lotes, blobs, preimágenes, testigos o configuración.
  • Suponer que un compromiso o una entrada disponible implica todos los datos de derivación.
  • Obtener otra traza correcta por un fallo del cliente del impugnador.
  • Fallos del programa, VM, oráculo de preimágenes o verificador de un paso.
  • Proponente, impugnador o creación permissionados, inactivos o capturados.
  • Ausencia de un observador honesto antes del plazo.
  • Censura, congestión, reorganización o gas L1 que impidan actuar a tiempo.
  • Interpretar mal relojes, extensiones, profundidad o inclusión.
  • Atacar o defender afirmación, intervalo, posición o instrucción equivocados.
  • Fianzas o capital circulante que hagan impracticable participar.
  • Distribución, oportunistas o incentivos incompatibles con la seguridad asumida.
  • Juegos múltiples, afirmaciones duplicadas o implementaciones conflictivas.
  • Gobernanza que cambie tipo respetado, verificador, umbral o demora.
  • Pausa o bloqueo del Guardian que impidan retiros válidos.
  • Confundir resolución del juego con finalidad inmediata del retiro.
  • Probar contra un juego invalidado y no volver a probar.
  • Suponer que excluir una salida repara todos los efectos posteriores.
  • Extrapolar el modelo de un rollup optimista a otro.

Errores comunes

  • Una afirmación optimista no impugnada ha quedado probada criptográficamente.
  • Cualquiera puede impugnar todo despliegue sin permisos, capital ni infraestructura.
  • La prueba funciona aunque no estén disponibles los datos de derivación.
  • Ganar finaliza al instante todo retiro dependiente y reembolsa todas las pérdidas.
  • Siete días, un juego binario y un observador honesto son constantes universales.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...