20,000語:ロールアップセキュリティの議論

もともとジョンシャルボノーによって書かれ、フランクによって編集され、フォーサイトニュース

はじめに

好むと好まざるとにかかわらず、Twitterはおそらく「L2」またはRollupが「セキュリティを継承する」かどうかについての議論をやめないでしょう。

ほとんどの議論は識別できない意味論的な戦いですが、議論を絞り込むことができれば、ロールアップがいつ、どこで、なぜ理にかなっているのかという核心的な質問に触れるため、根本的なポイントは価値があります。

スケーラブルなL2は、市場でのL1の必要性を排除しますか? ソラナのようなL1をL2に変えることは可能ですか?

これらの議論は、主にセキュリティの問題に要約されます。 残念ながら、ここでの「セキュリティ」の定義は常に非常にとらえどころのないものでした。 私たちは通常、この用語を何気なく使用し、ほとんどの人は私たちが話していることを大まかに知っていますが、完全ではありません。 ここでは、さまざまなアーキテクチャ間のセキュリティを詳細に分析します。

流行語の定義

ロールアップ

私は以前、Mustafaの次の定義を使用しました:「ロールアップは、そのブロックを別のブロックチェーンに公開し、そのブロックチェーンのコンセンサスとデータ可用性(DA)を継承するブロックチェーンです」。

以下は、James Prestwichによって与えられたより一般的な定義です:「ロールアップは、状態遷移関数をカスタマイズし、スーパーセット状態を維持することによって、別のコンセンサスメカニズムにオプトインする方法です。」

どちらも検証ブリッジを必要とせず、最小限の信頼前提でクロスチェーンブリッジを構築できることはロールアップの大きな利点ですが、それらを個別に分析することが重要です。

次のロールアップ基準を検討できます。

※ロールアップとは、メインチェーン(DA層)上のデータ入力に対してカスタム状態遷移関数(STF)を実行することで導出されたステートフルなシステム(ブロックチェーンなど)です。 *リモートチェーンの最終確認状態(つまり、ロールアップ)を導出するために使用されるすべての入力データ(つまり、完全なトランザクションデータまたは状態の違い)は、メインチェーンで確認されます。 ※ロールアップ状態は、メインチェーン上のデータに対して実行される状態遷移関数(STF)から導出されるため、ロールアップの有効性はメインチェーンの有効性に依存します。 次に、ロールアップノードは、メインチェーンのコンセンサスと有効性を完全に検証する必要があります(または、メインチェーンについて正直な過半数の仮定を行う必要があります)。

ロールアップノードは、独自の状態遷移関数(STF)を適用して、メインチェーンのコンセンサス結果(メインチェーンがデータブロックの順序と可用性を確認するなど)のロールアップの状態を決定します。

クロスチェーンブリッジ

クロスチェーンブリッジは、2つのブロックチェーンが相互に通信できるようにするシステムです。 チェーンA(ターゲットチェーン)は、チェーンB(ソースチェーン)で何かが起こったことを確信する必要があり、その逆も同様です。 理想的には、この通信は双方向であり、強く相関するセキュリティ属性(たとえば、メッセージが有効であるという高い信頼度、ソースチェーンが元に戻されないなど)が必要です。

基本的に、クロスチェーンブリッジは別のブロックチェーンの「オブザーバー」として機能します(他の典型的な人間のユーザーと同じように)。 クロスチェーンブリッジは、接続されたチェーンの状態(たとえば、転送入力を受け入れるために通過する必要があるイーサリアムブロックの数)を確信するための特定の確認ルールを実装します。

*従来のクロスチェーンブリッジは、通常、ソースチェーンのオンチェーンコンセンサスバリデータライトノードを実行します(つまり、ほとんどのコンセンサスサインを信頼するもの)。 *クロスチェーンブリッジは、完全なバリデータライトノードとして機能することにより、より強力なセキュリティ属性を提供できます(つまり、データ可用性サンプリング(DAS)+有効性/失敗証明を追加します)。 たとえば、チェーンのバリデータは、チェーンを接続するすべてのDASライトノードで実行する必要がある場合がありますが、これは、バリデーターが接続されたチェーンを実行する必要があるフルノードよりも軽量な代替手段です。 *ロールアップクロスチェーンブリッジは、メインチェーンの活動と抵抗を保持することもできます(ロールアップはメインチェーンのコンセンサスを共有する必要があるため)。

メインチェーンからのブリッジング→ロールアップ

ロールアップノードがメインチェーンを完全に検証するため、この方向は非常に簡単です。

ロールアップノードはメインチェーンで発生するすべてを知っているため、クロスチェーンブリッジトランザクションがいつ発生するかを認識し、現在のイーサリアムロールアップフルノードはイーサリアムベースレイヤー自体のフルノードも実行する必要があります。

ロールアップノードは、サポートされている場合、代わりにメインチェーンの完全なバリデータライトノードを実行することもできます。 イーサリアムが次のアップグレードを完全に実装した架空の例を考えてみましょう。

*有効性の証明を持つイーサリアム実行ブロック(ベースレイヤーでのzkEVM研究は進行中です); *イーサリアムは完全なDASを実装しているため、ノードはDAをサンプリングできます。 *イーサリアム実行レイヤーは、イーサリアム上の他のロールアップと同様に、データをBLOBとしてデータレイヤーに公開します(たとえば、Celestiaの実行レイヤーデータはDAレイヤーに公開されるため、DASノードはロールアップデータとCelestia独自の実行レイヤーの可用性をチェックします)。

  • イーサリアムは、同期委員会に頼る代わりに、コンセンサスの完全な証明を提供します(例えば、バリデーターの統合、より良い署名集約、可能なZKコンセンサス証明など)。

ここで、イーサリアムベースのロールアップのフルノードを実行すると仮定すると、有効なロールアップチェーンに従うには、イーサリアム自体のコンセンサスと有効性をチェックする必要があるイーサリアムの正規チェーンを理解する必要があります。

*イーサリアムコンセンサス - 任意のライトノードクライアントは、ブロックチェーン、ブロックヘッダーとして署名されたコンセンサスを追跡できます。 *イーサリアム独自の実行層DA –ロールアップノードはイーサリアムのDA層をサンプリングし、ロールアップデータとイーサリアム独自の実行層データの可用性を確認します(後で説明するように、DASノードはフルノードについていくつかの追加の仮定を行うことに注意してください)。 *イーサリアム独自の状態の有効性– zkEVMでは、各イーサリアムブロックには有効性の証明が付属しています。

ロールアップノードは、イーサリアムブロックの有効性条件であるため、イーサリアム自身の実行レイヤーの状態の有効性とDAを確認する必要があります。 ロールアップノードは、コンセンサスが署名されたイーサリアムを追跡するだけでなく、有効なブロックヘッダーであることも認識する必要があります。 たとえば、コンセンサスに署名されているが無効であるイーサリアムブロックを誤って追跡する可能性があります(たとえば、大量のETHを生成します)。

基になる実行レイヤー自体が (他のロールアップと同様に) DA レイヤーにデータをパブリッシュし、有効性または失敗の証明を追加すると、組み込みのロールアップになります。

ロールアップ→メインチェーンからのブリッジ

メインチェーンはデフォルトでロールアップとSTFの状態を認識しないため、この方向は注意が必要です(つまり、イーサリアムノードはロールアップノードを実行する必要はありません)。 メインチェーンがロールアップの状態を信じるために、メインチェーンにデプロイされたスマートコントラクト(つまり、ロールアップの検証ブリッジコントラクト)にロールアップのロジックを実装できます。 このスマートコントラクトは、DAとロールアップの状態の有効性をチェックします。

繰り返しますが、このクロスチェーンブリッジはオプションです。 メインチェーンのスマートコントラクトは、すべてのメインチェーンノードにロールアップの有効性を納得させるために使用され、適切な信頼の前提の下で双方向通信を可能にします。

ロールアップ、コプロセッサ、およびインテント

説明したように、ロールアップは、メインチェーンの状態(イーサリアムなど)を所有することに加えて、独自の状態(ロールアップの状態)の一部を保存します。 では、CoWスワップには、イーサリアム状態の一部ではない独自の状態がありますか? はいの場合、ロールアップのように聞こえます。 そうでない場合は、「コプロセッサ」である可能性があります。

しかし、この質問でさえ見かけほど単純ではありません。

代わりに、区別要因は状態の永続性であると考えるかもしれません。

CoW Swapが特定の参加者に迅速な事前確認(イーサリアムのブロック時間よりも速い)を提供し、バッチを含む注文を約束することを可能にする場合、イーサリアムのバッチ処理はほとんどのユーザーが望むよりも時間がかかるため、ロールアップになりますか?

Chris Gogoes は、モジュール性サミットでの講演でこのトピックに触れ、意図のおおよその定義である「特定のシステム状態空間に対するプリファレンス関数のコミットメント」から始めました。

部分的な解決 (一致意図) とロールアップの並べ替えの類似点に注意してください。 オペレーターは、ユーザーのオフチェーン署名付きメッセージを取得し→結果のデータをメインチェーンに公開します。

