Prysm a indiqué qu’un bug introduit sur un testnet un mois avant la mise à jour Fusaka d’Ethereum était à l’origine d’un problème de validation des nœuds ayant touché son client plus tôt ce mois-ci.
Le développeur Ethereum Terence Tsao a publié dimanche un rapport post-mortem détaillant l’incident survenu sur le réseau principal lors du déploiement de Fusaka, qui a impacté Prysm le 4 décembre.
Selon ce rapport, les nœuds Prysm ont subi une « épuisement des ressources » lors du traitement d’attestations provenant de nœuds désynchronisés. Cette situation a forcé Prysm à rejouer des blocs d’epochs passés et à recalculer des transitions d’état coûteuses, ce qui a fortement dégradé les performances en raison d’une charge excessive.
Le post-mortem indique que le bug était présent sur les réseaux de test depuis un mois avant l’incident, mais qu’il ne s’était jamais déclenché jusque-là.
« Le bug a été introduit dans la pull request Prysm PR 15965 et déployé sur les testnets un mois avant l’incident, sans que le déclencheur ne se produise », précise le rapport.
Les testnets sont conçus pour détecter les bugs, mais ils ne constituent pas une méthode infaillible.
En mai 2023 — un mois après le hard fork Shanghai — les développeurs d’Ethereum avaient déjà été confrontés à un incident majeur, lorsque le réseau avait temporairement perdu la finalité des transactions pendant environ 25 minutes, puis à nouveau pendant plus d’une heure le lendemain, avant de se rétablir de lui-même.
Prysm corrigé
Au lieu d’utiliser l’état courant (head state), Prysm a régénéré des états antérieurs depuis zéro, générant une charge de calcul massive.
Pendant plus de 42 epochs, le réseau a enregistré un taux de missed slots de 18,5 %, la participation chutant à 75 %, tandis que les validateurs ont perdu environ 382 ether (ETH) en récompenses d’attestation.
Les opérateurs de nœuds ont été invités à déployer une solution temporaire, le temps que les développeurs finalisent un correctif pour les clients Prysm.
La diversité des clients a limité les dégâts
D’après les développeurs, l’incident aurait pu être bien plus grave s’il avait affecté Lighthouse, le client de consensus dominant d’Ethereum.
Prysm, développé par Offchain Labs, est le deuxième client Ethereum le plus utilisé, avec une part de 17,6 %, selon les données de ClientDiversity.
« La diversité des clients a évité un impact perceptible pour les utilisateurs d’Ethereum. Un client représentant plus d’un tiers du réseau aurait entraîné une perte temporaire de finalité et davantage de blocs manqués », expliquent les développeurs.
L’incident souligne toutefois que Lighthouse se rapproche dangereusement du seuil des deux tiers, au-delà duquel un bug sur un seul client pourrait permettre la finalisation d’une chaîne invalide.
Lighthouse affiche actuellement une part de marché de 52,6 %, contre environ 56 % au moment de l’incident.
