Auteur : @Web3Mario
Introduction : Le 13 mai 2024, Vitalik a publié la proposition EIP-7706, qui complète le modèle actuel de gas en isolant le calcul du coût du calldata et en instaurant un mécanisme de prix similaire à celui du blob gas via une base fee ajustable, réduisant ainsi davantage les coûts d'exploitation des L2. Cette proposition fait suite à l'EIP-4844 proposée en février 2022, avec un écart temporel important entre les deux. Afin de mieux comprendre les dernières évolutions du mécanisme de gas d’Ethereum, nous présentons ici une synthèse actualisée pour faciliter la compréhension générale.
Modèles actuels de gas sur Ethereum — EIP-1559 et EIP-4844
Dans sa conception initiale, Ethereum utilisait un simple mécanisme d’enchères pour fixer les frais de transaction : chaque utilisateur devait spécifier manuellement le prix du gas (gas price). Étant donné que ces frais revenaient aux mineurs, ceux-ci priorisaient naturellement les transactions offrant le prix le plus élevé, selon un principe d’optimisation économique (en l’absence de MEV). Toutefois, les développeurs principaux ont identifié quatre problèmes majeurs liés à ce système :
l Insuffisante corrélation entre la volatilité des frais et le coût réel du consensus : Sur une blockchain active, la demande de place dans les blocs est élevée, entraînant facilement des blocs pleins, mais aussi une forte volatilité des frais. Par exemple, si le prix moyen du gas passe de 1 Gwei à 10 Gwei, le coût marginal pour inclure une transaction supplémentaire est multiplié par 10, ce qui est inacceptable.
l Retards inutiles pour les utilisateurs : La limite stricte du gas par bloc, combinée aux fluctuations naturelles du volume de transactions, force souvent celles-ci à attendre plusieurs blocs avant d’être incluses. Cela s’avère inefficace pour le réseau, car il n’existe pas de mécanisme souple permettant à un bloc d’être plus grand quand nécessaire, suivi d’un bloc plus petit.
l Inefficacité du mécanisme de tarification : Le système d’enchères conduit à une découverte inefficace du prix juste, rendant difficile pour les utilisateurs de proposer un prix raisonnable. Dans de nombreux cas, ils paient donc trop cher.
l Instabilité des blockchains sans récompense de bloc : En supprimant la récompense de minage pour adopter uniquement un modèle basé sur les frais, on risque d’encourager des comportements malveillants comme la création de "blocs sœurs" visant à capter les frais ou de renforcer les attaques par minage égoïste.
L’introduction et l’implémentation de l’EIP-1559 ont marqué la première évolution significative du modèle de gas. Proposé par Vitalik et d’autres développeurs clés le 13 avril 2019, il a été intégré lors de la mise à niveau London le 5 août 2021. Ce nouveau mécanisme remplace l’enchère par un modèle à double tarification composé d’une base fee et d’une priority fee. La base fee est calculée automatiquement selon un modèle mathématique prenant en compte la consommation de gas du bloc précédent par rapport à un objectif cible variable. Si la consommation dépasse cet objectif, la base fee augmente ; sinon, elle diminue. Ce mécanisme reflète mieux l’offre et la demande tout en facilitant la prévision du prix du gas, évitant ainsi les erreurs conduisant à des frais exorbitants, puisque la base fee est déterminée systématiquement, non par l’utilisateur. Voici le code correspondant :
On observe que lorsque parent_gas_used excède parent_gas_target, la base fee du bloc courant augmente d’un montant proportionnel au surplus, calculé à partir du produit de parent_base_fee par le ratio de dépassement, divisé par le minimum entre gas_target et une constante. Le raisonnement est symétrique en cas de sous-utilisation.
Par ailleurs, la base fee n’est plus versée aux mineurs, mais brûlée, plaçant ainsi le modèle économique de l’ETH en situation de contraction, favorable à la stabilité de sa valeur. La priority fee, quant à elle, constitue un pourboire optionnel pour les validateurs, qu’ils peuvent librement choisir, permettant ainsi une certaine réutilisation de leurs algorithmes de priorisation.
En 2021, les Rollups commençaient à se développer fortement. Que ce soit OP Rollup ou ZK Rollup, tous nécessitent de publier sur la chaîne principale des données compressées (via calldata) afin d’assurer la disponibilité des données (Data Availability) ou leur vérification directe. Cette contrainte imposait aux solutions Rollup des coûts élevés en gas lors du maintien de la finalité de L2, coûts finalement répercutés sur les utilisateurs. De ce fait, les frais associés aux protocoles L2 n’étaient pas aussi bas qu’on aurait pu l’espérer.
Parallèlement, Ethereum connaissait une forte compétition pour l’espace bloc. Chaque bloc étant limité en gas (actuellement 30 000 000), cela implique une limite théorique de 30 000 000 / 16 = 1 875 000 octets, sachant que chaque octet de calldata coûte 16 unités de gas dans l’EVM. Un bloc peut donc contenir environ 1,79 Mo de données. Or, les données générées par les séquenceurs des Rollups sont souvent volumineuses, ce qui crée une concurrence avec les transactions ordinaires, réduit le nombre total de transactions pouvant être incluses et affecte ainsi le TPS de la chaîne principale.
Pour résoudre ce problème, les développeurs ont proposé l’EIP-4844 le 5 février 2022, mis en œuvre lors de la mise à niveau Dencun au début du deuxième trimestre 2024. Cette proposition introduit un nouveau type de transaction appelé « Blob Transaction », dont l’innovation repose sur l’ajout d’un nouveau type de données : le blob data. Contrairement au calldata, le blob data ne peut pas être lu directement par l’EVM, seul son hachage (appelé VersionedHash) est accessible. Deux autres caractéristiques accompagnent cette nouveauté : premièrement, le cycle de garbage collection (GC) des blobs est plus court, limitant ainsi la croissance excessive de la taille des blocs ; deuxièmement, le blob data dispose d’un mécanisme de gas natif, similaire en esprit à l’EIP-1559, mais reposant sur une fonction exponentielle naturelle pour une meilleure stabilité face aux variations de volume. En effet, la pente de la fonction exponentielle étant elle-même exponentielle, la base fee réagit plus fortement lors de pics d’activité, freinant efficacement la surcharge du réseau. Une propriété importante de cette fonction est qu’elle vaut 1 lorsque l’entrée est nulle.
base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS * e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)
MIN_BASE_FEE_PER_BLOB_GAS et BLOB_BASE_FEE_UPDATE_FRACTION sont deux constantes. Le terme excess_blob_gas représente la différence entre la consommation totale de blob gas dans le bloc parent et une constante TARGET_BLOB_GAS_PER_BLOCK. Si cette consommation dépasse l’objectif (différence positive), alors e**(excess_blob_gas / ...) > 1, et la base fee augmente ; sinon, elle diminue.
Ce dispositif permet désormais de stocker des données volumineuses à faible coût grâce au consensus d’Ethereum, sans compromettre la capacité de traitement des transactions classiques. Par exemple, un séquenceur Rollup peut encapsuler les informations critiques de L2 dans un blob data, puis utiliser le VersionedHash pour implémenter la logique de vérification sur chaîne via l’EVM.
Il convient de noter que les paramètres actuels TARGET_BLOB_GAS_PER_BLOCK et MAX_BLOB_GAS_PER_BLOCK imposent une limite : chaque bloc peut traiter en moyenne 3 blobs (0,375 Mo) avec un maximum de 6 blobs (0,75 Mo). Ces limites initiales visent à minimiser la pression sur le réseau, mais devraient augmenter dans les mises à jour futures à mesure que la fiabilité du réseau sera confirmée avec des blocs plus grands.
Raffinement du modèle de gas pour l’environnement d’exécution — EIP-7706
Après avoir clarifié les modèles actuels de gas sur Ethereum, examinons maintenant les objectifs et détails techniques de la proposition EIP-7706, publiée par Vitalik le 13 mai 2024. À l’instar du blob data, cette proposition isole le modèle de gas d’un autre champ de données particulier : le calldata. Elle optimise également la logique d’implémentation du code.
Sur le plan technique, le calcul de la base fee pour le calldata suit le même principe que celui défini dans l’EIP-4844 pour le blob data : une fonction exponentielle ajuste la base fee en fonction de l’écart entre la consommation réelle de gas dans le bloc précédent et une cible prédéfinie.
Un nouveau paramètre apparaît ici : LIMIT_TARGET_RATIOS=[2,2,4], où :
- LIMIT_TARGET_RATIOS[0] : taux cible pour le gas lié aux opérations d’exécution,
- LIMIT_TARGET_RATIOS[1] : taux cible pour le gas blob data,
- LIMIT_TARGET_RATIOS[2] : taux cible pour le gas calldata.
Ce vecteur permet de calculer les objectifs de gas pour chaque catégorie dans le bloc précédent, selon la formule suivante (division entière du gas limit par le ratio correspondant) :
La logique de définition 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
Sachant que gas_limits[0] = 30 000 000 et CALLDATA_GAS_LIMIT_RATIO = 4, on obtient un objectif de gas calldata de 30 000 000 // 4 // 4 = 1 875 000. Comme chaque octet non nul coûte 16 gas et chaque octet nul coûte 4 gas, avec une répartition 50/50, le coût moyen par octet est de 10 gas. L’objectif correspond donc à environ 187 500 octets de calldata, soit environ deux fois la consommation moyenne actuelle.
Cet ajustement présente plusieurs avantages : il réduit considérablement la probabilité d’atteindre la limite de gas liée au calldata, stabilise économiquement son utilisation et empêche toute forme de surutilisation. Cette conception vise à faciliter le développement des L2, en complémentarité avec le blob data, afin de réduire encore davantage les coûts des séquenceurs.
@web3_mario
