Prueba de fraude

¿Qué es una prueba de fraude?

Una prueba de fraude es un mecanismo de blockchain que demuestra que una transición de estado propuesta, el resultado de una transacción, una retirada u otro cálculo off-chain es incorrecto.

Las pruebas de fraude se asocian principalmente a los optimistic rollups, que procesan transacciones de criptomonedas fuera de una blockchain base y publican en ella datos comprimidos y compromisos de estado.

Un sistema optimista acepta temporalmente un resultado enviado en lugar de exigir una prueba criptográfica de validez para cada lote de transacciones.

Durante un periodo de impugnación establecido, un participante independiente puede disputar un resultado incorrecto presentando pruebas de que no se siguieron las reglas del sistema.

Si la impugnación prospera, se rechaza la declaración no válida, el estado correcto sigue siendo el válido y el participante deshonesto o equivocado puede perder una garantía económica.

La documentación de Ethereum sobre optimistic rollups explica que estos sistemas dan por válidas las transacciones off-chain, salvo que alguien las impugne mediante un proceso de prueba de fraude.

Una prueba de fraude no demuestra necesariamente que una persona tuviera intención de cometer fraude, ya que un resultado no válido también puede deberse a un error de software, un fallo de configuración, un problema de hardware o un error de cálculo accidental.

Por este motivo, muchos desarrolladores de blockchain modernos utilizan el término más amplio «prueba de fallos» en lugar de «prueba de fraude».

¿Por qué son importantes las pruebas de fraude en el sector cripto?

Las pruebas de fraude permiten que los sistemas blockchain trasladen cálculos costosos fuera de la capa base sin exigir a los usuarios que confíen plenamente en un único operador centralizado.

La blockchain base no necesita ejecutar cada transacción del rollup a medida que se produce.

Solo necesita almacenar información suficiente para reconstruir el estado del rollup y resolver disputas cuando alguien afirme que se ha enviado un resultado no válido.

Este diseño optimista puede reducir los costes de transacción, ya que la verificación on-chain costosa solo es necesaria principalmente cuando los participantes discrepan.

Las pruebas de fraude también respaldan la autocustodia al ofrecer a los usuarios una vía para impugnar retiradas o declaraciones de estado no válidas sin depender únicamente de la organización que gestiona el rollup.

El mecanismo convierte la blockchain base en un árbitro neutral que verifica las pruebas conforme a las reglas de los contratos inteligentes.

Un sistema bien diseñado puede seguir siendo seguro siempre que al menos un participante honesto y capacitado supervise la cadena y pueda presentar una impugnación a tiempo.

Este modelo de seguridad suele resumirse como el supuesto de una parte honesta.

¿Cómo funciona una prueba de fraude?

Un secuenciador de rollup recopila las transacciones de los usuarios, las ordena, las ejecuta y crea una nueva versión del estado del rollup.

A continuación, el rollup publica datos de transacciones o compromisos de datos, junto con una declaración sobre el estado resultante, en su blockchain de liquidación.

Según el protocolo, esta declaración puede denominarse aserción, raíz de salida, raíz de estado, compromiso de estado o punto de control.

El contrato de liquidación no da por sentado de inmediato que la declaración sea definitiva.

En su lugar, inicia un periodo de impugnación durante el cual validadores o impugnadores pueden reproducir los cálculos de forma independiente.

Un impugnador honesto compara el resultado propuesto con el obtenido al ejecutar las transacciones publicadas conforme a las reglas oficiales del rollup.

Si ambos resultados coinciden, no se necesita una prueba de fraude y la declaración puede convertirse en definitiva cuando termine el periodo de impugnación.

Si los resultados difieren, el impugnador inicia una disputa mediante el contrato de liquidación.

El proceso de disputa delimita la discrepancia hasta que la blockchain de liquidación puede verificar el cálculo exacto que causó los resultados enfrentados.

Entonces, el contrato determina qué declaración sigue las reglas del protocolo y rechaza la otra.

Ejemplo sencillo de una prueba de fraude

Supongamos que, al inicio, Alice tiene 10 tokens y Bob tiene 2 tokens en un rollup.

Una transacción válida transfiere 3 tokens de Alice a Bob.

El estado resultante correcto deja a Alice con 7 tokens y a Bob con 5.

Supongamos que el operador del rollup envía por error un compromiso de estado que indica que Alice tiene 6 tokens y Bob tiene 6.

Un validador independiente vuelve a ejecutar la transacción y calcula los saldos correctos.

El validador impugna el compromiso de estado del operador porque el resultado enviado no se deriva del estado anterior y de la transacción válida.

La prueba de fraude identifica el paso de ejecución controvertido y proporciona la información necesaria para que el contrato de liquidación verifique las reglas de transferencia.

El contrato confirma que solo deberían haberse transferido 3 tokens y rechaza el compromiso de estado incorrecto.

El ejemplo es simplificado, pero los sistemas reales de pruebas de fraude aplican el mismo principio a la ejecución compleja de contratos inteligentes, el cálculo de gas, las actualizaciones de almacenamiento y los compromisos criptográficos.

¿Qué es un optimistic rollup?

Un optimistic rollup es un sistema de escalabilidad de capa 2 que ejecuta transacciones de criptomonedas fuera de una blockchain base y utiliza esa blockchain para la disponibilidad de datos, la liquidación y la resolución de disputas.

El término «optimista» significa que los lotes de transacciones se consideran válidos por defecto, en lugar de ir acompañados inmediatamente de una prueba de que todos los cálculos son correctos.

Los usuarios suelen recibir una confirmación rápida dentro del rollup, ya que el secuenciador comunica los resultados poco después de procesar las transacciones.

Sin embargo, el retorno del rollup a la capa de liquidación puede requerir más tiempo porque la declaración de estado correspondiente debe superar el periodo de impugnación.

