La Ethereum Foundation prioriza la seguridad sobre la velocidad y establece una estricta regla de 128 bits para 2026

El ecosistema zkEVM pasó un año corriendo para reducir la latencia. El tiempo de prueba para un bloque de Ethereum se redujo de 16 minutos a 16 segundos, los costos bajaron 45 veces y los zkVMs participantes ahora prueban el 99% de los bloques de mainnet en menos de 10 segundos en el hardware objetivo.

La Ethereum Foundation (EF) declaró la victoria el 18 de diciembre: la prueba en tiempo real funciona. Los cuellos de botella de rendimiento han sido eliminados. Ahora comienza el verdadero trabajo, porque la velocidad sin solidez es una responsabilidad, no un activo, y las matemáticas detrás de muchos zkEVMs basados en STARK han estado fallando silenciosamente durante meses.

En julio, la EF estableció un objetivo formal para la “prueba en tiempo real” que incluía latencia, hardware, energía, apertura y seguridad: probar al menos el 99% de los bloques de mainnet en menos de 10 segundos, en hardware que cuesta aproximadamente $100,000 y funciona dentro de los 10 kilovatios, con código completamente open-source, con seguridad de 128 bits y con tamaños de prueba de 300 kilobytes o menos.

La publicación del 18 de diciembre afirma que el ecosistema alcanzó el objetivo de rendimiento, según lo medido en el sitio de benchmarking EthProofs.

En este contexto, “tiempo real” se define en relación con el tiempo de slot de 12 segundos y aproximadamente 1,5 segundos para la propagación del bloque. El estándar es esencialmente “las pruebas están listas lo suficientemente rápido como para que los validadores puedan verificarlas sin romper la vivacidad”.

La EF ahora pivota del rendimiento a la solidez, y el cambio es contundente. Muchos zkEVMs basados en STARK han dependido de conjeturas matemáticas no probadas para lograr los niveles de seguridad anunciados.

En los últimos meses, algunas de esas conjeturas, especialmente las suposiciones de “proximity gap” utilizadas en las pruebas de bajo grado de SNARK y STARK basadas en hash, han sido matemáticamente rotas, reduciendo la seguridad efectiva en bits de los conjuntos de parámetros que dependían de ellas.

La EF dice que el único final aceptable para el uso en L1 es la “seguridad demostrable”, no la “seguridad asumiendo que la conjetura X se mantiene”.

Establecieron la seguridad de 128 bits como objetivo, alineándola con los organismos de estándares de criptografía convencionales y la literatura académica sobre sistemas de larga duración, así como con cálculos récord del mundo real que muestran que 128 bits están realmente fuera del alcance de los atacantes.

El énfasis en la solidez sobre la velocidad refleja una diferencia cualitativa.

Si alguien puede falsificar una prueba zkEVM, puede acuñar tokens arbitrarios o reescribir el estado de L1 y hacer que el sistema mienta, no solo drenar un contrato.

Eso justifica lo que la EF llama un margen de seguridad “no negociable” para cualquier zkEVM de L1.

Hoja de ruta de tres hitos

La publicación presenta una hoja de ruta clara con tres paradas obligatorias. Primero, para finales de febrero de 2026, cada equipo de zkEVM en la carrera conecta su sistema de pruebas y circuitos a “soundcalc”, una herramienta mantenida por la EF que calcula estimaciones de seguridad basadas en los límites criptoanalíticos actuales y los parámetros del esquema.

La historia aquí es “regla común”. En lugar de que cada equipo cite su propia seguridad en bits con suposiciones personalizadas, soundcalc se convierte en la calculadora canónica y puede actualizarse a medida que surgen nuevos ataques.

Segundo, “Glamsterdam” para finales de mayo de 2026 exige al menos 100 bits de seguridad demostrable a través de soundcalc, pruebas finales de 600 kilobytes o menos y una explicación pública y concisa de la arquitectura de recursión de cada equipo con un esquema de por qué debería ser sólida.

Eso retrocede silenciosamente el requisito original de 128 bits para el despliegue temprano y trata los 100 bits como un objetivo interino.

Tercero, “H-star” para finales de 2026 es el listón completo: 128 bits de seguridad demostrable por soundcalc, pruebas de 300 kilobytes o menos, más un argumento formal de seguridad para la topología de recursión. Ahí es donde esto se vuelve menos ingeniería y más métodos formales y pruebas criptográficas.

Palancas técnicas

La EF señala varias herramientas concretas destinadas a hacer viable el objetivo de 128 bits y menos de 300 kilobytes. Destacan WHIR, una nueva prueba de proximidad Reed-Solomon que también funciona como un esquema de compromiso polinómico multilineal.

WHIR ofrece seguridad transparente y post-cuántica y produce pruebas más pequeñas y verificaciones más rápidas que los esquemas antiguos tipo FRI en el mismo nivel de seguridad.

