Introducción

El 13 de mayo de 2024, Vitalik propuso EIP-7706, sugiriendo un plan complementario al modelo de gas existente. Esta propuesta aísla el cálculo de gas de los datos de llamadas y personaliza un mecanismo de fijación de precios de tarifa base similar al gas Blob, lo que reduce aún más los costos operativos de la capa 2 (L2). Las propuestas relacionadas se remontan a EIP-4844, propuesta en febrero de 2022. Dada la importante brecha de tiempo, este artículo revisa los materiales relevantes para proporcionar una visión general de los últimos desarrollos en el mecanismo Ethereum Gas, lo que permite a los lectores comprender rápidamente las actualizaciones.

Modelos de gas Ethereum admitidos actualmente: EIP-1559 y EIP-4844

En su diseño inicial, Ethereum adoptó un mecanismo de subasta simple para fijar el precio de las tarifas de transacción, lo que requería que los usuarios pujen activamente por sus transacciones estableciendo un precio de gas. Por lo general, dado que las tarifas de transacción pagadas por los usuarios van a los mineros, los mineros priorizan las transacciones en función de las ofertas más altas, asumiendo que no hay consideraciones sobre el valor extraíble del minero (MEV). Los desarrolladores principales identificaron cuatro problemas principales con este mecanismo:

Desajuste entre la volatilidad de las tarifas de transacción y los costos de consenso: Para una cadena de bloques activa, existe una amplia demanda de inclusión de transacciones, lo que significa que los bloques se pueden llenar fácilmente. Sin embargo, esto también da lugar a una importante volatilidad de las comisiones. Por ejemplo, cuando el precio medio del gas es de 10 Gwei, el coste marginal de añadir otra transacción a un bloque es diez veces mayor que cuando el precio medio del gas es de 1 Gwei, lo cual es inaceptable.

Retrasos innecesarios para los usuarios: Debido al límite de gas duro por bloque y a las fluctuaciones naturales en el volumen histórico de transacciones, las transacciones a menudo esperan varios bloques para ser incluidas. Esto es ineficiente para la red en general porque no existe un mecanismo de flexibilidad para permitir que un bloque sea más grande y el siguiente sea más pequeño para satisfacer la demanda variable de bloque a bloque.

Ineficiencia en la fijación de precios: El simple mecanismo de subasta conduce a un descubrimiento de precios ineficiente, lo que dificulta que los usuarios establezcan un precio razonable. Esto a menudo da como resultado que los usuarios paguen de más por las tarifas de transacción.

Inestabilidad en una cadena de bloques sin recompensas de bloque: Cuando se eliminan las recompensas de bloque de la minería y se adopta un modelo de tarifas puras, puede conducir a la inestabilidad, como la creación de "bloques de tíos" que roban tarifas de transacción, aumentando los vectores para poderosos ataques de minería egoístas.

Con la introducción e implementación de EIP-1559, el modelo Gas experimentó su primera iteración significativa. Propuesto por Vitalik y otros desarrolladores principales el 13 de abril de 2019, y adoptado durante la actualización de Londres el 5 de agosto de 2021, este mecanismo abandonó el modelo de subasta en favor de un modelo de precios duales que consiste en una tarifa base y una tarifa prioritaria. La tarifa base se ajusta cuantitativamente a través de un modelo matemático predeterminado basado en el consumo de gas en el bloque principal en relación con un objetivo de gas flotante y recursivo.

Cálculo y efectos de la tarifa base: Si el uso de gas en el bloque anterior excede el objetivo de gas, la tarifa base aumenta; si no alcanza el objetivo de gas, la tarifa base disminuye. Este ajuste refleja bien la dinámica de la oferta y la demanda y mejora la precisión de las predicciones razonables del gas, evitando precios exorbitantes del gas debido a un mal funcionamiento, ya que el cálculo de la tarifa base está determinado por el sistema en lugar de especificado por el usuario. El código específico para el cálculo es el siguiente:

A partir del contenido, podemos inferir que cuando el parent_gas_used es mayor que el parent_gas_target, la tarifa base del bloque actual se incrementará en comparación con la tarifa base del bloque anterior en un valor de compensación. Esta compensación se determina multiplicando el parent_base_fee por la desviación del uso total de gas del objetivo de gas en el bloque anterior, luego tomando el resto del objetivo de gas y una constante, y el valor máximo entre este resto y 1. Por el contrario, la lógica se aplica de manera similar cuando el parent_gas_used es menor que el parent_gas_target.

Además, la tarifa base ya no se distribuirá como recompensa a los mineros, sino que se quemará. Esto hace que el modelo económico de ETH sea deflacionario, lo que ayuda a estabilizar su valor. Por otro lado, la tarifa de prioridad, similar a una propina de los usuarios a los mineros, puede tener un precio libre, lo que permite cierto grado de reutilización en los algoritmos de clasificación de los mineros.

En 2021, el desarrollo de Rollup había entrado en una etapa madura. Sabemos que tanto OP Rollup como ZK Rollup implican comprimir los datos L2 y cargar algunos datos de prueba a través de calldata a la cadena para la disponibilidad de datos o la verificación directa en la cadena. Esto conduce a costos significativos de gas para mantener la finalidad de L2, que en última instancia son asumidos por los usuarios, lo que resulta en costos más altos de lo previsto para la mayoría de los protocolos L2.

Al mismo tiempo, Ethereum se enfrentó al reto de la competencia en el espacio de bloques. Cada bloque tiene un límite de gas, lo que significa que el consumo total de gas de todas las transacciones en un bloque no puede exceder este límite. Con el límite de gas actual establecido en 30.000.000, teóricamente, hay un límite de 1.875.000 bytes (30.000.000 / 16) por bloque, donde se necesitan 16 unidades de gas por cada byte de datos de llamada procesado por la EVM, lo que da como resultado una capacidad máxima de datos de aproximadamente 1,79 MB por bloque. Los datos relacionados con el Rollup generados por los secuenciadores L2 suelen ser grandes, lo que crea competencia con las transacciones de otros usuarios de la red principal y reduce el número de transacciones que se pueden incluir en un solo bloque, lo que afecta al TPS de la red principal.

Para abordar este problema, los desarrolladores principales propusieron EIP-4844 el 5 de febrero de 2022, que se implementó después de la actualización de Dencun a principios del segundo trimestre de 2024. En esta propuesta se introdujo un nuevo tipo de transacción denominado Blob Transaction. A diferencia de las transacciones tradicionales, Blob Transaction incluye un nuevo tipo de datos, Blob data, al que, a diferencia de calldata, la EVM no puede acceder directamente, sino solo a través de su hash, también conocido como VersionedHash. Además, las transacciones de blobs tienen un ciclo de GC más corto en comparación con las transacciones normales, lo que evita que los datos de bloque se hinchen demasiado. Los datos de blob también vienen con un mecanismo de gas inherente, similar a EIP-1559, pero utiliza una función exponencial natural en su modelo matemático, lo que proporciona una mejor estabilidad en el manejo de las fluctuaciones del tamaño de la transacción. La pendiente de la función exponencial natural también es una función exponencial natural, lo que significa que, independientemente del estado actual de los tamaños de las transacciones de la red, la tarifa base del gas de blob reacciona más plenamente a los rápidos aumentos repentinos de las transacciones, lo que frena eficazmente la actividad de las transacciones. Otra característica clave es que el valor de la función es 1 cuando el eje horizontal es 0.

base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS e*(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)

Aquí, MIN_BASE_FEE_PER_BLOB_GAS y BLOB_BASE_FEE_UPDATE_FRACTION son constantes, mientras que excess_blob_gas está determinada por la diferencia entre el consumo total de gas de blob en el bloque principal y un TARGET_BLOB_GAS_PER_BLOCK constante. Cuando el consumo total de gas de blob supera el valor objetivo, lo que hace que la diferencia sea positiva, e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) es mayor que 1, lo que hace que el base_fee_per_blob_gas aumente y viceversa.

Este mecanismo permite la ejecución de bajo costo de escenarios en los que la capacidad de consenso de Ethereum se utiliza para certificar grandes volúmenes de datos para garantizar la disponibilidad sin ocupar la capacidad de empaquetado de transacciones. Por ejemplo, los secuenciadores consolidados pueden usar transacciones de blobs para encapsular información clave de L2 en datos de blobs y lograr la verificación en cadena a través de VersionedHash dentro de la EVM.

