# Dieciséis segundos fueron la parte fácil: el zkEVM de Ethereum

> Los objetivos de prueba en tiempo real de Ethereum se cumplen según las propias cifras de la EF. El problema más difícil es que algunas de las suposiciones de seguridad subyacentes ya estaban equivocadas.

- Source: https://www.steadyrain.xyz/es/articles/ethereum-l1-zkevm-realtime-proving/
- Publisher: Steady Rain
- Author: 0xYatha
- Published: 2026-10-28T04:25:00.719Z
- Categories: DeFi
- Language: es

## Introducción

El post de la Ethereum Foundation del 18 de diciembre de 2025 sobre los fundamentos de seguridad de los zkEVM hace dos cosas en el mismo documento. Declara cumplidos los objetivos de realtime proving: latencia de prueba reducida de 16 minutos a 16 segundos, costos reducidos aproximadamente 45x, zkVMs produciendo pruebas para el 99% de los bloques de mainnet en menos de 10 segundos con hardware que cuesta menos de $100,000. Luego admite que algunas de las conjeturas matemáticas que sustentan los sistemas de prueba basados en STARK han sido refutadas, lo que significa que un zkEVM que anuncia 100 bits de seguridad puede, en la práctica, estar entregando algo más cercano a 80.

Esas dos afirmaciones pertenecen a categorías distintas. La primera es un resultado de ingeniería, autorreportado y visible en un dashboard público. La segunda es una retractación de una afirmación que la industria ya venía haciendo en material de marketing y en resúmenes de auditoría. El número de rendimiento mejoró; el número de seguridad estaba equivocado.

Ese orden es la parte interesante. La restricción vinculante en un zkEVM enshrined en L1 nunca fue el throughput. Un sistema de prueba que tarda 16 minutos en probar un bloque de 12 segundos es inútil para el consenso, así que la latencia tenía que bajar primero, y los equipos de zkVM la bajaron rápido. Pero una vez que los validadores de Ethereum dejan de reejecutar transacciones y empiezan a aceptar pruebas, el sistema de prueba se convierte en lo que decide qué es verdadero. Una falla de liveness en ese mundo significa un slot perdido. Una falla de soundness significa que el consenso acepta una transición de estado que nunca ocurrió: tokens acuñados de la nada, balances reescritos, bridges drenados, y ninguna capa de reejecución debajo que lo detecte.

Por eso la hoja de ruta 2026 de la Foundation es un sprint de seguridad y no uno de rendimiento. Los entregables son una herramienta de scoring llamada soundcalc, 100 bits de seguridad demostrable con pruebas de menos de 600 KiB para el fork Glamsterdam, y 128 bits con pruebas de menos de 300 KiB más un argumento formal de soundness para fines de 2026. La palabra que carga el peso en todo esto es "demostrable", a diferencia de "conjeturada", y la distinción es estructural precisamente porque las conjeturas ya fallaron una vez.

## Lo que el realtime proving tenía que superar

*[Figure: img1]*

El post de la Foundation del 10 de julio de 2025 que abrió este programa definió el realtime proving como una lista de números duros más que como una dirección de avance. Una prueba para el 99% de los bloques de mainnet en 10 segundos. Gasto de capital en infraestructura propia bajo $100,000. Consumo eléctrico bajo 10 kW. Tamaño de prueba bajo 300 KiB. Al menos 128 bits de seguridad, con 100 bits aceptados como piso a corto plazo. Sin trusted setups, y código completamente open-source.

Cada restricción corresponde a una propiedad del estado final. El presupuesto de latencia de 10 segundos existe porque el tiempo de slot de Ethereum no deja margen para una prueba que llegue después del siguiente bloque. Los límites de $100,000 y 10 kW existen porque la Foundation quiere que el proving siga siendo accesible para operadores que no son hyperscalers, lo cual enmarcan como una salvaguarda de resistencia a la censura: si solo un puñado de instalaciones industriales puede producir pruebas a tiempo, esas instalaciones pueden negarse a probar un bloque. El límite de tamaño de prueba importa porque cada validador de la red descarga la prueba, y un objeto de 600 KiB propagándose a cada nodo en un slot es un problema de ancho de banda distinto al de uno de 50 KiB. La ausencia de trusted setups elimina una clase de riesgo de ceremonia que ninguna cantidad de auditoría posterior puede retirar.

