Ethereum presenta su hoja de ruta de escalabilidad, ¿qué hay de diferente esta vez?

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

Nota del editor: A medida que el ecosistema de Ethereum sigue creciendo, 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 el camino de escalabilidad de Ethereum: a corto plazo, mejorando la eficiencia de ejecución a través de la optimización del mecanismo de Gas, la paralelización de la validación de bloques y otras actualizaciones técnicas; a largo plazo, confiando en ZK-EVM y la estructura de datos de 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 para que Ethereum expanda continuamente su capacidad de red en los próximos años.

El siguiente es el texto original:

Ahora hablemos sobre la escalabilidad. Se puede dividir principalmente en dos partes: escalabilidad a corto plazo y escalabilidad a largo plazo.

Escalabilidad a corto plazo

Respecto a la escalabilidad a corto plazo, he escrito sobre ello en otros lugares. La idea central es más o menos 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 (también se introducirá en Glamsterdam) tiene múltiples características, una de las cuales es: nos permite usar de manera segura una mayor proporción de tiempo en cada slot para validar bloques, en lugar de usar solo unos pocos cientos de milisegundos como ahora.

· La revalorización del gas asegurará que el costo del gas de varias operaciones se mantenga consistente con su tiempo de ejecución real (y otros costos que incurren). También estamos en las primeras etapas de explorar un mecanismo de gas multidimensional, permitiendo que diferentes recursos tengan límites separados. La combinación de estos dos puede permitirnos usar una mayor proporción del tiempo de slot en la validación de bloques sin preocuparnos por escenarios extremos.

Respecto al gas multidimensional, hemos trazado una hoja de ruta por fases. La primera fase está en la actualización de Glamsterdam, donde el "costo de configuración del estado" se separa de los "costos de ejecución y calldata."

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

En un evento de revalorización del gas en Glamsterdam, este costo adicional se incrementará significativamente (por ejemplo, se incrementará a 60000). El objetivo de esto es aumentar el costo mientras se hace 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.

Respecto a las razones, 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 "gas base," por ejemplo, 55000 "gas de creación de estado."

Es importante notar: El gas de creación de estado no cuenta para el límite de aproximadamente 16 millones de gas por transacción.

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

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

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

Nuestra solución es mantener dos invariantes:

Si inicias una llamada con X gas, esa llamada tendrá X gas disponible para "operaciones base," "creación de estado," o cualquier potencial dimensión adicional futura.

Si el opcode GAS te dice que actualmente tienes Y gas, y luego inicias una llamada que consume X gas, después de que la llamada regrese, aún tendrás 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 llama el reservorio.

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

Si es posible, priorizá consumir gas de dimensiones especializadas.

Si no es suficiente, consumí del reservorio.

Por ejemplo, si tenés: (100000 gas de creación de estado, 100000 reservorio)

Si usás SSTORE para crear tres nuevos estados, el proceso de transformación de gas es: (100000, 100000) → (45000, 95000) → (0, 80000) → (0, 20000)

En este diseño:

El opcode GAS devuelve el reservorio

CALL pasará una cantidad especificada de gas del reservorio y todo el gas no del reservorio

Precios de Gas Multi-Dimensionales

Más adelante, introduciremos más sobre precios multidimensionales, permitiendo que diferentes dimensiones de recursos tengan diferentes precios de gas flotantes.

Esto traerá:

Mejor sostenibilidad económica a largo plazo

Eficiencia optimizada en la asignación de recursos

Vé más en: https://vitalik.eth.limo/general/2024/05/09/multidim.html

El mecanismo del reservorio resuelve de manera ordenada el problema de sub-llamadas mencionado al final de ese artículo.

Escalabilidad a Largo Plazo

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

Blobs

Para los blobs, planeamos seguir iterando en PeerDAS, con el objetivo de lograr eventualmente un rendimiento de datos de aproximadamente 8 MB/segundo.

Esta escala:

Es suficiente para satisfacer las propias necesidades de Ethereum

Y no está destinado a convertirse en una "capa de datos global."

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

El propósito de hacer esto es permitir que las personas validen una red de Ethereum altamente escalable sin descargar y volver a ejecutar toda la cadena:

Los ZK-SNARKs eliminan la necesidad de re-ejecución

PeerDAS + blobs permiten la verificación de 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: Los clientes que soporten ZK-EVM surgirán, permitiendo que los nodos participen en la atestación con ZK-EVM. Sin embargo, aún no son lo suficientemente seguros como para permitir que toda la red dependa de ellos para su funcionamiento. No obstante, es aceptable si alrededor del 5% de la red los utiliza. (Si hay problemas con ZK-EVM, no serás penalizado en el slashing, pero podrías construir sobre bloques inválidos, lo que resultaría en pérdida de ingresos.)

2027: Comenzaremos a recomendar que una mayor proporción de nodos ejecute ZK-EVM, mientras nos enfocamos en la verificación formal y 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 un camino de validación de bajo costo para los stakers solitarios, y la proporción de stakers solitarios es menor al 20%.

Madurez post-técnica: Introduciremos 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 ser considerado válido. Para entonces, esperamos que la mayoría de los nodos se basen en las pruebas de ZK-EVM, excepto por los nodos que necesiten hacer indexación.

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

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

[Enlace al Artículo Original]