イーサリアムの短期的な異常分析は2夜連続で

5月11日と12日の2夜連続で、イーサリアムのコンセンサスレイヤーに短時間の異常が発生しました。分析によると、これは主に一部のイーサリアムコンセンサスレイヤーのクライアントノードの負荷が過剰で、バリデータノードがダウンしてオフラインになったためです。これにより、エポック投票が2/3の閾値に達することができず、コンセンサスレイヤーが最終性を確認できなくなりました。しかし、イーサリアムネットワークは短時間で自己回復し、これはイーサリアムPoSコンセンサスアルゴリズムのレジリエンスと自己修復能力を示しています。

! なぜイーサリアムは2夜連続で下落したのですか? 事故原因の分析

イベントの振り返り

通常の場合、イーサリアムPoSコンセンサスネットワークの状態は2つのエポック内で確定します。しかし、先週は2回のエポック確定遅延が発生しました:

• 5月11日:エポックファイナライズが3エポック遅れ、約20分。
• 5月12日:エポックの確定が8つのエポック遅延し、約51分となりました。

この期間中、イーサリアムネットワークは引き続きブロックを生成し、トランザクションを処理しました。しかし、バリデータノードの投票率が不足しているため、Epochは確定できず、イーサリアムのPoSネットワークの合意レベルのセキュリティ保証を得ることができませんでした。これは、極端な状況下では、そのepoch内のトランザクションがロールバックされる可能性があることを意味します。

実際、この期間中にイーサリアムネットワークはフォークを発生させず、バリデーターノードも悪意のある投票を行っていませんでした。大量のバリデーターノードがオフラインになったため、投票率が不足し、エポックが確定できない直接的な原因となりました。観察によると、オフラインのバリデーターノードにCPU過負荷の異常が発生していました。

第二回のイベントでは、確定の遅延が4つのエポックを超えたため、イーサリアムのコンセンサスアルゴリズムのInactivity leakメカニズムがトリガーされました:

• オフラインのバリデータノードに対して罰則が科され、そのステーク資金が削減され、約28のETHが没収されました。
• Attestation報酬をキャンセルし、約50ETHが発行されていない。
• このメカニズムは、オンラインバリデーターが最終的にイーサリアムの総ステーキング資金の2/3を掌握できることを保証し、ネットワークの状態が最終的に確定されることを可能にします。

! なぜイーサリアムは2夜連続で下落したのですか? 事故原因の分析

原因分析

この事件の直接的な原因は、いくつかのイーサリアムコンセンサスレイヤーのクライアントノードの負荷が高すぎたため、バリデータノードがダウンしてオフラインになり、正常にコンセンサス投票を行うことができなくなったことです。具体的な分析は以下の通りです:

古いブロックを指す証明(Attestation)を受け取ったとき、ノードはこれらの証明を検証するためにビーコンサインの状態を再計算する必要があります。このプロセスは大量のCPUとメモリリソースを消費します。同時に多くの古いブロックを指す証明を受け取ると、ノードのCPUとメモリリソースが枯渇し、これらの検証者ノードがダウンしてオフラインになります。

理論的には、この種の問題は、証人がブロックを指し示すキャッシュを基にして解決できる。しかし、バリデーターの規模の拡大と大量のこのようなアテステーションの出現により、問題が発生したクライアント実装のキャッシュが破損し、ノードは大量のリソースを消費してビーコンサインの状態を再計算せざるを得なくなる。

コンセンサスレイヤークライアントTekuとPrysmは、この問題を解決するためにパッチバージョンをリリースしました。パッチバージョンのクライアント実装は、以下の条件が満たされた場合に、これらの古い証拠を無視するようにフィルタリングします:

• 古いスロットを指す証人
• ウェ witnessは、ノードが見たことのないチェックポイントを指します

! なぜイーサリアムは2夜連続で下落したのですか? 事故原因の分析

イーサリアムの設計の利点

この出来事において、イーサリアムは可用性を維持し、ブロックを継続的に生成し、トランザクションを処理しましたが、Epochの確定が遅れました。これは主に2つの点によるものです。

1. イーサリアムクライアントの多様性
2. Gasperアルゴリズムの設計

