El 27 de febrero de 2026, Vitalik Buterin publicó un artículo largo en Ethereum Research titulado «Hyper-scaling state by creating new forms of state».
En este artículo, Vitalik Buterin clarifica aún más la ruta de escalabilidad de Ethereum. Este artículo no solo aborda la escalabilidad de Ethereum desde una perspectiva técnica, sino que también ofrece, desde una perspectiva arquitectónica integral, un plan escalonado para expandir la red, con el objetivo de proporcionar una base para que Ethereum aumente su capacidad de red durante los próximos años.
Al mismo tiempo, también publicó un tweet en X explicando más a fondo este artículo. Intentamos comprender de manera clara y accesible qué es exactamente la nueva propuesta de escalabilidad presentada por Vitalik y por qué lo hizo.
Short-term and long-term expansion of execution resources and data resources
Vitalik señala al inicio del artículo largo: «Para escalar Ethereum en los próximos cinco años, se necesitan escalar tres recursos»:
Recursos de ejecución: cálculo EVM, verificación de firmas, etc.
- Recursos de datos: remitente, destinatario, firma, etc. de la transacción
- Recursos de estado: saldo de la cuenta, código, almacenamiento
Los dos primeros tienen planes de expansión a corto y largo plazo.
Para los recursos de ejecución, se logrará un aumento de aproximadamente 10 a 30 veces a corto plazo mediante listas de acceso a bloques (BAL), ePBS y reprecificación de tarifas de gas, y un aumento de aproximadamente 1000 veces a largo plazo mediante ZK-EVM. Además, para ciertos tipos específicos de cálculos (firma, SNARK/STARK), la agregación fuera de cadena puede mejorar el rendimiento en aproximadamente 10,000 veces.
Para los recursos de datos, a corto plazo se logrará un crecimiento de aproximadamente 10 a 20 veces mediante mejoras en P2P y Gas multidimensional; a largo plazo, se logrará un crecimiento de aproximadamente 500 veces mediante Blobs + PeerDAS.
La expansión a corto plazo se enfoca en hacer que Ethereum funcione más rápido. Actualmente, Ethereum es lento porque el método actual de validación es secuencial: se verifican las transacciones una tras otra. Si una transacción se atasca, todo el proceso de validación se detiene.
Por lo tanto, la próxima actualización de Glamsterdam este año introducirá la lista de acceso a bloques (BAL) y ePBS.
La lista de acceso a bloques permite a los empaquetadores de bloques informar anticipadamente a los validadores: «Las transacciones en este bloque accederán a estas cuentas y posiciones de almacenamiento». Con esta información, los validadores pueden prepararse con anticipación y cargar estos datos desde el disco duro a la memoria. Luego, los validadores pueden verificar múltiples transacciones en paralelo, en lugar de hacerlo una por una. Es como una línea de ensamblaje en una fábrica: antes, un solo trabajador se encargaba de todo el producto; ahora, varios trabajadores procesan simultáneamente diferentes partes.
ePBS separa el proceso de empaquetado y validación de bloques: los constructores de bloques se encargan de empaquetar las transacciones, los proponentes proponen bloques y los validadores los verifican. Cada rol se enfoca en su tarea específica; así, los constructores de bloques pueden empaquetar más transacciones de forma más agresiva, ya que los proponentes y validadores los ayudan a verificar, eliminando preocupaciones sobre la seguridad.
La reprecificación de la tarifa de gas + el gas multidimensional podría decirse que es el «movimiento clave». Actualmente, todas las operaciones en Ethereum utilizan la misma tarifa de gas. Pero la idea de Vitalik es que diferentes operaciones deberían tener precios distintos.
En particular, crear nuevos estados (por ejemplo, crear una nueva cuenta o implementar un nuevo contrato) debería tener una «tarifa de creación de estado» especial, ya que crear nuevos estados es la operación más costosa. No solo consume recursos de cálculo, sino también recursos de almacenamiento. Además, este costo es permanente: una vez creado, este estado persistirá indefinidamente.
Entonces, la idea de Vitalik es: hacer que crear un nuevo estado sea más caro, pero que las transacciones normales sean más baratas.
El método implementado es el "mecanismo de reserva". Imagina dos baldes: uno almacena "la tarifa de creación de estado" y el otro almacena "la tarifa Gas normal". Cuando los contratos se llaman entre sí, el Gas se toma automáticamente de ambos reservorios, asegurando que todo funcione correctamente.
Las transacciones de usuarios normales serán más baratas, ya que no requieren el pago de una "tarifa de creación de estado". Los desarrolladores que deseen crear nuevos estados deberán pagar tarifas más altas. Así, la capacidad general de la red aumenta enormemente, pero el crecimiento del estado se controla, evitando que el disco duro de los nodos completos se sobrecargue.
La expansión a largo plazo consiste en fortalecer y hacer crecer la red principal, reduciendo la dependencia de Layer 2. Esto incluye el despliegue por fases de Blobs + PeerDAS y ZK-EVM.
Blobs, un almacenamiento temporal de archivos grandes, actualmente se utiliza principalmente para Layer 2. En el futuro, la red principal de Ethereum también usará Blobs para almacenar datos. Pero surge un problema: si cada nodo debe descargar todos los Blobs, la red se colapsará.
Aquí es donde entra PeerDAS: no necesitas descargar todos los datos, solo una pequeña parte. Como en una encuesta por muestreo, no necesitas preguntar a todos, solo a un pequeño grupo, para inferir la situación del conjunto completo. Combinado con pruebas ZK, incluso si solo descargas 1/16 de todos los datos, puedes confirmar la integridad de los datos.
Luego viene el despliegue por fases de ZK-EVM, lo que hace que la validación de un bloque ya no requiera volver a ejecutar todas las transacciones dentro del bloque; los nodos simplemente confían en la prueba ZK, reduciendo el costo de validación de «ejecutar todas las transacciones» a «verificar una prueba ZK».
El plan de Vitalik es que en 2026, algunos nodos prueben la verificación ZK. Para 2027, se animará a más nodos a utilizarla. Finalmente, para que un bloque sea válido, debe contener tres de los cinco tipos de pruebas de diferentes sistemas de prueba. Él espera que, finalmente, todos los nodos (excluyendo los nodos de índice) dependan de pruebas ZK-EVM.
No hay extensión de estado de "píldora mágica"
Ahora veamos los "recursos de estado" que aún no se han abordado en la expansión a corto y largo plazo. Aunque a corto plazo aún es posible mejorar entre 5 y 30 veces mediante la sincronización con listas de acceso a bloques, mejoras en p2p y optimizaciones de base de datos, ¿qué pasa a largo plazo?
La respuesta de Vitalik es que no.
¿Por qué es tan difícil escalar el estado? El estado de Ethereum es como una base de datos enorme. Esta base de datos almacena los saldos de todas las cuentas, el código de todos los contratos y los datos de todos los lugares de almacenamiento.
Actualmente, esta base de datos aún es pequeña, con solo aproximadamente 100 GB, pero si se expande el estado 20 veces, serían 2 TB. ¿Y si el tiempo fuera aún más largo? ¿8 TB?
El problema no es que el disco duro no tenga suficiente espacio, sino que:
- La eficiencia de la base de datos se ve afectada: las bases de datos modernas utilizan estructuras de árbol (como los árboles Merkle) para organizar los datos. Al escribir un nuevo dato, es necesario actualizar todo el árbol. Esto significa que, si realizas X actualizaciones, en el nivel de la base de datos se realizan X operaciones adicionales, en lugar de una sola operación de actualización. Cuantas más actualizaciones haya, más operaciones se realizarán, y la escritura se volverá extremadamente lenta.
Dificultad de sincronización: Un nodo que se une por primera vez a la red de Ethereum debe descargar todo el estado para validar nuevos bloques. Si el tamaño de los datos alcanza 8 TB, la mayoría de las personas necesitarán mucho tiempo para descargarlo con sus velocidades de internet actuales.
Hay soluciones, pero Vitalik cree que todas tienen problemas:
- "Estado sin estado fuerte": los nodos no necesitan almacenar el estado completo, solo requieren que el usuario proporcione pruebas Merkle. Vitalik considera que este enfoque presenta problemas de centralización del almacenamiento de estado, fallos en transacciones debido al acceso dinámico al almacenamiento y costos de ancho de banda.
- "Estado caducado": los estados no accesados con frecuencia se eliminan automáticamente del estado activo. Los nodos solo necesitan almacenar los estados más recientemente accedidos, lo que reduce significativamente el espacio de almacenamiento. Vitalik considera que existe un problema fundamental: al crear un nuevo estado, ¿cómo demostrar que un estado "nunca existió"? Supongamos que se crea una nueva cuenta; entonces se debe demostrar que la dirección de la nueva cuenta nunca se ha creado en Ethereum. Esto implica que la creación de cada nueva cuenta requiere verificar 10 años de datos históricos, lo que hará que la creación de nuevas cuentas sea compleja y costosa.
El enfoque final de Vitalik es combinar ambos métodos para proponer varias nuevas formas de estado, lo que constituye un cambio integral en la arquitectura de recursos de estado de Ethereum:
- Almacenamiento temporal: un almacenamiento que expira automáticamente. Por ejemplo, se puede crear un nuevo árbol que se restablezca automáticamente cada mes. Este tipo de almacenamiento es útil para datos temporales, como el libro de órdenes, pools de liquidez o contadores temporales, que generalmente no requieren almacenamiento permanente; después de un mes, las órdenes antiguas expiran y se crean nuevos pools de liquidez.
- Almacenamiento periódico: Similar al almacenamiento temporal, pero con un período más largo, como un año.
Almacenamiento restringido: ciertos almacenamientos solo pueden accederse de formas específicas. Por ejemplo, el almacenamiento del saldo de un token ERC20 podría solo ser accesible a través de una interfaz específica. Esto permite que el sistema optimice dicho almacenamiento.
Al mismo tiempo, mantenga el estado existente. Así, la ejecución puede ser hasta 1000 veces más barata (a través de ZK-EVM), pero la creación de nuevo estado puede ser solo 20 veces más barata.
Vitalik cree que, con la nueva forma de estado, los desarrolladores tienen opciones: continuar utilizando la forma de estado existente, pero pagando tarifas más altas, o rediseñar las aplicaciones para utilizar la nueva forma de estado y obtener tarifas más bajas. Para casos de uso comunes (como saldos ERC20 o NFT), habrá flujos de trabajo estandarizados, mientras que para casos de uso más complejos (como DeFi), los desarrolladores deberán encontrar sus propias soluciones para optimizar.
Esta estrategia es bastante interesante, con un toque de desarrolladores esforzándose mentalmente para reducir costos, beneficiando así a una amplia base de usuarios de Ethereum.