Introduction

Le 13 mai 2024, Vitalik a proposé l’EIP-7706, suggérant un plan supplémentaire au modèle Gas existant. Cette proposition isole le calcul du gaz des données d’appel et personnalise un mécanisme de tarification des frais de base similaire au gaz Blob, réduisant ainsi les coûts opérationnels de la couche 2 (L2). Les propositions connexes remontent à l’EIP-4844, proposée en février 2022. Compte tenu de l’écart de temps important, cet article passe en revue les documents pertinents pour fournir un aperçu des derniers développements du mécanisme Ethereum Gas, permettant aux lecteurs de comprendre rapidement les mises à jour.

Modèles de gaz Ethereum actuellement pris en charge : EIP-1559 et EIP-4844

Dans sa conception initiale, Ethereum a adopté un mécanisme d’enchères simple pour fixer le prix des frais de transaction, obligeant les utilisateurs à enchérir activement pour leurs transactions en fixant un prix du gaz. En général, comme les frais de transaction payés par les utilisateurs vont aux mineurs, les mineurs donnent la priorité aux transactions en fonction des offres les plus élevées, en supposant qu’il n’y a pas de considérations relatives à la valeur extractible (MEV) du mineur. Les développeurs principaux ont identifié quatre problèmes principaux avec ce mécanisme :

Inadéquation entre la volatilité des frais de transaction et les coûts consensuels : Pour une blockchain active, il existe une forte demande d’inclusion de transactions, ce qui signifie que les blocs peuvent facilement être remplis. Cependant, cela entraîne également une volatilité importante des frais. Par exemple, lorsque le prix moyen du gaz est de 10 Gwei, le coût marginal de l’ajout d’une autre transaction à un bloc est dix fois plus élevé que lorsque le prix moyen du gaz est de 1 Gwei, ce qui est inacceptable.

Retards inutiles pour les utilisateurs : En raison de la limite de gaz par bloc et des fluctuations naturelles du volume de transactions historiques, les transactions attendent souvent plusieurs blocs pour être incluses. Cela est inefficace pour l’ensemble du réseau car il n’existe aucun mécanisme de flexibilité permettant à un bloc d’être plus grand et au suivant d’être plus petit pour répondre à la demande variable d’un bloc à l’autre.

Inefficacité de la tarification : Le mécanisme d’enchères simple conduit à une découverte inefficace des prix, ce qui rend difficile pour les utilisateurs de fixer un prix raisonnable. Cela entraîne souvent des frais de transaction excessifs pour les utilisateurs.

Instabilité dans une blockchain sans récompenses de bloc : Lorsque les récompenses de bloc de minage sont supprimées et qu’un modèle de frais purs est adopté, cela peut conduire à une instabilité, comme la création de « blocs oncle » qui volent les frais de transaction, augmentant les vecteurs de puissantes attaques de minage égoïstes.

Avec l’introduction et la mise en œuvre de l’EIP-1559, le modèle Gas a subi sa première itération significative. Proposé par Vitalik et d’autres développeurs principaux le 13 avril 2019 et adopté lors de la mise à niveau de Londres le 5 août 2021, ce mécanisme a abandonné le modèle d’enchères au profit d’un modèle à double prix composé d’une redevance de base et d’une redevance prioritaire. Les frais de base sont ajustés quantitativement au moyen d’un modèle mathématique prédéterminé basé sur la consommation de gaz dans le bloc parent par rapport à une cible de gaz flottant et récursif.

Calcul et effets des frais de base : Si la consommation de gaz dans le bloc précédent dépasse la cible de gaz, les frais de base augmentent ; s’il n’atteint pas l’objectif de gaz, les frais de base diminuent. Cet ajustement reflète bien la dynamique de l’offre et de la demande et améliore la précision des prévisions raisonnables du gaz, évitant ainsi des prix exorbitants du gaz dus à une mauvaise utilisation, car le calcul des frais de base est déterminé par le système plutôt que par l’utilisateur. Le code spécifique pour le calcul est le suivant :

