Ethereum presenta su hoja de ruta para la escalabilidad. ¿Qué hay de diferente esta vez?

Autor original: @VitalikButerin
Traducción: Peggy, BlockBeats

Nota del editor: A medida que el ecosistema Ethereum sigue creciendo, lograr la escalabilidad de la red sin sacrificar la seguridad y la descentralización se ha convertido en una cuestión fundamental. En este artículo, Vitalik Buterin describe con más detalle la trayectoria de escalabilidad de Ethereum: a corto plazo, mejorar la eficiencia de ejecución mediante la optimización del mecanismo Gas, la paralelización de la validación de bloques y otras mejoras técnicas; a largo plazo, confiar en ZK-EVM y la estructura de datos blobs para impulsar la escalabilidad de la red.

En general, esta hoja de ruta proporciona un plan de escalabilidad por fases diseñado para sentar las bases que permitan a Ethereum ampliar continuamente la capacidad de su red en los próximos años.

El siguiente es el texto original:

Ahora hablemos del escalado. Se puede dividir principalmente en dos partes: escalado a corto plazo y escalado a largo plazo.

Escalado a corto plazo

En cuanto al escalado a corto plazo, ya he escrito sobre ello en otra parte. La idea central es, a grandes rasgos, la siguiente:

· Las listas de acceso a nivel de bloque (que se introducirán en la actualización Glamsterdam) pueden permitir la paralelización de la validación de bloques.

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

· La revisión de los precios del gas garantizará que el coste del gas de las distintas operaciones se mantenga en consonancia con su tiempo de ejecución real (y otros costes en los que se incurra). También estamos empezando a explorar un mecanismo de gas multidimensional, que permite que diferentes recursos tengan límites separados. La combinación de estos dos elementos nos permite utilizar una mayor proporción del tiempo de ranura en la validación de bloques sin preocuparnos por situaciones extremas.

En cuanto al gas multidimensional, hemos elaborado una hoja de ruta por fases. La primera fase se encuentra en la actualización Glamsterdam, donde el «coste de configuración del estado» se separa de los «costes de ejecución y datos de llamada».

Por ejemplo, actualmente: una operación SSTORE cuesta 5000 gas si la ranura de almacenamiento cambia de no cero → no cero; cuesta 20000 gas si cambia de cero → no cero.

En un evento de reajuste de precios del gas en Glamsterdam, este coste adicional aumentará significativamente (por ejemplo, aumentará a 60 000). El objetivo es aumentar el coste y, al mismo tiempo, hacer que la tasa de expansión de la capacidad de ejecución sea significativamente mayor que la tasa de expansión del tamaño del estado.

En cuanto a los motivos, ya he escrito anteriormente: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

Por lo tanto, en Glamsterdam: Esta operación de SSTORE consumirá 5000 «gas base», es decir, 55 000 «gas de creación de estado».

Es importante tener en cuenta lo siguiente: El gas que crea estados no cuenta para el límite aproximado de 16 millones de gas de transacción.

Esto significa: Será posible crear contratos más grandes que los actuales.

¿Cómo se consigue el gas multidimensional en el EVM?

Aquí hay un problema: El diseño del EVM asume que el gas solo tiene una dimensión; por ejemplo, GAS, CALL y otros códigos de operación se basan en esta suposición.

Nuestra solución consiste en mantener dos invariantes:

Si inicias una llamada con X gas, esa llamada tendrá X gas disponible para «operaciones básicas», «creación de estados» o cualquier posible dimensión adicional futura.

Si el código de operación GAS te indica que actualmente tienes Y gas y, a continuación, inicias una llamada que consume X gas, después de que la llamada regrese, seguirás teniendo al menos Y − X gas disponible para operaciones posteriores.

La implementación específica es: Introducimos N+1 dimensiones de gas. Por defecto, N = 1 (creación de estado), y la dimensión adicional se denomina reservorio.

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

Si es posible, priorice el consumo de gas de dimensiones especializadas.

Si no es suficiente, consuma del depósito.

Por ejemplo, si tienes: (100 000 gas creado por el estado, 100 000 depósito)

Si utiliza SSTORE para crear tres nuevos estados, el proceso de transformación del gas es el siguiente: (100 000, 100 000) → (45 000, 95 000) → (0, 80 000) → (0, 20 000)

En este diseño:

El código de operación GAS devuelve el depósito.

CALL pasará una cantidad específica de gas del depósito y todo el gas que no provenga del depósito.

Precios multidimensionales del gas

Más adelante, introduciremos el precio multidimensional, que permite que diferentes dimensiones de recursos tengan diferentes precios flotantes del gas.

Esto traerá consigo:

Mejor sostenibilidad económica a largo plazo

Eficiencia optimizada en la asignación de recursos

Más información en: https://vitalik.eth.limo/general/2024/05/09/multidim.html

El mecanismo del depósito resuelve perfectamente el problema de las subllamadas mencionado al final de ese artículo.

Escalado a largo plazo

La ampliación a largo plazo implica principalmente dos direcciones: ZK-EVM y Blobs.

Manchas

En cuanto a los blobs, tenemos previsto seguir iterando en PeerDAS, con el objetivo de alcanzar finalmente un rendimiento de datos de aproximadamente 8 MB/segundo.

Esta escala:

Es suficiente para satisfacer las propias necesidades de Ethereum.

Y no pretende convertirse en 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 validen una red Ethereum altamente escalable sin necesidad de descargar y volver a ejecutar toda la cadena:

Los ZK-SNARK eliminan la necesidad de volver a ejecutar.

PeerDAS + blobs permiten verificar la disponibilidad de los datos sin necesidad de descargarlos todos.

ZK-EVM

En cuanto a ZK-EVM, nuestro objetivo es aumentar gradualmente la dependencia de la red respecto a este.

2026: Surgirán clientes compatibles con ZK-EVM, lo que permitirá a los nodos participar en la certificación con ZK-EVM. Sin embargo, aún no son lo suficientemente seguras como para permitir que toda la red dependa de ellas para su funcionamiento. No obstante, es aceptable que alrededor del 5 % de la red los utilice. (Si hay problemas con ZK-EVM, no se le penalizará con recortes, pero es posible que construya sobre bloques no válidos, lo que provocará una pérdida de ingresos).

2027: Comenzaremos a recomendar una mayor proporción de nodos para ejecutar ZK-EVM, al tiempo que nos centraremos en la verificación formal y las mejoras de seguridad. Incluso si solo el 20 % de la red utiliza ZK-EVM, podemos aumentar significativamente el límite de gas, ya que esto proporciona una vía de validación de bajo coste para los stakers individuales, y la proporción de stakers individuales es inferior al 20 %.

Madurez post-técnica: Introduciré un mecanismo de prueba obligatoria de 3 de 5. Es decir, un bloque debe contener al menos 3 pruebas de 5 sistemas de prueba diferentes para que se considere válido. Para entonces, esperamos que la mayoría de los nodos se basen en pruebas ZK-EVM, excepto los nodos que necesiten realizar indexación.

A largo plazo: Seguir mejorando ZK-EVM para hacerlo más robusto y someterlo a una verificación formal más estricta. Esta etapa también puede implicar cambios a nivel de la máquina virtual, como la dirección de RISC-V.

Véase: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

[Enlace al artículo original]