ブログ > 2024 > May > Ouroboros Genesisの設計更新情報

Ouroboros Genesisの設計更新情報

Cardanoの信頼性とセキュリティを担うコンセンサスプロトコルの最新版であるOuroboros Genesisの設計と実装の詳細

2024年 5月 8日 Nicolas Frisby 16 分で読めます

Ouroboros Genesisの設計更新情報

Ouroboros Genesisは、ただでさえ堅牢なOuroborosプロトコルをさらに強化する一連の拡張機能。新規に参加する場合や、しばらくオフラインであった後に再度参加する場合に、ネットワークノードを保護する対策を備えています。

Ouroborosは、Cardanoブロックチェーンの中心にあるコンセンサスプロトコルです。Cardanoの継続的な開発と普及が進む中、Ouroborosは予定通りのアップグレードパスに沿って進んでいます。Ouroboros Classicは証明可能安全性を持つ、初のプルーフオブステーク型プロトコル。Ouroboros BFTは、Byronの更新を可能にする暫定的な解決策でした。Ouroboros Praosは、Ouroboros Classicをさらに開発したものです。Ouroborosの進化は、Ouroboros Genesisでさらに一歩前進します。これは、2024年の第3四半期までには配信される予定です。

本稿では、Ouroboros Genesisプロトコルの開発と実装に関する最近の更新について説明します。

Ouroborosの来歴

ブロックチェーンは、ノードと呼ばれるデバイス間で複製される分散型台帳です。単一の中央集権的機能が存在しないため、台帳の全複製の一貫性と不変性を保証するメカニズムの存在が不可欠です。そのメカニズムがコンセンサスプロトコルです。また、このプロトコルは、ノードが新しいブロックを検証してチェーンに追加するためのインセンティブも設定します。

OuroborosはCardanoの時間をエポックに分割します。これはさらにスロットに細分化されています。スロットは、ブロックが作成される短い期間を表します。

Ouroboros Classicは、ほとんどのノードがオンラインであり、それが所持する台帳の複製が一貫している場合に安全であることを証明しています。攻撃者はどのノードが次のスロットリーダー(チェーンにブロックを追加するノード)になるかを予測できないため、攻撃は非常にコストがかかるものとなります。

Ouroboros Praosは次のスロットリーダーを選ぶ際のランダム性を高め、他の起こりうる攻撃への対策を追加しました。

Ouroboros Genesisは、ノードが最初にネットワークに参加する状況(ジェネシスブロックから開始するとき)、または長期間オフラインであったあとに再参加する状況に対処します。そのようなノードは、現状に追いつくまで脆弱な状態にあります。たとえば、ロングレンジ攻撃は、攻撃者がチェーンの履歴を書き換えようとして発生します。敵は大量のステークを蓄積して、こっそりとメインチェーンよりも速くブロックを作ります。代替履歴チェーンの準備ができたら、メインチェーンを攻撃者のチェーンに切り替えようとします。Genesisの実装により、同期中のノードがエクリプスされない限り、ロングレンジ攻撃が緩和されます。エクリプス攻撃は、攻撃者が攻撃対象ノードを悪意のあるピアで囲み、実際のネットワークを遮蔽することにより発生します。

最新の開発情報

Genesisは次の新しい概念を導入します。

  • 台帳ピア
  • ライトウェイトチェックポイント(一時的なフォールバックまたはオーバーライドとして)
  • LOE
  • GDD
  • LOP
  • Genesisステートマシン

台帳ピア

Genesis論文からもっとも深く逸脱した点は、初期アーキテクチャーにおいてなされた、ロールバックに関するPraosノードの制限を維持するための決定でした。Praosでは、Cardanoノードは手動操作なしで2,160ブロックよりも前にロールバックすることはありません。Genesis論文で概説されているように、何年も敵対的なチェーンの延長を選択するしかなかったエクリプス攻撃下のノードは、最終的に誠実なチェーンを処理するノードに接続すると、直ちに任意の数のブロックをロールバックします。

ノードに無制限ロールバック機能は必要ないため、アーキテクトは代わりにロールバック制限を優先しました。これは、リソース使用量の多くの制限の鍵となります。Genesisでそれを省くと、それまでのエンジニアリング作業の中でも重要な部分によって喚起される主要な不変条件が取り除かれることになります。さらに、同期するCardano Genesisノードが健全なピアにアクセスできる限り、Praosノードと同様に、2,160ブロックを超えるロールバックは必要とされないはずです。