Los optimistic rollups se diferencian de las sidechains ordinarias porque su seguridad está diseñada para depender en gran medida de la blockchain de liquidación y no únicamente de un grupo de validadores independiente.

La documentación de escalabilidad de Ethereum distingue los optimistic rollups, que ejecutan los cálculos impugnados mediante pruebas de fraude, de los zero-knowledge rollups, que envían pruebas de validez.

¿Qué es una raíz de estado?

Una raíz de estado es un compromiso criptográfico compacto que representa el estado completo de una blockchain o un rollup en un momento determinado.

El estado puede incluir saldos de cuentas, código de contratos inteligentes, valores de almacenamiento, nonces y otra información necesaria para procesar transacciones futuras.

Una raíz de estado es mucho más pequeña que la base de datos subyacente completa.

Modificar incluso un único valor pertinente suele cambiar el compromiso resultante.

Un proponente de rollup puede publicar una raíz de estado sin incluir todo el estado directamente en el contrato de liquidación.

Otros participantes pueden reconstruir el estado a partir de los datos de transacciones disponibles y comprobar si obtienen la misma raíz.

Una disputa sobre una prueba de fraude suele comenzar porque dos partes obtienen raíces distintas a partir de un mismo estado inicial y una misma secuencia de transacciones.

¿Qué es una transición de estado?

Una transición de estado es el proceso de convertir un estado antiguo de una blockchain en uno nuevo mediante la ejecución de una o varias transacciones válidas.

Una fórmula simplificada es

.

La función de transición de estado contiene las reglas del protocolo que rigen las firmas, los saldos, el gas, la ejecución de contratos, el almacenamiento y el orden de las transacciones.

Todos los participantes honestos que utilicen las mismas entradas y la misma versión del protocolo deberían calcular el mismo resultado.

Una prueba de fraude demuestra que un estado nuevo propuesto no se deriva correctamente del estado anterior y de las entradas publicadas.

La ejecución determinista es esencial, ya que una disputa no puede resolverse de forma fiable si se permite que ordenadores honestos obtengan respuestas diferentes a partir de las mismas entradas.

¿Qué es un periodo de impugnación?

El periodo de impugnación es el tiempo durante el cual se puede disputar un resultado optimista antes de que sea definitivo a efectos de liquidación.

Muchos diseños de optimistic rollups utilizan un periodo cercano a una semana, aunque la duración exacta depende del protocolo y puede cambiar mediante gobernanza o actualizaciones.

El plazo permite a los validadores independientes descargar los datos, reproducir la ejecución, detectar declaraciones no válidas, conseguir fondos para las comisiones de transacción o las garantías y presentar una impugnación.

Un plazo demasiado breve puede hacer que la seguridad dependa en gran medida de la supervisión constante, una infraestructura rápida y el acceso ininterrumpido a la blockchain de liquidación.

Un plazo demasiado largo puede reducir la eficiencia del capital y hacer que las retiradas habituales resulten incómodas.

La guía de Ethereum sobre disponibilidad de datos explica que los optimistic rollups suelen ofrecer un periodo de disputa para que verificadores independientes puedan comprobar los datos publicados e impugnar transiciones de estado incorrectas.

Los usuarios deben consultar las reglas concretas de impugnación y finalización de cada red, en lugar de suponer que todos los optimistic rollups utilizan exactamente siete días.

¿Por qué tardan las retiradas?

Una retirada estándar de un optimistic rollup puede demorarse porque el contrato de liquidación debe evitar liberar activos basándose en una declaración de estado no válida.

Si una declaración falsa pudiera finalizar de inmediato, un atacante podría inventar un saldo y retirar los activos bloqueados en la capa de liquidación antes de que nadie pudiera responder.

El periodo de impugnación da tiempo a los validadores para demostrar que la retirada depende de un estado no válido del rollup.

Cuando el compromiso de estado correspondiente se convierte en definitivo, la retirada puede completarse conforme a las reglas del bridge del protocolo.

Los usuarios pueden acceder a sus fondos más rápidamente mediante acuerdos de liquidez con terceros, pero estos introducen comisiones independientes, requisitos de liquidez, riesgos de contratos inteligentes y supuestos de contraparte.

La guía de Ethereum sobre zero-knowledge rollups explica que las retiradas de los optimistic rollups se retrasan para permitir impugnaciones mediante pruebas de fraude, mientras que los sistemas con pruebas de validez pueden finalizar las salidas tras verificar la prueba.

¿Qué es una prueba de fraude interactiva?

Una prueba de fraude interactiva utiliza un juego de disputa de varias fases entre partes que discrepan sobre un cálculo largo.

Publicar y volver a ejecutar un bloque entero del rollup directamente en la blockchain de liquidación podría resultar demasiado costoso o superar los límites de las transacciones.

En su lugar, el proponente y el impugnador se comprometen con trazas de ejecución diferentes y delimitan repetidamente el tramo en disputa.

Un método habitual divide la traza en secciones más pequeñas mediante un proceso denominado bisección.

Cada ronda identifica qué mitad contiene la primera discrepancia.

El proceso continúa hasta que la disputa se reduce a una instrucción de máquina u otra operación pequeña que el contrato de liquidación pueda verificar directamente.

La blockchain de liquidación no necesita reproducir todos los pasos, ya que solo comprueba los compromisos, los movimientos de la disputa y la instrucción final controvertida.

La documentación oficial sobre un diseño interactivo de disputa vigente explica cómo puede acotarse una disputa hasta obtener una prueba de un solo paso que verifique la blockchain principal.

¿Qué es una prueba de un solo paso?

Una prueba de un solo paso proporciona información suficiente para que un contrato de liquidación verifique una instrucción controvertida de la traza de ejecución de un rollup.

