EIP-7623 : la proposition qui réévaluera le prix des données d'appel pour les transactions Ethereum

Les transactions de la blockchain consomment du processeur, de la mémoire, du stockage et d'autres ressources lorsqu'elles sont propagées, exécutées entre les nœuds et stockées. Par conséquent, une tarification appropriée des transactions est essentielle pour éviter les abus du réseau et obtenir une utilisation efficace des ressources.

Cependant, déterminer la tarification appropriée pour les transactions est un défi de longue date dans la conception des protocoles de blockchain. Vitalik Buterin, fondateur d'Ethereum, aborde cette question dans un ancien document de recherche :

« L’un des problèmes les plus difficiles dans la conception du protocole blockchain est de savoir comment limiter et tarifer la soumission des transactions qui sont incluses dans la chaîne. » — Vitalik Buterin

L'EIP-7623 est une proposition d'amélioration d'Ethereum (EIP) qui vise à modifier la tarification des données d'appel afin de limiter la taille maximale des blocs. Contrairement aux propositions précédentes qui se contentaient d'augmenter le coût des données d'appel, l'EIP-7623 se concentre sur la minimisation de son impact sur les transactions quotidiennes des utilisateurs tout en permettant une utilisation efficace des ressources.

Dans cet article, nous expliquons la raison d'être de la réévaluation des données d'appel utilisées par les transactions sur la couche 1 (L1) d'Ethereum et l'impact sur la taille des blocs et les performances du réseau. Nous établissons également le contexte des modifications proposées au mécanisme des frais de transaction d'Ethereum, en nous appuyant sur des années de recherche sur le problème de la tarification efficace des ressources de la blockchain.

Plongeons-nous dedans !

Préparation du terrain : pourquoi est-il si difficile de fixer correctement le prix des transactions ?

La tarification des transactions de blockchain est difficile car l’estimation de la quantité exacte de chaque ressource consommée par chaque transaction est intrinsèquement complexe. Actuellement, dans Ethereum, toutes les ressources sont représentées sous forme d’unités unifiées appelées « gaz » et « gaz blob » (introduites avec EIP-4844 ).

Il existe des règles prédéfinies qui convertissent la consommation de ressources de transaction en gaz, et ces règles sont périodiquement mises à jour. Voici quelques exemples de ces règles :

• Une transaction entraînant des frais généraux fixes d'au moins 21 000 gaz, principalement pour la vérification de la signature

• Consommation de gaz prédéfinie pour chaque opcode EVM

  
  

De plus, la consommation de gaz pour les données d'appel fait partie intégrante de ces règles, ce qui est moins connu mais très important. La tarification des données d'appel est cruciale car elle influence directement la taille maximale des blocs. De plus, elle a un impact sur toutes les transactions utilisant des contrats intelligents, affectant notamment le coût des transactions de cumul qui dépendent de l'espace des données d'appel (plutôt que des blobs) pour la disponibilité des données .

Pourquoi la taille des blocs est-elle importante ?

Ethereum fonctionne par tranches de 12 secondes, pendant lesquelles tous les nœuds validateurs doivent propager des blocs et des blobs, exécuter et valider des transactions et attester du nouveau bloc. Plus précisément, l'implémentation client Ethereum exige que les nœuds honnêtes reçoivent et valident les blocs dans les 4 premières secondes de la tranche. Ils attestent 4 secondes après le début de la tranche, ce qui signifie que les blocs arrivant après 4 secondes ne devraient pas obtenir d'attestations et sont susceptibles d'être réorganisés par le proposant suivant .

Pour minimiser les vues divisées entre les nœuds Ethereum, le temps d'exécution des blocs et le temps de propagation doivent être plafonnés. Ethereum limite le temps d'exécution des blocs en définissant une utilisation maximale de gaz, actuellement plafonnée à 30 millions avec un objectif de 15 millions . Cela signifie que les blocs Ethereum utiliseront environ 15 millions de gaz en moyenne, avec la capacité d'augmenter et de consommer 30 millions de gaz en période de forte activité.

