Deux développeurs d'Ethereum, Leo Glisic et Giulio Rebuffo, ont soumis dimanche des propositions concurrentes décrivant des stratégies distinctes pour protéger les applications déjà déployées sur le réseau. Toutes deux abordent les conséquences potentielles des Ethereum Improvement Proposals EIP-8037 et EIP-8038, qui augmenteraient le gaz requis pour certaines opérations de smart contracts. Le différend est devenu un enjeu majeur pour Glamsterdam, les développeurs évaluant si les changements de tarification proposés peuvent être introduits sans interférer avec les contrats conçus autour du barème de gaz actuel d'Ethereum.

Les changements de gaz de Glamsterdam suscitent des inquiétudes de compatibilité

Au cœur de la controverse se trouvent EIP-8037 et EIP-8038, deux propositions incluses dans la mise à niveau Glamsterdam prévue, qui modifieraient le coût de création de contrats et d'accès aux données stockées sur la blockchain. Le gaz est l'unité qu'Ethereum utilise pour mesurer les ressources de calcul nécessaires à l'exécution des transactions et des instructions des smart contracts, et les modifications de la tarification du gaz peuvent altérer le comportement des applications, en particulier lorsque les développeurs ont programmé des contrats autour de limites d'exécution spécifiques.

Les mises à niveau d'Ethereum comme Glamsterdam regroupent plusieurs EIP en un changement coordonné unique des règles du réseau, et les propositions passent généralement par une revue des développeurs cœur, une implémentation par les clients et des tests sur testnet avant toute décision d'activation. Le différend actuel se déroule dans ce processus : les objections émergent alors que Glamsterdam est encore en évaluation sur testnet, avant tout déploiement sur la blockchain principale.

Selon EIP-8037, les frais de gaz de base pour créer un smart contract passeraient de 32 000 à 183 600 de gaz, des coûts supplémentaires liés au stockage du code et à l'exécution s'appliquant séparément. Cette augmentation a suscité des inquiétudes car certaines applications Ethereum existantes ont été développées en supposant que certaines opérations continueraient à consommer la même quantité de gaz.

Certains contrats allouent une quantité fixe de gaz lorsqu'ils interagissent avec d'autres applications. Si le coût de ces interactions dépasse le montant alloué, les opérations pourraient échouer. Les enjeux sont particulièrement élevés pour les smart contracts qui ne peuvent pas être modifiés après déploiement, car ces applications peuvent ne disposer d'aucun mécanisme simple pour s'adapter à un barème de gaz révisé.

Des chercheurs en sécurité alertent sur des perturbations généralisées des contrats

Ces inquiétudes ont déjà affecté le calendrier de tests de Glamsterdam. Bien que la mise à niveau ait été déployée sur un réseau de test Ethereum, un deuxième exercice de test prévu le 26 octobre a été reporté à la suite d'avertissements de chercheurs en sécurité. Les réseaux de test Ethereum permettent aux développeurs d'évaluer les changements de protocole avant qu'ils n'atteignent la blockchain principale, où les applications et transactions impliquent des actifs réels. Les barèmes de gaz ont également été révisés lors de précédentes mises à niveau d'Ethereum, c'est pourquoi les propositions de repricing sont systématiquement vérifiées par rapport aux contrats écrits selon d'anciennes hypothèses de coût.

Le chercheur en sécurité pcaversaccio a publiquement critiqué les ajustements de gaz proposés, estimant que Glamsterdam ne devrait pas avancer sous sa forme actuelle.

« imho Glamsterdam should not be shipped in its current form, period », a écrit pcaversaccio sur X.

Le chercheur a indiqué que ces inquiétudes avaient été transmises aux développeurs cœur d'Ethereux deux semaines plus tôt.

Le développeur pseudonyme banteg a également remis en question la portée des évaluations de compatibilité existantes, pointant une liste d'environ 200 000 contrats potentiellement affectés dans le dépôt ethereum/repricing-impact. Selon banteg, les limites méthodologiques de l'évaluation pourraient signifier que nettement plus de contrats sont affectés que ne l'indique la liste existante. Le développeur a en outre averti que les changements proposés pourraient interférer avec le déploiement et le fonctionnement de plusieurs protocoles Ethereum de premier plan, plutôt que d'affecter uniquement des applications moins utilisées.