*インテントベースのアプリケーション - 結果として生じる状態変更はチェーン上で解決されます(例えば、CoWスワップの例では、アプリケーションは基礎となるチェーン上にあるため、トークンはそこで交換されます)。 *ロールアップアプリケーション - メインチェーンに送信されたデータを使用して、ロールアップによって生成された状態の変化を計算します。

インテント中心のアーキテクチャとロールアップ中心のアーキテクチャは、反対方向から同様の目標を達成します。 インテントセントリックなアプローチは、ユーザーとアプリケーションの観点からこの問題に広く対処し、ロールアップセントリックなアプローチは、さまざまなブロックチェーンの観点からこの問題に広く対処します。

ここでは、特定の識別境界を設定することは重要ではありません。 さらに、ロールアップは、実際にはオフチェーンのインテントマッチングで慣れ親しんできたアプリと大差ないことがわかりました。

オフチェーン参加者(シーケンサーとソルバー/フィラーなど)に依存して、メインチェーンに公開されたデータに基づいて結果を決定する→、最高の実行と優れたユーザーエクスペリエンスを提供するなど、いくつかの弱い保証を取得します。 しかし、彼らはあなたの資金を保管していません。

検証可能なオフチェーン計算がより重要になるにつれて、2つの間の境界線が曖昧になる可能性があります。

インテントソルバーまたはロールアップオーダラーの信頼性を低くしたい場合...

モジュラーブロックチェーンとモノリシックブロックチェーン

モノリシックブロックチェーン(別名統合ブロックチェーン)は、多くの場合、すべてのコア機能、つまりコンセンサス、DA、および実行を垂直に統合するチェーンとして定義されます。 彼らは自分たちの安全に全責任を負い、ソラナとコスモスハブはその代表的な例です。

DAレイヤー(イーサリアムやセレスティアなど)は、実行をロールアップにアウトソーシングするため、「モジュラー」ブロックチェーンと呼ばれることがよくありますが、これは完全に正確ではありません。 彼らはまた、彼ら自身のコンセンサス、DA、および施行に対して独立して責任があります。

セレスティアの実行でさえ制限されます(例:転送、ステーキング、クロスチェーン)。 同様に、誰かがSolanaの上でロールアップを開始した場合、それは魔法のように「モジュラー」ブロックチェーンになることはありません。

したがって、人々がイーサリアムやセレスティアのようなチェーンを「モジュラー」ブロックチェーンと呼んでいるのを聞いたら、これは厳密に技術的なものよりも実用的な違いであることを理解してください。 どちらも、ロールアップをサポートするために独自のアーキテクチャを最適化することがよくあります。 これらのロールアップは、その範囲内でほとんどの取引実行を処理することが期待されています。

ロールアップでさえ、必ずしも完全に「モジュール式」であるとは限りません—ロールアップシーケンサーは、メインチェーンが何かをする前に、トランザクションシーケンスに同意し、DAを提供し、トランザクションを実行できます。 これは、ユーザーが事前確認される方法です。 次に、メインチェーンは別の「最終」コミットメントを提供し、ロールアップのトランザクションの順序に関するDAとコンセンサスを再度宣言します。

ロールアップと統合チェーン

ここでは、より重要な区別は "ロールアップ" または "非ロールアップ" です。 チェーンの最終状態は、別のメインチェーン(つまりDAレイヤー)に公開されたデータに由来しますか?

現在、DASと有効性/失敗証明は従来のロールアップに関連付けられていますが、これらは論理的に異なる概念であることに注意してください。 理論的には、任意の「統合チェーン」(一般的なCosmosアプリケーションチェーンなど)をアップグレードして、イーサリアムなどの他の外部メインチェーンにデータを公開することなく、DASと有効性の証明を追加できます。 ノードはチェーンを個別にサンプリングしてチェックします。

ヴィタリックはエンドゲームでこの違いについて語っています。

DAS +有効性/失敗証明を備えた「従来の大きなブロックチェーン」(統合チェーン)が「祀られたロールアップ」のように見えることに気付くかもしれません! 同様に、「スケーラブルで支配的なロールアップ」は非常に成功し、そのロールアップに対応するためにメインチェーンとマージするだけです。

限界で区別の境界が曖昧になります。

したがって、DAS+の有効性/失敗の証明が最終結果であると信じるなら、ある意味での「ロールアップ」は避けられません。 前の図の 2 つの方法には有効な違いがあります。

*「ロールアップ」別名「モジュール性」-論理的に独立したチェーンを構築し、データをメインチェーン(DAレイヤー)に公開し、メインチェーンのコンセンサスを再利用します。 *「統合ブロックチェーン」別名「モノリシックブロックチェーン」-データを別のメインチェーンに公開することなく、すべてを独自のコンセンサスで1つのプロトコルに統合します(DA層と実行層がある意味で共有プロトコルの論理的に別々の部分であっても)。

このレポートで「ロールアップ」について話すときは、前者を指します(つまり、DAS +有効性/失敗証明との統合チェーンではなく、組み込みのロールアップと呼ばれる場合があります)。

「従来の」ロールアップはDASや証明を独占していませんが(つまり、統合された大規模なブロックチェーンで追加できます)、ここでは多くの技術的な詳細を見落としており、Solanaを選んで「ああ、今日はDASを追加すると思います」と決めることはできません。

これには、イーサリアムとセレスティアが行っていることに近づき始めるために、プロトコルの根本的なリファクタリングが必要です。

DASをサポートするためにデータのエンコード方法を変更すると、ブロックのエンコードと伝播が遅くなり、従来のDAレイヤーに近づき始めます。

このため、チームは次のものを構築します。

*特殊なDAレイヤー(例:イーサリアムのダンクシャーディング、セレスティアなど)-低速ブロック+ DAS。 *共有シーケンサー(エスプレッソ、アストリア、さらにはソラナなど) - 実際には高速DAレイヤーのみで、DASは必要ありません。

ただし、高速チャンクと DAS の時間を分離すると、必ずしも互換性があるとは限りません。 たとえば、Solanaのようなチェーンが2つの異なるパスを提供していると想像できます。

*ファストパス - トランザクションを実行し続け、できるだけ早くデータを広める(今日のように)。 *スローパス - 非同期サンプリングを実行できる方法で事後にデータをエンコードし、DASノードがコンセンサスよりわずかに遅れていることを保証します。

アナトリーはポッドキャストで、Eclipseがイーサリアム、セレスティア、ソラナをどのようにまとめるかを説明しており、スペクトルの反対側から、データをサンプリングに使用できるようにする前に、DAレイヤーがより高速なパスを追加することを想像できます。

同じベース レイヤー プロトコルで 2 つのパスを提供することで、高速な共有並べ替えが効果的に内部化され、ロールアップに基づく興味深い設計が提供されます。 現時点では、これはまだ非常に探索的なアイデアであることに注意してください。

ルールを確認する

このような背景から、これらの異なるアーキテクチャのセキュリティ属性を分解し始めることができます。

まず、ノードは「確認ルール」を実行してブロックチェーンと対話します。

「確認ルールとは、ブロックが確定したかどうかを出力するためにノードによって実行されるアルゴリズムを指します。 この場合、主にネットワークの同期と正直な共有の割合を含む特定の仮定の下で、これらの条件が満たされると、ブロックは再編成が発生しないことが保証されます。

特定のチェーンには、任意の数の確認ルールを設定できます。

*ビットコイントランザクションを確認する前に、いくつのブロックを待つ必要がありますか? 1 ? 6 ? 10 ? *LMD GHOSTを使用して、イーサリアムの使用可能な元帳に基づいてブロックを確認しますか、それとも最終的なガジェット(キャスパーFFG)が確認するのを待ちますか? *各ブロックを直接検証するフルノードを実行しますか、それともコンセンサス署名をチェックするライトノードのみを実行しますか? *インフラに聞いただけですか?

各受信確認ルールは非常に異なる仮定を行う可能性があるため、同じチェーンと対話する場合でも、非常に異なるセキュリティ プロパティを持つことができます。

この区別は微妙ですが重要です。

セキュリティ = セキュリティ + アクティビティ

それでは、ロールアップがメインチェーンから「セキュリティを継承」するかどうかについて詳しく見ていきましょう。

継承、そしておそらくより明確には、ロールアップは常にメインチェーン内の何かを「継承」するのではなく「賃貸」し、消費されたリソース(DA)の継続的なコストを支払い、どちらの当事者も関係を終了することを選択できます。 しかし、それは問題の興味深い部分ではありません。

セキュリティ、これからはセキュリティに焦点を当てます。 アルゴリズムのセキュリティは、安全性と活性で構成されます。

*セキュリティ(悪いことは何も起こりません)、2つの正常なノードによって決定された最終状態は決して競合しません。 *活性(最終的には良いことが起こる)、すべての正常なノードは、限られた時間内に含まれているトランザクションを反映した新しい状態を完了します。

Sreeramの優れたフレームワークを使用して、それらをさらに5つの属性に分類し、連携して確認ルールを確保できます。

