原題:「ロールアップはセキュリティを継承しますか?」
原作者: ジョン・シャルボノー
オリジナル編集: Frank、Foresight News
導入
好き嫌いは別として、Twitter では「L2」と「Rollup」のどちらが「セキュリティを継承する」のかについての議論が止まることはないだろう。
ほとんどの議論は識別するのが難しいセマンティクスの戦いですが、それをなんとか絞り込むことができれば、根底にある論点は価値があります。なぜなら、いつ、どこで、そしてなぜロールアップが意味をなすのかという問題の核心に迫るからです。
スケーラブルな L2 により L1 は不要になりますか? Solana のような L1 を L2 に変えることは可能ですか?
これらの議論は主に安全性の問題に帰着します。残念ながら、ここでの「セキュリティ」の定義は非常にわかりにくいです。私たちはこの用語を曖昧に使用することが多く、ほとんどの人は私たちが何について話しているのかについて大まかに理解していますが、完全には確信していません。ここでは、さまざまなアーキテクチャにわたってセキュリティを詳しく説明します。
流行語の定義
Rollup
以前にも使用したことがありますMustafa次の定義: 「ロールアップとは、そのブロックを別のブロックチェーンに公開し、そのブロックチェーンのコンセンサスとデータ可用性 (DA) を継承するブロックチェーンです。」
以下はJames Prestwichより一般的な定義は次のようになります。「ロールアップは、別のコンセンサス メカニズムに参加し、カスタム状態遷移関数を通じてスーパーセット状態を保持することを選択する方法です。」
どちらもブリッジを検証する必要はなく、最小限の信頼仮定でクロスチェーン ブリッジを構築できることはロールアップの主な利点ですが、それらを個別に分析することが重要です。
次のロールアップ基準を考慮できます。
ロールアップは、メイン チェーン (DA 層) 上のデータ入力に対してカスタム状態遷移関数 (STF) を実行することによって派生されるステートフル システム (ブロックチェーンなど) です。
リモート チェーンの最終確認済み状態 (つまり、ロールアップ) を導出するために使用されるすべての入力データ (つまり、完全なトランザクション データまたは状態の差異) は、メイン チェーンで確認されます。
ロールアップ状態はメイン チェーン上のデータに対して実行される状態遷移関数 (STF) から派生するため、ロールアップの有効性はメイン チェーンの有効性に依存します。次に、ロールアップ ノードはメイン チェーンのコンセンサスと妥当性を完全に検証する必要があります (または、メイン チェーンについて正直な多数決を仮定します)。
Rollup ノードは、独自の状態遷移関数 (STF) を適用することによって、メイン チェーンのコンセンサス結果に基づいてロールアップのステータスを決定します (メイン チェーンがデータ ブロックの順序と可用性を確認するなど)。
クロスチェーンブリッジ
クロスチェーンブリッジは、2 つのブロックチェーンが相互に通信できるようにするシステムです。チェーン A (ターゲット チェーン) はチェーン B (ソース チェーン) で何かが起こったことを確信する必要があり、その逆も同様です。理想的には、この通信が双方向であり、強力なセキュリティ特性 (メッセージが有効であること、ソース チェーンが取り消されないことなど) が高いものであることが望ましいと考えます。
基本的に、クロスチェーン ブリッジは、(他の典型的な人間のユーザーと同様に) 別のブロックチェーンに対する「オブザーバー」として機能します。クロスチェーンブリッジは、接続されたチェーンの状態を確認するための特定の確認ルールを実装します (たとえば、転送入力が受け入れられる前に通過する必要があるイーサリアムブロックの数など)。
従来のクロスチェーンブリッジは通常、ソースチェーンのオンチェーンコンセンサス検証ライトノードを実行します（つまり、過半数のコンセンサスによって署名されたものはすべて信頼します）。
クロスチェーン ブリッジは、完全なバリデータ ライト ノードとして機能する (つまり、データ可用性サンプリング (DAS) + 有効性/障害証明を追加する) ことにより、より強力なセキュリティ特性を提供できます。たとえば、チェーンのバリデーターは、チェーンに接続されているすべての DAS ライト ノードで実行する必要がある場合があります。これは、バリデーターがチェーンに接続されているフルノードを実行することを要求するよりも軽量な代替手段です。
ロールアップクロスチェーンブリッジは、メインチェーンの活性と再編成耐性を保持することもできます (ロールアップはメインチェーンのコンセンサスを共有する必要があるため)。
メインチェーンからブリッジ→ロールアップ
Rollup ノードがメイン チェーンを完全に検証するため、この方向は非常に簡単です。
ロールアップ ノードはメイン チェーンで発生するすべてのことを知っているため、クロスチェーン ブリッジ トランザクションがいつ発生するかを知っています。現在のイーサリアム ロールアップ フル ノードは、イーサリアム ベース レイヤー自体のフル ノードも実行する必要があります。
ロールアップ ノードは、サポートされている場合、メイン チェーンの完全なバリデータ ライト ノードを実行するように変更することもできることに注意してください。イーサリアムが次のアップグレードを完全に実装した仮定の例を考えてみましょう。
イーサリアムは、有効性証明付きのブロックを実行します (ベースレイヤーの zkEVM 研究は進行中です)。
イーサリアムは完全な DAS を実装しているため、ノードは DA をサンプリングできます。
Ethereum 実行層は、Ethereum 上の他のロールアップと同様に、そのデータを BLOB としてデータ層に公開します (たとえば、Celestia の実行層データは DA 層に公開されるため、DAS ノードはロールアップ データと Celestia 自体の可用性を確認します)実行層の);
イーサリアムは、同期委員会に依存するのではなく、完全なコンセンサスの証明を提供します（たとえば、バリデータの統合、署名の集約の改善、ZK コンセンサスの可能な証明などを通じて）。
ここで、イーサリアム ベースのロールアップのフル ノードを実行すると仮定して、有効なロールアップ チェーンをたどるには、イーサリアム自体のコンセンサスと有効性をチェックする必要があるイーサリアムの正規チェーンを理解する必要があります。
イーサリアムのコンセンサス – ライトノードクライアントは、ブロックチェーン、ブロックヘッダーとして署名されたコンセンサスを追跡できます。
イーサリアム独自の実行層 DA – ロールアップ ノードはイーサリアムの DA 層をサンプリングし、ロールアップ データとイーサリアム独自の実行層データの可用性をチェックします (DAS ノードはまだ完全なノードに関して追加の仮定を行っていることに注意してください。後で説明します)。
イーサリアム独自の状態の有効性 - zkEVM を使用すると、すべてのイーサリアム ブロックに有効性証明書が付属します。
ロールアップ ノードは、イーサリアム自身の実行層の状態の有効性と DA をチェックする必要があります。これらはイーサリアム ブロックの有効性条件であるためです。 Rollup ノードは、コンセンサス署名された Ethereum を追跡しているだけでなく、それが有効なブロック ヘッダーであることも認識する必要があります。たとえば、コンセンサスによって署名されたが無効な (大量の ETH が生成されたなど) イーサリアム ブロックを誤って追跡する可能性があります。
基本実行層自体が (他のロールアップと同様に) DA 層にデータを公開し、検証または失敗の証明を追加する場合、それは組み込みロールアップになります。
ロールアップ→主鎖ブリッジへ
メインチェーンはデフォルトではロールアップと STF のステータスを知らないため、この方向は注意が必要です (つまり、イーサリアム ノードはロールアップ ノードを実行する必要がありません)。メインチェーンにロールアップのステータスを信じさせるために、メインチェーンにデプロイされたスマートコントラクト (つまり、ロールアップの検証ブリッジコントラクト) にロールアップのロジックを実装できます。スマート コントラクトは、DA およびロールアップ状態の有効性をチェックします。
繰り返しますが、このクロスチェーン ブリッジはオプションです。メイン チェーンのスマート コントラクトは、すべてのメイン チェーン ノードにロールアップの有効性を信じさせるために使用され、これにより、良好な信頼の仮定の下で双方向の通信が可能になります。
ロールアップ、コプロセッサ、およびインテント
説明したように、ロールアップは、メイン チェーンの状態 (例: イーサリアムの状態) に加えて、独自の状態 (ロールアップの状態) も保存します。では、CoW Swap には独自の状態があり、イーサリアム状態の一部ではないのでしょうか?もしそうなら、それはロールアップのように聞こえます。そうでない場合は、「コプロセッサ」である可能性があります。
ただし、この問題も思ったほど単純ではありません。
代わりに、差別化要因は状態の永続性であると考えるかもしれません。
CoW Swap により、特定の参加者がユーザーに迅速な事前確認 (イーサリアムのブロック時間よりも速い) を提供し、バッチ処理を含む注文をコミットできる場合 - イーサリアムのバッチ処理時間はほとんどのバッチ処理時間よりも速いため、ユーザーが望んでいるのは長いため、ロールアップですか?今？
Chris Goesこのトピックは、Modularity Summit での講演で議論され、まず、意図 (インテント) のおおよその定義、「特定のシステム状態空間に対する優先関数へのコミットメント」を示しました。
部分解決 (意図の一致) とロールアップ並べ替えの類似点に注目してください。オペレーターはユーザーのオフチェーン署名メッセージを取得し、結果のデータをメインチェーンに公開します。
インテントベースのアプリケーション - 結果として生じる状態変化はオンチェーンで解決されます (たとえば、CoW Swap の例では、アプリケーションは基礎となるチェーン上にあるため、トークンはそこで引き換えられます)。
ロールアップ アプリケーション - メイン チェーンに送信されたデータを使用して、ロールアップによって生成された状態の変化を計算します。
インテント中心のアーキテクチャとロールアップ中心のアーキテクチャは、反対の方向から同様の目標を達成します。インテント中心のアプローチは、ユーザーとアプリケーションの観点からこの問題を幅広く解決し、ロールアップ中心のアプローチは、さまざまなブロックチェーンの観点からこの問題に広く対処します。
ここでは、区別の具体的な境界を設定することは重要ではありません。さらに、Rollup は実際には、オフチェーン インテント マッチングで慣れ親しんだアプリとそれほど変わらないことがわかりました。
最適な実行と優れたユーザーエクスペリエンスの提供→メインチェーンに投稿されたデータに基づいた結果の決定など、いくつかの弱い保証については、オフチェーンの参加者（ソーター対ソルバー/ポピュレーターなど）に依存します。ただし、資金を安全に保管するわけではありません。
検証可能なオフチェーン計算がますます重要になるにつれて、この 2 つの境界線があいまいになる可能性があります。
インテント ソルバーまたはロールアップ ソーターの信頼性を低くしたい場合は...
モジュラー型ブロックチェーンとモノリシック型ブロックチェーン
モノリシック ブロックチェーン (別名統合ブロックチェーン) は、一般に、すべてのコア機能 (つまり、コンセンサス、DA、実行) を垂直に統合するチェーンとして定義されます。 Solana や Cosmos Hub がその代表的な例であり、彼らは自らのセキュリティに対して全責任を負います。
DA レイヤー (イーサリアムやセレスティアなど) は、実行をロールアップにアウトソーシングするため、「モジュラー」ブロックチェーンと呼ばれることがよくありますが、これは完全に正確ではありません。また、彼らは独自のコンセンサス、DA、および実行に対して独立した責任を負います。
Celestia の実行も制限されます (転送、ステーキング、クロスチェーンなど)。同様に、誰かが Solana の上に Rollup を起動したとしても、魔法のように「モジュール式」ブロックチェーンになるわけではありません。
そのため、人々がイーサリアムやセレスティアのようなチェーンを「モジュール式」ブロックチェーンと呼んでいるのを聞いた場合、これは厳密に技術的な区別というよりも実際的な区別であることを理解してください。通常、どちらもロールアップをサポートするためにアーキテクチャを最適化しています。これらのロールアップは、その範囲内で取引執行の大部分を処理すると予想されます。
Rollup でさえ、必ずしも完全に「モジュール化」されているわけではありません。Rollup シーケンサーは、メイン チェーンが操作を実行する前に、トランザクションの順序付けについて合意に達し、DA を提供し、トランザクションを実行できます。これは、ユーザーが事前確認を取得する方法です。次に、メイン チェーンは別の「最終」コミットメントを提供し、ロールアップ トランザクション シーケンスに関する DA とコンセンサスを再度示します。
ロールアップと「統合チェーン」
ここでの目的では、より重要な区別は「ロールアップ」か「非ロールアップ」です。チェーンの最終状態は、別のメインチェーン (つまり DA レイヤー) にパブリッシュされたデータから生じますか?
私たちは今日、DAS と有効性/障害証明を従来のロールアップと関連付けていますが、これらは論理的に異なる概念であることに注意する必要があります。理論的には、任意の「統合チェーン」(典型的な Cosmos アプリケーション チェーンなど) は、イーサリアムなどの他の外部メイン チェーンにデータを公開せずに、DAS と有効性証明を追加するようにアップグレードできます。ノードは個別にサンプリングしてチェーンのプルーフを確認します。
ヴィタリックの「終盤「（『エンドゲーム』は）この違いについて次のように語っています。
「従来の大きなブロックチェーン」（統合チェーン）に DAS + 有効性/失敗証明を追加すると、最終的には「安置されたロールアップ」のように見える可能性があることに気づくかもしれません。同様に、「スケーラブルで支配的なロールアップ」は非常に成功するため、ロールアップに対応するためにメイン チェーンとマージするだけになる可能性があります。
境界線は限界に達すると曖昧になります。
したがって、DAS + 有効性/障害証明が最終結果であると信じている場合、ある種の「ロールアップ」は避けられません。上の図の 2 つのアプローチには明確な違いがあります。
「モジュール化」とも呼ばれる「ロールアップ」 - 論理的に独立したチェーンを構築し、データをメイン チェーン (DA 層) に公開し、メイン チェーンのコンセンサスを再利用します。
「統合ブロックチェーン」は「モノリシックブロックチェーン」としても知られており、独自のコンセンサスを持つプロトコルにすべてを統合し、別のメインチェーンにデータを公開しません（DA層と実行層がある意味論理的に独立している場合でも）共有契約の一部）;
このレポートで「ロールアップ」について説明する場合、前者を指します (つまり、DAS + 有効性/失敗証明を備えた統合チェーンではなく、組み込みロールアップと呼ばれる可能性があります)。
「従来の」Rollup は DAS や証明を独占していません (つまり、統合された大規模なブロックチェーンがそれらを追加できる) が、ここでは多くの技術的な詳細を無視していることに注意してください。また、Solana を選んで決めることはできません。」ああ、今日 DAS を追加すると思います。」
これには、イーサリアムとセレスティアが行っていることに近づき始めるために、プロトコルの根本的なリファクタリングが必要です。
DAS をサポートするためにデータのエンコード方法を変更すると、ブロックのエンコードと伝播速度が遅くなり、従来の DA レイヤーに近づき始めます。
このため、チームが次のものを構築しているのを見てきました。
専用 DA レイヤー (イーサリアムの Danksharding、Celestia など) - 低速ブロック + DAS。
共有シーケンサー (Espresso、Astria、さらには Solana など) - 実質的には単なる高速 DA レイヤーであり、DAS は必要ありません。
ただし、高速ブロックと DAS のタイミングが離れていれば、必ずしも互換性がないわけではありません。たとえば、Solana のようなチェーンが 2 つの異なるパスを提供していると想像できます。
高速パス - トランザクションの実行を継続し、できるだけ早くデータを伝播します (現在と同様)。
スロー パス - 非同期でサンプリングできる方法で事後データをエンコードし、DAS ノードがコンセンサスからわずかに遅れていることを保証します。
アナトリーのポッドキャスト話し合うEclipse が Ethereum、Celestia、Solana をどのように統合するかを見ると、もう一方の端に目を向けると、データをサンプリングできるようにする前に、DA 層がより高速なパスを追加していることが想像できます。
同じ基本層プロトコルで 2 つのパスを提供すると、高速な共有順序付けが効果的に内部化され、ロールアップに基づいた興味深い設計が可能になります。現時点では、これはまだ非常に模索的なアイデアであることに注意してください。
ルールの確認
この背景知識を活用して、これらのさまざまなアーキテクチャのセキュリティ特性を分析し始めることができます。
まず、ノードは確認ルールを実行してブロックチェーンと対話します。
「確認ルールとは、特定のブロックが確認されたかどうかを出力するノードによって実行されるアルゴリズムを指します。この場合、主にネットワーク同期と正直なシェアの割合を含む特定の仮定の下で、これらの条件が満たされた場合、ブロックは決して再編されないことが保証されている。」
特定のチェーンには、任意の数の検証ルールを含めることができます。
ビットコイントランザクションが確認されるまでに何ブロック待つ必要がありますか? 1? 6? 10?
LMD GHOST を使用してイーサリアムの利用可能な台帳に基づいてブロックを確認しますか、それともファイナリティ ガジェット (Casper FFG) が確認するのを待ちますか?
各ブロックを直接検証するフルノードを実行しますか、それともコンセンサス署名をチェックするライトノードのみを実行しますか?
インフラに聞いてるだけですか？
各確認ルールは非常に異なる仮定を行う可能性があるため、同じチェーンと対話する場合でも、非常に異なるセキュリティ特性を持つ可能性があります。
違いは微妙ですが重要です。
セキュリティ = セキュリティ + アクティビティ
次に、Rollup がメインチェーンから「セキュリティを継承」するかどうかを詳しく見てみましょう。
おそらくより明確に言うと、ロールアップはメイン チェーン内の何かを「継承」するのではなく、常に「レンタル」し、消費されたリソース (DA) に対して継続的なコストを支払い、どちらかの当事者が関係を終了することを選択できます。しかし、それは質問の興味深い部分ではありません。
セキュリティ、これからはセキュリティに重点を置いていきます。アルゴリズムのセキュリティは、安全性と生存性で構成されます。
安全性 (何も悪いことは起こりません)、2 つの機能するノードによって決定される最終状態は決して競合しません。
ライブネス (最終的には良いことが起こります)、すべての機能中のノードは、含まれるトランザクションに適した新しい状態の反映を完了するまでの時間が限られます。
Sreeram の優れた使用法フレームをさらに、確認ルールの安全性を保証する 5 つのプロパティに分解できます。
DAS + 妥当性/失敗証明を備えた仮説的な統合チェーンの例を考えてみましょう。そのデータは他の外部メインチェーンには公開されません。簡単にするために、即時ファイナリティ (Tendermint など) を想定しているため、使用可能な台帳と最終的な台帳 (イーサリアムのギャスパーなど) の間に使用可能な違いはありません。
さまざまなタイプのノードを使用してチェーンを追跡するために使用できる 3 つの確認ルールを検討します。
コンセンサス検証ライト ノード - コンセンサスの証拠を検証します (つまり、正直な多数派のコンセンサスを信頼します)。
完全なバリデータ ライト ノード - コンセンサスを検証 + DA をチェック (DAS を使用) + 状態の有効性を検証 (有効性/障害証明を使用)。
フルノード - コンセンサスを検証し、DA (すべてのデータをダウンロード) と有効性 (すべてのトランザクションを実行してステータスを計算) を直接検証します。
ルールにはセキュリティ属性があるが、チェーンにはセキュリティ属性がないことを確認します。
この点をもう一度強調すると、「私たちは口語的にチェーンが安全であると話しますが、実際には、それはセキュリティプロパティに付加された検証ルールです。」
いくつかの例を見てみましょう。
CAP定理
背景としては、CAP定理両方の条件を同時に満たす台帳は存在しないと教えてください。
適応性 (別名動的可用性) - 動的に参加してもアクティブな状態を維持します (つまり、ノードの大部分がオフラインの場合)。
ファイナリティ (別名一貫性) - ネットワーク分割下で安全を維持します。
コンセンサスプロトコルは多くの場合 2 つの部分に分かれており、それぞれが上記の条件のいずれかを満たします。
最長チェーン プロトコル - これらのプロトコル (ビットコインのサトシ コンセンサスなど) は、アクティブに参加しているノードの数が変動する (つまり、適応的である) 場合でも生存性を保証しますが、ネットワーク分割の下では安全ではありません (つまり、ファイナリティがない)。
BFT タイプのプロトコル - 古典的なコンセンサス プロトコル (PBFT など) はファイナリティを実現しますが、適応性は実現しません。
ビットコイン確認ルール
ビットコインのコンセンサスは、厳密な経済的最終決定を提供するものではありません。
ノードはローカル ビューで最長のチェーンを観察し、各ユーザーは好みの確認ルールを自由に適用できます (例: k 件を超える確認を持つブロックを受け入れる)。標準は 6 ブロックの確認を待つことですが、それはあなた次第です。
より高額な取引の場合は、より長く待つのが合理的です。待ち時間と安全性（つまり再編成の可能性）の間にはトレードオフの関係があります。
イーサリアムの確認ルール
イーサリアムのPoSコンセンサス（Gasper）は、一見するとCAP定理を回避しているように見えます。ただし、ネストされた台帳が 2 つ含まれているため、両方のプロパティが実装されます。
動的に利用可能な台帳 - ネットワークが分割されていない場合、動的に参加する安全かつアクティブな台帳。
完成したプレフィックス台帳 - 常に安全で安心です。ネットワークが分割されておらず、十分な数のノードが参加している場合、ネットワークはアクティブのままになります。
Gasper は、「引き潮」 (引き潮、二重元帳または二重確認ルールとも呼ばれる) プロトコル ファミリに属しています。二重元帳設計は CAP 定理の範囲外です (つまり、単一の確認ルールを前提としています)。ネットワークが分断されると、最終的な台帳は適応型台帳よりも遅れますが、ネットワークが修復すると追いつきます。
これにより、適応性と最終性の間のトレードオフを、システム全体のレベルではなくユーザー レベルで対処できるようになります。これは、ブロックチェーン CAP 定理によって提案された「チェックポイント最長チェーン」プロトコルの機能であり、ユーザーが適応性と最終性を信頼できるようになります。これらのプロトコルは、システム全体のレベルにそれを課すのではなく、個々のユーザーにファイナリティと適応性の間の選択を提供します。
Gasper は、上記の 2 つの台帳にマッピングする 2 つの異なる確認ルールを明示的に公開します。
動的に利用可能なルール - 適応性が保証されています。最も長いチェーンのブロック ヘッダーを尊重します。LMD GHOST最も重いサブツリーを決定するために使用されるフォーク選択ルールです。
ファイナライゼーション ルール - ファイナリティを保証します。ファイナリティ ガジェットによって確認されたブロックを尊重します。Casper FFGこれは、フォーク選択ルールに適用される最後のガジェットです。
論文で説明されているように:
「より楽観的な適応ルールは、より保守的なルールによって最終としてマークされたブロックを常に確認し、変数参加レベルの間はさらに多くのブロックを確認する可能性があります。クライアント (ユーザー) は個人の好みに基づいて確認ルールを決定します。ブロック間でローカル選択が行われ、マイナーはこれに従います。」これら 2 つの確認ルールと一致するブロック提案ルールを修正しました。」
これにより、システム内のすべての (正直な) ノードは次のことが可能になります。
共通のブロック提案メカニズムに従います。
ただし、ノードごとに異なる確認ルールを選択できます。
バリデーターは、参加の有無に関係なく、最長のチェーンを拡張し続けます (常に増加する高さで新しいブロックをマイニングします)。しかし、新しいチェックポイントは十分な参加がある場合にのみ発生します。
最も長いチェーン (最新のチェックポイントを含む) は、異なるチェーン間で切り替えることができます (つまり、未処理のブロックを再編成する) が、チェックポイントはネットワークの状態 (つまり、ファイナリティ) に関係なく単一のチェーン上にあることが保証されます。
ユーザーのセキュリティは、ユーザーが従う確認ルールによって決まります。迅速なブロック確認とより強力なセキュリティ保証の間にはトレードオフがあります。コーヒーを販売するユーザーはセキュリティよりもアクティビティを好む可能性がありますが、ヨットを販売するユーザーはアクティビティよりも安全を好む可能性があります。
イーサリアムノードが実用的な目的に適用できる他の中間確認ルールのヒューリスティックもいくつかあります。ビットコインのように適応確認ルールとして単純な k ブロックを使用するのではなく、ネットワーク同期と検証者の誠実さに関する仮定を含む他のヒューリスティックを追加できます。
まさにこれですよ」イーサリアムコンセンサスプロトコルの確認ルール》では、次の特性を持つ確認ルールが提案されています。
理想的な条件下では、ルールはスロットの直後に新しいブロックを確認します。
典型的なメインネット条件下では、このルールはほとんどの新しいブロックを 1 分以内に確認できるはずです。
この確認規則は経済的最終性の代わりとなるものではありません。むしろ、これは、ネットワーク同期が近い将来に維持されると信じているユーザーに有用なヒューリスティックを提供します。 2 つを比較してみましょう。
いくつかの例を考えてみましょう。ヨットを ETH で 250 万ドルで販売する入札をしたとします。考えられる確認ルールは次のとおりです。
完全なノード + 最終結果を待機 - 悪意のある大多数のバリデータであっても、無効なブロックを受け入れるように騙すことはできません (偽の ETH の生成など)。彼らが ETH で 250 万ドルを支払い、後で完成したブロックを再編成しようとすると、莫大な費用が発生することになります (少なくとも賭け金の 3 分の 1 は懲罰的に削減される可能性があります)。
フルノード + ブロックを待機 - ほとんどの悪意のあるバリデータは、依然としてユーザーをだまして無効なブロックを受け入れることはできませんが、有効なブロックで 250 万ドルの ETH を送信し、ヨットに残し、ブロックを即時再編成する可能性があります。十分なステークウェイトがある場合、またはネットワーク状態が劣悪な場合は、削減による罰を受けない可能性があります。
ライトノードクライアント - 悪意のある同期委員会はペナルティなしで嘘をつくことができ、購入者はヨットで出航することができます（この同期委員会はコンセンサスのサブセットとしてイーサリアムに固有のものであり、他のものは効率的なライトノードによってサポートされるより多くのPoSチェーンを備えていることに注意してください）クライアントは、バリデーターの数が少ない場合でも、すべてのコンセンサス投票をチェックできます)。
MetaMask - あなたは Infura を信頼していました。あなたが Infura の従業員からヨットを買った人は、週末はヨットに乗れると約束したので、彼らはあなたに嘘をつき、あなたは ETH を 250 万ドル持っていると思い込んで、そのキーを渡しました。
ロールアップ確認ルール
他のチェーンと同様に、ノードはさまざまな検証ルールを使用してロールアップと対話します。 Rollup の最も強力な確認ルールは、メインチェーンのコンセンサスとともに最終決定されます。ロールアップ シーケンサーは、ユーザー エクスペリエンスを向上させるために弱い確認ルールを公開できます (つまり、せっかちなユーザーに高速な事前確認を提供します)。ただし、ユーザーはメイン チェーン確認ルールの完全なセキュリティを待つこともできます。
一般的なロールアップ トランザクション プロセスはおおよそ次のとおりです。
ユーザーはトランザクションをシーケンサーに送信します。
シーケンサーはトランザクションを分類し、事前確認を行います。
新しいロールアップ状態を計算するために、確定的 STF が順序付けされたトランザクションに適用されます。
更新されたロールアップ ステータス コミットメントと関連トランザクション データは、最終的にメイン チェーンに公開されます。
トランザクション データがメイン チェーンに公開された後、次のようになります。
フルノードのロールアップ - 提案されたチェーン状態が正しいかどうかを直接検証します。
ロールアップ ライト ノード (検証ブリッジを含む) - 直接検証できません。
同じロールアップの異なる観察者は異なる確認ルールを使用するため、異なる時点で意見を最終決定します。
(ステータスの違いだけでなく) 完全なトランザクション データが公開されると仮定します。
前述したように、ロールアップ ノードは、メイン チェーンのフル ノードまたはフル バリデーター ライト ノードも実行する必要があります (または、コンセンサス バリデーター ライト ノードを使用して、正直な多数派の仮定を行う)。ロールアップ ライト ノードは、追加のソフトウェアとして、またはメイン チェーン ノード内で暗黙的に実行できます (つまり、メイン チェーン上のクロスチェーン ブリッジ コントラクトがロールアップを検証します)。
また、ユーザーは、メインチェーンがデータを受信する前であっても、シーケンサーの事前確認を信頼することで、トランザクションをより迅速に確認できます。シーケンサーが誤動作すると、セキュリティが失敗する可能性があります。その後、データがメイン チェーン上に置かれると (そして DA+ の有効性を確認すると)、メイン チェーンの障害 (イーサリアムの再編成など) のみがセキュリティに影響を及ぼします。
したがって、集中型シーケンサーであっても、「ロールアップ」のセキュリティが実質的に低下することはありません。必要な確認ルールに一致するセキュリティが常に得られます。ロールアップがシーケンサー ベースの設計であっても、その他の設計であっても、同じ確認ルール (メイン チェーンが完了するのを待機し、ロールアップの有効性をチェックするなど) を使用できます。適切な実装 (たとえば、メイン チェーン経由でトランザクションの組み込みを強制する) を前提とすると、他のものを同じに保ちながら、同じ時間枠で同じセキュリティ プロパティを実現できます。
同様に、ブロック時間が遅いためにイーサリアム L1 ブロックプロデューサーが事前確認を提供することも想像できますが、これによってイーサリアムの安全性が低下することはありません。 Ethereum バリデーターがより高いセキュリティを最終決定するまで、別の確認ルール (安全性が低い) を使用するかどうかを決定する必要があります。
事前確認のアイデアは、Vitalik が説明したように、Gasper の論理に非常によく適合します。
一般的な原則は、ユーザーに「可能な限り多くの合意」を提供することです。2/3 を超える合意があれば、定期的に合意に達しますが、合意が得られない場合は、合意に達する必要があります。2/3 未満の場合、新しいブロックのセキュリティ レベルが一時的に低下したにもかかわらず、チェーンが成長し続ける可能性が高いことは明らかなので、遅らせたり何も提供しない理由はありません。個々のアプリケーションが下位レベルのセキュリティに満足できない場合は、最終化されるまでこれらのブロックを自由に無視できます。
これらすべてをまとめると、すべての確認ルールが台帳の同じ状態に同時に一致する場合、「整合性ゾーン」が得られます。
ルールの確認 - セキュリティとアクセシビリティ
世界で最も評判の高いバリデーターで構成される分散型シーケンサーを信頼するのではなく、SBF によって実行される単一のシーケンサーを信頼する確認ルールを設定している場合、セキュリティが低下し、活性エラーが発生する可能性があり、再編成は安全な失敗です。
あるいは、より強力な (メインチェーン) 確認ルールが利用可能になるまで待つこともできます。したがって、他のすべてが同じであれば、信頼できないシーケンサーはセキュリティに影響を与えません。コーヒーを販売している場合はすぐに行くことができますが、ヨットを販売している場合は、メインチェーンの確認を再確認する必要があります。
ただし、誰もが実際にヨットを販売するためにこの検証ルールを使用している場合、「別個のシーケンサーを実行しているランダムな人物を信頼する」検証ルールのセキュリティが低下する可能性があることを完全に無視することはできません。正確な設計は、特定のユースケースに必要なコミットメントの漸進的レベルのバランスに基づいています。
繰り返しになりますが、これは Solana のような高スループットのブロックチェーンに対する本当の批判に触れています。実際にどのような検証ルールを使用できるのでしょうか? Solana フル ノードを実行するには適切なセキュリティ条件があるかもしれませんが、ほとんどの人は確認ルールにアクセスできない可能性があります (つまり、リソース要件やコストによっては)。
直接検証（つまり、正直な多数派を信頼するだけではない）は、これらのシステムの中核的な特性です。したがって、特定の検証ルールについては、セキュリティとアクセシビリティという 2 つの側面を重視します。
要するに：
ユーザーは確認ルールを介して任意のチェーンと対話します。
チェーンには、任意の数の確認ルールを含めることができます。
セキュリティは検証ルールのプロパティであり、チェーン自体ではありません。
私たちは、特定のチェーンの確認ルールのセキュリティとアクセシビリティを重視しています。
実際、特定のチェーンが安全であると言うとき、私たちは、それに関連する確認ルールが安全でアクセス可能であるという概念を伝えようとしています。
ロールアップと統合チェーンセキュリティ
1. DAS+ 有効性証明を備えた統合チェーン
DA と状態の有効性に関するセキュリティは、チェーンのオペレーターについて強い仮定を置くことなく、暗号化 (DAS + 有効性/障害証明) によって直接チェックできることがわかりました。どのプロトコルでも技術的にはこれらを実装できます。フルノードは、外部の仮定なしに DA と状態の妥当性をチェックすることもできます。
次に、他の属性、つまり活性度と再編成に対する抵抗力に焦点を当てましょう。前に見たように、どの検証ルールを実行しても、これらは失敗する可能性があります。 DAS+ 有効性証明+PoS シングルスロットファイナリティの統合チェーンを見てみましょう。
強力な確認ルールを選択することは、セキュリティ障害のサブセットに対して特に効果的です。この場合、悪意のあるバリデータの大多数であっても、フル ノードまたはフル バリデータ ライト ノードを騙して次のことを信じ込ませることができません。
利用できないデータも実際には利用可能です。
または無効な状態遷移が有効です。
イーサリアムに 1 つのバリデーターがあるか無数のバリデーターがあるかに関係なく、フルノードは DA またはブロックの有効性を多かれ少なかれ信頼し、チェックすることでそれを保証します。完全なバリデータ ライト ノードは、より簡単な方法でチェックできます (ただし、DAS では追加の仮定がいくつかあることに注意してください。これについては後で説明します)。
ただし、悪意のある多数決バリデータにより、台帳の成長が妨げられたり、検閲されたり、チェーンが再編成されたりする可能性があります (どのような失敗が発生するかは確認ルールによって異なります)。 DAS + ZK では救えません。再編に対する抵抗と活性化は常に、特定のチェーンのさまざまな基礎的な特性 (信頼できる運営者、経済的インセンティブ、社会的合意など) にある程度依存します。
それほど明白ではないのは、すべてのノードが上の表と同じ攻撃を受けるため、活性度と再編成に対する耐性が依然として特定の確認ルールの特性であるということです。ここでの確認ルールに関係なく、すべて同じ保証が適用されます。
ただし、単一スロットのファイナリティの仮定を取り除くと、このことが再び明らかになります。イーサリアムのギャスパーでは、どの台帳をフォローするか（つまり、利用可能な最長のチェーン台帳またはチェックポイントが完了した台帳）に応じて、再び異なる生存性と再編成耐性のプロパティを持つことになります。ほとんどの悪意のあるバリデータは、実行する検証ルールに応じてさまざまなセキュリティ障害を引き起こします。
いずれにしても、ここで重要なのは、チェーンの基礎となる構造が非常に重要であるということです。チェーンの活動を維持し、再編に抵抗するには、強力な運営者、経済的インセンティブ、社会的合意が必要です。さらに、イーサリアムなどのデュアルレジャーコンセンサスプロトコルは、ユーザーに、ニーズに基づいて可用性とファイナリティを独自に計算するための貴重な柔軟性を提供します。
2. DAS + Validity Proof Rollup を使用する
次に、この例を少し変更してみましょう。
前の例 - DAS + 有効性証明を備えた統合チェーン。今日の Solana に DAS + 証明を追加すると想像してください。
新しい例 - ロールアップは有効性証明 + DAS を備えた外部メイン チェーン (例: イーサリアム) にデプロイされます (イーサリアム DAS はまだオンラインではないことに注意してください)。ロールアップには、事前に確認されたコンセンサスを迅速に達成できる分散型シーケンサー セットがあります。
Rollup には、異なるタイムフレーム (つまり、シーケンサーの事前コンセンサスに基づいて動作するか、メインチェーンの最終コンセンサスを待つか) に応じた 2 つの完全に別個のカテゴリの確認ルールがあることがわかります。ここで、それぞれのパスを見てみましょう。
ファストパス - メインチェーンのコンセンサスが得られる前
ロールアップ ノードは、(メイン チェーンに公開する前に) シーケンサーの確認に依存することができ、次のロールアップ ノードを実行できると想定しています。
ロールアップ コンセンサス バリデータ ライト ノード - ロールアップ シーケンサー コンセンサスの正直な多数派を信頼します。
ロールアップフルバリデータライトノード - シーケンサーのフィードで DAS を実行し、イーサリアムに何かを公開する前に有効性証明をチェックします。
ロールアップ フル ノード - シーケンサーのフィードからすべてのデータをダウンロードし、すべてのトランザクションを実行して DA と有効性を直接チェックします。
技術的には、ロールアップ シーケンサーは DAS を促進し、メイン チェーンに公開する前に有効性の証明を提供できますが、実際にはこれは起こりません。フルバリデータライトノードは通常、メインチェーンを介してこれらをチェックするように設計されていますが、「ライブ」DAS+ 証明により、統合チェーンとのより明確な同一性のある比較が可能になると思います。
次の表は、統合チェーンの例と比較した変更を示しています。
チェーンのバリデータ セットを統合するのではなく、ロールアップ シーケンサーに依存して、ライブ性と再編成に対する耐性を実現します。
ここではメインチェーンのコンセンサス前の時間範囲のみが表示されるため、最終アクティビティ属性のみが削除されます (これらの「最終」アクティビティ属性は後でメインチェーンから取得されます)。
削除されたコンテンツは赤い取り消し線で表示され、追加されたコンテンツは青い線で表示されます。
遅いパス - メインチェーンのコンセンサスを待っています
追加のセキュリティのために、ノードはメイン チェーン (例: イーサリアム) からのコンセンサスを待つことができます。そして、これがより明確に機能する場所です。つまり、ロールアップ ノードはメイン チェーン ノードも実行する必要があります。
メインチェーンコンセンサス検証ライトノード - メインチェーンの正直な多数派コンセンサスを信頼します。
メインチェーンのフルバリデータライトノード - メインチェーンの有効性証明を確認し、メインチェーン上で DAS を実行します (データロールアップ + メインチェーンデータを含む)。
メイン チェーン フル ノード - すべてのメイン チェーン データ (ロールアップ データのチェックを含む) をダウンロードし、すべてのメイン チェーン トランザクションを実行して有効性を直接チェックします。
ロールアップの状態の有効性は、次の 2 つの異なるパスで検証できることに注意してください。
メイン チェーンの外側 (追加のロールアップ ノード ソフトウェアを実行) - ロールアップは、その状態や STF を検証するためにメイン チェーンを必要とせず、検証ブリッジをデプロイする必要もありません。代わりに、ロールアップ プルーフは別の方法 (たとえば、 p2p によるロールアップ証明)。これには、証明を検証するために追加のロールアップ ノード ソフトウェアを実行する必要があります (つまり、ロールアップ ライト ノード)。
メイン チェーンの内部 (メイン チェーン内にロールアップ ノードを実装) - これが今日の標準です。ロールアップ ライト ノードの検証ロジックはメイン チェーン自体 (つまり、ロールアップの組み込みブリッジ コントラクト) にデプロイされます。 validator ノードはメイン チェーン内にあり、STF 内で実行されるため、メイン チェーンの STF を検証することは、ロールアップの STF を検証することも意味します。
ゼロ知識証明可能なメイン チェーン (イーサリアム L1 zkEVM など) + すべてのロールアップがメイン チェーン内の状態を証明する場合 →特異点の証明に対するヴィタリックのビジョン。 Ethereum のゼロ知識証明を検証するということは、他のすべてのチェーンとその内部に実装された検証ノードを検証することを意味します。
話を簡単にするために、ここではロールアップの状態の有効性がメイン チェーン自体内で検証されると仮定します (たとえば、ロールアップにはメイン チェーンへのブリッジが組み込まれています)。そのため、プロトコルの外部で追加のロールアップ ノード ソフトウェアを明示的に実行する必要性は無視できます。
以前の「クイック パス」ロールアップ テーブルと比較した変更点は次のとおりです。
メイン チェーンがトランザクションの包含を強制するか、シーケンサー/認証子の置換を強制することによって達成されます。ここではこれを「最終」アクティビティと呼びます。これは、ロールアップの観点からは遅いパスですが、メイン チェーンの観点からは、これは次のとおりである可能性があります。 「リアルタイム」アクティビティとみなされます。
ロールアップと統合ブロックチェーン
これで、ブロックチェーンとロールアップの統合に関連するセキュリティ プロパティの変更が確認できます。
DA と状態の有効性 - DAS + 有効性証明が実装されている場合、チェーンが統合されているか従来のロールアップであるかに関係なく、適用可能なセキュリティ保証を提供できます。実際、今日のこれらのテクノロジーはロールアップによって支配されています。
Liveness Re-org Resistance - 統合されたブロックチェーンは、すべてのシナリオにおいてこれらを独立して処理します。逆に、ロールアップでは、さまざまな時間範囲でルールを確認する選択肢が提供されます。安全性の低い確認ルール (トラスト シーケンサー コンセンサス) を使用して迅速な保証を取得することも、より安全な確認ルール (メイン チェーンのコンセンサスを待つ) を待つこともできます。
活性と組換えに対する耐性
これらのプロパティは暗号的に保証することができず、確認ルール全体 (フル ノードを実行しているかライト ノードを実行しているかなど) であってもセキュリティ障害に対して脆弱になる可能性があります。
完全なノードまたは ZK プルーフでは、オペレーターが完全に制御を失った場合にライブネス障害や再編成からユーザーを保護することはできません。
これらの属性は、強力で分散化された事業者、検閲に耐えるメカニズム、活動を有利にする合意、再組織の高い「コスト」、強力な社会的合意などを通じて達成されます。これらを客観的に比較することは、多くの場合困難です。
事業者の分散化と社会的合意をどのように測定しますか?唯一の正解はありません。これらはおそらく、設計するのが最も難しい側面であり、実際、特定のチェーンに非常に固有のものです。
重要なのは、Rollup は再編成の耐性と活性性をメイン チェーンに委任でき、Rollup で使用される確認ルールは、同じ時間枠でメイン チェーン上で実行された場合と同じセキュリティ プロパティを持つことができることがわかります。
チェーンは、どのプロパティをどのチェーンに委任するかを選択することもでき、さまざまなタイプの「L2」アーキテクチャ (妥当性、最適化、サイドチェーンなど) がセキュリティ プロパティのさまざまなサブセットを吸収できます。例えば：
再編成に対する抵抗 - ロールアップは再編成に対する抵抗をイーサリアムに委任することができ、そのフォーク選択ルールは、イーサリアムのコンセンサスによって確認された内容に基づいて「正規チェーン」を選択することです。イーサリアムが再編されれば、ロールアップも再編されるでしょう。
Liveness - ただし、Rollup に強制組み込みメカニズムと強制オペレーター置換メカニズムが欠けている場合、Rollup ユーザーは依然として Ethereum の liveness 属性を受け取りません。
ロールアップはユーザーにロールアップからの脱出ルートを提供することもできますが、ユーザーを検閲してデポジットがロールアップに入るのを防ぐ機能も保持します (これが、たとえば Loopring の仕組みです)。一定期間経過しても入金が処理されない場合、ユーザーはロックされた資金を L1 契約から引き出すことができます。
これは、そのようなメカニズムの重要性を強調しています。
データの可用性とステータスの有効性
活性や再編成耐性とは異なり、ノードは大きなしきい値を仮定することなく (または 2 つの間のセキュリティのトレードオフを行うことなく)、DA と状態の有効性を保証できます。悪意のあるマジョリティ ブロック プロデューサーは、活性や再編成の失敗を引き起こす可能性がありますが、フル ノードやフル バリデータ ライト ノードに対して DA や有効性のエラーを引き起こすことはありません。
ただし、コンセンサスバリデータのライトノードは、当然、正直な多数決状態の妥当性と DA の失敗の影響を受けます。彼らはコンセンサスが言うことをすべて信じているだけです。 DA と状態の有効性により、セキュリティ検証ルールがアクセスしやすくなり、非常に便利になるのはこのためです。これは、従来のロールアップと、ユーザー検証をあまり重視しない大規模なブロックチェーンとの間の大きなイデオロギーの違いであることがよくあります。
一般に、セキュリティとアクセシビリティのバランスを取るために推奨される方法は次のとおりです。
DAS と有効性の証明を広く利用できるようにする。
DAS や有効性証明がない場合は、完全なノードを広くアクセスできるようにします (つまり、リソース要件が低く、実行が簡単など)。
DAS や妥当性証明がなく、フルノードが基本的にアクセスできない場合は、コンセンサスバリデータのライトノードを広くアクセスできるようにして、信頼できる正直な多数派のコンセンサスを取得します。
インフラにアクセスしてください。
実際には 2 (フルノード) が最も安全であることに注意してください。 ZK 検証は非常に簡単ですが、DAS ノードでは、フル ノードでは行われないいくつかの追加の仮定が行われます。ただし、リソース要件の一部でフル ノードとほぼ同じセキュリティを提供し、スケーラブルです。
フルノードではすべてのデータをダウンロードするだけでよいため、確実性は 100% です。すべてが揃った場合にのみ、ブロックに署名します。外部関係者についてはいかなる仮定も行われません。
DAS の目標は、リソース要件を大幅に削減 (つまり、より大規模化) しながら、フル ノードとほぼ同等のセキュリティを実現することです。この記事についてライトノードのデータ可用性セキュリティレベルの記事ではこれについて非常に詳しく説明されています。
つまり、通常は、ネットワークの同期性と、データを再構築するのに十分なノードがあるかどうかに関して、いくつかの仮定を立てます。敵対的なブロックプロデューサーがデータを差し控えた場合、たとえ少数の誠実なライトノードのグループであっても、ブロックを集合的に再構築できるはずです。また、選択的な共有開示については、敵対的なブロックプロデューサーが少数のライトノードを個別にスプーフィングできるが、集団的にはスプーフィングできないという仮定がいくつかあります。
これらの「N 個のうちのいくつか」の仮定 (たとえば、誠実な少数のノードが DAS セキュリティを保証できる) は、典型的な大まかな「N/2」の仮定 (たとえば、ブロックプロデューサーの 51% が再編成を引き起こす可能性がある) と比較して非常に有利です。ヴィタリックがいる信頼モデルこの投稿にはこれについての良い紹介があります。
一般に、DA と状態の有効性は、活性度や再編成に対する抵抗と同じように、ロールアップによって「委任」されません。 DA と状態の有効性はユーザーが直接検証できますが、他のプロパティはチェーンのコンセンサス参加者とそのインセンティブに大きく依存します。
ロールアップ証明を検証する前述の例を確認してみましょう。
Rollup の ZK プルーフを Ethereum スマート コントラクトに公開するには、Ethereum フル ノードを実行してプルーフを暗黙的に検証します。
Rollup の ZK 証明書を Rollup ライト ノードに送信して、証明書を直接検証します。
いずれの場合でも、効果は保証されています。どこを調べても、その正当性を確信することはできません。イーサリアムノードが再編成耐性や活性特性を「強制」するのと同じように、イーサリアムは実際には有効性を「強制」しません。抵抗力と活力は、誰から得られるかに大きく依存します。
詐欺チェーンに基づくロールアップを考えてみましょう。
Rollup のフォーク選択ルールは、不正連鎖によって確認された連鎖の先端をたどる→不正連鎖が再編成されれば Rollup も再編成される、というものです。
Rollup の強制組み込みメカニズムとシーケンサーの削除は、詐欺チェーン上のクロスチェーン ブリッジ コントラクトを通じて強制されます。→ 詐欺チェーンの台帳が停止すると、Rollup の台帳も停止します。詐欺チェーンがあなたのロールアップを検閲したい場合は、あなたも検閲されるでしょう。
ロールアップは、メイン チェーンと同じセキュリティ プロパティを持つ確認ルールを公開でき、これらのプロパティを最大でホスト チェーンのコンセンサスと同じ速度で受信できます (実際には、ロールアップがメイン チェーンに公開する頻度に応じて、通常は遅くなります)。 。
Rollup は、ユーザー エクスペリエンスを向上させるために、「ハッピー パス」のより緩やかな確認ルール (つまり、シーケンサー) を提供することもできますが、失敗した場合のトランザクション フォールバックは保持されます。シーケンサーが停止していても、動き続けることができます。ただし、チェーンが独自のバリデーターのセットに完全に依存している場合 (つまり、統合チェーンとして)、これは当てはまりません。
Rollup のメイン チェーンを賢明に選択すると、セキュリティ特性に特定の影響を与えます。強力な活性（台帳の成長 + CR）と再編成に対する耐性を備えたメインチェーンを利用することは特に価値があります。
期間ごとに異なるセキュリティの前提条件
簡単な例を見てみましょう。チェーン X は、既存のメインチェーンにロールアップとしてデプロイするか、独自の統合ブロックチェーンとしてデプロイするかを決定しています。
ロールアップには次の特徴があります。
ブロックタイムは10秒。
DAS ライトノードをサポート可能
生存性と再編成に対する耐性に関する「高セキュリティ」確認ルールを提供できます (分散型の信頼できるバリデータなど)。
統合ブロックチェーンには次の特徴があります。
ブロックの生成時間は 1 秒です。
DAS ライトノードと有効性証明は、統合ブロックチェーンとして起動されるかロールアップとして起動されるかに関係なく実装できます。
集中型シーケンサーの実装など - 生存性と再編成に対する耐性に関する「安全性が低い」確認ルールを提供します。
独自の分散型コンセンサスを (事前確認済みのロールアップ シーケンサー セットまたは統合されたチェーン バリデータ セットとして) 実装する場合、活性性と再編成に対する耐性に関して「中程度に安全な」確認ルールが提供されます。
以下の表は、さまざまな実装（つまり、利用可能な最も強力な確認ルールを使用）の下でユーザーが持つ可能性のある最良のセキュリティ保証を簡略化して視覚的に表現したものです。ここでは特に、生存性と組換え耐性に焦点を当てます (これら 2 つのケースではチェーンが DAS + 有効性証明のみを実装すると想定しているため)。
Rollup の「究極のセキュリティ」は、メイン チェーンが独自のブロック時間よりも速い保証を提供できないため、「リアルタイム セキュリティ」よりも優れています。シーケンサーの事前確認応答が有効な状態遷移であることを確認できたとしても、最終的に DA 層に到達する前にその最終性を完全に保証することはできません。
しかし、これまで見てきたように、ロールアップ方式で強力なメイン チェーンにデプロイすると、セキュリティを強化できます。彼らはメインチェーンの速度でセキュリティをレンタルできます。基本的に、メイン チェーン自体のコンセンサスよりも早くメイン チェーンのすべてのセキュリティ属性を取得する方法はありません。
ただし、ユーザーは多くの場合、せっかちです。したがって、ロールアップは通常、より迅速な事前確認を提供しますが、この期間中の保証は低くなります。ロールアップでは、バランスの取れたシーケンサーのデザインを選択できます。
実用的な機能性と効率性。たとえば、集中型シーケンサは高速な事前確認を提供し、運用上のオーバーヘッドを削減できます。
強力な保証。たとえば、信じられないほど分散されたシーケンサーのセットは、より優れたリアルタイムのライブ性を提供できますが、より高い運用コストとレイテンシーを犠牲にします (最も極端なケースでは、ロールアップの並べ替えを DA レイヤーに処理させるだけで、公開しないことを選択することになります)。より速いパス);
興味深いことに、時間スケールによっては、L1 ソートされたロールアップは集中型シーケンサーよりも活発ではないと主張することもできます。これまで、ライブネスをある種の「有限時間」の概念に組み込んで議論してきました。ただし、これは完全に相対的で主観的なものです。何と比べて？どのくらいの時間が必要ですか?
純粋な L1 シーケンシャル ロールアップは、L1 チャンクのレート (例: 10 秒) でのみ含まれ、周囲の世界が変化している間、それらのチャンク間の生存性は保証されません。したがって、それはベンチマークによって異なります。
ベースライン = ロールアップ内の操作の場合、L1 順次ロールアップによりライブ性が向上する可能性があります。メイン チェーンが確認されるまで、チェーン上の他の誰もコミットしてはなりません。そのため、全員が平等な立場にあります。
ベースライン = ロールアップ外の操作の場合 - ソフト事前確認を使用したロールアップにより、より良いライブネスを提供できます。事前確認は単なる無料のオプションであり、メイン チェーンの速度ではメイン チェーンの保証に戻りますが、その間は保証が弱くなります。信頼できない場合は、メインチェーンが確認するまで待ってください。イーサリアムのブロック間で世界がフリーズすることはなく、長いブロック時間の間の古い価格は多くのアプリケーションにとって受け入れられない可能性があります。
事前確認なしで「実際の」ベースのロールアップを実装しようとすると、いずれにしても事前確認が発生する可能性さえあります。参加者 (イーサリアム構築者や検証者など) が自らこのコミットメントを行うには、金銭的なインセンティブがあります。まさにこれが、イーサリアムの構築者と関係者がベース層で迅速な事前確認をどのように提供しようとしているかについて議論されている理由です。
ここで最後に重要な注意事項が 1 つあります。ロールアップ ユーザーがメイン チェーンと同じアクティビティにフォールバックできると仮定し、メイン チェーン ブロックの速度で完全に強制的に含めることができると仮定します (たとえば、ロールアップ シーケンサーが検閲している場合、メイン チェーンの次のイーサ スクエアにトランザクションを強制的に含めることができます)ブロック）。
実際には、通常、短い遅延が発生します。即時に強制的に含めることを許可すると、収益性の高い検閲 MEV やその他の複雑さが露呈する可能性があります。ただし、メイン チェーンからほぼリアルタイムの活性保証を提供できる設計もあります (たとえば、おそらく 1 つではなく複数のメイン チェーン ブロックのレートで)。
正確な時間スケールに関係なく、メインチェーンの最終的なアクティビティを吸収することは非常に強力であり、調整メカニズムとして強力なメインチェーンを使用すると、信頼できる脅威と出口権が提供されます。この信頼できる脅威自体を単に暴露するだけでは、そもそも悪意のある行為を防ぐためにそれが必要になる可能性は非常に低くなります。
たとえば、ユーザーがオペレーターを強制終了したり、強制的に削除したりできる信頼性の高いメカニズムを備えている場合、集中管理されたロールアップ シーケンサーはユーザーから自由に家賃を引き出してユーザーをロックすることはできません。これは Chris Goes ですMEV 変換にはエッジと低速ゲームのコストがかかりますプレゼンテーションで議論される一般的な領域。
もちろん、予期しない活性化が発生する可能性もあります。その場合、このバックアップ パスは再び非常に貴重になる可能性があります。
証拠はチェーンを保護するのではなく、ユーザーを保護します
これらすべてを踏まえると、特定の検証ルールについては、「ロールアップ」自体を保護するよりも、ロールアップのさまざまな「オブザーバー」(ユーザー) を保護する方がより正確であることがわかります。 「ロールアップ」のセキュリティは、単一の具体的な手段として存在するものではありません。
私たち全員がチェーンの監視者であるため、監視者の安全を確保することがもちろん最重要です。鎖は観察者が言うとおりです。安全な方法でそれを観察できない場合は、それについての「真実」を教えてくれる誰か (バリデーターなど) を信頼する必要があります。しかし、私たちは信頼したいのではなく、検証が欲しい→証拠が欲しいのです。
「証明保護チェーン」と「証明保護チェーンのオブザーバー」を区別することがなぜ重要かを理解するには、次の点を考慮してください。
ライト ノード - ロールアップ ライト ノードは、証拠があればより安全です。誰かの言葉の正当性を信頼する必要はありません。
フル ノード - ロールアップ フル ノードは、証明がある場合は多かれ少なかれ安全ではありません。ビルトイン ブリッジや証明がなくてもロールアップを開始できます (「悲観的ロールアップ」)。有効性証明の送信を開始すると、フル ノード ノードのセキュリティが強化されます。増えたり減ったりしない。
Proof は、その有効性を直接チェックできないチェーン オブザーバー (ライト ノードなど) にセキュリティを追加します。ユーザーが強力なフルノードを実行する必要がないようにしたいため、これらの認定は重要です。
ロールアップブリッジの安全性を確保した証
Rollup の検証ブリッジは非常に重要なオブザーバーです。橋の安全性は証拠によって確実に証明されています。
一般的なライト ノードと同様に、ブリッジはロールアップの有効性を直接チェックできません。正直な多数派を信頼する代わりに、私たちは証拠を持って橋を守ります。データベース A (DA 層) のコンセンサス プロトコルがデータ BLOB を並べ替えた後、検証ブリッジがデータベース B (ロールアップ) の対応する更新の有効性を独立してチェックします。
ブリッジは他のチェーンのオブザーバーであり、ブリッジによって作成されたすべての資産には、対応するブリッジの確認ルールのセキュリティ前提が常に伴います。その確認ルールのセキュリティは広範囲に影響を与える可能性があります。だからこそ、安全なブリッジを構築することが非常に重要です (あるいは、理想的には、そもそもシングルチェーンの実行をさらに拡張することで、非常に多くのブリッジの必要性を減らすことができます)。
チェーンのフル ノードを実行すると、悪意のある当事者がユーザーをだまして無効な状態遷移を受け入れることができなくなります。ただし、悪意のある当事者が異なる確認ルールを持っている場合でも、ブリッジを偽装する可能性があります。ブリッジの担保に裏付けされた資産を保有している場合、資金の裏付けがなくなる可能性があります。この意味で、デセプション ブリッジのセキュリティ障害は「伝染性」があります。
Terra に関する古い仮説シナリオを考えてみましょう。
Terra には独自のバリデータ セットがあり、そのネイティブ トークンは LUNA であり、ネイティブ UST を発行できます。
Osmosis には独自のバリデーターセットがあり、そのネイティブトークンは OSMO です。
標準の Terra ←→ Osmosis IBC ブリッジがあり、各側が他のチェーンのコンセンサス検証ライト ノードを実行します (つまり、ブリッジの各側は他のチェーンの検証セットの正当な多数派に依存します)。
ユーザーはチェーンごとに独自の完全なノードを実行します。
IBC を介してブリッジされた Osmosis 上の UST を osmoUST と呼びます。
IBC を介してブリッジされた Terra 上の OSMO を terraOSMO と呼びます。
Terra には terraOSMO があります。
Osmosis の osmoUST/OSMO プールで LP を実行しています。
Terra が崩壊すると、LUNA の価格が急落し、最終的には理論上、悪意のあるバリデーター セットの利益がステーキングされた LUNA の価値を超えることになります。Terra バリデーターは無効なブロックに署名し、次のことを行うことができます。
偽の UST をミントする → Osmosis へのクロスチェーンで osmoUST をミントし、それを使用してすべての osmoUST 取引ペアを枯渇させます (例: osmoUST/OSMO プールからすべての OSMO を引き出します。
偽の terraOSMO を鋳造 → Osmosis へのクロスチェーンで、Osmosis にロックされているすべてのネイティブ OSMO 担保を引き出して terraOSMO をサポートします。Terra 上の残りの terraOSMO はすべてサポートされなくなります。
さて、ここではセキュリティが失敗します。
フル ノード (私) - 私のフル ノードは、Terra ブロックを無効であると認識し、拒否します。Terra バリデーターは、私の terraOSMO または osmoUST/OSMO LP の位置を盗むことができません。
ライトノード (ブリッジ) - ブリッジは、Terra のコンセンサスがブロックに署名したことをチェックするだけ (有効な状態遷移はチェックしない) ため、ブロックを拒否しません。また、Terra バリデーターは、私の terraOSMO を裏付ける OSMO 担保を、osmoUST/OSMO から盗むことができます。プール内のすべての OSMO を使い果たします (価値のない osmoUST が大量に残ります)。
ブリッジは、より強力な信頼前提を備えた確認ルールを使用します。
Terra バリデーターは、完全なノードから大量の Terra 自身のアセットを盗むことはできず (騙されることはできません)、これらのブロックは拒否されます。ただし、バリデーターがコンセンサスバリデーターライトクライアント (ブリッジを含む) を偽装する可能性があるため、コンセンサスエラーがクロスチェーンアセットに影響を与える可能性があります。
これらの障害がチェーンの残りの部分に「伝染」しないことが重要であることに注意してください。つまり、障害は Terra Bridge ルートに公開されている Osmosis アセットに「伝染」しますが、Osmosis チェーン自体にはセキュリティ障害はありません。
ただし、私たちは明らかに物事の橋渡し (一般にチェーン間で通信) を行いたいと考えており、メイン チェーンでのネイティブ アセットの使用に限定されるのは良くありません。安全に通信し、チェーン間でブリッジするチェーンが必要です。
思考実験として、最も簡単な解決策は、すべてのユーザーが各チェーンの完全なノードを実行することです。これには、クロスチェーン ブリッジ自体も含まれます。一方向の埋め込みフルノード ブリッジがいくつか見られたことに留意してください。
現在、イーサリアム ロールアップでは、ノードがイーサリアム フル ノードを実行する必要があり、これらのロールアップはイーサリアムのコンセンサスを共有しています。
Namada (Rollup チェーンではなく、別の Tendermint チェーン) は、そのノードが Ethereum フル ノードを実行する必要がありますが、Namada は Ethereum のコンセンサスに同意しません (つまり、Ethereum にデータを公開したり、これに基づいてステータスを導出したりすることはありません)。
これはイーサリアムのフルノードでは機能しますが、明らかに拡張できません。すべての Cosmos チェーンを他のすべての Cosmos チェーンで完全なノードを実行するだけで開始することはできません。これらの双方向フルノード ブリッジは拡張性がなく、ハードウェア要件が増加するだけです。
幸いなことに、よりスケーラブルなオプションがあります。ブリッジをデプロイして、（コンセンサスの確認に加えて）別のチェーンの状態の有効性と DA を完全に検証できます。
状態の有効性 - IBC は現在、従来のコンセンサス証明で動作しますが、チェーン接続された有効性証明を追加するように変更することも可能で、無効な状態遷移によってブリッジがだまされることはなくなりました。これにより、ブリッジが状態遷移の有効性を検証できた場合に、Terra バリデーターのブロックを無効として拒否することで、前述の攻撃を正確に防ぐことができたでしょう。
これは、イーサリアムのロールアップ ブリッジがロールアップ プルーフをチェックする方法と非常によく似ていますが、ここでは双方向にもできる点が異なります。
DA - さらに、チェーンでは、そのノードがチェーンに接続された DAS ライト ノードを実行する必要がある場合があります。たとえば、2 つの Cosmos チェーンが、もう一方のチェーンの DAS ライト ノードを実行するために独自のバリデーターを必要とするようにすることができます (各チェーンが DAS ライト クライアントを実装している場合、これらのチェーンは現在サポートしていません)。これが完了すると、各チェーンはノード全体を実行しなくても、互いの有効性と DA を認識できるようになります。
Rollup では、定義上、メイン チェーン上のすべてのデータを所有しているため、そこにあるブリッジがそれにアクセスできます。一方、ロールアップ ノードはメイン チェーン ノードを実行します。
依存チェーンと独立チェーン
イーサリアムのロールアップを調べているロールアップ検証ブリッジのコンテキストで、5 つのセキュリティ プロパティをもう一度見てみましょう。
台帳の成長 - イーサリアム検証ツールは、Rollup の台帳を強制的に成長させ続けることができます (たとえば、トランザクションの包含を強制する)。
検閲への抵抗 - イーサリアムバリデーターは、ロールアップのオペレーターに無期限に検閲されないよう強制することができます (例: トランザクションの包含やシーケンサーの置き換えの強制など)。
再組織化に対する耐性 - 再組織化に対するロールアップの耐性はイーサリアムに関連しています。イーサリアムが再編成されると、イーサリアム上のすべてのロールアップが再編成されます。
データの可用性 - ロールアップの DA は保証されています。ロールアップは定義上、メイン チェーンのコンセンサス (ロールアップ コントラクトが存在する) によって確認されたデータから派生し、ロールアップとメイン チェーンはマージされたコンセンサスを共有し、DA はイーサリアム自体の有効性条件であるためです。データが利用できない場合、イーサリアム ブロック自体は無効です。ブリッジは、信頼の仮定を追加せずにメイン チェーン上のデータにアクセスできます。
状態の有効性 - コントラクトは、ロールアップ状態遷移の有効性証明をチェックします (またはチャレンジ ウィンドウが通過するのを待ちます)。これにより、宣言された状態更新が、メイン チェーンで確認された対応するデータにロールアップの STF を適用した有効な結果であることが証明されます。 ;
ブリッジのセキュリティは、単に非常に強力な確認ルールをチェーンに付加することによって最大化されるわけではないことに注意してください (たとえば、完全なバリデータ ブリッジを超信頼できるバリデータ セットを持つチェーンに接続する)。ブリッジがメイン チェーンと同じセキュリティを前提としている場合、チェーン間でネイティブ アセットを横断するときに最大限のセキュリティが得られます。
Vitalik は役立つ説明例を提供しています。
「100 ETH を Solana のブリッジに転送し、100 Solana-WETH を取得すると、イーサリアムは 51% の攻撃を受けることになります。攻撃者は自分の ETH の束を Solana-WETH に預け、その直後に Solana によって確認されます」イーサリアム側でトランザクションを再開します。Solana-WETH コントラクトは完全にはサポートされなくなり、おそらく 100 Solana-WETH は現在 60 ETH の価値しかありません。コンセンサスを完全に検証する完璧な ZK-SNARK ベースのブリッジがあっても、依然として脆弱です51%はこのように攻撃します。
したがって、Ethereum で Ethereum ネイティブ資産を保持するか、Solana で Solana ネイティブ資産を保持することは、Solana で Ethereum ネイティブ資産を保持するか、Ethereum で Solana ネイティブ資産を保持するよりも常に安全です。この場合、「イーサリアム」はベース チェーンだけでなく、その上に構築された適切な L2 も指します。
イーサリアムが 51% 攻撃を受けて回復すると、Arbitrum と Optimism も回復するため、Arbitrum と Optimism の状態を保存する「クロスロールアップ」アプリケーションは、イーサリアムが 51% 攻撃を受けても一貫性が保たれることが保証されます。イーサリアムが 51% 攻撃を受けない場合、Arbitrum と Optimism に対してそれぞれ 51% 攻撃を実行する方法はありません。したがって、Arbitrum の楽観主義に基づいて発行された資産を保持することは完全に安全です。
Solana を任意のチェーンに置き換えることができます。基本的に、記録台帳全体で資産を移動することについて話している場合 (例: イーサリアムからの ETH)、チェーンする際の安全性の前提条件は、イーサリアムのバリデーターよりも信頼できる仮想チェーンであっても構いません。追加的なものであり、接続されたチェーンが再編成されたり、活性化の失敗が発生したりする可能性が常にあります。
ただし、マージされたコンセンサスを持つチェーン (つまり、メイン チェーンのコンセンサスを共有するロールアップ) は、これらの追加のセキュリティ前提を回避できます。これらの異なる領域間の架橋は、バックボーン自体と同じ最終的な活性と組換え耐性特性を持つことができます。共有コンセンサスにより、この共有セキュリティ ゾーン内でのクロスチェーンの信頼の前提が最小限に抑えられます。
適切なセキュリティの前提条件を決定するのはあなた次第です。実際、大手チェーンの間で同様のコンセンサス不履行が起こったことはありません。これは明白でコストがかかりますが、弱いチェーンを接続する場合にはより強力な仮定となる可能性があります。
ロールアップ チェーンをメイン チェーンにバインドすることには、いくつかの欠点もあります。 2 つのクロスチェーン シナリオを比較してみましょう。どちらの場合も、双方向完全バリデーターを使用してチェーン間で 2 つのチェーンがブリッジされています。
依存関係 - リモート チェーン (つまり、ロールアップ) は、メイン チェーン (つまり、DA 層) のコンセンサスを共有し、メイン チェーン上のデータから独自の状態を取得します。リモート チェーンは、メイン チェーンと一緒にフォークし、それに基づいて最終状態を決定する必要があります。メインチェーン上で。
独立 - これらのチェーンには独自の独立したコンセンサスがあり、他のチェーンのデータに基づいて独自の状態を導き出しません。これらは、リモート チェーン (つまり、ロールアップ) ←→ メイン チェーン (つまり、DA 層) の関係を共有しません。それらは再び一緒に集まることはなく、お互いの活動に依存することもありません。
興味深いことに、これらには長所と短所があります。
悪い - チェーンを他のチェーンと再編成したり、ライブネスの不具合が発生したりすることは、最初は不利なように聞こえるかもしれません。あなたのチェーンが壊れているために、なぜ私のチェーンに問題が発生するのでしょうか?
良い - この相違がチェーン上で深刻な問題を引き起こす場合、これは実際に重要な利点です（たとえば、ソースチェーンからのクロスチェーンアセットが多数ある場合、クロスチェーンブリッジの観点から再編成する必要があります）裏付けのない担保を残す）、チェーンとそのクロスチェーンブリッジは相互に一貫している必要があります。
同様に、ロックインと過度のレントシーキングにはプラスとマイナスの潜在的な影響があり、中立的で検閲に強いベースレイヤーがなぜ非常に重要であるかを浮き彫りにしています。
良い - 優れたメイン チェーンは、ロールアップ オペレーターがロールアップ ユーザーから過剰な値を抽出し、終了権限を強制することからユーザーを保護できます。
悪い - 悪いメインチェーンは、価格を恣意的に値上げし、ロールアップとそのユーザー自体からその価値を引き出す可能性があります。
また、提出証明 + 共通のメインチェーンを共有する代わりに両方向で DAS を実行することには、いくつかの非効率性もあります。
ノードが他の多数のチェーン上で DAS ライト ノードを実行する必要がなくなり、新しいチェーンを手動で追加する必要がなくなります。巨大な共有 DA レイヤー上で DAS を実行する方がはるかに効率的です。
各チェーンが多くの異なるチェーンの有効性証明を双方向に検証するのは非効率的ですが、理論的には複数のチェーンにわたる証明を集約して、チェーン クラスタ全体が 1 つの証明をチェーンに公開するだけで済むようにすることは可能です。
ここにはトレードオフと利点がありますが、興味深いアセットには大きなパス依存関係があることにも留意してください。イーサリアムネイティブのアセット (ロールアップ内のアセットを含む) を大量に使用したい場合は、チェーンをイーサリアムにルートし、そのクロスチェーンブリッジは理にかなっています。
結論は
「ロールアップ継承の安全性」は適切な省略表現ですが、実際に意味する重要な点は次のとおりであることに留意してください。
Rollup は、消費するリソース (DA) の対価として、メイン チェーン (イーサリアムなど) にレンタル料を支払います。
ロールアップは、メイン チェーンと同じくらい高いセキュリティ特性を持つ確認ルールを公開できます (つまり、ユーザーはメイン チェーン自体で動作する場合と同じセキュリティ保証を得ることができます)。
ユーザーは、メイン チェーンのコンセンサスの速度でこれらのメイン チェーンのセキュリティ属性を取得します。
ロールアップ ユーザーがメイン チェーンが提供するよりも迅速な確認を必要とする場合は、一時的なセキュリティの仮定を追加する確認ルールを使用できます。
オブザーバー (つまり、ユーザー) は、確認ルールを通じてロールアップと対話します。最小限の信頼仮定を持つ検証ブリッジは、そのような (オプションですが非常に価値のある) オブザーバーです。
さて、考えてみましょう
IOS
Android