ブリッジとファイナリティ：Ethereum

Jump Crypto和訳
2023年3月4日
By John

マージ後のEthereumのコンセンサスプロトコルは、2つの異種プロトコルの合成を伴うため、クロスチェーンを構築する際に開発者が考慮すべきデザインスペースが広く存在します。このシリーズの最初の投稿で述べたように、クロスチェーンアプリケーションが設計しなければならないコアトレードオフは、復帰リスクと レイテンシーの間のものである。以下では、各ステージについて、経験的な考察、攻撃対象の特徴、参考文献を紹介することで、このトレードオフがどのような位置づけにあるのか、有意義なイメージを提供したいと思います。

おもちゃのような図解：チェーンによって、復帰リスクとレイテンシーのトレードオフ曲線は異なる

導入

Ethereumのコンセンサスモデルやその開発の歴史はよく知られているので、この記事では主要な概念について知っていることを前提に説明します。この記事では、Ethereumのコンセンサスのコアコンポーネントを簡単に説明しますが、クロスチェーン開発のフィールドガイドとして、レイテンシーの分布やプロトコルのある段階で予想される復帰率を簡単に参照できるようにすることを目的としています。

非常に高いレベルで、Ethereumのコンセンサスは、2つの独立したメカニズムを通じて、正規のチェーンの見解を証明し、決定しながらブロックを生成する一連のステークバリデーターに基づいています。最初のメカニズムは、LMD GHOSTと呼ばれるフォーク選択ルールで、非同期のブロック生産と投票から生じるブロックの曖昧なツリーを解決する方法をフルノードに提供し、バリデータがどのチェーンの上に新しいブロックを提案するかを決定できるようにしています。ブロック生成スケジュールのチェックポイントでは、より長い時間スケールで動作するBFTメカニズムであるCasper FFGが、バリデータ全体の投票ラウンドを開始し、2/3のハード閾値を通過する必要があります。Casperコンセンサスが達成されると、ツリーはチェックポイントまでの単一の正規のチェーンに「刈り込まれ」、ツリーは進行し続けています。

前回の記事で述べたように、ファイナリティとブロック安全性の保証（より一般的には）は、チェーンの特定のビューにのみ意味があります。修飾語が与えられていない場合、通常、暗黙の前提として、フルノードの視点に立っていることになりますが、すべてのブリッジ設計がこの仮定に準拠しているわけではないので、ここでこのことを明示したいと思います。これから説明する「ライフサイクル」はフルノードの視点に特化したものであり、これは重要な違いです。

ブロックプロポーザル

ランダウン

ブロックプロポーザルは、ネットワークを監視している全ノードにトランザクションが（コンセンサスの観点から）初めて見えるようになるもので、最終的にチェーンに含まれることになる最初の意味のある兆候を提供します。即時確認に近い確認は、ブリッジトランザクションが持つべき魅力的な特性であることは明らかです。しかし、これには極めて低いセキュリティ閾値が伴うため、UXや安全性にとって復帰が取るに足らないアプリケーションにのみ使用することが適切です。

レイテンシー

理想的な条件下では、プロポーザルは毎スロット、つまり12秒ごとに出てくることになります。しかし、スロットスケジュールは一定ですが、これは実際に新しいブロックを見ることを保証するものではありません。なぜなら、あるスロットの提案者が実際にはブロックをリリースしないこともあり得るからです。

敵対的な条件下で、連続するN個のスロットのブロック生成を遅らせるには、攻撃者はそれらのスロットの提案者を妥協しなければなりません。攻撃者がスロットの提案者を直接所有することでしかこれを達成できないモデルを考えた場合、攻撃者の賭け金の関数としてその確率は二項分布に従いますが、Nが大きくなると指数関数的に減少します。しかし、他のケースとして、攻撃者が第三者の提案に賄賂を送ったり、DDOSをかけたりするケースを考える必要がありますが、これはきれいに記述したり仮定したりするのが難しいため、この確率の上限を決めるのに使える明確なモデルがありません。

ネットワーク障害やノード管理の不備など、一過性のものである可能性が高い一方で、多くのバリデータが使用するクライアント実装にバグがある場合、ブロック提案の失敗が相関的に発生することがあります。しかし、これはマージ前のことであり、クライアントの多様性はその後改善され、この種の相関的な失敗の可能性は減少していることに留意する必要があります。

