Détaillez EIP-7706 et triez les dernières mécaniques d’Ethereum Gas

Auteur original : @Web3 Mario

Introduction : Le 13 mai 2024, Vitalik a publié la proposition EIP-7706, proposant une solution complémentaire au modèle gas existant, séparant le calcul gas des données d’appel et personnalisant un mécanisme de tarification des frais de base similaire à Blob gas pour Goutte davantage le coût de fonctionnement de L2. La proposition connexe doit également être retracée jusqu’à EIP-4844 proposée en février 2022, ce qui est il y a long temps, alors consultez les documents pertinents pour fournir un aperçu du dernier mécanisme Ethereum Gas pour que vous compreniez rapidement.

Les modèles Ethereum Gas actuellement pris en charge - EIP-1559 et EIP-4844

Dans la conception originale, Ethereum utilise un mécanisme d’enchères simple pour fixer le prix de Blanchiment de capitaux, ce qui oblige les utilisateurs à enchérir activement pour leurs propres transactions, c’est-à-dire à fixer un prix du gas, normalement, car les frais de transaction payés par les utilisateurs seront vesting que Mineur, de sorte que le Mineur déterminera le ordre de l’emballage des transactions selon le principe de l’optimalité économique, selon le niveau d’enchères, notez que c’est dans le cas de l’ignorance de MEV. Aux yeux des développeurs principaux de l’époque, ce mécanisme se heurtait aux quatre problèmes suivants :

• Fluctuation du niveau de blanchiment d’argent et du coût consensuel des transactions : Dans une Blockchain active, il y a une demande suffisante pour l’emballage des transactions, ce qui signifie que les blocs peuvent être facilement remplis, mais cela signifie souvent aussi que la fluctuation globale des frais est extrêmement élevée. Par exemple, lorsque le prix du gaz moyen est de 10 Gwei, le coût marginal du réseau pour accepter une transaction supplémentaire dans un bloc est 10 fois supérieur au prix du gaz moyen de 1 Gwei, ce qui est inacceptable.
• Latence inutile pour les utilisateurs : En raison de la limite de gaz stricte de chaque bloc, associée à la fluctuation naturelle du volume historique, les transactions attendent généralement que plusieurs blocs soient empaquetés, mais cela est inefficace pour l’ensemble du réseau ; C’est-à-dire qu’il n’y a pas de mécanisme de « mou » qui permet à un bloc d’être plus grand et au bloc suivant plus petit pour répondre aux différences de besoins qui sont blocs au cas par cas.
• Tarification inefficace : L’utilisation d’un mécanisme d’enchères simple conduit à une découverte inefficace du prix équitable, ce qui signifie qu’il sera difficile pour les utilisateurs de donner un prix raisonnable, ce qui signifie que dans des cas très longs, les utilisateurs paient des frais élevés.
• Les Blockchain sans Récompense du bloc seront instables : lorsque le Récompense du bloc apporté par Mining est supprimé et qu’un modèle de frais purs est adopté, cela peut conduire à une instabilité très long, comme inciter le minage à voler Blanchiment de capitaux « blocs frères », ouvrir des selfish mining Vecteur d’attaque plus puissants, etc.

Ce n’est que lorsque l’EIP-1559 a été proposé et mis en œuvre qu’il y a eu une première itération du modèle Gas, qui a été proposé par des développeurs principaux tels que Vitalik le 13 avril 2019 et adopté dans la mise à niveau de Londres le 5 août 2021, qui a abandonné le mécanisme d’enchères en faveur d’un modèle de double tarification des frais de base et des frais prioritaires, où les frais de base seraient basés sur le gas déjà généré dans le bloc parent La relation entre la consommation et une cible de gaz flottante et récursive est calculée quantitativement à l’aide d’un modèle mathématique établi, et 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, la redevance de base sera augmentée, et si elle est inférieure à la cible de gaz, la redevance de base sera abaissée, ce qui peut non seulement mieux refléter la relation entre l’offre et la demande, mais aussi rendre la prédiction de gaz raisonnable plus précise. Il n’y aura pas de prix du gaz exorbitant en raison d’une mauvaise utilisation, car le calcul de la redevance de base est directement déterminé par le système plutôt que librement spécifié par l’utilisateur. Le code spécifique est le suivant :