El mecanismo al que sirve todo esto es la **validación stateless**. Hoy un validador de Ethereum mantiene el estado completo y reejecuta cada transacción de un bloque para confirmar la raíz de post-estado declarada por el proposer. Esa reejecución es la razón por la que los requisitos de hardware de los nodos siguen el límite de gas, y por la que subir el límite de gas es una pelea. Bajo validación stateless, el validador no mantiene estado. Recibe un bloque, una prueba sucinta de que ejecutar las transacciones del bloque contra la raíz de pre-estado produce la raíz de post-estado declarada, y verifica la prueba. La verificación es barata y aproximadamente constante respecto al tamaño del cómputo que se está probando. El proving es costoso y escala con él.

Esa asimetría es toda la fuente del argumento de margen para el límite de gas. Si los validadores verifican en lugar de reejecutar, el costo de validar un bloque 10x más grande no sube 10x para ellos. Sube para quien produce la prueba. La secuenciación de la Foundation se sigue directamente de esto: los validadores primero corren clientes ZK stateless de forma opcional, junto a la reejecución normal; una vez que una supermayoría del stake está cómoda, el límite de gas sube a un nivel donde la verificación de pruebas es la única manera práctica de seguir el ritmo; una vez que todos los validadores verifican pruebas, esas pruebas pueden alimentar un precompile `EXECUTE` que extiende la misma maquinaria a los rollups.

Ethproofs, el tracker público que usa el ecosistema para medir esto, plantea el camino en cinco fases: sprint de rendimiento, sprint de seguridad, proving diferido, proving obligatorio, pruebas enshrined. Según la instantánea que sustenta este análisis, el sprint de rendimiento está marcado como completo y el sprint de seguridad es la fase actual, trabajando hacia el hito de 100 bits y 600 KiB. Las últimas tres fases no han comenzado.

## La distancia entre el 99% de los bloques y el tracker

*[Figure: img2]*

El "99% de los bloques en menos de 10 segundos" de la Foundation y los datos de cohorte de Ethproofs describen el mismo sistema desde ángulos distintos, y la brecha entre ambos es donde vive el trabajo de ingeniería restante.

En las cifras agregadas de Ethproofs, a lo largo de 502,520 slots de bloque rastreados, los provers produjeron una prueba dentro de los 10 segundos el 70.2% de las veces. Eso supera el umbral provisional declarado del 70%, aunque por poco. La masa restante no son en su mayoría pruebas lentas. Es ausencia: 26.2% de los slots registraron al prover offline, 3.36% "stunned", y 0.22% "paralizado". Condicionado a que una prueba se haya completado, el 95.4% cayó dentro de la ventana de elegibilidad.

Esos dos números, 70.2% incondicional y 95.4% condicional, dicen algo específico. Los sistemas de prueba son rápidos. Las operaciones a su alrededor todavía no son confiables. Una cohorte de investigación corriendo zkVMs experimentales en clústeres de GPU va a tener downtime, y nadie debería leer un cuarto de los slots offline como una declaración sobre la criptografía subyacente. Pero la hoja de ruta de la Foundation llega eventualmente al proving obligatorio, donde una prueba faltante es un evento relevante para el consenso y no un hueco en un dashboard. La variable que tiene que acercarse a cero antes de que esa fase sea creíble es la tasa de offline, y es la variable que el titular del sprint de rendimiento no aborda.

La diversidad de provers muestra la misma forma. De diez provers evaluados en la cohorte de realtime proving, tres cumplen el umbral semanal de elegibilidad: Zisk con 69%, Axiom con 58%, zkDTVM con 8%. El resto, incluyendo Pico, las variantes de Airbender, Succinct y Ziren, están en 0%. Eso es una instantánea de un objetivo en movimiento y varios de esos equipos probablemente están a semanas de cruzar la línea. Sigue siendo la configuración que tiene la red hoy, y importa para la siguiente sección, porque la defensa que propone la Foundation contra una falla de soundness es la diversidad.