La prueba identifica el estado de la máquina anterior a la instrucción, la propia instrucción, los datos de entrada necesarios y el estado resultante declarado.

El contrato de liquidación aplica las reglas de la instrucción y calcula el siguiente estado correcto.

Si el resultado coincide con la declaración del impugnador y no con la del proponente, el impugnador gana la disputa.

La verificación de un solo paso permite hacer cumplir cálculos off-chain extensos sin que la blockchain de liquidación tenga que ejecutar habitualmente todo el programa del rollup.

La máquina virtual utilizada para ejecutar la prueba debe ser determinista y representar fielmente las reglas de consenso del rollup.

¿Qué es una prueba de fraude no interactiva?

Una prueba de fraude no interactiva intenta aportar en un único envío o en un proceso de verificación limitado todas las pruebas necesarias para demostrar que una transición no es válida.

Este diseño puede reducir la necesidad de respuestas repetidas entre el proponente y el impugnador.

Puede exigir que la prueba contenga más datos o utilice un método especializado para aislar el cálculo incorrecto.

Los sistemas interactivos pueden reducir el trabajo on-chain al delimitar las disputas en varias rondas, mientras que los sistemas no interactivos pueden acelerar su resolución y reducir la dependencia de la disponibilidad de respuesta durante la disputa.

El diseño más adecuado depende de la complejidad de la ejecución, los costes de la capa de liquidación, el tamaño de la prueba, la seguridad de la implementación y los tipos de fallos que debe gestionar el protocolo.

Prueba de fraude frente a prueba de fallos

Los términos «prueba de fraude» y «prueba de fallos» suelen utilizarse para describir el mismo mecanismo general de disputa optimista.

Históricamente, «prueba de fraude» era el término habitual porque describe las pruebas utilizadas para impugnar un comportamiento deshonesto.

«Prueba de fallos» es más preciso porque el mecanismo comprueba si un resultado es incorrecto, no cuál era la intención del operador.

Un resultado defectuoso puede deberse a una manipulación maliciosa, software obsoleto, una configuración incorrecta, una base de datos dañada o un error de programación corriente.

La documentación actual de los protocolos utiliza cada vez más el término «prueba de fallos» para describir sistemas de disputa en producción.

La documentación oficial del sistema de pruebas de fallos describe una arquitectura modular que incluye un programa de pruebas de fallos, una máquina virtual para dichas pruebas y un protocolo de juegos de disputa.

Prueba de fraude frente a prueba de validez

Una prueba de fraude demuestra que un resultado enviado es incorrecto después de que alguien lo impugne.

Una prueba de validez demuestra que una transición de estado enviada es correcta antes de que el contrato de liquidación la acepte.

Por lo general, los optimistic rollups publican declaraciones de estado sin pruebas de validez y dependen de un plazo de impugnación.

Los rollups de validez generan pruebas criptográficas, a menudo con tecnología de pruebas de conocimiento cero, para lotes de cálculos off-chain.

Un verificador de pruebas de validez puede rechazar de inmediato un lote incorrecto porque un atacante no debería poder crear una prueba válida de una transición no válida.

Durante el funcionamiento normal, un sistema de pruebas de fraude puede exigir menos recursos de cálculo porque no se necesita calcular una disputa si todas las declaraciones son correctas.

Un sistema de pruebas de validez puede ofrecer una liquidación más rápida una vez generada la prueba, pero quizá necesite una infraestructura compleja para generarlas y criptografía especializada.

Ninguno de los dos diseños es necesariamente superior, ya que la seguridad también depende de la disponibilidad de datos, la calidad de la implementación, las facultades de gobernanza, los controles de actualización y la capa de liquidación.

Prueba de fraude frente a prueba de conocimiento cero

Una prueba de conocimiento cero permite a una parte demostrar que una afirmación es cierta sin revelar todos los datos privados utilizados para demostrarlo.

Muchos sistemas de validez blockchain utilizan pruebas sucintas de conocimiento cero, aunque los datos de las transacciones sigan siendo públicos para reconstruir el estado.

Una prueba de fraude suele ser reactiva, ya que se crea después de proponerse un resultado incorrecto.

Una prueba de validez de conocimiento cero suele ser proactiva, ya que acompaña a la aceptación del nuevo estado o la precede.

Las pruebas de fraude dependen de que una parte honesta tenga la oportunidad de detectar e impugnar un fallo.

Las pruebas de validez dependen de la solidez criptográfica y de que el verificador esté bien implementado.

Las arquitecturas futuras de rollups podrían combinar pruebas de fallos, pruebas de validez, atestaciones y varias implementaciones independientes para reducir la dependencia de un único sistema.

Prueba de fraude frente a prueba de Merkle

Una prueba de Merkle demuestra que un elemento concreto pertenece a un conjunto de datos representado por una raíz de Merkle.

Por ejemplo, puede demostrar que un saldo de cuenta, una transacción o un mensaje de retirada está incluido en un árbol comprometido.

Una prueba de fraude demuestra que un cálculo o una transición de estado declarados son inválidos.

Las pruebas de fraude suelen contener pruebas de Merkle para que el contrato de liquidación pueda acceder únicamente a las pequeñas partes del estado necesarias para verificar el paso controvertido.

Una prueba de Merkle puede demostrar la inclusión sin demostrar que la transacción incluida se ejecutó correctamente.

Por tanto, ambos tipos de prueba tienen finalidades distintas, aunque a menudo se utilizan conjuntamente.

El papel de la disponibilidad de datos

Las pruebas de fraude no pueden proteger un rollup si los impugnadores carecen de los datos necesarios para reconstruir su estado e identificar una ejecución incorrecta.