De plus, chaque opcode EVM a un coût en gaz prédéterminé basé sur sa consommation de ressources. Par exemple, l' opcode SSTORE est plus coûteux que des opérations plus simples (par exemple, l'addition arithmétique (ADD)) car il implique l'accès et la modification du trie d'état. Cette tarification différenciée des opcodes EVM, ainsi que la limite de gaz totale, visaient à limiter le temps d'exécution total.

Bien que la limite de gaz d'un bloc puisse quelque peu limiter le temps d'exécution du bloc, le temps de propagation du bloc reste explicitement non limité. La taille du bloc est un facteur majeur affectant le temps de propagation dans les blockchains publiques. Par exemple, des tailles de bloc plus importantes augmentent la charge du réseau et les besoins en bande passante ; si la taille du bloc dépasse largement la bande passante de la plupart des nœuds, il faut plus de temps aux nœuds pour se propager complètement et recevoir le bloc, ce qui augmente le risque de blocs manqués ou réorganisés. (C'est pourquoi le protocole Bitcoin (avant Segwit ) avait une taille de bloc plafonnée à 1 Mo pour éviter l'augmentation des taux de fork et garantir la sécurité et les faibles exigences des nœuds de la blockchain.)

Actuellement, Ethereum ne dispose pas d'une limite de taille de bloc explicitement définie. Cependant, la taille maximale théorique du bloc peut être estimée en prenant en compte la limite de gaz, le coût des données d'appel, le taux de compression, etc. Bien que la taille actuelle du bloc d'Ethereum soit d'environ 2,78 Mo (à l'exclusion des blobs), la tarification actuelle des données d'appel autorise des charges utiles EL allant jusqu'à 7,15 Mo, tandis que la taille moyenne est beaucoup plus petite, environ 100 Ko.

Si des charges utiles aussi importantes étaient propagées de manière cohérente sur 10 minutes, elles pourraient atteindre environ 42,9 Mo, ce qui est nettement supérieur aux tailles de blocs typiques des autres réseaux blockchain.

Cela pourrait potentiellement surcharger le réseau Ethereum et amener les nœuds à avoir des vues différentes pendant une courte période dans un scénario d'attaque DoS où des charges utiles de 7,15 Mo continuent pendant un certain temps.

En pratique, la taille moyenne des blocs d'Ethereum est aujourd'hui d'environ 125 Ko, ce qui indique un écart important par rapport à la taille maximale des blocs. Cela soulève une autre préoccupation concernant l'inefficacité de l'utilisation des ressources. Par exemple, si le réseau peut gérer suffisamment de blocs de 1 Mo d'affilée, un écart important entre la taille moyenne des blocs et 1 Mo suggère qu'Ethereum a plus de capacité pour la fonctionnalité de disponibilité des données (DA) mais ne l'utilise pas efficacement.

En limitant la taille maximale des blocs et en alignant la taille moyenne des blocs plus près de ce maximum, Ethereum pourrait réduire les risques de consensus tout en parvenant à une utilisation plus efficace des ressources. C'est pourquoi l'EIP-7623 se concentre sur la taille maximale possible des blocs, qui est fortement affectée par la tarification des données d'appel.

Qu'est-ce que Calldata dans Ethereum ?

Calldata est un champ dans une transaction généralement utilisé pour indiquer les fonctions à appeler et les paramètres à transmettre. Par exemple, si vous souhaitez créer un NFT, vous devez inclure la méthode « mint » et les caractéristiques spécifiques du NFT dans le champ calldata. L'exemple suivant montre la première transaction de création d'un CryptoPunk en 2017.

Les données d'appel (appelées « données d'entrée » dans la figure) contiennent le nom de la fonction getPunk , représenté par 0xc81d1d5b, et l'index NFT, représenté par 0x00001eb0 (7856 en hexadécimal). Si vous transférez uniquement de l'ETH et n'interagissez avec aucun contrat intelligent, le champ calldata est nul ( 0x ).

Outre son objectif principal qui est de transmettre des paramètres aux contrats intelligents, calldata est également utilisé pour enregistrer des mémos simples ou par des rollups stockant leurs données de transaction. En d'autres termes, calldata n'a pas toujours besoin d'interagir avec des contrats intelligents ou de suivre des règles strictes ; il peut contenir des valeurs arbitraires.