ここでは、マージ発生以降に観測された提案ブロック間のスロット遅延の分布について簡単に説明します：

統合後のフルノード履歴をアーカイブした結果

リベンジリスク

ブロック提案の段階はバリデーターの認証が行われる前に行われるため、この時点では、提案された最新のブロックがGHOSTによって選択されたチェーンに入るか（あるいは正規の先頭として始まるか）、ましてや最終的なチェーンに入るかどうかもわからないため、次のセクションで説明するフォークチョイスルールに基づく復帰リスクに直面します。この段階に特に関連するリスクは、悪意のある提案者からの二重提案です。X%の賭け金を持つ攻撃者が、あるスロットの提案者をコントロールする確率は、もちろんX%に過ぎません(ただし、賄賂を受け取るという局所的に合理的な決定をする検証者の割合を考慮する方がよいでしょう)。

実際には、ビーコンチェーン上で提案者のイコライジングは十数件以下であり、これらはすべて実際にマージを開始する前に発生しています（ここに掲載したのは、公開日現在で発生した最後の1件です）。この割合は極めて低いが、攻撃者が二重提案するためのコストはもちろん、1人のバリデータの賭け金である32ETHが上限であることを念頭に置いておく必要があります（それが孤立した出来事であれば、もっと低くなるでしょう）。

ブロックプロポーザルで確認されるトランザクションは、それが元に戻ってもプロトコルやそのユーザーに害を及ぼさない場合に限られるべきです。ブロックプロポーザルでブリッジトランザクションを安全に確認できる可能性があるユースケースは、クロスチェーン電子メールなど、直接的または暗黙的に大きな価値を持たないサービスです。より一般的には、ブリッジトランザクションで証明する状態がコントラクトレベルで不変であることが保証されている場合（ただし、この仮定を確認することには極めて慎重であるべき）、証明する状態は依然として有効であるため、証明内容が元に戻されても害はありません。

GHOSTチェーンへの組み込み

ランダウン

連鎖に含まれるとは、具体的には LMD GHOST アルゴリズムを適用して選択されたフォークに含まれることを意味します（これは Casper で最終性を達成するための前提条件です）。このフォーク選択ルールでは、提案されたばかりのブロックが必ずしもチェーンの先頭になるとは限らないので、これはブロック提案よりも強い条件であり、たとえ最初はそこにあったとしても、ブロックの生成と合意の進展に応じて後で元に戻すことができることに注意が必要です。

GHOSTによってフォークが選択されたからといって、それが元に戻らないという保証はありませんが（チェーンのローカルビューに適用されるルールに過ぎません）、関心のあるブロックに根ざしたサブツリーが認証の重みを蓄積するにつれ、それが最終的に最終化されるという確信を強めることができます。これは、前回の記事で説明したNakamotoプロトコルにおけるブロック確認の数を数える方法とほぼ同じです。

このプロセスでは、ブロックが戻されないという絶対的な確信が得られるポイントはありません（実際、主観的なヒューリスティックに任せるのではなく、イーサリアムは「ファイナリティ」の判断をCasperに委ねています）ので、この段階でのレイテンシとリバーシのトレードオフは、ブロックのサブツリーの重さに応じた勾配に従うと考えてよいのです。

レイテンシー

繰り返しますが、フォークを選択した場合のチェーンの進行には、質的に新しい保証を提供する特定のポイントが存在しないため、レイテンシーを測定するための特に意味のある条件はありません。あるサブツリーについて、認証の重みが所定の割合に達するまでの予想時間に興味があるなら、その重みが蓄積される速度について大まかに理解しておくとよいでしょう。バリデータは委員会の予定スロットに従って投票を行うが、これはエポック内の32スロットで均等に分割されるため、サブツリーがバリデータ集合の総投票重量の1/32を獲得するには、最低1スロット（12秒）かかることになります。これは、競合するフォークが現れなければ、一定の速度で進行します（各スロットの委員会の参加率に依存する）。

リベンジリスク

一般に、LMD GHOSTの下で攻撃者が復帰を引き起こす方法は、あるスロットの提案者を制御してその提案を保留し、後にいくつかの正直なブロックを復帰させるフォークを公開し、そのフォークに自分の認証の重みを投じるというものです。単純な攻撃だけを考えると、あるサブツリーがすでにN個の認証を得ている場合、攻撃者はそのサブツリーからネットワークをフォークするために、同じ認証の重みを持つ必要があります。