De lo contrario, un operador malicioso podría publicar un compromiso de estado y ocultar las transacciones que lo sustentan.

Los validadores independientes sabrían que no pueden reproducir el resultado, pero quizá no podrían crear la prueba necesaria de un fallo concreto.

Los optimistic rollups abordan este problema publicando datos de transacciones comprimidos o compromisos de datos reconocidos por el protocolo a través de la capa de liquidación.

Los rollups de Ethereum pueden publicar datos mediante datos de llamada (calldata) de transacciones ordinarias o mediante transacciones con blobs diseñadas para datos de rollups.

La especificación EIP-4844 introdujo transacciones que incluyen blobs, lo que permite a los rollups publicar datos temporales a menor coste que mediante datos de ejecución permanentes en calldata.

Como el protocolo conserva los datos de los blobs durante un periodo limitado, los sistemas de supervisión deben recuperar y preservar la información necesaria durante el plazo de impugnación.

Por tanto, la disponibilidad de datos es un elemento esencial de la seguridad de las pruebas de fraude, no una función opcional independiente.

El papel de la blockchain de liquidación

La blockchain de liquidación almacena los compromisos del rollup, recibe las transacciones de disputa, gestiona las garantías de los participantes y ejecuta la lógica de verificación final.

Actúa como árbitro neutral porque sus reglas de consenso determinan qué movimientos y pruebas de disputa son válidos.

El rollup hereda parte de su seguridad de la finalidad, la resistencia a la censura, la ejecución de contratos inteligentes y la disponibilidad de datos de la capa de liquidación.

Si la blockchain de liquidación deja de finalizar bloques, las declaraciones y retiradas del rollup también pueden dejar de avanzar.

Si los atacantes pueden censurar todas las impugnaciones honestas durante todo el plazo de disputa, puede resultar difícil detener una declaración no válida.

Por tanto, la seguridad de las pruebas de fraude depende tanto del código del rollup como de que la blockchain de liquidación siga disponible y resista una censura prolongada.

El papel del secuenciador

Un secuenciador recibe las transacciones de los usuarios, decide su orden, ejecuta bloques del rollup y publica lotes de transacciones o compromisos.

Un secuenciador centralizado puede ofrecer confirmaciones rápidas, pero también retrasar, reordenar o censurar transacciones.

Las pruebas de fraude protegen frente a una ejecución no válida, pero no impiden automáticamente todas las formas de censura de transacciones u ordenación perjudicial.

Un secuenciador puede publicar un estado válido conforme a las reglas del protocolo y, aun así, excluir temporalmente la transacción de un usuario.

Los sistemas de rollup pueden ofrecer mecanismos de inclusión forzosa que permiten enviar transacciones a través de la capa de liquidación cuando el secuenciador las rechaza.

Los usuarios deben distinguir entre la corrección de la ejecución, que es lo que abordan las pruebas de fraude, y la equidad en la ordenación y la disponibilidad operativa, que requieren mecanismos adicionales.

El papel del impugnador

Un impugnador es un participante o servicio automatizado que supervisa los estados propuestos de un rollup e impugna las declaraciones no válidas.

El impugnador ejecuta software de nodo compatible y reproduce la ejecución del rollup a partir de los datos de la capa de liquidación.

Debe permanecer conectado, mantenerse al día con las actualizaciones del protocolo, conservar la información histórica necesaria y enviar transacciones antes de los plazos pertinentes.

El impugnador puede necesitar criptomonedas para pagar el gas de la capa de liquidación y las garantías económicas.

El software actual de impugnación puede supervisar disputas, defender propuestas válidas, impugnar propuestas no válidas y reclamar garantías tras ganar.

La documentación oficial del impugnador describe un servicio de producción que depende de un nodo de rollup sincronizado y un proveedor de trazas deterministas.

La participación sin permisos es más significativa cuando partes técnicamente independientes pueden ejecutar impugnadores sin la aprobación de una organización central.

¿Por qué se utilizan garantías?

Una garantía es una cantidad de criptomonedas que un participante bloquea al proponer una declaración o realizar determinados movimientos en una disputa.

Las garantías disuaden a los atacantes de presentar declaraciones falsas ilimitadas o de obligar a los validadores honestos a gastar recursos sin consecuencias económicas.

Un participante que respalde una declaración incorrecta puede perder parte o la totalidad de la garantía asociada.

Según el protocolo, un impugnador que gane puede recuperar su garantía y recibir una recompensa económica.

Las garantías deben ser lo bastante elevadas para disuadir los abusos, pero no tanto como para que solo las organizaciones con grandes recursos puedan participar.

Unas garantías excesivamente elevadas pueden hacer que un sistema de pruebas de fraude, en teoría abierto a todos, sea inaccesible en la práctica.

Unas garantías demasiado bajas pueden incentivar el spam, el sabotaje y los ataques de retraso.

El diseño de las garantías debe tener en cuenta las comisiones de la capa de liquidación, la volatilidad de los activos, la duración de las disputas, el coste de oportunidad del capital y el valor en riesgo.

Pruebas de fraude con permisos y sin permisos

Un sistema de pruebas de fraude sin permisos permite a cualquier participante que cumpla los requisitos técnicos y económicos públicos presentar o impugnar una declaración de estado.

Un sistema con permisos limita la presentación de propuestas, las impugnaciones o ambas acciones a direcciones u organizaciones aprobadas.

La validación con permisos puede reducir el spam y la incertidumbre operativa durante las primeras fases de desarrollo.

También introduce supuestos de confianza, ya que los usuarios dependen de que los validadores aprobados sean honestos, estén disponibles y sean independientes.

Los sistemas sin permisos mejoran la apertura, pero necesitan fuertes defensas contra el sabotaje, los ataques de retraso, la manipulación de garantías y la explotación de vulnerabilidades de software.

