Orador: Vitalik Buterin
Compilado por: Yuliya, PANews
¡Hola a todos! Bienvenidos a ETHShanghai 2026. Hoy quiero discutir con ustedes un tema técnico bastante complejo que es crucial para el futuro de Ethereum: puede permitir que Ethereum logre una escalabilidad extremadamente alta mientras también equilibra la privacidad y la descentralización, y los tres pueden lograrse simultáneamente. Es muy probable que esta propuesta realmente cambie la arquitectura operativa de muchos componentes en la cadena de bloques. Puede cambiar muchas cosas, pero inesperadamente, implementarla en el Ethereum existente no es demasiado difícil. Esta es la EIP-8288: Firma Recursiva y Agregación.
Punto de dolor central: La irreconciliabilidad de la seguridad, la privacidad y la escalabilidad
Hoy quiero centrarme en varios problemas importantes que a todos les preocupan mucho: la seguridad cuántica, la privacidad y la escalabilidad. Actualmente, un gran problema es que tanto la seguridad cuántica como la privacidad entran en gran conflicto con la escalabilidad:
Una transacción normal de Ethereum actualmente consume alrededor de 21,000 gas; verificar de forma independiente una firma ECDSA (aproximadamente 65 bytes) toma alrededor de 4,000 gas.
Si se reemplaza con firmas cuánticamente seguras (independientemente de qué tipo de esquema de firma post-cuántica), el consumo de gas estará aproximadamente entre 100,000 y 300,000 gas, dependiendo del tamaño de parámetro elegido (por ejemplo, si necesita ser compatible con escenarios de billeteras blockchain). Pero no importa cómo se elija, el costo será varias veces mayor que el de las transacciones actuales: las firmas cuánticamente seguras son grandes y costosas.
El segundo problema: las pruebas para protocolos de privacidad son igualmente grandes y costosas. Si alguien ha usado algún protocolo de privacidad basado en tecnología de conocimiento cero (ZK), sabrá que en Ethereum, tales operaciones cuestan al menos alrededor de 350,000 gas. Debido a que muchos de estos protocolos no están diseñados de manera muy eficiente, a veces el costo real puede incluso alcanzar alrededor de 1 millón de gas; esto es muy costoso. Hoy una transacción normal puede costar solo unos centavos, mientras que tales transacciones pueden costar 20 centavos, o incluso dos dólares.
Un problema más grave es: si quieres tanto seguridad cuántica como privacidad, necesitas usar pruebas STARK para reemplazar los esquemas anteriores. Sin embargo, una prueba STARK consume alrededor de 8 millones de gas, y muy probablemente más. Es decir, si ahora hacemos que todos comiencen a usar transacciones "cuánticamente seguras + privacidad", la capacidad de procesamiento original de Ethereum de aproximadamente 25 TPS se desplomará a alrededor de 0.25 TPS, perdiendo casi por completo su usabilidad.
Otro problema es: las personas también pueden querer admitir esquemas criptográficos personalizados. Por ejemplo, cambiar de las curvas elípticas actuales a la futura criptografía basada en retículos. El problema es que cada vez que quieres admitir tales esquemas nuevos, aumenta el tamaño del protocolo en sí y requiere más archivos de precomputación (de gran tamaño y alto costo). Y si no admites de forma nativa estos esquemas en la EVM, o no tienes los archivos de precomputación correspondientes, entonces verificar cualquier firma de este tipo en la cadena consumirá una cantidad muy grande de gas.
En otras palabras, todos nuestros objetivos en seguridad y privacidad en realidad están obstaculizando la escalabilidad, al menos bajo la arquitectura actual.
Solución central: Mover el cálculo de agregación hacia adelante, al mempool
Entonces, ¿cómo resolvemos este problema? Este es el mecanismo central implementado por EIP-8288.
La idea central es: en lugar de poner directamente todas estas firmas y todas estas pruebas STARK (estos objetos enormes y estructuralmente complejos) en la cadena, las mantenemos fuera de la cadena y completamos la agregación dentro del mempool.
Específicamente: cuando un usuario envía una transacción, hay un grupo de nodos en el mempool, y estos nodos ya están trabajando antes de que la transacción se empaquete en un bloque. Lo que hacen estos nodos se llama "agregación": reemplazan una gran cantidad de firmas y pruebas con una única prueba, que puede verificar que todas estas firmas y pruebas realmente existen y son válidas.
Entonces, desde la perspectiva del usuario: el usuario envía una transacción y, junto con la transacción, también envía este enorme objeto (firma/prueba), pero este enorme objeto en sí nunca llega realmente a la cadena. Lo que realmente llega a la cadena es solo una única prueba STARK, utilizada para verificar que todas las firmas y todas las pruebas contenidas en todas las transacciones de usuario realmente existen y son válidas.
Este mecanismo se construye sobre 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 el campo de la abstracción de cuentas. Permite que cada transacción declare directa y precisamente de forma explícita sus componentes constitutivos, especificaciones de firma y algoritmos de verificación, otorgando a las transacciones una mayor programabilidad y una estructura tipada.
En EIP-8288, añadimos un nuevo tipo de marco, que puede entenderse como una "dependencia". Hay dos tipos de dependencias en total: una corresponde a las firmas y otra corresponde a las pruebas (STARK). A diferencia del modelo actual, donde las firmas se incrustan directamente en el cuerpo de la transacción, bajo el nuevo mecanismo la transacción misma contiene solo una declaración abstracta que indica de qué tipo de firma y prueba depende la transacción. Cuando se difunde la transacción, aunque los datos completos se envían junto con ella, lo que finalmente se escribe en el bloque es solo la microestructura de marco que transporta las dependencias. Los datos ocupados por cada dependencia son de solo 96 bytes, y la mayoría son incluso de tan solo 65 bytes. El resto de las enormes entidades criptográficas se absorben y agregan dentro del mempool, y finalmente aparecen en el libro mayor de la cadena de bloques solo en forma de una única prueba.
Bajo esta arquitectura, cada nodo en el mempool escucha continuamente un portador de datos llamado "sobre". Un único sobre puede encapsular múltiples transacciones y sus pruebas acompañantes.
Los nodos utilizan un período de tiempo fijo como ventana, recopilan continuamente todos los objetos sobre observados durante ese período, realizan un cálculo de agregación local y luego lo difunden. Durante la difusión, todas las pruebas independientes originalmente discretas han sido reemplazadas por una prueba agregada global, que cubre matemáticamente de manera rigurosa la corrección de todas las firmas subyacentes en este lote.
Esto muestra que antes de que los nodos de empaquetado de bloques ejecuten formalmente las actualizaciones de estado, la red de Ethereum ya ha completado la gran mayoría del cálculo de verificación de alta intensidad en la etapa del mempool, en la capa no consensuada.
Esencia arquitectónica: "Fragmentación especializada"
Una forma de entender este mecanismo es verlo como una especie de fragmentación especializada. Su idea es: podemos seleccionar aquellas partes del cálculo extremadamente costosas que involucran cantidades extremadamente grandes de datos, y dejar que toda la red distribuida procese esta parte del cálculo en paralelo de una manera muy flexible y no estructurada.
Este enfoque no es frágil; por el contrario, es muy robusto: cualquier nodo puede asumir cualquier porción de este trabajo. Lo que estamos haciendo es esencialmente dividir cada transacción en dos partes:
Una parte explica "qué hace esta transacción, cómo interactúa con el estado y cómo interactúa con otras transacciones";
La otra parte es la parte enorme y de alto costo de esta transacción, es decir, el trabajo de verificación puro.
Al fragmentar y despojar específicamente la carga de verificación, la carga útil de datos que la capa de consenso de la cadena principal finalmente requiere que todos los nodos de verificación de la red soporten conjuntamente se comprime estrictamente a un rango extremadamente pequeño de 100 a 300 KB por bloque. Esta sobrecarga es solo aproximadamente el doble del volumen de datos actual de los bloques de Ethereum, y a medida que el rendimiento general de la red se expande linealmente, la proporción de esta sobrecarga constante en la carga total de la red seguirá diluyéndose.
Esencialmente, lo que estamos haciendo es: alejar el trabajo de los validadores, e incluso de los nodos que empaquetan bloques, empujando esta parte del trabajo a aquellos nodos fuera de la cadena ubicados entre "el usuario envía una transacción" y "el nodo que empaqueta el bloque realmente incluye la transacción en el bloque".
¿Qué significa esto para Ethereum?
Desde una perspectiva técnica, esto significa que Ethereum está hiperescalando una clase específica de cálculo. Creo que esta también es una tendencia que veremos cada vez más a medida que Ethereum continúe desarrollándose.
Ethereum, nacido hace diez años, se centró en la computación totalmente general, pero también carecía por completo de escalabilidad. Así que lo que estamos haciendo ahora es dividir la computación en diferentes tipos, y luego hacer específicamente que aquellos tipos de computación que son "naturalmente más adecuados para escalar" sean extremadamente escalables: estamos construyendo estas "pequeñas herramientas" más especializadas para lograrlo.
Al mismo tiempo, también estamos haciendo más pequeños y más fáciles de manejar aquellos cálculos que deben gestionarse de una manera menos eficiente. EIP-8288 es precisamente el hiperescalado de dos tipos de objetos: "verificación de firmas" y "verificación de pruebas de conocimiento cero".
Otro punto interesante es este: sé que muchas personas han sentido curiosidad durante mucho tiempo sobre cuándo Ethereum migrará a RISC-V, porque en comparación con el enfoque actual, RISC-V o algún otro conjunto de instrucciones más moderno es mucho más eficiente y también mucho más simple. Y es muy probable que EIP-8288 se convierta en el primer escenario en Ethereum que realmente introduzca RISC-V (o un conjunto de instrucciones similar). La razón es que EIP-8288 permite a los usuarios enviar pruebas, y cuando los usuarios envían pruebas, necesitan usar algún lenguaje para expresar las afirmaciones que están verificando; RISC-V es exactamente ese lenguaje.
Es decir, la lógica de verificación expresada en RISC-V solo necesita ejecutarse como un único cálculo físico localmente en el cliente del usuario: el usuario genera la prueba correspondiente (en escenarios de privacidad, esto es un ZK-STARK), y luego la empuja inmediatamente al mempool; el primer nodo de retransmisión que la siga la comprimirá inmediatamente de forma recursiva junto con cientos o miles de pruebas similares en toda la red en una sola entidad.
Esto también equivale a dividir todo el cálculo en dos grandes categorías:
Una categoría son las "dependencias", es decir, las partes que deben garantizarse como correctas para que la transacción sea válida;
La otra categoría es la "lógica de negocio", es decir, lo que la transacción misma hace realmente.
La lógica de negocio puede, por lo tanto, volverse más ligera y más limpia, lo que también significa que la parte de la lógica de construcción de bloques que depende del ordenamiento de transacciones también se volverá más simple. Y la parte de las "dependencias" puede procesarse en paralelo a una escala extremadamente grande, casi sin necesidad de ningún cambio importante en la experiencia de desarrollo de los desarrolladores de Ethereum.
El valor práctico para desarrolladores, usuarios y Layer 2
Para cualquiera que construya aplicaciones on-chain, el significado central de todo esto es: las operaciones más costosas hoy se volverán mucho más baratas.
El costo de ejecución de las transacciones resistentes a la computación cuántica se comprimirá a un nivel bajo casi insignificante;
Las aplicaciones de preservación de la privacidad construidas sobre zk-SNARK/STARK escaparán de las restricciones de las altas tarifas de Gas, se generalizarán a un costo asequible y tendrán de forma nativa resistencia cuántica.
Más allá de los escenarios de privacidad, la eficiencia de aplicación de zk-SNARK en el escalado (especialmente Layer 2) experimentará un salto cualitativo. Actualmente, muchos ZK-Rollups, para amortizar el alto costo de Gas de publicar pruebas de estado en la red principal, a menudo se ven obligados a alargar el ciclo de envío, liquidando en lotes con frecuencias de diez minutos o incluso una hora. Esto restringe severamente la velocidad de confirmación final durante los períodos de baja actividad de transacciones en la red.
Actualmente, muchos ZK-Rollups, para amortizar el alto costo de Gas de publicar pruebas de estado en la red principal, a menudo se ven obligados a alargar el ciclo de envío, liquidando en lotes con frecuencias de diez minutos o incluso una hora. Esto restringe severamente la velocidad de confirmación final durante los períodos de baja actividad de transacciones en la red.
La evolución final: llevar la computación completamente al borde
Finalmente, si hay otros cálculos que quieres hacer pero que son demasiado costosos de ejecutar dentro de la EVM, espero que podamos realmente comenzar a cambiar de dirección: que el propio protocolo de Ethereum ya no soporte directamente todos los cálculos que todos quieren hacer, sino que en su lugar anime a los usuarios a completar esta parte del cálculo localmente en sus clientes, y luego publicar una prueba, de modo que esta prueba sea verificada en Ethereum.
Esencialmente, esto es escalar Ethereum moviendo la computación fuera del "centro" de la cadena y empujándola hacia el "borde". El resultado es: las cosas que hoy son más costosas en Ethereum (diversas formas de seguridad, diversas formas de privacidad y diversas formas de compatibilidad con aplicaciones externas) no las hace la gente hoy porque son demasiado costosas, y en el futuro todas se volverán mucho más baratas y verdaderamente utilizables por 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 nueva completamente diferente y aún más poderosa: una nueva arquitectura que realmente combine dos cosas: una es la idea de blockchain temprana muy simple de Satoshi Nakamoto; la otra es la tecnología criptográfica extremadamente poderosa y extremadamente moderna que hemos acumulado continuamente desde entonces.
Participación en el ecosistema y progreso de implementación
Actualmente, la exploración temprana y la validación de ingeniería en torno a este enfoque se están llevando a cabo intensivamente, y la comunidad técnica ya puede participar en la construcción desde múltiples puntos de entrada:
Modelos de simulación a nivel de red: se han abierto herramientas de simulación tempranas para la topología del mempool y los mecanismos de propagación de agregación;
Operación de testnet: la testnet EIP-8141 que admite la forma de transacción de marco se ha puesto en prueba;
Competencias de optimización de algoritmos: se están impulsando competencias de algoritmos especiales para la comunidad de desarrolladores, centrándose en la implementación eficiente del sistema de prueba subyacente;
Implementación y verificación de código: la base de código prototipo subyacente ha tomado forma, para que los desarrolladores del ecosistema lleven a cabo implementaciones de clientes independientes y verificación formal.
Una gran cantidad de piezas técnicas subyacentes se están completando rápidamente. Se invita a los desarrolladores a participar profundamente en este proceso técnico y ayudar a que esta arquitectura revolucionaria se convierta en un estándar real en la red principal de Ethereum lo antes posible.