Los costos, mientras tanto, han llegado por debajo de donde casi cualquiera hubiera adivinado hace dos años. Los provers líderes reportan costos por prueba en el rango de $0.0031 a $0.0063, logrados en clústeres de cuatro a dieciséis GPUs NVIDIA 5090. Un tercio de centavo para probar un bloque de Ethereum no es un error de redondeo frente a las recompensas de bloque; está por debajo de toda consideración. Si ese precio sobrevive el contacto con un mercado competitivo que cargue electricidad a costo pleno, depreciación, redundancia y margen de operador es una pregunta aparte, y la economía de una cohorte de investigación no es economía de mercado.

## Por qué las fallas de soundness son una clase de problema distinta

Todo sistema distribuido distingue liveness de safety, y la distinción usualmente se resuelve en un trade-off donde se acepta más de uno para obtener menos del otro. Un zkEVM enshrined en L1 vuelve ese trade-off radicalmente asimétrico.

Una falla de liveness en la capa de proving significa que no llega ninguna prueba válida para un bloque dentro del slot. Bajo los diseños propuestos, esto es sobrevivible. La red puede recurrir a la reejecución durante las fases opcional y diferida, los attesters pueden negarse a construir sobre un bloque no probado, y las penalizaciones pueden fijarse para que una falla repetida sea costosa para quien debía producir la prueba. El daño se mide en slots perdidos y finalidad retrasada.

Una falla de soundness significa que el sistema de prueba acepta una prueba para una transición de estado que es falsa. Si los validadores han dejado de reejecutar, nada más en el stack lo está verificando. El propio planteamiento de la Foundation es contundente sobre lo que eso permite: acuñar tokens, reescribir estado, robar fondos. No hay un equivalente a una detención de la cadena que lo atrape en curso, porque desde el punto de vista del consenso no ocurrió nada anormal. El estado falsificado es canónico.

Por eso el despliegue propuesto nunca pone a un solo zkVM en la posición de confianza. Un cliente ZK stateless en el diseño de la Foundation verifica pruebas de múltiples zkVMs implementados de forma independiente, cada uno probando contra una implementación distinta del EVM, con tres como número ilustrativo. Un validador acepta el bloque solo si todos ellos verifican. La analogía es explícita: esto es diversidad de clientes aplicada una capa más abajo. Un bug de soundness en un solo zkVM se convierte en un problema de liveness en lugar de un robo, porque los otros verificadores rechazan la prueba falsificada y el bloque no recibe attestation.

La debilidad de ese argumento es la misma debilidad que ha perseguido a la diversidad de clientes en sí. La defensa en profundidad solo funciona si las implementaciones fallan de forma independiente. Dos zkVMs construidos sobre el mismo esquema de polynomial commitment, apoyados en la misma conjetura de soundness, compilados mediante toolchains superpuestos, apuntando a la misma especificación del EVM, no dan tres oportunidades independientes de detectar un error. Dan una, disfrazada de tres. Los datos de la cohorte lo hacen concreto: si solo tres implementaciones son suficientemente rápidas para ser elegibles en un momento dado, la diversidad práctica disponible para un validador es la que esas tres resulten tener, y la estructura de correlación entre ellas no es algo que mida el dashboard de Ethproofs.

La diversidad nominal que reproduce concentración bajo otra etiqueta es el modo de falla a vigilar aquí, y no se resuelve agregando más entradas a un tracker.

## Bits demostrables versus bits conjeturados

*[Figure: img3]*

La respuesta de la Foundation al problema de soundness es dejar de aceptar niveles de seguridad autorreportados y empezar a calificarlos contra un estándar común. Ese estándar es **soundcalc**, una herramienta que estima la seguridad de un zkVM en bits a partir de cotas criptográficas actuales y los parámetros del sistema de prueba. La integración entre los equipos participantes estaba prevista para fines de febrero de 2026, con los scores publicados junto al rendimiento, la liveness y el costo en Ethproofs.

