Autor: @Web3Mario
Introducción: Vitalik publicó la propuesta EIP-7706 el 13 de mayo de 2024, que proponía un complemento al modelo de gas existente, separaba el cálculo de gas de los datos de llamadas por separado y personalizaba un mecanismo de fijación de precios de tarifa base similar al gas Blob, para reducir aún más los costos operativos de L2. . Las propuestas relacionadas deben remontarse a EIP-4844 propuesta en febrero de 2022, que fue hace mucho tiempo. Por lo tanto, verifiqué la información relevante y espero hacer una descripción general del último mecanismo de Ethereum Gas para que todos puedan comprenderlo rápidamente. .
Modelos de Ethereum Gas actualmente compatibles: EIP-1559 y EIP-4844
En el diseño inicial, Ethereum utilizó un mecanismo de subasta simple para fijar el precio de las tarifas de transacción, lo que requería que los usuarios ofertaran activamente por sus propias transacciones, es decir, para establecer el precio del gas. Normalmente, las tarifas de transacción pagadas por los usuarios pertenecerán a los mineros. , por lo que los mineros decidirán el orden del paquete de transacciones en función del precio de la oferta según el principio de optimización económica. Tenga en cuenta que esto se hace ignorando MEV. Según los desarrolladores principales en ese momento, este mecanismo enfrentaba los siguientes cuatro problemas:
Desajuste entre la volatilidad de los niveles de tarifas de transacción y el costo de consenso de las transacciones: para una cadena de bloques activa, existe suficiente demanda de paquetes de transacciones, lo que significa que los bloques se pueden completar fácilmente, pero esto a menudo también significa que los costos generales son altamente volátiles. Por ejemplo, cuando el precio medio del gas es de 10 Gwei, el coste marginal incurrido por la red al aceptar otra transacción en un bloque es 10 veces mayor que cuando el precio medio del gas es 1 Gwei, lo cual es inaceptable.
Retrasos innecesarios para los usuarios: debido al límite estricto de gas por bloque, junto con las fluctuaciones naturales en el volumen histórico de transacciones, las transacciones a menudo esperarán varios bloques antes de empaquetarse, pero esto es bajo para la red en general. Eficiente; no hay ningún mecanismo de "relajación" que permita que un bloque sea más grande y el siguiente sea más pequeño para satisfacer las diferencias de demanda entre bloques.
Fijación de precios ineficiente: debido al uso de un mecanismo de subasta simple, la eficiencia del descubrimiento de precios justos es baja, lo que significa que será difícil para los usuarios dar un precio razonable, lo que significa que en muchos casos, los usuarios pagan tarifas elevadas.
Una cadena de bloques sin recompensas en bloque será inestable: cuando se eliminan las recompensas en bloque generadas por la minería y se adopta un modelo de tarifa pura, puede generar mucha inestabilidad, como los "bloques hermanos" que incentivan a la minería a robar tarifas de transacción. vectores de ataque minero egoístas más poderosos y más.
Hasta la propuesta e implementación de EIP-1559, el modelo Gas tuvo su primera iteración. EIP-1559 fue propuesto por desarrolladores principales como Vitalik el 13 de abril de 2019 y fue adoptado en la actualización de Londres el 5 de agosto de 2021. Adoptado. este mecanismo abandona el mecanismo de subasta y en su lugar adopta un modelo de fijación de precios dual de Tarifa Base y Tarifa de Prioridad, en el que la tarifa Base se basará en el consumo de gas que se haya generado en el bloque matriz y una relación objetivo de gas flotante y recursiva. entre Puede reflejar mejor la relación entre oferta y demanda y puede hacer que la predicción del gas razonable sea más precisa, evitando precios altísimos del gas debido a un mal funcionamiento, porque el cálculo de la tarifa base lo determina directamente el sistema en lugar de especificarse libremente. por el usuario. El código específico es el siguiente:
Se puede ver 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, parent_base_fee se multiplica por el costo total del gas. el bloque anterior El desplazamiento relativo al objetivo de gas y el valor máximo del módulo 1 entre el objetivo de gas y una constante. Al contrario, la lógica es similar.
Además, la tarifa base ya no se distribuirá a los mineros como recompensa, sino que se destruirá directamente, colocando así el modelo económico de ETH en un estado deflacionario, lo que favorece la estabilidad del valor. Por otro lado, la tarifa de prioridad es equivalente a la recompensa otorgada por los usuarios a los mineros y se puede fijar un precio libremente. Esto permite que el algoritmo de clasificación de los mineros se reutilice hasta cierto punto.
A medida que avanza el tiempo hasta 2021, el desarrollo de Rollup entrará gradualmente en una buena situación. Sabemos que si OP Rollup o ZK Rollup significa que ciertos datos de prueba después de la compresión de los datos L2 deben cargarse en la cadena a través de calldata para realizar los datos. Disponibilidad (Datos Disponibles) o enviado directamente a la cadena para su verificación. Esto hace que estas soluciones Rollup enfrenten un gran costo de gas al mantener la finalidad de L2, y estos costos eventualmente se trasladarán a los usuarios. Por lo tanto, el costo de usar la mayoría de los protocolos L2 en ese momento no era tan bajo como se imaginaba.
Al mismo tiempo, Ethereum también se enfrenta al dilema de la competencia por el espacio del bloque. Sabemos que hay un límite de gas en cada bloque, lo que significa que el consumo total de gas de todas las transacciones en el bloque actual no puede exceder este valor. el límite actual de gas se calcula como 30000000. Teóricamente, hay un límite de 30 000 000/16 = 1 875 000 bytes, donde 16 se refiere al hecho de que EVM consume 16 unidades de gas para procesar cada byte de datos de llamada, lo que significa que los datos máximos que un solo bloque puede transportar El tamaño es de aproximadamente 1,79 MB. Los datos relacionados con el resumen generados por el clasificador L2 suelen ser de gran tamaño, lo que hace que compitan con las confirmaciones de transacciones de otros usuarios de la cadena principal, lo que da como resultado un volumen de transacciones más pequeño que se puede empaquetar en un solo bloque, lo que afecta el TPS. de la cadena principal.
Para resolver este dilema, los desarrolladores principales propusieron la propuesta EIP-4844 el 5 de febrero de 2022 y 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 llamado Blob Transaction. En comparación con el tipo de transacción tradicional, la idea central de Blob Transaction es agregar un nuevo tipo de datos, a saber, datos Blob. A diferencia del tipo de datos de llamada, el EVM no puede acceder directamente a los datos del blob, sino que solo puede acceder a su hash, también llamado VersionedHash. Además, hay dos diseños que lo acompañan: uno es que, en comparación con las transacciones ordinarias, el ciclo de GC de las transacciones de blobs es más corto, lo que garantiza que los datos del bloque no estén demasiado inflados. El otro es que los datos de blobs tienen un mecanismo de gas nativo. El efecto presentado es similar al de EIP-1559, pero la función exponencial natural se selecciona en el modelo matemático para que funcione mejor en términos de estabilidad en respuesta a las fluctuaciones en el tamaño de la transacción, porque la pendiente de la función exponencial natural también es una función exponencial natural, lo que significa que independientemente de ¿Cuál es el estado de la escala de transacciones de la red en este momento? Cuando la escala de transacciones se dispara rápidamente, la tarifa base del blob gas responde de manera más completa, frenando así de manera efectiva la actividad de transacciones. , esta función también tiene una característica importante. Cuando la abscisa es 0, el valor de la función es 1.
tarifa_base_por_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS * e**(exceso_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)
Entre ellos, MIN_BASE_FEE_PER_BLOB_GAS y BLOB_BASE_FEE_UPDATE_FRACTION son dos constantes, y el exceso_blob_gas se determina por la diferencia entre el consumo total de blob de gas en el bloque principal y una constante TARGET_BLOB_GAS_PER_BLOCK. Cuando el consumo total de blob de gas excede el valor objetivo, es decir, la diferencia es positiva. , si e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) es mayor que 1, base_fee_per_blob_gas aumenta y viceversa.
De esta manera, algunos escenarios que solo quieren utilizar la capacidad de consenso de Ethereum para certificar ciertos datos a gran escala para garantizar la disponibilidad se pueden ejecutar a bajo costo sin desplazar las capacidades 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 transacciones de blob y, mediante un diseño sofisticado en EVM, versionedHash se puede usar para implementar la lógica de verificación en cadena.
Cabe agregar que las configuraciones actuales de TARGET_BLOB_GAS_PER_BLOCK y MAX_BLOB_GAS_PER_BLOCK traen un límite a la red principal, es decir, el objetivo de procesar un promedio de 3 blobs (0,375 MB) por bloque y un límite de hasta 6 blobs (0,75 MB). Estos límites iniciales están diseñados para minimizar el estrés que este EIP impone a la red y se espera que aumenten en futuras actualizaciones a medida que la red demuestre confiabilidad con bloques más grandes.
Mayor perfeccionamiento del entorno de ejecución Modelo de consumo de gas——EIP-7706
Después de aclarar el modelo Gas actual de Ethereum, echemos un vistazo a los objetivos y los detalles de implementación de la propuesta EIP-7706. La propuesta fue presentada por Vitalik el 13 de mayo de 2024. Similar a Blob data, esta propuesta elimina el modelo Gas correspondiente a otro campo de datos con características especiales, que es calldata. Y optimizó la lógica de implementación del código correspondiente.
En principio, la lógica de cálculo de la tarifa base de calldata es la misma que la tarifa base para los datos de blobs en EIP-4844. Ambos utilizan una función exponencial y calculan la tarifa base actual en función de la desviación entre el valor real del consumo de gas en el bloque principal. y el 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 de ejecución Gas, LIMIT_TARGET_RATIOS[1] representa la relación objetivo de la clase de datos Blob Gas, LIMIT_TARGET_RATIOS [2] representa la proporción objetivo del tipo de datos de llamada Gas. Este vector se utiliza para calcular el valor objetivo de gas correspondiente a los tres tipos de gas en el bloque principal. La lógica de cálculo es la siguiente, es decir, usar LIMIT_TARGET_RATIOS para realizar un número entero. operaciones de división en el límite de gas:
La lógica de configuración 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 objetivo actual de gas de calldata es aproximadamente 30000000 // 4 // 4 = 1875000, y debido a la lógica de cálculo de gas de calldata actual, cada Los bytes distintos de cero consumen 16 gases y los bytes cero consumen 4 gases. Suponiendo que la distribución de bytes distintos de cero y cero en un determinado segmento de datos de llamada representa cada uno el 50%, entonces, en promedio, se necesitan 10 gases para procesar 1 byte de. datos de llamada. Por lo tanto, el objetivo actual de gas de datos de llamadas debe corresponder a 187500 bytes de datos de datos de llamadas, que es aproximadamente el doble del uso promedio actual.
La ventaja de esto es que reduce en gran medida la probabilidad de que los datos de llamada alcancen el límite de gas. A través del modelo económico, el uso de datos de llamada se mantiene en un estado más consistente y también se elimina el abuso de datos de llamada. El motivo de este diseño es eliminar obstáculos para el desarrollo de L2 y, con datos de blobs, el coste del clasificador se puede reducir aún más.