DAS +妥当性/失敗証明を持つ架空の統合チェーンの例を考えてみましょう。 そのデータは、他の外部メインチェーンには公開されません。 簡単にするために、即時ファイナライゼーション(例:テンダーミント)を想定しているため、利用可能な元帳とファイナライズされた元帳(例:イーサリアムのギャスパー)の間に使用可能な区別はありません。

異なるタイプのノードを使用してチェーンをトレースするために使用できる3つの確認ルールを検討します。

*コンセンサスバリデータライトノード - コンセンサスの証明を検証します(つまり、正直な多数決を信頼します)。 *完全なバリデータライトノード - コンセンサスの検証+DAのチェック(DASを使用)+状態の妥当性の検証(有効性/失敗の証明を使用)。 *フルノード - 検証コンセンサス+DA(すべてのデータをダウンロード)と有効性(すべてのトランザクションの実行とステータスの計算)の直接検証。

ルールにセキュリティ属性があることを確認しますが、チェーンには含まれていません

繰り返しになりますが、「チェーンは安全であると口語的に話しますが、実際にはセキュリティ属性に付けられた確認ルールです」。

いくつかの例を見てみましょう。

キャップ定理

背景として、CAP定理は、台帳がこれらの条件の両方を同時に満たすことができないことを示しています。

適応性(別名動的可用性)-動的参加でアクティブな状態を維持します(つまり、ほとんどのノードがオフラインの場合)。 ファイナリティ(別名一貫性)–ネットワークパーティションの下でセキュリティを維持します。

コンセンサスプロトコルは2つの部分に分けられる傾向があり、それぞれが上記の条件のいずれかを満たしています。

*最長のチェーンプロトコル - これらのプロトコル(例えば、ビットコインのサトシコンセンサス)は、アクティブな参加ノードの数が可変である(すなわち、適応的である)場合でも活動を保証するが、ネットワークパーティショニングの下では安全ではない(すなわち最終ではない)。 BFTタイプのプロトコル - 古典的なコンセンサスプロトコル(PBFTなど)はファイナリティを達成しますが、適応性を達成しません。

ビットコイン確認ルール

ビットコインのコンセンサスは、ハードな経済的最終性を提供しません。

ノードはローカルビューで最も長いチェーンを観察し、各ユーザーは好きな確認ルールを自由に適用できます(たとえば、>kの確認でブロックを受け入れる)。 6ブロックの確認を待つのが目安ですが、それはあなた次第です。

より価値の高いトランザクションの場合は、より長く待つのが妥当です。 待機時間とセキュリティの間にはトレードオフ、つまり再編成の可能性があります。

イーサリアム確認ルール

イーサリアムのPoSコンセンサス(Gasper)は、一見するとCAP定理を回避しているように見えます。 ただし、2つのネストされた元帳が含まれているため、これら2つのプロパティを実装します。

*動的に利用可能な元帳 - ネットワークが分割されていない場合、動的参加で安全でアクティブです。 *確定されたプレフィックス元帳 - 常に安全で安全です。 ネットワークがパーティション分割されておらず、十分な数のノードが参加している場合、ネットワークはアクティブなままになります。

Gasperは、「引き潮流」(二重元帳または二重確認ルールとも呼ばれます)プロトコルファミリーに属しています。 2元帳設計はCAP定理の範囲外です(つまり、単一の確認ルールを想定しています)。 ネットワークが分割されると、ファイナライズされた台帳はアダプティブ台帳に遅れをとっていますが、ネットワークが修復されると追いつきます。

これにより、適応性とファイナリティの間のトレードオフを、システム全体のレベルではなく、ユーザーレベルで対処できます。 これは、ユーザーが信頼できる適応性とファイナリティの観点から、ブロックチェーンCAP定理によって提案された「チェックポイントの最長チェーン」プロトコルの特徴です。 これらのプロトコルは、システム全体レベルでそれを課すのではなく、個々のユーザーにファイナリティと適応性のどちらかの選択肢を提供します。

Gasperは、上記の2つの元帳にマッピングされた2つの異なる確認ルールを明示的に公開します。

*動的に利用可能なルール - 適応性を保証します。 最長チェーンのブロックヘッダーを尊重します。 LMD GHOST は、最も重いサブツリーを決定するために使用されるフォーク選択ルールです。 *ファイナライゼーションルール - 最終的な確実性を保証します。 最終的なガジェットによって確認されたブロックを尊重します。 キャスパーFFGは、フォーク選択ルールの上に適用される最終的なガジェットです。

論文で議論されているように:

「より楽観的な適応ルールは、より保守的なルールによってファイナライズされたとマークされたブロックを常に確認し、可変参加レベルでより多くのブロックを確認する可能性があります。 顧客(ユーザー)は個人の好みに基づいて確認ルールをローカルで選択しますが、マイナーはこれら2つの確認ルールと一致する固定ブロック提案ルールに従います。」

これにより、システム内のすべての(正直な)ノードが許可されます。

*共通のブロック提案メカニズムに従います。

  • ただし、ノードごとに異なる確認ルールを選択できます。

バリデーターは、参加のレベルに関係なく、最長のチェーンを長くし続けます(ますます増加する高さで新しいブロックをマイニングします)が、十分な参加がある場合にのみ、新しいチェックポイントが表示されます。

最長のチェーン(最新のチェックポイントを含む)は、異なるチェーン間で交互に行うことができます(つまり、不完全なブロックを再構築します)が、チェックポイントはネットワークの状態(つまり、ファイナリティ)に関係なく、単一のチェーン上にあることが保証されます。

ユーザーのセキュリティは、ユーザーが従う確認ルールによって異なります。 迅速なブロック確認とより強力なセキュリティ保証の間にはトレードオフがあります。 コーヒーを販売するユーザーはセキュリティよりもアクティビティを好むかもしれませんが、ヨットを販売するユーザーはアクティビティよりもセキュリティを好むかもしれません。

イーサリアムノードは、他の中間確認ルールヒューリスティックを実用的な目的に適用することもできます。 ビットコインのように、単純なkブロックを適応確認ルールとして使用する代わりに、ネットワーク同期とバリデータの正直性に関する仮定を含む他のヒューリスティックを追加できます。

これはまさにイーサリアムコンセンサスプロトコル確認ルールで提案されているものであり、次のプロパティを持つ確認ルールを提案します。

*理想的な条件下では、ルールはスロットの直後に新しいブロックを確認します。

  • 典型的なメインネット条件下では、ルールはほとんどの新しいブロックを1分以内に確認できるはずです。

この確認ルールは、経済的なファイナリティに代わるものではありません。 代わりに、ネットワーク同期が近い将来も続くと信じているユーザーに便利なヒューリスティックを提供します。 2つを比較してみましょう。

ETHでヨットを250万ドルで販売する場合など、いくつかの例を考えてみましょう。

*フルノード+最終結果を待っている - 悪意のある大多数のバリデーターでさえ、あなたをだまして無効なブロックを受け入れることはできません(例えば、偽のETHを生成する)。 彼らがあなたにETHで250万ドルを支払い、後で最終的なブロックを再構築しようとすると、彼らは莫大な費用を負担します(エクイティの少なくとも3分の1は罰せられるカットです)。 *フルノード+ブロックを待つ - ほとんどの悪意のあるバリデーターはまだあなたをだまして無効なブロックを受け入れることはできませんが、有効なブロックで250万ドルのETHを送り、ヨットに乗り、ブロックはすぐに再編成されます。 *ライトノードクライアント - 悪意のある同期ボードはペナルティなしであなたに嘘をつくことができ、買い手はヨットに残すことができます(この同期委員会はコンセンサスのサブセットとしてイーサリアム専用であり、より効率的なライトノードクライアントをサポートする他のPoSチェーンは少数のバリデーターですべてのコンセンサス投票をチェックできます)。

  • MetaMask - あなたはただInfuraを信頼します、あなたからヨットを購入した人は彼らが週末にヨットに乗ることができるとインフラの従業員に約束しました、それで彼らはあなたに嘘をつきました、あなたはあなたがETHで250万ドルを手に入れたと思っていました、そしてあなたは鍵を渡しました。

ロールアップでルールを確認する

他のチェーンと同様に、ノードは異なる受信確認ルールを使用してロールアップと対話します。 ロールアップの最も強力な確認ルールは、メインチェーンのコンセンサスとともに最終決定されます。 ロールアップシーケンサーは、ユーザーエクスペリエンスを向上させるために弱い確認ルールを公開できますが(つまり、せっかちなユーザーに迅速な事前確認を提供します)、ユーザーはメインチェーン確認ルールの完全なセキュリティを待つこともできます。

一般的なロールアップ トランザクション フローは次のようになります。

*ユーザーはシーケンサーにトランザクションを送信します。 *シーケンサーはトランザクションをソートし、事前確認を行います。

  • 決定論的 STF は、新しいロールアップ状態を計算するために、順序付けられたトランザクションに適用する必要があります。 *更新されたロールアップステータスコミットメントと関連するトランザクションデータが最終的にメインチェーンにリリースされます。

トランザクションデータがメインチェーンに公開された後:

