Vitalik reconoce los puntos débiles de Ethereum contra la cuántica 

Vitalik Buterin expuso los cuatro componentes de Ethereum que considera potencialmente vulnerables frente a la computación cuántica: el sistema de consenso, la disponibilidad de datos, las firmas digitales de las cuentas externas (EOA) y las pruebas de conocimiento cero (ZK) utilizadas en la capa de aplicación. 

El cofundador de la red explicó que esos cuatro aspectos de la red están protegidos por esquemas criptográficos basados en problemas matemáticos que una computadora cuántica suficientemente avanzada podría resolver con mayor facilidad que los sistemas clásicos. 

Ante esta situación, Buterin, quien viene advirtiendo que la amenaza cuántica podría llegar en 2028, compartió en su publicación del 26 de febrero cuatro propuestas para alcanzar la resistencia cuántica, tomando en cuenta los cuatro componentes. 

Las propuestas de Vitalik coincidieron con la hoja de ruta que presentó la Fundación Ethereum (EF). Tal como reportó Criptonoticias, la misma contempla siete bifurcaciones duras (hard forks) hasta el año 2029, con el fin de proteger a Ethereum de la computación cuántica. 

De esta forma, se planean cambios bajo la premisa de que la amenaza cuántica es una realidad que está más cerca de lo que se cree. Por tanto, la explicación de Buterin se centra en los cuatro problemas detectados y sus posibles soluciones, los cuales se exponen a continuación.

1. Consenso: reemplazar la criptografía de clave pública 

El consenso de Ethereum utiliza firmas BLS (por los investigadores Boneh–Lynn–Shacham). Se trata de un tipo de criptografía de clave pública. Este esquema permite a Ethereum agregar muchas firmas en una sola, lo que reduce datos y mejora eficiencia cuando miles de validadores confirman bloques. 

El problema es que BLS se basa en criptografía de curvas elípticas (ECC) y este tipo de criptografía sería vulnerable a un algoritmo cuántico como el de Shor. 

Buterin propone reemplazar las firmas BLS por firmas basadas en funciones hash como Winternitz, consideradas resistentes a la computación cuántica. Estas no dependen de curvas elípticas, pero generan firmas mucho más grandes. 

Para evitar que el tamaño de los bloques se dispare, plantea combinar funciones hash con STARK (Argumentos de Conocimiento Transparentes y Escalables). Un tipo de criptografía que permite demostrar en una sola prueba que muchas firmas son válidas. 

Buterin advierte además que la elección de la función hash será crítica, ya que podría convertirse en el estándar definitivo de Ethereum en un escenario poscuántico. 

2. Disponibilidad de datos: abandonar compromisos KZG 

La red Ethereum emplea compromisos KZG (Kate–Zaverucha–Goldberg). Este mecanismo permite comprometer criptográficamente a un conjunto de datos y luego probar que una parte de esos datos pertenece al conjunto original. Esto,  sin revelar todo el contenido. 

KZG es fundamental para la “disponibilidad de datos”, es decir, garantizar que la información publicada en bloques realmente existe y puede reconstruirse. El problema es que también se basa en criptografía vulnerable a la cuántica. 

Buterin propone reemplazar KZG con pruebas STARK. A diferencia de KZG, los STARK no dependen de configuraciones de confianza inicial ni de curvas elípticas vulnerables. 

Pero presentan desafíos: las pruebas son más grandes y el proceso de generación es más costoso. Buterin reconoce que el problema es manejable, pero requiere una gran cantidad de trabajo de ingeniería. 

3. Sustituir ECDSA para impedir que se deriven claves privadas

Las cuentas externas (EOA) en Ethereum firman transacciones mediante el algoritmo ECDSA (Algoritmo de Firma Digital de Curva Elíptica). Este mismo tipo de criptografía es utilizado en Bitcoin. 

ECDSA sería vulnerable a una computadora cuántica capaz de ejecutar el algoritmo de Shor, lo que permitiría derivar la clave privada a partir de la pública. En términos simples, si alguien pudiera romper ECDSA, podría firmar transacciones en nombre de cualquier usuario. 

La solución propuesta por Buterin es introducir abstracción de cuentas (Account Abstraction, AA) de forma nativa en el protocolo. Tal hecho permite que las cuentas utilicen cualquier algoritmo de firma, incluyendo opciones resistentes a la cuántica, como firmas basadas en hash o en retículas (lattice-based cryptography). 

El obstáculo es el costo. Según Vitalik, verificar una firma ECDSA cuesta alrededor de 3.000 unidades de gas, mientras que una firma resistente a la cuántica puede costar cerca de 200.000 unidades de gas o más.  

Para reducir ese impacto, Buterin plantea dos vías complementarias:

• Añadir optimizaciones matemáticas directamente en el protocolo (mediante precompilados que hagan más eficiente la verificación de firmas poscuánticas). 

• Aplicar agregación recursiva (EIP-8141), es decir, reemplazar múltiples verificaciones individuales por una única prueba criptográfica que certifique que todas son válidas. 

4. Pruebas ZK: comprimir la verificación 

Un problema similar ocurre con las pruebas de conocimiento cero (ZK), teóricamente vulnerables ante un ordenador cuántico. 

Muchas aplicaciones en Ethereum utilizan esas pruebas ZK. Según Buterin se utiliza especialmente el esquema Groth16 para demostrar que algo es cierto sin revelar la información subyacente.  

El cofundador de red propone integrar agregación recursiva (mediante EIP-8141) a nivel de protocolo: en lugar de verificar cada prueba individual en la cadena, se generaría una única prueba que certifique que todas las verificaciones fueron correctas. 

Este mecanismo permitiría que bloques que contengan múltiples pruebas grandes no tengan que publicar ni verificar cada una directamente en Ethereum. En su lugar, solo se validaría una prueba compacta que resume todo el proceso.  

Según Buterin, esta arquitectura es clave para que Ethereum pueda usar criptografía resistente a la cuántica sin sacrificar escalabilidad. 

Las propuestas de Buterin no constituyen aún cambios formales en el protocolo, sino lineamientos técnicos que ahora deberán ser debatidos por la comunidad de Ethereum. Su eventual implementación dependerá del consenso entre desarrolladores, validadores y la propia Fundación Ethereum, en coordinación con la hoja de ruta de actualizaciones prevista para los próximos años.