En tirant parti de cette flexibilité, les cumuls optimistes tels que Optimism et Arbitrum, certains cumuls ZK (validité), les données de transaction de cumul post-compressées et les états mis à jour dans le champ calldata de leurs transactions de séquençage. Bien que l'EIP-4844 ait permis la disponibilité des données via des blobs au lieu de calldata, calldata est toujours préféré par les petits cumuls qui n'ont pas besoin de la totalité des 128 Ko d'un blob pour un seul lot.

Calldata est souvent utilisé pour la fonctionnalité DA car il s'agit du moyen le moins gourmand en gaz pour publier des données volumineuses sur l'EVM. C'est pourquoi la taille maximale du bloc est limitée par le prix de calldata. Le pire scénario se produit lorsqu'un bloc est rempli de transactions à des fins DA qui utilisent de petites quantités de gaz mais de grandes tailles de données.

Actuellement, le coût des données d'appel est de 4 gaz par octet nul et de 16 gaz par octet non nul. Les données d'appel peuvent être compressées à l'aide de la compression rapide ( EIP-706 ) et la taille de la transaction ne peut pas dépasser 125 Ko. Le calcul précis de la taille maximale du bloc est complexe en raison de la nature variable des taux de compression, mais on sait que le bloc peut augmenter jusqu'à environ 2,78 Mo.

Si des blocs de 2,78 Mo se succèdent pour certaines raisons (par exemple, des attaques de spam), le réseau peut être surchargé et les nœuds peuvent avoir des vues divisées en raison de faibles vitesses de propagation. Un plus grand nombre de nœuds peuvent attester de différents blocs en tant que chaîne canonique, augmentant ainsi le risque de ne pas parvenir à un consensus. Pour éviter cela, une solution simple pourrait être d'augmenter le coût des données d'appel. Par exemple, doubler le coût des données d'appel à 8 gaz par octet nul et 32 gaz par octet non nul pourrait réduire approximativement de moitié la taille maximale du bloc.

Cependant, cette approche pourrait nuire aux transactions normales des utilisateurs. Augmenter les coûts des données d'appel uniquement pour éviter le pire des scénarios pourrait entraîner une perte plus importante que le gain, étant donné que la taille moyenne des blocs n'est actuellement que de 125 Ko et ne pose pas de problèmes majeurs.

Quelle est la motivation de l'EIP-7623 ?

L'EIP-7623 diffère légèrement des autres propositions qui se contentent d'augmenter le coût des données d'appel. Au lieu d'un ajustement général du prix des données d'appel, l'EIP-7623 se concentre sur l'augmentation du coût du gaz spécifiquement pour les transactions qui semblent servir à des fins de disponibilité des données (DA).

Qu'est-ce que cela signifie ? Si le gaz utilisé dans une transaction est insuffisant par rapport à la taille totale des données chargées, elle est considérée comme une transaction à but DA et les frais pour les données d'appel sont nettement plus élevés. À l'inverse, si une transaction consomme suffisamment de gaz par rapport à la taille des données, elle est considérée comme une transaction non DA et est facturée au même prix qu'aujourd'hui.

Une analogie utile peut être établie entre les données d’appel dans Ethereum et les sacs en plastique dans le monde réel. Lorsque nous achetons des produits ou des produits d’épicerie, nous recevons souvent des sacs en plastique pour les transporter, généralement à très bas prix, voire gratuitement. Cependant, si les individus pouvaient acheter un nombre illimité de sacs en plastique, cela serait préjudiciable à l’environnement.

Une solution possible consiste à limiter l’utilisation des sacs en plastique aux clients qui achètent suffisamment de produits ou à facturer un prix plus élevé, par exemple 1 $ par sac. Cette approche est analogue à l’approche EIP-7623, qui fonctionne comme une forme de taxe Pigouvienne. Elle impose des coûts plus élevés aux transactions qui utilisent une grande quantité de données d’appel mais pas suffisamment de gaz, favorisant ainsi une utilisation plus efficace des ressources. En appliquant des coûts plus agressifs à ceux qui utilisent principalement les données d’appel pour la disponibilité des données plutôt qu’un mélange équilibré de données et d’exécution, le protocole vise à garantir une utilisation plus efficace et plus durable des ressources du réseau.