Los benchmarks a 128 bits de seguridad muestran pruebas aproximadamente 1,95 veces más pequeñas y verificaciones varias veces más rápidas que las construcciones base.

Hacen referencia a “JaggedPCS”, un conjunto de técnicas para evitar el relleno excesivo al codificar trazas como polinomios, lo que permite a los probadores evitar trabajo desperdiciado mientras siguen produciendo compromisos sucintos.

Mencionan el “grinding”, que es la búsqueda por fuerza bruta sobre la aleatoriedad del protocolo para encontrar pruebas más baratas o pequeñas manteniéndose dentro de los límites de solidez, y la “topología de recursión bien estructurada”, es decir, esquemas en capas en los que muchas pruebas pequeñas se agregan en una sola prueba final con solidez cuidadosamente argumentada.

Se están utilizando matemáticas polinómicas exóticas y trucos de recursión para reducir el tamaño de las pruebas después de aumentar la seguridad a 128 bits.

Trabajos independientes como Whirlaway usan WHIR para construir STARKs multilineales con mayor eficiencia, y se están construyendo construcciones de compromiso polinómico más experimentales a partir de esquemas de disponibilidad de datos.

Las matemáticas avanzan rápido, pero también se alejan de suposiciones que parecían seguras hace seis meses.

Qué cambia y las preguntas abiertas

Si las pruebas están consistentemente listas en menos de 10 segundos y se mantienen por debajo de los 300 kilobytes, Ethereum puede aumentar el límite de gas sin obligar a los validadores a reejecutar cada transacción.

En su lugar, los validadores verificarían una pequeña prueba, permitiendo que la capacidad de los bloques crezca mientras se mantiene el staking doméstico como una opción realista. Por eso la publicación anterior de la EF sobre tiempo real vinculaba explícitamente la latencia y la energía a presupuestos de “prueba en casa” como 10 kilovatios y equipos de menos de $100,000.

La combinación de grandes márgenes de seguridad y pruebas pequeñas es lo que hace que un “L1 zkEVM” sea una capa de liquidación creíble. Si esas pruebas son rápidas y demostrablemente seguras a 128 bits, los L2 y zk-rollups pueden reutilizar la misma maquinaria mediante precompilados, y la distinción entre “rollup” y “ejecución L1” se convierte más en una elección de configuración que en una frontera rígida.

La prueba en tiempo real es actualmente un benchmark off-chain, no una realidad on-chain. Los números de latencia y costo provienen de las configuraciones y cargas de trabajo de hardware seleccionadas por EthProofs.

Todavía hay una brecha entre eso y miles de validadores independientes ejecutando realmente estos probadores en casa. La historia de la seguridad está en evolución. Toda la razón de la existencia de soundcalc es que los parámetros de seguridad de STARK y SNARK basados en hash siguen cambiando a medida que se refutan conjeturas.

Resultados recientes han redefinido la línea entre los regímenes de parámetros “definitivamente seguros”, “conjeturalmente seguros” y “definitivamente inseguros”, lo que significa que las configuraciones “de 100 bits” de hoy pueden ser revisadas nuevamente a medida que surgen nuevos ataques.

No está claro si todos los equipos principales de zkEVM realmente alcanzarán la seguridad demostrable de 100 bits para mayo de 2026 y de 128 bits para diciembre de 2026 manteniéndose dentro de los límites de tamaño de prueba, o si algunos aceptarán silenciosamente márgenes menores, dependerán de suposiciones más pesadas o trasladarán la verificación off-chain por más tiempo.

La parte más difícil puede no ser las matemáticas o las GPUs, sino formalizar y auditar las arquitecturas de recursión completas.

La EF admite que diferentes zkEVMs a menudo componen muchos circuitos con un considerable “código de pegamento” entre ellos, y que documentar y probar la solidez de esas pilas personalizadas es esencial.

Eso abre una larga cola de trabajo para proyectos como Verified-zkEVM y marcos de verificación formal, que aún están en etapas tempranas y desiguales entre ecosistemas.

Hace un año, la pregunta era si los zkEVMs podían probar lo suficientemente rápido. Esa pregunta ya tiene respuesta.
La nueva pregunta es si pueden probar con suficiente solidez, a un nivel de seguridad que no dependa de conjeturas que puedan romperse mañana, con pruebas lo suficientemente pequeñas como para propagarse a través de la red P2P de Ethereum, y con arquitecturas de recursión verificadas formalmente para respaldar cientos de miles de millones de dólares.

La carrera por el rendimiento ha terminado. La carrera por la seguridad acaba de comenzar.

La publicación Ethereum Foundation refocuses to security over speed – sets strict 128-bit rule for 2026 apareció primero en CryptoSlate.