La razón por la que esto necesitaba una herramienta y no solo un requisito de divulgación es que los argumentos de seguridad de STARK frecuentemente se parametrizan contra conjeturas. Quien diseña un sistema de prueba elige parámetros que entregarían un nivel de seguridad objetivo si una conjetura particular sobre el comportamiento del código subyacente o el esquema de commitment se cumple, publica ese objetivo, y el número entra en circulación. La brecha entre "seguro bajo la conjetura C" y "seguro" es invisible en una afirmación de una línea sobre 100 bits.

Según el post de diciembre, al menos una de esas conjeturas fundacionales ha sido refutada matemáticamente. La consecuencia no es académica. Un sistema que anuncia 100 bits bajo la conjetura refutada puede estar proveyendo algo más cercano a 80 bits cuando se califica contra lo que realmente está demostrado. Ochenta bits de soundness no son inmediatamente quebrables por un atacante motivado con una GPU, pero es el número equivocado para asegurar una capa de settlement, y es el número equivocado para descubrir después de hacer la afirmación en lugar de antes.

La hoja de ruta que sigue es específica. Para el fork Glamsterdam, previsto para fines de mayo de 2026, los zkVMs participantes deberían alcanzar 100 bits de seguridad demostrable con pruebas de no más de 600 KiB. Para fines de 2026, bajo la etiqueta H-star, el objetivo es 128 bits con pruebas de menos de 300 KiB y un argumento formal de soundness que las acompañe.

Esos dos objetivos tiran en direcciones opuestas. El margen de seguridad en un STARK proviene sustancialmente de la repetición, y la repetición infla la prueba. Pasar de 100 bits a 600 KiB a 128 bits a 300 KiB significa mejorar la seguridad por byte de la construcción misma, razón por la cual el post apunta a maquinaria más nueva: WHIR como esquema de commitment, JaggedPCS, y arquitecturas de recursión reestructuradas que cambian cuántas capas de compresión de prueba se ubican entre la traza de ejecución y el objeto final que descarga un validador. Son líneas de investigación activas con riesgo de etapa de investigación asociado, y el cronograma asume que van a funcionar.

### Lo que un conteo de bits no cubre

Las fuentes que describen soundcalc especifican qué estima y no qué omite, y la lista de omisiones es donde históricamente se ha producido el daño real en este campo.

Un score de soundness derivado de cotas criptográficas y parámetros del sistema de prueba es una afirmación sobre el protocolo en el papel. Dice que un atacante que no puede romper los supuestos de dureza subyacentes no puede falsificar una prueba para una afirmación falsa con probabilidad mejor que cierta cota. No dice, según ninguna lectura que sustenten las fuentes disponibles, si el circuito codifica fielmente la semántica del EVM, si algún sistema de restricciones está sub-restringido de modo que witnesses inválidos lo satisfacen, si el generador de witnesses produce valores que las restricciones no logran fijar, o si el compilador que traduce una descripción de circuito de alto nivel a restricciones introduce una divergencia.

Esas son las clases de bugs que han producido incidentes reales de zkEVM. Un sistema puede tener un argumento de soundness de 128 bits matemáticamente impecable y aún así aceptar una prueba falsificada porque el conjunto de restricciones de un opcode permite un valor que debería prohibir. El post de julio de la Foundation reconoce el requisito más amplio, listando verificación formal, auditorías y bug bounties como necesarios con el tiempo, lo que implica que no considera el conteo de bits suficiente. Pero el scoreboard público va a mostrar un número en bits, y un número en un dashboard tiende a convertirse en lo que la gente cita.

No pudimos determinar a partir de las fuentes disponibles si el alcance de soundcalc está pensado para extenderse a la corrección a nivel de implementación o si una pista de verificación separada la cubre. Esa brecha vale la pena resolverla antes de que los scores se conviertan en el criterio de habilitación para una transición de fase.

## EXECUTE y el camino de los rollups nativos

*[Figure: img4]*

El tercer hilo de este programa es una propuesta de diseño más que un sistema ya desplegado. El post de native rollups de Justin Drake, publicado en ethresear.ch en enero de 2025, describe un precompile `EXECUTE` que expondría la verificación de ejecución de L1 como una primitiva que cualquier contrato puede invocar.

