Vitalik Buterin plantea EIP-8288 para abaratar criptografía de Ethereum

Ethereum lleva años resolviendo cada necesidad criptográfica nueva con un precompilado: una función incrustada en el software de los nodos que abarata una operación muy concreta a cambio de un cambio de protocolo. Vitalik Buterin quiere romper esa inercia. El 19 de octubre de 2026, defendió en X lo que él mismo llamó «maximalismo de la EIP-8288», una propuesta que firmó con el investigador Thomas Coratger y que saca la criptografía pesada fuera de la cadena. Según sus cálculos, una transacción privada a prueba de cuántica pasaría de unos 10 millones de gas a decenas de miles.

El borrador se registró el 3 de junio de 2026 y sigue sin aprobación. Su idea central se enuncia rápido: la transacción no transporta la firma ni la prueba, transporta una declaración de 96 bytes que dice qué hay que verificar, y los nodos del mempool agrupan esas declaraciones en una única prueba recursiva cada segundo. El bloque carga solo con esa prueba final. Lo que se evita es justamente lo que hoy no cabe: firmas poscuánticas de 2 a 3 kilobytes y pruebas de más de 128 kilobytes viajando como datos de cada transacción.

El interés no está solo en la factura de gas. Con EIP-8288, Ethereum dejaría de decidir qué esquemas criptográficos admite: la verificación se encapsula en una prueba que el protocolo no necesita entender. El plan oficial de la Fundación reserva la agregación poscuántica para la bifurcación M, mientras Buterin la quiere en la I.

Un precompilado pesa para siempre

Un precompilado no se ejecuta como un contrato normal: vive dentro de cada cliente de ejecución, desde Geth hasta Erigon, y hace baratas operaciones que en bytecode puro costarían demasiado. El problema es que añadir uno exige una bifurcación dura y una implementación idéntica en cada cliente. Ethereum lo comprobó en septiembre de 2016, cuando una tanda de ataques de denegación de servicio aprovechó los precompilados y forzó dos bifurcaciones de emergencia para recalibrar su precio, como recuerda Mark Rutherford en Tech Times.

Buterin llevaba tiempo intentando cerrar esa puerta. En 2024 propuso convertir el precompilado de identidad en código de la máquina virtual, y un borrador posterior hacía lo mismo con cinco precompilados poco usados.

La EIP-8288 cambia la unidad de trabajo. El usuario demuestra en local la validez de su firma dentro de una prueba STARK y envía una dependencia de 96 bytes con el esquema, el hash de los datos y el hash de la clave.

Los nodos del mempool pliegan esas dependencias cada segundo y el bloque incluye una sola prueba recursiva que cubre todas las transacciones. En palabras de Buterin, los precompilados son «el lugar equivocado» para sostener la criptografía de Ethereum, y con este modelo la red «nunca tendría que añadir otro precompilado».

El movimiento encaja con la reconstrucción de herramientas que Ethereum ya viene haciendo para su etapa poscuántica, un trabajo que la casa ha seguido al explicar cómo la criptografía poscuántica empuja una nueva era de la ingeniería en Ethereum. La diferencia es de grado: el debate ya no es qué algoritmo elegir, sino si el protocolo debe seguir eligiéndolos.

El coste real, de 10 millones de gas a decenas de miles

Las cifras del propio borrador delimitan el ahorro. Una firma poscuántica basada en hash mide entre 2 y 3 kilobytes y cuesta entre 150 000 y 200 000 gas verificarla. Una prueba STARK suelta supera los 128 kilobytes y llega a 512 kilobytes cuando se prima la velocidad de generación, lo que la lleva a millones de gas. La especificación fija 3 000 gas por firma leanSPHINCS declarada y 30 000 por la prueba recursiva, de modo que una transacción con una sola dependencia ronda los 33 000 gas.

El «más del 99%» que repitieron las coberturas del 19 y el 20 de octubre se sostiene en el caso extremo, el de las transacciones privadas poscuánticas, que hoy rozan los 10 millones de gas y quedarían en decenas de miles según los cálculos que Buterin publicó en septiembre y recogió Decrypt. Para una firma suelta, el recorte que se deduce de los parámetros del borrador ronda el 80%, no el 99%. Tech Times atribuyó el porcentaje a la verificación de firmas en general.

