La Fundación Ethereum reorienta su enfoque hacia la seguridad por encima de la velocidad – establece una regla estricta de 128 bits para 2026

El ecosistema zkEVM pasó un año enfocándose en la latencia. El tiempo de prueba para un bloque de Ethereum se redujo de 16 minutos a 16 segundos, los costos cayeron 45 veces, y las 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 están despejados. Ahora comienza el trabajo real, porque la velocidad sin solidez es un pasivo, no un activo, y las matemáticas subyacentes en muchas zkEVMs basadas 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 10 segundos, en hardware que cuesta aproximadamente $100,000 y funciona dentro de 10 kilovatios, con código completamente de código abierto, 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 cumplió con el objetivo de rendimiento, según lo medido en el sitio de benchmarking EthProofs.

Tiempo real aquí se define en relación con el tiempo de ranura de 12 segundos y aproximadamente 1.5 segundos para la propagación de bloques. El estándar es esencialmente "las pruebas están listas lo suficientemente rápido como para que los validadores puedan verificarlas sin romper la disponibilidad."

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

Durante los últimos meses, algunas de esas conjeturas, especialmente las suposiciones de "brecha de proximidad" utilizadas en pruebas de bajo grado basadas en hash SNARK y STARK, se han roto matemáticamente, derribando la seguridad de bits efectiva de los conjuntos de parámetros que dependían de ellas.

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

Establecieron la seguridad de 128 bits como objetivo, alineándola con los principales organismos de estándares de criptomonedas y la literatura académica sobre sistemas de larga duración, así como con cálculos de registro del mundo real que muestran que 128 bits está 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 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 L1.

Hoja de ruta de tres hitos

La publicación presenta una hoja de ruta clara con tres paradas definitivas. Primero, para finales de febrero de 2026, cada equipo zkEVM en la carrera conecta su sistema de prueba y circuitos en "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 de 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 compacta de la arquitectura de recursión de cada equipo con un esbozo de por qué debería ser sólida.

Eso discretamente retrocede del requisito original de 128 bits para el despliegue temprano y trata 100 bits como un objetivo provisional.

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

Palancas técnicas

La EF señala varias herramientas concretas destinadas a hacer factible 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 de polinomios multilineales.

WHIR ofrece seguridad transparente y post-cuántica y produce pruebas que son más pequeñas y verificación más rápida que las de los esquemas antiguos estilo FRI al mismo nivel de seguridad.

Los benchmarks con seguridad de 128 bits muestran pruebas aproximadamente 1.95 veces más pequeñas y verificación varias veces más rápida que las construcciones de referencia.

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 producen compromisos sucintos.

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

Las matemáticas de polinomios exóticas y los trucos de recursión se están utilizando para reducir las pruebas después de aumentar la seguridad a 128 bits.

El trabajo independiente como Whirlaway usa WHIR para construir STARKs multilineales con eficiencia mejorada, y se están construyendo más construcciones experimentales de compromiso de polinomios a partir de esquemas de disponibilidad de datos.

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

Qué cambia y las preguntas abiertas

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

Los validadores en su lugar verificarían una pequeña prueba, permitiendo que la capacidad de bloques crezca mientras se mantiene realista el staking desde casa. Por eso la publicación anterior de tiempo real de la EF vinculó explícitamente la latencia y la potencia con presupuestos de "prueba desde 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 de 128 bits, las L2s y zk-rollups pueden reutilizar la misma maquinaria a través de precompilaciones, y la distinción entre "rollup" y "ejecución L1" se convierte más en una elección de configuración que en un límite rígido.

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

Todavía hay una brecha entre eso y miles de validadores independientes que realmente ejecutan estos probadores en casa. La historia de seguridad está en flujo. La razón completa por la que existe soundcalc es que los parámetros de seguridad STARK y SNARK basados en hash siguen cambiando a medida que se desmienten las conjeturas.

Los resultados recientes han redibujado la línea entre regímenes de parámetros "definitivamente seguros", "conjeturalmente seguros" y "definitivamente inseguros", lo que significa que la configuración actual de "100 bits" puede revisarse nuevamente a medida que surgen nuevos ataques.

No está claro si todos los equipos principales de zkEVM alcanzarán realmente la seguridad demostrable de 100 bits para mayo de 2026 y 128 bits para diciembre de 2026 mientras se mantienen por debajo de los límites de tamaño de prueba, o si algunos aceptarán silenciosamente márgenes más bajos, dependerán de suposiciones más pesadas o empujarán la verificación fuera de cadena 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 "código de pegamento" sustancial 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 son desiguales entre ecosistemas.

Hace un año, la pregunta era si las zkEVMs podían probar lo suficientemente rápido. Esa pregunta está respondida.
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 para propagarse a través de la red P2P de Ethereum, y con arquitecturas de recursión formalmente verificadas lo suficiente para anclar cientos de miles de millones de dólares.

El sprint de rendimiento ha terminado. La carrera de seguridad acaba de comenzar.

La publicación Ethereum Foundation se reenfoca en la seguridad sobre la velocidad – establece una regla estricta de 128 bits para 2026 apareció primero en CryptoSlate.