On peut voir que lorsque parent\gas_used est supérieur à parent_gas_target, les frais de base de l’Bloc actuel seront comparés aux frais de base de l’Bloc précédente plus une valeur de compensation, et la valeur de compensation est prise comme parent_base_fee multipliée par le décalage de l’utilisation totale de la Bloc gas précédente par rapport à gas cible, et la valeur maximale du reste de 1 avec gas cible et une constante. La logique inverse est similaire.

En outre, les frais de base ne seront pas distribués plus long aux mineurs en guise de récompense, mais seront brûlés directement, de sorte que le modèle économique de l’ETH soit dans un état déflationniste, ce qui est propice à la stabilité de la valeur. D’autre part, les frais prioritaires sont équivalents au pourboire de l’utilisateur au mineur, et le prix peut être fixé librement, ce qui peut permettre à l’algorithme de tri du mineur d’être réutilisé dans une certaine mesure.

Au fur et à mesure que le temps avance vers 2021, lorsque le développement de Rollup entre progressivement dans un meilleur état, nous savons que OP Rollup et ZK Rollup signifient que certaines données de preuve après compression des données L2 doivent être téléchargées sur la chaîne off-chain via calldata pour assurer la disponibilité des données ou directement remises à l’off-chain pour vérification. Par conséquent, ces solutions de cumul sont confrontées à des coûts de gas importants lors du maintien de la finalité L2, et ces coûts sont finalement répercutés sur les utilisateurs, de sorte que la plupart des coûts d’utilisation du protocole L2 ne sont pas aussi bas qu’imaginé.

Dans le même temps, Ethereum est également confronté au dilemme de la concurrence entre Bloc short, nous savons qu’il existe un limite de gas pour chaque Bloc, ce qui signifie que la consommation totale de gas de toutes les transactions dans le Bloc actuel ne peut pas dépasser cette valeur, sur la base de la limite de gas actuelle de 300000000, il existe une limite théorique de 30 000 000 / 16 = 1 875 000 octets, où 16 fait référence à la consommation de 16 par octet calldata traité par le EVM Cela signifie que la long maximale d’un seul Bloc peut transporter des données est d’environ 1,79 Mo. Les données liées au cumul générées par le séquenceur L2 sont généralement à grande échelle, ce qui les met en concurrence avec les confirmations de transaction des autres utilisateurs de la mainchain, ce qui entraîne un volume plus petit qui peut être emballé dans un seul bloc, ce qui affecte à son tour le TPS de la mainchain.

Pour résoudre ce dilemme, les développeurs principaux ont proposé 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. La proposition propose un nouveau type de transaction appelé Blob Transaction, qui est basé sur un nouveau type de données, Blob data, qui est un nouveau type de données, Blob data, par rapport au type traditionnel de Transaction. Contrairement au type calldata, les données d’objet blob ne peuvent pas être directement accessibles par EVM, mais uniquement par son hash, également appelé VersionedHash. En outre, il existe deux conceptions d’accompagnement, l’une est que, par rapport aux transactions ordinaires, la période GC des transactions blob est plus courte, afin de garantir que les données de bloc ne sont pas trop gonflées, et la seconde est que les données blob ont un mécanisme de gas natif, qui présente généralement un effet similaire à EIP-1559, mais choisit la fonction exponentielle naturelle dans le modèle mathématique, de sorte qu’il peut mieux fonctionner en stabilité lorsqu’il s’agit de fluctuations de taille de transaction, car la pente de la fonction exponentielle naturelle est également une fonction exponentielle naturelle, Cela signifie que, quel que soit l’état dans lequel se trouve la taille de transaction réseau à ce moment-là, lorsque la taille de la transaction augmente rapidement, les frais de base du gas blob répondent plus pleinement, freinant ainsi efficacement l’activité de transaction, et la fonction a également une caractéristique importante, lorsque l’abscisse est 0, la valeur de la fonction est 1.

base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS * e*\(excès_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)