*ロールアップフルノード - 提案されたチェーン状態が正しいことを直接検証します。

  • ロールアップ ライト ノード (検証ブリッジを含む) - 直接検証できません。 *同じロールアップの異なるオブザーバーは異なる確認ルールを使用するため、異なる時間に視点を確定します。 *完全なトランザクションデータ(状態の違いだけでなく)のリリースを想定します。
  • 前述のように、ロールアップノードはメインチェーンのフルノードまたはフルバリデーターライトノードも実行する必要があります(または、コンセンサスバリデーターライトノードを使用して、正直な多数決の仮定を行う必要があります)。 ロールアップライトノードは、追加のソフトウェアとして、またはメインチェーンノード内で暗黙的に実行できます(つまり、メインチェーンでのクロスチェーンブリッジコントラクト検証ロールアップ)。

ユーザーは、プライマリリンクがデータを受信する前であっても、シーケンサーを信頼して事前に確認することで、トランザクションをより迅速に確認することもできます。 シーケンサーが正しく動作しない場合、セキュリティが失敗する可能性があります。 次に、データがメインチェーン上にあると(そしてDA +の有効性を確認した後)、メインチェーンの障害(イーサリアムの再編成など)のみがセキュリティに影響します。

したがって、集中型の注文者でさえ、「ロールアップ」のセキュリティを実際に低下させることはありません。 必要な確認ルールに準拠したセキュリティを常に取得できます。 ロールアップがシーケンサーベースのデザインであろうと他のデザインであろうと、同じ確認ルールを使用できます(たとえば、メインチェーンが確定するのを待って、ロールアップの有効性を確認します)。 適切な実装(メインチェーンを介したトランザクションインクルードの強制など)を前提とすると、他の条件を同じに保ちながら、同じ時間枠内で同じセキュリティ属性を取得できます。

同様に、イーサリアムL1ブロックプロデューサーは、ブロック時間が遅いために事前確認を提供し、それによって「イーサリアム」の安全性が低下することはないと想像できます。 イーサリアムバリデーターがより高いセキュリティを確定するまで、別の確認ルール(安全性が低い)を使用するかどうかを決定する必要があります。

事前確認のアイデアは、ヴィタリックによって記述されたギャスパーの論理によく適合します。

一般的な原則は、ユーザーに「できるだけ多くのコンセンサス」を提供したいということです:2/3>ある場合、定期的にコンセンサスに達しますが、2/3<ある場合、新しいブロックのセキュリティレベルが一時的に低下しているにもかかわらず、明らかにチェーンは成長し続けるため、何も提供せずに遅延する理由はありません。 1 つのアプリケーションが低レベルのセキュリティに満足できない場合は、ファイナライズされるまでこれらのチャンクを無視してください。

これらすべてをまとめると、すべての確認ルールが同時に元帳の同じ状態に同意すると、「整合性領域」が得られます。

ルールを確認する - セキュリティとアクセシビリティ

確認ルールが、世界で最も評判の良いバリデーターで構成される分散型シーケンサーではなく、SBFによって実行される単一のシーケンサーを信頼することである場合、セキュリティが悪化する可能性があり、アクティブな障害と再編成はセキュリティ障害です。

または、より強力な (メインチェーンの) 確認ルールが使用可能になるまで待つこともできます。 次に、他のすべてが同じであれば、信頼されていないシーケンサーはセキュリティに影響を与えません。 コーヒーを販売している場合は、おそらくすぐに行くでしょうが、ヨットを販売している場合は、メインチェーンの確認を再確認する必要があります。

ただし、全員が実際にその確認ルールを使用してヨットを販売する場合、「別のシーケンサーを実行しているランダムな人を信頼する」確認ルールの潜在的に低い安全性を完全に無視することはできません。 正確な設計は、特定のユースケースの何時に必要なプログレッシブコミットメントのレベルのバランスに基づいています。

繰り返しになりますが、これはSolanaのような高スループットブロックチェーンに対する真の批判に触れています。 実際にどのような確認ルールを使用できますか? Solanaフルノードを実行するための適切なセキュリティ条件があるかもしれませんが、ほとんどの人はその確認ルールにアクセスできない可能性があります(つまり、リソース要件やコストによって異なります)。

直接検証(つまり、正直な大多数を信頼するだけでなく)は、これらのシステムのコア属性です。 したがって、特定の確認ルールでは、セキュリティとアクセシビリティという2つの側面に重点が置かれています。

一言で言えば:

*ユーザーは確認ルールを通じて任意のチェーンと対話します。 *チェーンは任意の数の確認ルールを持つことができます。

  • セキュリティは確認ルールの属性であり、チェーン自体ではありません。 *私たちは、特定のチェーンの確認ルールのセキュリティとアクセシビリティに関心があります。

実際、特定のチェーンが安全であると言うとき、関連する確認ルールは安全でアクセス可能であるという概念を表現しようとしています。

統合チェーンセキュリティを備えたロールアップ

1、DAS+の有効性を証明する統合チェーン

DAと状態の有効性に関するセキュリティは、チェーンの演算子について強い仮定をすることなく、暗号化(DAS +有効性/失敗の証明)によって直接チェックできることがわかりました。 どのプロトコルでも技術的にこれらを実装できます。 フルノードは、外部の仮定なしにDAと状態の有効性をチェックすることもできます。

それでは、他の特性 - 活性と再結合に対する抵抗性 - に焦点を当てましょう。 前に説明したように、これらはどのような種類の確認ルールを実行しても失敗する可能性があります。 +PoSシングルソケットのDAS+の有効性の最終性を証明する別の統合チェーンを見てみましょう。

強力な確認応答ルールを選択することは、ほとんどの悪意のあるバリデーターでさえ、フルノードまたはフルバリデータのライトノードをだまして次のことを信じさせることができないセキュリティ障害のサブセットに特に効果的です。

*利用できないデータは実際に利用可能です。

  • または無効な状態遷移は有効です。

イーサリアムに1つのバリデーターがあるか、無数のバリデーターがあるかにかかわらず、すべてのノードは多かれ少なかれブロックのDAまたは有効性を信じており、チェックによって保証されます。 完全なバリデータのライトノードは、より簡単な方法でチェックできます(ただし、DASは後で説明する他のいくつかの仮定を行うことに注意してください)。

ただし、悪意のある大多数のバリデータは、台帳の成長、検閲、またはチェーンの再編成を妨げる可能性があります(どの障害が発生するかは確認ルールによって異なります)。 DAS + ZKはあなたを救いません。 再編成と活動に対する抵抗は、常に特定のチェーンのさまざまな根本的な属性(たとえば、信頼できるオペレーター、経済的インセンティブ、社会的コンセンサスなど)にある程度依存します。

それほど明白ではありませんが、各ノードは上記の表と同じ攻撃を受けるため、アクティビティと再編成に対する抵抗は、特定の確認応答ルールの属性です。 ここでの確認ルールに関係なく、同じ保証があります。

ただし、これは、単一スロットのファイナリティの仮定を削除すると再び明らかになります。 イーサリアムのGasperでは、フォローする元帳(つまり、利用可能な最長のチェーン元帳またはチェックポイント)に応じて、アクティビティと再編成に強いプロパティが再び異なります。 ほとんどの悪意のあるバリデータは、実行する確認ルールに応じて異なるセキュリティエラーを引き起こします。

いずれにせよ、ポイントは、チェーンの基礎となる構造がここで非常に重要であるということです。 チェーンをアクティブに保ち、リストラに抵抗するには、強力なオペレーター、経済的インセンティブ、および社会的コンセンサスが必要です。 さらに、イーサリアムなどの二重元帳コンセンサスプロトコルは、ニーズに応じて可用性とファイナリティを計算するための貴重な柔軟性をユーザーに提供します。

2、DAS を使用したロールアップの証明 + 有効性

次に、この例を少し変更しましょう。

*前の例 - DAS +の有効性の証明を持つ統合チェーンは、今日のソラナを取ることを想像しますが、DAS +の証明を追加します。 *新しい例 - ロールアップは有効性の証明+ DAS(イーサリアムDASはまだライブではないことに注意してください)を使用して外部メインチェーン(イーサリアムなど)に展開され、ロールアップには迅速な事前確認でコンセンサスに達することができる分散型シーケンサーセットがあります。

ロールアップには、異なる時間枠(つまり、シーケンサーの事前コンセンサスに基づいて操作しているか、メインチェーンの最終コンセンサスを待っているか)に対して2つの完全に異なるタイプの確認ルールがあることに気付くでしょう。

ファストパス - メインチェーンのコンセンサス前

ロールアップ ノードは、(メイン チェーンに発行する前に) シーケンサーからの確認に依存でき、次のロールアップ ノードを実行できることを前提としています。

*ロールアップコンセンサスバリデータライトノード - ロールアップシーケンサコンセンサスの正直な過半数を信頼します。 *ロールアップフルバリデータライトノード - シーケンサのフィードでDAS +を実行して、イーサリアムに何かを公開する前に有効性の証明をチェックします。 *ロールアップフルノード - シーケンサーのフィードからすべてのデータをダウンロードし、DAと有効性を直接チェックするためにすべてのトランザクションを実行します。