El borrador acota además la promesa: cada transacción admite 16 dependencias de firma y una de prueba STARK, y repetir una dependencia se paga otra vez. Del lado de los constructores, la agregación implica unos 256 kilobytes fijos de prueba cada segundo.

Quién decide qué criptografía admite la red

Aquí está el punto que menos se ha discutido. La hoja de ruta poscuántica de la Fundación Ethereum, publicada en pq.ethereum.org, encadena cuatro hitos: registro de claves en la I, precompilados de firma poscuántica en la J, atestaciones y pruebas de consenso en la L, y solo en la M la agregación de firmas. El plan del clúster de protocolo, fechado el 7 de septiembre de 2026, promete una L1 resistente al cuántico en las tres capas para diciembre de 2029.

Los plazos de ese camino son los que Thomas Coratger detalló, con Lean Ethereum como sustrato común entre consenso y ejecución, y con la agregación de firmas como último tramo.

Buterin firma esa misma dirección técnica y discrepa del orden: quiere la EIP-8288 en la I*, antes de que se instale ningún precompilado poscuántico. Si prospera, cualquier equipo capaz de escribir un circuito STARK podría desplegar un esquema de firma nuevo sin presentar una propuesta de mejora ni esperar a una bifurcación dura.

Ese traslado de poder apenas salió en el debate público. Tech Times señala que no hay postura formal sobre si distribuir la innovación fuera del cuello de botella de las propuestas es una ventaja o un riesgo de que lleguen esquemas sin revisión. El precedente de la EIP-8361, cuando Aave cargó contra la propuesta y contra la torre de marfil de la Fundación, muestra que ese pulso no es nuevo.

Hash contra retículos, la pelea que empujó la propuesta

Los mensajes del 19 de octubre cerraron un fin de semana de discusión que arrancó el viernes con la publicación de Aerie, un sistema para agregar firmas Falcon-512 basado en retículos y firmado por LayerZero Labs con a16z crypto, la Universidad Carnegie Mellon y el Imperial College de Londres. En la demostración agregó 32 768 firmas en 0,65 segundos sobre un portátil con chip M4 Max y sin GPU. Cada firma agregada ocupa unos 42,1 bytes.

El argumento de a16z crypto es que la demostración recursiva en la que se apoya el plan de Ethereum para la poscuántica resulta intrincada y propensa a errores. Eli Ben-Sasson, consejero delegado de StarkWare, respondió que los retículos no están maduros para asegurar activos grandes, según Bankless, y Tech Times apunta que StarkWare tiene interés comercial directo en que las pruebas STARK sean la capa de verificación estándar.

La EIP-8288 no cierra el debate, lo aparca. Quien use un esquema distinto de leanSPHINCS asumirá el coste en cadena o lo envolverá en una prueba STARK. Buterin admite que, si los retículos aguantan los ataques asistidos por IA, aún podrían llegar precompilados para cuentas y monederos.

Frames, la I* y un calendario sin firmar

El borrador está lejos de estar cerrado. La ruta de agregación con leanSTARK figura como «reservada» en la especificación, los parámetros de la clave de verificación agregada y del hash de dependencias siguen pendientes, y la implementación de referencia aparece como próxima. Depende además de la EIP-2718 y de la EIP-8141, conocida como Frames, que tampoco tiene bifurcación asignada.

Nada de esto se activa por decreto. Los nodos sin la actualización rechazarían las transacciones con el nuevo modo de marco y los bloques con la cabecera de prueba recursiva, así que la entrada en mainnet exige una actualización coordinada y el visto bueno de los equipos de cliente en las llamadas de desarrollo.

La propuesta entra ahora en esa fase, la misma en la que se decidirá si la J* mantiene sus precompilados poscuánticos o si el plan oficial se reescribe para saltar directamente a la agregación de firmas.

Lo que se juega Ethereum con esta discusión no es un porcentaje de gas. Es si la criptografía del protocolo seguirá creciendo a base de funciones incrustadas y bifurcaciones negociadas una a una, o si se convierte en software que cualquiera puede escribir, demostrar y desplegar por su cuenta. La primera opción es más lenta y más previsible. La segunda deja menos control en manos de la Fundación y traslada el riesgo a circuitos que nadie ha auditado todavía.