où MIN_BASE_FEE_PER_BLOB_GAS et BLOB_BASE_FEE_UPDATE_FRACTION sont deux constantes, tandis que l’excès_blob_gas est déterminé par la différence entre le nombre total d’objets blob dans le Bloc gas parent et une constante TARGET_BLOB_GAS_PER_BLOCK, lorsque le nombre total d’objets blob gas Lorsque la consommation dépasse la valeur cible, c’est-à-dire lorsque la différence est positive, e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) est supérieur à 1, alors base_fee_per_blob_gas devient plus grande, et vice versa devient plus petite.

De cette façon, pour certains scénarios qui souhaitent uniquement utiliser la capacité de consensus d’Ethereum pour stocker des données à grande échelle afin d’assurer la disponibilité, il peut être exécuté à faible coût sans évincer la capacité d’empaquetage de transaction du bloc. En prenant l’exemple du séquenceur de cumul, les informations clés de L2 peuvent être encapsulées dans des données blob via une transaction blob, et la logique de vérification off-chain peut être implémentée en utilisant versionedHash grâce à une conception intelligente dans l’EVM.

Il convient d’ajouter que les paramètres actuels TARGET_BLOB_GAS_PER_BLOCK et MAX_BLOB_GAS_PER_BLOCK introduisent une limite d’Mainnet de 3 objets blob (0,375 Mo) par Bloc et un maximum de 6 objets blob (0,75 Mo) par long. Ces limites initiales sont conçues pour minimiser la pression exercée sur le réseau par cette EIP et devraient augmenter lors des futures mises à niveau, à mesure que le réseau démontrera sa fiabilité sur des blocs plus importants.

Affine le modèle de consommation de gas pour l’environnement d’exécution - EIP-7706

Maintenant que le modèle Ethereum gas actuel a été clarifié, jetons un coup d’œil aux objectifs et aux détails de la mise en œuvre de la proposition EIP-7706. La proposition a été présentée par Vitalik le 13 mai 2024. Semblable aux données blob, cette proposition supprime le modèle gas pour un autre champ de données spécial, qui est calldata. Et la logique d’implémentation du code correspondante a été optimisée.

En principe, la logique de calcul des frais de base de calldata est la même que celle des frais de base pour les données blob dans EIP-4844, qui utilise une fonction exponentielle et calcule la mise à l’échelle des frais de base actuels en fonction de la valeur d’écart de la valeur réelle de consommation de gas dans le bloc parent par rapport à la valeur cible.

Il est intéressant 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 la classe d’opération Gas, LIMIT_TARGET_RATIOS[ 1 ] représente le ratio cible de la classe de données Blob Gas, et LIMIT_TARGET_RATIOS [ 2 ] représente les données d’appel Le rapport cible de la classe Gas, ce vecteur est utilisé pour calculer les valeurs cibles gas correspondant aux trois classes de gas dans le Bloc parent, et la logique de calcul est la suivante, c’est-à-dire que le limite de gas est divisible par LIMIT_TARGET_RATIOS respectivement :

La logique de gas_limits est la suivante :

gas_limits[ 0 ] doit suivre la formule d’ajustement existante

gas_limits[ 1 ] doit être égal à MAX_BLOB_GAS_PER_BLOCK

gas_limits[ 2 ] doit être égal à gas_limits[ 0 ] // CALLDATA_GAS_LIMIT_RATIO

Nous savons que le gas_limits[ 0 ] actuel est de 300000000, et que CALLDATA_GAS_LIMIT_RATIO est préréglé à 4, ce qui signifie que la cible actuelle de l’gas calldata est d’environ 300000000 // 4 // 4 = 1875000, et parce que selon la logique de calcul du gas calldata actuel, chaque octet non nul consomme 16 gas, et zéro octet consomme 4 gas. En supposant que la distribution d’octets non nuls et nuls dans un certain segment de calldata représente 50% chacun, il faut en moyenne 10 gas pour traiter 1 octet de calldata. Par conséquent, la cible actuelle de gas calldata devrait faire face à 187500 octets de données calldata, soit environ 2 fois l’utilisation moyenne actuelle.

L’avantage est que la probabilité que les données d’appel atteignent la limite de gaz est considérablement réduite, et l’utilisation des données d’appel est maintenue dans un état plus cohérent grâce à la modélisation économique, et l’abus de données d’appel est également éliminé. La raison de cette conception est d’ouvrir la voie au développement de L2, et avec les données blob, le coût du séquenceur est encore réduit.