Pourquoi cibler les transactions DA sur Ethereum ?

Il n'y a rien de fondamentalement mauvais dans le fait que les transactions utilisent Ethereum pour la disponibilité des données. L'EIP-7623 ne décourage pas Ethereum de fonctionner comme une couche de disponibilité des données ; au contraire, il décourage l'utilisation de données d'appel pour stocker les données de transaction et encourage indirectement l'utilisation de blobs pour l'analyse des données. Cette proposition vise à séparer la couche d'exécution de la couche de disponibilité des données, permettant à chaque couche de gérer efficacement la demande et de mieux prévoir les cas extrêmes.

Ce faisant, l'EIP-7623 cherche à améliorer l'efficacité et la prévisibilité de la gestion des ressources d'Ethereum tout en limitant la surface de déni de service. Cette séparation garantit que chaque couche peut gérer ses fonctions spécifiques plus efficacement, contribuant ainsi à un réseau Ethereum plus robuste et plus évolutif.

Aperçu des spécifications EIP-7623

Le calcul actuel du gaz d'une transaction est le suivant :

Les 21,000 de la spécification ci-dessus correspondent au gaz minimum facturé pour toute transaction. De plus, STANDARD_TOKEN_COST tokens_in_calldata représente le gaz utilisé pour les données d'appel, ce que l'EIP-7623 tente principalement de corriger. Ici, tokens_in_calldata est une simple combinaison pondérée d'octets nuls et non nuls, qui est calculée par tokens_in_calldata = zero_bytes_in_calldata + 4 * nonzero_bytes_in_calldata .

STANDARD_TOKEN_COST est actuellement défini sur 4, donc le coût du gaz de zero_bytes_in_calldata est de 4 et nonzero_bytes_in_calldata est de 16.

evm_gas_used est le gaz utilisé pour l'exécution d'une transaction, couvrant principalement les interactions avec les contrats intelligents. Les transactions à des fins non DA ont généralement une composante evm_gas_used importante.

Lorsqu'une transaction crée un nouveau contrat, le terme isContractCreation devient 1, ce qui signifie que la création et le stockage du nouveau contrat nécessitent du gaz supplémentaire. Étant donné que la création de contrat n'est pas l'objectif ici, nous allons définir ce terme sur zéro.

L'EIP-7623 propose l'ajustement suivant au calcul du gaz total :

Dans le nouveau calcul, max(blue box, red box) compare le gaz calculé par la méthode actuelle (boîte bleue) avec les données d'appel TOTAL_COST_FLOOR_PER_TOKEN (boîte rouge). La boîte bleue est exactement la même que la méthode de calcul du gaz actuelle. La boîte rouge, qui est nouvelle dans EIP-7623, représente la valeur qui détermine si une transaction est destinée à des fins de DA. À compter du 1er janvier 2025, il est proposé que TOTAL_COST_FLOOR_PER_TOKEN soit de 10, ce qui est bien plus élevé que le STANDARD_TOKEN_COST de 4.

En d'autres termes, si une transaction ne dépense pas suffisamment evm_gas_used , la case rouge aura probablement une valeur plus élevée que la valeur de la case bleue, la marquant comme une transaction à des fins DA. Par conséquent, la transaction sera facturée au tarif TOTAL_COST_FLOOR_PER_TOKEN , payant effectivement un peu moins de 3 fois plus pour les données d'appel. Inversement, la plupart des transactions à usage général dépensent suffisamment evm_gas_used , donc max(blue box, red box) prendra par défaut la valeur de la case bleue, conservant la méthode de coût du gaz actuelle.

Quels types de transactions sont concernés par l’EIP-7623 ?

Pour déterminer quelles transactions sont affectées par EIP-7623, nous devons identifier la condition dans laquelle la case rouge (nouveau calcul de gaz) est supérieure à la case bleue (calcul de gaz actuel).

