---
title: "Prueba de fallo (prueba de fraude)"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Prueba de fallo (prueba de fraude)
> 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.
## 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
- [Disponibilidad de datos](/es/crypto/data-availability/)
- [Rollup optimista](/es/crypto/optimistic-rollup/)
- [Prueba de validez](/es/crypto/validity-proof/)
## Fuentes
- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org (consultado: 2026-08-12)
- [Fault Proof](https://specs.optimism.io/fault-proof/index.html) - OP Stack Specification (consultado: 2026-08-12)
- [Fault Dispute Game](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html) - OP Stack Specification (consultado: 2026-08-12)
- [Honest Challenger (Fault Dispute Game)](https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html) - OP Stack Specification (consultado: 2026-08-12)
- [Bridge Integration](https://specs.optimism.io/fault-proof/stage-one/bridge-integration.html) - OP Stack Specification (consultado: 2026-08-12)
- [Optimism Portal](https://specs.optimism.io/fault-proof/stage-one/optimism-portal.html) - OP Stack Specification (consultado: 2026-08-12)
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (consultado: 2026-08-12)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (consultado: 2026-08-12)
Source: https://wiki.fcontext.com/es/crypto/fraud-proof/index.mdx