レッスン21 — Custom payload builder（sequencer モードの block 生成）
問い
Ethereum mainnet では block を validator が consensus client 動かして execution client から pull。L2 や中央集権 sequencer chain では sequencer がそのまま block producer。Payload builder が「どうやって作るか」を担う — 何を制御し、何を制御しないか？
原理（最小モデル）
PayloadBuilderの入出力. 入力 = Parent block / chain state / Pending tx pool / Timestamp / slot、出力 = 構築済み block（"payload"）。- 3 種の本番 builder. Default Ethereum builder（mainnet validator）+ OP payload builder（OP Stack sequencer）+ op-rbuilder（flashbots/rbuilder、OP 向け高性能 external block builder）。
- L2 builder の 5 つの追加責務. ① Deposit tx 強制 include（L1 oracle queue から）+ ② FIFO or priority-fee ソート + ③ L1 block oracle slot 更新（最初の state write）+ ④ L2 gas limit でキャップ + ⑤ Sequencer signature でタグ付け。
- Builder と executor の境界. Builder = block に何が入るか を制御、Executor = block に入っているもの を実行。
- MEV 3 立場. MEV-blind（厳格 FIFO）/ MEV-aware public（MEV-share bid）/ MEV-extracting（内部 searcher）。chain の MEV policy は payload builder ソースに現れる。
- op-rbuilder. Bundle merging + Sealing strategy + Builder API、OP Stack 向け本番グレードリファレンス。
具体例
3 種 builder:
| Builder | 場所 | 用途 |
|---|---|---|
| Default Ethereum builder | crates/payload/builder/ | Mainnet validator |
| OP payload builder | crates/optimism/payload/ | OP Stack sequencer |
| op-rbuilder | flashbots/rbuilder | OP Stack 向け高性能 external builder |
L2 builder の 5 責務:
- Deposit tx を block 先頭に強制 include（既知の L1 oracle queue から）
- 残りを FIFO か priority-fee でソート
- 最初の state write として L1 block oracle storage slot を更新
- L2 gas limit で block をキャップ（mainnet limit ではない）
- Sequencer signature で block にタグ付け（一部 L2 は sequencer identity にコミット）
MEV 3 立場:
| Position | 意味 | 例 |
|---|---|---|
| MEV-blind | 厳格 FIFO、tx 意味に踏み込まない | 一部小規模 L2 が主張 |
| MEV-aware public | 公開 order flow、builder が MEV-share 風 bid 受ける | OP Stack + op-rbuilder |
| MEV-extracting | Sequencer が内部 searcher 運用 | 不透明、中央集権 chain は何でも可能 |
op-rbuilder の特徴:
- Bundle merging（private order flow + public mempool）
- Sealing strategy（greedy、並列化可能）
- Builder API（第三者 bundle 提出可能）
- オープンソースで「本物の」本番 block builder に最も近い
Tempo 予測:
- 決済認識型 payload builder — 決済 tx が汎用 tx より優先される可能性
- Builder レベル merchant 認可フィルタ
- merchant 単位レート制限
- ローンチ時公開 mempool なし（sequencer-private）
失敗例（誤解）
「mempool を FIFO に流せば sequencer 完成」— 間違い。3 攻撃が抜けている: ① tx 提出の latency 攻撃（低レイテンシピアが優位）、② toxic order flow（malicious tx が次の被害者を釣る）、③ reorg 攻撃（sequencer 自身が短期 reorg）。FIFO + 防御層が必要。
「builder と executor は同じこと」— 間違い。Builder = 何を入れるか（順序 + フィルタ）、Executor = 入っているものをどう走らせるか（state 遷移）。順序は builder が決定 + executor が忠実に実行。
「MEV-blind が常に倫理的」— 半分間違い。MEV-blind 主張でも実際は order flow の見え方で抽出可能（mempool 公開 vs sequencer 専有）。公開された主張ではなく builder source code が真実。
🛑 予測。 ジュニアエンジニアが「mempool を FIFO に流せば sequencer 完成」と言う。そこに考慮が抜けている攻撃を 3 つ。（答え: ① tx 提出 latency 攻撃 — 低レイテンシピアが MEV 機会を独占（先着 FIFO で）、② toxic order flow — bait tx が後続 tx の被害者を釣る、sequencer が一律 FIFO だと罠が成功、③ reorg / sequencer 自身の MEV — sequencer 自身が短期 reorg で過去 block を書き換えて利益抽出（中央集権なので何でもできる）。FIFO は 公平に見えて公平でない — 防御層必要。）
ステップで組み立てる
Step 1: 3 種 builder を即答
Default / OP payload / op-rbuilder（external）。
Step 2: L2 builder の 5 責務
Deposit tx 強制 / FIFO or priority-fee / L1 oracle slot 更新 / L2 gas cap / Sequencer signature。
Step 3: Builder vs Executor の境界
Builder = 何を入れるか（順序 + フィルタ）、Executor = 入っているものを実行。
Step 4: MEV 3 立場の判別
source code を読む — extend_builder_with_mev_share のような feature flag、external builder 統合の有無、internal searcher hook。
Step 5: op-rbuilder を読む準備
OP Stack 向けの「本物の」本番 builder 参考実装、Bundle merging + Sealing + Builder API。
答え合わせ
- 3 攻撃（latency / toxic flow / reorg）が FIFO で防げない理由: ① latency は network 層の話 → application 層の順序付けでは介入不能、低レイテンシピアが mempool の自分の tx を先に入れる、② toxic flow は順序付けロジックが意味解釈しない FIFO だと罠 tx + 被害者 tx を順に通す、③ sequencer 自身の reorg は順序付けではなく consensus 層の問題、中央集権 sequencer は何でも可能。FIFO は平等の幻想、防御層必要。
- Tempo の予測差分（5 つ）: 決済認識型優先 / merchant 認可フィルタ / merchant rate limit / 公開 mempool なし / sequencer signature。各々が payload-builder crate の trait impl として現れる。
- MEV policy が source code に現れる理由: feature flag や external builder 統合は public API 露出 / 内部 searcher hook は private 関数だが GitHub source で見える / Bundle merging の有無 / Order flow privacy 設定。主張ではなくコードを読む — 「MEV-blind」と言いながら
internal_searcher::bid()が呼ばれているかもしれない。
合格基準
- 3 種 builder を即答できる。
- L2 builder の 5 責務を言える。
- Builder vs Executor の境界を 1 文で説明できる。
- MEV 3 立場を判別できる。
- 3 攻撃（latency / toxic / reorg）が FIFO で防げない理由を言える。
まとめ（3行）
- Payload builder = block 内容（順序 + フィルタ）を制御、Executor = 内容を実行。Mainnet validator vs L2 sequencer で「誰がトリガーするか」が違うだけ。
- L2 builder の 5 責務（Deposit tx / FIFO or priority-fee / L1 oracle slot / L2 gas cap / Sequencer signature）+ MEV 3 立場が source code に現れる。
- op-rbuilder が OP Stack 向け本番グレードリファレンス、Bundle merging + Sealing + Builder API。