D’après le contenu, nous pouvons déduire que lorsque le parent_gas_used est supérieur au parent_gas_target, les frais de base du bloc actuel seront augmentés par rapport aux frais de base du bloc précédent d’une valeur de compensation. Ce décalage est déterminé en multipliant le parent_base_fee par l’écart de la consommation totale de gaz par rapport à la cible de gaz dans le bloc précédent, puis en prenant le reste de la cible de gaz et une constante, et la valeur maximale entre ce reste et 1. Inversement, la logique s’applique de la même manière lorsque le parent_gas_used est inférieur au parent_gas_target.

De plus, les frais de base ne seront plus distribués en récompense aux mineurs, mais seront brûlés à la place. Cela rend le modèle économique de l’ETH déflationniste, contribuant à stabiliser sa valeur. D’autre part, les frais de priorité, semblables à un pourboire des utilisateurs aux mineurs, peuvent être librement tarifés, ce qui permet un certain degré de réutilisation dans les algorithmes de tri des mineurs.

En 2021, le développement de Rollup était entré dans une phase de maturité. Nous savons que OP Rollup et ZK Rollup impliquent tous deux de compresser des données L2 et de télécharger des données d’épreuve via calldata vers la chaîne pour la disponibilité des données ou une vérification directe sur la chaîne. Cela entraîne des coûts de gaz importants pour maintenir la finalité de la L2, qui sont finalement supportés par les utilisateurs, ce qui entraîne des coûts plus élevés que prévu pour la plupart des protocoles L2.

Simultanément, Ethereum a été confronté au défi de la concurrence de l’espace des blocs. Chaque bloc a une limite de gaz, ce qui signifie que la consommation totale de gaz de toutes les transactions d’un bloc ne peut pas dépasser cette limite. Avec la limite actuelle de gaz fixée à 30 000 000, théoriquement, il y a une limite de 1 875 000 octets (30 000 000 / 16) par bloc, où 16 unités de gaz sont nécessaires pour chaque octet de données d’appel traité par l’EVM, ce qui donne une capacité de données maximale d’environ 1,79 Mo par bloc. Les données liées au rollup générées par les séquenceurs L2 sont généralement volumineuses, ce qui crée une concurrence avec les transactions des autres utilisateurs du réseau principal et réduit le nombre de transactions pouvant être incluses dans un seul bloc, affectant ainsi le TPS du réseau principal.

Pour résoudre ce problème, les principaux développeurs ont proposé l’EIP-4844 le 5 février 2022, qui a été mis en œuvre après la mise à niveau de Dencun au début du T2 2024. Cette proposition a introduit un nouveau type de transaction appelé Transaction Blob. Contrairement aux transactions traditionnelles, Blob Transaction inclut un nouveau type de données, les données Blob, qui, contrairement aux calldata, ne peuvent pas être directement accessibles par l’EVM mais uniquement via son hachage, également connu sous le nom de VersionedHash. De plus, les transactions Blob ont un cycle GC plus court que les transactions normales, ce qui évite que les données de bloc ne deviennent trop gonflées. Les données Blob sont également dotées d’un mécanisme de gaz inhérent, similaire à EIP-1559, mais utilisent une fonction exponentielle naturelle dans son modèle mathématique, offrant une meilleure stabilité dans la gestion des fluctuations de taille des transactions. La pente de la fonction exponentielle naturelle est également une fonction exponentielle naturelle, ce qui signifie que, quel que soit l’état actuel de la taille des transactions du réseau, les frais de base du gaz blob réagissent plus pleinement aux pics rapides des transactions, freinant efficacement l’activité de transaction. Une autre caractéristique clé est que la valeur de la fonction est 1 lorsque l’axe horizontal est 0.

base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS e*(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)

Ici, MIN_BASE_FEE_PER_BLOB_GAS et BLOB_BASE_FEE_UPDATE_FRACTION sont des constantes, tandis que excess_blob_gas est déterminée par la différence entre la consommation totale de gaz blob dans le bloc parent et une TARGET_BLOB_GAS_PER_BLOCK constante. Lorsque la consommation totale de gaz blob dépasse la valeur cible, ce qui rend la différence positive, e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) est supérieur à 1, ce qui entraîne une augmentation de la base_fee_per_blob_gas, et vice versa.

Ce mécanisme permet une exécution à faible coût de scénarios où la capacité de consensus d’Ethereum est utilisée pour notarier de grands volumes de données afin de garantir la disponibilité sans occuper la capacité de packaging des transactions. Par exemple, les séquenceurs de cumul peuvent utiliser des transactions d’objets blob pour encapsuler des informations clés L2 dans des données d’objets blob et effectuer une vérification sur la chaîne via VersionedHash dans l’EVM.

