Evolución completa de la arquitectura EVM: estrategia de escalado gradual de Ethereum

A medida que el ecosistema de Ethereum se expande rápidamente, la forma en que se escalará la red mientras se protege la seguridad y la Descentralización ha surgido como uno de los desafíos más importantes. Este mapa tecnológico presentado por Vitalik Buterin ofrece un enfoque integral hacia la eficiencia y expansión del EVM. Es una estrategia que aumenta gradualmente la capacidad de procesamiento de Ethereum en dos capas diferentes: a corto plazo y a largo plazo.

Eficiencia a corto plazo de Ethereum EVM: Optimización de Gas y paralelización de la verificación de bloques

La estrategia de escalado a corto plazo se centra en maximizar la eficiencia operativa aprovechando el diseño de la máquina EVM existente. Se espera que las mejoras técnicas en torno a la actualización de Glamsterdam aumenten gradualmente la capacidad de procesamiento de la red.

La introducción de un mecanismo de lista de acceso a nivel de bloque permitirá paralelizar el proceso de verificación de bloques de EVM. Anteriormente, las tareas de verificación se ejecutaban de manera secuencial, pero ahora podrán ser procesadas simultáneamente en múltiples procesos, lo que reducirá el tiempo total de generación de bloques. Esta es una mejora que se traduce directamente en un aumento de la velocidad de procesamiento de transacciones en toda la red.

El ePBS (Separación de Propuesta-Creador Encriptada), que se implementará también en Glamsterdam, cuenta con múltiples funciones importantes. Un aspecto especialmente notable es la capacidad de extender el tiempo asignado para la validación de bloques en cada slot, pasando de los cientos de milisegundos tradicionales a una proporción de tiempo mayor. Esto permite una mayor holgura en el proceso de validación, lo que posibilita el procesamiento seguro de más datos.

Mecanismo del gas multidimensional: Innovación en el diseño de EVM

El mecanismo de revalorización del gas no es solo un ajuste de tarifas, sino que implica un cambio fundamental en la filosofía de diseño del EVM. Si los costos de gas de varias operaciones se corresponden exactamente con el tiempo de ejecución y el consumo de recursos correspondiente, será posible una asignación más eficiente de los recursos de la red.

La introducción del gas multidimensional evolucionará el mecanismo de gas que hasta ahora se gestionaba en una única dimensión a una estructura que permite una gestión de límites independiente para cada tipo de recurso. En la primera fase, se planea separar el “costo de creación de estado” del “costo de ejecución y calldata” en la actualización de Glamsterdam.

Por ejemplo, en la operación SSTORE actual, cambiar un slot de almacenamiento de cero a no cero consume 20000 gas. Después de la revalorización en Glamsterdam, se espera que este costo aumente considerablemente, alcanzando aproximadamente 60000 gas. Este cambio que a primera vista parece negativo, en realidad tiene un objetivo estratégico. Al expandir simultáneamente el límite de gas, se puede superar significativamente la velocidad de expansión de la capacidad de ejecución de la validación de bloques en comparación con la velocidad de expansión del tamaño del estado de la blockchain.

En el diseño existente de EVM, el gas se implementa como una única dimensión. Por lo tanto, todos los opcodes como GAS y CALL se basan en esta premisa, pero la transición hacia gas multidimensional necesita mantener esta suposición básica sin cambiarla y conservar la compatibilidad hacia atrás.

La solución adoptada debe cumplir con las siguientes condiciones inmutables. Primero, si se inicia una llamada con X gas, esa llamada debe poseer X gas y debe poder usarse para operaciones normales, creación de estados o en otras dimensiones que puedan añadirse en el futuro. En segundo lugar, si el opcode GAS indica que actualmente hay Y gas, al emitir una llamada que consuma X gas, debe quedar al menos Y - X gas después del retorno de la llamada, que debe estar disponible para operaciones posteriores.

En la implementación específica, se introducen N+1 dimensiones de gas. Por defecto, N=1 (creación de estado), y la dimensión adicional se llama “reservorio”. La lógica de ejecución de EVM está estructurada para consumir prioritariamente el gas de dimensiones dedicadas tanto como sea posible, y en caso de escasez, se realiza un consumo adicional desde el reservorio.

Por ejemplo, en la situación de poseer gas (100000 gas de creación de estado, 100000 reservorio ), si se utiliza SSTORE para crear un nuevo estado 3 veces, la transición de gas será (100000, 100000) → (45000, 95000) → (0, 80000) → (0, 20000). En este diseño, el opcode de GAS devuelve el reservorio, y CALL actuará pasando la cantidad especificada de gas desde el reservorio, mientras que también pasará todo el gas que no es del reservorio al mismo tiempo.

