Posibles direcciones futuras del protocolo Ethereum: Capítulo de prosperidad
El diseño del protocolo Ethereum tiene muchos "detalles" importantes que son cruciales para su éxito. Aproximadamente la mitad del contenido se refiere a diferentes tipos de mejoras de EVM, mientras que el resto está compuesto por una variedad de temas de nicho, y esa es la esencia de "prosperidad".
Prosperidad: objetivo clave
Convertir el EVM en un "estado final" de alto rendimiento y estable
Introducir la abstracción de cuentas en el protocolo, permitiendo a todos los usuarios disfrutar de cuentas más seguras y convenientes.
Optimizar la economía de las tarifas de transacción, mejorar la escalabilidad mientras se reduce el riesgo
Explorar la criptografía avanzada para mejorar significativamente Ethereum a largo plazo.
Mejora de EVM
¿Qué problema resolvió?
Actualmente, el EVM es difícil de analizar estáticamente, lo que dificulta la creación de implementaciones eficientes, la verificación formal del código y la realización de futuras expansiones. Además, la eficiencia del EVM es baja, lo que dificulta la implementación de muchas formas de criptografía avanzada, a menos que se soporte explícitamente a través de precompilados.
¿Qué es y cómo funciona?
El primer paso en la hoja de ruta de mejora del EVM actual es el formato de objeto EVM (EOF), que se planea incluir en la próxima bifurcación dura. EOF es una serie de EIP que especifica una nueva versión del código EVM, con muchas características únicas, siendo la más notable:
El código ( es ejecutable, pero no se puede leer desde el EVM. ) y los datos ( se pueden leer, pero no se pueden ejecutar entre la separación.
Prohibido el salto dinámico, solo se permite el salto estático
El código EVM ya no puede observar información relacionada con el combustible
Se ha añadido un nuevo mecanismo de subrutina explícita.
La estructura del código EOF incluye la sección de código, la sección de datos y la sección de información de tipo.
![Vitalik sobre el posible futuro de Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Tras la introducción de EOF, las actualizaciones adicionales se han vuelto más fáciles. Actualmente, el desarrollo más avanzado es la extensión aritmética del módulo EVM ) EVM-MAX (. EVM-MAX crea un conjunto de nuevas operaciones específicas para la aritmética modular y las coloca en un nuevo espacio de memoria que no se puede acceder mediante otros códigos de operación, lo que hace posible utilizar optimizaciones como la multiplicación de Montgomery.
Una idea más reciente es combinar EVM-MAX con la característica de múltiples datos de una sola instrucción )SIMD(. SIMD se puede utilizar para acelerar muchas formas de criptografía, incluidos los hash, STARKs de 32 bits y criptografía basada en rejillas. La combinación de EVM-MAX y SIMD hace que estas dos extensiones orientadas al rendimiento sean una pareja natural.
) enlaces de investigación existentes
EOF:
EVM-MAX:
SIMD:
El trabajo restante y la ponderación
Actualmente, se planea incluir EOF en la próxima bifurcación dura. Aunque siempre existe la posibilidad de eliminarlo en el último momento, hacerlo representará un gran desafío. Eliminar EOF significa que cualquier actualización futura de EVM deberá realizarse sin EOF; aunque es posible, podría ser más difícil.
El principal compromiso del EVM radica en la complejidad de L1 y la complejidad de la infraestructura. EOF es una gran cantidad de código que necesita ser añadido a la implementación del EVM, y la verificación de código estática también es relativamente compleja. Sin embargo, a cambio, podemos simplificar los lenguajes de alto nivel, simplificar la implementación del EVM y otros beneficios. Se puede decir que la hoja de ruta para priorizar la mejora continua de Ethereum L1 debe incluir y basarse en EOF.
Una tarea importante que debe realizarse es implementar funciones similares a EVM-MAX junto con SIMD, y llevar a cabo pruebas de referencia sobre el consumo de gas de varias operaciones criptográficas.
¿Cómo interactuar con otras partes del mapa de ruta?
L1 ajusta su EVM para que L2 también pueda realizar ajustes correspondientes más fácilmente. Si ambos no sincronizan sus ajustes, puede haber incompatibilidades que traerán efectos adversos. Además, EVM-MAX y SIMD pueden reducir el costo de gas de muchos sistemas de prueba, lo que hace que L2 sea más eficiente. También facilita reemplazar más precompilados por código EVM que puede realizar las mismas tareas, lo que probablemente no afectará significativamente la eficiencia.
![Vitalik sobre el posible futuro de Ethereum (Seis): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
Abstracción de cuentas
) ¿Qué problema se resolvió?
Actualmente, las transacciones solo se pueden verificar de una manera: firma ECDSA. Inicialmente, la abstracción de cuentas estaba destinada a ir más allá de esto, permitiendo que la lógica de verificación de cuentas fuera código EVM arbitrario. Esto puede habilitar una serie de aplicaciones:
Cambiar a criptografía post-cuántica
Rotar la clave antigua ### es ampliamente considerado como una práctica de seguridad recomendada (
Monedero de múltiples firmas y monedero de recuperación social
Usar una clave para operaciones de bajo valor, usar otra clave ) o un conjunto de claves ( para operaciones de alto valor.
Permitir que el protocolo de privacidad funcione sin intermediarios, reduciendo significativamente su complejidad y eliminando un punto de dependencia central clave.
Desde que se propuso la abstracción de cuentas en 2015, su objetivo también se ha ampliado para incluir una gran cantidad de "objetivos de conveniencia", por ejemplo, una cuenta que no tiene ETH pero posee algunos ERC20 puede utilizar ERC20 para pagar el gas.
![Vitalik sobre el posible futuro de Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) ¿Qué es y cómo funciona?
El núcleo de la abstracción de cuentas es simple: permite que los contratos inteligentes inicien transacciones, y no solo EOA. Toda la complejidad proviene de implementar esto de una manera que sea favorable para el mantenimiento de redes descentralizadas y prevenir ataques de denegación de servicio.
Un desafío clave típico es el problema de múltiples fallos: si hay 1000 funciones de validación de cuentas que dependen de un único valor S, y el valor S actual hace que las transacciones en el mempool sean todas válidas, entonces una única transacción que invierte el valor de S puede hacer que todas las demás transacciones en el mempool sean inválidas. Esto permite a un atacante enviar transacciones basura al mempool a un costo muy bajo, obstruyendo así los recursos de los nodos de la red.
Después de años de esfuerzo, con el objetivo de expandir las funciones mientras se limita el riesgo de denegación de servicio ###DoS(, finalmente se llegó a la solución para lograr "abstracción ideal de cuentas": ERC-4337.
El funcionamiento de ERC-4337 divide el procesamiento de las operaciones del usuario en dos etapas: verificación y ejecución. Todas las verificaciones se procesan primero, y todas las ejecuciones se procesan después. En el pool de memoria, solo se aceptarán las operaciones del usuario cuya etapa de verificación solo involucre su propia cuenta y no lea variables de entorno. Esto puede prevenir ataques de doble gasto. Además, se imponen estrictos límites de gas a la etapa de verificación.
![Vitalik sobre el posible futuro de Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
) enlace de investigación existente
Discurso sobre la historia de la abstracción de cuentas:
ERC-4337:
EIP-7702:
El código BLSWallet ### utiliza la función de agregación (:
EIP-7562) escritura de la cuenta abstracta del protocolo (:
EIP-7701) cuenta abstracta de protocolo de escritura basada en EOF (:
) El trabajo restante y las consideraciones
Actualmente, lo que se necesita resolver principalmente es cómo introducir completamente la abstracción de cuentas en el protocolo. El EIP de abstracción de cuentas de escritura de protocolo que ha ganado popularidad recientemente es el EIP-7701, que implementa la abstracción de cuentas sobre el EOF. Una cuenta puede tener una parte de código separada para la verificación; si la cuenta establece esa parte de código, entonces ese código se ejecutará en el paso de verificación de las transacciones provenientes de esa cuenta.
El encanto de este método radica en que muestra claramente dos perspectivas equivalentes de la abstracción de cuentas locales:
Incluir EIP-4337 como parte del protocolo
Un nuevo tipo de EOA, donde el algoritmo de firma es la ejecución de código EVM.
Si comenzamos estableciendo límites estrictos sobre la complejidad del código ejecutable durante el período de verificación, entonces la seguridad de este enfoque es muy clara: simplemente reemplazar la verificación ECDSA por la ejecución de código EVM que requiere un tiempo similar.
Sin embargo, con el paso del tiempo, necesitamos relajar estos límites, ya que permitir que aplicaciones de protección de la privacidad funcionen sin intermediarios, así como la resistencia cuántica, son muy importantes. Para ello, necesitamos encontrar formas más flexibles de abordar el riesgo de denegación de servicio ###DoS(, sin requerir que los pasos de verificación sean extremadamente simplistas.
El principal compromiso parece ser "escribir rápidamente una solución que satisfaga a menos personas" frente a "esperar más tiempo para posiblemente obtener una solución más ideal". El enfoque ideal podría ser algún tipo de enfoque híbrido. Un enfoque híbrido sería escribir más rápidamente algunos casos de uso y reservar más tiempo para explorar otros casos de uso. Otro enfoque sería implementar primero una versión de abstracción de cuentas más ambiciosa en L2. Sin embargo, el desafío que enfrenta esto es que el equipo de L2 necesita tener confianza en el trabajo de la propuesta adoptada para estar dispuesto a implementarla, especialmente para garantizar que L1 y/o otros L2 puedan adoptar soluciones compatibles en el futuro.
Otra aplicación que necesitamos considerar claramente es la cuenta de almacenamiento de claves, que almacena el estado relacionado con la cuenta en L1 o en L2 dedicado, pero puede ser utilizada en L1 y en cualquier L2 compatible. Hacer esto de manera efectiva puede requerir que L2 soporte códigos de operación como L1SLOAD o REMOTESTATICCALL, pero también requiere que la implementación de abstracción de cuentas en L2 soporte estas operaciones.
) ¿Cómo interactúa con otras partes del mapa de ruta?
La lista de inclusión necesita soportar transacciones de abstracción de cuentas. En la práctica, la necesidad de la lista de inclusión es muy similar a la necesidad de un pool de memoria descentralizado, aunque hay un poco más de flexibilidad en la lista de inclusión. Además, la implementación de la abstracción de cuentas debería coordinarse tanto como sea posible entre L1 y L2. Si en el futuro esperamos que la mayoría de los usuarios utilicen un Rollup de almacenamiento de claves, el diseño de la abstracción de cuentas debería basarse en esto.
![Vitalik sobre el posible futuro de Ethereum (seis): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
Mejora EIP-1559
) ¿Qué problema resuelve?
EIP-1559 se activó en Ethereum en 2021, mejorando significativamente el tiempo promedio de inclusión de bloques. Sin embargo, la implementación actual de EIP-1559 no es perfecta en varios aspectos:
La fórmula tiene un ligero defecto: no está dirigida a un objetivo del 50% de los bloques, sino a aproximadamente el 50-53% de bloques completos, dependiendo de la varianza ###, lo que está relacionado con lo que los matemáticos llaman "desigualdad de la media aritmética-geométrica" (.
En situaciones extremas, el ajuste no es lo suficientemente rápido.
La fórmula para blobs ) EIP-4844 está diseñada específicamente para resolver el primer problema, y en general es más sencilla. Sin embargo, tanto EIP-1559 como EIP-4844 no han intentado resolver el segundo problema. Por lo tanto, la situación actual es un estado intermedio confuso, que involucra dos mecanismos diferentes, y hay una opinión que sostiene que, con el tiempo, ambos necesitan ser mejorados.
Además, hay otras debilidades en la fijación de precios de recursos de Ethereum que no están relacionadas con EIP-1559, pero que pueden mitigarse mediante ajustes a EIP-1559. Uno de los principales problemas es la diferencia entre la situación promedio y la peor: el precio de los recursos en Ethereum debe establecerse para poder manejar la peor situación, es decir, el consumo total de gas de un bloque ocupa un recurso, pero el uso promedio real está muy por debajo de esto, lo que lleva a la ineficiencia.
( ¿Qué es el Gas multidimensional y cómo funciona?
La solución a estos problemas de ineficiencia es el Gas multidimensional: establecer diferentes precios y límites para diferentes recursos. Este concepto es técnicamente independiente de EIP-1559, pero EIP-1
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
14 me gusta
Recompensa
14
7
Compartir
Comentar
0/400
MissedAirdropBro
· 07-26 03:16
¡¿Por qué otra vez la abstracción de cuentas?!
Ver originalesResponder0
BrokenDAO
· 07-25 06:25
Otra hoja de ruta ambiciosa, lo más probable es que termine repitiendo el destino de Casper.
Ver originalesResponder0
GasGuru
· 07-24 20:52
Suena bastante confiable, eh.
Ver originalesResponder0
SigmaBrain
· 07-24 20:51
¿Qué? ¿Esta versión todavía necesita cambios?
Ver originalesResponder0
OPsychology
· 07-24 20:45
¿Cuándo estará disponible esta actualización?
Ver originalesResponder0
WalletWhisperer
· 07-24 20:31
los patrones de comportamiento sugieren que evm2.0 provocará migraciones masivas de billeteras... estadísticamente inevitable
Ver originalesResponder0
Whale_Whisperer
· 07-24 20:29
La actualización de EVM debería haberse propuesto antes. Esta tarifa de gas realmente no se puede soportar.
El futuro plano del protocolo Ethereum: actualización de EVM, abstracción de cuentas y optimización de tarifas
Posibles direcciones futuras del protocolo Ethereum: Capítulo de prosperidad
El diseño del protocolo Ethereum tiene muchos "detalles" importantes que son cruciales para su éxito. Aproximadamente la mitad del contenido se refiere a diferentes tipos de mejoras de EVM, mientras que el resto está compuesto por una variedad de temas de nicho, y esa es la esencia de "prosperidad".
Prosperidad: objetivo clave
Mejora de EVM
¿Qué problema resolvió?
Actualmente, el EVM es difícil de analizar estáticamente, lo que dificulta la creación de implementaciones eficientes, la verificación formal del código y la realización de futuras expansiones. Además, la eficiencia del EVM es baja, lo que dificulta la implementación de muchas formas de criptografía avanzada, a menos que se soporte explícitamente a través de precompilados.
¿Qué es y cómo funciona?
El primer paso en la hoja de ruta de mejora del EVM actual es el formato de objeto EVM (EOF), que se planea incluir en la próxima bifurcación dura. EOF es una serie de EIP que especifica una nueva versión del código EVM, con muchas características únicas, siendo la más notable:
La estructura del código EOF incluye la sección de código, la sección de datos y la sección de información de tipo.
![Vitalik sobre el posible futuro de Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Tras la introducción de EOF, las actualizaciones adicionales se han vuelto más fáciles. Actualmente, el desarrollo más avanzado es la extensión aritmética del módulo EVM ) EVM-MAX (. EVM-MAX crea un conjunto de nuevas operaciones específicas para la aritmética modular y las coloca en un nuevo espacio de memoria que no se puede acceder mediante otros códigos de operación, lo que hace posible utilizar optimizaciones como la multiplicación de Montgomery.
Una idea más reciente es combinar EVM-MAX con la característica de múltiples datos de una sola instrucción )SIMD(. SIMD se puede utilizar para acelerar muchas formas de criptografía, incluidos los hash, STARKs de 32 bits y criptografía basada en rejillas. La combinación de EVM-MAX y SIMD hace que estas dos extensiones orientadas al rendimiento sean una pareja natural.
) enlaces de investigación existentes
El trabajo restante y la ponderación
Actualmente, se planea incluir EOF en la próxima bifurcación dura. Aunque siempre existe la posibilidad de eliminarlo en el último momento, hacerlo representará un gran desafío. Eliminar EOF significa que cualquier actualización futura de EVM deberá realizarse sin EOF; aunque es posible, podría ser más difícil.
El principal compromiso del EVM radica en la complejidad de L1 y la complejidad de la infraestructura. EOF es una gran cantidad de código que necesita ser añadido a la implementación del EVM, y la verificación de código estática también es relativamente compleja. Sin embargo, a cambio, podemos simplificar los lenguajes de alto nivel, simplificar la implementación del EVM y otros beneficios. Se puede decir que la hoja de ruta para priorizar la mejora continua de Ethereum L1 debe incluir y basarse en EOF.
Una tarea importante que debe realizarse es implementar funciones similares a EVM-MAX junto con SIMD, y llevar a cabo pruebas de referencia sobre el consumo de gas de varias operaciones criptográficas.
¿Cómo interactuar con otras partes del mapa de ruta?
L1 ajusta su EVM para que L2 también pueda realizar ajustes correspondientes más fácilmente. Si ambos no sincronizan sus ajustes, puede haber incompatibilidades que traerán efectos adversos. Además, EVM-MAX y SIMD pueden reducir el costo de gas de muchos sistemas de prueba, lo que hace que L2 sea más eficiente. También facilita reemplazar más precompilados por código EVM que puede realizar las mismas tareas, lo que probablemente no afectará significativamente la eficiencia.
![Vitalik sobre el posible futuro de Ethereum (Seis): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
Abstracción de cuentas
) ¿Qué problema se resolvió?
Actualmente, las transacciones solo se pueden verificar de una manera: firma ECDSA. Inicialmente, la abstracción de cuentas estaba destinada a ir más allá de esto, permitiendo que la lógica de verificación de cuentas fuera código EVM arbitrario. Esto puede habilitar una serie de aplicaciones:
Permitir que el protocolo de privacidad funcione sin intermediarios, reduciendo significativamente su complejidad y eliminando un punto de dependencia central clave.
Desde que se propuso la abstracción de cuentas en 2015, su objetivo también se ha ampliado para incluir una gran cantidad de "objetivos de conveniencia", por ejemplo, una cuenta que no tiene ETH pero posee algunos ERC20 puede utilizar ERC20 para pagar el gas.
![Vitalik sobre el posible futuro de Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) ¿Qué es y cómo funciona?
El núcleo de la abstracción de cuentas es simple: permite que los contratos inteligentes inicien transacciones, y no solo EOA. Toda la complejidad proviene de implementar esto de una manera que sea favorable para el mantenimiento de redes descentralizadas y prevenir ataques de denegación de servicio.
Un desafío clave típico es el problema de múltiples fallos: si hay 1000 funciones de validación de cuentas que dependen de un único valor S, y el valor S actual hace que las transacciones en el mempool sean todas válidas, entonces una única transacción que invierte el valor de S puede hacer que todas las demás transacciones en el mempool sean inválidas. Esto permite a un atacante enviar transacciones basura al mempool a un costo muy bajo, obstruyendo así los recursos de los nodos de la red.
Después de años de esfuerzo, con el objetivo de expandir las funciones mientras se limita el riesgo de denegación de servicio ###DoS(, finalmente se llegó a la solución para lograr "abstracción ideal de cuentas": ERC-4337.
El funcionamiento de ERC-4337 divide el procesamiento de las operaciones del usuario en dos etapas: verificación y ejecución. Todas las verificaciones se procesan primero, y todas las ejecuciones se procesan después. En el pool de memoria, solo se aceptarán las operaciones del usuario cuya etapa de verificación solo involucre su propia cuenta y no lea variables de entorno. Esto puede prevenir ataques de doble gasto. Además, se imponen estrictos límites de gas a la etapa de verificación.
![Vitalik sobre el posible futuro de Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
) enlace de investigación existente
) El trabajo restante y las consideraciones
Actualmente, lo que se necesita resolver principalmente es cómo introducir completamente la abstracción de cuentas en el protocolo. El EIP de abstracción de cuentas de escritura de protocolo que ha ganado popularidad recientemente es el EIP-7701, que implementa la abstracción de cuentas sobre el EOF. Una cuenta puede tener una parte de código separada para la verificación; si la cuenta establece esa parte de código, entonces ese código se ejecutará en el paso de verificación de las transacciones provenientes de esa cuenta.
El encanto de este método radica en que muestra claramente dos perspectivas equivalentes de la abstracción de cuentas locales:
Si comenzamos estableciendo límites estrictos sobre la complejidad del código ejecutable durante el período de verificación, entonces la seguridad de este enfoque es muy clara: simplemente reemplazar la verificación ECDSA por la ejecución de código EVM que requiere un tiempo similar.
Sin embargo, con el paso del tiempo, necesitamos relajar estos límites, ya que permitir que aplicaciones de protección de la privacidad funcionen sin intermediarios, así como la resistencia cuántica, son muy importantes. Para ello, necesitamos encontrar formas más flexibles de abordar el riesgo de denegación de servicio ###DoS(, sin requerir que los pasos de verificación sean extremadamente simplistas.
El principal compromiso parece ser "escribir rápidamente una solución que satisfaga a menos personas" frente a "esperar más tiempo para posiblemente obtener una solución más ideal". El enfoque ideal podría ser algún tipo de enfoque híbrido. Un enfoque híbrido sería escribir más rápidamente algunos casos de uso y reservar más tiempo para explorar otros casos de uso. Otro enfoque sería implementar primero una versión de abstracción de cuentas más ambiciosa en L2. Sin embargo, el desafío que enfrenta esto es que el equipo de L2 necesita tener confianza en el trabajo de la propuesta adoptada para estar dispuesto a implementarla, especialmente para garantizar que L1 y/o otros L2 puedan adoptar soluciones compatibles en el futuro.
Otra aplicación que necesitamos considerar claramente es la cuenta de almacenamiento de claves, que almacena el estado relacionado con la cuenta en L1 o en L2 dedicado, pero puede ser utilizada en L1 y en cualquier L2 compatible. Hacer esto de manera efectiva puede requerir que L2 soporte códigos de operación como L1SLOAD o REMOTESTATICCALL, pero también requiere que la implementación de abstracción de cuentas en L2 soporte estas operaciones.
) ¿Cómo interactúa con otras partes del mapa de ruta?
La lista de inclusión necesita soportar transacciones de abstracción de cuentas. En la práctica, la necesidad de la lista de inclusión es muy similar a la necesidad de un pool de memoria descentralizado, aunque hay un poco más de flexibilidad en la lista de inclusión. Además, la implementación de la abstracción de cuentas debería coordinarse tanto como sea posible entre L1 y L2. Si en el futuro esperamos que la mayoría de los usuarios utilicen un Rollup de almacenamiento de claves, el diseño de la abstracción de cuentas debería basarse en esto.
![Vitalik sobre el posible futuro de Ethereum (seis): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
Mejora EIP-1559
) ¿Qué problema resuelve?
EIP-1559 se activó en Ethereum en 2021, mejorando significativamente el tiempo promedio de inclusión de bloques. Sin embargo, la implementación actual de EIP-1559 no es perfecta en varios aspectos:
La fórmula para blobs ) EIP-4844 está diseñada específicamente para resolver el primer problema, y en general es más sencilla. Sin embargo, tanto EIP-1559 como EIP-4844 no han intentado resolver el segundo problema. Por lo tanto, la situación actual es un estado intermedio confuso, que involucra dos mecanismos diferentes, y hay una opinión que sostiene que, con el tiempo, ambos necesitan ser mejorados.
Además, hay otras debilidades en la fijación de precios de recursos de Ethereum que no están relacionadas con EIP-1559, pero que pueden mitigarse mediante ajustes a EIP-1559. Uno de los principales problemas es la diferencia entre la situación promedio y la peor: el precio de los recursos en Ethereum debe establecerse para poder manejar la peor situación, es decir, el consumo total de gas de un bloque ocupa un recurso, pero el uso promedio real está muy por debajo de esto, lo que lleva a la ineficiencia.
( ¿Qué es el Gas multidimensional y cómo funciona?
La solución a estos problemas de ineficiencia es el Gas multidimensional: establecer diferentes precios y límites para diferentes recursos. Este concepto es técnicamente independiente de EIP-1559, pero EIP-1