Prysm a révélé qu’un bug introduit dans un testnet un mois avant la mise à niveau Fusaka d’Ethereum était la cause d’un problème de validation d’un nœud Ethereum qui a affecté son client plus tôt ce mois-ci.
Le développeur Ethereum Terence Tsao a publié un post-mortem dimanche détaillant l’incident Fusaka sur le réseau principal Prysm qui a impacté le réseau le 4 décembre.
Les nœuds Prysm ont rencontré une « saturation des ressources » lors du traitement des attestations provenant de nœuds hors sync, indique le rapport. Cela a conduit Prysm à rejouer des blocs d’époques passées et à recalculer des transitions d’état coûteuses, ce qui a eu un impact significatif sur la performance en raison de la charge de travail excessive.
Le post-mortem a révélé que le bug était présent sur les testnets depuis un mois avant l’incident, mais n’avait pas été déclenché.
« Le bug a été introduit dans Prysm PR 15965 et déployé sur les testnets un mois avant l’incident sans que le déclencheur ne se produise. »
Les testnets sont conçus pour identifier les bugs, mais ils ne sont pas une méthode infaillible.
En mai 2023 — un mois après la hard fork Shanghai — les développeurs Ethereum ont été pris de panique lorsque le réseau a temporairement perdu la finalité des transactions pendant environ 25 minutes, puis à nouveau pendant plus d’une heure le lendemain, avant que la blockchain ne se rétablisse d’elle-même.
Au lieu d’utiliser l’état actuel, Prysm a régénéré des états antérieurs à partir de zéro, créant une charge computationnelle massive.
Pendant plus de 42 époques, le réseau a enregistré un taux de slots manqués de 18,5 %, avec une participation tombée à 75 %, tandis que les validateurs ont perdu environ 382 Ether (ETH) en récompenses d’attestation, indique le rapport.
En relation : Vitalik Buterin affirme qu’Ethereum peut gérer une perte temporaire de la finalité
Les opérateurs de nœuds ont été instruits de déployer une solution temporaire pendant que les développeurs travaillaient sur une mise à jour pour les clients Prysm.
L’incident aurait pu être beaucoup plus grave s’il avait touché le client de consensus dominant d’Ethereum, Lighthouse, ont déclaré les développeurs.
Prysm d’Offchain Labs est le deuxième client Ethereum en taille avec une part de 17,6 %, selon ClientDiversity.
« La diversité des clients a empêché un impact notable sur les utilisateurs d’Ethereum. Un client avec plus d’un tiers du réseau aurait causé une perte temporaire de la finalité et plus de blocs manqués. »
Cependant, l’incident a mis en évidence que Lighthouse est dangereusement proche du seuil des deux tiers, où un seul bug client pourrait finaliser une chaîne invalide.
Lighthouse détient actuellement une part de client de 52,6 %, en baisse par rapport à environ 56 % au moment de l’incident.
Les développeurs Ethereum militent pour une plus grande diversité des clients. Source : ClientDiversity
Magazine : Grandes questions : Bitcoin survivrait-il à une panne de courant de 10 ans ?
Articles similaires
La stratégie prudente de prêt en ETH de Spark s’avère justifiée alors qu’Aave fait face à une crise de liquidité sur plusieurs chaînes
Elon Musk : X lance des tags intelligents, en 3 jours pour dynamiser 1 milliard de dollars de volume de transactions dans le monde entier
Baleine d’ETH avec 44,61 M$ de profits en 2 mois ouvre une position longue de 4 000 ETH sur Hyperliquid avec un levier de 15x
Le domaine eth.limo a été détourné, EasyDNS reconnaît la première attaque d’ingénierie sociale en 28 ans
Vitalik confirme un discours à Hong Kong, l’IA d’Ethereum et les applications écosystème ZK au cœur des préoccupations
Une baleine liée à Matrixport ouvre une position longue de $100M ETH avec 44 000 ETH