Ethereum 2.0 toujours paralysé – Après les bugs en cascade, le testnet Medalla à la peine

Plus de détails sur Medalla – Le dernier testnet en date d’Ethereum 2.0, Medalla, a été déployé le 4 août. Après 10 jours de bon fonctionnement, un bug sévère est apparu sur la beacon chain. Un dysfonctionnement des nœuds a engendré une multitude de forks difficiles à contrôler.

Retour sur cet événement grâce aux éclaircissements de Ben Edgington (Consensys).

Notre avis sur Ethereum (ETH) »

Retour vers le futur sur la beacon chain

L’alerte a été lancée lorsque, dans la nuit du vendredi 14 août, environ 80 % des nœuds validateurs du réseau de test ont disparu soudainement.

Tous ces nœuds utilisaient le logiciel client Prysm (le logiciel client le plus utilisé sur les testnets d’Ethereum 2.0). Le problème est survenu à cause de la synchronisation temporelle de ces nœuds Prysm.

En effet, ces derniers utilisent le système de certificat de Cloudflare (Roughtime) comme horloge. Pour des raisons peu claires, Roughtime s’est mis à avancer de 4 h pendant un peu plus d’1 h. De ce fait, les nœuds Prysm ont horodaté leurs blocs avec un timestamp qui n’existait pas encore.

Cela n’a pas posé de problème au début, car les nœuds restants rejetaient les « blocs du futur ». Par contre, quelques heures après l’incident, les choses se sont compliquées.

Ces blocs défaillants ont commencé à être acceptés par le réseau. De plus, les nœuds Prysm qui se reconnectaient ont été à nouveau rejetés à cause des injonctions contradictoires qu’ils renvoyaient aux autres validateurs. Le mécanisme de protection dédié du PoS d’ethereum (le slashing) a commencé à faire son effet.

Cela a eu de fâcheuses conséquences. La beacon chain s’est retrouvée divisée en une multitude de forks. La pagaille est devenue telle que les nœuds n’arrivaient même plus à analyser les données.

Après des jours de travail acharné de la part des développeurs, la beacon chain commence à retrouver un fonctionnement normal.

Les leçons à tirer de ce bug d’Ethereum 2.0

Ben Edgington nous rappelle que, malgré ces désagréments, il n’y a pas eu de problème de consensus entre les différents logiciels clients d’Ethereum 2.0.

La synchronisation temporelle des différents clients devra faire l’objet d’une attention plus poussée. C’est un sujet qui a été largement étudié, notamment par Alex Vaslov (Consensys).

Il est aussi important d’avoir une grande diversité de logiciels clients sur Ethereum 2.0. Si les nœuds utilisant l’un d’entre eux ont un problème, une large proportion du réseau pourra faire le travail à leur place. De même, il faut un système dynamique pour que les nœuds validateurs puissent passer d’un logiciel client à un autre en cas de problème.

Le développeur conclut en rappelant aux stakers d’Ethereum 2.0 qu’il est de leur responsabilité de rester à jour. Ils devraient enrichir perpétuellement leurs connaissances quant au fonctionnement du réseau et faire tourner leur propre nœud validateur. De sages paroles qui valent pour tous les systèmes distribués.