エクリプスは、論文で表現されているよりも、Genesisノードにとって潜在的に重大な脅威であり、論文ではエクリプスに直接対処していません。こうした攻撃はGenesisの安全性を脅かします。なぜなら、ほんの数秒のエクリプスであっても、同期中のGenesisノードがGenesisの密度比較を忠実に実装しているにもかかわらず、敵対チェーンから2,161ブロックを選択するのに十分である可能性があるからです。誠実なチェーンについての知識がなければ、Gnensisルールにより、その時点で単純にアクセス可能なもっとも密度の高いチェーンが選択されます。エクリプス状態では、必ずしも誠実なチェーンが選ばれるとは限りません。これは、エクリプス状態のノードとそのユーザーは単に遅れたり、混乱したり、誤った情報を伝えたりするだけとするGenesis論文とは対照的です。 これには関連するリスクが伴いますが、安全性や活性が損なわれることはありません。なぜなら、ノードは最終的に誠実なピアに接続し、回復できうるからです。

理論的にノードが決して遅れることのないPraosネットワークだけを考えると、エクリプスは依然として有害である可能性があります。Genesisとの主な違いは、Praosノード(本質的に追いついている)は、敵対的なチェーンに関与する可能性がかなり高くなるまでに、はるかに長いエクリプスに耐えることができるということです。ただし、同期中はさらに脆弱性が増すという点を考慮しなくても、Praosノードはエクリプスに対する防御を必要とします。

防御策の1つは、ピア選択ロジック内に台帳ピアの概念を導入してエクリプスの確率と期間を大幅に制限することです。同期中に、Genesisノードは台帳ピアの設定を調整して、エクリプスされる可能性を大幅に減らします。エクリプスされなければ、Genesisノードが敵対的なチェーンから2,161ブロックを選択することはありません。

変更されたピア選択は、次のように機能します。Genesisノードは最近のステーク分布を調べ、ネットワークの保持に参加したサンプルピアを選択します。これにより、悪意のあるノードを選択する可能性が大幅に減少します。

フォールバック:ライトウェイトチェックポイント

Genesis論文では、正常なPraosネットワーク内の最良のチェーンは、2つのチェーンが交差した直後に固定されたスロットウィンドウ内で、他のどのチェーンよりも多くのブロックを持つということが確立されています。唯一の例外はPraosネットワークが正常でない場合です。

深刻なネットワーク障害が発生した場合は、災害復旧計画を実行することが正当化されます。障害復旧計画は、関係者間のオフチェーン協力によって、停止期間内にチェーンを書き直し、誠実なチェーンを修復する必要があります。その後、Genesisルールにより、やはり誠実なチェーンが有利になります。

しかし、障害復旧計画の実行は、本質的に困難でコストがかかります。少なくともその間、単純なチェックポイントメカニズムを使用すると、ブロック生成停止中またはその直後に、警戒心の強いステークプールオペレーターからなる十分な規模のサブセットが協力して、迅速かつ容易にネットワークの制御を維持します。

ロジックは単純で、他のプロトコルと一貫しています。ブロック番号とハッシュペアのリストを指定する設定ファイルがあり、それぞれが同じブロック番号を持つ他のブロックを無効として処理します。チェックポイントの構成データは慎重に使用し、信頼できるソースからのみ取得する必要があります。理想的には復旧計画の最終的な実行によって、チェックポイントリストへの事後的な追加を一時的なものとすることが許可(さらには要求)されます。唯一の永続的なチェックポイントは、Byron期のジェネシス鍵がCardanoチェーンとはもはや無関係であることを保証するセットです。

LOE

台帳ピアは効果的にエクリプスを防止することから、同期中のノードは、少なくとも1つは健全なピアがあり、誠実なチェーンを保持していると仮定できます。したがって、同期中のGenesisノードが台帳ピアのチェーンの交差点を超えてチェーンの2,160を超えるブロックを選択することを禁止するだけで、安全性が直接確保されます。すべての台帳ピアが同意するブロックのみを選択します。これには、ほぼ確実に誠実なピアが含まれます。この制約はLOE(Limit on Eagerness:熱意の制限)と名付けられています。これは、同期中のノードがこれまでに確認した最良のブロックに熱心にコミットしてはならないためです。敵対的なピアは、任意の誠実なピアがこれまでのブロックを処理するよりもはるかに速く代替ブロックを処理できる可能性があります。

GDD

攻撃者がLOEを悪用して被害者にブロックの同期を停止させ、同期中のノードの活性プロパティを妨げるのは簡単です。これには、次の3通りの方法があります。

  • 攻撃側のピアが、ブロックは尽きたと主張する
  • 攻撃側のピアが代替チェーンを提供する
  • 攻撃側のピアは、代替ブロックがあると主張するが、これを提供しない