技術的には、ロールアップシーケンサーはDASを容易にし、メインチェーンに公開する前に有効性の証明を提供できますが、これは実際には発生しません。 完全なバリデーターライトノードは通常、メインチェーンを介してこれらをチェックするように設計されていますが、「ライブ」DAS +プルーフは統合チェーンと同じものとより明確に比較できると思います。

次の表は、統合チェーンの例と比較した変更点を示しています。

*統合されたチェーンのバリデーターセットではなく、アクティビティと組換え防止のためにロールアップシーケンサーに依存します。 *メインチェーンのコンセンサスまでの時間範囲のみがここに表示されるため、最終的なアクティビティ属性のみを削除しました(これらの「最終的な」アクティビティ属性は、将来自己所有されます)。

削除は赤い取り消し線で表示され、追加は青で表示されます。

遅いパス - メインチェーンのコンセンサスを待つ

セキュリティを強化するために、ノードはメインチェーン(イーサリアムなど)からのコンセンサスを待つことができ、そこでより明確に機能します。

*メインチェーンコンセンサスバリデータライトノード - メインチェーンの正直な多数決を信頼します。 *メインチェーンフルバリデータライトノード - メインチェーンの有効性証明を確認する+メインチェーンでDASを実行する(データロールアップ+メインチェーンデータを含む)。 *メインチェーンフルノード - すべてのメインチェーンデータ(ロールアップデータのチェックを含む)をダウンロード+すべてのメインチェーントランザクションを実行して有効性を直接チェックします。

  • ロールアップの状態の有効性は、次の 2 つの異なるパスで検証できることに注意してください。 *メインチェーンの外側(追加のロールアップノードソフトウェアを実行)-ロールアップは、メインチェーンがその状態またはSTFを検証する必要はなく、検証ブリッジを展開する必要はなく、代わりに別の方法でロールアップ証明を確認できます(たとえば、p2p経由でロールアップ証明を受信する)、証明を検証するために追加のロールアップノードソフトウェアを実行する必要があります(つまり、ロールアップライトノード)。 *メインチェーン内(メインチェーン内にロールアップノードを実装する)-これは今日の標準であり、ロールアップライトノードバリデータロジックはメインチェーン自体(つまり、ロールアップの組み込みブリッジコントラクト)に展開されますこのロールアップバリデータノードはメインチェーンのSTF内で実行されるため、メインチェーンのSTFを検証することは、ロールアップのSTFを検証することも意味します。

ゼロ知識証明のメインチェーン(例:イーサリアムL1 zkEVM)+すべてのロールアップがメインチェーン内の状態を証明すると→特異点の証明というVitalikのビジョンが得られます。 イーサリアムを検証するゼロ知識証明とは、他のすべてのチェーンを検証し、それらの内部実装のノードを検証することを意味します。

簡単にするために、ここではロールアップの状態の有効性がメインチェーン自体の中で検証されると仮定します(たとえば、ロールアップにはメインチェーンとのブリッジが組み込まれています)ので、プロトコルの外部で追加のロールアップノードソフトウェアを明示的に実行することは無視できます。

以前の高速機能ロールアップ表からの変更点は、以下のとおりです。

これは、メインチェーンがトランザクションにシーケンサー/証明者の置換を含めるか、課すことによって達成されますが、ロールアップの観点からは低速パスであるため、ここでは「最終」アクティビティと呼ばれますが、メインチェーンの観点からは、これは「リアルタイム」アクティビティと見なすことができます。

統合ブロックチェーンによるロールアップ

これで、統合されたブロックチェーンとロールアップに関連するセキュリティ属性の変更を確認できます。

  • DA および状態妥当性 - 実装されている場合、DAS+ 妥当性証明は、チェーンが統合されているか従来のロールアップであるかに関係なく、適用可能なセキュリティー保証を提供できます。 実際、今日のこれらのテクノロジはロールアップによって支配されています。 活性再編成抵抗 –統合されたブロックチェーンは、すべてのシナリオでこれらを個別に担当します。 代わりに、ロールアップでは、異なる時間枠内で確認ルールを選択できます。 安全性の低い確認ルール (信頼シーケンサー コンセンサス) を使用して迅速な保証を取得するか、より安全な確認ルールを待つ (メインチェーン コンセンサスを待つ) ことができます。

活性と組換え抵抗性

これらの属性はパスワードでは保証できず、確認応答ルール全体(たとえば、フルノードまたはライトノードのどちらを実行しているかにかかわらず)でも、セキュリティ障害に対して脆弱になる可能性があります。

オペレーターが完全に制御不能になった場合、フルノードまたはZKプルーフは、アクティビティの失敗や再編成からユーザーを保護することはできません。

これらの属性は、強力で分散型のオペレーター、検閲に強いメカニズム、活動を助長するコンセンサス、リストラの高い「コスト」、強力な社会的コンセンサスなどによって達成されます。 これらを客観的に比較することは、しばしば困難です。

オペレーターの分散化と社会的コンセンサスをどのように測定しますか? 正解は1つではありません。 これらは間違いなく設計するのが最も難しい側面であり、確かに特定のチェーンに非常に固有です。

重要なのは、ロールアップが再編成防止とアクティビティをメインチェーンに委任できること、およびロールアップで使用される確認ルールが、同じ時間枠内でメインチェーンで実行されている場合と同じセキュリティ属性を持つことができることです。

チェーンは、どの属性をどのチェーンに委任するかを選択することさえでき、さまざまなタイプの「L2」アーキテクチャ(検証、楽観主義、サイドチェーンなど)は、セキュリティ属性のさまざまなサブセットを吸収できます。 例えば:

*反リストラ-ロールアップは反リストラをイーサリアムに委任することができ、そのフォーク選択ルールは、イーサリアムコンセンサスが「正規チェーン」を選択することを確認したものに基づいています。 イーサリアムが再編成された場合、ロールアップも再編成されます。 *ライブネス - ただし、ロールアップに強制インクルードと強制オペレーター置換メカニズムがない場合、ロールアップユーザーはイーサリアムのライブネス属性を受け取りません。

ロールアップは、ロールアップを終了するためのエスケープルートをユーザーに提供することもできますが、ユーザーを精査し、預金がロールアップに入るのを防ぐ機能を保持します(たとえば、これはループリングの仕組みです)。 一定期間経過してもデポジットが未処理のままである場合、ユーザーはL1契約からロックされた資金を引き出すことができます。

これは、そのようなメカニズムの重要性を浮き彫りにします。

データの可用性とステータスの有効性

アクティビティや組換え防止とは異なり、ノードは大きなしきい値の仮定(または2つの間のセキュリティトレードオフ)を行うことなく、DAと状態の有効性を保証できます。 悪意のあるマジョリティブロックプロデューサーは、アクティビティと再編成の失敗を引き起こす可能性がありますが、フルノードまたはフルバリデータのライトノードで DA または有効性の失敗を引き起こすことはありません。

ただし、コンセンサスバリデーターのライトノードは、もちろん、正直な多数派の状態妥当性とDAの失敗の影響を受けます。 彼らはコンセンサスが言うことすべてを信じています。 そのため、DAと状態の有効性は、セキュリティ確認ルールにアクセスし、実際に機能させるものです。 これは多くの場合、従来のロールアップとユーザー検証をあまり重視しない大規模なブロックチェーンとの間の大きなイデオロギーの違いです。

多くの場合、セキュリティとアクセシビリティのバランスを取るために、次の方法が推奨されます。

  • DASと有効性の証明を広く利用できるようにする。
  • DAS および/または有効性の証明がない場合は、フルノードを広くアクセス可能にする (つまり、リソース要件が低い、実行しやすいなど)。
  • DASおよび/または有効性の証明がなく、フルノードにほとんどアクセスできない場合は、コンセンサスバリデーターライトノードを広くアクセスできるようにし、信頼できる正直な多数決を得てください。 *インフラを訪問;

実際には2(フルノード)が最も安全であることに注意してください。 ZKの検証は簡単ですが、DASノードは、フルノードにはないいくつかの追加の仮定を行います。 ただし、フルノードとほぼ同じセキュリティを提供し、そのほんの一部にリソース要件があるため、スケーラブルです。

フルノードはすべてのデータをダウンロードするだけでよいため、100%確実です。 彼らはすべてがそこにあるときにのみブロックに署名します。 外部関係者については想定されていません。

DASの目標は、フルノードとほぼ同じくらい優れたセキュリティを実現することですが、リソース要件は大幅に低くなります(つまり、スケールが高くなります)。 ライトノードのデータ可用性セキュリティレベルに関するこの記事では、これについてよく説明しています。

つまり、通常は、ネットワークの同期と、データを再構築するのに十分なノードがあるかどうかについて、いくつかの仮定を行います。 敵対的なブロックプロデューサーがデータを隠した場合、正直なライトノードの小さなグループでも、ブロックをまとめて再構築できるはずです。 選択的シェア開示に関する仮定もあり、敵対的なブロックプロデューサーは少数のライトノードを個別に欺くことができますが、まとめて欺くことはできません。

