-
EIP-8288 busca llevar transacciones poscuánticas de 10 millones de gas a decenas de miles.
-
La propuesta agrupa firmas y pruebas STARK fuera de la ejecución principal de Ethereum.
Vitalik Buterin propuso EIP-8288 para resolver un problema puntual: el costo prohibitivo de las firmas resistentes a computación cuántica. Pero la lectura técnica de la propuesta apunta a algo más amplio que ese objetivo declarado.
Lo que EIP-8288 dibuja, en el fondo, es una capa de verificación agnóstica al algoritmo criptográfico que usen las aplicaciones de Ethereum.
El punto de partida es concreto. Buterin calculó que una transacción privada resistente a la computación cuántica puede llegar a costar hoy 10 millones de unidades de gas, frente a los 300.000 de una transacción privada convencional. EIP-8288 buscaría reducir ambos casos a decenas de miles de unidades.
Ese ahorro no vendría de comprimir la criptografía en sí, sino de moverla de lugar. En lugar de que cada nodo verifique individualmente cada firma o cada prueba, las transacciones declararían dependencias de apenas 96 bytes, que la mempool agruparía en una sola prueba STARK recursiva antes de que llegue al bloque.
Ahí está la tesis que conviene sostener con cuidado: el problema que Buterin dice resolver es la resistencia cuántica, pero el mecanismo que propone no está diseñado exclusivamente para eso. Es una arquitectura de verificación que podría absorber cualquier esquema criptográfico futuro sin que el protocolo base tenga que aprenderlo primero.
Un protocolo que deja de necesitar conocer el algoritmo
Hoy, si una aplicación quiere adoptar SPHINCS+, ML-DSA, Falcon o cualquier otro esquema de firma poscuántica, ese soporte tiene que integrarse en el protocolo base o pasar por una capa intermedia costosa en gas, para que pueda funcionar para cualquier transacción en la red.
Con EIP-8288, esa firma podría presentarse simplemente como una dependencia declarada, y la validez de esa dependencia quedaría cubierta por la prueba STARK agregada que ya generó la mempool. El protocolo no necesitaría ejecutar ni conocer el algoritmo subyacente, solo confiar en que la prueba compacta que recibe es válida. En lugar de procesarla, solo confía en la prueba.
Esa es la diferencia entre «Ethereum soporta la criptografía X» y «Ethereum verifica que alguien demostró correctamente algo, sin que le importe qué método usó para demostrarlo». La segunda es una capa mucho más difícil de volver obsoleta.
Para que esto funcione, Buterin también contempla usar RISC-V, un estándar abierto de instrucciones para procesadores, como lenguaje común con el que expresar y verificar cálculos dentro de la red. Esa pieza encaja con Lean Ethereum, la hoja de ruta de tres o cuatro años que busca poner las pruebas STARK recursivas en el centro de la arquitectura de la red.
Lo que gana el protocolo, resumido
| Modelo actual | Con EIP-8288 | |
|---|---|---|
| Costo de firma poscuántica | Hasta 200.000 gas por verificación | Verificación agregada, fracción del costo |
| Costo de transacción privada+cuántica | Hasta 10 millones de gas | Decenas de miles de gas |
| Soporte de nuevo esquema criptográfico | Requiere cambio de protocolo | Se declara como dependencia externa |
| Quién verifica el algoritmo | Cada nodo, directamente | Prueba STARK compacta, agregada |
La tabla deja ver el patrón: en cada fila, lo que cambia no es solo el costo, sino quién hace el trabajo y dónde. Esa es la conclusión que no está explícita en el anuncio de Buterin, pero que se desprende de la mecánica que propone.
El costo no desaparece, cambia de dueño
Aquí está el matiz que equilibra la tesis. Sacar la criptografía pesada del camino principal de Ethereum no la elimina: la traslada a quien construye el bloque.
Generar una prueba STARK recursiva que agregue decenas o cientos de dependencias exige capacidad de cómputo real. Ese trabajo recaería sobre los participantes de la mempool y sobre los clientes que ensamblan bloques, no sobre cada nodo que valida.
Esto introduce una pregunta que el propio diseño no resuelve todavía: si generar la prueba agregada requiere infraestructura especializada, ¿ese requisito termina concentrando esa función en pocos actores capaces de correrla? La respuesta no está en el EIP, y es el límite más serio que enfrenta la propuesta.
Es una tensión que Bitcoin conoce bien. Cada vez que un sistema descentralizado saca trabajo pesado de la capa base para bajar costos, ese trabajo reaparece en otro punto de la cadena de producción, y ese punto se vuelve, por definición, más fácil de centralizar que un protocolo abierto a cualquier nodo.
Todavía no hay fecha, y eso importa
EIP-8288 depende de Frames, otra propuesta que modificaría el modelo de transacciones de Ethereum, y ambas podrían entrar en discusión para I-star, la actualización posterior a Hegota. Ninguna tiene fork asignado formalmente.
Esa falta de calendario no es un detalle menor para la tesis. Una capa de verificación universal solo cumple su promesa si sobrevive el escrutinio técnico y la implementación real, no en el papel de un EIP en discusión.
Ethereum ha mostrado antes que sus hojas de ruta más ambiciosas —Verkle trees, state expiry— pueden reescribirse o descartarse antes de llegar a producción. EIP-8288 corre el mismo riesgo, y su dependencia de Frames añade una capa adicional de incertidumbre.
Lo que queda planteado
EIP-8288 no resuelve el problema cuántico solamente: propone una forma distinta de relacionarse con toda la criptografía futura. Si funciona, Ethereum podría dejar de rediseñar su capa base cada vez que aparezca un nuevo esquema de firmas o de pruebas.
Pero esa promesa de estabilidad tiene un costo que todavía no está resuelto: la complejidad no se borra, se reubica en la mempool y en la infraestructura que genera las pruebas. La verdadera pregunta de EIP-8288 no es si Ethereum puede volverse agnóstico a la criptografía, sino si puede hacerlo sin crear un nuevo cuello de botella donde antes había un protocolo abierto a cualquiera.
