Une erreur de client Ethereum vieille d'un mois est responsable de la panne de Prysm

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.

Prysm a été corrigé

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.

La diversité des clients a sauvé la mise

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 ?

• #Ethereum
• #Logiciel
• #Nœuds
• #Validateur Ajouter une réaction