EIP-7706 : Vitalik Buterin propose la création d’un nouveau type de gas pour les calldatas
Vitalik Buterin, le cofondateur d’Ethereum, est encore très impliqué dans le développement du protocole. Que ce soit concernant la philosophie du projet ou via des propositions d’évolution par le biais d’EIP. Sa dernière proposition en date n’est autre que l’EIP-7706, qui propose la création d’un nouveau type de gas sur Ethereum.
EIP-7706 : la séparation du gas des calldatas
Le 13 mai, Vitalik Buterin a publié une EIP (Ethereum Improvement Proposal) pour Ethereum. Pour rappel, les EIP sont des propositions d’évolution pour le réseau. Si acceptée par les développeurs, l’EIP sera ajoutée au protocole dans l’un des hard fork à venir.
Ainsi, l’EIP-7706 intitulée « Separate gas type for calldata » propose, comme son nom l’indique, de séparer le type de gas pour les calldata.
La structure d’une transaction sur Ethereum
Avant d’entrer dans le vif du sujet, il faut comprendre la structure d’une transaction Ethereum. Ainsi, une transaction sur Ethereum est composée de plusieurs champs :
- Nonce : l’identifiant de la transaction qui permet d’assurer que la transaction est unique ;
- Max Priority Fee Per Gas (pourboire): Montant maximal en wei que l’expéditeur est prêt à payer par unité de gaz ;
- Max Fee Per Gas: Le prix maximum en wei que l’expéditeur est prêt à payer par unité de gaz, englobant le frais de base plus le pourboire ;
- Gas Limit: La quantité maximale de gaz que l’expéditeur est prêt à utiliser pour la transaction ;
- To: Adresse du destinataire ou du smart contract avec lequel interagir ;
- Value: La quantité d’Ether (en wei) à transférer de l’expéditeur au destinataire ;
- Data (Calldata): Contiens les instructions pour le contrat intelligent, y compris la fonction à exécuter et les arguments nécessaires ;
- Chain ID: Identifiant unique de la chaîne sur laquelle la transaction doit être traitée ;
- v, r, s: Composants de la signature ECDSA qui vérifient que l’expéditeur de la transaction est bien qui il prétend être et qu’il a autorisé la transaction.
Ainsi, l’EIP proposé par Vitalik Buterin affecterait le champ data, fréquemment appelé calldata qui contient l’ensemble des instructions pour les smart contracts.
Actuellement, les transactions sur Ethereum impliquent deux types de gas :
- Un gas pour l’exécution, qui permet de couvrir les calculs nécessaires pour traiter une transaction. Par exemple, l’exécution d’une fonction de smart contract ;
- Un gas pour le stockage, qui permet de couvrir le coût du stockage des données. Par exemple, le coût de stockage des blobs.
Par conséquent, l’EIP-7706 impliquerait l’introduction d’un troisième type de gas. Celui-ci serait destiné aux données que transporte la transaction, à savoir les calldatas.
Vers un nouveau type de gas
Avec l’EIP-7706, Buterin souhaite introduire un nouveau type de gas spécifique aux calldatas. En pratique, cela vise à séparer l’utilisation du gas au sein des transactions pour qu’il soit spécifique aux différentes composantes.
« Ajout d’un nouveau type de gaz pour la transaction calldata. Ajouter un nouveau type de transaction qui fournit max_basefee et priority_fee en tant que vecteur, en fournissant des valeurs pour execution gas, blob gas et calldata gas. Modifier l’ajustement des frais de base afin d’utiliser le même mécanisme pour les trois types de gaz. »
Par conséquent, l’EIP-7706 introduirait un marché de frais séparé pour le calldata. Cela réduirait considérablement la taille maximale théorique du calldata dans un bloc, tout en rendant le calldata nettement moins cher en moyenne.
Cette approche est similaire à celle utilisée pour les blobs, qui ont été introduits via le hard fork Cancun Deneb.
Selon Buterin, cela permettrait une optimisation des coûts en gas en fonction de l’utilisation réelle. Ainsi, chaque transaction aurait un coût en gas plus précis, en fonction de si elle vise à transporter des données via les calldatas, où si elle fait office de stockage via les blobs.
Toutefois, cette proposition est encore embryonnaire. Il est peu probable qu’elle soit ajoutée à la liste des EIP qui seront déployés via le prochain hard fork Prague Electra. Pour l’instant, 4 EIP ont été approuvées pour ce hard fork, et elles concernent principalement le processus de validation et les validateurs du réseau.