Avalanche攻撃のような定式化から得られるハイレベルな教訓は、攻撃者が公開のタイミングと生成する代替フォークの構造によって、ステークウェイトでより深い復帰を達成できるということです。このように、ブロックの復帰の難易度はサブツリーの認証重量とともに明らかに上昇しますが、これに正確な価格をつけることは困難です。

Ethereumのフォーク選択ルールには、証明書を曖昧にするバリデーターを無視したり、タイムリーに提案されたブロックに特別な重みを与えるプロポーザーブーストなど、こうした攻撃の可能性を低くする修正が多数施されていますが、攻撃の成功に必要なパラメータの正確性はかなり曖昧なままです。

ネットワークの非同期性やクライアントの分割によって、誠実な検証者の間でもブロックの再置換が起こることがありますが（ここでは、コンセンサスクライアントの更新を部分的に採用したために、マージ前に起こった7ブロックの再置換について説明します）、イーサリアムのPoSコンセンサスは「偶然の」再置換を生み出す状況を防ぐのに非常に有効で、これまでのところ、Proof of Work体制よりずっと安定していることが証明されています。

フルノードでは、マージ以降、約 90 のチェーンの再編成を経験しましたが、いずれも1ブロックより深く戻すことはありませんでした。繰り返しになりますが、これを軽率に事前情報として受け取り、特に攻撃者に特定の報酬がある場合は、より深い復帰は起こり得ないと考えることは重要です。検証者の認証の重みが51%になり、素朴な攻撃ができなくなったとしても、サブツリーを元に戻せないという正式な保証はありません。クロスチェーンアプリケーションでは、二重消費攻撃（元に戻すことで達成される）のリスクを特に重要視しなければなりません。

ここでもう1つ重要な考慮点は、ブリッジトランザクションには独自のMEVが含まれる可能性があるため、攻撃者がチェーンの再編成を試みる余分な誘因となる可能性があることです。したがって、クロスチェーンアプリケーションの設計者は、一般的なケースでGHOSTによるブロック再作成のリスクだけでなく、そのプロトコルが生成するトランザクションが、攻撃者にとって（それ自体）ブロックを狙うインセンティブになる可能性も考慮しなければなりません。

これはやや二次的な効果ではありますが、最終確認前の確認は、価値を直接移転するクロスチェーン取引（二重消費攻撃を受けやすい）だけでなく、トークンの送受信を直接伴わないが、価値に対応する明示または暗黙の情報を伝える取引（例えば、クロスチェーンプールのコンポーネントが流動性に関する更新やオラクルの更新を送るなど）でも危険であるということを意味するので考慮すべきことです。

Casperチェーンのヘッド（ジャスティフィケーション）

ランダウン

Casperのもとで正当化されるブロックは、Tendermintの投票前段階の終了に似ています。検証者セットの少なくとも2/3が正直であるという仮定のもとでは（等閑視してはいけません）、最終的な候補となるのに十分な票を得た正規のブロックは1つだけとなりますが、この仮定が成立しない場合に何が起こり得るかを考えることも重要です。この段階だけでは、CasperのようなBFTメカニズムにおいて、ファイナリティの条件がどのように定式化されるかわかりませんが（この投票に関するコンセンサスを確認する追加のラウンドを必要とする）、すでに復帰に対する強い保証を提供しており、LMD GHOSTと比較して、形式的に推論することが容易です。

レイテンシー

コンセンサスが円滑に行われている場合、チェックポイントスロットはエポックごとに正当化され、32スロット、つまり6.4分となる。ランダムに選択されたブロック/スロットがある場合、これらのチェックポイントの1つに到達する時間は、0から32の間で一様に分布する16スロットの平均値を持つことになります。

しかし、Casperの全ラウンドが常にこのスケジュールに従って成功するかどうかは、バリデータセットの少なくとも2/3が有効であるかどうかに依存するため、確実ではありません。たとえ3分の1以上のバリデーターがオフラインになったとしても、それは相関する停電やチェーンを止めようとする悪意ある試みのためであり、Casperは不活性リークによってハードフォークを必要とせず、最終的に再び進行するように設計されている。したがって、最悪の場合、バリデータが大規模に停止した場合、ブロックが正当化されるまでの時間は数日から数週間に及ぶ可能性があります。この論文では、確定を遅らせることができる攻撃についてより詳細に見ていますが、GHOSTの下で長距離再オルグを効果的に行うことでCasperを混乱させるなど、多くの攻撃ベクトルは、実装されているイーサリアムのコンセンサスを実用的に修正することで再び対処できます。

