Échec de la mise à jour maladise d’Ethereum dans le réseau de test

Le filet d’essai d’Ethereum Holesky Le réseau n’a pas atteint l’état de “but”dans lequel les transactions sont consolidées comme immuables et irréversibles dans le réseau.

Au moment de cet article, Holesky porte Au moins sept heures inactives et sans blocs de traitementcomme on le voit dans l’image suivante:

L’expérience dans ce réseau de test Ethereum renforce l’importance de ces phases expérimentales, Permettre les échecs d’être détectés et corrigés sans compromettre la stabilité de la chaîne principale.

Quelle était la Falla dans le réseau de test Ethereum?

Georgios Konstantopoulos, CTO de Paradigm, a expliqué que l’échec provenait d’une erreur au sein de certains clients de la couche d’exécution (Couche d’exécution, El). Selon leurs déclarations, ces clients Ils ont omis d’inclure la bonne direction du contrat de dépôtun composant qui prend la pertinence avec Péin en raison de son impact sur le calcul du hachage des applications.

Ce hachage est essentiel pour traiter les opérations telles que les dépôts et les retraits, les fonctions que la mise à jour transfère de la couche consensus (CL) à la couche d’exécution.

Konstantopoulos a déclaré que, bien que l’erreur soit simple à détecter, affecté les performances de certains clients à Holesky. Cependant, il a souligné que des équipes comme Reth et Eregon, deux implémentations des clients, fonctionnaient correctement pendant le test.

Ethereum a une structure composée de différentes couches, en plus du: Couche de consensus (Couche consensus), Couche d’application (Couche d’application), Couche de disponibilité des données (Couche de disponibilité des données), Couche de réseau (Cap Couche d’infrastructure (Couche d’infrastructure).

Cette architecture multicapa permet de distribuer les fonctions clés du réseau dans différentes strates, optimisant ses performances générales sans compromettre son intégrité.

Les clients doivent gérer le contrat de dépôt

Dans une réponse qui complète cette explication, Timbeiko.eth, un développeur éminent au sein de l’écosystème Ethereum, s’est approfondi dans le contexte technique du problème.

Avant Pein, les clients d’exécution n’avaient pas besoin de reconnaître la pertinence particulière du contrat de dépôt, car la couche consensus était responsable de la lire directement. Cela a changé avec Sirty: maintenant, les dépôts peuvent être initiés par la couche d’exécution sans le retard des blocs 2048 mis en œuvre dans l’ère pré-sans atténuation des réorganisations dans le test de travail (POW).

En conséquence, le Les clients doivent gérer directement le contrat de dépôtqui exige que votre adresse soit correctement configurée.

La décision à Holesky, selon Timbeiko.eth, a été déclenchée parce que les adresses du contrat de dépôt dans ce réseau de test, ainsi qu’à Sepolia, diffèrent de ceux utilisés dans le réseau principal d’Ethereum. Certains clients n’ont pas mis à jour cette adresse pour refléter les spécificités de Holesky, ce qui a provoqué des incohérences dans les vérifications du hachage et, par conséquent, a empêché le réseau d’atteindre l’objectif.

Bien que Timbeiko.eth ait admis de ne pas savoir pourquoi les adresses sont différentes entre les réseaux, il a souligné que ce type de divergences fait partie des défis qui surviennent lorsqu’ils essaient des mises à jour dans des environnements contrôlés.

L’écosystème Ethereum attend Sirty

La mise à jour de la PECTRA introduit des changements importants, comme dans le stimulation, dans l’interaction de l’EOA (comptes contrôlés à l’extérieur) et des comptes de contrat intelligents et la possibilité de activer les dépôts directement à partir de la couche d’exécutionen dehors d’autres améliorations. Cependant, sa mise en œuvre nécessite que tous les clients soient alignés sur de nouvelles spécifications, ce qui ne s’est pas produit uniformément à cette occasion.

La différence dans les directions du contrat de dépôt entre le réseau principal et les TestNets, combinée à une configuration inadéquate chez certains clients, a présenté une vulnérabilité qui est actuellement abordée.

La prochaine étape pour les développeurs sera d’ajuster ces erreurs avant le test suivant prévue à Sepolia, prévue le 5 mars 2025, et plus tard sur le réseau principal d’Ethereum, le 8 avril.