Analyse des anomalies brèves de la couche de consensus Ethereum sur deux nuits consécutives

Récemment, la couche de consensus d'Ethereum a connu une brève anomalie, suscitant une large attention dans l'industrie. Cet article analysera en profondeur cet événement.

Aperçu de l'événement

Les nuits des 11 et 12 mai, la couche de consensus d'Ethereum a connu de brèves anomalies. L'analyse montre que cela est principalement dû à une surcharge de certains nœuds clients de la couche de consensus d'Ethereum, entraînant la défaillance et la mise hors ligne du nœud de validation (Validator). Cela a directement affecté le vote Epoch, empêchant d'atteindre le seuil requis de 2/3, ce qui a conduit à l'incapacité de la couche de consensus à confirmer la finalité.

Il est à noter que, malgré l'anomalie, le réseau Ethereum s'est rétabli de lui-même en peu de temps. Cela démontre la résilience et la capacité d'auto-réparation de l'algorithme de consensus PoS d'Ethereum.

Détails de l'événement

En général, l'état du réseau de consensus PoS d'Ethereum est finalisé dans 2 Epochs (Finalisé). Cependant, lors des deux événements de la semaine dernière, la finalisation de l'Epoch a été retardée :

• 11 mai : Le délai de l'Époque a été prolongé de 3 Époques, soit environ 20 minutes.
• 12 mai : Le délai de l'Epoch a été prolongé de 8 Epochs, soit environ 51 minutes.

Bien que l'Epoch n'ait pas pu être finalisé à temps, le réseau Ethereum continue de produire des blocs et de traiter des transactions. Cependant, en raison d'un taux de vote insuffisant des nœuds de validation, l'Epoch ne peut pas obtenir les garanties de sécurité au niveau du consensus du réseau PoS d'Ethereum.

Il convient de noter que lors du deuxième événement, un retard dans la finalisation dépassant le seuil prédéfini a déclenché le mécanisme de fuite d'inactivité de l'algorithme de consensus Ethereum. Cela a entraîné la confiscation d'environ 28 ETH et l'émission d'environ 50 ETH non effectuée.

Analyse des causes

La cause directe de ces deux événements est la surcharge de certaines nœuds de clients de la couche de consensus d'Ethereum, entraînant l'arrêt et la mise hors ligne des nœuds de validation, ce qui empêche un vote de consensus normal. Plus précisément :

1. Lorsque le nœud reçoit une attestation ( pointant vers un ancien bloc, il doit recalculer l'état de la chaîne de balises pour vérifier ces attestations, ce processus nécessite beaucoup de ressources CPU et de mémoire.

2. Lorsque de nombreux témoignages pointant vers des blocs obsolètes sont reçus en même temps, les ressources du nœud sont épuisées, entraînant une panne hors ligne du nœud de validation.

3. Bien que ce type de problème puisse être résolu par un cache basé sur les attestations pointant vers des blocs, la croissance du nombre de nœuds de validation et l'apparition d'un grand nombre de telles attestations ont conduit à une saturation du cache des implémentations de clients problématiques.

Actuellement, les clients de couche de consensus Teku et Prysm ont publié des versions patchées pour résoudre ce problème. Les versions patchées filtreront ces témoins obsolètes, en ignorant le témoin lorsque celui-ci pointe vers un slot obsolète ou qu'un nœud n'a jamais vu le checkpoint.

![Pourquoi Ethereum a-t-il connu des pannes brèves pendant deux nuits consécutives ? Une analyse des causes de l'événement])https://img-cdn.gateio.im/webp-social/moments-93dc511107c2b8ba99b85fe1c242b76b.webp(

Avantages de la conception d'Ethereum

Dans cet événement, Ethereum a montré ses avantages en matière de conception :

1. Diversité des clients : Les conceptions d'implémentation de différents clients sont différentes, même si certains clients rencontrent des problèmes, cela n'affectera pas le fonctionnement normal des autres clients.

2. Conception de l'algorithme Gasper : séparer la production de blocs de la finalisation, de sorte que même si la finalisation des blocs est entravée, la production de blocs ne s'arrête pas, garantissant ainsi la disponibilité du réseau.

![Pourquoi Ethereum a-t-il connu des pannes temporaires ces deux dernières nuits ? Une analyse des causes de l'événement])https://img-cdn.gateio.im/webp-social/moments-3bbc1797156b2a00d2fe30c0b5c1a567.webp(

Expérience et enseignements

1. La diversité des clients doit encore être renforcée : actuellement, la diversité des clients Ethereum présente encore des possibilités d'amélioration, en particulier la concentration des clients de couche d'exécution sur Geth, qui représente jusqu'à 61 %, ce qui pose un risque potentiel.

2. Le mécanisme de commutation des clients doit être amélioré : lorsqu'un client rencontre un problème, il reste un défi de savoir comment passer en toute sécurité à une implémentation client normale.

3. Le suivi du consensus doit être renforcé : des services similaires à Safe Head sont nécessaires pour surveiller en continu l'état en temps réel du réseau PoS d'Ethereum et détecter rapidement les anomalies avec des alertes.

4. Renforcer l'éducation des utilisateurs : vulgariser le mécanisme de consensus PoS d'Ethereum pour éviter que les utilisateurs ne ressentent une panique inutile.

5. La couche d'application doit bien se préparer : les applications comme Layer2, les échanges, les Oracle, etc. doivent traiter correctement les scénarios d'instabilité du réseau, comme prolonger le temps de confirmation ou suspendre le service.

Résumé

Cet événement a démontré la résilience et la capacité d'auto-réparation de l'algorithme de consensus PoS d'Ethereum, tout en mettant également en lumière certains aspects nécessitant des améliorations. À l'avenir, l'écosystème Ethereum devra continuer à investir dans la diversité des clients, la surveillance du réseau, l'éducation des utilisateurs, etc., afin d'améliorer la stabilité et la fiabilité de l'ensemble du réseau.

![Pourquoi Ethereum a-t-il connu des pannes temporaires pendant deux nuits consécutives ? Analyse des causes de l'événement])https://img-cdn.gateio.im/webp-social/moments-b286aa6918497b555cf460e5c4e5f0cb.webp(