著者: シヴァンシュ・マダン、編纂者: Huohuo/Vernacular Blockchain

最近 Twitter での議論の多くは L2 分散化を中心に展開しています。私たちが構築しているロールアップは十分に分散化されていますか?それとも少なくとも分散化への道を進んでいるのだろうか？関係ありますか？

ロールアップのアイデアはシンプルです。オフチェーンの参加者がトランザクションを実行できるようにし、その後オンチェーンで簡単に検証できるようにしたいと考えています。 Rollup を使用すると、ベース層により、その「信頼」のベースをその直接の領域の外側で発生するアクティビティに使用できるようになります。その見返りに、Rollup はこの信頼を活用するために少額の手数料 (家賃) を支払います。

では、分散型ロールアップは必要なのでしょうか?

直感的な答えは「はい」です。これが私たちがブロックチェーンを構築する精神です。

しかし、この質問に対する答えは単純に「はい」か「いいえ」ではないと思います。代わりに、個別に分析する必要がある複数の側面があります。次の章では、この疑問を哲学的、技術的、経済的という 3 つの観点から分析していきます。 ****これら 3 つは必ずしも網羅的または排他的ではありませんが、問題の全体的な見通しを適切に提供するはずです。 **

1. 哲学的な視点

まず、会話を 1 つ上のレベルに引き上げることから始めましょう。なぜ私たちは分散化に関心があるのでしょうか?

私たちはオープンイノベーションを推進するパーミッションレスの未来を望んでいるからです。私たちは、ユーザーが何の制限もなく、単一のエンティティを信頼する必要もなく、新しいものを構築できるようにしたいと考えています。

ブロックチェーンの短い歴史の中で、多くの匿名の開発者が素晴らしいものを構築してきました。実際、ビットコイン自体は匿名の組織によって作成されました。近い将来、ビットコインは世界中のほとんどの人が国際的な支払いに使用する通貨になるかもしれません。それが許可のないイノベーションの力です。

ブロックチェーンを使用すると、共通点のない人々と協力することができ、その信頼を打ち破る方法がないことを私たちは知っています - プレストン・エヴァンス

ビットコインやイーサリアムのようなトラストレスネットワークの分散型基盤により、私たちはそのような未来を構築することができます。したがって、Rollups など、これらのチェーンと信頼関係があるチェーンも分散化する必要があることは明らかです。

実際、これは興味深い重要な疑問を引き起こします。

**ロールアップが分散化されていない場合、それはイーサリアムが分散化されていないことを意味しますか? **

これを少し楽観的に見ると、パーミッションレスの世界では、ロールアップは完全にパーミッションされたチェーンを含む (ただしこれに限定されない) 必要なものをすべて構築できるようにする必要があり、そのロールアップのユーザーは依然としてセキュリティを活用できるはずです。ベースレイヤー。ベースレイヤーが分散化され、ロールアップが「完全に」実装されている限り、許可チェーンであっても安全に使用できるはずです (「完全に実装」については技術セクションで詳しく説明します)。

しかし現実には、今日のほとんどのロールアップはまだ完全な実装段階に達しておらず、ユーザーに望ましいレベルのセキュリティとトラストレス性を提供していません。

では、ロールアップの正しい実装はどのようなものでしょうか?見てみましょう：

2. テクノロジー

ロールアップレベルでの分散化とセキュリティの問題を真に理解するには、第一原則から考える必要があります。スリーラム・カナン氏以上にブロックチェーンの第一原理を説明できる人は多くありません。

ブロックチェーンは分散型台帳であり、ネットワーク内のさまざまなノードが定義されたプロトコルに従って台帳の状態に関する合意を取得します。これらのノードがネットワークをどのように認識しているかに応じて、ノードは独自の台帳でネットワークの正しい状態を確認するための異なるルールを持つことができます。

たとえば、イーサリアムのギャスパー プロトコルには、利用可能なルール (最も重いチェーンに基づく) と最終ルール (ガジェットによって確認されたブロックに基づく) という 2 つの異なる確認ルールがあります。

特にロールアップでは、フル ノードにはライト クライアントとは異なる確認ルールがあります。従来のスマート コントラクト ロールアップ (SCR) では、スマート コントラクト (検証ブリッジ) に独自の確認ルールがあります。有害事象がない場合、これらの確認ルールは最終的にいわゆる「一致領域」で一致します。名前が示すように、コンセンサス ゾーンでは、すべての参加者がネットワークに対して同じビューを持ちます (台帳には同じ履歴があります)。

