Autor original: @Web3 Mario

Introducción: El 13 de mayo de 2024, Vitalik lanzó la propuesta EIP-7706, proponiendo una solución complementaria al modelo de gas existente, separando el cálculo de gas de los datos de llamadas y personalizando un mecanismo de fijación de precios de tarifa base similar al gas Blob para soltar aún más el costo de funcionamiento de L2. La propuesta relacionada también debe rastrearse hasta EIP-4844 propuesta en febrero de 2022, que es hace largo tiempo, así que consulte los materiales relevantes para proporcionar una descripción general del último mecanismo de gas de Ethereum para que lo entienda rápidamente.

Los modelos de gas Ethereum actualmente compatibles: EIP-1559 y EIP-4844

En el diseño original, Ethereum utiliza un mecanismo de subasta simple para fijar el precio del blanqueo de capitales, que requiere que los usuarios oferten activamente por sus propias transacciones, es decir, que establezcan un precio del gas, normalmente, porque la tarifa de transacción pagada por los usuarios será vesting que el minero, por lo que el minero determinará el orden del empaquetado de la transacción de acuerdo con el principio de optimalidad económica, de acuerdo con el nivel de oferta, tenga en cuenta que esto es en el caso de ignorar MEV. A los ojos de los desarrolladores principales de la época, este mecanismo se enfrentaba a los siguientes cuatro problemas:

• Fluctuación en el nivel de blanqueo de capitales y el costo de consenso de las transacciones: En una cadena de bloques activa, hay suficiente demanda para el empaquetado de transacciones, lo que significa que los bloques se pueden llenar fácilmente, pero esto a menudo también significa que la fluctuación general de la tarifa es extremadamente alta. Por ejemplo, cuando el precio del gas promedio es de 10 Gwei, el costo marginal de la red para aceptar una transacción más en un bloque es 10 veces mayor que el precio del gas promedio de 1 Gwei, lo cual es inaceptable.
• Latencia innecesaria para los usuarios: Debido al límite de gas duro de cada bloque, junto con la fluctuación natural del volumen histórico, las transacciones generalmente esperan que se empaqueten varios bloques, pero esto es ineficiente para la red en general; Es decir, no existe un mecanismo de "holgura" que permita que un Bloquear sea más grande y el siguiente Bloquear más pequeño para satisfacer las diferencias en las necesidades que se bloquean caso por caso.
• Precios ineficientes: El uso de un mecanismo de subasta simple conduce a un descubrimiento de precios justos ineficiente, lo que significa que será difícil para los usuarios dar un precio razonable, lo que significa que en casos muy largos, los usuarios pagan tarifas altas.
• Los Cadena de bloques libres de Recompensa de bloque serán inestables: Cuando se elimina el Recompensa de bloque traído por Minería y se adopta un modelo de tarifa pura, puede conducir a una inestabilidad muy largo, como incentivar a la minería a robar Blanqueo de capitales "bloques hermanos", abrir minería selfish Vector de ataque más potentes, etc.

No fue hasta que se propuso e implementó EIP-1559 que hubo una primera iteración del modelo Gas, que fue propuesto por desarrolladores principales como Vitalik el 13 de abril de 2019 y adoptado en la actualización de Londres el 5 de agosto de 2021, que abandonó el mecanismo de subasta a favor de un modelo de precios dual de tarifa base y tarifa de prioridad, donde la tarifa base se basaría en el gas ya generado en el padre Bloquear La relación entre el consumo y un objetivo de gas flotante y recursivo se calcula cuantitativamente a través de un modelo matemático establecido, y el efecto intuitivo es que si el uso de gas en el Bloqueo anterior excede el objetivo de gas predeterminado, la tarifa base aumentará, y si es menor que el objetivo de gas, la tarifa base se reducirá, lo que no solo puede reflejar mejor la relación entre la oferta y la demanda, sino también hacer que la predicción de gas razonable sea más precisa. No habrá un precio del gas altísimo debido a un mal funcionamiento, porque el cálculo de la tarifa base está determinado directamente por el sistema en lugar de ser especificado libremente por el usuario. El código específico es el siguiente:

Se puede ver que cuando el padre\gas_used es mayor que el padre_gas_target, entonces la tarifa base del Bloquear actual se comparará con la tarifa base del Bloquear anterior más un valor de compensación, y el valor de compensación se toma como padre_base_fee multiplicado por el desplazamiento del uso total del Bloquear gas anterior en relación con gas destino, y el valor máximo del resto de 1 con gas objetivo y una constante. La lógica inversa es similar.

Además, la tarifa base no se distribuirá más larga a los mineros como recompensa, sino que se quemará directamente, por lo que el modelo económico de ETH se encuentra en un estado deflacionario, lo que favorece la estabilidad del valor. Por otro lado, la tarifa de prioridad es equivalente a la propina del usuario al minero, y el precio se puede establecer libremente, lo que puede permitir que el algoritmo de clasificación del minero se reutilice hasta cierto punto.

A medida que avanza el tiempo hasta 2021, cuando el desarrollo de Rollup entra gradualmente en un mejor estado, sabemos que tanto OP Rollup como ZK Rollup significan que algunos datos de prueba después de la compresión de datos L2 deben cargarse en la cadena on-chain a través de calldata para lograr la disponibilidad de los datos o entregarse directamente a la cadena on-chain para su verificación. Como resultado, estas soluciones de rollup enfrentan costos de gases significativos al mantener la finalidad de L2, y estos costos finalmente se transfieren a los usuarios, por lo que la mayoría de los costos de uso del protocolo L2 no son tan bajos como se imagina.

Al mismo tiempo, Ethereum también se enfrenta al dilema de la competencia entre Bloquear coro, sabemos que existe un límite de gas para cada Bloquear, lo que significa que el consumo total gas de todas las transacciones en el Bloquear actual no puede superar este valor, en base al límite de gas actual de 3000000000, existe un límite teórico de 30, 000, 000 / 16 = 1, 875, 000 bytes, donde 16 se refiere al consumo de 16 por byte de datos de llamada procesado por el EVM Esto significa que el largo máximo de un solo bloque puede transportar datos es de aproximadamente 1,79 MB. Los datos relacionados con el rollup generados por el secuenciador L2 suelen ser a gran escala, lo que lo hace competir con las confirmaciones de transacciones de otros usuarios de la cadena principal, lo que resulta en un volumen más pequeño que se puede empaquetar en un solo bloque, lo que a su vez afecta 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 a principios del segundo trimestre de 2024. La propuesta propone un nuevo tipo de transacción denominada Blob Transaction, que se basa en un nuevo tipo de datos, Blob data, que es un nuevo tipo de datos, Blob data, en comparación con el tipo tradicional de Transaction. A diferencia del tipo calldata, EVM no puede tener acceso directo a los datos de blob, sino solo a su hash, también conocido como VersionedHash. Además, hay dos diseños que lo acompañan, uno es que, en comparación con las transacciones ordinarias, el período de GC de las transacciones de blobs es más corto, para garantizar que los datos del bloque no estén demasiado hinchados, y el segundo es que los datos de blob tienen un mecanismo de gas nativo, que generalmente presenta un efecto similar al EIP-1559, pero elige la función exponencial natural en el modelo matemático, de modo que pueda funcionar mejor en estabilidad cuando se trata de fluctuaciones del tamaño de la transacción, porque la pendiente de la función exponencial natural también es una función exponencial natural, Esto significa que no importa en qué estado se encuentre el tamaño de la transacción de red en este momento, cuando el tamaño de la transacción aumenta rápidamente, la tarifa base del gas de blob responde más completamente, lo que frena efectivamente la actividad de la transacción, y la función también tiene una característica importante, cuando la abscisa es 0, el valor de la función es 1.

base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS * e**(exceso_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)

