概要
概要
最初のレベルのタイトル
出来事と背景
通常、イーサリアムのPoSコンセンサスネットワークのステータスは2エポックで確定（Finalized）されますが、先週は確定が2エポックの遅れがありました。
初めそれは 5 月 11 日に発生し、エポックの最終処理は 3 エポック、約 20 分遅れました。
2回目それは 5 月 12 日に発生し、エポックの最終処理は 8 エポック、約 51 分遅れました。
イベント中、イーサリアムネットワークはブロックの生成とトランザクションの処理を続けました。しかし、Validator (検証ノード) の投票率が不十分だったため、Epoch を最終決定することができませんでした (つまり、Epoch はイーサリアム PoS ネットワークのコンセンサス レベルのセキュリティ保証を受けました)。 Epoch がファイナライズに失敗するということは、ほとんどのバリデーターが悪意を持ってフォークを行った場合、epcoh がロールバックされ、その結果トランザクションがロールバックされる可能性があることを意味します。
実際、インシデント中、イーサリアム ネットワークにはフォークは存在せず、バリデーターは悪意のある投票を行っていませんでしたが、投票率が不十分だったのは多数のバリデーターがオフラインだったためであり、そのためエポックが完了することができませんでした。行事。
観察の結果、オフライン バリデーターの CPU 過負荷という異常な状況がオフライン バリデーターの直接の原因であると考えられます。
2 番目のイベントでは、ファイナライゼーションの遅延が 8 エポックよりも大きかったため、エポックのファイナライズが 8 エポック遅れました。MIN_EpochS_TO_INACTIVITY_PENALTY(= 4) したがって、イーサリアムコンセンサスアルゴリズムがトリガーされますInactivity leak処理機構。
約束した資金を削減することでオフラインのバリデーターにペナルティを与えます。約28ETHが没収された。
認証報酬のキャンセルにより、約50ETHが発行されていない。
このメカニズムにより、オンライン バリデーターは最終的にイーサリアムの誓約資金の 2/3 を保持できるようになり、ネットワークのステータスを最終的に確定できるようになります。
imTokenのノードサービスもこのインシデントを検知しており、イーサリアムコンセンサス層のバリデーターの投票状況をリアルタイムに監視することで、エポックが正常に終了しない前にイーサリアムコンセンサスネットワークの異常を早期に警告することができます。以下の図は、最初のイベントが発生したときのノードの状態です。
PoW メカニズムでは、トランザクションの成功は、一定数の連続ブロック後にトランザクションがロールバックされないことを判断することであり、PoS は、トランザクションの成功の判断として Safe Head によって返されたブロックの高さに基づいています。取引。現在の仕様では、Safe Head のステータスとして Justified Checkpoint が使用されているため、以前の Epoch のステータスから判断すると、6.4 分の遅延が発生する可能性があり、ユーザーにとっては非常に悪い経験になります。
imTokenが開発したSafe Headサービスは、ユーザートランザクションの安全性確保を前提に、リアルタイムのイーサリアムコンセンサス層データに基づいてトランザクション確認用の安全なブロックを計算し、トランザクション確認にかかる時間を短縮します。通常の状況では、imToken の Safe Head アルゴリズムによって返されるブロックの高さ (上図の黄色) は最新のブロックの高さ (緑色) に非常に近いため、ユーザー エクスペリエンスが向上します。
セーフヘッドメカニズムの詳細情報:
原因分析
上記のインシデントの直接の原因は、特定の Ethereum コンセンサス層クライアント ノードの負荷が高すぎるため、Validator がオフラインになり、コンセンサス投票が正常に実行できなくなることです。分析の結果、これらのノードの負荷が高くなる理由は次のとおりです。
古いブロックを指す証明書を受信した場合、ノードはこれらの証明書を検証するためにビーコン チェーンの状態を再計算する必要があり、このプロセスは大量の CPU リソースとメモリ リソースを消費します。
古いブロックを指す多数のウィットネスを同時に受信すると、ノードの CPU およびメモリ リソースが枯渇し、これらのバリデーターがオフラインになります。
本来、この種の問題は、ブロックを指す証人に基づいてキャッシュすることで解決できますが、Validator の規模の増大とそのような証明書の大量の出現により、問題のあるクライアントが実装したキャッシュが壊れてしまいました。ダウンしている場合、ノードは再起動するために大量のリソースを消費する必要があります。 ビーコン チェーンの状態を計算します。
コンセンサス層クライアントである Teku と Prysm は、この問題を解決するパッチ バージョンをリリースしました。具体的には、パッチ バージョンのクライアント実装は、これらの古い監視をフィルターで除外します。つまり、次の条件が満たされる場合、監視は無視されます。
証人は古いスロットを指摘する
証人はノードが見たことのないチェックポイントを指しています
ただし、パッチの有効性を確認するには、引き続きイーサリアムメインネットの完成を観察する必要があります。
最初のレベルのタイトル
Prysm：v 4.0.3-hotfix
Teku：v2 3.5.0
イーサリアム設計の利点
このインシデントでは、イーサリアムは可用性を保証し、ブロックの生成とトランザクションの処理を継続しており、エポックのファイナライズを遅らせるだけの鍵は次の 2 点にあります。
1. イーサリアムクライアントの多様性
副題
イーサリアムクライアントの多様性
このインシデントでは、コンセンサス層クライアントである Teku と Prysm の実装に問題がありましたが、他のコンセンサス層クライアントの正常な動作には影響はありませんでした。今回の Lighthouse クライアントのように、影響を受けません、クライアントごとに実装設計が異なるため、Validator は引き続き正常に動作します。
副題
使いやすさのための Ethereum Gasper コンセンサス アルゴリズムの設計
イーサリアムの可用性を確保することは、イーサリアム コンセンサス アルゴリズム Gasper の設計開始点の 1 つであり、イーサリアム ブロックの生成と完成を分離します。したがって、ブロックのファイナライズが阻止されても、ブロックの生成は終了しません。ほとんどの場合、ブロックのファイナライズは最終的に再開されることを考慮すると (生成されたブロックは引き続きファイナライズされます)、ユーザーへの影響は実際には非常に低いものになります。他の BFT コンセンサス アルゴリズムと比較すると、ブロックのファイナライズに失敗した場合、コンセンサス ノードは次のブロックの生成を停止します。その結果、その期間中はブロックチェーン全体が利用できなくなり、これは一般に「ブロックチェーンのハング」として知られています。
最初のレベルのタイトル
副題
イーサリアムのマルチクライアントの課題
画像の説明
ソース：https://clientdiversity.org/#distribution
イーサリアムクライアントの多様性は依然として促進され、宣伝される必要があることがわかります。おそらく、クライアントの実装が十分に多様で、Prysm と Teku の割合が 1/3 未満であれば、このイベントは発生しないでしょう (2/3 のクライアントはエポックを終了するのに十分に適切に機能していました)。さらに、現在の実行層のクライアントは Geth に集中しており、その割合は 61% にも上ります。これは実際には潜在的なリスクです。Geth が適切に機能しない場合、イーサリアムは大きな影響を受けます。
イーサリアム クライアントの多様性に対する更なる取り組みの必要性に加えて、イーサリアム クライアントの切り替えも、このインシデントによって明らかになった問題点です。特定のクライアント実装が失敗した場合、Validator はどのようにして通常のクライアント実装に切り替えるのでしょうか。このプロセスには以下が含まれます。
問題のあるクライアントの検証キーを通常のクライアントに安全に移行します
イーサリアムコンセンサスにはスラッシュルールがあるため、古いクライアントと新しいクライアントの動作がスラッシュされずに一貫していることを保証する必要があります。例えば：
新旧のクライアントは分岐点の両側のチェックポイントに投票したため、削減されました
副題
イーサリアムコンセンサスのモニタリング
Safe Head のようなサービスは、イーサリアム PoS ネットワークのリアルタイム ステータスを継続的に監視し、エポックが期待どおりに終了しないまでネットワーク ステータスが異常であることを知るのではなく、そのようなイベントを事前に検出して警告するために必要です。関連する最新の研究は次の場所でご覧いただけます。副題。
イーサリアムコンセンサスアルゴリズムの普及科学
副題
イーサリアムアプリケーションへの影響
イーサリアム ネットワークは十分に堅牢ですが、時折不安定になるとアプリケーションに一定の影響が生じます。同時に、アプリケーションはこれらの不安定なシナリオを正しく処理する必要があります。
Layer 1 ->レイヤー 2 のデポジット時間は長くなります。レイヤ 2 が導入されている場合、重要な前提条件は、L1 デポジット トランザクションがロールバックされないことを確認することです。そのため、イーサリアムネットワークEpochのファイナライズが遅れると、その分L1→L2の入金時間も長くなります。
同様に、取引所もチェーン上のリチャージ トランザクションがロールバックされないようにする必要があるため、リチャージ時間もそれに応じて長くなります。
Oracle チェーン上の引用はロールバックされる危険性があるため、Oracle チェーンに依存する高価値のサービスは適切に一時停止する必要があります。
要約する
要約する
参考リンク