El precompile toma una raíz de pre-estado, una raíz de post-estado, una traza de transacciones y una cantidad de gas, y devuelve si ejecutar esa traza contra el pre-estado produce el post-estado dentro del límite de gas. Cómo se convence un validador de esa respuesta queda deliberadamente sin especificar a nivel de consenso. Un validador puede reejecutar la traza directamente, o puede verificar un SNARK que demuestre la misma afirmación. Ningún sistema de prueba queda enshrined. Los operadores de staking eligen su propio cliente verificador zkEL de la misma forma en que hoy eligen un cliente de ejecución, como una decisión local subjetiva y no como una constante del protocolo.

La contabilidad de gas está diseñada para que la primitiva sea medible. Una llamada cuesta un `EXECUTE_GAS_COST` fijo más el gas usado por la ejecución interna multiplicado por un precio medido al estilo EIP-1559 específico para `EXECUTE`, con un límite y un objetivo acumulado separados para todas esas llamadas en un bloque. El gas se cobra en su totalidad incluso cuando la llamada devuelve falso, lo que elimina el vector obvio de griefing de enviar trazas inválidas a bajo costo.

Un **rollup nativo** es entonces un contrato que envuelve `EXECUTE` en una función de derivación: la lógica que maneja secuenciación, bridging, inclusión forzada y gobernanza. La corrección de la transición de estado del rollup ya no es algo que el rollup se demuestra a sí mismo. Es algo que los validadores de L1 verifican como parte de validar el bloque de L1. Lo que esto elimina de la superficie de ataque del rollup es considerable: ningún circuito SNARK a medida que se pueda hacer mal, ningún juego de fraud proof con sus ventanas de desafío y supuestos de bonding, y ningún security council que sostenga llaves de upgrade como respaldo ante bugs en ninguno de los dos. El rollup se mantiene EVM-equivalente por construcción, y hereda los hard forks de L1 automáticamente, ya que la semántica que `EXECUTE` hace cumplir es la que sea que signifique la ejecución de L1 en ese momento.

La mecánica de timing es la parte delicada. La propuesta esboza una ejecución diferida de un slot, dando a los provers un slot completo para producir pruebas del bloque n mientras se construye el bloque n+1, con los attesters condicionando su attestation del bloque n+1 a que las pruebas del bloque n estén disponibles. Las penalizaciones por slots perdidos se ilustran en torno a 1 ETH. La liveness de los light clients descansa en un supuesto de prover minoritario altruista, lo que significa que el diseño espera que al menos algunos provers produzcan pruebas incluso cuando la economía marginal es ajustada.

El post de Drake también señala que un rollup nativo optimista podría correr un límite de gas muy por encima de `EXECUTE_CUMULATIVE_GAS_LIMIT`, porque en el caso optimista `EXECUTE` solo se invoca para resolver un desafío sobre un segmento disputado pequeño en lugar de verificar cada bloque. Eso importa para el throughput: el costo del camino ZK está acotado por lo que L1 está dispuesto a medir, mientras que el camino optimista usa `EXECUTE` como oráculo de settlement y paga por él solo bajo disputa.

Nada de esto se ha desplegado. El post es un boceto de diseño de enero de 2025 con parámetros ilustrativos, y los tamaños de penalización, la estructura de retraso y las constantes de gas son placeholders. Se menciona en discusiones sobre esta hoja de ruta una demostración de prueba de concepto ocurrida en marzo de 2026; las fuentes disponibles aquí no documentan su alcance ni su resultado, y la tratamos como no verificada. Una demostración funcional de un precompile está lejos de la integración en consenso, la calibración del mercado de fees, y un ecosistema de clientes capaz de verificar las pruebas resultantes dentro de un slot.

## Lo que queda del stack de L2

Si los rollups nativos llegan a producción, lo que vuelven obsoleto es una capa específica del stack de rollups y no los rollups como categoría.

