Cada vez que un rollup envía transacciones a Ethereum, alguien tiene que convencer a la capa uno de que el resultado es el correcto. De eso depende que un retiro llegue a destino. Durante los primeros años del escalado, esa garantía se delegó en la vigilancia: si nadie protestaba a tiempo, el lote se daba por bueno.
Las pruebas de validez invierten la lógica. En lugar de confiar y esperar una denuncia, producen un certificado criptográfico que Ethereum comprueba antes de aceptar nada, sin repetir la ejecución. El retiro deja de arrastrar un plazo de disputa, y ese plazo es el cuello de botella de las pruebas de fraude: la documentación de Ethereum cifra en unos siete días la espera de un rollup optimista.
El interés por cambiar de sistema ya no es teórico. Scroll cerró el 22 de septiembre de 2026 la migración de su stack de pruebas a OpenVM v2.0.0 con SWIRL, y Base mantiene desde mayo de 2026 un diseño que combina dos pruebas para el mismo estado, una atestación de hardware y una prueba ZK generada con SP1. La pregunta ya no es si la criptografía funciona, si no cuánto cuesta producir una prueba y cuánto cuesta verificarla en la capa uno.
¿Qué es una ZK Proofs o Prueba de validez?
Cada lote que sale de una red de capa dos llega a Ethereum con un certificado que acredita que el resultado es correcto. Ese documento responde a una pregunta concreta: ¿el estado que anuncia el operador es el que resulta de aplicar esas transacciones sobre el estado anterior? La prueba no describe el resultado ni lo resume, lo demuestra.
El reparto de tareas es fijo. Un probador externo, que trabaja en máquinas con tarjetas gráficas, genera la prueba y asume el coste eléctrico. Un contrato desplegado en Ethereum la verifica, y apenas ocupa unas pocas líneas. Producir es caro y comprobar es barato.
Los formatos más usados son las zk-SNARK y las zk-STARK. La diferencia con más consecuencias no está en el tamaño ni en la latencia, sino en el arranque. Algunas construcciones SNARK, como Groth16, necesitan una ceremonia de configuración con parámetros secretos, y si esos parámetros se manipulan, la garantía se debilita.
Las STARK no pasan por ahí, y por eso los criterios de la Fundación Ethereum exigen que las pruebas de la capa uno no dependan de configuraciones de confianza. Verificar también tiene precio: una medición de Nethermind cifra en 194.396 gas el coste de verificar una prueba Groth16 sobre la curva BN254.
La mayor parte de ese gasto son los emparejamientos de curva, con un precio fijado por EIP-1108 en 34.000 gas por unidad más 45.000 de base. Las STARK ocupan bastante más y pueden superar el millón de gas, así que en la práctica se envuelven en un SNARK más pequeño antes de publicarlas.
Infografía de como funciona una ZK Proofs
La prueba de fraude, la apuesta por la vigilancia
El modelo opuesto parte de una premisa distinta: dar por bueno el lote y confiar en que alguien lo revise. Un rollup optimista publica sus datos y su raíz de estado en Ethereum y abre una ventana durante la cual cualquier observador puede comparar el resultado anunciado con el que obtiene al ejecutar los datos por su cuenta.
El lote se publica y arranca la ventana de disputa.
Quien detecta una discrepancia presenta una prueba de fraude.
Las dos partes estrechan el desacuerdo hasta una sola instrucción.
Solo esa instrucción se reejecuta en Ethereum.
Esa ventana explica la espera del usuario. La documentación de Ethereum sobre rollups optimistas sitúa en unos siete días el plazo que separa una salida de la red de su confirmación definitiva, y ese plazo existe para que el vigilante tenga tiempo de actuar. La ventana no se dedica a resolver la disputa, que cuesta minutos, sino a garantizar que al defensor no le corten el turno.
El mecanismo de disputa es más barato de lo que parece, aunque el supuesto de seguridad que lo sostiene es incómodo de decir en voz alta: el sistema funciona mientras exista al menos un nodo honesto dispuesto a vigilar y con fondos para apostar. La ausencia de disputas en la práctica no reduce esa dependencia.
Conviene matizar que la vigilancia casi nunca se ha ejercido. En Arbitrum no se presentó ninguna disputa por fraude en la red principal durante los más de tres años que van de su lanzamiento en agosto de 2021 a la apertura del sistema a validadores sin permiso, en febrero de 2025. El mecanismo disuade por su existencia, no por su uso.
¿Qué es una zkVM y qué la diferencia de un circuito a medida?
La pieza que cambia el coste del montaje no es el formato de la prueba, sino cómo se construye el circuito. Un circuito a medida se diseña para el programa exacto que se quiere probar: cada cambio en la lógica obliga a revisar restricciones, y la auditoría no se hereda de un programa al siguiente.
Una zkVM invierte el planteamiento. En lugar de construir un circuito por programa, se construye un circuito que representa una máquina virtual completa, casi siempre sobre el conjunto de instrucciones RISC-V, y el programa se entrega como entrada.
El conjunto base de RISC-V tiene alrededor de cuarenta instrucciones, una superficie pequeña y auditable. Por eso SP1, OpenVM o RISC Zero comparten la misma arquitectura conceptual, y el desarrollo se hace en Rust en lugar de en un lenguaje de restricciones.
El precio de esa comodidad es el rendimiento. Un circuito a medida puede ejecutar menos trabajo por prueba que una zkVM, aunque en la práctica la ventaja se diluye porque la plataforma compartida recibe toda la inversión en ingeniería.
Uma Roy, cofundadora de Succinct, sostiene que optimizar un prover de GPU para SP1 sale a cuenta porque cada mejora beneficia a decenas de equipos a la vez. Un circuito específico obliga a justificar ese mismo esfuerzo para un único caso de uso.
La estimación que recoge el análisis The zkVM Wars apunta en la misma dirección: llevar un proyecto de circuitos a medida al mercado puede costar del orden de dos años y cien millones de dólares entre ingeniería y auditoría.
La frontera se ha difuminado. La Fundación Ethereum arrancó su zkEVM con circuitos a medida, y el equipo de Privacy and Scaling Explorations acabó pasándose a una zkVM de propósito general por auditabilidad.
Las zkVM modernas incorporan circuitos especializados para las operaciones caras, y la versión de producción de OpenVM 2.0.0 añadió aplazamientos, un mecanismo que permite a un programa invitado verificar circuitos arbitrarios dentro de la misma prueba.
Lo que cuesta cada opción
Los precios de producir una prueba se han desplomado en los últimos dos años. Axiom publicó en su banco de pruebas de OpenVM 2.0 Beta un coste medio de 0,01 dólares por bloque de Ethereum probado en un clúster de dieciséis tarjetas RTX 5090, con 7,9 segundos en el percentil 99.
Criterio
Prueba de fraude
Prueba de validez con zkVM
Prueba de validez con circuito propio
Finalidad del retiro
Unos siete días de ventana
Minutos u horas
Minutos u horas
Dónde está el gasto
Publicar datos en la capa uno
Generar la prueba en GPU
Generar la prueba y mantener el circuito
Coste de generar
No aplica en el caso normal
En torno a 0,01 dólares por bloque
Más trabajo por restricción
Coste de verificar
Una instrucción reejecutada
Unos 194.000 gas envuelta en Groth16
Verificación propia del circuito
Desarrollo
Bajo, el sistema ya existe
Semanas de código en Rust
Del orden de dos años y cien millones
Supuesto de seguridad
Un vigilante honesto
La solidez del sistema de pruebas
La solidez del circuito y su auditoría
Riesgo principal
Censura del vigilante
Fallo de solidez del sistema
Error en una restricción no revisada
La versión de producción de OpenVM 2.0.0 prueba bloques de Ethereum en tiempo real con ocho tarjetas, con un percentil 99 de 9,8 segundos, y envuelve la prueba resultante en un SNARK verificable en la EVM en 8,1 segundos con una sola tarjeta. Esa cifra explica por qué la comparación se hace a menudo sobre el coste en gas de la verificación.
La comparación honesta tiene que incluir el desarrollo, porque el coste de producir pruebas no decide una migración. Escribir el programa en Rust sobre una zkVM es cuestión de semanas, y diseñar un circuito propio es un proyecto de años con auditorías independientes.
Hay un tercer coste que no aparece en las hojas de cálculo, y es el de la incertidumbre. La Fundación Ethereum fijó en julio de 2025 el listón del proving en tiempo real en diez segundos para el percentil 99 de los bloques, hardware de 100.000 dólares, 10 kilovatios de consumo, código abierto, 300 kilobytes de prueba como máximo y ninguna configuración de confianza, según su definición publicada.
Los límites que la prueba no arregla
Añadir criptografía a una red no la convierte en descentralizada. El marco de etapas de L2BEAT mide esa descentralización por separado y avisa de que un proyecto puede estar en la fase más avanzada y aun así tener un sistema de pruebas experimental o sin auditar.
El control de quién puede proponer bloques y en qué orden.
La actualización de contratos sin ventana de salida.
La censura de una transacción concreta.
Base ejemplifica ese límite. La red sigue en etapa 1 porque mantiene un único secuenciador, contratos actualizables sin ventana de salida y un multisig que controla la lista de probadores autorizados. La prueba ZK no corrige ninguno de esos puntos y funciona como mecanismo de respaldo.
Tampoco garantiza que los datos estén disponibles ni que el operador incluya transacciones. Una prueba de validez demuestra que la transición de estado es correcta, y nada más: si el secuenciador ignora una orden, el usuario necesita otra vía para forzar su inclusión en la capa uno. Esa vía llega con retraso.
El riesgo propio de este modelo es un fallo de solidez. Un error que permita demostrar un estado inválido no se parece a un fallo de rendimiento, porque un atacante podría acuñar activos o reescribir el estado. La Fundación Ethereum lo advirtió en diciembre de 2025 y cambió el foco del sector: la velocidad ya no era el obstáculo, la seguridad demostrable sí, según su segunda entrega sobre el zkEVM.
La seguridad releva a la velocidad
La Fundación Ethereum declaró en diciembre de 2025, que el proving en tiempo real había dejado de ser el problema. La latencia por bloque cayó de dieciséis minutos a dieciséis segundos, los costes se redujeron 45 veces y el 99% de los bloques se probaba por debajo de los diez segundos en hardware de referencia. De ahí salieron tres objetivos medidos con la misma vara.
Medir la seguridad de cada zkVM con una herramienta común, llamada soundcalc.
Llegar a 100 bits de seguridad demostrable con pruebas de hasta 600 kilobytes.
Alcanzar 128 bits, pruebas de 300 kilobytes como máximo y un argumento formal sobre la recursión antes de que acabe 2026.
Aun así, el comunicado admitía que quedaba lo difícil. Los dos primeros objetivos se miden con la herramienta que la propia Fundación mantiene, mientras que el tercero exige demostrar matemáticamente que la recursión del sistema es sólida. Ese punto ya no es ingeniería, es formalización sobre un sistema que todavía cambia.
La auditoría externa forma parte del mismo giro. OpenVM 2.0.0 pasó una revisión de zkSecurity que cubrió SWIRL, los circuitos de agregación y continuaciones, los aplazamientos y el verificador de Halo2, y sus extensiones de Keccak y SHA-2 entraron en la verificación formal. La carrera ya no se decide por quién prueba antes, sino por quién puede demostrar que su prueba no se rompe.
Queda un matiz que la propia Fundación reconoce. Las cifras de latencia y coste salen de bancos de pruebas con hardware de referencia, y el nivel de seguridad se estima con modelos que todavía dependen de conjeturas criptográficas. Cumplir hoy el listón no garantiza cumplirlo dentro de tres años.
¿Qué decide la próxima migración de pruebas?
El argumento económico se ha vuelto difícil de rebatir. Producir una prueba de bloque cuesta céntimos, verificarla cuesta menos de 200.000 gas y el trabajo de integrarla se reduce a elegir una máquina virtual y auditar el resultado. Cuando la criptografía deja de ser el cuello de botella, la decisión de una red de capa dos se parece más a una compra de infraestructura.
El premio mayor no está en las capas dos. La hoja de ruta de la Fundación Ethereum para integrar un zkEVM en la capa uno persigue que los validadores verifiquen una prueba en lugar de reejecutar el bloque, lo que permitiría subir el límite de gas sin exigir más hardware a quien hace staking desde casa.
Ese escenario sigue siendo un banco de pruebas. El proving en tiempo real se mide hoy fuera de la cadena, y su adopción depende de que la seguridad demostrable llegue al nivel que el propio plan exige.
La tensión que queda es la de siempre en criptografía. Cuanto más rápido cambia un sistema, más difícil es demostrar que es correcto, y cuanto más dinero depende de él, más caro sale un error de solidez. Las próximas migraciones no se decidirán por quién las anuncia, sino por quién sostiene durante años que su prueba nunca se rompió.