すべての確認ルールが安全であれば、悪いことは起こりません。 Sreeram が上記の投稿で共有したように、主に 5 つのプロパティがこれらの確認ルールのセキュリティを定義します。

1. 台帳の成長 - ロールアップ チェーンは成長し続ける必要があります (活性化)
2. 検閲への耐性 - すべてのユーザーは、あらゆるトランザクションをベースレイヤーに含めることができる必要があります
3. リストラへの抵抗 - 一度完了した取引は元に戻すべきではありません
4. データの可用性 - 取引データはどこかに公開される必要があります
5. 有効性 - トランザクションと状態遷移は有効である必要があります

最初の 2 つのプロパティはシステムの「ライブ」状態を定義し、最後の 3 つのプロパティは「安全」状態を定義します。

さまざまな集約アクターの観点からそれぞれを見て、分散化せずにどれを軽減できるかを見てみましょう。

さまざまなアクターが、安全性と生存性を確保するためにさまざまなメカニズムに依存しています。

フルノード:

フルノードを実行すると、公開されたデータにアクセスでき、それを直接検証できます。その後、そのデータを使用して自分でトランザクションを実行し、トランザクションの有効性とトランザクション後のロールアップの最終状態を判断できます。

したがって、残りの安全条件は活性特性と組換え耐性です。後者の場合、フル ノードは基礎となるチェーンのバリデーターと使用するコンセンサス プロトコルに依存しますが、ライブネス プロパティの場合、フル ノードはシーケンサーとロールアップ実装に依存します。

ライトクライアント:

ほとんどのユーザーは、ライトノードに埋め込まれたウォレットを使用するか、サードパーティのサービスを使用してブロックチェーンデータを取得し、ブロックチェーンと対話します。ライト ノードにはさまざまなタイプがあります。

• State Validator - 状態遷移の有効性を検証します。
• DA Validator - データの可用性を検証します。
• **コンセンサスバリデータ - ベースレイヤーのコンセンサス証明を検証する、または **
• 完全な検証者 - 上記のすべてを検証します

フルバリデータライトクライアントを実行する場合、データ可用性サンプリングを通じてデータが利用可能であることを検証でき、有効性証明または不正証明を通じて状態遷移の妥当性を検証でき、ベース上で状態が最終化されていることも検証できます。レイヤーのコンセンサス (イーサリアムでは、同期委員会に従うことでこれを行うことができます)。

残りの安全条件は liveness プロパティであり、ライト クライアントはシーケンサーとロールアップの実装に依存します。

組み込みのスマート コントラクト (検証ブリッジ):

従来の SCR では、スマート コントラクトの「確認ルール」は、次の 5 つのセキュリティ プロパティすべてを強制することです。

• シーケンサー置き換えプロトコルによる台帳の増加
• 包含を強制することで検閲に抵抗します
• 以前の状態の上にのみ再編に対する抵抗力を構築する
• データの可用性は、ベースレイヤーで DA を送信することで実現されます。
• 有効性/不正行為の証明による有効性の検証

SCR のフル ノードは、スマート コントラクトに依存して活性プロパティを強制します。それらはベース層からの再構築抵抗を「吸収」します。

ライトノードは、スマートコントラクトに依存してライブネス特性を強化し、ベースレイヤーからの DA と再編成の抵抗を吸収します。有効性の証明は自分自身で、またはスマート コントラクト経由で検証できます。

SCR のコンセンサスは、スマート コントラクトによって定義された正規チェーンに従うことです。

**ソブリン ロールアップについてはどうですか? **

ソブリン ロールアップには、有効性や生存条件を強制するためのスマート コントラクト (検証ブリッジ) がありません。代わりに、下流のロールアップ ノードに「ロールダウン」することが証明されます。これらのノードは依然として DA および Reorg の抵抗をベース層から吸収します。

SCR と同様に、ソブリン ロールアップ ノードでは liveness プロパティを強制する何らかのメカニズムが必要です。正規チェーンを定義するために、彼らは p2p プルーフをブロードキャストするなどの独立したメカニズムを選択しました。

