原作者：シヴァンシュ・マダンオリジナル編集：ルフィ、フォーサイトニュース最近、Crypto Twitter での議論の多くは L2 分散化を中心に展開しています。私たちが構築しているロールアップは十分に分散化されていますか?彼らはすでに分散化への道を進んでいますか？関係ありますか？この記事ではこれらのテーマについて説明します。詳細に説明する前に、ロールアップが実際にどのように機能するかをまだ知らない場合は、この記事「Rollups for Dummies」を簡単に読んでおくことをお勧めします。ロールアップのアイデアは実際には非常にシンプルです。オフチェーンの参加者がトランザクションを実行し、その後オンチェーンで簡単に検証できるようにすることを望んでいます。 Rollup を使用すると、ベースレイヤーの「信頼」がブロックチェーンの外側のアクティビティに拡張されます。その見返りに、Rollup はこの信託を使用するために少額の手数料 (家賃) を支払います。では、分散型ロールアップは必要なのでしょうか?直感的な答えは、「絶対にそうする必要がある」です。これがブロックチェーンの精神です。しかし、この質問に対する答えは単純に「はい」か「いいえ」ではないとも思います。むしろ、これには複数の側面が含まれており、個別に分析する必要があります。以下では、この問題を哲学、テクノロジー、経済学の 3 つの観点から検討していきます。### 哲学的な視点まず、会話を 1 つ上のレベルに引き上げることから始めましょう。なぜ私たちは分散化を気にするのでしょうか?私たちはオープンイノベーションを推進するパーミッションレスの未来を望んでいるからです。私たちは、ユーザーが何の制限もなく、単一のエンティティを信頼する必要もなく、新しいものを構築できるようにしたいと考えています。ブロックチェーンの短い歴史の中で、多くの匿名の開発者が素晴らしいものを構築してきました。実際、ビットコイン自体は匿名の団体によって作成されたものであり、間もなく世界中のほとんどの人が使用する世界的な決済通貨になる可能性があります。それが許可のないイノベーションの力です。ブロックチェーンを使用すると、共通点のない人々と協力することができ、その信頼を打ち破る方法がないことを私たちは知っています。——プレストン・エヴァンスビットコインやイーサリアムのようなトラストレスネットワークの分散型基盤により、私たちはそのような未来を構築することができます。明らかに、Rollup など、これらのブロックチェーンと信頼関係があるチェーンも分散化する必要があります。実際、これは興味深い重要な疑問を引き起こします。Rollup が分散化されていない場合、それは Ethereum が分散化されていないことを意味しますか?これを少し楽観的に見ると、パーミッションレスの世界では、ロールアップはパーミッション付きチェーンを含む (ただしこれに限定されない) 必要なものすべてを構築できるようにする必要があり、そのロールアップのユーザーは依然として基礎層のセキュリティを利用できるということになります。 。基本レイヤーが分散化されており、ロールアップが「完全に実装」されている限り (「完全な実装」については技術セクションで詳しく説明します)、許可されたチェーンであっても安全に使用できるはずです。しかし現実には、今日のほとんどのロールアップは完全な実装段階に達しておらず、ユーザーに必要なレベルのセキュリティとトラストレス性を提供していません。では、Rollup の正しい実装は何でしょうか?見てみましょう：### 技術的な観点Rollup の分散化とセキュリティ上の懸念を真に理解するには、第一原則からそれを検討する必要があります。スリーラム・カナン以上にブロックチェーンの第一原理を説明できる人はほとんどいません。ブロックチェーンは分散型台帳であり、ネットワーク内のさまざまなノードがあらかじめ決められたプロトコル ルールに従って台帳の状態に関する合意を取得します。これらのノードがネットワークをどのように認識しているかに応じて、ノード自体の台帳ネットワークの正しい状態を確認するための異なるルールを持つことができます。特にロールアップでは、フルノードとライトクライアントでは確認ルールが異なります。従来のスマート コントラクト ロールアップ (SCR) では、スマート コントラクト (検証ブリッジ) に独自の確認ルールがあります。有害事象がない場合、これらの確認ルールは最終的にいわゆる「一致領域」で一致します。名前が示すように、コンセンサス ゾーンでは、すべての参加者がネットワークに対して同じビュー (および台帳内の同じ履歴) を持ちます。すべての確認ルールが安全であれば、悪いことは起こりません。 Sreeram が上記の投稿で共有したように、主に 5 つのプロパティがこれらの確認ルールのセキュリティを定義します。* 台帳の成長 - ロールアップ チェーンは成長し続ける必要があります (活性化)* 検閲耐性 - すべてのユーザーがベースレイヤーにあらゆるトランザクションを含めることができる必要があります* リストラに強い - 取引は一度完了すると撤回できません* データの可用性 - トランザクション データはどこかで公開される必要があります* 有効性 - トランザクションと状態遷移は有効である必要があります最初の 2 つのプロパティはシステムの「ライブ」状態を定義し、最後の 3 つのプロパティは「安全」状態を定義します。さまざまなロールアップ参加者の観点からこれらの問題を検討し、分散化せずにどの問題を軽減できるかを見てみましょう。さまざまなアクターが、安全性と生存性を確保するためにさまざまなメカニズムに依存しています。フルノード:フルノードを実行すると、公開されたデータにアクセスでき、それを直接検証できます。その後、そのデータを使用して自分でトランザクションを実行し、トランザクションの有効性とトランザクション後のロールアップの最終状態を判断できます。したがって、残りの安全条件は活性と組換え耐性です。再編成耐性については、フル ノードはベース チェーンのバリデーターとベース チェーンが使用するコンセンサス プロトコルに依存しますが、ライブ性については、フル ノードはシーケンサーとロールアップの実装に依存します。ライトクライアント:ほとんどのユーザーは、ブロックチェーン データをフェッチするライト クライアントを使用してブロックチェーンと対話します。ライトノードにはいくつかの種類があります。* 状態バリデータ - 状態遷移の有効性を検証します。* データ可用性検証ツール - データの可用性を検証します。* コンセンサスバリデータ - ベースレイヤーのコンセンサス証明を検証します* 完全なバリデータ - 上記のすべてを検証します完全な Validator Light クライアントを実行する場合、データ可用性サンプリングを通じてデータが利用可能かどうかを検証し、有効性証明または不正証明を通じて状態遷移の妥当性を検証し、状態が基本層 (上記のイーサリアムの場合) のコンセンサスに従っているかどうかを検証できます。 、同期委員会に従うことで実行できます）。次に、残りの安全条件は活性であり、ライト クライアントはシーケンサーとロールアップの実装に依存します。組み込みのスマート コントラクト (検証ブリッジ):従来の SCR では、スマート コントラクトの「確認ルール」は、次の 5 つのセキュリティ プロパティすべてを強制することです。* シーケンサー置き換えプロトコルによる台帳の増加* 包含を強制することで検閲に抵抗します* 再結合防止のために以前の状態に基づいて構築されます*ベースレイヤーでDAを送信することでデータの可用性を実現*有効性/不正行為の証明によって検証された有効性SCR フルノードは、スマート コントラクトに依存して活性プロパティを強制します。再組織化耐性はベース層から得られます。ライトノードは、スマートコントラクトに依存してライブネス特性を強化し、ベースレイヤーからの DA と再編成の抵抗を吸収します。有効性の証明を自分自身で、またはスマートコントラクト経由で検証できます。SCR のコンセンサスは、スマート コントラクトによって定義された正規チェーンに従うことです。ソブリンロールアップについてはどうですか？ソブリン ロールアップには、有効性または生存条件を強制するためのスマート コントラクト (検証ブリッジ) がありません。代わりに、下流のロールアップ ノードに「ロールダウン」することが証明されます。これらのノードは依然として、ベース層からのデータの可用性と再編成の耐性に依存しています。SCR と同様に、ソブリン ロールアップでは、ノードには liveness プロパティを強制する何らかのメカニズムが必要です。正規チェーンを定義するために、彼らは p2p プルーフをブロードキャストするなどの独立したメカニズムを選択しました。これらすべてが分散化とどのような関係があるのでしょうか?スマート コントラクト ロールアップであってもソブリン ロールアップであっても、liveness プロパティはロールアップの正しい実装から得られます。上で見たように、Rollup を正しく実装するには、次の 2 つの重要なコンポーネントが含まれている必要があります。* 必須の包含メカニズム。* シーケンサー交換プロトコル。強制的な包含メカニズムは、検閲への抵抗を高めるのに役立ちます。このメカニズムにより、ユーザーはトランザクションを基本層に直接「強制的に含める」ことができます。ロールアップ上のユーザーは、資金を強制的にベースレイヤーに引き出すことができます。したがって、集中化されたコレーター ノードが 1 つしかない場合でも、成熟した強制包含メカニズムがある限り、ユーザーを検閲することはできません。しかし、それだけで十分でしょうか？ユーザーが自由に終了できる場合でも、ほとんどのユーザーが L1 に戻った場合、L2 には操作を継続するインセンティブがあまりないことを意味する可能性があります。また、必須の包含メカニズムは通常待ち時間が長く、平均的なユーザーにとって実装するには非常に高価な場合があります。このメカニズムによって提供される検閲耐性は完全に実用的 (またはリアルタイム) ではなく、「弱い検閲」と呼ぶことができます。次に、最後のアクティビティ属性である元帳の増加があります。集中発注者が何か悪いことをした場合、ブロックの生成を停止するだけでロールアップ チェーンの成長を止めることができます。この問題が発生した場合、ユーザーはロールアップを再び「ライブ」にするためにできることは何もありません。この問題を解決するには、ソーター置き換えプロトコルが必要です。Sequencer Replacement Protocol の考え方は、Sequencer が悪意のある動作をした場合に、Rollup がガバナンスを通じて新しい Sequencer を開始できるというものです。これを実現する方法の 1 つは、集中型順序付けノードを分散型順序付けプロトコルに置き換えることです。注文者が分散化されており、ロールアップのブロック構築を独占していない場合、ロールアップ チェーンをブロックすることはほぼ不可能になります。したがって、ユーザー資金は強制包含メカニズムを通じてロールアップ内で常に安全ですが、堅牢な注文者置換プロトコルを構築することでロールアップを存続させ、実用的なリアルタイムの検閲耐性を提供します。これで全部ですか？完全ではありません。技術的な観点から見ると、考慮すべき点がもう 1 つあります。スマートコントラクト自体がロールアップの中央委員会によってアップグレードできたらどうなるでしょうか?ロールアップは現在正しく実装されていますが、明日委員会はスマート コントラクトを必要とせず、代わりにロールアップ状態の証明を p2p ネットワークにブロードキャストすることに同意したとします。ロールアップ ユーザーとしてそのようなアップグレードに同意できない場合は、アップグレードが実装される前にロールアップを終了できる必要があります (ただし、これはユーザー エクスペリエンスが良くなく、ビジネスにとっても良くない可能性があります)。これは、「通知期間」などの「遅延ガバナンス更新」を通じて実現でき、その後アップグレードが実装されます。アップデートに同意しないユーザーは、通知期間内に退会することができます。分散化の究極は、完全に不変のスマートコントラクトを持つことです。これらのコントラクトは、マルチシグネチャウォレットやその他の委員会によって管理されず、一度デプロイされるとアップグレードすることはできません。もちろん、これにはそれ自体の問題があります。コードにバグがある場合、または重大なイベントでスマート コントラクトの更新が必要な場合、ロールアップの唯一の選択肢は新しいスマート コントラクトにフォークすることですが、ユーザーの資金は古いコントラクトに留まります。残念ながら、Rollup の現在の状態は、上で説明した完全な実装には程遠いです。ほとんどのロールアップはまだ「探索」フェーズにあり、正しく実装しようとしています。L2 BEAT によると、すべてのアクティビティと安全条件を達成できるように成熟したロールアップは、Fuel v1 と DeGate の 2 つだけです。### 経済的観点最後に、ユーザーとロールアップ オペレーターの観点からロールアップの経済性を見てみましょう。* ユーザーエクスペリエンス: ユーザーは安価な価格で取引を行うことができ、あまり長く待つ必要はありません。* ロールアップ利益: シーケンサーとトークン所有者は利益を得る必要があります。ユーザーが高速かつ安価なトランザクション サービスを受けると、ユーザー エクスペリエンスが最適化されます。トランザクションが完了する速度は、基本層が完了する速度によって異なります。 L1 上のデータが最終化されると、トランザクションは最終的なものとみなされます。ただし、フルノードを実行しているユーザーは、単にトランザクションを実行して最終状態を決定するだけで、即座にファイナリティを達成することもできます。しかし、誰もが完全なノードを実行することは現実的ではありません。したがって、集中型ソーターは、トランザクションがブロックに含まれており、最終的に完了するという「ソフトな確認」をユーザーに提供できるため便利です。ほとんどのユースケースではこれで十分です。しかし、中央集権的な機関に依存しているため、不利な行動をとる可能性があります。一部の発注者代替プロトコル ソリューションではこの特性が（ユーザーにとって不利となるため）省略されていますが、外部 PoS コンセンサス スキーム Espresso などの他のソリューションでは、集中発注者のリスクなしに同様の事前確認保証を提供できます。ユーザーのコストはどうなるでしょうか?通常、ロールアップ トランザクションの明示的なコストは次のとおりです。L2 ガスのコスト = L1 ガスのコスト + シーケンサー料金。合理的な集中型仕分け機は、たとえユーザーに高いコストを転嫁することになっても、常に利益を最大化したいと考えています。ただし、これは分散型ソーター機構によっても必ずしも解決できるわけではないことに注意してください。分散型発注者の PoS ノードでも、自身の利益を最大化したいと考えています。実際、これによって不一致の問題が発生し、Rollup が外部シーケンサーに利益を渡したくない場合があります。ロールアップ利益: シーケンサー料金に加えて、ロールアップはユーザー トランザクションから MEV を抽出することによっても利益を得ることができます。注文者が独自のフロントランニング トランザクションの一部をトランザクション パッケージに含めているかどうかを確認するのが難しいため、この MEV を特定するのは困難なことがよくあります。ロールアップが外部 PoS コンセンサスに置き換えられた場合、この MEV は外部オペレーターに引き渡されます。ロールアップが収益を外部メカニズムに引き渡すというこれらの問題は両方とも、ロールアップと外部メカニズムの間の「取引協定」を通じて解決できることは注目に値します。ただし、モジュラー サミットでの Jon Charbonneau の講演とその後の投稿で説明されているように、ロールアップ ガバナンスで一連の検証済みノードに注文を委任する方が良いアイデアかもしれません。これらのノードは地理的に分散するように戦略的に選択することができ、ガバナンスによって悪者を簡単に追い出すことができます。これは、Rollup が利益を社内に維持できると同時に、集中型仕分け機のマイナス面も軽減できるため、一石二鳥のソリューションとなる可能性があります。しかし逆に、シーケンサーのローテーションが制限されている場合、シーケンサーは近視眼的な動作をする可能性があり、独占価格設定/価格つり上げにつながり、犠牲となったロールアップ ユーザーの利益をさらに害する可能性があります。いずれにせよ、Rollup をユーザーにとって費用対効果の高いものにするためには、何らかのソーター代替プロトコルが必要です。＃＃＃ 結論はRollup がどのような道をたどるかに関係なく、成熟したシーケンサー置換プロトコル、必須の組み込み、ラグ ガバナンスの更新メカニズムを備えた完全な実装を目指すことが重要です。強制的な組み込みと遅れた更新のメカニズムがあれば、仕分け機が集中化されているかどうかに関係なく、ユーザーの資金は安全になります。ただし、堅牢なシーケンサー置換プロトコルにより、生存性の保証が向上し、ロールアップ ユーザーの経済性が向上する可能性があります。
ロールアップの分散化の重要性を多角的に解釈する
原作者：シヴァンシュ・マダン
オリジナル編集：ルフィ、フォーサイトニュース
最近、Crypto Twitter での議論の多くは L2 分散化を中心に展開しています。私たちが構築しているロールアップは十分に分散化されていますか?彼らはすでに分散化への道を進んでいますか？関係ありますか？
この記事ではこれらのテーマについて説明します。詳細に説明する前に、ロールアップが実際にどのように機能するかをまだ知らない場合は、この記事「Rollups for Dummies」を簡単に読んでおくことをお勧めします。
ロールアップのアイデアは実際には非常にシンプルです。オフチェーンの参加者がトランザクションを実行し、その後オンチェーンで簡単に検証できるようにすることを望んでいます。 Rollup を使用すると、ベースレイヤーの「信頼」がブロックチェーンの外側のアクティビティに拡張されます。その見返りに、Rollup はこの信託を使用するために少額の手数料 (家賃) を支払います。
では、分散型ロールアップは必要なのでしょうか?
直感的な答えは、「絶対にそうする必要がある」です。これがブロックチェーンの精神です。
しかし、この質問に対する答えは単純に「はい」か「いいえ」ではないとも思います。むしろ、これには複数の側面が含まれており、個別に分析する必要があります。以下では、この問題を哲学、テクノロジー、経済学の 3 つの観点から検討していきます。
哲学的な視点
まず、会話を 1 つ上のレベルに引き上げることから始めましょう。なぜ私たちは分散化を気にするのでしょうか?
私たちはオープンイノベーションを推進するパーミッションレスの未来を望んでいるからです。私たちは、ユーザーが何の制限もなく、単一のエンティティを信頼する必要もなく、新しいものを構築できるようにしたいと考えています。
ブロックチェーンの短い歴史の中で、多くの匿名の開発者が素晴らしいものを構築してきました。実際、ビットコイン自体は匿名の団体によって作成されたものであり、間もなく世界中のほとんどの人が使用する世界的な決済通貨になる可能性があります。それが許可のないイノベーションの力です。
ブロックチェーンを使用すると、共通点のない人々と協力することができ、その信頼を打ち破る方法がないことを私たちは知っています。
——プレストン・エヴァンス
ビットコインやイーサリアムのようなトラストレスネットワークの分散型基盤により、私たちはそのような未来を構築することができます。明らかに、Rollup など、これらのブロックチェーンと信頼関係があるチェーンも分散化する必要があります。
実際、これは興味深い重要な疑問を引き起こします。
Rollup が分散化されていない場合、それは Ethereum が分散化されていないことを意味しますか?
これを少し楽観的に見ると、パーミッションレスの世界では、ロールアップはパーミッション付きチェーンを含む (ただしこれに限定されない) 必要なものすべてを構築できるようにする必要があり、そのロールアップのユーザーは依然として基礎層のセキュリティを利用できるということになります。 。基本レイヤーが分散化されており、ロールアップが「完全に実装」されている限り (「完全な実装」については技術セクションで詳しく説明します)、許可されたチェーンであっても安全に使用できるはずです。
しかし現実には、今日のほとんどのロールアップは完全な実装段階に達しておらず、ユーザーに必要なレベルのセキュリティとトラストレス性を提供していません。
では、Rollup の正しい実装は何でしょうか?見てみましょう：
技術的な観点
Rollup の分散化とセキュリティ上の懸念を真に理解するには、第一原則からそれを検討する必要があります。スリーラム・カナン以上にブロックチェーンの第一原理を説明できる人はほとんどいません。
ブロックチェーンは分散型台帳であり、ネットワーク内のさまざまなノードがあらかじめ決められたプロトコル ルールに従って台帳の状態に関する合意を取得します。これらのノードがネットワークをどのように認識しているかに応じて、ノード自体の台帳ネットワークの正しい状態を確認するための異なるルールを持つことができます。
特にロールアップでは、フルノードとライトクライアントでは確認ルールが異なります。従来のスマート コントラクト ロールアップ (SCR) では、スマート コントラクト (検証ブリッジ) に独自の確認ルールがあります。有害事象がない場合、これらの確認ルールは最終的にいわゆる「一致領域」で一致します。名前が示すように、コンセンサス ゾーンでは、すべての参加者がネットワークに対して同じビュー (および台帳内の同じ履歴) を持ちます。
すべての確認ルールが安全であれば、悪いことは起こりません。 Sreeram が上記の投稿で共有したように、主に 5 つのプロパティがこれらの確認ルールのセキュリティを定義します。
最初の 2 つのプロパティはシステムの「ライブ」状態を定義し、最後の 3 つのプロパティは「安全」状態を定義します。
さまざまなロールアップ参加者の観点からこれらの問題を検討し、分散化せずにどの問題を軽減できるかを見てみましょう。
さまざまなアクターが、安全性と生存性を確保するためにさまざまなメカニズムに依存しています。
フルノード:
フルノードを実行すると、公開されたデータにアクセスでき、それを直接検証できます。その後、そのデータを使用して自分でトランザクションを実行し、トランザクションの有効性とトランザクション後のロールアップの最終状態を判断できます。
したがって、残りの安全条件は活性と組換え耐性です。再編成耐性については、フル ノードはベース チェーンのバリデーターとベース チェーンが使用するコンセンサス プロトコルに依存しますが、ライブ性については、フル ノードはシーケンサーとロールアップの実装に依存します。
ライトクライアント:
ほとんどのユーザーは、ブロックチェーン データをフェッチするライト クライアントを使用してブロックチェーンと対話します。ライトノードにはいくつかの種類があります。
完全な Validator Light クライアントを実行する場合、データ可用性サンプリングを通じてデータが利用可能かどうかを検証し、有効性証明または不正証明を通じて状態遷移の妥当性を検証し、状態が基本層 (上記のイーサリアムの場合) のコンセンサスに従っているかどうかを検証できます。 、同期委員会に従うことで実行できます）。
次に、残りの安全条件は活性であり、ライト クライアントはシーケンサーとロールアップの実装に依存します。
組み込みのスマート コントラクト (検証ブリッジ):
従来の SCR では、スマート コントラクトの「確認ルール」は、次の 5 つのセキュリティ プロパティすべてを強制することです。
SCR フルノードは、スマート コントラクトに依存して活性プロパティを強制します。再組織化耐性はベース層から得られます。
ライトノードは、スマートコントラクトに依存してライブネス特性を強化し、ベースレイヤーからの DA と再編成の抵抗を吸収します。有効性の証明を自分自身で、またはスマートコントラクト経由で検証できます。
SCR のコンセンサスは、スマート コントラクトによって定義された正規チェーンに従うことです。
ソブリンロールアップについてはどうですか？
ソブリン ロールアップには、有効性または生存条件を強制するためのスマート コントラクト (検証ブリッジ) がありません。代わりに、下流のロールアップ ノードに「ロールダウン」することが証明されます。これらのノードは依然として、ベース層からのデータの可用性と再編成の耐性に依存しています。
SCR と同様に、ソブリン ロールアップでは、ノードには liveness プロパティを強制する何らかのメカニズムが必要です。正規チェーンを定義するために、彼らは p2p プルーフをブロードキャストするなどの独立したメカニズムを選択しました。
これらすべてが分散化とどのような関係があるのでしょうか?
スマート コントラクト ロールアップであってもソブリン ロールアップであっても、liveness プロパティはロールアップの正しい実装から得られます。上で見たように、Rollup を正しく実装するには、次の 2 つの重要なコンポーネントが含まれている必要があります。
強制的な包含メカニズムは、検閲への抵抗を高めるのに役立ちます。このメカニズムにより、ユーザーはトランザクションを基本層に直接「強制的に含める」ことができます。ロールアップ上のユーザーは、資金を強制的にベースレイヤーに引き出すことができます。したがって、集中化されたコレーター ノードが 1 つしかない場合でも、成熟した強制包含メカニズムがある限り、ユーザーを検閲することはできません。
しかし、それだけで十分でしょうか？
ユーザーが自由に終了できる場合でも、ほとんどのユーザーが L1 に戻った場合、L2 には操作を継続するインセンティブがあまりないことを意味する可能性があります。また、必須の包含メカニズムは通常待ち時間が長く、平均的なユーザーにとって実装するには非常に高価な場合があります。このメカニズムによって提供される検閲耐性は完全に実用的 (またはリアルタイム) ではなく、「弱い検閲」と呼ぶことができます。
次に、最後のアクティビティ属性である元帳の増加があります。
集中発注者が何か悪いことをした場合、ブロックの生成を停止するだけでロールアップ チェーンの成長を止めることができます。この問題が発生した場合、ユーザーはロールアップを再び「ライブ」にするためにできることは何もありません。
この問題を解決するには、ソーター置き換えプロトコルが必要です。
Sequencer Replacement Protocol の考え方は、Sequencer が悪意のある動作をした場合に、Rollup がガバナンスを通じて新しい Sequencer を開始できるというものです。これを実現する方法の 1 つは、集中型順序付けノードを分散型順序付けプロトコルに置き換えることです。注文者が分散化されており、ロールアップのブロック構築を独占していない場合、ロールアップ チェーンをブロックすることはほぼ不可能になります。
したがって、ユーザー資金は強制包含メカニズムを通じてロールアップ内で常に安全ですが、堅牢な注文者置換プロトコルを構築することでロールアップを存続させ、実用的なリアルタイムの検閲耐性を提供します。
これで全部ですか？
完全ではありません。技術的な観点から見ると、考慮すべき点がもう 1 つあります。
スマートコントラクト自体がロールアップの中央委員会によってアップグレードできたらどうなるでしょうか?ロールアップは現在正しく実装されていますが、明日委員会はスマート コントラクトを必要とせず、代わりにロールアップ状態の証明を p2p ネットワークにブロードキャストすることに同意したとします。
ロールアップ ユーザーとしてそのようなアップグレードに同意できない場合は、アップグレードが実装される前にロールアップを終了できる必要があります (ただし、これはユーザー エクスペリエンスが良くなく、ビジネスにとっても良くない可能性があります)。これは、「通知期間」などの「遅延ガバナンス更新」を通じて実現でき、その後アップグレードが実装されます。アップデートに同意しないユーザーは、通知期間内に退会することができます。
分散化の究極は、完全に不変のスマートコントラクトを持つことです。これらのコントラクトは、マルチシグネチャウォレットやその他の委員会によって管理されず、一度デプロイされるとアップグレードすることはできません。
もちろん、これにはそれ自体の問題があります。コードにバグがある場合、または重大なイベントでスマート コントラクトの更新が必要な場合、ロールアップの唯一の選択肢は新しいスマート コントラクトにフォークすることですが、ユーザーの資金は古いコントラクトに留まります。
残念ながら、Rollup の現在の状態は、上で説明した完全な実装には程遠いです。ほとんどのロールアップはまだ「探索」フェーズにあり、正しく実装しようとしています。
L2 BEAT によると、すべてのアクティビティと安全条件を達成できるように成熟したロールアップは、Fuel v1 と DeGate の 2 つだけです。
経済的観点
最後に、ユーザーとロールアップ オペレーターの観点からロールアップの経済性を見てみましょう。
ユーザーが高速かつ安価なトランザクション サービスを受けると、ユーザー エクスペリエンスが最適化されます。
トランザクションが完了する速度は、基本層が完了する速度によって異なります。 L1 上のデータが最終化されると、トランザクションは最終的なものとみなされます。ただし、フルノードを実行しているユーザーは、単にトランザクションを実行して最終状態を決定するだけで、即座にファイナリティを達成することもできます。
しかし、誰もが完全なノードを実行することは現実的ではありません。したがって、集中型ソーターは、トランザクションがブロックに含まれており、最終的に完了するという「ソフトな確認」をユーザーに提供できるため便利です。ほとんどのユースケースではこれで十分です。しかし、中央集権的な機関に依存しているため、不利な行動をとる可能性があります。
一部の発注者代替プロトコル ソリューションではこの特性が（ユーザーにとって不利となるため）省略されていますが、外部 PoS コンセンサス スキーム Espresso などの他のソリューションでは、集中発注者のリスクなしに同様の事前確認保証を提供できます。
ユーザーのコストはどうなるでしょうか?
通常、ロールアップ トランザクションの明示的なコストは次のとおりです。
L2 ガスのコスト = L1 ガスのコスト + シーケンサー料金。合理的な集中型仕分け機は、たとえユーザーに高いコストを転嫁することになっても、常に利益を最大化したいと考えています。ただし、これは分散型ソーター機構によっても必ずしも解決できるわけではないことに注意してください。分散型発注者の PoS ノードでも、自身の利益を最大化したいと考えています。
実際、これによって不一致の問題が発生し、Rollup が外部シーケンサーに利益を渡したくない場合があります。
ロールアップ利益: シーケンサー料金に加えて、ロールアップはユーザー トランザクションから MEV を抽出することによっても利益を得ることができます。注文者が独自のフロントランニング トランザクションの一部をトランザクション パッケージに含めているかどうかを確認するのが難しいため、この MEV を特定するのは困難なことがよくあります。
ロールアップが外部 PoS コンセンサスに置き換えられた場合、この MEV は外部オペレーターに引き渡されます。
ロールアップが収益を外部メカニズムに引き渡すというこれらの問題は両方とも、ロールアップと外部メカニズムの間の「取引協定」を通じて解決できることは注目に値します。
ただし、モジュラー サミットでの Jon Charbonneau の講演とその後の投稿で説明されているように、ロールアップ ガバナンスで一連の検証済みノードに注文を委任する方が良いアイデアかもしれません。これらのノードは地理的に分散するように戦略的に選択することができ、ガバナンスによって悪者を簡単に追い出すことができます。
これは、Rollup が利益を社内に維持できると同時に、集中型仕分け機のマイナス面も軽減できるため、一石二鳥のソリューションとなる可能性があります。
しかし逆に、シーケンサーのローテーションが制限されている場合、シーケンサーは近視眼的な動作をする可能性があり、独占価格設定/価格つり上げにつながり、犠牲となったロールアップ ユーザーの利益をさらに害する可能性があります。
いずれにせよ、Rollup をユーザーにとって費用対効果の高いものにするためには、何らかのソーター代替プロトコルが必要です。
＃＃＃ 結論は
Rollup がどのような道をたどるかに関係なく、成熟したシーケンサー置換プロトコル、必須の組み込み、ラグ ガバナンスの更新メカニズムを備えた完全な実装を目指すことが重要です。強制的な組み込みと遅れた更新のメカニズムがあれば、仕分け機が集中化されているかどうかに関係なく、ユーザーの資金は安全になります。
ただし、堅牢なシーケンサー置換プロトコルにより、生存性の保証が向上し、ロールアップ ユーザーの経済性が向上する可能性があります。