Dernier défi d'Ethereum : la chaîne Beacon est-elle toujours en vie ?

Auteur original : Yicheng

Compilation du texte original : Deep Tide TechFlow

introduire

"La chaîne Beacon a de la vie." Les 11 et 12 mai 2023, Ethereum a fait face à deux événements de perte temporaires et définitifs, testant sa résilience. Malgré ces défis, le réseau est resté vivant et s'est remis des deux événements de manière autonome. Nous sommes sur le point d'approfondir ces incidents notables, en examinant leur impact et les améliorations ultérieures mises en œuvre pour empêcher que des incidents similaires ne se reproduisent à l'avenir.

Dernier défi d'Ethereum : la chaîne de balises est-elle toujours en vie ?

Aperçu de l'événement

Les 11 et 12 mai 2023 seront des dates importantes dans l'histoire d'Ethereum car durant ces deux jours, la résilience d'Ethereum a été mise à rude épreuve. Le 11 mai, vers 20 h 19 UTC, le réseau principal Ethereum a connu un ralentissement significatif de la vitesse à laquelle les blocs ont été produits, ce qui a retardé la finalisation de quatre époques – une première pour Ethereum. Le lendemain, un événement similaire s'est produit, cette fois étendant le délai à neuf époques et entraînant une pénalité d'inactivité.

Au cours de ces événements, une baisse significative de l'engagement du réseau a été observée. Le premier glissement s'est produit à l'époque 200,;551, provoquant un blocage temporaire de la finalisation jusqu'à l'époque 200,;555. La deuxième baisse de participation s'est produite à l'époque 200,;750, provoquant une nouvelle suspension de la finalisation jusqu'à l'époque 200,;759.

Malgré les inquiétudes initiales, le réseau Ethereum a démontré sa résilience inhérente en se rétablissant par lui-même. Ces événements ont non seulement confirmé la résilience de la chaîne Ethereum Beacon, mais ont également mis en évidence les domaines potentiels d'amélioration.

Dernier défi d'Ethereum : la chaîne de balises est-elle toujours en vie ?

Fuite d'inactivité

Pendant l'état non final, le réseau Ethereum déploie un mécanisme clé appelé "fuite d'inactivité". Cette fonctionnalité est ancrée dans le protocole PoS d'Ethereum 2.0 et est conçue pour maintenir la fonctionnalité du réseau lors de perturbations majeures, telles que des événements tels que la troisième guerre mondiale ou des catastrophes naturelles à grande échelle, qui peuvent entraîner la mise hors ligne d'un grand nombre de validateurs. empêchant ainsi la finalisation du bloc.

Le mode de fuite d'inactivité est déclenché si le réseau ne peut pas finaliser un bloc pendant quatre époques consécutives (environ 16 minutes). Dans ce mode, les validateurs qui n'attestent pas de blocs commenceront à perdre une partie de leur Ether jalonné (ETH). Cette pénalité augmente de manière quadratique au fil du temps jusqu'à ce que le blocage soit finalisé et restauré.

Ce modèle a un double effet dissuasif. Tout d'abord, il supprime les récompenses pour les preuves de validateur. Deuxièmement, il impose des pénalités supplémentaires aux validateurs non participants proportionnelles à leur temps d'inactivité. Ce mécanisme incite les validateurs à maintenir une participation active et accélère la récupération du réseau. Il s'agit d'une caractéristique essentielle pour maintenir l'intégrité du réseau lors de perturbations majeures.

Influence

Pour les participants au réseau (validateurs) :

Selon une estimation fournie par Ben Edgington, en supposant que 65 % des validateurs étaient hors ligne pendant la fuite de 8 époques, la fuite d'inactivité a entraîné la destruction d'environ 28 ETH. Cela équivaut à une perte d'environ 0,0006 ETH par validateur hors ligne.

De plus, pendant la panne, les récompenses de preuve ont été réduites à zéro, entraînant une perte supplémentaire d'environ 50 ETH qui aurait pu être émise par d'autres moyens. Au total, la perte totale estimée pour les validateurs, y compris les pénalités d'inactivité et les récompenses de preuve perdues, est d'environ 78 ETH.

Pour les utilisateurs :

En revanche, les utilisateurs finaux ont été peu touchés. Bien que la réduction de l'espace de bloc disponible ait entraîné une réduction de la capacité de traitement des transactions, les prix du gaz n'ont pas connu de forte augmentation et sont toujours inférieurs à leurs pics intrajournaliers. De plus, le réseau reste actif tout au long de ces événements.

Cela signifie qu'Ethereum continue de traiter les transactions sans aucune interruption majeure, démontrant sa résilience. En conséquence, les utilisateurs peuvent maintenir les opérations sur le réseau Ethereum en grande partie sans perturbation, même face à des défis, soulignant la robuste résilience du système.

raison