Una red puede utilizar juegos de disputa sin permisos y, al mismo tiempo, conservar un consejo de emergencia o una autoridad de actualización capaz de pausar o sustituir partes del sistema.

Los usuarios deben examinar el modelo de seguridad completo en lugar de suponer que una vía de impugnación sin permisos elimina todas las facultades administrativas.

Avances actuales en pruebas de fraude

A julio de 2026, los sistemas de pruebas de fallos en producción siguen evolucionando con nuevos clientes, máquinas virtuales actualizadas, mejores protocolos de disputa y una participación más amplia sin permisos.

La documentación oficial de OP Stack describe impugnaciones sin permisos y una transición en 2026 a un cliente de pruebas de fallos más reciente, lo que muestra que los operadores de impugnadores deben utilizar el software y los estados previos absolutos vigentes.

El aviso oficial de 2026 sobre la migración del cliente de pruebas de fallos explica que el software de pruebas anterior llegó al final de su periodo de soporte y que los operadores de cadenas deben migrar a la implementación sustituta.

La documentación oficial de Arbitrum describe BoLD como un diseño de disputa con límites temporales que admite la validación sin permisos y limita la capacidad de participantes maliciosos para prolongar indefinidamente las disputas.

La introducción general de BoLD de 2026 explica cómo las pruebas de fraude interactivas pueden permitir impugnaciones abiertas y, al mismo tiempo, limitar la duración de las disputas.

Estos avances muestran que las pruebas de fraude son sistemas de seguridad activos en producción, no simples conceptos teóricos de blockchain.

También muestran que los sistemas de pruebas requieren auditorías continuas, mantenimiento de clientes, coordinación de actualizaciones, supervisión y respuesta a incidentes.

Pruebas de fraude y actualizaciones de software

Un programa de pruebas de fallos debe ejecutar las mismas reglas de consenso que la versión del rollup cuyo estado se está impugnando.

Una actualización del protocolo puede modificar la ejecución de transacciones, los costes de gas, las funciones precompiladas, las reglas de los bloques, los contratos del sistema o la interpretación de los datos.

El software de impugnación que utilice un conjunto de reglas obsoleto puede clasificar erróneamente como no válida una declaración legítima o no impugnar una declaración realmente no válida.

Los sistemas de pruebas suelen utilizar un estado previo absoluto que compromete las condiciones iniciales de la máquina virtual de pruebas.

Modificar el programa de pruebas o las reglas de consenso puede exigir un nuevo estado previo y contratos on-chain actualizados.

Los operadores deben coordinar cuidadosamente las actualizaciones para que las disputas antiguas y nuevas se resuelvan conforme a las reglas correctas.

Esta complejidad es una de las razones por las que se consideran valiosas varias implementaciones independientes de pruebas para la seguridad a largo plazo.

¿Qué es un ataque de retraso?

Un ataque de retraso intenta prolongar la resolución de una disputa o impedir que un estado válido se convierta en definitivo, sin demostrar correctamente que el estado es inválido.

Un atacante puede crear declaraciones contradictorias, forzar rondas repetidas de impugnación, aprovechar reglas de plazos o bloquear el capital de los participantes honestos.

Los diseños interactivos más antiguos podían permitir que los atacantes iniciaran disputas secuenciales que prolongasen repetidamente las retiradas.

Los diseños de disputa con límites temporales pretenden que numerosas declaraciones maliciosas puedan resolverse dentro de un plazo máximo previsible.

Las garantías económicas encarecen los ataques de retraso, pero no eliminan la necesidad de reglas sólidas sobre plazos y disputas.

Un sistema debe proteger la seguridad —que las declaraciones no válidas no se conviertan en definitivas— y también la disponibilidad operativa, que exige que las declaraciones válidas lleguen a ser definitivas.

Seguridad frente a disponibilidad operativa

La seguridad significa que el sistema de pruebas de fraude no acepta un estado no válido ni permite una retirada no autorizada.

La disponibilidad operativa significa que las transacciones, declaraciones de estado y retiradas legítimas acaban completándose.

Un sistema puede preservar la seguridad pausando todas las retiradas mientras persista la incertidumbre, pero esa respuesta perjudica la disponibilidad operativa.

Un sistema puede mejorar la disponibilidad operativa finalizando las declaraciones rápidamente, pero un plazo de impugnación demasiado breve puede debilitar la seguridad.

Los controles de emergencia, los plazos de disputa, las garantías, los periodos de impugnación y las reglas de permisos equilibran estos dos objetivos.

Al evaluar un rollup, los usuarios deben preguntarse tanto si pueden robarse los fondos como si pueden quedar inaccesibles durante un periodo prolongado.

Principales supuestos de seguridad de las pruebas de fraude

En general, un rollup con pruebas de fraude presupone que al menos una parte honesta puede reconstruir el estado del rollup e impugnar las declaraciones no válidas.

Los datos de transacciones necesarios deben seguir disponibles el tiempo suficiente para que esa parte pueda verificar el estado.

La blockchain de liquidación debe seguir procesando transacciones y no censurar todas las impugnaciones honestas durante el plazo de disputa.

La función de transición de estado del rollup y la máquina virtual de pruebas deben implementar correctamente las reglas previstas.

Los contratos on-chain de disputa deben evaluar correctamente los movimientos, plazos, garantías, compromisos y pruebas finales.

Los impugnadores honestos deben utilizar software actualizado, recursos de cálculo suficientes, fuentes de datos fiables y fondos suficientes para pagar el gas y las garantías.

Las claves de actualización, los guardianes, los consejos de seguridad y los contratos de gobernanza no deben abusar de ninguna facultad que permita anular o sustituir el sistema de pruebas.

¿Puede un solo impugnador honesto proteger a todos?