Se espera que la introducción de una estrategia de precios multidimensional que aplique diferentes tarifas de gas variables a múltiples dimensiones de recursos mejore la sostenibilidad económica a largo plazo y logre una mayor eficiencia en la asignación de recursos.

Ruta de escalado a largo plazo: fusión de ZK-EVM y Blobs

Las mejoras a corto plazo aumentan la eficiencia de las máquinas EVM existentes, mientras que la estrategia de escalado a largo plazo contempla cambios de diseño más fundamentales. Dos direcciones tecnológicas clave, ZK-EVM (verificación de ejecución de EVM basada en pruebas de conocimiento cero) y Blobs, darán forma al futuro de Ethereum.

En la actualidad, en 2026, la aparición de clientes compatibles con ZK-EVM está a punto de convertirse en una realidad. Estamos llegando a la etapa en la que los nodos podrán participar en la atestación (verificación de firma en la red) utilizando ZK-EVM. Sin embargo, en esta etapa inicial, estos clientes aún no han alcanzado un nivel de seguridad suficiente, por lo que la red en su totalidad no puede depender completamente de ellos. Se permite que aproximadamente el 5% de los nodos de la red utilicen ZK-EVM, pero se adoptará la política de abstenerse de una adopción superior a esa proporción. En esta etapa, si surgen problemas con la prueba de ZK-EVM, las recompensas de staking de nodos individuales no serán confiscadas, pero puede haber la posibilidad de construcción de bloques inválidos, lo que podría llevar a pérdidas en los ingresos de esos nodos.

En 2027, se avanzará hacia una etapa en la que se recomienda que más nodos ejecuten ZK-EVM. Es un momento en el que se pone énfasis en la verificación formal y la mejora continua de la seguridad. Lo importante es que con solo el 20% de los nodos de la red utilizando ZK-EVM, se puede lograr la provisión de rutas de verificación de bajo costo para los validadores solistas, lo que puede mejorar significativamente el límite de gas. Teniendo en cuenta que el número total de validadores solistas es en sí mismo menos del 20% de la red, esta mejora en esta etapa beneficiará a muchos usuarios.

Se planea introducir un mecanismo de prueba forzada 3-de-5 una vez que la tecnología esté lo suficientemente madura. Esto significa que, para que un bloque sea considerado válido, debe incluir al menos 3 pruebas de 5 sistemas de prueba diferentes. Este mecanismo de prueba diverso ayudará a reducir el riesgo de depender de una única tecnología y mejorará aún más la resiliencia de la red. En etapas posteriores, se espera que la mayoría de los nodos, a excepción de aquellos que requieren funciones de índice, transiten a un estado en el que dependen de pruebas ZK-EVM.

A largo plazo, se busca mejorar aún más la robustez del ZK-EVM y llevar a cabo una verificación formal más rigurosa. En esta etapa, se considerarán cambios estructurales a nivel de máquina virtual, incluyendo direcciones como RISC-V. Esto sugiere la posibilidad de evolucionar fundamentalmente el diseño de la máquina EVM.

Evolución hacia Blobs y capas de datos avanzadas

En cuanto a los Blobs, se está buscando alcanzar un rendimiento de datos de aproximadamente 8 MB/s gracias a la mejora continua de la capa de transporte PeerDA. Este nivel de capacidad de procesamiento de datos es lo suficientemente grande como para satisfacer adecuadamente la demanda de Ethereum. Sin embargo, no se pretende que Ethereum se convierta en una capa de datos a escala global, sino que satisface el nivel de demanda como una red independiente.

Actualmente, los Blobs se utilizan principalmente para el almacenamiento de datos en soluciones de capa 2 (L2). Como evolución futura, se está considerando la dirección de escribir directamente los datos del bloque de Ethereum en los Blobs. El objetivo de este cambio es de suma importancia. Será posible validar una red de Ethereum altamente escalada sin descargar y volver a ejecutar toda la cadena.

La realización de este objetivo combina dos tecnologías importantes. Primero, ZK-SNARKs (pruebas no interactivas de conocimiento cero y concisas) eliminan la necesidad del proceso de reejecución en sí. Luego, PeerDAS y Blobs permiten verificar la disponibilidad de los datos sin necesidad de descargar todos los datos. Esta combinación hace posible que incluso los nodos ligeros participen completamente en la verificación de la red.

La estrategia de escalado de Ethereum muestra un enfoque para expandir gradualmente la capacidad de la red, equilibrando la eficiencia a corto plazo y la evolución estructural a largo plazo. La continua optimización del EVM y la introducción gradual de nuevas tecnologías de validación determinarán el desarrollo de la red Ethereum en los próximos años.