La mise à niveau Glamsterdam d'Ethereum pourrait perturber les contrats intelligents existants

Propositions Concurrentes pour la Mise à Niveau Glamsterdam

Les développeurs d'Ethereum ont introduit deux propositions concurrentes pour éviter que la prochaine mise à niveau Glamsterdam ne perturbe les contrats intelligents existants, alors que les inquiétudes grandissent concernant les modifications des règles de tarification du gaz du réseau. Les développeurs Leo Glisic et Giulio Rebuffo ont soumis des propositions distinctes le dimanche 8 novembre, offrant différentes manières d'introduire les nouvelles charges de gaz sans affecter les applications déjà en fonctionnement sur Ethereum. Ces propositions font suite à des avertissements de sécurité qui ont contraint les développeurs à reporter certaines parties du calendrier de test de Glamsterdam.

Impact des Modifications de Tarification du Gaz

Certaines contrats intelligents existants reposent sur des coûts de gaz fixes, et modifier ces coûts pourrait entraîner des échecs de transactions ou interférer avec des applications qui ne peuvent pas être mises à jour après leur déploiement. La proposition de Glisic, EIP-8488, introduirait un ensemble distinct d'instructions pour les contrats intelligents nouvellement déployés tout en permettant aux anciens contrats de continuer à fonctionner selon leurs règles de gaz existantes. Selon cette proposition, les nouveaux contrats utiliseraient des opcodes V2 qui suivent la tarification révisée introduite par EIP-8037 et EIP-8038. Les contrats existants conserveraient la structure de tarification originale, permettant aux développeurs d'introduire les changements sans forcer les anciennes applications à s'adapter.

Rebuffo a suggéré une solution différente dans un projet distinct, qui introduirait deux systèmes de comptabilité de gaz au sein de chaque transaction. L'un calculerait combien de gaz un contrat consomme selon les règles précédentes, préservant ainsi les conditions qu'il attend lors de l'exécution. Le second calculerait les frais de transaction réels en utilisant le calendrier de tarification révisé. Sa proposition reconnaît qu'aucune mise en œuvre de client d'exécution ou test de consensus n'a encore été complétée pour ce design. Aucune des propositions n'a été approuvée pour inclusion dans Glamsterdam.

Préoccupations de Compatibilité

Les préoccupations de compatibilité découlent des EIP-8037 et EIP-8038, qui modifient la manière dont Ethereum facture la création et l'accès à l'état de la blockchain. L'EIP-8037 augmenterait la charge de gaz de base pour la création d'un contrat intelligent de 32 000 à 183 600, excluant les coûts d'exécution et de stockage de code supplémentaires. Bien que ces changements soient destinés à tenir compte des ressources consommées par l'activité de la blockchain, les chercheurs en sécurité ont averti que les applications existantes pourraient ne pas être préparées aux charges révisées.

Comme l'a précédemment rapporté crypto.news, la société de sécurité ChainSecurity a identifié huit hypothèses utilisées par les contrats intelligents existants qui pourraient devenir invalides sous les règles de gaz proposées. Certains contrats réservent un montant fixe de gaz pour les appels externes, tandis que d'autres dépendent d'un comportement spécifique lorsque les transactions échouent. Un changement inattendu dans la consommation de gaz pourrait interférer avec ces opérations.

Le développeur pseudonyme banteg a averti sur X qu'une analyse existante avait déjà identifié environ 200 000 contrats potentiellement affectés, tandis que des problèmes méthodologiques pourraient signifier que le nombre réel est plus élevé.

Réactions de la Communauté

Le développeur a déclaré que les préoccupations s'étendent au déploiement et à l'exploitation de plusieurs protocoles importants, plutôt que d'être limitées à des erreurs de codage isolées. Les changements proposés ont suscité des critiques de la part des développeurs et des figures de l'industrie DeFi qui estiment qu'Ethereum devrait résoudre les préoccupations de compatibilité avant de procéder. Le fondateur de Curve Finance, Michael Egorov, a averti sur X que Glamsterdam pourrait causer de graves problèmes si les développeurs poursuivent sans aborder les risques.

"Cher – s'il vous plaît, ne cassez pas la chaîne. Il semble que Glamsterdam dans sa forme actuelle entraînerait un autre hard fork d'urgence, avec beaucoup de drame,"

a écrit Egorov.

Le membre de la communauté Ethereum et investisseur Ryan Berckmans a initialement soutenu l'avancement de la mise à niveau, arguant qu'Ethereum ne pouvait pas garantir une tarification du gaz inchangée pour chaque application existante. Berckmans a ensuite inversé sa position après avoir examiné les préoccupations de compatibilité.

"Nous ne devrions pas (clairement, maintenant) continuer vers l'activation de Glam dès que possible. J'avais tort de le dire,"

a-t-il écrit sur X.

Le chercheur en sécurité pcaversaccio a pris une position plus ferme, arguant que Glamsterdam ne devrait pas être déployé dans sa forme actuelle.

"Imho, Glamsterdam ne devrait pas être expédié dans sa forme actuelle, point final,"

a écrit le chercheur, faisant référence aux changements de gaz qui avaient apparemment été signalés aux développeurs principaux d'Ethereum des semaines plus tôt.

Report de l'Activation de Hoodi

Les développeurs d'Ethereum ont reporté l'activation de Hoodi du 26 octobre après que des préoccupations aient émergé concernant la manière dont les règles de gaz révisées pourraient affecter les contrats déjà déployés sur le mainnet. Le report couvrait les changements de couche d'exécution d'Amsterdam, les changements de consensus de Gloas et une augmentation prévue de la limite de gaz de Hoodi à 200 millions. Dans une déclaration du 6 novembre, le développeur de la Fondation Ethereum, Marius van der Wijden, a déclaré que l'organisation travaillait avec ChainSecurity et Dedaub pour examiner les applications affectées et recueillir des retours d'expérience des développeurs. Un test privé ultérieur de Glamsterdam avait été discuté de manière provisoire pour le 16 au 20 novembre au plus tôt lors d'une réunion de développeurs du 29 octobre. Le calendrier avait été établi avant la soumission des deux propositions concurrentes.