これらの「N-in-2」仮定(例えば、正直な少数のノードがDASを保護できる)は、典型的な近似的な「N/2」仮定(例えば、ブロックプロデューサーの51%が再編成につながる可能性がある)と比較して非常に有利です。 Vitalikは、信頼モデルに関する彼の投稿でこれについての良い紹介をしています。

全体として、DAと状態の有効性は、ロールアップによって活動および組換え抵抗として「委託」されていません。 DAと状態の有効性はユーザーが直接検証できますが、他の属性はチェーンのコンセンサス参加者とそのインセンティブに大きく依存します。

ロールアップ証明の以前の検証の例を確認します。

*ロールアップのZKの証明をイーサリアムのスマートコントラクトに公開し、そこでイーサリアムのフルノードを実行し、暗黙的に証明を検証します。 *ロールアップのZKプルーフをロールアップライトノードに送信して、プルーフを直接確認します。

いずれの場合も、有効性を保証できます。 どこでチェックしても、その効果を判断することはできません。 イーサリアムは、イーサリアムノードが再構築防止またはアクティブなプロパティを「強制」するのと同じ真に「強制された」有効性を持っていません。 反リストラと活力は、あなたがそれらを誰から得るかに大きく依存します。

詐欺チェーンベースのロールアップを考えてみましょう。

*ロールアップのフォーク選択ルールはチェーンの先端に従います→チェーンが再編成されると、ロールアップも再編成されます。 *ロールアップの必須の包含メカニズムとシーケンサーの削除は、詐欺チェーン上のクロスチェーンブリッジングコントラクトを通じて適用されます→ 詐欺チェーンの元帳が停止すると、ロールアップの元帳も停止します。 詐欺チェーンがロールアップを検閲したい場合は、検閲されます。

ロールアップは、メインチェーンと同じセキュリティ属性を持つ確認ルールを公開することができ、ホストチェーンのコンセンサスの割合で最大で受け取ることができます(実際、ロールアップがメインチェーンに公開される頻度によっては、通常は遅くなります)。

ロールアップは、ユーザーエクスペリエンスを向上させるために、より緩和された確認ルール(つまり、シーケンサー)を備えた「ハッピーパス」を提供することもできますが、失敗した場合に備えてトランザクションのロールバックを保持します。 シーケンサーが停止した場合は、移動を続けることができます。 ただし、チェーンが独自のバリデーターのセットに完全に依存している場合(つまり、統合チェーンとして)は当てはまりません。

ロールアップのメインチェーンを賢く選択すると、セキュリティ属性に具体的な影響を与える可能性があります。 強力な活動(元帳の成長+ CR)と再編成への抵抗を持つバックチェーンを活用することは特に価値があります。

期間ごとに異なるセキュリティの前提条件

簡単な例を見てみましょう。 チェーンXは、既存のメインチェーンにロールアップとして展開するか、独自の統合ブロックチェーンとして展開するかを決定しています。

ロールアップには次の特性があります。

  • 10秒のブロック時間。
  • DAS ライト ノードがサポートされています *アクティビティと再編成防止のための「高セキュリティ」確認ルール(例えば、分散型の信頼できるバリデーターなど)を提供することができます。

統合ブロックチェーンには、次の特徴があります。

*ブロック出力時間は1秒です。

  • DASライトノードと有効性の証明は、統合ブロックチェーンとして起動されるか、ロールアップとして起動されるかにかかわらず、実装できます。 *集中型シーケンサーが実装されている場合-活性と再結合に対する耐性に関する「安全性の低い」確認ルールを提供します。 *独自の分散型コンセンサス(事前確認されたロールアップシーケンサーセットまたは統合チェーンバリデーターセットのいずれか)を実装する場合、アクティビティと再編成防止のための「中程度のセキュリティ」確認ルールを提供します。

次の表は、さまざまな実装でユーザーが持つことができる最高のセキュリティ保証を簡略化したものです(つまり、利用可能な最も強力な受信確認ルールを使用します)。 特に、ここでは活性と組換えに対する耐性に焦点を当てます(チェーンはこれら2つの場合にのみDAS+の有効性の証明を達成すると想定しているため)。

ロールアップの「究極のセキュリティ」は、メインチェーンが独自のブロック時間よりも速く私たちを保証できないため、「リアルタイムセキュリティ」よりも高くなっています。 シーケンサーの事前確認応答が有効な状態遷移であることは確認できますが、最終的に DA レイヤーに到達するまで、その最終性を完全に保証することはできません。

しかし、これまで見てきたように、ロールアップ方式で強力なメインチェーンにデプロイすると、セキュリティが強化されます。 彼らはメインチェーンの速度でセキュリティを借りることができます。 基本的に、メインチェーン自体のコンセンサスよりも速くメインチェーンのすべてのセキュリティ属性を取得する方法はありません。

ただし、ユーザーはせっかちになる傾向があります。 その結果、ロールアップは通常、より迅速な事前確認を提供しますが、この期間中の保証は低くなります。 ロールアップでは、バランスのとれたシーケンサー設計を選択できます。

*実用的な機能性と効率性。 たとえば、集中型シーケンサーは、迅速な事前検証を提供し、運用オーバーヘッドを削減できます。 *強力な保証。 たとえば、分散型シーケンサーの信じられないほどのセットは、より優れたリアルタイムアクティビティを提供できますが、運用コストと遅延が高くなります(最も極端なケースでは、DAレイヤーにロールアップの順序を処理させ、より高速なパスを公開しないことを選択します)。

興味深いことに、L1 順序ロールアップは、タイム スケールによっては集中型シーケンサーよりもアクティブではないと主張することができます。 これまで、ある種の「有限時間」の概念でそれを含む活動について話してきました。 ただし、これは完全に相対的で主観的なものです。 何に対して? どのくらい時間がかかりますか?

純粋なL1シーケンシャルロールアップは、L1ブロックの速度(10秒など)でのみ含まれ、周囲の世界が変化したときにこれらのブロック間のアクティビティが保証されることはありません。 だからそれはあなたのベンチマークに依存します:

  • ベースライン = ロールアップ内の操作の場合、L1 シーケンシャル ロールアップの方がアクティビティが向上する可能性があります。 メインチェーンが確認されるまで、チェーンの他の誰も約束されるべきではないので、あなたは皆対等な立場にあります。
  • ベースライン = ロールアップ外での操作の場合 - ソフト事前認定を使用したロールアップにより、より良いアクティビティを提供できます。 事前確認は単なる無料のオプションであり、メインチェーンの速度でメインチェーン保証にフォールバックしますが、その間、より弱い保証を得ることができます。 それらを信頼しない場合は、メインチェーンの確認を待つだけです。 世界はイーサリアムブロック間で凍結せず、多くのアプリケーションでは、長いブロック時間の間の古い価格は受け入れられないかもしれません。

事前確認なしで「実際の」ベースのロールアップを実装しようとすると、とにかく事前確認が発生する可能性さえあります。 イーサリアムビルダーやバリデーターなどの参加者には、このコミットメントを自分で行うための金銭的インセンティブがあります。 これがまさに、イーサリアムビルダーと利害関係者がベースレイヤーで迅速な事前確認を提供しようとしている方法について議論されている理由です。

最後に重要な注意事項をもう1つ紹介します。 ロールアップユーザーがメインチェーンと同じレベルのアクティビティにフォールバックできると仮定すると、メインチェーンブロックの速度で完全にインクルードを強制できると仮定します(たとえば、ロールアップ注文者があなたをレビューしている場合、トランザクションをメインチェーンの次のイーサリアムブロックに強制的に含めることができます)。

実際には、通常は短い遅延があります。 即時の強制的な包含を許可すると、他の複雑さとともに有益な検閲MEVを公開するリスクがあります。 ただし、一部の設計では、メインチェーンからほぼリアルタイムのアクティビティ保証を提供できます(たとえば、1つのブロックではなく複数のメインチェーンブロックの速度で)。

正確なタイムスケールに関係なく、主鎖の吸収の究極の活動は非常に強く、調整メカニズムとして強力な主鎖を使用することは、信頼できる脅威と出口の権利を提供します。 この信頼できる脅威が公開されただけで、そもそも悪意のある動作を防ぐために必要になる可能性はほとんどありません。

たとえば、ユーザーがオペレーターを強制的に終了したり、強制的に削除したりする信頼できるメカニズムを持っている場合、集中型ロールアップシーケンサーはユーザーから家賃を任意に抽出してロックインすることはできません。 これは、Chris GoesがMEV変換コストエッジとスローゲームに関する講演で説明した一般的な領域です。

もちろん、予期しないアクティビティも発生する可能性があり、その場合、このバックアップパスも非常に価値があります。

証明はチェーンを保護するのではなく、ユーザーを保護します

これらすべてに続いて、特定の確認ルールについて、「ロールアップ」自体を保護するよりも、ロールアップのさまざまな「オブザーバー」(ユーザー)を保護する方が正確であることがわかります。 「ロールアップ」のセキュリティは、単一の特定の手段としては存在しません。

