Ahora, la escalabilidad.
Se distinguen dos categorías: corto plazo y largo plazo.
La escalabilidad a corto plazo ya ha sido abordada en otros espacios. Básicamente:
Las listas de acceso a nivel de bloque (próximas en Glamsterdam) permiten verificar bloques en paralelo.
ePBS (próxima en Glamsterdam) incorpora varias funciones, una de ellas es que permite usar una mayor parte de cada slot (en vez de solo unos cientos de milisegundos) para verificar un bloque de forma segura.
La nueva tarificación del gas garantiza que los costes de gas de las operaciones reflejen el tiempo real de ejecución (junto con otros costes asociados). Además, se están dando los primeros pasos hacia el gas multidimensional, que asegura que los diferentes recursos tengan límites específicos. Ambas mejoras permiten usar una mayor parte del slot para verificar bloques, sin riesgo de casos excepcionales.
Existe una hoja de ruta en varias etapas para el gas multidimensional.
En primer lugar, en Glamsterdam, se separan los costes de “creación de estado” de los de “ejecución y calldata”. Actualmente, un SSTORE que modifica un slot de no cero a no cero cuesta 5000 gas, mientras que uno que pasa de cero a no cero cuesta 20000. Uno de los cambios de tarificación en Glamsterdam incrementa mucho esa diferencia (por ejemplo, hasta 60000); el objetivo, junto con los aumentos del límite de gas, es escalar la capacidad de ejecución mucho más que la capacidad de tamaño de estado, por razones ya explicadas previamente (
https://
ethresear.ch/t/hyper-scalin
g-state-by-creating-new-forms-of-state/24052
). Así, en Glamsterdam, ese SSTORE cobrará 5000 gas “regular” y (por ejemplo) 55000 gas de “creación de estado”.
El gas de creación de estado NO contará para el límite de ~16 millones de gas por transacción, por lo que será posible crear contratos más grandes que los actuales.
Un reto es: ¿cómo se implementa esto en la EVM? Los códigos de operación de la EVM (GAS, CALL…) asumen solo una dimensión. La propuesta es mantener dos invariantes:
Si haces una llamada con X gas, esa llamada dispone de X gas utilizable para “regular”, “creación de estado” o futuras dimensiones.
Si invocas el código de operación GAS, te indica que tienes Y gas; luego haces una llamada con X gas, y aún te quedan al menos Y-X gas, utilizable para cualquier función, después de la llamada para operar posteriormente.
Lo que se propone es crear N+1 “dimensiones” de gas, donde por defecto N=1 (creación de estado), y la dimensión adicional se denomina “reservorio”. La ejecución de la EVM consume primero las dimensiones especializadas si es posible, y si no, del reservorio. Por ejemplo, con (100000 gas de creación de estado, 100000 reservorio), al usar SSTORE para crear nuevo estado tres veces, el gas restante evoluciona así: (100000, 100000) → (45000, 95000) → (0, 80000) → (0, 20000). GAS devuelve el reservorio. CALL transmite la cantidad especificada del reservorio, junto con todo el gas no reservorio.
En una etapa posterior, se introduce la tarifación multidimensional, en la que cada dimensión puede tener precios de gas flotantes distintos. Esto permite una sostenibilidad y eficiencia económica a largo plazo (ver
https://
vitalik.eth.limo/general/2024/0
5/09/multidim.html
). El mecanismo de reservorio resuelve el problema de sub-llamadas mencionado al final de ese artículo.
Para la escalabilidad a largo plazo, hay dos elementos clave: ZK-EVM y blobs.
Respecto a los blobs, el plan es seguir iterando con PeerDAS hasta alcanzar un estado final en el que pueda manejar idealmente ~8 MB/s de datos. Esto cubriría las necesidades de Ethereum, sin pretender ser una capa global de datos. Actualmente, los blobs se usan para L2s. En el futuro, se prevé que los datos de bloque de Ethereum se almacenen directamente en blobs. Esto es necesario para que alguien pueda validar una cadena hiper-escalada de Ethereum sin descargar y re-ejecutar personalmente: los ZK-SNARKs eliminan la necesidad de re-ejecutar, y PeerDAS sobre blobs permite verificar la disponibilidad sin descargar los datos.
En cuanto a ZK-EVM, el objetivo es aumentar progresivamente la confianza en su uso:
En 2026 existirán clientes que permitan participar como attestador con ZK-EVMs. No serán suficientemente seguros para que la red opere sobre ellos, pero, por ejemplo, que el 5 % de la red dependa de ellos será aceptable. (Si el ZK-EVM falla, no serás penalizado, solo tendrás el riesgo de construir sobre un bloque inválido y perder ingresos)
En 2027 se recomendará que una mayor minoría de la red opere sobre ZK-EVMs, y se enfocará en la verificación formal y maximización de la seguridad. Incluso que el 20 % de la red funcione sobre ZK-EVMs permitirá aumentar significativamente el gaslimit, ya que facilita límites de gas mayores y una ruta económica para los stakers individuales, que ya representan menos del 20 %.
Cuando esté listo, se implementará la prueba obligatoria 3-de-5. Para que un bloque sea válido, deberá contener 3 de 5 tipos de pruebas de distintos sistemas. En ese momento, se espera que todos los nodos (excepto los que requieren indexación) dependan de pruebas ZK-EVM.
Seguir mejorando el ZK-EVM y hacerlo lo más robusto y verificado formalmente posible. Esto también implicará cambios en la VM (por ejemplo, RISC-V).
Aviso legal:
- Este artículo es una reimpresión de [vitalikbuterin]. Todos los derechos de autor pertenecen al autor original [vitalikbuterin]. Si tiene objeciones a esta reimpresión, contacte al equipo de Gate Learn y lo gestionarán de inmediato.
- Aviso de responsabilidad: Las opiniones expresadas en este artículo corresponden únicamente al autor y no constituyen consejo de inversión.
- Las traducciones a otros idiomas son realizadas por el equipo de Gate Learn. Salvo indicación contraria, está prohibido copiar, distribuir o plagiar los artículos traducidos.
