Vitalik Buterin提出以太坊超级扩展方案：状态分层与执行提效

2026-02-27, Vitalik Buterin publicó en *Ethereum Research* un artículo extenso titulado «Hyper‑scaling state by creating new forms of state» («Super‑escalar el estado creando nuevas formas de estado»).

En el texto, Vitalik Buterin vuelve a ordenar la hoja de ruta de escalabilidad de Ethereum. El artículo no solo discute la expansión desde el punto de vista técnico, sino que parte de una visión arquitectónica integral y propone un plan por fases, con el objetivo de sentar las bases para que la red aumente su capacidad en los próximos años.

Posteriormente, el propio Vitalik compartió un hilo en X (antes Twitter) explicando los puntos clave del escrito. A continuación intentamos desglosar, en un lenguaje accesible, la propuesta de escalado y la motivación que la sustenta.

Desde la perspectiva del equipo de edición de *BitRoot*, analizamos la última hoja de ruta quinquenal de Ethereum propuesta por Vitalik, desglosando la lógica técnica y el posible impacto de la mejora de ejecución, la fragmentación de datos y la capa de estado. El objetivo es que el lector entienda las tendencias clave de escalado on‑chain; en las secciones siguientes desarrollaremos cada punto. También se discutirá el significado a largo plazo para el ecosistema.

Expansión a corto y largo plazo de los recursos de ejecución y de datos

Al iniciar el artículo, Vitalik afirma: “Para escalar Ethereum en los próximos cinco años, debemos ampliar tres tipos de recursos”:

• Recursos de ejecución: cálculo de la EVM, verificación de firmas, etc.
• Recursos de datos: remitentes, destinatarios, firmas de cada transacción, etc.
• Recursos de estado: balances de cuentas, código de contratos, almacenamiento.

Los dos primeros recursos cuentan con soluciones tanto a corto como a largo plazo.

Recursos de ejecución

• Corto plazo: mediante *Block Access Lists* (BAL), *ePBS* y la reprecificación del gas, se estima un aumento de 10‑30×.
• Largo plazo: usando ZK‑EVM se proyecta un salto de alrededor de 1000×; para cálculos específicos (firmas, SNARK/STARK) la agregación fuera de cadena podría multiplicar el rendimiento en ≈ 10 000×.

Recursos de datos

• Corto plazo: con mejoras p2p y Gas multidimensional, se apunta a un crecimiento de 10‑20×.
• Largo plazo: la combinación de *Blobs* + *PeerDAS* permitiría una mejora de aproximadamente 500×.

El objetivo inmediato es que Ethereum funcione más rápido. En la actualidad la validación ocurre de forma secuencial: cada transacción se revisa una a una, y si una se “cuelga”, todo el proceso se bloquea.

Por eso, la actualización Glamsterdam de este año introducirá *Block Access Lists* (BAL) y *ePBS*.

• Block Access Lists permite que el empaquetador del bloque indique previamente a los validadores qué cuentas y posiciones de almacenamiento serán leídas. Con esa información, los validadores pueden precargar los datos del disco a la memoria y, a partir de ahí, procesar varias transacciones en paralelo, como una línea de ensamblaje: antes un solo trabajador hacía todo el trabajo, ahora varios operan simultáneamente en diferentes etapas.
• ePBS separa la fase de empaquetado del bloque de la fase de validación: el creador del bloque agrupa las transacciones, el proponente propone el bloque y los validadores lo verifican. Cada rol se concentra en su responsabilidad, lo que permite al creador empaquetar de forma más agresiva, sabiendo que el proponente y los validadores revisarán la seguridad.
• Reprecificación del gas + Gas multidimensional es la herramienta central. Actualmente, todas las operaciones pagan el mismo precio de gas. Vitalik propone que distintas operaciones tengan tarifas diferenciadas. En particular, la creación de nuevo estado (por ejemplo, abrir una cuenta o desplegar un contrato) debería pagar una “tarifa de creación de estado” dedicada, ya que consume tanto recursos de cómputo como de almacenamiento permanente. La idea es: elevar el costo de crear estado y reducir el costo de transacciones ordinarias.

La implementación se basa en un “mecanismo de reservorio”. Imagínese dos piscinas de fondos: una para la “tarifa de creación de estado” y otra para el gas regular. Cuando los contratos se llaman entre sí, el gas se descuenta automáticamente de ambas piscinas, garantizando una distribución justa. Los usuarios finales pagarían menos por sus transacciones habituales, mientras que los desarrolladores que generen nuevo estado absorberían un cargo mayor, lo que ayuda a controlar el crecimiento del estado y a evitar que los discos de los nodos completos se saturen.

Expansión a largo plazo

El objetivo a largo plazo es que la capa base sea más robusta y dependa menos de las soluciones de capa 2. Las piezas clave son Blobs + PeerDAS y el despliegue escalonado de ZK‑EVM.

• Blobs son actualmente archivos temporales de gran tamaño pensados para uso de capa 2. En el futuro, la cadena principal también los consumirá. Sin embargo, si cada nodo tuviera que descargar todos los blobs, la red se vería sobrecargada.
• PeerDAS permite descargar solo una fracción del conjunto total (por ejemplo, 1/16) y, mediante pruebas ZK, comprobar la integridad completa, una especie de muestreo estadístico.
• Con el rollout escalonado de ZK‑EVM, los nodos al validar un bloque no tendrían que volver a ejecutar todas las transacciones; bastaría con verificar la prueba ZK correspondiente. Así, el costo de validación pasa de “ejecutar todas las transacciones” a “verificar una única prueba”. Vitalik planea que en 2026 algunos nodos prueben la verificación ZK, en 2027 se amplíe el uso y, al final, cada bloque válido deberá incluir 3 de los 5 tipos de pruebas de diferentes sistemas. Se prevé que, salvo los nodos de indexación, todos los demás dependerán de la ZK‑EVM.