En teoría, un solo impugnador honesto puede impedir que una declaración de estado no válida se convierta en definitiva si el protocolo no requiere permisos y se cumplen todos los supuestos necesarios.

El impugnador no necesita el apoyo de la mayoría de los usuarios del rollup, porque el contrato de liquidación resuelve la disputa conforme a reglas de ejecución objetivas.

Sin embargo, la parte honesta debe detectar el fallo, disponer de los datos necesarios, seguir conectada, poder participar económicamente y evitar la censura.

Un sistema que técnicamente solo requiere un impugnador es más sólido si varios impugnadores independientes utilizan infraestructuras e implementaciones de software diferentes.

La diversidad reduce el riesgo de que un error, una interrupción, una restricción jurídica o un fallo de servicios en la nube desactive simultáneamente todos los sistemas de supervisión.

¿Pueden las pruebas de fraude detener todos los ataques a un rollup?

Las pruebas de fraude pueden rechazar transiciones de estado no válidas, pero no resuelven todos los problemas de seguridad que afectan a un rollup.

No impiden automáticamente la censura del secuenciador, el robo de claves de usuario, los contratos de aplicaciones maliciosos, el phishing, la manipulación de oráculos ni los ataques de gobernanza.

Es posible que no protejan a los usuarios si los datos se almacenan fuera de la capa de liquidación bajo supuestos de disponibilidad menos sólidos.

Tampoco pueden ayudar si el propio sistema de pruebas contiene un error grave compartido que hace que los participantes honestos y deshonestos calculen el mismo resultado incorrecto.

Un rollup seguro necesita pruebas de fraude, además de una sólida disponibilidad de datos, contratos bridge auditados, procedimientos de actualización seguros, nodos fiables y una gobernanza transparente.

Pruebas de fraude en Plasma

Los sistemas Plasma utilizan una blockchain principal para resolver disputas sobre la actividad en una cadena secundaria independiente.

Los usuarios pueden enviar pruebas de fraude si un operador intenta finalizar una transacción o un estado no válido.

Los diseños tradicionales de Plasma suelen almacenar gran parte de los datos de transacciones fuera de la blockchain principal.

Esta estructura crea un problema de retención de datos, porque es posible que los usuarios no puedan crear una prueba de fraude si el operador se niega a facilitar la información necesaria.

La documentación de Ethereum sobre Plasma explica que los rollups mejoran este modelo de seguridad al publicar los datos de las transacciones a través de la capa de liquidación.

Por tanto, las pruebas de fraude aparecen tanto en Plasma como en los optimistic rollups, pero las garantías de disponibilidad de datos que las acompañan son distintas.

Pruebas de fraude en canales de estado

Los canales de estado permiten a un grupo definido de participantes intercambiar actualizaciones de estado firmadas fuera de la blockchain.

Normalmente, los participantes utilizan la blockchain solo para abrir el canal, liquidar el estado final o resolver una disputa.

Un participante deshonesto puede intentar cerrar el canal utilizando un estado antiguo que le otorgue un saldo más favorable.

Durante el plazo de disputa, el participante honesto puede responder presentando un estado posterior firmado correctamente.

Esta prueba funciona como una prueba de fraude porque demuestra que la liquidación intentada está obsoleta o no es válida.

La guía de Ethereum sobre canales de estado explica cómo el arbitraje de disputas protege a los usuarios cuando se envía un estado no válido o desactualizado.

Cómo afectan las pruebas de fraude a los usuarios cripto

La mayoría de los usuarios de rollups no envían pruebas de fraude personalmente, ya que validadores especializados y servicios de supervisión verifican continuamente los estados.

Aun así, los usuarios dependen de este mecanismo cuando mantienen activos, interactúan con aplicaciones o retiran fondos mediante el bridge canónico de un optimistic rollup.

Un usuario puede ver una transacción confirmada rápidamente en el rollup mientras su finalidad en la capa de liquidación sigue pendiente.

Una impugnación satisfactoria puede revertir resultados aún no finalizados que se basen en una declaración de estado no válida.

Las carteras y aplicaciones deben explicar la diferencia entre la confirmación del secuenciador, la confirmación de la capa de liquidación y la finalidad completa de una retirada.

Los usuarios también deben saber si las pruebas de fraude de la red están activas, son abiertas a todos, pueden actualizarse o cuentan con controles administrativos de emergencia.

Cómo deben diseñar los desarrolladores las pruebas de fraude

Los desarrolladores de rollups deben garantizar que todas las operaciones relevantes para el consenso puedan reproducirse de forma determinista dentro del entorno de pruebas.

Deben evitar dependencias de la hora local, el comportamiento aleatorio del sistema operativo, servicios externos no documentados o resultados específicos del hardware.

El código de las pruebas, el código de los nodos y los contratos de verificación on-chain deben coincidir en la semántica de las instrucciones y los formatos de datos.

Los desarrolladores deben probar resultados no válidos, respuestas tardías, declaraciones contradictorias, falta de datos, agotamiento de garantías y actualizaciones del protocolo.

Deben ofrecer procedimientos claros para ejecutar impugnadores y verificar los estados previos y las direcciones de los contratos necesarios.

Las auditorías de seguridad deben examinar tanto la ruta de ejecución habitual del rollup como la ruta de disputa, menos frecuente.

Un sistema de disputa que nunca se haya probado en condiciones adversas realistas puede fallar cuando por fin se necesite.

Cómo evaluar un sistema de pruebas de fraude

Empieza por confirmar si la red dispone realmente de un sistema activo de pruebas de fraude o si solo cuenta con una hoja de ruta o un diseño previsto.

Comprueba si cualquiera puede presentar impugnaciones o si la participación está controlada por una lista de permitidos.