donde MIN_BASE_FEE_PER_BLOB_GAS y BLOB_BASE_FEE_UPDATE_FRACTION son dos constantes, mientras que excess_blob_gas viene determinado por la diferencia entre el total de blobs en el Bloquear gas primario y una constante TARGET_BLOB_GAS_PER_BLOCK, cuando el total de blobs gas Cuando el consumo supera el valor objetivo, es decir, cuando la diferencia es positiva, e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) es mayor que 1, entonces base_fee_per_blob_gas se hace más grande y viceversa se hace más pequeña.

De esta manera, para algunos escenarios que solo desean utilizar la capacidad de consenso de Ethereum para almacenar algunos datos a gran escala para garantizar la disponibilidad, se puede ejecutar a bajo costo sin desplazar la capacidad de empaquetado de transacciones del bloque. Tomando el secuenciador consolidado como ejemplo, la información clave de L2 se puede encapsular en datos de blob a través de una transacción de blob, y la lógica de verificación on-chain se puede implementar mediante versionedHash a través de un diseño inteligente en EVM.

Se debe agregar que las configuraciones actuales de TARGET_BLOB_GAS_PER_BLOCK y MAX_BLOB_GAS_PER_BLOCK introducen un límite de Mainnet de 3 blobs (0,375 MB) por Bloquear y un máximo de 6 blobs (0,75 MB) por largo. Estos límites iniciales están diseñados para minimizar la tensión en la red de este EIP y se espera que aumenten en futuras actualizaciones a medida que la red demuestre confiabilidad en bloques más grandes.

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

Ahora que se ha aclarado el modelo de Ethereum gas actual, echemos un vistazo a los objetivos y detalles de implementación de la propuesta EIP-7706. La propuesta fue presentada por Vitalik el 13 de mayo de 2024. De forma similar a los datos de blobs, esta propuesta elimina el modelo de gases para otro campo de datos especial, que es calldata. Y se ha optimizado la lógica de implementación del código correspondiente.

En principio, la lógica de cálculo de la tarifa base de los datos de llamada es la misma que la de la tarifa base para los datos de blob en EIP-4844, que utiliza una función exponencial y calcula la escala de la tarifa base actual en función del valor de desviación del valor real de consumo de gas en el bloque principal del valor objetivo.

Vale la pena señalar un nuevo diseño de parámetros, LIMIT_TARGET_RATIOS=[ 2, 2, 4 ], donde LIMIT_TARGET_RATIOS[ 0 ] representa la relación objetivo de la clase de operación Gas, LIMIT_TARGET_RATIOS[ 1 ] representa la relación objetivo de la clase de datos Blob Gas y LIMIT_TARGET_RATIOS [ 2 ] representa los datos de llamada La relación objetivo de la clase Gas, este vector se utiliza para calcular los valores objetivo gas correspondientes a las tres clases de gas en el Bloquear principal, y la lógica de cálculo es la siguiente, es decir, el límite de gas es divisible por LÍMITE_TARGET_RATIOS respectivamente:

La lógica de gas_limits es la siguiente:

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

gas_limits[ 1 ] debe ser igual a 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, lo que significa que el destino actual de gas de datos de llamada es de aproximadamente 300000000 // 4 // 4 = 1875000, y porque de acuerdo con la lógica de cálculo de gas de datos de llamada actual, cada byte distinto de cero consume 16 gas y cero bytes consume 4 gas. Suponiendo que la distribución de bytes distintos de cero y cero en un determinado segmento de datos de llamadas representa el 50% cada uno, se necesita un promedio de 10 gases para procesar 1 bytes de datos de llamadas. Por lo tanto, el destino de gas de datos de llamada actual debe hacer frente a 187500 bytes de datos de datos de llamada, que es aproximadamente 2 veces el uso promedio actual.

La ventaja de esto es que la probabilidad de que los datos de llamadas alcancen el límite de gas se reduce considerablemente, y el uso de datos de llamadas se mantiene en un estado más consistente a través del modelado económico, y también se elimina el abuso de los datos de llamadas. La razón de este diseño es despejar el camino para el desarrollo de L2 y, con los datos de blobs, el costo del secuenciador se reduce aún más.