En ignorant le terme de création du contrat et en remplaçant les valeurs dans les paramètres, nous dérivons la condition suivante : les transactions entraîneront un coût de gaz plus élevé si le gaz consommé pour l'exécution de l'EVM est inférieur à 6 fois les jetons dans les données d'appel.

Pour rendre cela plus intuitif, divisons les deux côtés par 4 tokens_in_calldata . Rappelons que 6 tokens_in_calldata correspondent au gaz payé pour les données d'appel dans une transaction.

Cette équation finale indique que si le gaz utilisé pour l'exécution de l'EVM est inférieur à deux fois le gaz utilisé pour les données d'appel, la transaction entraînera des frais plus élevés pour les données d'appel.

De combien les coûts de Calldata augmenteront-ils après EIP-7623 ?

Supposons que le gaz minimum pour une transaction soit de 21 000, que le gaz utilisé pour l'exécution de l'EVM soit k et que le gaz utilisé pour les données d'appel soit kx. Le coût total de la transaction peut alors être exprimé comme suit :

Selon le calcul actuel (sans EIP-7623), le coût serait de 21 000+k+kx. Par conséquent, le taux d'augmentation avec EIP-7623 serait de :

Le taux d'augmentation en fonction de k est représenté ci-dessous :

Pour comprendre l’impact pratique, examinons les statistiques d’utilisation du gaz pour les méthodes de fonctionnement courantes, en nous concentrant sur celles qui sont familières à la plupart des utilisateurs.

Parmi les différentes fonctions d'échange dans les échanges décentralisés, swap(string, address, uint256, bytes) est la plus utilisée.

En moyenne, il utilise 5 152 pour les données d'appel et 175 742 pour EVM , ce qui représente une valeur 34 fois plus grande. La fonction transfer(address, uint256) , utilisée pour transférer les jetons ERC20, consomme environ 24 501 gaz pour l'exécution EVM, soit environ 40 fois plus que les 620 gaz utilisés pour les données d'appel.

Similaires à ces fonctions, la plupart des transactions quotidiennes des utilisateurs présentent une différence significative entre le gaz utilisé pour les données d'appel et l'exécution EVM, ce qui signifie qu'il est peu probable qu'elles soient affectées par EIP-7623.

L'analyse fournie par le chercheur Ethereum Toni Wahrstätter montre que si l'EIP-7623 est appliqué, 3,02 % des transactions Ethereum récentes seraient affectées. Son analyse identifie également les méthodes de fonction qui seront affectées et estime l'augmentation des coûts pour ces méthodes. Une analyse plus approfondie fournie par Wahrstätter montre que pour les transactions récentes sur Ethereum, 3,02 % des transactions sont affectées si l'EIP-7623 est appliqué.

Son site montre également quelles méthodes de fonction seront réellement affectées et dans quelle mesure le prix de ces méthodes augmenterait.

Parmi les fonctions impactées par l'EIP-7623, la plus fréquemment utilisée est addSequencerL2BatchFromOrigin() , couramment utilisée pour séquencer les transactions de cumul sur Ethereum. Une autre méthode affectée est commitBatches() , fréquemment utilisée dans les transactions de cumul. Ces deux fonctions devraient connaître les augmentations de coûts les plus importantes, avec une augmentation estimée à 150 % des coûts totaux du gaz lors de l'utilisation de ces méthodes.

Toutefois, les rollups peuvent utiliser des blobs pour la publication des données, et de nombreux rollups, tels qu'Arbitrum One et Base, le font déjà . Par conséquent, les rollups qui utilisent des blobs pour la publication des données ne risquent pas d'être fortement affectés par l'augmentation des coûts imposée par la directive EIP-7623.

Analyse de l'impact de l'EIP-7623 sur la taille des blocs

L'EIP-7623 augmente le coût du gaz pour les transactions qui utilisent de grandes quantités de données d'appel. Cela signifie que les attaques de spam, qui s'appuient fortement sur les données d'appel, nécessiteraient environ trois fois plus de gaz, réduisant ainsi la taille maximale du bloc de 2,54 Mo à environ 0,72 Mo. Par conséquent, le réseau Ethereum serait mieux équipé pour gérer les pires scénarios où de gros blocs se propagent en continu.

