Introduction : Le 13 mai 2024, Vitalik a proposé l'EIP-7706, qui complète le modèle de Gas existant en supprimant séparément le calcul du gas pour les calldata et en personnalisant un mécanisme de tarification des frais de base similaire au gas Blob, réduisant ainsi davantage les coûts d'exploitation de la Couche 2. Les propositions connexes doivent également remonter à l'EIP-4844 proposé en février 2022, ce qui représente un long laps de temps. Par conséquent, en consultant les documents connexes, nous espérons fournir un résumé du dernier mécanisme de Gas d'Ethereum pour faciliter la compréhension rapide de tous.

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

Dans la conception initiale, Ethereum a adopté un mécanisme d'enchères simple pour fixer les frais de transaction, obligeant les utilisateurs à enchérir activement pour leurs transactions, c'est-à-dire fixer les prix du gaz. En général, parce que les frais de transaction payés par les utilisateurs vont aux mineurs, les mineurs décident de l'ordre de l'emballage des transactions en fonction du principe de l'optimalité économique, selon le prix de l'enchère, en ignorant la situation de MEV. Selon les développeurs principaux de l'époque, ce mécanisme était confronté à quatre problèmes.

La fluctuation des niveaux de frais de transaction ne correspond pas au coût consensuel des transactions : Pour les blockchains dans un état actif, il y a une demande suffisante pour l'emballage des transactions, ce qui signifie que les blocs peuvent être facilement remplis, mais cela entraîne souvent des fluctuations significatives des frais globaux. Par exemple, lorsque le prix moyen du Gas est de 10 Gwei, le coût marginal encouru par le réseau pour accepter une autre transaction dans un bloc est dix fois plus élevé que lorsque le prix moyen du Gas est de 1 Gwei, ce qui est inacceptable.

Retards inutiles pour les utilisateurs : En raison de la limite rigide de gaslimit pour chaque bloc, associée à la fluctuation naturelle des volumes de transactions historiques, les transactions doivent souvent attendre plusieurs blocs pour être traitées, ce qui est inefficace pour l'ensemble du réseau. Il n'y a pas de mécanisme de "relâchement" qui permettrait à un bloc d'être plus grand et au bloc suivant d'être plus petit pour répondre aux différences de demande entre les blocs.

Tarification inefficace : L'adoption d'un mécanisme d'enchères simple a conduit à une faible efficacité dans la découverte du juste prix, ce qui signifie qu'il est difficile pour les utilisateurs de donner un prix raisonnable, entraînant de nombreux cas où les utilisateurs paient des frais excessifs.

La blockchain sans récompenses en bloc sera instable : Lors de l'annulation des récompenses en bloc résultant du minage et de l'adoption d'un modèle de frais pur, cela peut entraîner de nombreuses instabilités, telles que l'incitation à miner des « blocs frères » pour voler les frais de transaction, ouvrir davantage de vecteurs d'attaque de minage égoïste plus puissants, etc.

Jusqu'à la proposition et la mise en œuvre de l'EIP-1559, il y avait une première itération du modèle de Gas. L'EIP-1559, proposée par Vitalik et d'autres développeurs principaux le 13 avril 2019, a été adoptée lors de la mise à niveau de Londres le 5 août 2021. Ce mécanisme abandonne le mécanisme d'enchères et adopte plutôt un modèle de tarification double de frais de base et de frais de priorité. Les frais de base sont calculés quantitativement en fonction de la relation entre la consommation de gaz dans le bloc parent et une cible de gaz flottante et récursive à travers un modèle mathématique établi. L'effet intuitif est que si l'utilisation de gaz dans le bloc précédent dépasse la cible de gaz prédéterminée, les frais de base augmentent, et s'il est inférieur à la cible de gaz, les frais de base diminuent. Cela peut mieux refléter l'offre et la demande et rendre les prévisions pour un gaz raisonnable plus précises, empêchant les prix exorbitants du gaz dus à des erreurs d'opération car le calcul des frais de base est directement déterminé par le système plutôt que spécifié librement par les utilisateurs. Le code spécifique est le suivant:

On peut déduire que lorsque parent_gas_used est supérieur à parent_gas_target, les frais de base du bloc actuel seront comparés aux frais de base du bloc précédent plus une valeur de décalage. En ce qui concerne la valeur de décalage, elle est calculée en multipliant parent_base_fee par le décalage de l'utilisation totale de gaz du bloc précédent par rapport à la cible de gaz et en prenant le modulo avec la cible de gaz et une constante, puis en prenant la valeur maximale du résultat et 1. La logique est similaire en sens inverse.

