- Rubrique
28k Popularité
59k Popularité
9k Popularité
16k Popularité
30k Popularité
2k Popularité
113k Popularité
27k Popularité
26k Popularité
7k Popularité
- Épingler
28k Popularité
59k Popularité
9k Popularité
16k Popularité
30k Popularité
2k Popularité
113k Popularité
27k Popularité
26k Popularité
7k Popularité
La couche de consensus Ethereum a connu des anomalies brèves pendant deux nuits consécutives, et l'auto-réparation du réseau met en évidence la résilience du PoS.
Analyse des brèves anomalies d'Ethereum sur deux nuits consécutives
Les nuits des 11 et 12 mai, la couche de consensus d'Ethereum a connu de courtes anomalies. Les analyses montrent que cela est principalement dû à une surcharge de certains nœuds clients de la couche de consensus d'Ethereum, entraînant la mise hors ligne de nœuds validateurs. Cela a directement affecté le vote Epoch, qui n'a pas pu atteindre le seuil de 2/3, empêchant ainsi la couche de consensus de confirmer la finalité. Cependant, le réseau Ethereum s'est rétabli rapidement, ce qui témoigne de la résilience et de la capacité d'auto-réparation de l'algorithme de consensus PoS d'Ethereum.
Récapitulatif des événements
En général, l'état du réseau de consensus PoS d'Ethereum est finalisé en 2 Epochs. Cependant, la semaine dernière, il y a eu deux cas de retard dans la finalisation des Epochs :
Pendant cette période, 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 validateurs, l'Epoch ne peut pas être finalisé, ce qui signifie qu'il n'est pas possible d'obtenir la garantie de sécurité au niveau de consensus du réseau PoS d'Ethereum. Cela signifie que dans des cas extrêmes, les transactions de cette epoch peuvent être annulées.
En réalité, durant cette période, le réseau Ethereum n'a pas connu de fork, et les nœuds validateurs n'ont pas voté de manière malveillante. Un grand nombre de nœuds validateurs hors ligne a entraîné un taux de vote insuffisant, ce qui est la cause directe de l'incapacité à finaliser l'Epoch. Il a été observé que les nœuds validateurs hors ligne présentaient des cas anormaux de surcharge CPU.
Lors du deuxième événement, un retard de confirmation de plus de 4 Epochs a déclenché le mécanisme de fuite d'inactivité de l'algorithme de consensus Ethereum :
Analyse des causes
La cause directe de cet événement est la surcharge de certaines nœuds clients de la couche de consensus d'Ethereum, entraînant l'interruption de fonctionnement des nœuds validateurs, qui ne peuvent pas participer normalement au vote de consensus. L'analyse spécifique est la suivante :
Lorsqu'un témoin pointant vers un ancien bloc est reçu, ( Attestation ), le nœud doit recalculer l'état de la chaîne de balises pour vérifier ces témoins, ce processus consomme beaucoup de ressources CPU et mémoire. Lorsqu'un grand nombre de témoins pointant vers d'anciens blocs sont reçus simultanément, les ressources CPU et mémoire du nœud sont épuisées, entraînant l'arrêt hors ligne de ces nœuds validateurs.
Théoriquement, ce type de problème peut être résolu par un cache basé sur les attestations pointant vers les blocs. Cependant, en raison de la croissance du nombre de validateurs et de l'apparition d'un grand nombre de telles attestations, le cache de l'implémentation du client problématique est compromis, forçant les nœuds à consommer de nombreuses ressources pour recalculer l'état de la chaîne de balises.
Les clients de couche de consensus Teku et Prysm ont publié des versions de correctif pour résoudre ce problème. Les clients de la version de correctif mettront en œuvre un filtrage de ces anciens témoins, c'est-à-dire qu'ils ignoreront ce témoin lorsque les conditions suivantes seront remplies :
Avantages de la conception d'Ethereum
Dans cet événement, Ethereum a maintenu sa disponibilité, continuant à produire des blocs et à traiter des transactions, ne retardant que la finalisation de l'Epoch. Cela est principalement dû à deux points :
La diversité des clients Ethereum
Bien que les clients Teku et Prysm aient rencontré des problèmes, cela n'affecte pas le bon fonctionnement des autres clients de la couche de consensus. Par exemple, le client Lighthouse n'est pas affecté cette fois-ci. En raison des différences de conception dans l'implémentation des différents clients, il y a toujours des nœuds validateurs qui fonctionnent normalement.
La diversité des clients Ethereum garantit que : même si certains clients rencontrent des problèmes ( et même entraînent une impossibilité de finaliser l'Epoch ), cela n'affectera pas la génération de blocs et le traitement des transactions par les clients normaux, assurant ainsi la disponibilité d'Ethereum.
Conception de la disponibilité de l'algorithme de consensus Gasper
Garantir la disponibilité d'Ethereum est l'un des points de départ de la conception de l'algorithme Gasper, qui sépare la production de blocs de la finalisation. Ainsi, même si la finalisation des blocs est entravée, la production de blocs ne s'arrête pas. Étant donné que dans la plupart des cas, la finalisation des blocs finira par se rétablir, l'impact réel sur les utilisateurs est très faible.
En revanche, d'autres algorithmes de consensus BFT arrêtent la production du prochain bloc lorsque la confirmation du bloc échoue, rendant la blockchain complètement inutilisable pendant cette période.
De plus, le deuxième événement a également déclenché le mécanisme de fuite d'inactivité, qui vise principalement à garantir qu'Ethereum puisse encore reconfirmer des blocs même dans des situations extrêmes où ( un grand nombre de validateurs sont hors ligne pendant une longue période ).
Expérience et enseignements
Les défis des multiples clients Ethereum
La diversité des clients Ethereum doit encore être promue et annoncée. Si les clients sont suffisamment variés pour que la part de Prysm et Teku soit inférieure à 1/3, alors cet événement ne se produira même pas (2/3 le fonctionnement normal des clients suffit à valider l'Epoch ).
De plus, lorsque l'implémentation d'un client présente des problèmes, la façon dont les nœuds validateurs peuvent passer en toute sécurité à une implémentation de client normale est également un problème à résoudre. Ce processus implique :
Surveillance du consensus Ethereum
Il est nécessaire d'avoir des services similaires à Safe Head pour surveiller en continu l'état en temps réel du réseau PoS d'Ethereum, afin de détecter et d'alerter à l'avance de tels événements, au lieu d'attendre que l'Epoch ne puisse pas être confirmé comme prévu pour découvrir que l'état du réseau est anormal.
La vulgarisation de l'algorithme de consensus d'Ethereum
Cet événement a mis en lumière la nécessité de vulgariser le mécanisme de consensus PoS d'Ethereum. De nombreux utilisateurs ont cru à tort que "Ethereum était en panne", provoquant une panique inutile. En réalité, le réseau Ethereum continue de produire des blocs et de traiter des transactions. La vulgarisation des connaissances sur la blockchain à destination des utilisateurs reste un domaine dans lequel les professionnels doivent continuer à travailler.
sur les applications Ethereum
Bien que le réseau Ethereum soit suffisamment robuste, une instabilité occasionnelle peut avoir un certain impact sur les applications. Les applications doivent gérer correctement ces scénarios d'instabilité :
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, ainsi que la réactivité rapide et la capacité de correction des erreurs des équipes de clients. Pour l'écosystème Ethereum, il est nécessaire de continuer à investir dans les domaines suivants : augmenter la diversité des clients, optimiser la surveillance en temps réel et l'alerte de l'état du réseau, approfondir l'éducation des utilisateurs et améliorer les plans d'urgence des participants de l'écosystème en cas d'anomalies du réseau.