Nota del editor: A medida que el ecosistema de Ethereum continúa expandiéndose, cómo lograr la escalabilidad de la red sin sacrificar la seguridad y la descentralización se ha convertido en un tema central. En este artículo, Vitalik Buterin detalla aún más la ruta de escalabilidad de Ethereum: a corto plazo, mejorar la eficiencia de ejecución mediante optimizaciones en el mecanismo de gas y la paralelización de la verificación de bloques; a largo plazo, impulsar la expansión de la red mediante ZK-EVM y la arquitectura de datos blobs.

En general, esta hoja de ruta proporciona un plan de escalabilidad por fases, destinado a sentar las bases para que Ethereum continúe expandiendo su capacidad de red en los próximos años.

A continuación, el texto original:

Hablemos ahora de la escalabilidad (scaling). Esto se divide principalmente en dos partes: escalabilidad a corto plazo y escalabilidad a largo plazo.

Escalabilidad a corto plazo

Sobre la escalabilidad a corto plazo, ya he escrito en otros lugares. La idea central es más o menos la siguiente:

· Las listas de acceso a nivel de bloque (block-level access lists) (que se lanzarán en la actualización Glamsterdam) pueden permitir la paralelización de la verificación de bloques.

· ePBS (también se lanzará en Glamsterdam) tiene múltiples características, una de las cuales es: nos permite utilizar de forma segura una mayor proporción del tiempo de cada slot para verificar bloques, en lugar de usar solo unos cientos de milisegundos como ahora.

· La repreciación del gas (gas repricing) asegurará que el coste de gas de varias operaciones coincida con su tiempo de ejecución real (y otros costes que conllevan). También estamos explorando de forma temprana un mecanismo de gas multidimensional (multidimensional gas), que permite establecer límites separados para diferentes recursos. La combinación de estos dos aspectos nos permitirá utilizar una mayor proporción del tiempo del slot al verificar bloques, sin preocuparnos por casos extremos.

Sobre el gas multidimensional, hemos trazado una hoja de ruta por fases. La primera fase es en la actualización Glamsterdam, separando el «coste de creación de estado» del «coste de ejecución y calldata».

Por ejemplo, actualmente: una operación SSTORE, si cambia un slot de almacenamiento de distinto de cero → distinto de cero, cuesta 5000 gas; si cambia de cero → distinto de cero, cuesta 20000 gas.

En una repreciación del gas en Glamsterdam, este coste adicional se incrementará significativamente (por ejemplo, a 60000). El objetivo es, al aumentar el límite de gas, que la capacidad de ejecución se escale mucho más rápido que el tamaño del estado.

Sobre el porqué, ya lo he escrito antes: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

Por lo tanto, en Glamsterdam: esta operación SSTORE consumirá 5000 de «gas normal», y por ejemplo 55000 de «gas de creación de estado».

Es importante señalar: el gas de creación de estado no contará para el límite de gas de transacción de unos 16 millones.

Esto significa: será posible crear contratos más grandes que ahora.

¿Cómo se implementa el Gas Multidimensional en la EVM?

Aquí surge un problema: el diseño de la EVM asume por defecto que el gas tiene una sola dimensión, por ejemplo, los opcodes GAS, CALL, etc., se basan en esta suposición.

Nuestro método de solución es mantener dos invariantes:

Si inicias una llamada (call) con X gas, entonces esa llamada tendrá X gas, que se puede usar para «operaciones normales», o «creación de estado», u otras dimensiones que puedan añadirse en el futuro.

Si el opcode GAS te indica que tienes Y gas, y luego inicias una llamada que consume X gas, después de que la llamada regrese, todavía tendrás al menos Y − X gas para operaciones posteriores.

La forma concreta de implementarlo es: introducimos N+1 dimensiones de gas. Por defecto N = 1 (creación de estado), la dimensión adicional se llama reservoir (depósito de reserva).

La lógica de ejecución de la EVM es:

Si es posible, consumir primero el gas de la dimensión específica.

Si no es suficiente, consumir del reservoir.

Por ejemplo, si tienes: (100000 gas de creación de estado, 100000 reservoir)

Si realizas tres operaciones SSTORE creando nuevo estado, el cambio de gas sería: (100000, 100000)→ (45000, 95000)→ (0, 80000)→ (0, 20000)

En este diseño:

El opcode GAS devuelve el valor del reservoir.

CALL transferirá la cantidad especificada de gas desde el reservoir, y también transferirá todo el gas que no sea del reservoir.

Precios de Gas Multidimensionales

Posteriormente, introduciremos precios multidimensionales (multi-dimensional pricing), permitiendo que diferentes dimensiones de recursos tengan precios de gas flotantes diferentes.

Esto traerá:

Mejor sostenibilidad económica a largo plazo.

Eficiencia óptima en la asignación de recursos.

Para más detalles: https://vitalik.eth.limo/general/2024/05/09/multidim.html

Y el mecanismo del reservoir resuelve precisamente el problema de las sub-llamadas (sub-call) mencionado al final de ese artículo.

Escalabilidad a Largo Plazo

La escalabilidad a largo plazo incluye principalmente dos direcciones: ZK-EVM y Blobs.

Blobs

Para los blobs, planeamos iterar continuamente PeerDAS, con el objetivo final de alcanzar una capacidad de procesamiento de datos de aproximadamente 8 MB/segundo.

Esta escala:

Es suficiente para satisfacer las propias necesidades de Ethereum.

No pretende ser una «capa de datos global».

Actualmente, los blobs se utilizan principalmente para L2. El plan futuro es que los datos de los bloques de Ethereum se escriban directamente en blobs.

El objetivo de esto es permitir que las personas puedan verificar una red de Ethereum altamente escalada sin tener que descargar y re-ejecutar toda la cadena:

Los ZK-SNARKs eliminan la necesidad de re-ejecutar.

PeerDAS + blobs permite verificar la disponibilidad de datos sin descargar todos los datos.

ZK-EVM

Para ZK-EVM, nuestro objetivo es aumentar gradualmente la dependencia de la red en él.

2026: Aparecerán clientes compatibles con ZK-EVM, permitiendo que los nodos participen en la attestation usando ZK-EVM. Pero aún no serán lo suficientemente seguros como para que toda la red dependa de ellos. Sin embargo, si alrededor del 5% de la red los usa, es aceptable. (Si ZK-EVM falla, no serás penalizado con un slashing, pero podrías construir sobre un bloque inválido y perder ganancias).

2027: Comenzaremos a recomendar que una mayor proporción de nodos ejecuten ZK-EVM, centrándonos al mismo tiempo en la verificación formal y la mejora de la seguridad. Incluso si solo el 20% de la red usa ZK-EVM, podrí aumentar significativamente el límite de gas, ya que esto proporciona una ruta de verificación de bajo costo para los solo stakers, cuya proporción en sí misma es inferior al 20%.

Una vez madure la tecnología: Introduciremos un mecanismo de prueba forzada 3-de-5. Es decir, un bloque debe incluir al menos 3 pruebas de 5 sistemas de prueba diferentes para ser considerado válido. Para entonces, esperamos que, excepto los nodos que necesiten hacer indexación, la mayoría de los nodos dependan de las pruebas ZK-EVM.

A largo plazo: Continuar mejorando ZK-EVM, haciéndolo más robusto y realizando una verificación formal más estricta. Esta etapa también implicará posibles cambios a nivel de máquina virtual, como en la dirección de RISC-V, etc.

Para más detalles: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052