Il convient de noter que les paramètres actuels de TARGET_BLOB_GAS_PER_BLOCK et MAX_BLOB_GAS_PER_BLOCK imposent une limitation au réseau principal, avec un objectif moyen de traitement de 3 objets blob (0,375 Mo) par bloc et un maximum de 6 objets blob (0,75 Mo) par bloc. Ces limites initiales visent à minimiser la pression sur le réseau causée par cette EIP, et l’on s’attend à ce qu’elles augmentent ces limites lors des futures mises à niveau à mesure que le réseau démontre sa fiabilité sous des blocs de plus grande taille.

Affinage du modèle de consommation de gaz pour les environnements d’exécution : EIP-7706

Après avoir compris le modèle actuel d’Ethereum Gas, plongeons dans les objectifs et les détails de la mise en œuvre de la proposition EIP-7706. Cette proposition, présentée par Vitalik le 13 mai 2024, vise à redéfinir le modèle Gas pour un champ de données spécifique connu sous le nom de calldata, un peu comme les changements précédents pour les données Blob. De plus, la proposition optimise la logique de code correspondante.

Concepts fondamentaux

La logique de calcul des frais de base pour les données d’appel dans EIP-7706 reflète le calcul des frais de base pour les données d’objets blob comme spécifié dans EIP-4844. Les deux utilisent une fonction exponentielle pour ajuster les frais de base en fonction de l’écart entre la consommation réelle de gaz et la valeur cible dans le bloc parent.

Un aspect notable de cette proposition est l’introduction d’un nouveau plan de paramètre, LIMIT_TARGET_RATIOS = [2, 2, 4]. Voici la répartition :

LIMIT_TARGET_RATIOS[0] : Ratio cible pour le gaz d’opération d’exécution.

LIMIT_TARGET_RATIOS[1] : Ratio cible pour le gaz de données Blob.

LIMIT_TARGET_RATIOS[2] : Ratio cible pour le gaz calldata.

Ces ratios sont utilisés pour calculer les valeurs cibles de gaz pour les trois types de gaz dans le bloc parent en divisant la limite de gaz par les rapports respectifs.

Les limites de gaz sont fixées comme suit :

• gas_limits[0] suit la formule d’ajustement existante.

• gas_limits[1]MAX_BLOB_GAS_PER_BLOCKest égal à .

• gas_limits[2]gas_limits[0] / CALLDATA_GAS_LIMIT_RATIOest égal à .

Étant donné que le courant gas_limits[0] est de 30 000 000 et que le CALLDATA_GAS_LIMIT_RATIO est préréglé sur 4, cela signifie que la cible de gaz actuelle calldata est approximativement :

[ \frac{30 000 000}{4 \times 4} = 1 875 000 ]

Selon la logique actuelle calldata de calcul du gaz :

• Chaque octet non nul consomme 16 gaz.

• Chaque octet zéro consomme 4 gaz.

En supposant une distribution paire d’octets non nuls et nuls dans un segment de , la consommation moyenne de gaz par octet est de calldata10 gaz. Par conséquent, l’objectif actuel calldata de gaz correspond à environ 187 500 octets de calldata, soit environ le double de l’utilisation moyenne actuelle.

Avantages de la proposition

Cet ajustement réduit considérablement la probabilité d’atteindre la limite de calldata gaz, en maintenant calldata l’utilisation à un niveau constant grâce à la modélisation économique et en prévenant les abus. L’objectif principal de cette conception est de faciliter la croissance des solutions de couche 2, en réduisant les coûts du séquenceur lorsqu’il est utilisé avec des données blob.

En conclusion, l’EIP-7706 affine non seulement le modèle calldata de gaz, mais positionne également stratégiquement Ethereum pour la mise à l’échelle efficace des solutions de couche 2 en contrôlant et en optimisant la consommation de gaz liée aux données.

Démenti:

1. Cet article est reproduit à partir de [Web3Mario], Tous les droits d’auteur appartiennent à l’auteur original [Web3Mario]. S’il y a des objections à cette réimpression, veuillez contacter l’équipe Gate Learn , et ils s’en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l’auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l’article dans d’autres langues sont effectuées par l’équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.