Identifica el periodo de impugnación, el retraso de las retiradas, los requisitos de garantías, los plazos de disputa y el tiempo máximo de resolución previsto.

Averigua dónde se publican los datos de las transacciones y si los usuarios pueden reconstruir el estado del rollup de forma independiente.

Revisa si los guardianes de emergencia, los consejos de seguridad, los administradores o los contratos de gobernanza pueden anular resultados ya finalizados.

Busca varios operadores de impugnadores, software público para nodos, compilaciones reproducibles, auditorías, divulgaciones de vulnerabilidades y programas de recompensas por errores.

Confirma cómo gestiona el sistema de pruebas las actualizaciones del protocolo y las disputas iniciadas con una versión anterior del software.

Una descripción de seguridad sólida debe explicar las limitaciones y los supuestos de confianza, en lugar de limitarse a afirmar que el rollup hereda toda la seguridad de la capa base.

Malentendidos habituales sobre las pruebas de fraude

Un malentendido habitual es creer que cada transacción de un rollup va acompañada de una prueba de fraude.

Por lo general, las pruebas de fraude solo se generan cuando alguien impugna un resultado controvertido.

Otro malentendido es pensar que una prueba de fraude demuestra una intención delictiva o deshonesta.

El mecanismo demuestra que un cálculo o una declaración son incorrectos; la intención jurídica es una cuestión independiente.

Algunos usuarios creen que un plazo de retirada de una semana significa que la transacción del rollup tarda una semana en ejecutarse.

La transacción del rollup puede ejecutarse en segundos, mientras que el plazo más largo se aplica a la liquidación y a la seguridad de las retiradas canónicas.

Otro error es suponer que las pruebas de fraude sin permisos eliminan todos los controles centralizados.

Un rollup puede permitir impugnaciones abiertas y, aun así, mantener la secuenciación centralizada, claves de actualización, guardianes o facultades para pausar el sistema en caso de emergencia.

Riesgos de las pruebas de fraude

El riesgo de implementación surge cuando el programa de pruebas, la máquina virtual o los contratos inteligentes contienen errores.

El riesgo de disponibilidad de datos aparece cuando los impugnadores no pueden obtener la información necesaria para reconstruir el estado en disputa.

El riesgo de censura surge cuando una transacción de prueba de fraude honesta no puede llegar a la blockchain de liquidación antes de que venza el plazo.

El riesgo para la disponibilidad operativa surge cuando las declaraciones maliciosas o los fallos de software retrasan las retiradas válidas.

El riesgo económico aparece cuando el precio del gas o los requisitos de las garantías hacen que las impugnaciones sean demasiado costosas.

El riesgo de actualización surge cuando los nodos, los programas de pruebas, los contratos y los estados previos no utilizan la misma versión del protocolo.

El riesgo de gobernanza aparece cuando algunas partes privilegiadas pueden pausar, sustituir o anular el sistema de disputa.

El riesgo operativo surge cuando todos los impugnadores dependen del mismo proveedor de servicios en la nube, base de código, base de datos o servicio de supervisión.

Preguntas frecuentes

¿Qué es una prueba de fraude, explicado de forma sencilla?

Una prueba de fraude es una evidencia de que un resultado propuesto para una blockchain o un rollup se ha calculado incorrectamente.

¿Por qué se utilizan pruebas de fraude en el sector cripto?

Permiten que el cálculo off-chain escale una blockchain y ofrecen a los participantes independientes una forma de rechazar resultados no válidos.

¿Cuál es la diferencia entre una prueba de fraude y una prueba de fallos?

Los términos suelen describir el mismo mecanismo, pero «prueba de fallos» evita sugerir que todos los resultados incorrectos se deban a un fraude intencionado.

¿Qué sistemas cripto utilizan pruebas de fraude?

Se utilizan principalmente en optimistic rollups, aunque también aparecen mecanismos de disputa relacionados en sistemas Plasma y canales de estado.

¿Cada transacción de un optimistic rollup genera una prueba de fraude?

No, normalmente las pruebas de fraude solo se generan cuando un participante disputa una declaración de estado incorrecta.

¿Quién puede presentar una prueba de fraude?

En un sistema totalmente abierto a todos, cualquiera puede presentarla; en un sistema con permisos, las impugnaciones quedan restringidas a participantes aprobados.

¿Qué es un impugnador?

Un impugnador es un participante o servicio automatizado que comprueba las declaraciones de estado del rollup e impugna las que no siguen las reglas del protocolo.

¿Qué es un periodo de impugnación?

Es el plazo durante el cual se puede disputar un estado optimista propuesto antes de que se convierta en definitivo.

¿Cuánto dura el periodo de impugnación de una prueba de fraude?

La duración depende del protocolo, aunque en los optimistic rollups en producción son habituales los periodos cercanos a una semana.

¿Por qué tardan varios días las retiradas de los optimistic rollups?

El retraso da tiempo a los impugnadores para detener las retiradas basadas en estados del rollup no válidos o inventados.

¿Puede una prueba de fraude revertir una transacción?

Puede invalidar una declaración de estado aún no finalizada y los resultados basados en ella, conforme a las reglas de disputa y recuperación del rollup.

¿Qué es una prueba de fraude interactiva?

Es una prueba que utiliza varias rondas de disputa para reducir un cálculo extenso a un único paso pequeño que pueda comprobarse on-chain.

¿Qué es la bisección en una prueba de fraude?

La bisección divide repetidamente una traza de ejecución para que las partes enfrentadas puedan localizar el primer punto en que divergen sus resultados.

¿Qué es una prueba de un solo paso?

Permite al contrato de liquidación verificar una instrucción controvertida de la máquina y determinar qué participante la calculó correctamente.

¿Qué es una raíz de salida?

Es un compromiso criptográfico del estado de un rollup y de información relacionada en un bloque determinado.

