Vitalik detalla EIP-8288: la solución definitiva para escalar Ethereum con transacciones más rápidas y baratas

Ponente: Vitalik Buterin

Compilación: Yuliya, PANews

¡Hola a todos! Bienvenidos a ETHShanghai 2026. Hoy quiero hablar de un tema técnico bastante complejo, pero crucial para el futuro de Ethereum: esta propuesta permitirá a Ethereum lograr una escalabilidad extrema sin sacrificar la privacidad ni la descentralización, y las tres cosas serán posibles a la vez. Esta propuesta probablemente cambiará la arquitectura de muchos componentes de la blockchain. Puede cambiar muchas cosas, pero, sorprendentemente, implementarla en el Ethereum actual no es tan difícil. Se trata de EIP-8288: Firma Recursiva y Agregación (Recursive Signature and Aggregation).

El problema central: seguridad, privacidad y escalabilidad son incompatibles

Hoy quiero centrarme en tres grandes preocupaciones: la seguridad cuántica, la privacidad y la escalabilidad. Actualmente, hay un gran problema: la seguridad cuántica y la privacidad entran en conflicto con la escalabilidad:

• Una transacción normal de Ethereum consume hoy unos 21.000 gas; verificar una firma ECDSA (unos 65 bytes) requiere unos 4.000 gas.
• Si se cambia a firmas cuánticamente seguras (sea cual sea el esquema de firma resistente a cuántica), el consumo de gas estaría entre 100.000 y 300.000 gas, dependiendo del tamaño de los parámetros elegidos (por ejemplo, si se necesita compatibilidad con monederos blockchain). En cualquier caso, el coste sería varias veces superior al de las transacciones actuales: las firmas cuánticamente seguras son grandes y caras.

Segundo problema: las pruebas de los protocolos de privacidad también son grandes y caras. Si alguien ha usado algún protocolo de privacidad basado en conocimiento cero (ZK), sabrá que en Ethereum estas operaciones consumen como mínimo unos 350.000 gas. Como muchos de estos protocolos no están diseñados de forma eficiente, a veces el coste real llega a cerca de 1 millón de gas, lo cual es muy caro. Hoy una transacción normal puede costar unos pocos centavos de dólar, mientras que estas pueden costar 20 centavos de dólar o incluso dos dólares.

El problema más grave es que, si se quiere a la vez seguridad cuántica y privacidad, hay que sustituir los esquemas anteriores por pruebas STARK. Sin embargo, una prueba STARK consume aproximadamente 8 millones de gas, probablemente más. Es decir, si ahora mismo todos empezáramos a usar transacciones con «seguridad cuántica + privacidad», la capacidad de procesamiento original de Ethereum, de unos 25 TPS, se desplomaría a unos 0,25 TPS, quedando prácticamente inutilizable.

Otro problema es que la gente podría querer soportar esquemas criptográficos personalizados. Por ejemplo, pasar de las curvas elípticas actuales a la futura criptografía basada en retículos (lattice-based cryptography). El problema es que cada vez que se quiere soportar un esquema nuevo, aumenta el tamaño del propio protocolo y se necesitan más archivos de precomputación (grandes y costosos). Y si no se soportan estos esquemas de forma nativa en la EVM, o no existen los archivos de precomputación correspondientes, verificar en cadena cualquiera de estas firmas consume una cantidad enorme de gas.

Es decir, todos nuestros objetivos de seguridad y privacidad están, de hecho, obstaculizando la escalabilidad, al menos con la arquitectura actual.

La solución central: adelantar la agregación al mempool

Entonces, ¿cómo resolvemos este problema? Este es el mecanismo central que implementa EIP-8288.

La idea principal es no poner directamente en cadena todas esas firmas y todas esas pruebas STARK (objetos enormes y de estructura compleja), sino mantenerlas fuera de la cadena y completar la agregación dentro del mempool.

En concreto: cuando un usuario envía una transacción, hay un conjunto de nodos en el mempool que ya están trabajando antes de que la transacción se incluya en un bloque. Estos nodos realizan lo que se llama «agregación»: sustituyen una gran cantidad de firmas y pruebas por una única prueba que verifica que todas esas firmas y pruebas existen y son válidas.

Así, desde el punto de vista del usuario: el usuario envía una transacción y, junto con ella, ese objeto enorme (firma/prueba), pero ese objeto enorme nunca llega a subir a la cadena. Lo que realmente se sube a la cadena es una única prueba STARK que verifica que todas las firmas y todas las pruebas contenidas en todas las transacciones de los usuarios existen y son válidas.