Ces avertissements ont intensifié l'examen de la manière dont les développeurs d'Ethereum comptent mettre en œuvre la refonte des tarifs de gaz tout en préservant la fonctionnalité des contrats déjà en fonctionnement sur le réseau.

EIP-8488 propose des règles de gaz distinctes pour les contrats existants et nouveaux

La proposition de Glisic, identifiée comme EIP-8488, introduit un mécanisme de compatibilité qui distinguerait les smart contracts déployés avant la mise à niveau de ceux créés ensuite. Les contrats existants continueraient de fonctionner selon les règles de tarification du gaz actuelles d'Ethereum, tandis que les contrats nouvellement déployés utiliseraient un jeu d'instructions révisé reflétant les coûts de gaz accrus introduits par EIP-8037 et EIP-8038.

La proposal diviserait en pratique le jeu d'instructions d'Ethereum en deux versions, permettant aux applications plus anciennes de conserver leurs coûts d'exécution établis tout en exigeant des nouvelles applications qu'elles suivent la structure tarifaire actualisée.

« Existing contracts keep the legacy schedule », indique le projet d'EIP-8488.

Les nouveaux contrats seraient tenus d'utiliser les opcodes V2 associés au barème de gaz révisé. Cette approche vise à réduire les risques de compatibilité pour les applications qui ne peuvent pas être mises à niveau, tout en permettant à Ethereum d'introduire ses changements de tarification du gaz prévus pour les futurs déploiements.

Une proposition alternative introduit une double comptabilisation du gaz

Rebuffo a proposé un mécanisme différent qui appliquerait le nouveau barème de tarification du gaz à la facturation des transactions tout en préservant le comportement d'exécution existant des anciens smart contracts. Plutôt que de maintenir des jeux d'instructions séparés pour les anciennes et nouvelles applications, ce design introduirait deux mécanismes de comptabilisation du gaz au sein de chaque transaction. Un compteur suivrait l'exécution des contrats selon les règles de gaz existantes, tandis qu'un second calculerait les frais de transaction selon le barème tarifaire actualisé.

Dans cette structure, le nouveau barème déterminerait les frais de transaction, mais les applications plus anciennes continueraient de s'exécuter selon les hypothèses établies par les anciennes règles de gaz. La proposition vise à séparer le calcul des coûts de transaction des conditions d'exécution dont dépendent les smart contracts existants.

Le projet reconnaît toutefois que le design reste non testé au niveau de l'implémentation.

« no execution-client implementation or consensus tests have been run for this design », précise la proposition.

Les développeurs face aux décisions sur les changements de gaz de Glamsterdam

Les propositions concurrentes illustrent différentes approches pour résoudre le même problème de compatibilité. L'EIP-8488 de Glisic préserverait la tarification du gaz existante pour les contrats déjà déployés tout en introduisant le barème révisé via de nouvelles instructions. L'alternative de Rebuffo appliquerait une facturation de transaction actualisée tout en conservant le comportement d'exécution historique. Les deux approches cherchent à empêcher que la refonte planifiée des tarifs de gaz ne perturbe les applications qui reposent sur les coûts d'exécution actuels d'Ethereum.

La question a attiré l'attention car les contrats concernés peuvent inclure des protocoles établis qui ne peuvent pas facilement modifier leur code déployé. Les tests ayant déjà été retardés suite aux avertissements de sécurité, les propositions apportent des solutions techniques potentielles pour les développeurs évaluant les risques de compatibilité de Glamsterdam.

Les jalons qui feront avancer le débat sont concrets : une nouvelle session de testnet menée avec un mécanisme de compatibilité en place, et, si l'un des projets doit progresser, des implémentations par les clients d'exécution et des résultats de tests de consensus pour l'évaluer. D'ici là, la question de la compatibilité reste ouverte tandis que Glamsterdam poursuit son cycle de développement.

Les informations disponibles ne permettent pas d'établir si l'une ou l'autre proposition sera adoptée. Le design de Rebuffo reste également sans implémentation par les clients d'exécution ni résultats de tests de consensus, sa faisabilité technique devant faire l'objet d'une évaluation plus approfondie.

Source : CoinDesk

Première publication par : Hokanews