De plus, les frais de base ne seront plus alloués comme récompense aux mineurs, mais seront directement brûlés, mettant ainsi le modèle économique d'Ethereum dans un état déflationniste, ce qui est propice à la stabilité de la valeur. D'autre part, les frais de priorité sont semblables à un pourboire donné par les utilisateurs aux mineurs et peuvent être fixés librement, ce qui permet dans une certaine mesure de réutiliser l'algorithme de séquençage des mineurs.

Au fur et à mesure que l'année 2021 avançait, le développement des Rollups a progressivement atteint son apogée. Nous savons que qu'il s'agisse de Rollups OP ou de Rollups ZK, cela implique la nécessité de télécharger certaines données de preuve de données L2 compressées sur la chaîne via call data pour atteindre la disponibilité des données on-chain, ou d'être directement vérifié on-chain. Cela entraîne des coûts significatifs en gaz pour maintenir la finalité de L2, qui sont finalement répercutés sur les utilisateurs. Par conséquent, le coût d'utilisation de la plupart des protocoles L2 n'était pas aussi bas qu'imaginé à l'époque.

En même temps, Ethereum a également fait face au dilemme de la concurrence pour l'espace de blocs. Nous savons que chaque bloc a une limite de gaz, ce qui signifie que la consommation totale de gaz de toutes les transactions dans le bloc actuel ne peut pas dépasser cette valeur. En calculant en fonction de la limite de gaz actuelle de 30 000 000, il y a théoriquement une limite de 1 875 000 octets, où 16 fait référence au gaz consommé par octet de données de calldata traité par l'EVM. Cela implique que la taille de données maximale pouvant être logée dans un seul bloc est d'environ 1,79 Mo. Cependant, les données liées à Rollup générées par les séquenceurs L2 ont généralement une taille de données plus importante, ce qui entre en concurrence avec la confirmation des transactions par d'autres utilisateurs de la chaîne principale, entraînant une diminution du nombre de transactions pouvant être regroupées dans un seul bloc, affectant ainsi le TPS de la chaîne principale.

Pour résoudre ce dilemme, les développeurs principaux ont proposé l'EIP-4844 le 5 février 2022, qui a été mis en œuvre après la mise à niveau de Dencun au deuxième trimestre de 2024. Cette proposition introduit un nouveau type de transaction appelé Transaction Blob. Contrairement aux types de transactions traditionnels, l'idée principale de la Transaction Blob ajoute un nouveau type de données, à savoir les données Blob. Contrairement aux types calldata, les données blob ne peuvent pas être accédées directement par l'EVM mais peuvent uniquement accéder à son hachage, également connu sous le nom de VersionedHash. Deux conceptions accompagnantes sont également introduites. Tout d'abord, par rapport aux transactions régulières, le cycle GC des transactions blob est plus court, garantissant que les données de bloc ne deviennent pas trop volumineuses. Deuxièmement, les données blob disposent d'un mécanisme de Gas natif. Dans l'ensemble, l'effet présenté est similaire à l'EIP-1559, mais le modèle mathématique sélectionne une fonction exponentielle naturelle, qui se comporte mieux en termes de stabilité lors de la gestion des fluctuations du volume des transactions. Cela est dû au fait que la pente de la fonction exponentielle naturelle est également une fonction exponentielle naturelle, ce qui signifie que quel que soit l'état du volume des transactions du réseau, lorsque le volume des transactions augmente rapidement, la taxe de base du gas blob reflète plus pleinement, ce qui limite efficacement l'activité des transactions. De plus, cette fonction a une caractéristique importante où la valeur de la fonction est de 1 lorsque l'abscisse est de 0.

base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS e*(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)

Où MIN_BASE_FEE_PER_BLOB_GAS et BLOB_BASE_FEE_UPDATE_FRACTION sont deux constantes, et excess_blob_gas est déterminé par la différence entre la consommation totale de blob gas dans le bloc parent et une constante TARGET_BLOB_GAS_PER_BLOCK. Lorsque la consommation totale de blob gas dépasse la valeur cible, c'est-à-dire que la différence est positive, e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) est supérieur à 1, et base_fee_per_blob_gas augmente, sinon elle diminue.