La réduction de la taille maximale possible des blocs crée une opportunité d'augmenter le nombre de blobs inclus par bloc. Actuellement, le nombre maximal de blobs est de 6, chacun d'une taille de 128 Ko. Si la norme EIP-7623 est adoptée et que la même taille maximale des blocs est maintenue, il pourrait être possible d'augmenter le nombre maximal de blobs à environ 18, ce qui signifie une augmentation de 3x du nombre maximal de TPS (transactions par seconde) des rollups.

Ce calcul implique une certaine simplification excessive, car les méthodes de propagation des blobs et des blocs diffèrent. Cependant, le principal avantage est la séparation accrue entre les couches d'exécution et de disponibilité des données. Étant donné que le gaz de blob et le gaz d'exécution ont des marchés de frais distincts, les perturbations sur l'un des marchés n'auront pas d'impact direct sur l'autre.

Cette séparation simplifie l’efficacité du capital car il devient plus facile de contrôler les ressources cibles et maximales que le réseau Ethereum peut gérer au sein d’un seul bloc.

Quelles sont les autres considérations liées à la mise en œuvre de l’EIP-7623 ?

Bien que la norme EIP-7623 offre des avantages significatifs, elle pourrait potentiellement avoir un impact sur les petits cumuls en nécessitant l'utilisation de blobs au lieu de données d'appel. Pour les cumuls à faible demande, la taille importante du blob de 128 Ko peut les obliger à attendre plus longtemps avant de pouvoir remplir le blob complet. Cette situation augmente le besoin de protocoles de partage de blob , permettant à plusieurs cumuls de partager le grand espace blob pour une meilleure rentabilité.

Bien que les frais de base des blobs soient actuellement très bas (ce qui fait des blobs un espace DA peu coûteux), une augmentation soudaine de la demande pourrait représenter une charge importante pour ces rollups. Sans une augmentation simultanée du nombre de blobs par bloc, l'EIP-7623 pourrait rendre les rollups soumettant des transactions DA plus compétitifs, car la capacité totale de DA diminue globalement. Il est nécessaire d'évaluer si le nombre de blobs doit être augmenté simultanément pour s'adapter à ce changement.

Une autre considération consiste à déterminer les critères du seuil à partir duquel les transactions doivent être affectées par cette mise à jour. Il existe des compromis entre la taille des blocs et l'expérience utilisateur. Par exemple, définir le seuil de manière trop agressive pourrait réduire considérablement la taille maximale des blocs, mais de nombreuses transactions pourraient devoir payer plus de gaz pour les données d'appel.

Bien que le changement de taille maximale des blocs soit explicite et frappant, il est difficile d’estimer et de quantifier l’impact que pourrait avoir sur Ethereum l’augmentation des coûts de gaz pour les transactions à des fins d’accès direct aux données. Ce seuil ne peut être fixé que socialement.

De plus, les critères dépendent fortement d'autres paramètres définis par les opérations EVM ou la limite de gaz. Par exemple, si Ethereum devait augmenter la limite de gaz de bloc à 300 millions à l'avenir, le seuil de l'EIP-7623 devrait également être modifié pour maintenir la taille de bloc maximale.

Conclusion

L'EIP-7623 est une proposition d'amélioration d'Ethereum qui vise à réduire la taille maximale des blocs en ajustant le coût des données d'appel, en ciblant spécifiquement les transactions à des fins d'analyse de données. Cet ajustement pourrait potentiellement augmenter le coût des transactions DA non blob jusqu'à 300 %, tandis que la plupart des transactions quotidiennes des utilisateurs ne sont pas affectées.

Tout au long de cet article, nous avons exploré la motivation derrière la proposition, ses implications, les types de transactions concernées et les préoccupations potentielles qui peuvent survenir. J'espère que cet article vous aidera à mieux comprendre cette récente proposition et vous fournira des informations détaillées sur son contenu. Si vous êtes intéressé et que vous souhaitez en savoir plus, vous pouvez suivre l'analyse et l'explication de Toni Wahrstätter et participer à la discussion ouverte sur le forum Ethereum Magicians.