Au cœur du problème de Prysm se trouve l'absence d'un mécanisme de mise en cache pour la relecture des blocs. Cette absence exacerbe la charge du système, engendre trop de routines go et augmente la pression du processeur. Dans certains cas, une nouvelle rediffusion commençait avant la fin de la précédente, ce qui accentuait davantage le système.

Un autre facteur qui a exacerbé le problème était la mauvaise gestion par Prysm des preuves des époques précédentes - les données qui auraient dû être ignorées ne l'ont pas été. Cette inefficacité, combinée à une utilisation sous-optimale de l'état principal, exerce une pression sur le système, en particulier à mesure que les dépôts augmentent et que les enregistrements de validateurs augmentent.

Ces événements ont également révélé des différences essentielles entre les stratégies employées par les différents clients Ethereum. Face au problème de l'exécution des clients, Lighthouse choisit de rejeter les preuves pour maintenir le réseau en vie, tandis que Prysm et Teku etc. utilisent par défaut les anciennes preuves pour générer des blocs.

Malgré les défis, ces événements sont essentiels pour fournir un aperçu des inefficacités logicielles, des choix de conception et des conditions du réseau, renforçant ainsi le réseau Ethereum. Cette séquence d'événements n'a entraîné aucun dommage permanent, mais a plutôt amélioré la résilience et la diversité de la conception du réseau Ethereum.

récupération

Au cours de ces événements, la résilience de la chaîne de balises Ethereum a été véritablement testée et elle a extrêmement bien fonctionné. La chaîne de balises Ethereum semble être vivante et se réparer.

Un facteur clé pour une récupération réussie est la diversité des clients sur le réseau Ethereum. La présence de plusieurs clients, chacun avec une façon unique de gérer le réseau, s'est avérée être une aubaine. Par exemple, alors que les clients Prysm et Teku se débattaient sous la charge d'anciennes épreuves, la politique de Lighthouse consistant à rejeter les épreuves garantissait qu'une partie du réseau restait active et opérationnelle.

Essentiellement, la résilience d'Ethereum vient de la diversité de ses clients, un facteur qui joue un rôle clé en aidant le réseau à se guérir, éliminant tout besoin d'intervention humaine.

Leçons apprises

  • Testnet vs Mainnet : ces événements mettent en évidence les différences entre l'environnement testnet et le réseau principal. Avec plus de 600 000 validateurs sur le réseau principal et un grand nombre d'opérations de retrait, il est clair que la complexité et l'imprévisibilité des réseaux en direct dépassent souvent celles des environnements de test. Cela souligne la nécessité de tests de résistance plus rigoureux pour mieux gérer les conditions réelles du réseau.
  • Pénalité de fuite d'inactivité : l'efficacité de la pénalité de fuite d'inactivité du réseau principal a été renforcée lors de ces événements. Ces pénalités jouent un rôle essentiel dans la promotion de la participation active des validateurs, le maintien de la vie du réseau et la récupération du réseau.
  • L'importance de la vivacité : ces événements soulignent le rôle important de la vivacité dans les réseaux blockchain. Dans le cadre de la conception du protocole LMD Ghost, Ethereum est resté actif tout au long du processus, garantissant que les utilisateurs étaient peu affectés. Contrairement à certaines blockchains qui peuvent faire face à des temps d'arrêt lors de problèmes de réseau, Ethereum donne la priorité à la vivacité plutôt qu'au débit. Cette approche protège les utilisateurs et le fonctionnement normal du réseau, soulignant que sans vivacité, quel que soit le débit, la fonctionnalité du réseau et la sécurité des utilisateurs sont compromises.
  • Importance de la diversité des clients : le processus de rétablissement met l'accent sur la valeur d'avoir des clients diversifiés. Différents clients Ethereum ont des réponses uniques aux événements du réseau, contribuant à la résilience et à la robustesse globales du réseau.
  • Résilience du réseau : Ces événements sont un témoignage fort de la résilience du réseau Ethereum. Malgré des défis importants, le réseau s'auto-guérit et devient plus fort, incarnant le concept d'anti-fragilité dans les systèmes complexes. Cette résilience crée un précédent solide pour l'écosystème crypto plus large et démontre la robustesse de l'architecture sous-jacente et des principes de conception d'Ethereum.

Les événements des 11 et 12 mai 2023 sont des moments charnières dans l'évolution d'Ethereum. Ils fournissent des preuves tangibles de la viabilité de la chaîne Beacon, même dans des circonstances difficiles. Alors qu'Ethereum continue d'évoluer, il s'appuie sur ces expériences pour devenir non seulement plus robuste, mais aussi plus résistant à la fragilité - prêt à poursuivre son voyage vers la décentralisation et au-delà.

Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
  • Récompense
  • Commentaire
  • Partager
Commentaire
0/400
Aucun commentaire
  • Épingler
Trader les cryptos partout et à tout moment
qrCode
Scan pour télécharger Gate.io app
Communauté
Français (Afrique)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)