No existe una solución mágica para escalar el estado

Ahora abordemos el recurso estado, que no se cubrió en detalle en los planes a corto y largo plazo. En el corto plazo, combinar *Block Access Lists*, mejoras p2p y optimizaciones de bases de datos podría ofrecer un aumento de 5‑30×, pero ¿qué pasa a largo plazo?

Vitalik responde que, por el momento, no hay una solución viable.

¿Por qué el estado es difícil de escalar?

El estado de Ethereum funciona como una enorme base de datos que registra balances, códigos de contrato y ubicaciones de almacenamiento. Actualmente ocupa alrededor de 100 GB; si se multiplica 20 veces, se llega a 2 TB, y a 80 veces, a 8 TB.

El problema no radica en la capacidad del disco, sino en:

1. Pérdida de eficiencia de la base de datos: las bases modernas utilizan estructuras de árbol (por ejemplo, Merkle Trees). Cada inserción requiere actualizar todo el árbol, lo que provoca múltiples operaciones de bajo nivel. A medida que aumenta la cantidad de actualizaciones, la velocidad de escritura crece exponencialmente, generando un cuello de botella.
2. Alto costo de sincronización: un nodo nuevo debe descargar el estado completo antes de poder validar bloques. Si el estado alcanza varios terabytes, la descarga mediante una conexión de banda ancha típica se vuelve imprácticamente lenta.

Limitaciones de las propuestas actuales

• Fuerte “statelessness”: los nodos no almacenan el estado completo y dependen de pruebas Merkle proporcionadas por los usuarios. Vitalik advierte que esto podría centralizar el almacenamiento, generar fallos de transacción por accesos dinámicos y elevar los costos de ancho de banda.
• Expiración del estado: eliminar del disco los estados que no se consultan frecuentemente, conservando solo los activos recientes. El gran obstáculo es demostrar que “un determinado estado nunca existió”. Por ejemplo, al crear una cuenta nueva, habría que probar que esa dirección no aparece en la historia completa, lo que implicaría revisar años de datos y resultaría prohibitivamente caro.

Nuevas formas de estado

Partiendo de esas ideas, Vitalik propone varias formas de estado novedosas, que implicarían una reconfiguración estructural del recurso de estado en Ethereum:

• Almacenamiento temporal: datos que expiran automáticamente, como estructuras de árbol que se reinician cada mes. Ideal para libros de órdenes, pools de liquidez o contadores que no requieren preservación permanente.
• Almacenamiento periódico: similar al temporal, pero con un ciclo de expiración más largo, por ejemplo 1 año.
• Almacenamiento restringido: solo accesible mediante interfaces específicas; por ejemplo, los balances de un token ERC‑20 podrían leerse exclusivamente a través de la función estándar `balanceOf`, lo que facilita optimizaciones focalizadas.

Al mismo tiempo, se mantiene la forma de estado tradicional. De esta manera, la capa de ejecución, con ZK‑EVM, podría acelerar alrededor de 1000×, mientras que la tarifa de creación de estado nuevo podría incrementarse solo ≈ 20×.

Los desarrolladores tendrían la libertad de elegir: seguir usando el estado clásico pagando una tarifa mayor, o rediseñar sus contratos para aprovechar las nuevas formas de estado y reducir costos. Para casos de uso comunes (por ejemplo, balances ERC‑20 o NFTs), se podrían estandarizar flujos de trabajo; en escenarios DeFi más complejos, correspondería a los programadores explorar optimizaciones propias.

Esta estrategia incentiva a la comunidad a buscar eficiencia sin sacrificar la experiencia del usuario final.

---

Adaptación local (LATAM)

• Métodos de pago: para adquirir servicios vinculados a la infraestructura de Ethereum (por ejemplo, tarifas de gas en plataformas de terceros), se aceptan SPEI en México, PSE en Colombia, Mercado Pago en Argentina y Nequi en Colombia.
• Identificación (KYC): la verificación de identidad se realiza mediante INE en México y DNI en los demás países de América Latina.
• Conversión de montos en USD: cuando sea necesario expresar valores en dólares, se incluyen entre paréntesis su equivalente aproximado en moneda local (1 USD ≈ 18 MXN, 1 USD ≈ 4 000 COP, 1 USD ≈ 1 000 ARS).
• Impuestos: recuerde que cualquier ingreso o gasto relacionado con criptomonedas está sujeto a la normativa fiscal de su país. En México, por ejemplo, los ingresos por actividades relacionadas con criptoactivos deben reportarse en la declaración anual y pueden estar gravados bajo la categoría de ganancias de capital. Consulte a un contador o asesor fiscal local para cumplir con sus obligaciones.

---

*Esta traducción mantiene la estructura y el contenido del artículo original, adaptando los elementos de localización solicitados y respetando las normas de divulgación sin ofrecer garantías de rendimiento ni consejos de inversión.*

💡 Regístrate en Binance con el código B2345 para el descuento máximo en comisiones. Ver guía completa Binance.

⚠️ Aviso de riesgo: Los precios de las criptomonedas son muy volátiles. Esto no es asesoramiento de inversión.