Debe tenerse en cuenta que la configuración actual para TARGET_BLOB_GAS_PER_BLOCK y MAX_BLOB_GAS_PER_BLOCK imponer una limitación en la red principal, con un objetivo promedio de procesar 3 blobs (0,375 MB) por bloque y un máximo de 6 blobs (0,75 MB) por bloque. Estos límites iniciales tienen como objetivo minimizar el estrés de la red causado por este EIP, con la expectativa de aumentar estos límites en futuras actualizaciones a medida que la red demuestre confiabilidad en tamaños de bloque más grandes.

Refinación del modelo de consumo de gas para entornos de ejecución: EIP-7706

Después de comprender el modelo actual de Ethereum Gas, profundicemos en los objetivos y detalles de implementación de la propuesta EIP-7706. Esta propuesta, presentada por Vitalik el 13 de mayo de 2024, tiene como objetivo redefinir el modelo de gas para un campo de datos específico conocido como calldata, al igual que los cambios anteriores para los datos de blobs. Además, la propuesta optimiza la lógica de código correspondiente.

Conceptos fundamentales

La lógica de cálculo de la tarifa base para los datos de llamadas en EIP-7706 refleja el cálculo de la tarifa base para los datos de blobs como se especifica en EIP-4844. Ambos utilizan una función exponencial para ajustar la tarifa base en función de la desviación entre el consumo real de gas y el valor objetivo en el bloque principal.

Un aspecto destacable de esta propuesta es la introducción de un nuevo diseño de parámetros, LIMIT_TARGET_RATIOS = [2, 2, 4]. Aquí está el desglose:

LIMIT_TARGET_RATIOS[0]: Relación objetivo para el gas de operación de ejecución.

LIMIT_TARGET_RATIOS[1]: Relación de destino para el gas de datos de blobs.

LIMIT_TARGET_RATIOS[2]: Relación objetivo para el gas de datos de llamada.

Estas relaciones se utilizan para calcular los valores objetivo de gas para los tres tipos de gas en el bloque principal dividiendo el límite de gas por las relaciones respectivas.

Los límites de gas se establecen de la siguiente manera:

• gas_limits[0] sigue la fórmula de ajuste existente.

• gas_limits[1] es MAX_BLOB_GAS_PER_BLOCKigual a .

• gas_limits[2] es gas_limits[0] / CALLDATA_GAS_LIMIT_RATIOigual a .

Dado que la corriente gas_limits[0] es de 30.000.000 y está CALLDATA_GAS_LIMIT_RATIO preestablecida en 4, esto significa que el objetivo de gas actual calldata es aproximadamente:

[ \frac{30.000.000}{4 \times 4} = 1.875.000 ]

De acuerdo con la lógica de cálculo de gas actual calldata :

• Cada byte distinto de cero consume 16 de gas.

• Cada byte cero consume 4 de gas.

Suponiendo una distribución uniforme de bytes distintos de cero y cero en un segmento de , el consumo medio de calldatagas por byte es de 10 gas. Por lo tanto, el objetivo de gas actual calldata corresponde a aproximadamente 187.500 bytes de calldata, que es aproximadamente el doble del uso promedio actual.

Beneficios de la propuesta

Este ajuste reduce significativamente la probabilidad de alcanzar el límite de gas, manteniendo calldata el uso a un nivel constante a través de calldata modelos económicos y evitando el abuso. La intención principal de este diseño es facilitar el crecimiento de las soluciones de capa 2, reduciendo los costos del secuenciador cuando se usan junto con los datos de blobs.

En conclusión, EIP-7706 no solo refina el modelo calldata de gas, sino que también posiciona estratégicamente a Ethereum para el escalado eficiente de las soluciones de capa 2 mediante el control y la optimización del consumo de gas relacionado con los datos.

Renuncia:

1. Este artículo es una reimpresión de [Web3Mario], Todos los derechos de autor pertenecen al autor original [Web3Mario]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.