Este mecanismo se basa en EIP-8141 (abstracción de cuenta nativa), que se introducirá en el próximo hard fork. EIP-8141 condensa casi una década de investigación de la comunidad de Ethereum en abstracción de cuentas y permite que cada transacción declare de forma explícita y precisa sus componentes, especificación de firma y algoritmo de verificación, otorgando a las transacciones mayor programabilidad y una estructura tipada.

En EIP-8288 añadimos un nuevo tipo de trama, que puede entenderse como una «dependencia». Hay dos tipos de dependencias: una para firmas y otra para pruebas (STARK). A diferencia del modelo actual, en el que la firma se incrusta directamente en la transacción, con el nuevo mecanismo la transacción solo contiene una declaración abstracta que indica de qué tipo de firma y prueba depende. Cuando la transacción se difunde, los datos completos viajan con ella, pero lo que finalmente se escribe en el bloque es solo una microtrama que porta las dependencias. Cada dependencia ocupa solo 96 bytes, y la mayoría incluso 65 bytes. El resto de las entidades criptográficas voluminosas se absorben y agregan dentro del mempool, y finalmente aparecen en el libro mayor de la blockchain como una única prueba.

Bajo esta arquitectura, los nodos del mempool escuchan continuamente un tipo de portador de datos llamado «sobre» (envelope). Un solo sobre puede encapsular múltiples transacciones y sus pruebas asociadas.

Los nodos, en ventanas de tiempo fijas, recopilan todos los sobres observados en ese periodo, ejecutan la agregación local y luego la difunden. Al difundir, todas las pruebas independientes originalmente dispersas han sido sustituidas por una única prueba agregada global que cubre matemáticamente la corrección de todas las firmas subyacentes del lote.

Esto demuestra que, antes de que el nodo que empaqueta el bloque ejecute formalmente la actualización de estado, la red Ethereum ya ha completado la mayor parte del trabajo de verificación intensivo en la fase de mempool, fuera de la capa de consenso.

La esencia de la arquitectura: «fragmentación especializada»

Una forma de entender este mecanismo es verlo como una fragmentación especializada. La idea es que podemos extraer las partes del cómputo que son extremadamente caras y que implican grandes cantidades de datos, y hacer que toda la red distribuida procese esa parte en paralelo de una manera muy laxa y no estructurada.

Este enfoque no es frágil, sino muy robusto: cualquier nodo puede asumir cualquier parte de ese trabajo. Lo que hacemos, en esencia, es dividir cada transacción en dos partes:

• Una parte que indica «qué hace esta transacción, cómo interactúa con el estado y con otras transacciones»;
• Otra parte que es el componente voluminoso y costoso de la transacción: el trabajo puro de verificación.

Al aplicar una fragmentación específica para la carga de verificación, la carga de datos que la capa de consenso de la cadena principal exige a todos los nodos validadores se comprime estrictamente a un rango muy pequeño de 100 a 300 KB por bloque. Este coste es solo aproximadamente el doble del tamaño actual de los bloques de Ethereum y, a medida que el rendimiento global de la red crezca linealmente, el peso de este coste constante en la carga total de la red se irá diluyendo.

En esencia, lo que hacemos es quitar trabajo a los validadores, e incluso a los nodos que empaquetan bloques, y empujar ese trabajo a los nodos fuera de la cadena que se encuentran entre «el usuario envía la transacción» y «el nodo que empaqueta el bloque realmente incluye la transacción en el bloque».

¿Qué significa esto para Ethereum?

Desde el punto de vista técnico, significa que Ethereum está hiperescalando un tipo específico de cómputo. Creo que esta es una tendencia que veremos cada vez más a medida que Ethereum evolucione.

Ethereum nació hace diez años con la idea de cómputo totalmente general, pero sin ninguna escalabilidad. Así que lo que hacemos ahora es dividir el cómputo en distintos tipos y, para aquellos tipos que son «naturalmente más escalables», hacerlos extremadamente escalables: estamos construyendo estas «herramientas» más especializadas para lograrlo.

Al mismo tiempo, hacemos que los cómputos que deben procesarse de forma menos eficiente sean más pequeños y fáciles de manejar. EIP-8288 es precisamente el hiperescalado de dos tipos de objetos: la «verificación de firmas» y la «verificación de pruebas de conocimiento cero».

Otro aspecto interesante es que sé que mucha gente se pregunta cuándo Ethereum pasará a RISC-V, porque, en comparación con el esquema actual, RISC-V u otros conjuntos de instrucciones más modernos son mucho más eficientes y, a la vez, mucho más simples. Y EIP-8288 probablemente será el primer escenario en Ethereum que introduzca de verdad RISC-V (o un conjunto de instrucciones similar). La razón es que EIP-8288 permite a los usuarios enviar pruebas y, al hacerlo, necesitan expresar en algún lenguaje las afirmaciones que están verificando: RISC-V es ese lenguaje.