リバーシブルリスク

これまでのところ、ありがたいことにバリデーターの間で大規模な合意形成が行われていないため、Casperのフォークが競合するという脅威はまだ現実のものとなってはいません。GHOSTチェーンのトップは、プロトコルのルールの範囲内で、悪意を持って行動する少数のバリデータがあれば、復帰が可能ですが、Casperは、多くのバリデータがダブルサインをする場合にのみ、あいまいな結果をもたらすことができます。

これが起こらないことをイーサリアムが保証することはできませんが、対立する2つのCasperチェーンが正常にコンセンサスに達した場合、両方のフォークで最低1070万ETH（現在のバリデータセットサイズである～50万で）が燃焼することを保証しています。しかし、価値の直接移転を伴うアプリケーションの場合、より安全な選択は、最終的なコンセンサスを達成するために別のラウンドを待つことです。

Casperファイナリティ

ランダウン

Casperの下でのファイナリティは、Ethereumのコンセンサスが提供する最も強い保証であり、正当性の上に追加の投票ラウンドを必要とします。復帰や二重支払いが本質的な脅威となるようなハイステークスアプリケーションでは、もちろん可能な限り高いレベルの安全性が要求されるはずです。

レイテンシー

ブロックが正当化されることをTendermintのプレコミットフェーズの完了に例えるなら、ファイナリティの達成はプレボーティングフェーズに似ています。しかし、Casperはこの2つの投票段階を、ある意味で「パイプライン化」している点が興味深いです。バリデーターがCasperの投票に署名するとき、個々のチェックポイントブロックに投票するのではなく、2つのチェックポイント間の移行に投票します。ブロックを正当化するプロセスは、ブロックをファイナリティするプロセスと同じもので、エポック単位で位相がずれるだけです。したがって、ブロックのファイナリティまでの待ち時間は、正当化までの待ち時間と同じ分布になり、関心のある特定のブロックから見ると、ファイナリティまでの予想時間は、正当化までの時間にさらにエポックを加えた6.4分となります。最悪の場合、正当化の場合と同じように、非アクティブリークがオフラインのバリデーターを押し出すまで待つ必要があります。

リバーシブルリスク

技術的には、バリデーターステークの重さの3分の1だけでファイナリティを戻すことは可能ですが、Casperのもとで2つの対立するフォークをうまく正当化し、さらにファイナリティを出すためには、両者が最初のイクイボーションを聞き、その後アタッカーをスラッシュしてから再びイクイボーションを出してファイナリティに至ることを防ぐために、残りの2/3のバリデーションセットを完全に分割しなければならないのです。

より現実的には、攻撃者が誠実なバリデータ間の分割に依存することなく競合するブロックを確定するためには、バリデータセットの3分の2を完全にコントロールする必要があります。最終的に、Ethereumのセキュリティは、賭けられた経済的価値と、その経済的価値が、バリデーターセットのその割合を支配することを禁止するのに十分高い閾値（ETHの現在の価格で200億ドル以上）を生み出すかどうかにかかっています。

結論

この記事では、Ethereumの現在のPoSコンセンサスプロトコルの主要な段階におけるレイテンシーと復帰リスクのトレードオフを探ってきました。次回は、Optimisticロールアップの安全性保証と、そこでのファイナリティを考慮する際に生じるいくつかの微妙な点について検討します。

原文：Bridging and Finality: Ethereum

Scalablyメディアをフォローしましょう！

Scalablyのブログをフォローして世界のWeb3 VCやアクセラレーターの最新の発信をチェックしよう！

• Scalablyブログ: https://medium.com/scalably-community
• Website: https://scalably.com/
• Twitter: https://twitter.com/ScalablyInc
• LinkedIn: https://www.linkedin.com/company/scalably
• オープンチャット「Web3.0発掘コミュニティ｜プロダクトハンター」 https://line.me/ti/g2/EirJxjb_EpajyaNUilgFWvWrysudfHcgIZVd6Q?utm_source=invitation&utm_medium=link_copy&utm_campaign=default
• プロダクトハンターJapanイベント情報 https://www.meetup.com/ja-JP/web3tokyo/