Ethereum presenta la hoja de ruta a escala, ¿qué es diferente esta vez?

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

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 un problema fundamental. En este artículo, Vitalik Buterin describe aún más la ruta de escalabilidad de Ethereum: en short plazo, mejorar 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; en long plazo, confiar en la estructura de datos ZK-EVM y blobs para impulsar la escalabilidad de la red.

En general, esta hoja de ruta proporciona un plan de escalabilidad escalonado diseñado para sentar las bases para que Ethereum amplíe continuamente su capacidad de red en los próximos años.

El texto original es el siguiente:

Ahora hablemos de escalabilidad. Se puede dividir principalmente en dos partes: escalado en short plazo y escalado en long plazo.

Escalabilidad en short plazo

Con respecto al escalamiento en short plazo, he escrito sobre ello en otro lugar. La idea central es aproximadamente la siguiente:

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

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

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

En cuanto al gas multidimensional, hemos establecido una hoja de ruta escalonada. La primera fase es en la actualización de Glamsterdam, donde el “costo de configuración del estado” está separado de los “costos de ejecución y calldata”.

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

En un evento de reprecio del gas en Glamsterdam, este coste adicional se incrementará significativamente (por ejemplo, hasta 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 los motivos, ya 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 de SSTORE consumirá 5000 “gas base”, por ejemplo, 55000 “gas creador de estado”.

Es importante tener en cuenta: El gas generador de estado no se cuenta para el límite de aproximadamente 16 millones de gas de transacción.

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

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

Aquí tienes un problema: El diseño de la 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 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 posible dimensión adicional futura.

Si el código de operación de GAS te dice que actualmente tienes gas Y, y luego inicias una llamada que consume gas X, después de que la llamada regrese, aún tienes al menos gas Y − X 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 depósito.

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

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

Si no es suficiente, consumir del depósito.

Por ejemplo, si tienes: (100000 gas de creación estatal, 100.000 depósito)

Si usas 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 código de operación GAS devuelve el depósito

CALL pasará un monto (según contexto) específico de gas desde el yacimiento y todo el gas no

Precios de gas multidimensionales

Más tarde, introduciremos aún más los precios multidimensionales, lo que permitirá que las diferentes dimensiones de los recursos tengan diferentes precios del gas flotante.

Esto traerá:

Mejor sostenibilidad económica en long 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 de depósito resuelve pulcramente el problema de subconvocatoria mencionado al final de ese artículo.

Escalabilidad en long plazo

El escalado en long plazo implica principalmente dos direcciones: ZK-EVM y Blobs.

Manchas

Para los blobs, planeamos continuar iterando en PeerDAS, con el objetivo de lograr en su evento 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, las manchas se utilizan principalmente para L2. El plan de futuro es que los datos del bloque Ethereum se escriban directamente en blobs.

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

Los ZK-SNARK eliminan la necesidad de volver a ejecutarse

Los blobs PeerDAS + permiten 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 ella.

2026: Surgirán clientes que admitan ZK-EVM, lo que permitirá que los nodos participen en la certificación con ZK-EVM. Sin embargo, todavía no son lo suficientemente seguros como para permitir que toda la red dependa de ellos para su funcionamiento. Sin embargo, es aceptable si alrededor del 5% de la red los utiliza. (Si hay problemas con ZK-EVM, no se te penalizará por cortar, pero puedes construir sobre bloques no válidos, lo que provocará la pérdida de ingresos.)

2027: Comenzaremos a recomendar una mayor proporción de nodos para ejecutar ZK-EVM, mientras nos enfocamos en 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 una ruta de validación de bajo costo para los staker individuales, y la proporción de staker individuales es menor al 20%.

Vencimiento posttécnico: Introduciremos un mecanismo de prueba obligatoria de 3 de 5. Es decir, un bloque debe contener al menos 3 pruebas de 5 sistemas de pruebas diferentes para considerarse válido. Para entonces, esperamos que la mayoría de los nodos se basen en pruebas ZK-EVM, excepto los nodos que necesitan hacer indexación.

En long plazo: Continuar mejorando ZK-EVM para hacerlo más robusto y someterse a una verificación formal más estricta. Esta etapa también puede implicar 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 original]