Genesis論文による基本ルールは、前の2つを直接緩和します。2つのピアが異なるチェーンを処理していて、少なくともそのうちの1つが交差後に2,161ブロック以上ある場合、Genesisは、2つのチェーンの交差後のスロットの固定ウィンドウにより多くのブロックがあるチェーンを優先します(その比較では常に誠実なチェーンが勝ちます。共有プレフィックスは、チェーンの1つが単に別のチェーンの延長であっても、チェーンの交差を反映していることを思い出してください)。Genesisノードは、他のピアから切断することで、誠実なチェーンを支持します。この現象は、GDD(Genesis density disconnection:Genesis密度の切断)として知られます。十分なGDDの後、残りのピアの交差点は、誠実なチェーン履歴に沿ってさらに遠くになります。

LOP

3番目の攻撃ベクトルは分析が最も困難です。ピアがより多くのブロックを持っていると主張しているため、GDDは無効になります。つまり、より多くのブロックを処理するためにより多くの時間が許可されている場合、その固定ウィンドウ内のブロック数が増加すると主張します。同期中のノードが実際にすべての誠実なブロックを持つまで、誠実なピアは常に純粋にその主張をします。しかし、攻撃者の仲間は、悪意を持ってその主張をすることができます。LOP(Limit on Patience:忍耐の制限)は、より多くのブロックを持つと主張するピアが実際に、また迅速にそれらを送信しなければならないようにします。重要な問題は、誠実なピアでさえ、何時間も完璧な応答性を維持できないこと、時にレイテンシーバーストが発生することなどです。 このため、LOPは各ピアのリーキーバケットとして実装されています。ここで、漏洩はブロックの処理速度であり、ピアがブロックを要求していて、ある程度の余裕のある最小速度よりも遅い速度で処理していますが、誠実な各ピアのバケット容量は、健全な台帳ピアから通常予想されるレイテンシーのバーストを吸収するのに十分な大きさになります。

Genesisステートマシン

Genesisノードは追いついたと判断した場合、LOE、GDD、LOPを無効にします。これには2つの重要な理由があります。まず、Praosネットワーク内で追いついたノードは、基本的に、選出されたスロットで可能な限り最良のブロックを作成する必要があります。たとえば、そのようなノードがまだGenesisルールを使用している場合、強力な攻撃者は潜在的にLOEを悪用して、被害者が作成したばかりのブロックを選択することを一時的に禁止することによって、それがネットワークに伝播するのを防ぐ可能性があります。このようなベクトルからのシステム全体の降下をバインドするのは難しいので、同期していないときはいつでもGenesisノードはPraosノードとまったく同じように動作する必要があります。

第2に、追いついたノードはエクリプスに対して脆弱ではないため、同期中のノードほど多くのピアを必要としません。したがって、すべてのノードが水増しされた台帳ピア数を維持しているため、ネットワークに大きな負荷がかかることは不要であり、望ましくありません。Genesisステートマシンは、自身が追いついていると見なすかどうかの間のノードの遷移を管理します。

追いつくと、ノードはLOE、GDD、LOPを無効にします。 ノードは、次の条件が満たされた場合に追いついたと結論付けます。

  • 十分な台帳ピアがある
  • すべてのピアが追加のブロックを持たないと主張している(適切に調整されたLOPにより、迅速に実行する必要がある)
  • ノードは、ピアのチェーンの中から最適なものをすでに選択済み
    これは、ローカル選択の経過時間などを信頼するよりも確実です。攻撃中のピアがこのようなしきい値をトリガーして、攻撃対象の防御を早期に低下させる可能性があるためです。

ノードは、チェーンの先端が古すぎると同期に戻ります(20分など)。これは特に、デバイスが一定時間スリープした場合(ユーザーがノートパソコンの蓋をしばらく閉じた場合など)に、ノードのオペレーティングシステムプロセスの有効期間中に発生します。

次のステップ

上記の設計は、ここ1年ほどで安定しています。まだわずかに進化していますが、大きな変化はありません。IOGはこの数か月間、Tweagと協力して実装とテストを行ってきました。

Genesis対応の最初の実装は、2024年の第3四半期までにリリースされる予定です。この段階で、最大の未知数となるのは、エクリプスを防ぐために不可欠なピア数の増加を補うために必要な最適化の程度です。

それまでは、ブートストラップピア設計がGenesisに向けた増分として機能します。ブートストラップステートマシンは、Genesisステートマシンを単純化したバリエーションです。同期中、ノードはブートストラップピアとのみ通信し、ブートストラップピアはすべて信頼できるため、LOE、GDD、LOPは不要です。対照的に、Genesisでは、同期中のノードがエクリプス状態にない限り(すなわち、ピアの1つが誠実である限り)、信頼できないピアを安全に含めることができます。これにより、ブートストラップピアの廃止が可能になり、ノードの同期と、Ouroboros Genesisの約束を果たすためのインフラが分散されます。

執筆協力:Neil Burgess