Es decir, la lógica de verificación expresada en RISC-V solo necesita ejecutarse una única vez físicamente en el cliente del usuario: el usuario genera la prueba correspondiente (en escenarios de privacidad, un ZK-STARK) y la introduce en el mempool; el primer nodo de retransmisión que la recibe la comprime recursivamente con cientos o miles de pruebas similares de toda la red en una única entidad.

Esto equivale a dividir todo el cómputo en dos grandes categorías:

• Por un lado, las «dependencias»: aquellas partes que deben ser correctas para que la transacción sea válida;
• Por otro, la «lógica de negocio»: lo que realmente hace la transacción.

La lógica de negocio puede así volverse más ligera y limpia, lo que también significa que la lógica de construcción de bloques que depende del orden de las transacciones se vuelve más simple. Y la parte de las «dependencias» puede procesarse en paralelo a gran escala, casi sin cambios importantes en la experiencia de desarrollo de Ethereum.

Valor práctico para desarrolladores, usuarios y Layer 2

Para cualquiera que construya aplicaciones en cadena, el significado central de todo esto es que las operaciones más caras de hoy serán mucho más baratas.

• El coste de ejecución de las transacciones cuánticamente seguras se comprimirá hasta un nivel casi insignificante;
• Las aplicaciones de privacidad basadas en zk-SNARK/STARK se liberarán de las altas tarifas de gas y se popularizarán a un coste asequible, con resistencia cuántica nativa.

Además de los escenarios de privacidad, la eficiencia de zk-SNARK en escalado (especialmente en Layer 2) experimentará un salto cualitativo. Actualmente, muchos ZK-Rollup, para diluir el alto coste de gas de publicar pruebas de estado en la red principal, se ven obligados a alargar los periodos de envío y liquidar por lotes cada diez minutos o incluso cada hora. Esto limita gravemente la velocidad de confirmación final en periodos de baja actividad de la red.

Actualmente, muchos ZK-Rollup, para diluir el alto coste de gas de publicar pruebas de estado en la red principal, se ven obligados a alargar los periodos de envío y liquidar por lotes cada diez minutos o incluso cada hora. Esto limita gravemente la velocidad de confirmación final en periodos de baja actividad de la red.

La evolución final: llevar el cómputo al borde

Por último, si hay otros cómputos que quieres hacer pero que resultan demasiado caros de ejecutar dentro de la EVM, espero que empecemos a cambiar de dirección: en lugar de que el protocolo Ethereum asuma directamente todo el cómputo que la gente quiera hacer, animar a los usuarios a realizar ese cómputo localmente en el cliente y publicar una prueba que se verifique en Ethereum.

En esencia, esto es escalar Ethereum moviendo el cómputo desde el «centro» de la cadena hacia el «borde». El resultado es que las cosas más caras de Ethereum hoy (diversas formas de seguridad, diversas formas de privacidad y diversas compatibilidades con aplicaciones externas) que la gente no hace porque son demasiado caras, serán mucho más baratas y estarán realmente al alcance de todos.

Espero que este sea solo el primer paso para transformar Ethereum desde la arquitectura que ha usado casi desde su nacimiento hacia una arquitectura completamente distinta y mucho más potente, una arquitectura que combine de verdad dos cosas: por un lado, la idea de blockchain más temprana y sencilla de Satoshi; por otro, las técnicas criptográficas extremadamente potentes y modernas que hemos ido acumulando desde entonces.

Participación del ecosistema y avances en la implementación

Actualmente, la exploración temprana y la validación de ingeniería en torno a esta propuesta avanzan intensamente, y la comunidad técnica ya puede participar desde varios puntos de entrada:

• Modelos de simulación a nivel de red: ya están disponibles herramientas de simulación tempranas para la topología del mempool y los mecanismos de propagación de agregados;
• Ejecución en redes de prueba: ya se está probando una red de pruebas de EIP-8141 compatible con transacciones en forma de trama;
• Competiciones de optimización de algoritmos: se está impulsando una competición de algoritmos dirigida a la comunidad de desarrolladores, centrada en implementaciones eficientes del sistema de pruebas subyacente;
• Implementación y verificación de código: el repositorio de código prototipo subyacente ya tiene una forma preliminar, disponible para que los desarrolladores del ecosistema realicen implementaciones de cliente independientes y verificación formal.

Muchas piezas técnicas de base se están completando rápidamente. Damos la bienvenida a todos los desarrolladores a participar en este proceso técnico y a impulsar que esta arquitectura revolucionaria se convierta cuanto antes en un estándar real de la red principal de Ethereum.