イーサリアムクライアントの多様性

TekuとPrysmクライアントに問題が発生しましたが、他のコンセンサスレイヤークライアントの正常な運用には影響しません。例えば、Lighthouseクライアントは今回影響を受けていません。異なるクライアントは実装設計に違いがあるため、検証者ノードは正常に運用されています。

イーサリアムクライアントの多様性は次のことを保証します: たとえ特定のクライアントに問題が発生したり(、またはEpochが決定できなくなったり)しても、正常なクライアントがブロックを生成し、取引を処理することには影響を及ぼさず、イーサリアムの可用性を保証します。

Gasperコンセンサスアルゴリズムの可用性設計

イーサリアムの可用性を保証することはGasperアルゴリズム設計の出発点の一つであり、ブロック生成と確定を分離します。したがって、ブロックの確定が妨げられても、ブロックの生成は停止しません。ほとんどの場合、ブロックの確定は最終的に回復することを考慮すると、ユーザーへの実際の影響は非常に小さいです。

対照的に、他のBFTコンセンサスアルゴリズムはブロックの確定に失敗した場合、コンセンサスノードが次のブロックを生成するのを停止し、その間、ブロックチェーン全体が利用できなくなります。

さらに、第二の事件はInactivity Leakメカニズムを引き起こしました。このメカニズムは、極端な状況(において大量のバリデーターが長時間オフライン)であっても、イーサリアムがブロックを再確定できるようにするためのものです。

! なぜイーサリアムは2夜連続で下落したのですか? 事故原因の分析

体験とインスピレーション

イーサリアム多クライアントの挑戦

現在、イーサリアムのクライアントの多様性はまだ推進と宣伝が必要です。クライアントが十分な多様性を持ち、PrysmとTekuの占有率が1/3未満になれば、今回の事件は発生しないでしょう(2/3クライアントが正常に機能すれば、Epoch)を確定するのに十分です。

さらに、あるクライアントの実装に問題が発生した場合、バリデータノードが正常なクライアント実装に安全に切り替える方法も解決が必要な問題です。このプロセスには:

• 問題のあるクライアントの検証キーを正常なクライアントに安全に移行する
• 旧クライアントと新クライアントの動作の一貫性を保証し、罰せられないようにする

イーサリアム共識の監視

Safe Headのようなサービスが必要で、イーサリアムPoSネットワークのリアルタイムの状態を継続的に監視し、そのようなイベントを事前に発見して警告する必要があります。Epochが期待通りに確定できないときにネットワークの状態異常が発見されるのではなく。

イーサリアムのコンセンサスアルゴリズムの普及

この事件は、イーサリアムのPoSコンセンサス機構の普及の必要性を明らかにしました。多くのユーザーが「イーサリアムがダウンした」と誤解し、不必要なパニックを引き起こしました。実際、イーサリアムネットワークは常にブロックを生成し、取引を処理し続けています。ユーザー向けのブロックチェーン知識の普及は、業界関係者が継続的に努力すべき方向です。

のイーサリアムアプリケーションへの示唆

イーサリアムネットワークは十分に堅牢ですが、時折の不安定性がアプリケーションに一定の影響を与えることがあります。アプリケーションはこれらの不安定なシーンを正しく処理する必要があります:

• Layer1からLayer2への入金時間が長くなる可能性があります
• 取引所の入金時間が延長される可能性があります
• オラクルチェーン上の価格提供にはロールバックリスクが存在し、それに依存する高価値サービスは適切に一時停止する必要があります。
• 一部のDeFiアプリケーションは、機能の一部を一時停止する必要があるかもしれません。

まとめ

この事件は、イーサリアムのPoSコンセンサスアルゴリズムの弾力性と自己修復能力、及びクライアントチームの迅速な対応とバグ修正能力を示しました。イーサリアムエコシステムにとって、以下の点への継続的な投資が必要です: クライアントの多様性の増加、ネットワーク状態のリアルタイム監視と警告の最適化、ユーザー教育の深化、ネットワーク異常時のエコシステム参加者の緊急プランの整備。

! なぜイーサリアムは2夜連続で下落したのですか? 事件の原因分析