Autor: @Web3Mario

Introducción: Vitalik lanzó la propuesta EIP-7706 el 13 de mayo de 2024, proponiendo un esquema complementario al modelo de gas existente, eliminando el cálculo de gas de los datos de llamadas y personalizando un mecanismo de precios de tarifa base similar al gas Blob para reducir 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 hacer una descripción general del último mecanismo de gas de Ethereum para que todos lo entiendan rápidamente.

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

En el diseño inicial, 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, por lo general, porque la tarifa de transacción pagada por el usuario 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 optimización 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:

Existe un desajuste entre la fluctuación del nivel de blanqueo de capitales y el costo de la transacción Consenso:* Para la cadena de bloques activa, la demanda de empaquetado para la transacción es suficiente, lo que significa que el bloqueo se puede llenar fácilmente, pero también a menudo significa que el costo total es extremadamente fluctuación. Por ejemplo, cuando el precio del gas promedio es de 10 Gwei, el costo marginal de la red para aceptar otra transacción 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 estricto de gaslimit por bloqueo, junto con la fluctuación natural del volumen histórico, las transacciones a menudo esperan unos pocos bloquear antes de empaquetarse, 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. Un Cadena de bloques sin Recompensa de bloque será inestable: Cuando se elimina el Recompensa de bloque traído por el Minería y se adopta un modelo de tarifa pura, puede llevar a una inestabilidad muy largo, como incentivar a la minería a robar el "bloque hermano" del Blanqueo de capitales, abrir una minería selfish Vector de ataque más poderosa, etc.

Hasta que se propuso y ejecutó EIP-1559, hubo una primera iteración del modelo Gas, EIP-1559 fue propuesto por Vitalik y otros desarrolladores principales el 13 de abril de 2019 y adoptado en la actualización de Londres el 5 de agosto de 2021 La tarifa se basará en el consumo de gas generado en el Bloquear y un gas flotante y recursivo La relación entre el objetivo 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 Bloquear 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 puede reflejar mejor la relación entre la oferta y la demanda. También puede hacer que la predicción de gas razonable sea más precisa, y no habrá un precio del gas altísimo causado por 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, 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 el objetivo gas, y el valor máximo del resto y 1 del objetivo gas 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, de modo que el modelo económico de ETH se encuentre 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, que puede tener un precio libre, lo que puede permitir que los algoritmos de clasificación del minero se reutilicen hasta cierto punto.

Con el avance del tiempo hasta 2021, cuando el desarrollo de Rollup entró gradualmente en una mejor situación, 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 on-chain para su verificación. Como resultado, estas soluciones acumulativas enfrentan grandes costos de gases al mantener la finalidad de L2, y estos costos eventualmente se transferirán 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 a la EVM que procesa cada dato de llamada Los bytes consumen 16 unidades de gas, lo que significa que un solo bloque puede transportar aproximadamente 1,79 MB de datos largos. Los datos relacionados con el rollup generados por el secuenciador L2 generalmente tienen una gran escala de datos, lo que los hace competir con las confirmaciones de transacciones de otros usuarios de la cadena principal, lo que resulta en un volumen más pequeño de transacciones que se pueden empaquetar en un solo bloque, lo que a su vez afecta el TPS de la cadena principal.

Para abordar este dilema, los desarrolladores principales presentaron una propuesta para 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 denominado Blob Transaction, que se complementa con 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 acompañantes, uno es que, en comparación con las transacciones ordinarias, el período de GC de la transacción de blob es más corto, para garantizar que los datos de bloqueo no estén demasiado hinchados, y el otro es que los datos de blob tienen un mecanismo de gas nativo, y el efecto general es similar a EIP-1559, pero la función exponencial natural se selecciona en el modelo matemático, de modo que funcione mejor en términos de estabilidad en respuesta a las 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 se dispara 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, y excess_blob_gas viene determinado por la diferencia entre el total de blobs del Bloquear gas primario consumido por una constante TARGET_BLOB_GAS_PER_BLOCK, cuando el total de blobs gas 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 mayor, y viceversa.

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 y no desplazará la capacidad de empaquetado de transacciones del bloque. Tomando el secuenciador Rollup 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 la verificación on-chain se puede realizar mediante el uso de versionedHash a través de un diseño ingenioso 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.

Re-refinamiento del modelo de consumo de gases del entorno de ejecución - EIP-7706

Ahora que se ha aclarado el modelo actual de Ethereum Gas, 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. Similar a los datos de blobs, esta propuesta elimina el modelo de gases correspondiente a 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 de la desviación entre el valor real de consumo de gas y el valor objetivo en el bloque principal.

Vale la pena señalar un nuevo diseño paramétrico, LIMIT_TARGET_RATIOS=[2,2,4], donde LIMIT_TARGET_RATIOS[0][1]Indica la relación de destino de la operación gas, LIMIT_TARGET_RATIOS[2]Indica la relación de destino de la clase de datos de blob Gas, que es LIMIT_TARGET_RATIOSEste vector se utiliza para calcular el valor objetivo gas correspondiente a las tres clases de gas en el Bloquear principal, y la lógica de cálculo es la siguiente, es decir, LIMIT_TARGET_RATIOS se utiliza para dividir el límite de gas dividiendo el límite:

La lógica de establecer gas_limits es la siguiente:

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

gas_limits[1]Debe ser igual a MAX_BLOB_GAS_PER_BLOCK

gas_limits[2][0]Debe ser igual a gas_limits CALLDATA_GAS_LIMIT_RATIO

Conocemos el gas actual_limits[0]es 300000000, CALLDATA_GAS_LIMIT_RATIO está preestablecido en 4, lo que significa que el destino de gas de datos de llamada actual es de aproximadamente 3000000000 // 4 // 4 = 1875000, y porque de acuerdo con la lógica de cálculo de gas de datos de llamada actual, cada bytes distinto de cero consume 16 gas y cero bytes consume 4 gas. Por ejemplo, si la distribución de bytes distintos de cero y cero en un determinado segmento de datos de llamada representa el 50% cada uno, el procesamiento promedio de 1 byte de datos de llamada consume 10 gases. Por lo tanto, el destino de gas de datos de llamada actual debe hacer frente a 187.500 bytes de datos de datos de llamada, que es aproximadamente el doble del 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 soltar el desarrollo de L2, y con los datos de blobs, el costo del secuenciador se reduce aún más.