Lo que desaparece es el aparato de seguridad a medida. Un rollup que enruta sus transiciones de estado a través de `EXECUTE` no necesita mantener su propio prover, su propio circuito, su propio contrato verificador, ni la estructura de gobernanza que existe para parchear esas cosas cuando se rompen. El security council, que en la práctica es la respuesta honesta a "qué pasa cuando el sistema de prueba tiene un bug", pierde su razón de sostener llaves. Para equipos cuya diferenciación es equivalencia con el EVM más fees más bajos, eso es la mayor parte del presupuesto de ingeniería y la mayor parte del supuesto de confianza que hoy le piden aceptar a los usuarios.

Lo que no desaparece es todo lo que está por encima de la función de transición de estado. Alguien sigue ordenando transacciones, y los derechos de secuenciación siguen siendo la principal fuente de ingresos para la mayoría de los rollups hoy. Alguien sigue publicando datos, y los fees de blobs siguen siendo un costo real que `EXECUTE` no reduce en nada. La función de derivación todavía tiene que manejar correctamente la inclusión forzada, que es donde en realidad vive la resistencia a la censura de un rollup, y hacerlo mal sigue siendo una forma de perder fondos de usuarios. La lógica de bridging todavía hay que escribirla y todavía tiene que estar correcta.

Y los rollups nativos son EVM-equivalentes por definición, lo cual acota a quién sirven. Un rollup que corre una máquina virtual no-EVM, un esquema de gas modificado, abstracción de cuentas nativa con semántica alterada, o cualquier otra cosa que diverja de la ejecución de L1 no puede enrutar a través de un precompile que hace cumplir la ejecución de L1. Para esos sistemas, `EXECUTE` no es un camino de upgrade. Es un competidor con una mejor historia de seguridad en el segmento donde ambos se superponen.

La postura honesta sobre los tokens de gobernanza de L2 es que las fuentes que sustentan este análisis no contienen datos de mercado, de gobernanza o de token-economics, y cualquier afirmación sobre consecuencias de valuación sería invención. Lo que puede decirse estructuralmente es más acotado: un token de gobernanza cuya función principal es nombrar y limitar a un security council es una reclamación sobre un proceso de toma de decisiones, y los rollups nativos están diseñados para eliminar las decisiones para las que ese proceso existe. Los tokens cuya función es derechos de secuenciación, captura de fees o coordinación de ecosistema están vinculados a funciones que `EXECUTE` no toca. La distinción entre esos dos casos es lo que hay que mirar, y es específica de cada stack y no general a la categoría.

La migración tampoco es gratuita. Un rollup en producción con miles de millones en activos bridgeados que se mueve a un nuevo camino de verificación de transición de estado está ejecutando un upgrade de bridge, que es la operación de mayor riesgo en el negocio. Los equipos se van a mover cuando la alternativa sea vergonzosa, no cuando el diseño sea elegante.

## Concentración del proving y el validador doméstico

*[Figure: img5]*

El argumento de resistencia a la censura del post de julio de 2025 depende de que el proving doméstico se mantenga viable, razón por la cual existen los objetivos de $100,000 y 10 kW. Un mercado de proving al que solo pueden entrar operadores industriales es un mercado donde un número reducido de partes puede negarse a probar un bloque, y bajo proving obligatorio eso se convierte en un veto.

Vale la pena separar dos roles que se suelen confundir. Verificar es barato: un validador stateless que comprueba tres pruebas no necesita un clúster de GPU, y la carga de hardware sobre un validador doméstico bajo validación stateless es posiblemente menor que hoy, ya que mantener el estado completo y reejecutar es la parte costosa. El proving es donde se concentra el riesgo. Las cifras de costo actuales, entre un tercio y seis décimas de centavo por prueba, se logran en clústeres de cuatro a dieciséis GPUs de gama alta. Eso es alcanzable para un individuo bien capitalizado y trivialmente alcanzable para una firma, pero no es una laptop, y el número de sub-centavo por prueba solo impresiona dado el capital que hay detrás.

La composición de la cohorte refuerza el punto. Tres provers elegibles de diez evaluados no es un mercado; es un grupo de investigación. Si esa proporción refleja una fase de arranque donde siete equipos están a mitad de optimización, o un resultado estructural donde el proving tiene economías de escala que expulsan a los operadores pequeños, no es algo que se pueda responder a partir de una instantánea puntual. Ambas lecturas son consistentes con los datos. La cadena de suministro de hardware, la exposición al costo de electricidad y la distribución geográfica de los operadores que sí califican no están rastreadas en ningún lugar que hayamos podido encontrar.

