イーサリアムコンセンサス層連続二晩短時間異常分析

近日、イーサリアムコンセンサス層に短時間の異常が発生し、業界の広範な関心を引き起こしました。本記事ではこの事件について深く分析します。

イベント概要

5月11日と12日の2晩連続で、イーサリアムのコンセンサス層に短期間の異常が発生しました。分析によると、これは主にいくつかのイーサリアムのコンセンサス層クライアントノードの負荷が過剰で、検証ノード(Validator)がダウンしてオフラインになったためです。これにより、エポック投票に直接影響を与え、必要な2/3の閾値に達することができず、コンセンサス層が最終性を確認できなくなりました。

注目すべきは、異常が発生したにもかかわらず、イーサリアムネットワークは短時間で自ら正常に回復したことです。これは、イーサリアムPoSコンセンサスアルゴリズムの弾力性と自己修復能力を示しています。

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

イベントの詳細

通常の場合、イーサリアムPoSコンセンサスネットワークの状態は2つのエポック内で確定されます(Finalized)。しかし、先週の2つのイベントでは、エポックの確定に遅れが生じました：

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

Epochが時間通りに決定できなかったにもかかわらず、イーサリアムネットワークは引き続きブロックを生成し、取引を処理しています。しかし、検証ノードの投票率が不足しているため、EpochはイーサリアムPoSネットワークのコンセンサスレベルのセキュリティ保証を得ることができません。

注目すべきは、第二の事件において、確定の遅延が事前に設定された閾値を超えたため、イーサリアムのコンセンサスアルゴリズムのInactivity leakメカニズムがトリガーされたことです。これにより、約28のETHが没収され、約50のETHが発行されませんでした。

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

原因分析

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

1. ノードが古いブロックを指す証明(Attestation)を受け取ったとき、これらの証明を検証するためにビーコンサインの状態を再計算する必要があり、このプロセスには大量のCPUとメモリリソースが必要です。

2. 古いブロックを指す大量の証拠が同時に受信されると、ノードのリソースが消費され、検証ノードがダウンしてオフラインになります。

3. この種の問題は、証人がブロックを指すキャッシュを基にして解決できますが、検証ノードの規模の増加とこのようなattestationの大量発生により、問題のあるクライアント実装のキャッシュが破壊されることになります。

現在、コンセンサス層クライアントTekuとPrysmはこの問題を解決するためのパッチ版をリリースしました。パッチ版はこれらの古い証拠をフィルタリングし、証拠が古いスロットを指すか、ノードが見たことのないチェックポイントを指す場合、その証拠を無視します。

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

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

今回の事件で、イーサリアムはその設計の優位性を示しました：

1. クライアントの多様性：異なるクライアントの実装設計が異なるため、あるクライアントに問題が発生しても、他のクライアントの正常な運用には影響しません。

2. Gasperアルゴリズム設計：ブロック生成と確定を分離し、ブロックの確定が妨げられても、ブロックの生成は停止せず、ネットワークの可用性が保証されます。

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

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

1. クライアントの多様性はまだ強化が必要です：現在、イーサリアムのクライアントの多様性には向上の余地があり、特に実行層のクライアントはGethに集中しており、その割合は61%に達しており、潜在的なリスクがあります。

2. クライアント切り替えメカニズムの改善が必要です：特定のクライアントに問題が発生した場合、正常なクライアント実装に安全に切り替える方法は依然として課題です。

3. コンセンサス監視の強化が必要：Safe Headのようなサービスが、イーサリアムPoSネットワークのリアルタイム状態を継続的に監視し、異常を迅速に発見し警告する必要があります。

4. ユーザー教育の強化：イーサリアムのPoSコンセンサスメカニズムを普及させ、ユーザーに不必要なパニックを引き起こさせない。

5. アプリケーション層は対応を整える必要があります：Layer2、取引所、Oracleなどのアプリケーションは、ネットワークの不安定なシナリオを適切に処理する必要があります。例えば、確認時間を適切に延長するか、サービスを一時停止することが求められます。

サマリー

このイベントはイーサリアムのPoSコンセンサスアルゴリズムのレジリエンスと自己修復能力を示す一方で、改善が必要な点も浮き彫りにしました。今後、イーサリアムエコシステムはクライアントの多様性、ネットワーク監視、ユーザー教育などの分野に継続的に投資し、全体のネットワークの安定性と信頼性を向上させる必要があります。

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