もちろん、私たちは皆チェーンのオブザーバーであるため、オブザーバーの安全を確保することが最も重要なことです。 このチェーンは、そのオブザーバーが言うことは何でもです。 安全な方法でそれを観察できない場合は、他の誰か(検証者など)を信頼して、それについての「真実」を伝える必要があります。 しかし、私たちは信頼したくありません、私たちは検証を望んでいます→私たちは証拠を望んでいます。

「プルーフオブチェーン」と「プルーフチェーンのオブザーバー」を区別することが重要である理由を理解するには、次の点を考慮してください。

*ライトノード - ロールアップライトノードは、証拠があればより安全であり、誰かの言葉の妥当性を信頼する必要はありません。 *フルノード - 証明がある場合、ロールアップのフルノードのセキュリティは増減しません、あなたは組み込みのブリッジや証明なしでロールアップ(「悲観的なロールアップ」)を開始することができます、有効性の証明の送信を開始すると、フルノードのセキュリティは増減しません。

Proven は、有効性を直接チェックできないチェーンオブザーバー(つまり、ライトノード)にセキュリティを追加します。 ユーザーが強力なフルノードを実行する必要がないようにするため、これらの証明は重要です。

構成証明でロールアップ ブリッジをセキュリティで保護

ロールアップの検証ブリッジは非常に重要なオブザーバーです! 証拠は橋の安全性を保証しています!

一般的なライトノードと同様に、ブリッジはロールアップの有効性を直接チェックすることはできません。 私たちは正直な多数派を信じていませんが、証拠で橋を守ります。 データベース A (DA レイヤー) のコンセンサス プロトコルは、データ BLOB を並べ替え、ブリッジがデータベース B に対する対応する更新の有効性を個別にチェックすることを確認します (ロールアップ)。

ブリッジは別のチェーンのオブザーバーであり、作成される各アセットには、対応するブリッジの確認ルールのセキュリティ前提が常に含まれています。 その確認ルールのセキュリティは、幅広い影響を与える可能性があります。 そのため、安全なブリッジを構築することが非常に重要です(理想的には、そもそもシングルチェーンの実行をさらに拡張することで、非常に多くのブリッジの必要性を減らします)。

チェーンのフルノードを実行すると、悪意のある当事者がユーザーをだまして無効な状態遷移を受け入れることはできません。 ただし、悪意のある当事者が異なる確認ルールを持っている場合でも、ブリッジをスプーフィングできます。 担保資産をブリッジに保有している場合、資金がサポートされなくなる可能性があります。 この意味で、スプーフィングブリッジのセキュリティ障害は「伝染性」です。

Terraに関する古い架空のシナリオを考えてみましょう。

  • Terraには独自のバリデーターのセットがあり、ネイティブトークンはLUNAであり、ネイティブUSTを発行できます。
  • Osmosisには独自のバリデーターのセットがあり、そのネイティブトークンはOSMOです。
  • 標準のTerra ←→ Osmosis IBCブリッジがあり、各側が他のチェーンのコンセンサスバリデータライトノードを実行します(つまり、ブリッジの両側は、他のチェーンのバリデーターセットの正直な過半数に依存します)。 *ユーザーとしてチェーンごとに独自のフルノードを実行します。
  • IBCを介してブリッジされた浸透のUSTをosmoUSTと呼びます。
  • IBC経由でブリッジされたテラのOSMOをテラオスモと呼びます。 *あなたはテラにテラオスモを所有しています。 *あなたは浸透のosmoUST / OSMOプールでLPを行っています。

Terraの崩壊により、LUNAの価格は急落し、最終的には、理論的に悪意のあるバリデータのセットの利益は、ステークされたLUNAの価値を超え、Terraバリデーターは無効なブロックに署名して次のことを実行できます。