これらすべてが分散化とどのような関係があるのでしょうか?

スマート コントラクト ロールアップであってもソブリン ロールアップであっても、liveness プロパティはロールアップの正しい実装から得られます。上で見たように、集計を正しく実装するには、次の 2 つの重要なコンポーネントが含まれている必要があります。

1. 強制的な包含メカニズム、および

2. シーケンサー交換プロトコル

強制的に含めることは、検閲への抵抗力を高めるのに役立ちます。このメカニズムにより、ユーザーはトランザクションを基本層に直接「強制的に含める」ことができます。ロールアップ内のユーザーは、資金を持って強制終了して基本レイヤーに戻ることができます。したがって、集約用の集中型照合ノードが 1 つしかない場合でも、成熟した強制メカニズムが整備されている限り、ユーザーを検閲することはできません。

しかし、それだけで十分でしょうか？

たとえユーザーがログアウトできたとしても、ほとんどのユーザーが L1 に戻ってしまうと、企業には実行を続けるインセンティブがあまりないことを意味する可能性があります。また、必須の包含メカニズムは通常待ち時間が長く、平均的なユーザーにとって実装するには非常に高価な場合があります。このメカニズムによって提供される検閲耐性は、厳密には実用的 (またはリアルタイム) ではありません。この状況を「弱い検閲」と呼ぶことができます。

次に、最後の活性属性である台帳の成長があります。

集中型照合装置が悪意のあるものになった場合、ブロックの生成を停止するだけで概要チェーンの成長を止めることができます。この問題が発生した場合、ユーザーまたは企業がロールアップを再び「有効」にするためにできることは何もありません。

この問題を解決するには、シーケンサー置き換えプロトコルが必要です。

シーケンサー置換プロトコルの考え方は、シーケンサーが悪意のある動作をした場合に、集合ガバナンスがシーケンサーを起動できるというものです。これを実現する方法の 1 つは、集中型シーケンサー ノードを分散型シーケンサー プロトコルに置き換えることです。ソーターが分散化されており、ロールアップの構成要素を独占していない場合、ロールアップを停止することはほぼ不可能です。

したがって、ユーザー資金は強制包含メカニズムを通じてロールアップ内で常に安全ですが、堅牢な注文者置換プロトコルを構築することでロールアップを存続させ、実用的なリアルタイムの検閲耐性を提供します。

これで全部ですか？

完全ではありません。技術的な観点から見ると、考慮すべき点がもう 1 つあります。

スマートコントラクト自体が集約された中央委員会によってアップグレードできたらどうなるでしょうか?ロールアップは現在正しく実装されていますが、明日委員会はスマートコントラクトを必要とせず、代わりにロールアップ状態の証明を p2p ネットワークにブロードキャストすることに同意したとします。

ロールアップ ユーザーとしてそのようなアップグレードに同意しない場合は、アップグレードが実装される前にロールアップを終了できる必要があります (ただし、繰り返しになりますが、これはユーザー エクスペリエンスが良くなく、ビジネスにとっても良くない可能性があります)。これは「ガバナンスの更新の遅れ」を通じて実現できます。これは、アップグレードが実装されるまでの「通知期間」のようなものです。アップデートに同意しないユーザーは、通知期間内に退会することができます。

分散化の究極は、完全に不変のスマート コントラクトを持つオプションです。これらのコントラクトは、マルチシグネチャウォレットやその他の委員会によって管理されず、一度デプロイされるとアップグレードすることはできません。

もちろん、これにはそれ自体の問題があります。コードにバグがある場合、または重大なイベントでスマート コントラクトの更新が必要な場合、アグリゲーション ノードの唯一の選択肢は新しいスマート コントラクトにフォークすることであり、ユーザーの資金は古いコントラクトに残されたままになります。

＃＃＃＃ 現在のステータス

残念ながら、Rollup の現在の状態は、上で説明した完全な実装には程遠いです。ほとんどのロールアップはまだ「補助輪」段階にあり、正しく調整しようとしています。

L2BEAT によると、Fuel v1 と DeGate は、すべてのアクティビティと安全性の条件を達成できるまでに成熟した唯一の 2 つの集合体です。

3. 経済性

ユーザーとロールアップ オペレーターの観点からロールアップの経済性を見てみましょう。

