Ideas clave:
- Vitalik Buterin trazó cuatro riesgos cuánticos.
- Ethereum puede sustituir a BLS y KZG.
- La agregación recursiva STARK pretende reducir costes.
El cofundador de Ethereum, Vitalik Buterin, publicó una hoja de ruta sobre la resistencia cuántica el 26 de febrero, en la que esbozaba correcciones para cuatro componentes vulnerables de la red. Dijo que las firmas de consenso, la disponibilidad de datos, las cuentas de propiedad externa y las pruebas de conocimiento cero se enfrentaban a un riesgo cuántico a largo plazo.
La propuesta establecía un plan por fases para endurecer Ethereum antes de que surjan máquinas cuánticas a gran escala.
La computación cuántica ha pasado de la teoría a la investigación aplicada, lo que plantea interrogantes sobre la durabilidad criptográfica. Ethereum se basa en la curva elíptica y en la criptografía basada en el emparejamiento, que las máquinas actuales no pueden romper.
Sin embargo, Buterin argumentó que la preparación debe comenzar pronto porque los cambios de protocolo requieren coordinación, pruebas y actualizaciones de la red entre validadores y desarrolladores.
Las firmas consensuadas se enfrentan al desplazamiento de la función hash
Vitalik Buterin escribió en X que la capa de consenso de Ethereum depende actualmente de las firmas Boneh-Lynn-Shacham, que los algoritmos cuánticos podrían debilitar. Propuso sustituirlas por firmas basadas en hash con un diseño de consenso “Lean”.
Ese modelo agregaría firmas utilizando pruebas STARK para mantener la eficacia y eliminar al mismo tiempo la criptografía basada en el emparejamiento”.
El cofundador de Ethereum advirtió que la selección de la siguiente función hash conllevaba consecuencias a largo plazo. El hash convencional no cumplía los objetivos de rendimiento de Ethereum.
Poseidón2 se enfrentó a un reciente escrutinio académico, mientras que Poseidón1 evitó esas preocupaciones pero funcionó más lentamente. También propuso BLAKE3 como alternativa basada en la criptografía convencional.
El cambio reduciría la dependencia de construcciones algebraicas vulnerables al algoritmo de Shor. Sin embargo, requeriría actualizaciones coordinadas de los clientes y una cuidadosa planificación de la compatibilidad con versiones anteriores. Antes de la plena finalidad de Lean, sugirió un paso intermedio con menos firmas por ranura para aliviar la presión de la implementación.
Compromisos entre la disponibilidad de los datos y la seguridad de las cuentas
Buterin explicó que Ethereum utiliza actualmente compromisos Kate-Zaverucha-Goldberg para la verificación de datos blob. Esa estructura permitía la codificación de borrado y el muestreo bidimensional de disponibilidad de datos. Dijo que sustituirla por pruebas basadas en STARK era técnicamente factible, pero requeriría un importante esfuerzo de ingeniería.
El KZG ofrecía propiedades de linealidad que simplificaban la validación de manchas distribuidas. Los sistemas STARK carecían de esa característica, lo que complicaba modelos de escalado como el muestreo bidimensional. La hoja de ruta de Ethereum, por tanto, se inclinaba hacia la maximización del muestreo unidimensional en lugar de ampliar agresivamente el rendimiento.
En cuanto a las cuentas de usuario, Buterin señaló las firmas del Algoritmo de Firma Digital de Curva Elíptica (ECDSA) como otra posible exposición. Abogó por añadir una abstracción de cuenta nativa para que las cuentas pudieran adoptar algoritmos resistentes al quantum. Las firmas basadas en hash requerían aproximadamente 200.000 gas para su verificación según las estimaciones actuales, muy por encima de los costes actuales.
Las firmas basadas en celosías seguían siendo aún más pesadas computacionalmente. Sin embargo, hizo referencia a trabajos sobre precompilaciones matemáticas vectorizadas que podrían reducir sustancialmente el consumo de gas. La mitigación a largo plazo implicaba la agregación recursiva en la capa de protocolo, lo que permitiría comprimir la verificación de firmas en una sola prueba.
La Agregación Recursiva de Pruebas como Estrategia Central
Buterin escribió en Ethereum Research que las pruebas resistentes al quantum eran mucho más caras que los actuales argumentos sucintos no interactivos de conocimiento cero. Una verificación SNARK típica consume entre 300.000 y 500.000 gas, mientras que una verificación STARK podía alcanzar los 10 millones de gas. Ese perfil de costes hacía poco práctica la sustitución directa para los protocolos de privacidad y los sistemas de capa dos.
Su propuesta de solución se centraba en los marcos de validación introducidos en la Propuesta de Mejora 8141 de Ethereum. Las transacciones ejecutarían comprobaciones de firma dentro de marcos aislados a los que los contratos externos no podrían acceder. Los constructores de bloques o los participantes de la red podrían sustituir entonces esos marcos por un STARK recursivo, verificando todas las operaciones colectivamente.
En lugar de verificar cada prueba individualmente en la cadena, una única prueba agregada validaría miles simultáneamente. Sugirió que los nodos podrían generar pruebas en la capa mempool a intervalos fijos, reduciendo la sobrecarga de ancho de banda y evitando los bloques hinchados. Este diseño pretendía desplazar la computación pesada fuera de la cadena, preservando al mismo tiempo la verificación determinista.
El investigador de la Fundación Ethereum Justin Drake presentó anteriormente “Lean Ethereum” en agosto de 2025 como un marco para la seguridad cuántica. La hoja de ruta de Buterin se alineaba con esa dirección, pero la ampliaba a las cuentas y a las pruebas de la capa de aplicación. La propuesta, por tanto, unía el consenso, los datos y los cambios de ejecución en una transición de seguridad coordinada.
La hoja de ruta de Ethereum también hace referencia al trabajo de “Strawmap” en curso, cuyo objetivo es acortar los tiempos de ranura y reducir los retrasos en la finalidad. Buterin dijo que esperaba reducciones progresivas de la latencia de confirmación junto con mejoras criptográficas. Esa vinculación indicaba que el desarrollo del rendimiento y la seguridad se realizarían en paralelo y no secuencialmente.
El siguiente paso inmediato se centra en seleccionar una función hash y desplegar una abstracción de cuenta temprana. Es probable que los desarrolladores debatan las ventajas y desventajas en los próximos debates de la Propuesta de Mejora de Ethereum. La hoja de ruta no asignaba una fecha fija de activación, pero los experimentos de la capa de protocolo podrían salir a la luz durante el próximo ciclo de mejora.