Cela permet une exécution à faible coût dans les scénarios où seule la capacité de consensus d'Ethereum est souhaitée pour stocker des données à grande échelle afin de garantir la disponibilité, sans monopoliser la capacité de regroupement des transactions du bloc. En prenant le séquenceur Rollup comme exemple, les informations critiques de L2 peuvent être encapsulées dans des données blob via des transactions de blob, et la logique de vérification on-chain peut être mise en œuvre dans l'EVM à travers des conceptions sophistiquées utilisant des hashages versionnés.

Il convient de noter que le paramétrage actuel de TARGET_BLOB_GAS_PER_BLOCK et MAX_BLOB_GAS_PER_BLOCK impose une limitation sur le mainnet, à savoir un objectif de traitement moyen de 3 blocs (0,375 Mo) par bloc et une limite maximale de 6 blocs (0,75 Mo) par bloc. Ces limites initiales visent à minimiser la pression que l'EIP exerce sur le réseau et devraient être augmentées lors de futures mises à jour, à mesure que le réseau démontre sa fiabilité avec des blocs plus importants.

Affinement du modèle de consommation de gaz pour l'environnement d'exécution - EIP-7706

Après avoir clarifié le modèle de Gas actuel d'Ethereum, regardons les objectifs et les détails de mise en œuvre de la proposition EIP-7706. Cette proposition a été introduite par Vitalik le 13 mai 2024. Similaire aux données Blob, cette proposition sépare le modèle de Gas pour un autre champ de données spécial, à savoir calldata, et optimise la logique de mise en œuvre du code correspondant.

En principe, la logique de calcul des frais de base pour les données d'appel est la même que celle des données blob dans l'EIP-4844, toutes deux utilisant une fonction exponentielle pour calculer le facteur d'échelle des frais de base actuels en fonction de l'écart entre la valeur réelle de consommation de gaz dans le bloc parent et la valeur cible.

Il convient de noter une nouvelle conception de paramètre, LIMIT_TARGET_RATIOS=[2,2,4], où LIMIT_TARGET_RATIOS[0] représente le ratio cible de Gas pour les opérations d'exécution, LIMIT_TARGET_RATIOS[1] représente le ratio cible de Gas pour les données Blob, et LIMIT_TARGET_RATIOS[2] représente le ratio cible de Gas pour les calldata. Ce vecteur est utilisé pour calculer les valeurs cibles de gas pour les trois types de gas dans le bloc parent, en utilisant les LIMIT_TARGET_RATIOS pour une division entière sur la limite de gas comme suit:

La logique de configuration pour les limites de gaz est la suivante :

gas_limits[0] doit suivre la formule d'ajustement existante.

gas_limits[1] doit être égal à MAX_BLOB_GAS_PER_BLOCK.

les limites de gas[2] doivent être égales aux limites de gas[0] // RATIO_DE_LIMITE_DE_GAS_DE_CALLDATA.

Nous savons que le gas_limits[0] actuel est de 30000000, et que CALLDATA_GAS_LIMIT_RATIO est préréglé à 4. Cela signifie que l'objectif actuel de gas de calldata est d'environ 30000000 // 4 // 4 = 1875000. En effet, selon la logique de calcul actuelle du gas de calldata, chaque octet non nul consomme 16 Gas et les octets nuls consomment 4 Gas. En supposant que la répartition des octets non nuls et nuls dans un segment de calldata soit de 50%, le traitement moyen de 1 octet de calldata nécessite 10 Gas. Par conséquent, l'objectif actuel de gas de calldata devrait correspondre à des données de calldata de 187500 octets, soit environ le double de l'utilisation moyenne actuelle.

L'avantage de cette approche est de réduire considérablement la probabilité que les données d'appel atteignent la limite de gaz, de maintenir l'utilisation des données d'appel à un niveau relativement constant grâce au modèle économique, et de prévenir les abus des données d'appel. La raison de cette conception est de préparer le terrain pour le développement de L2, associé aux données de blob, pour réduire encore plus le coût du séquenceur.

Disclaimer：

1. Cet article est repris de [ TechFlow]. Tous les droits d'auteur appartiennent à l'auteur original [Web3Mario]. If there are objections to this reprint, please contact the Porte Apprendreéquipe, 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 réalisées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits sont interdits.