Introducción: El 13 de mayo de 2024, Vitalik propuso EIP-7706, que complementa el modelo de Gas existente al eliminar por separado el cálculo de gas para calldata y personalizar un mecanismo de fijación de tarifas base similar al gas Blob, reduciendo aún más los costos operativos de la Capa 2. Las propuestas relacionadas también deben remontarse a EIP-4844 propuesto en febrero de 2022, lo que supone mucho tiempo de diferencia. Por lo tanto, al revisar los materiales relacionados, esperamos proporcionar un resumen del mecanismo de Gas más reciente de Ethereum para facilitar la comprensión rápida de todos.

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

En el diseño inicial, Ethereum adoptó un mecanismo de subasta simple para fijar las tarifas de transacción, lo que requería que los usuarios pujaran activamente por sus transacciones, es decir, estableciendo precios de gas. Por lo general, debido a que las tarifas de transacción pagadas por los usuarios van a los mineros, los mineros deciden el orden de empaquetado de las transacciones basándose en el principio de optimalidad económica, de acuerdo con el precio de la oferta, ignorando la situación de MEV. En la opinión de los desarrolladores principales en ese momento, este mecanismo enfrentaba cuatro problemas:

La fluctuación de los niveles de tarifas de transacción no coincide con el costo consensuado de las transacciones: Para las cadenas de bloques en un estado activo, hay suficiente demanda de empaquetado de transacciones, lo que significa que los bloques pueden llenarse fácilmente, pero esto a menudo conduce a fluctuaciones significativas en las tarifas generales. Por ejemplo, cuando el precio promedio del Gas es de 10 Gwei, el costo marginal incurrido por la red para aceptar otra transacción en un bloque es diez veces mayor que cuando el precio promedio del Gas es de 1 Gwei, lo cual es inaceptable.

Retrasos innecesarios para los usuarios: Debido al límite estricto de gaslimit para cada bloque, junto con la fluctuación natural de los volúmenes de transacciones históricas, las transacciones a menudo tienen que esperar varios bloques para ser empaquetadas, lo cual es ineficiente para la red en general. No hay un mecanismo de "relajación" que permita que un bloque sea más grande y el siguiente bloque sea más pequeño para satisfacer las diferencias de demanda entre bloques.

Precios ineficientes: La adopción de un mecanismo de subasta simple ha llevado a una baja eficiencia en la determinación del precio justo, lo que significa que es difícil para los usuarios dar un precio razonable, lo que resulta en muchos casos en los que los usuarios pagan tarifas excesivas.

La cadena de bloques sin recompensas en bloque será inestable: Al cancelar las recompensas en bloque provocadas por la minería y adoptar un modelo de tarifas puras, puede conducir a muchas inestabilidades, como incentivar la minería de "bloques hermanos" para robar tarifas de transacción, abrir vectores de ataque de minería egoístas más poderosos, etc.

Hasta la propuesta e implementación de EIP-1559, hubo una primera iteración del modelo de Gas. EIP-1559, propuesto por Vitalik y otros desarrolladores principales el 13 de abril de 2019, fue adoptado en la actualización de Londres el 5 de agosto de 2021. Este mecanismo abandona el mecanismo de subasta y en su lugar adopta un modelo de precios duales de Tarifa base y Tarifa de prioridad. La Tarifa base se calcula cuantitativamente en función de la relación entre el consumo de gas en el bloque padre y un objetivo de gas flotante y recursivo a través de un modelo matemático establecido. El efecto intuitivo es que si el uso de gas en el bloque anterior supera el objetivo de gas predeterminado, la tarifa base se incrementa, y si está por debajo del objetivo de gas, la tarifa base se reduce. Esto puede reflejar mejor la oferta y la demanda y hacer que las predicciones para un gas razonable sean más precisas, evitando precios exorbitantes de gas debido a malas operaciones porque el cálculo de la tarifa base está determinado directamente por el sistema en lugar de ser especificado libremente por los usuarios. El código específico es el siguiente:

Se puede inferir que cuando parent_gas_used es mayor que parent_gas_target, la tarifa base del bloque actual se comparará con la tarifa base del bloque anterior más un valor de compensación. En cuanto al valor de compensación, se calcula multiplicando parent_base_fee por el desfase del uso total de gas del bloque anterior en relación con el objetivo de gas y tomando el módulo con el objetivo de gas y una constante, luego tomando el valor máximo del resultado y 1. La lógica es similar en sentido contrario.

Además, la tarifa base ya no se asignará como recompensa a los mineros, sino que se quemará directamente, poniendo así el modelo económico de Ethereum en un estado deflacionario, lo que es propicio para la estabilidad del valor. Por otro lado, la tarifa de prioridad es similar a una propina dada por los usuarios a los mineros y puede tener un precio libre, lo que en cierta medida puede permitir que se reutilice el algoritmo de secuenciación de mineros.

A medida que avanzaba el tiempo en 2021, el desarrollo de Rollups alcanzó gradualmente su punto máximo. Sabemos que ya sea OP Rollups o ZK Rollups, implica la necesidad de subir ciertos datos de prueba de datos L2 comprimidos a la cadena a través de calldata para lograr la Disponibilidad de Datos en cadena, o ser verificados directamente en cadena. Esto impone costos significativos de gas en el mantenimiento de la finalidad de L2, que en última instancia se transfieren a los usuarios. Por lo tanto, el costo de usar la mayoría de los protocolos L2 no fue tan bajo como se imaginaba en ese momento.

Al mismo tiempo, Ethereum también enfrentó el dilema de la competencia por el espacio de bloque. Sabemos que cada bloque tiene un Límite de Gas, lo que significa que el consumo total de gas de todas las transacciones en el bloque actual no puede exceder este valor. Calculando en base al Límite de Gas actual de 30,000,000, teóricamente hay un límite de 1,875,000 bytes, donde 16 se refiere al gas consumido por byte de calldata procesado por la EVM. Esto implica que el tamaño de datos máximo que se puede acomodar en un solo bloque es aproximadamente 1.79 MB. Sin embargo, los datos relacionados con Rollup generados por los secuenciadores de L2 suelen tener un tamaño de datos más grande, lo que compite con la confirmación de transacciones por otros usuarios de la cadena principal, lo que resulta en una disminución en el número de transacciones que se pueden empaquetar en un solo bloque, afectando así el TPS de la cadena principal.

Para abordar este dilema, los desarrolladores principales propusieron EIP-4844 el 5 de febrero de 2022, que se implementó después de la actualización de Dencun en el segundo trimestre de 2024. Esta propuesta introduce un nuevo tipo de transacción llamado Transacción de Blob. En contraste con los tipos de transacción tradicionales, la idea principal de la Transacción de Blob complementa un nuevo tipo de datos, conocido como datos de Blob. A diferencia de los tipos de calldata, los datos de blob no pueden ser accedidos directamente por el EVM, pero solo puede acceder a su hash, también conocido como HashVersionado. Además, se introducen dos diseños acompañantes. En primer lugar, en comparación con las transacciones regulares, el ciclo GC de las transacciones de blob es más corto, asegurando que los datos de bloque no se vuelvan demasiado inflados. En segundo lugar, los datos de blob tienen un mecanismo de Gas nativo. En general, el efecto presentado es similar a EIP-1559, pero el modelo matemático selecciona una función exponencial natural, que tiene un mejor rendimiento en estabilidad al tratar con fluctuaciones en el volumen de transacciones. Esto se debe a que la pendiente de la función exponencial natural también es una función exponencial natural, lo que significa que independientemente del estado del volumen de transacciones de la red, cuando el volumen de transacciones aumenta rápidamente, la tarifa base del gas de blob refleja más completamente, frenando eficazmente la actividad de transacciones. Además, esta función tiene una característica importante donde el valor de la función es 1 cuando la abscisa es 0.

base_fee_per_blob_gas = TARIFA_BASE_MINIMA_POR_BLOB_GAS e*(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)

Donde MIN_BASE_FEE_PER_BLOB_GAS y BLOB_BASE_FEE_UPDATE_FRACTION son dos constantes, y excess_blob_gas se determina por la diferencia entre el consumo total de gas de blob en el bloque padre y una constante TARGET_BLOB_GAS_PER_BLOCK. Cuando el consumo total de gas de blob excede el valor objetivo, es decir, la diferencia es positiva, e**(exceso_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) es mayor que 1, y base_fee_per_blob_gas aumenta, de lo contrario disminuye.