*ミント偽のUST→オスモシスにクロスチェーンしてosmoUSTをミントし、それを使用してすべてのosmoUST取引ペアを使い果たします(たとえば、すべてのOSMOをosmoUST / OSMOプールから取り出します。 *偽のテラオスモ→クロスチェーンを浸透にミントして、テラオスモをサポートするオスモシスにロックされているすべてのネイティブOSMO担保を撤回し、テラに残っているすべてのテラオスモはサポートされなくなります。 *まあ、セキュリティはここで失敗します: *フルノード(私) - 私のフルノードはTerraブロックを無効として認識して拒否し、Terraバリデーターは私のterraOSMOまたはosmoUST / OSMO LPポジションを盗むことはできません。 *ライトノード(ブリッジ) - ブリッジはTerraのコンセンサスがブロックで署名されていることを確認するだけです(有効な状態遷移をチェックしません)ので、それらを拒否しません、Terraバリデーターは私のterraOSMOをサポートするOSMO担保を盗み、osmoUST / OSMOプールからすべてのOSMOを排出することができます(価値のないosmoUSTの束を残します)。

ブリッジは、より強力な信頼の前提を持つ確認応答ルールを使用します。

Terraバリデーターは、フルノードからTerra自身の資産を大量に盗むことはできず(だまされることはありません)、これらのブロックを拒否します。 ただし、バリデーターはコンセンサスバリデーターをだましてライトクライアント(ブリッジを含む)にする可能性があるため、コンセンサスエラーはクロスチェーンアセットに影響を与えます。

これらの障害がチェーンの残りの部分に「感染」しない、つまり、障害がTerraブリッジルートにさらされているOsmosis資産に「感染」することが重要であるが、Osmosisチェーン自体にはセキュリティ障害がないことに注意してください。

しかし、私たちは明らかに物事を橋渡ししたい(一般的にはクロスチェーン通信)、メインチェーンでネイティブアセットを使用することに限定するのは悪いことであり、安全に通信し、チェーン間で橋渡しするためのチェーンが必要です。

思考実験として、最も簡単な解決策は、各ユーザーにクロスチェーンブリッジ自体を含む各チェーンの完全なノードを実行させることです。 いくつかの一方向の組み込みフルノードブリッジを見てきたことを覚えておいてください。

*イーサリアムのロールアップは現在、ノードがイーサリアムのフルノードを実行する必要があり、これらのロールアップはイーサリアムのコンセンサスを共有しています。 ナマダ(ロールアップチェーンではなく、別のテンダーミントチェーン)は、ノードがイーサリアムのフルノードを実行する必要がありますが、ナマダはイーサリアムのコンセンサスに同意しません(つまり、イーサリアムにデータを公開したり、それに基づいて状態を導き出したりしません)。

これはイーサリアムのフルノードでは機能しますが、これは明らかに拡張できません。 各 Cosmos チェーンを他のすべての Cosmos チェーンに対して完全なノードを実行するだけで済むようにすることはできません。 これらの双方向フルノードブリッジは拡張できず、ハードウェア要件が増加するだけです。

幸い、よりスケーラブルなオプションがあります。 ブリッジを展開して、別のチェーンの状態の有効性とDAを完全に検証できます(コンセンサスをチェックすることに加えて)。

状態の有効性 - IBCは現在、従来のコンセンサスの証明で使用されていますが、チェーンを接続するための有効性の証明を追加するように変更でき、ブリッジは無効な状態遷移によってスプーフィングされなくなりました。 これにより、前述の攻撃を正確に防止し、ブリッジが状態遷移の有効性を確認できた場合、Terraバリデータのブロックを無効として拒否したことになります。

これは、イーサリアムのロールアップブリッジがロールアップ証明をチェックする方法と非常によく似ていますが、双方向にすることもできます。

DA - さらに、チェーンでは、チェーンを接続する DAS ライトノードを実行するためにノードが必要になる場合があります。 たとえば、2 つの Cosmos チェーンで、他のチェーンの DAS ライトノードを実行するために独自のバリデーターが必要な場合があります (各チェーンが現在サポートされていない DAS ライトクライアントを実装している場合)。 これが完了すると、各チェーンは、フルノードを実行しなくても、互いの有効性とDAを知ることができます。

ロールアップの場合、定義上、メインチェーン上のすべてのデータを所有しているため、そこにあるブリッジはそれにアクセスできます。 一方、ロールアップ ノードはメインチェーン ノードを実行します。

従属チェーンと独立チェーン

イーサリアム上のロールアップのロールアップ検証ブリッジを観察するコンテキストで、5つのセキュリティ属性をもう一度見てみましょう。

*元帳の成長–イーサリアムバリデーターは、ロールアップの元帳を成長させ続けることができます(例:包含トランザクションを強制します)。 *検閲耐性 - イーサリアムバリデーターは、ロールアップのオペレーターに無期限に検閲しないように強制することができます(たとえば、トランザクションの包含やシーケンサーの置換を強制します)。 *反リストラ-ロールアップの反リストラはイーサリアムに関連しています。 イーサリアムが再編成されると、イーサリアムのすべてのロールアップが再編成されます。 *データの可用性 - ロールアップは定義上、メインチェーンコンセンサス(ロールアップ契約が配置されている場所)によって確認されたデータから派生し、ロールアップとメインチェーンはマージコンセンサスを共有し、DAはイーサリアム自体の有効条件であるため、ロールアップのDAは保証されています。 ブリッジは、信頼の前提を追加することなくメインチェーン上のデータにアクセスできます。 *状態の有効性 - コントラクトはロールアップ状態遷移の有効性証明をチェックし(またはチャレンジウィンドウが通過するのを待ちます)、宣言された状態の更新がメインチェーンで確認された対応するデータにロールアップのSTFを適用した有効な結果であることを証明します。

ブリッジのセキュリティは、追加のチェーンに対する超強力な確認ルール(たとえば、非常に信頼できるバリデータのセットを持つチェーンへの完全なバリデータブリッジ)によって最大化されるだけではないことに注意してください。 ブリッジがメインチェーンと同じセキュリティの前提を持っている場合、クロスチェーンのネイティブアセット時に最大のセキュリティを得ることができます。

ヴィタリックは有用な実例を提供します:

「100 ETHをソラナに架かる橋に転送し、100ソラナ-WETを取得すると、イーサリアムは51%攻撃されます。 攻撃者はETHの束をソラナ-WEHに預け入れ、ソラナ側が確認するとすぐにイーサリアム側で取引を再開します。 ソラナ-WETH契約は完全にはサポートされなくなり、100ソラナ-WETHの価値は60ETHしかない可能性があります。 コンセンサスを完全に検証する完璧なZK-SNARKベースのブリッジを使用しても、このような51%の攻撃に対して脆弱です。

したがって、イーサリアムのネイティブ資産をソラナまたはソラナのソラナネイティブ資産に保持するよりも、ソラナのイーサリアムネイティブ資産またはソラナのネイティブ資産にイーサリアムのネイティブ資産を保持する方が常に安全です。 この文脈では、「イーサリアム」は、基礎となるチェーンだけでなく、その上に構築された適切なL2も指します。

イーサリアムが51%攻撃されて回復すると、アービトラムとオプティミズムも回復するため、イーサリアムが51%攻撃されても、アービトラムとオプティミズムに状態を保存する「クロスロールアップ」アプリケーションは一貫性を保つことが保証されます。 イーサリアムが51%の攻撃を受けていなかった場合、アービトラムとオプティミズムに対してそれぞれ51%の攻撃を行う方法はありません。 したがって、アービトラムベースの楽観主義によって発行された資産を保有することは依然として完全に安全です。

Solanaを任意のチェーンに置き換えることができます-信頼の点でイーサリアムバリデーターを超える架空のチェーンでさえ、基本的に、資産を記録元帳(イーサリアムのETH)でクロスチェーンすることについて話す場合、セキュリティの仮定は追加的であり、接続されたチェーンの再編成またはアクティビティの失敗の可能性は常にあります。

ただし、マージされたコンセンサスを持つチェーン(つまり、メインチェーンのコンセンサスを共有するロールアップ)は、これらの追加のセキュリティの仮定を回避できます。 これらの異なる領域間のクロスチェーンブリッジは、主鎖自体と同じ最終活性および抗組換え特性を有することができる。 共有コンセンサスは、その共有セキュリティゾーン内のクロスチェーン信頼の仮定を最小限に抑えます。

合理的なセキュリティの前提はあなた次第です。 実際、主要チェーン間で同様のコンセンサスの失敗はありませんでした。 これは明白でコストがかかりますが、弱いチェーンを接続することについてのより強い仮定である可能性があります。

ロールアップチェーンをメインチェーンにバインドすることにはいくつかの欠点もあります。 2つのクロスチェーンシナリオを比較してみましょう、どちらの場合も、双方向の完全バリデータークロスチェーンブリッジングを使用する2つのチェーンがあります。

*依存関係 - リモートチェーン(すなわちロールアップ)はメインチェーン(すなわちDA層)のコンセンサスを共有し、メインチェーン上のデータから独自の状態を導き出し、リモートチェーンはメインチェーンとフォークし、メインチェーンに基づいてその最終性を決定する必要があります。 *独立 - これらのチェーンは独自の独立したコンセンサスを持ち、他のチェーンのデータに基づいて独自の状態を導き出すことはありません。 リモートチェーン(つまり、ロールアップ)←→メインチェーン(つまり、DAレイヤー)の関係を共有しません。 それらは一緒に再グループ化されず、互いの活動に依存しません。 *興味深いことに、これらは良い面と悪い面の両方です。 *悪い - 他のチェーンでチェーンを再編成したり、アクティビティが失敗したりすると、一見すると欠点のように聞こえるかもしれませんが、チェーンが壊れているためにチェーンに問題があるのはなぜですか? *良い - この発散がチェーンに深刻な問題を引き起こす場合、これは実際には重要な利点です(たとえば、ソースチェーンからのクロスチェーン資産が多数ある場合、クロスチェーンブリッジの観点から再編成され、裏付けのない担保が残ります)、チェーンとそのクロスチェーンブリッジは互いに一貫している必要があります。

同様に、ロックインと過度のレントシーキングは潜在的なプラスとマイナスの効果をもたらし、中立的で検閲に強いベースレイヤーが非常に重要である理由を強調しています。

*良い - 良いメインチェーンは、ロールアップオペレータがそれらからあまりにも多くの価値を絞り出し、終了特権を強制することからロールアップユーザーを保護します。 *悪い - 悪いバックチェーンは、価格を任意に膨らませ、ロールアップとそのユーザー自身からその価値を引き出す可能性があります。 *送信の証明+共通のメインチェーンを共有する代わりに双方向でDASを実行することにも、いくつかの非効率性があります。 *ノードが他のチェーンのDASライトノードの束を実行する必要はなく、新しいチェーンを手動で追加する必要がある場合、巨大な共有DAレイヤーでDASを実行する方がはるかに効率的です。 *各チェーンが多くの異なるチェーンの有効性を検証することは非効率的ですが、理論的には、チェーンクラスター全体がチェーンに1つの証明を公開するだけで済むように、複数のチェーン間で証明を集約することは可能です。

ここにはトレードオフと利点がありますが、興味深い資産がどこにあるかには大きなパス依存があり、イーサリアムネイティブの資産(ロールアップのものを含む)の束を使用したい場合は、チェーンをイーサリアムとそのクロスチェーンブリッジに根付かせることは理にかなっています。

まとめ

「ロールアップ継承セキュリティ」は良い省略形ですが、次の点が私たちが本当に意味する重要なポイントであることを忘れないでください。

*ロールアップは、消費するリソース(DA)に対して、イーサリアムなどのメインチェーンに家賃を支払います。

  • ロールアップは、メインチェーンまでのセキュリティプロパティを持つ確認ルールを公開できます(つまり、ユーザーはメインチェーン自体を操作する場合と同じセキュリティ保証を得ることができます)。 *ユーザーは、メインチェーンのコンセンサスの速度でこれらのメインチェーンのセキュリティ属性を取得します。
  • ロールアップ ユーザーがメイン チェーンによって提供される確認よりも高速にしたい場合は、追加の一時的なセキュリティの前提を作成する確認ルールを使用できます。 *オブザーバー(つまり、ユーザー)は確認ルールを介してロールアップと対話し、信頼度が最も低い検証ブリッジはそのような(オプションですが、非常に価値のある)オブザーバーです。

ここで、統合チェーンにロールアップをデプロイする利点について考えてみましょう。

ユーザーの安全性 - クロスチェーンブリッジを実装するかどうかにかかわらず、ロールアップはメインチェーンからDAをリースしてコンセンサスを取り戻すことができるため、ロールアップは独自のコンセンサスに達することなくメインチェーンに一致する確認ルールをユーザーに公開できます。

クロスチェーンセキュリティ - ロールアップは、メインチェーンの共有セキュリティドメイン(つまり、メインチェーン自体とそのロールアップ)内にクロスチェーンを構築でき、そのセキュリティプロパティはメインチェーン自体で動作するのに匹敵します。

これは実際には同じコインの両面であり、ロールアップはチェーンが確認ルールを提供できるようにするだけで、そのセキュリティはメインチェーンのセキュリティに到達できることがわかります。 クロスチェーンブリッジと通常のユーザーの両方が、特定の確認応答ルールを持つチェーンのオブザーバーです。 橋は、そのセキュリティが幅広い影響を与えるため、おそらくこれらのチェーンで最も重要な「オブザーバー」です。

安全なシステムを作成しようとすると、特定の確認ルールのセキュリティとそのアクセシビリティに注意する必要があります。 これらのチェーンと対話するほとんどのオブザーバー(ユーザー)が手の届かないところにある場合、セキュリティ確認ルールはあまり役に立ちません。

現在、DAS と有効性の証明はロールアップに関連付けられていますが、論理的には別の概念です。 どのチェーンもこれらのテクノロジーを統合でき、ロールアップとロールアップではないものの区別は、ゲームの終わりに崩壊し始めます(つまり、単一の統合されたロールアップの場合、1つのプロトコルの下に論理的に分離されたDAレイヤーと実行レイヤーを持つ場合があります)。

ただし、「従来のロールアップ」レイヤーとDAレイヤーは、今日のこれらの検証およびスケーリングテクノロジーを支配していることは明らかです。

原文表示
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • コメント
  • 共有
コメント
0/400
コメントなし
いつでもどこでも暗号資産取引
qrCode
スキャンしてGateアプリをダウンロード
コミュニティ
日本語
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)