¿Qué es el supuesto de una parte honesta?

Es el supuesto de que al menos un participante capacitado detectará e impugnará un estado no válido antes de que venza el plazo.

¿Un sistema de pruebas de fraude necesita muchos validadores?

En teoría, puede bastar con un impugnador honesto, pero varios impugnadores independientes aportan más resiliencia operativa.

¿Por qué es necesaria la disponibilidad de datos?

Los impugnadores necesitan los datos de transacciones para reconstruir el estado del rollup y demostrar exactamente dónde se produjo una transición incorrecta.

¿Pueden funcionar las pruebas de fraude si los datos de transacciones están ocultos?

Pueden fallar si los datos ocultos son necesarios para reproducir la ejecución y el protocolo no ofrece otra prueba de disponibilidad de datos.

¿Cuál es la diferencia entre una prueba de fraude y una prueba de validez?

Una prueba de fraude demuestra que un resultado es incorrecto después de una impugnación; una prueba de validez demuestra que es correcto antes de aceptarlo.

¿Una prueba de fraude es una prueba de conocimiento cero?

No, una prueba de fraude suele ser un mecanismo de disputa optimista, aunque los sistemas avanzados pueden combinar pruebas de fallos con tecnología de conocimiento cero.

¿Una prueba de Merkle es lo mismo que una prueba de fraude?

No, una prueba de Merkle demuestra que un elemento está incluido en un conjunto de datos comprometido, mientras que una prueba de fraude demuestra que un cálculo o una transición de estado son incorrectos.

¿Qué ocurre si prospera una prueba de fraude?

Se rechaza la declaración no válida, se conserva el estado correcto y el participante perdedor puede perder una garantía.

¿Qué ocurre si fracasa una impugnación?

La declaración impugnada puede seguir avanzando hacia su finalización, y el impugnador que no tenga éxito puede perder parte de los fondos entregados como garantía.

¿Por qué se exigen garantías?

Las garantías disuaden de las declaraciones falsas, el spam y las disputas innecesarias, al hacer que la participación deshonesta o negligente tenga un coste económico.

¿Pueden las pruebas de fraude detener la censura del secuenciador?

No, verifican la corrección de la ejecución, mientras que la resistencia a la censura suele requerir vías de inclusión forzosa y otras funciones del protocolo.

¿Pueden las pruebas de fraude impedir los hackeos de contratos inteligentes?

No, una transacción maliciosa o vulnerable de una aplicación que se ejecute correctamente puede seguir siendo válida conforme a las reglas de transición de estado del rollup.

¿Puede contener errores un contrato de pruebas de fraude?

Sí, los programas de pruebas, las máquinas virtuales, los contratos de disputa y el software de los impugnadores pueden contener vulnerabilidades de implementación.

¿Qué es un ataque de retraso?

Es un intento de prolongar la resolución de una disputa o bloquear una finalización válida sin demostrar que el estado sea incorrecto.

¿Qué es una disputa con límite temporal?

Es una disputa diseñada para resolverse dentro de un plazo máximo previsible, incluso si se presentan muchas declaraciones maliciosas.

¿Todos los sistemas de pruebas de fraude son abiertos a todos?

No, algunas redes restringen la participación de validadores o impugnadores, mientras que otras permiten la participación pública sujeta a requisitos técnicos y de garantías.

¿Puede un sistema de pruebas de fraude sin permisos tener administradores?

Sí, los guardianes de emergencia, las autoridades de actualización, los órganos de gobernanza o los consejos de seguridad pueden conservar facultades importantes.

¿Tienen que ejecutar los usuarios el software de impugnación?

Por lo general, los usuarios corrientes dependen de validadores independientes, aunque ejecutar software de verificación puede reducir la dependencia de otros participantes.

¿Qué deben comprobar los usuarios antes de utilizar un optimistic rollup?

Deben comprobar si las pruebas de fraude están activas, quién puede impugnar, dónde se almacenan los datos, cuánto tardan las retiradas y qué partes conservan facultades de emergencia.

Conclusión

Una prueba de fraude es un mecanismo de disputa que demuestra que un lote de transacciones de criptomonedas, una transición de estado, una raíz de salida o una declaración de retirada se ha calculado incorrectamente.

Es un componente de seguridad central de los optimistic rollups, ya que estos sistemas aceptan temporalmente resultados off-chain sin exigir una prueba de validez inmediata.

Los impugnadores independientes reproducen la ejecución e impugnan las declaraciones incorrectas durante un periodo de impugnación definido.

Los juegos de disputa interactivos pueden reducir millones de pasos de cálculo a una sola instrucción que la blockchain de liquidación verifica directamente.

La disponibilidad de datos es esencial, porque los impugnadores no pueden demostrar un fallo si no acceden a las transacciones que sustentan un compromiso de estado.

Las garantías económicas disuaden de presentar declaraciones falsas y compensan parte del coste de defender el sistema.

Las pruebas de fraude sin permisos reducen la dependencia de validadores aprobados, pero no eliminan todos los supuestos de confianza relacionados con la gobernanza, las actualizaciones, la secuenciación o las operaciones.

Las pruebas de fraude se diferencian de las pruebas de validez porque rechazan resultados incorrectos tras una impugnación, en lugar de demostrar que cada resultado es correcto antes de aceptarlo.

En 2026, los sistemas de pruebas de fallos en producción siguen evolucionando con clientes de pruebas actualizados, protocolos de disputa con límites temporales y una participación más amplia sin permisos.

Comprender las pruebas de fraude ayuda a los usuarios cripto a evaluar la seguridad de los rollups, los retrasos de las retiradas, la disponibilidad de datos, los supuestos sobre los impugnadores y los límites reales de la escalabilidad optimista de blockchain.