Esto permite una ejecución de bajo coste en escenarios donde solo se desea la capacidad de consenso de Ethereum para almacenar datos a gran escala y garantizar la disponibilidad, sin monopolizar la capacidad de empaquetamiento de transacciones del bloque. Tomando el secuenciador de Rollup como ejemplo, la información crítica de L2 se puede encapsular en datos de blob a través de transacciones de blob, y la lógica para la verificación en cadena se puede implementar en el EVM a través de diseños sofisticados que utilizan versionedHash.

Cabe destacar que la configuración actual de TARGET_BLOB_GAS_PER_BLOCK y MAX_BLOB_GAS_PER_BLOCK impone una limitación en la mainnet, concretamente un objetivo de procesar un promedio de 3 blobs (0,375 MB) por bloque y un límite máximo de 6 blobs (0,75 MB) por bloque. Estos límites iniciales tienen como objetivo minimizar la presión que EIP ejerce sobre la red, y se espera que se incrementen en futuras actualizaciones a medida que la red demuestre fiabilidad con bloques más grandes.

Refinamiento del modelo de consumo de gas para el entorno de ejecución - EIP-7706

Después de aclarar el modelo de Gas actual de Ethereum, echemos un vistazo a los objetivos y detalles de implementación de la propuesta EIP-7706. Esta propuesta fue presentada por Vitalik el 13 de mayo de 2024. Similar a los datos Blob, esta propuesta separa el modelo de Gas para otro campo de datos especial, es decir, calldata, y optimiza la lógica de implementación de código correspondiente.

En principio, la lógica de cálculo de la tarifa base para los datos de llamada es la misma que la tarifa base para los datos de blob en EIP-4844, ambos utilizan una función exponencial para calcular el factor de escala para la tarifa base actual basada en la desviación entre el valor real de consumo de gas en el bloque padre y el valor objetivo.

Vale la pena destacar un nuevo diseño de parámetro, LIMIT_TARGET_RATIOS=[2,2,4], donde LIMIT_TARGET_RATIOS[0] representa la proporción objetivo de Gas para las operaciones de ejecución, LIMIT_TARGET_RATIOS[1] representa la proporción objetivo de Gas para los datos de Blob y LIMIT_TARGET_RATIOS[2] representa la proporción objetivo de Gas para calldata. Este vector se utiliza para calcular los valores objetivo de gas para los tres tipos de gas en el bloque principal, utilizando los LIMIT_TARGET_RATIOS para la división entera en el límite de gas de la siguiente manera:

La lógica de configuración para los límites de gas es la siguiente:

gas_limits[0] debe seguir la fórmula de ajuste existente.

gas_limits[1] must be equal to MAX_BLOB_GAS_PER_BLOCK.

gas_limits[2] debe ser igual a gas_limits[0] // CALLDATA_GAS_LIMIT_RATIO.

Sabemos que el gas_limits[0] actual es 30000000, y CALLDATA_GAS_LIMIT_RATIO está preestablecido en 4. Esto significa que el objetivo actual de gas de calldata es aproximadamente 30000000 // 4 // 4 = 1875000. Dado que, según la lógica actual de cálculo de gas de calldata, cada byte distinto de cero consume 16 Gas y los bytes de cero consumen 4 Gas, asumiendo que la distribución de bytes distintos de cero y de cero en un segmento de calldata es del 50%, el procesamiento promedio de 1 byte de calldata requiere 10 Gas. Por lo tanto, el objetivo actual de gas de calldata debería corresponder a datos de calldata de 187500 bytes, aproximadamente el doble del uso promedio actual.

El beneficio de este enfoque es reducir en gran medida la probabilidad de que los datos de llamada alcancen el límite de gas, manteniendo el uso de los datos de llamada en un nivel relativamente consistente a través del modelo económico y evitando el abuso de los datos de llamada. La razón de este diseño es allanar el camino para el desarrollo de L2, junto con datos de blob, para reducir aún más el costo del secuenciador.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [TechFlow]. Todos los derechos de autor pertenecen al autor original [Web3Mario]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente 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.