レッスン0 — Sequencer とは何か？ Rollup モデルを 15 分で

問い

Base で swap を送る。1 秒未満で confirm。Wallet に tx が表示される。その順序を決め、自社サーバで実行し、いずれ Ethereum に投稿するのは 1 企業 — Coinbase。慣習的な定義に従えばこれは中央集権システム。それなのになぜ Base は「分散化された rollup」と呼ばれるのか？

原理（最小モデル）

• Rollup = L2 実行 + L1 へのコミットメント. Sequencer が L2 ブロック生成、batcher + proposer が L1 投稿。
• Sequencer の 3 役割. Ordering（tx 順序選択）+ Execution（revm 実行 + post-state 生成）+ Batching（L2 ブロックを L1 投稿）。
• Rollup モデルの売り「UX は信頼、資金は信頼しない」. 中央集権 sequencer でもユーザ資金は安全 — 検閲されたら L1 force-inclusion contract に直接 tx 提出、L1 contract が期限内 inclusion 強制（OP Stack で約 1 時間）。
• L1 上の 3 contract. Inbox（OptimismPortal、deposit + 強制 include）+ Outbox/OutputOracle（state root commitment）+ Bridge（asset 転送ラッパ）。
• 中央集権パラドックスの 5 理由. 性能 / MEV / Liveness / Pre-confirmation / 運用シンプルさ。
• 分散化スペクトラム 4 位置. Single sequencer → Multi-sequencer（whitelist）→ 分散化 sequencer → 共有 sequencer。

具体例

Rollup データ経路:

flowchart TB
    Users["L2 Users"] -->|submit tx| Seq["Sequencer<br/>(centralized)"]
    Seq -->|execute| L2["L2 chain<br/>(Reth-based execution)"]
    L2 -->|batch| Batcher["Batcher<br/>(off-chain)"]
    Batcher -->|post calldata + state root| L1["L1 (Ethereum)"]
    L1 -->|finalize after challenge| L2

Sequencer の 3 役割:

OP Stack の 3 repo 対応:

• op-rbuilder（または op-geth）: 実行 + 順序付け
• op-batcher: batch サービス
• op-proposer: state root 提出サービス

L1 上の 3 contract:

分散化スペクトラム:

失敗例（誤解）

「Sequencer が中央集権 = rollup が中央集権」— 間違い。Sequencer は UX 担当（順序付け + 即時 confirmation）、資金担当ではない。資金は L1 contract 経由で escape hatch 保証。中央集権 = sequencer の選択肢、Rollup security ≠ sequencer trust。

「Sequencer が検閲したらユーザ詰む」— 間違い。L1 inbox contract（OptimismPortal）に直接提出 → sequencer は期限内（~1 時間）に inclusion 強制 → 期限超過なら誰でも force-inclusion 可能。検閲コストは有限（最大 ~1 時間遅延 + L1 ガス）。

「Sequencer が 2 時間 offline = ユーザ資金消失」— 間違い。L2 chain 停止（新ブロックなし）、ユーザ資金 安全（state 変更なし）、Inbox 経由 depositor は escape hatch 機構で tx 強制実行。

🛑 予測。 Optimism は OP Labs チームが運用する sequencer を 1 つだけ持つ。なぜこれが許容可能なのか？ Single sequencer であっても rollup アーキテクチャがなければ可能になる攻撃のうち、緩和できるものは？（答え: 中央集権 sequencer が緩和できないが rollup が緩和するもの = ① 資金窃取（L1 contract が withdrawal を state proof で検証 → sequencer の state 嘘 → 拒否）+ ② 永久検閲（L1 force-inclusion で期限超過なら誰でも強制）+ ③ サイレント rule 変更（OutputOracle に commitment → 全員が検証可能）。sequencer を信頼するのは UX（順序付けの即時性）のみ、資金 safety は L1 が担保。）

ステップで組み立てる

Step 1: Rollup = L2 実行 + L1 コミットメント

両方が必須 — 一方だけだと「ただの sidechain」または「ただの settlement layer」。

Step 2: Sequencer 3 役割を即答

Ordering / Execution / Batching。OP Stack では 3 サービス（op-rbuilder / op-batcher / op-proposer）。

Step 3: 検閲時のユーザ経路

L1 Inbox（OptimismPortal）に直接提出 → sequencer 期限内 inclusion 強制 → 期限超過なら誰でも force-inclusion。

Step 4: L1 3 contract の役割

Inbox（deposit + force-include）/ Outbox（state root commitment）/ Bridge（asset wrapper）。

Step 5: 中央集権パラドックスの 5 理由

性能 / MEV / Liveness / Pre-confirmation / 運用シンプルさ。UX vs 検閲耐性のトレードオフ、大半の L2 は UX 選ぶ。

Step 6: Reth が収まる場所

Sequencer が EL として Reth 走らせる → Engine API（forkchoiceUpdated / getPayload / newPayload）経由。OP Stack は crates/optimism/ が OP 理解の実行層提供。

Step 7: 分散化スペクトラム 4 位置

Single → Multi（whitelist）→ 分散化 → 共有。大半が位置 1、共有 sequencer が位置 4 のフロンティア。

答え合わせ

• Single sequencer 許容可能な理由: UX の即時性（pre-confirmation、低レイテンシ）+ 運用シンプルさ + 資金 safety は L1 が担保（escape hatch + force-inclusion + state proof）。検閲も期限付きで強制可能。信頼の対象が小さい（UX のみ）= 大きな利益。
• Sequencer downtime（2h）の結末: L2 chain 停止（新 block なし）+ ユーザ資金安全（state 不変）+ 2h 後に escape hatch で deposit tx 強制実行可能（具体経路は rollup ごとの contract 依存）。chain は止まるが、resume または migrate できる。
• 5 つの中央集権理由: 性能（予測可能順序付け）+ MEV（1 sequencer 制御）+ Liveness（1 オペ online 容易）+ Pre-confirmation（単一なら即時署名）+ 運用（1 オペで monitoring / on-call / deploy）。

合格基準

• Rollup の 2 要素（L2 実行 + L1 コミットメント）を即答できる。
• Sequencer の 3 役割と OP Stack の 3 repo を対応付けられる。
• 検閲時のユーザ経路（L1 inbox → force-inclusion）を辿れる。
• 中央集権 5 理由を即答できる。
• 分散化スペクトラム 4 位置を例で言える。

まとめ（3行）

• Rollup = L2 実行 + L1 コミットメント、Sequencer は UX（順序 + 即時性）を信頼、資金 safety は L1 contract が担保（escape hatch + force-inclusion）。
• 中央集権 sequencer の 5 理由（性能 / MEV / Liveness / Pre-confirmation / 運用）= UX 優先のトレードオフ、検閲コストは有限。
• 分散化スペクトラム 4 位置（Single → Multi → 分散化 → 共有）、大半が Single、共有 sequencer が次のフロンティア。