1) ユーザー エクスペリエンス - ユーザーは安価な価格で取引を行うことができ、あまり長く待つ必要はありません。

2) ロールアップの利益 - ソーターとトークン所有者がロールアップを運用することで利益が得られるはずです

ユーザーが迅速かつ安価なトランザクションを利用できるようになると、ユーザー エクスペリエンスが最適化されます。

トランザクションが完了する速度は、基本層ブロックが完了する速度によって異なります。 L1 上のデータが最終化されると、トランザクションは最終的なものとみなされます。ただし、フルノードを実行しているユーザーは、単にトランザクションを実行して最終状態を決定するだけで、即座にファイナリティを達成することもできます。

しかし、誰もが完全なノードを実行することは現実的ではありません。したがって、集中照合装置は、トランザクションがブロックに含まれており、最終的に完了するという「ソフトな確認」をユーザーに提供できるため、便利です。ほとんどのユースケースではこれで十分です。しかし、それには対抗できる中央政党への依存が伴います。

一部のシーケンサー代替プロトコル ソリューション (例: ロールアップに基づくもの) はユーザーに不利益をもたらすこの特性を無視していますが、他のソリューション (例: 外部 POS コンセンサス (例: Espresso)) は、次のリスクを負うことなく同様の事前確認保証を提供できます: 集中型シーケンサー。

ユーザーの負担はどうなるのでしょうか？

通常、ロールアップ トランザクションの明示的な価格は次のとおりです。

L2 ガスのコスト = L1 ガスのコスト + シーケンサー料金

合理的に行動する中央発注者は、たとえそれがユーザーに高いコストを転嫁することを意味するとしても、常に自分自身の利益を最大化したいと考えています。ただし、これは分散型ソーター機構によっても必ずしも解決できるわけではないことに注意してください。分散型発注者の POS ノードでも、自身の利益を最大化したいと考えています。

実際、これにより、アグリゲートが利益を外部の選別業者に引き渡したくないという不整合の問題が発生します。

ロールアップ利益 - シーケンサー料金に加えて、ロールアップはバルク ユーザー トランザクションから MEV を抽出することによっても利益を得ることができます。注文者が独自のフロントランニング トランザクションをバッチに含めたかどうかを確認するのが難しいため、この MEV を特定するのは難しいことがよくあります。

**ロールアップが外部 POS コンセンサスに置き換えられた場合、この MEV は外部オペレータに提供されます。 **

ロールアップが外部メカニズムに収益を引き渡すというこれらの問題は両方とも、ロールアップと外部メカニズムの間の「貿易協定」を通じて解決でき、内部およびロールアップ間のトランザクションによって生成される手数料と MEV を解決できることは注目に値します。概要にリダイレクトします。

ただし、モジュラー サミットでの Jon Charbonneau の講演やその後の投稿で説明されているように、ロールアップ ガバナンスで一連の許可されたノードに注文を委任する方が良いアイデアかもしれません。これらのノードは地理的に分散するように戦略的に選択することができ、ガバナンスによって悪者を簡単に追い出すことができます。

**これは、ロールアップによって社内のマージンを維持しながら、集中型ソーターの悪影響も軽減できるため、一石二鳥のソリューションとなります。 **

しかし、これとは逆に、ソーターの回転が制限されていると、ソーターが近視眼的ではない動作をする可能性があり、それが集約ユーザーを犠牲にして独占価格設定や価格つり上げにつながる可能性があります。

いずれにせよ、要約をユーザーにとって費用対効果の高いものにするためには、何らかのシーケンサー代替プロトコルが必要であることは明らかです。それがガバナンスの証明であるか、外部の合意メカニズムであるか、あるいはその他のものであるかについては、別の記事で議論します。

4 結論

Rollup がどのような道を歩むとしても、ソーターの置き換え、強制的な組み込み、およびラグ ガバナンスの更新のための成熟したメカニズムを備えた完全な実装を目標とすることが重要であることが明らかになったと思います。たとえそれが単なる必須の包含と遅延更新であっても、コーディネーターが一元化されているかどうかに関係なく、ロールアップが完全に実装されていればユーザーの資金は安全です。

ただし、堅牢なシーケンサー置換プロトコルにより、生存性の保証が向上し、ロールアップ ユーザーの経済性が向上する可能性があります。