La misma incertidumbre aplica al argumento del límite de gas, que es el beneficio concreto más visible para el usuario que se ofrece. El plan sube el límite de gas de L1 una vez que una supermayoría del stake corre clientes ZK con comodidad. Si la validación stateless realmente desacopla el costo del validador del límite de gas, eso es una ganancia grande y duradera. Pero la propuesta asume que la capacidad de proving escala con el límite de gas a un costo tolerable, y el costo de proving sí escala con el cómputo que se está probando. Un aumento 10x en el límite de gas es una traza 10x más grande para probar dentro del mismo slot. Las cifras de costo actuales corresponden a bloques en el límite de gas de hoy.

## Lo que tendría que volverse observable

El sprint de rendimiento produjo números que un tercero puede verificar en un dashboard público, lo cual es más de lo que ofrecen la mayoría de las hojas de ruta de infraestructura. El sprint de seguridad es más difícil de auditar desde afuera, porque un score de seguridad demostrable es una afirmación sobre una prueba cuya corrección la mayoría de los lectores no puede evaluar, y porque las clases de bugs más peligrosas son las que el score aparentemente no cubre.

Unas pocas cosas moverían la credibilidad de este programa más que otra mejora de latencia.

- Scores de soundcalc por prover publicados en Ethproofs, con las conjeturas de las que depende y de las que no depende cada sistema declaradas explícitamente, de modo que un lector pueda saber si tres provers elegibles representan tres modos de falla independientes o uno solo.
- La tasa de offline entre los slots rastreados bajando del \~26% actual hacia algo que sobreviva al proving obligatorio, donde una prueba faltante sea relevante para el consenso y no un hueco en un dashboard.
- Un umbral numérico y publicado para cada transición de fase. La secuencia de proving diferido a proving obligatorio a pruebas enshrined hoy se describe con nombres de fase y no con la proporción de stake, el número de implementaciones verificadas independientes, o la cifra de confiabilidad sostenida requerida para avanzar.
- Una respuesta a qué pasa después de una falla de soundness en un sistema enshrined. Si una prueba falsificada acuña tokens y el consenso la acepta, el camino de recuperación es un fork a nivel de capa social, que es la misma respuesta que Ethereum siempre ha tenido y una mucho menos cómoda cuando el disparador es un bug criptográfico en lugar de un exploit visible.

Los hitos de 2026, integración de soundcalc para febrero, 100 bits a 600 KiB para Glamsterdam en mayo, 128 bits a 300 KiB con un argumento formal de soundness para fin de año, son objetivos que la Foundation se fijó a sí misma, y que el indicador de fase de Ethproofs siga mostrando el sprint de seguridad como actual es la única señal de estado independiente disponible aquí. Si esas fechas se cumplieron no es algo que establezcan las fuentes que sustentan este análisis.

Lo que sí está establecido es el orden de dificultad. Pasar de dieciséis minutos a dieciséis segundos tomó dieciocho meses de ingeniería enfocada por equipos con métricas claras y una tabla de posiciones pública. Pasar de 100 bits conjeturados a 128 demostrados requiere que nueva criptografía funcione, que nuevos sistemas de restricciones sean correctos, y que un estándar de medición cubra los bugs que históricamente han causado las fallas en lugar de los que son más fáciles de cuantificar.

## Referencias

- [Shipping an L1 zkEVM #1: Realtime Proving](https://blog.ethereum.org/en/2025/07/10/realtime-proving), Ethereum Foundation, julio de 2025
- [Shipping an L1 zkEVM #2: The Security Foundations](https://blog.ethereum.org/2025/12/18/zkevm-security-foundations), Ethereum Foundation, diciembre de 2025
- [Ethproofs](https://ethproofs.org/), tracker público de provers
- [Native rollups: superpowers from L1 execution](https://ethresear.ch/t/native-rollups-superpowers-from-l1-execution/21517), Justin Drake, ethresear.ch, enero de 2025