本文へ移動

共有シーケンサー

共有シーケンサーが複数の Rollup のトランザクションを順序付ける仕組み、事前確認が保証することとしないこと、相互運用性・稼働性・検閲・MEV・共通障害のリスクを解説します。

更新日

教育目的の情報であり、金融、投資、相互運用性、トランザクションのファイナリティ、またはセキュリティに関する助言ではありません。共有シーケンサーの保証、代替経路、決済上の前提は実装ごとに異なり、アップグレード後に変更される場合があります。

直接の回答

共有シーケンサーとは、複数の Rollup からトランザクションデータを受け取り、そのデータについて共通の合意済み順序を生成するサービスまたはネットワークです。参加する Rollup は、順序付きログから自分に割り当てられた部分を読み取り、独自の状態遷移ルールに従って実行します。シーケンシング層は、データが Rollup のデータ可用性層と決済層に到達する前に、迅速な事前確認を発行することもあります。

「共有」は複数の Rollup による再利用を表す言葉であり、特定の信頼モデルを意味しません。共有シーケンサーは中央集権型、許可制委員会による運営、または分散型コンセンサスによる保護のいずれでもあり得ます。それだけで実行の正しさを証明したり、トランザクションデータを恒久的に利用可能にしたり、親チェーン上で Rollup を決済したり、Rollup 間操作のアトミック性を保証したりするものではありません。

この設計は順序付けインフラを分散し、複数の Rollup に相対順序の一貫した見方を与え、重複運用を減らせます。一方で、接続したすべての Rollup に同時に影響し得る新たな依存先も生まれます。

仕組み

  • 送信。 ユーザー、ウォレット、または Rollup 専用ゲートウェイが、署名済みトランザクションや中身を解釈しないトランザクションバンドルを共有シーケンシング層へ送ります。通常は Rollup 識別子または名前空間が付けられます。
  • 順序付け。 運営者またはコンセンサスネットワークがトランザクションを選択し、包含を決め、共通の順序付きブロックまたはログに合意します。その規則が、直接的な検閲、手数料、MEV の余地を左右します。
  • 事前確認。 サービスは順序へのコミットメントに署名するか、それをファイナライズする場合があります。その保証は実装の署名者、委員会、ステーク、コンセンサスの前提に由来し、親チェーンのファイナリティになるわけではありません。
  • 配布。 リレイヤーと Rollup ノードが順序付きデータを取得し、コミットメントを検証して、各 Rollup 向けの項目を抽出します。
  • 実行と公開。 各 Rollup は自らのトランザクションを実行し、独自のプロトコルに従ってデータと状態コミットメントを公開します。遅延実行型の共有シーケンサーは、Rollup の状態遷移を検証せずに不透明なバイト列を並べられます。
  • 決済。 Rollup の証明またはチャレンジ制度、データ可用性規則、ブリッジコントラクト、親チェーンのコンセンサスが、実行の正しさ、出金、最終決済を決めます。

共通順序があれば、アプリケーションは同じシーケンシングイベントを参照できるため、Rollup 間の協調を支援できます。ただし、アトミックな相互運用には、両方の処理を定義し、結果を検証し、部分実行を防止または処理する追加のプロトコルロジックが必要です。共有順序だけでは、メッセージ配信もロールバックの意味論も提供されません。

あるアプリケーションが Rollup A 上の資産を Rollup B 上の資産と交換するとします。両方の Rollup が使うシーケンシング層に、二つのトランザクション処理を一つのバンドルとして送信します。シーケンサーは相対順序にコミットし、各 Rollup は同じ順序付きログから自分の項目を導出します。

両 Rollup と相互運用プロトコルがバンドルを認識し、共有コミットメントを検証して、全件成功か全件失敗かの規則を強制するなら、共通順序は実行の協調に役立ちます。Rollup A が自分の処理を実行した一方で Rollup B がもう一方を拒否、遅延、または取得不能になった場合、共有シーケンサーが交換をアトミックにしたわけではありません。ブリッジ、証明システム、エスクローなどの復旧規則でその状態を解決する必要があります。

運用上の確認では、事前確認、可用性への公開、実行結果、親チェーン決済を別々の状態として追跡します。「確認済み」としか表示しないユーザーインターフェースでは、実際にどの保証へ到達したのかが隠れることがあります。

リスク

  • 共通原因による停止。 コンセンサス障害、ソフトウェアの欠陥、リレイヤーの問題、ネットワーク障害により、複数の Rollup が同時に停止する可能性があります。各 Rollup には文書化された代替経路と、復旧後に順序を整合させる規則が必要です。
  • 検閲とガバナンス。 バリデーター、運営者、参加方針、アップグレード権限者がトランザクションや Rollup を排除する可能性があります。実際の参加や送信が許可制のままなら、分散型コンセンサスだけでは解決しません。
  • 順序付けと MEV。 共有ビューは Rollup 間の活動を協調できますが、価値あるオーダーフローを集中させ、ドメイン横断のフロントラン、優先包含、高度な MEV 抽出を可能にすることもあります。
  • 確認の不一致。 シーケンサーのコミットメント、データ可用性の確認、Rollup の実行結果、親チェーン決済は別の保証です。ブリッジやアプリケーションが最初の信号を最も強い保証として扱うと、資金を失うおそれがあります。
  • データと統合の障害。 誤った名前空間、不正な導出、利用不能なデータ、互換性のないアップグレード、侵害されたアダプターにより、Rollup が誤った入力を実行したりブロック導出を停止したりする可能性があります。
  • 経済力と制御の集中。 共通のバリデーター集合、トークン、クライアント、RPC サービス、ガバナンス手続きがシステム上重要になる場合があります。インフラ共有は単一 Rollup の運営者を分散する一方、エコシステムを別の層へ集中させることがあります。

よくある誤解

  • 共有なら分散型である。 共有が示すのはサービスを使う Rollup の数です。分散性は、誰が検証、提案、送信、アップグレード、復旧できるかで決まります。
  • 一つの順序は一つの状態機械を意味する。 各 Rollup は通常、別々の実行と状態を維持します。シーケンサーは理解も実行もしないデータを順序付けできます。
  • 事前確認は親チェーンのファイナリティである。 必要な可用性、証明、決済の手順が完了するまでは、その強度と反転条件はシーケンシングプロトコルに由来します。
  • 共有シーケンシングならブリッジは不要である。 資産とメッセージには依然として、認証された状態遷移、決済ロジック、Rollup 間の障害処理が必要です。
  • この設計は MEV と検閲をなくす。 順序付けを誰が制御するかを変え、説明責任や競争を改善する可能性はありますが、順序付け権限と関連する動機は残ります。

関連トピック

出典

ナビゲーション

Wiki を検索...