Resumen: Vitalik afirma que los precompilados y la EVM ya se enfrentan a un cuello de botella de rendimiento al procesar criptografía. EIP-8288 propone sacar la verificación del hilo principal y dejar en la cadena solo una prueba recursiva.
El 19 de octubre, el cofundador de Ethereum, Vitalik Buterin, siguió explicando en X la hoja de ruta de EIP-8288. Expuso una limitación concreta: incluso con PeerDAS y blocks-in-blobs, el rendimiento de los datos empezará a sufrir una presión real cuando supere aproximadamente los 8 MB/s.
En el contexto del soporte criptográfico, esta frase apunta a un conflicto inminente. Ethereum necesita admitir cada vez más esquemas de firma y sistemas de prueba, pero si cada función criptográfica se incorpora a la cadena mediante contratos precompilados o ejecución en la EVM, el espacio de calldata ocupado seguirá creciendo. Los 8 MB/s no son un límite teórico lejano, sino una barrera física con la que ya está chocando la ampliación del hilo principal.
Precompilados y EVM: por qué ya no ocupan un lugar ideal
Los contratos precompilados fueron una solución pragmática para que #Ethereum incorporara operaciones criptográficas costosas: fijar ciertos cálculos como funciones nativas en la cadena y evitar el coste por byte de la EVM. El problema es que los datos que procesan los contratos precompilados y la EVM suelen tener que escribirse en bloques de Ethereum, ocupando espacio en calldata.
Cada nuevo esquema criptográfico implica añadir un precompilado o lógica de verificación a la EVM. Aumentan la complejidad del protocolo y el uso de calldata, mientras que el rendimiento del hilo principal tiene un límite. PeerDAS y los blobs ya han separado parte de la disponibilidad de datos de la ruta principal de ejecución, pero Vitalik considera que, incluso con estos cambios, seguirá habiendo presión por encima de los 8 MB/s.
Los contratos precompilados mejoran la eficiencia de cada verificación, pero no resuelven el crecimiento constante del volumen total de verificaciones. Cada nueva modalidad criptográfica añade más datos que debe cargar el hilo principal.
EIP-8288: sacar la verificación del hilo principal
La alternativa que propone Vitalik consiste en sacar los cálculos criptográficos pesados de la ruta de ejecución en cadena.
En el caso de los cálculos pesados autocontenidos, el usuario o el cliente los ejecuta localmente, genera una prueba STARK y la envía mediante el mecanismo de agregación recursiva de EIP-8288. La cadena ya no recibe los datos originales ni todo el proceso de cálculo; solo verifica dos cosas: que el cálculo se haya ejecutado y que el resultado sea correcto.
La agregación recursiva es el núcleo de este mecanismo. Los nodos del mempool reúnen las pruebas adjuntas a las transacciones y las agregan y comprimen recursivamente antes de incluirlas en un bloque. Al final, el bloque entero contiene una sola prueba resumida que demuestra que se cumplen todas las condiciones criptográficas de las que dependen sus transacciones. La tarea de los validadores de la cadena principal pasa de comprobar cada prueba completa una por una a confirmar si una única prueba recursiva es válida.
Esto prolonga la lógica de separación que Ethereum ha seguido durante los últimos años: los rollups trasladan la ejecución a L2, los blobs separan los datos de la ejecución y PeerDAS reduce aún más la carga de los nodos relacionada con la disponibilidad de datos. EIP-8288 busca separar la propia verificación.
Vitalik también corrige una inercia narrativa. Ethereum no debería considerarse solo una cadena de bloques, sino una «computadora del mundo criptográfico». La implicación es que el hilo principal no tiene que ejecutar personalmente todos los cálculos; su función es ofrecer una verificación final y confiable de sus resultados. Los datos y la ejecución que no necesitan estar en el hilo principal no deberían ocuparlo.
Poscuántica y privacidad: sin separación, el coste es inasumible
El impulso directo de EIP-8288 proviene de dos tipos de costes que cada vez son más difíciles de ignorar.
En criptografía poscuántica, las firmas poscuánticas basadas en hash ocupan aproximadamente entre 2 y 3 KB, y una sola verificación puede consumir entre 150.000 y 200.000 unidades de gas. Las pruebas STARK pueden superar los 128 KB, y verificarlas directamente en la cadena requiere millones de unidades de gas. Si cada transacción incluyera una prueba completa resistente a la computación cuántica y todos los nodos tuvieran que verificarla individualmente, el coste de la actualización de seguridad sería demasiado alto para permitir un uso generalizado.
Las transacciones privadas se enfrentan a una estructura de costes similar. Muchos sistemas de privacidad ya son viables desde el punto de vista criptográfico; el verdadero obstáculo es el coste de las pruebas. Exigir a la vez privacidad y seguridad poscuántica elevaría aún más el coste de verificación. Agregar las pruebas y procesarlas conjuntamente en la capa del mempool es un requisito previo para que estas capacidades pasen de ser «opciones costosas» a «funciones asequibles a nivel de cuenta».
Esto explica por qué EIP-8288 no genera tanto entusiasmo en los debates técnicos como las narrativas de precios, aunque aborda una cuestión más fundamental: ¿la compatibilidad criptográfica futura de Ethereum seguirá construyéndose mediante la incorporación de más precompilados o se adoptará otro enfoque, en el que el hilo principal solo se encargue del último paso de la verificación?
El ocaso de los precompilados y el amanecer de la infraestructura de pruebas
Si EIP-8288 funciona según lo previsto, una consecuencia inmediata será una reducción considerable de la necesidad de añadir nuevos contratos precompilados. Los usuarios podrán generar localmente firmas de cualquier tipo, enviarlas en forma de pruebas STARK y canalizarlas a la cadena a través de un agregador, sin que Ethereum tenga que incorporar un precompilado específico para cada nuevo algoritmo.
Otra consecuencia será un cambio en la infraestructura. Hoy, el mempool se encarga principalmente de propagar y ordenar las transacciones; con el marco de EIP-8288, sus nodos también deberán recopilar, agregar y comprimir recursivamente las pruebas. Esto podría dar lugar a una infraestructura de pruebas especializada: en vez de que todos los nodos repitan los cálculos, una red más especializada los realizaría y luego la cadena principal confirmaría el resultado.
Pero este mecanismo también presenta dificultades de ingeniería. El propio Vitalik ha señalado que gestionar y paralelizar el acceso al estado de Ethereum a gran escala podría ser más difícil que hacer que las pruebas de conocimiento cero sean eficientes y seguras. Las pruebas se pueden agregar, pero el estado no puede desaparecer por arte de magia. EIP-8288 resuelve la carga de datos de la verificación, pero no soluciona automáticamente el crecimiento del estado.
Qué observar a continuación
La dependencia entre EIP-8288 y EIP-8141: por ahora, la propuesta depende principalmente de la estructura de transacciones por tramas de EIP-8141. El avance de una implementación funcional de esta última en las redes de desarrollo determinará si EIP-8288 puede pasar a una fase de debate sustantivo
La estandarización de RISC-V: las STARK recursivas necesitan un conjunto de instrucciones de propósito general que sirva de base. Vitalik considera que RISC-V es la principal opción, y la decisión de si esta arquitectura llega a generar consenso afectará a la universalidad de las pruebas agregadas
Las ventanas de actualización de Hegota e I-star: EIP-8288 sigue siendo un borrador y todavía no se ha incorporado formalmente a una actualización confirmada de la red principal. El calendario posterior a Hegota, en 2027, servirá como referencia para observar si llega a implementarse
Soluciones para paralelizar la gestión del estado: una vez que la verificación salga del hilo principal, el acceso al estado será el siguiente cuello de botella. Los avances de la investigación determinarán los límites de los beneficios prácticos de EIP-8288
¿Qué queda en el hilo principal?
La hoja de ruta técnica de Ethereum durante la última década ha respondido repetidamente a una misma pregunta: ¿qué tareas debe realizar en conjunto toda la red y cuáles pueden delegarse a sistemas más especializados, para que la red principal confirme después el resultado? La ejecución se trasladó a L2, los datos a los blobs y ahora la verificación también se desplaza al mempool y a los clientes. La función esencial que le queda al hilo principal es ofrecer confianza final y consenso sobre los resultados de los cálculos.
Ethereum no se está haciendo más pequeño; se están redefiniendo los límites de sus responsabilidades. La presión de 8 MB/s no es el punto final: solo hace que el camino de «meterlo todo en el hilo principal» llegue antes al momento de tomar otro rumbo.