レッスン17 — Reth 拡張パターン（フォークではなくライブラリ）
問い
op-geth / bsc-geth / bor を触った経験があれば、geth-fork パターンの苦しみは知っている。upstream をクローンしてパッチを当て、ずっと rebase。upstream マージのたびに週末がコンフリクト解消で潰れ、監査対象が徐々に mainline からドリフトする。Reth はこのモデルを終わらせるために設計された — どう機能するか？
原理（最小モデル）
- 2 モデル. Fork（geth 流）= ソース patch + 定期 rebase → ドリフトコスト超線形 / Extension（reth 流）= crate 依存 + trait 別 crate impl → コスト局所化（trait シグネチャ変更時のみ）。
- Reth アーキ全体が extension モデル軸. NodeBuilder / components / ChainSpec パターンはまさに reth ソース patch せず chain を出荷する ためにある。
- Paradigm が選んだ 3 理由. ① Rebase 痛みは実証済み（op-geth は Optimism 自身が書き直しに資金 →
crates/optimism/）+ ② 監査範囲（fork = upstream diff + 全 patch 理由づけ vs node crate = 1 repo + trait impl 集合）+ ③ コンポーザビリティ（Berachain PoL / Scroll zk-friendly state / Seismic 暗号化 tx が共存）。 - 6 カスタマイズスロット. ChainSpec / ConfigureEvm / BlockExecutionStrategy / PayloadBuilder / Pool / RPC namespace / Consensus。他（P2P / MDBX / staged sync / ExEx / trie commitment）は何もしなくても reth が提供。
- 読むべき具体例 4 つ.
crates/optimism/（本番運用最大）/ alphanet（R&D）/ sova-reth（Bitcoin EL）/ seismic-reth（暗号化 tx）。 - Tempo は extension モデルの実証.
tempoxyz/tempo= node crate、tempoxyz/reth= upstream に 0 commits ahead, 1374 commits behind。L1 全体が依存レベル拡張。
具体例
2 モデル比較:
| Model | やり方 | 時間が経つほどのコスト |
|---|---|---|
| Fork model (geth 流) | upstream をクローン、ソースに patch、定期的に rebase | ドリフトコスト 超線形に増大 — パッチと upstream の距離が開き続け、コンフリクトが複利で効く |
| Extension model (reth 流) | reth crate に依存、chain 固有 trait を別 crate で実装 | ドリフトコスト 局所化 — trait のシグネチャが変わったときだけ手を入れる |
7 カスタマイズスロット（reth NodeBuilder）:
| スロット | 何を制御 |
|---|---|
ChainSpec | fork 高、gas params、precompile schedule、genesis |
ConfigureEvm / block execution strategy | 実行レイヤー、custom precompile、deposit tx |
PayloadBuilder | block 生成（sequencer mode） |
| Pool / mempool policy | どの tx をどの順序で受け入れるか |
| Custom RPC namespace | extend_rpc_modules で chain 固有エンドポイント |
| Custom consensus | Ethereum-PoS 以外向け |
| Add-ons | Custom 追加（ExEx、メトリクスなど） |
実例:
crates/optimism/in paradigmxyz/reth — Optimism / Base / Mode / OP Stack。世界で最も本番運用された extension。- paradigmxyz/alphanet — Paradigm 自身の OP Stack 互換テストネット。mainnet 実装前の precompile（EIP-7212 P-256）試す場。
- SovaNetwork/sova-reth — Bitcoin の execution layer として Reth。
- SeismicSystems/seismic-reth — 暗号化 tx 対応の Reth。
Tempo の構造証拠:
tempoxyz/tempo= node crate（Rust、L1）tempoxyz/reth= upstream Paradigm Reth に対して 0 commits ahead, 1374 commits behind
Reth を一切 fork していない。payments 固有カスタマイズすべて tempoxyz/tempo crate に依存レベル拡張。
失敗例（誤解）
「Berachain は PoL を入れるために reth を fork した」— 間違い。bera-reth は依存レベル拡張で reth crate に依存、独自 crate（consensus / evm / chainspec / node / rpc）で PoL を実装。Reth 本体は触らない。「fork」ではなく「extend」「compose」が正しい動詞。
「依存レベル拡張は性能を犠牲にする」— 間違い。コンパイラがインライン化、性能差なし。trait による拡張は ゼロコスト抽象 — 静的ディスパッチで最終バイナリは fork と同じ性能。
「全 chain は深いカスタマイズが必要」— 間違い。実例 4 つは深さが違う（alphanet < Optimism < Tempo < MegaETH）。SDK は浅い端から深い端まで対応 + 必要分だけ書く。
🛑 予測。 geth-fork チェーンが 18 ヶ月遅れの security patch を取り込みたい。rebase にどれくらいかかる？ rebase 自体が consensus bug を引き起こす経路 3 つ？（答え: 時間 = 数週間 - 数ヶ月（fork が 18 ヶ月分の patch を持つ → 各 patch をコンフリクト解消 + テスト + 監査）。bug 経路 = ① patch の意味解釈ミス（upstream の意図と違う形で適用）+ ② 上流の関連変更（chainspec、共通 utility）を引き継ぎ忘れ → 自分の patch が暗黙前提を破る + ③ rebase 後の rebuild で hidden コンパイラ最適化変化 → 確率的バグ。rebase 自体が consensus-critical。）
ステップで組み立てる
Step 1: 2 モデルの差を即答
Fork = 超線形ドリフトコスト / Extension = 局所化（trait シグネチャ変更時のみ）。
Step 2: 7 カスタマイズスロット
ChainSpec / ConfigureEvm / PayloadBuilder / Pool / RPC namespace / Consensus / Add-ons。他は reth が提供。
Step 3: 4 実例を見比べる
crates/optimism/（本番最大）/ alphanet（R&D 教育）/ sova-reth（Bitcoin）/ seismic-reth（プライバシー）。
Step 4: Tempo の構造証拠を確認
tempoxyz/reth の commits ahead / behind を見る → 0 / 1374 → fork ゼロ証明。
Step 5: 自分の chain 設計
「6 スロットのうちどれを差し替え、どれを継承？」を明示化。Reth に対する diff だけ書く。
答え合わせ
- Berachain の正しい言い直し: 「Berachain は PoL を入れるために bera-reth crate を書き、Reth crate に依存している」または「reth を extend した」。fork ではない（reth リポを copy していない、reth-core crate を import している）。
- Extension モデルが Reth で成立する構造的理由: trait-based aggregation（NodeBuilder composition）+ ゼロコスト抽象（静的ディスパッチ）+ chainspec / EVM / payload / consensus / pool / RPC が独立 trait → 各 chain が必要な分だけ別 crate で impl → reth-core は変更不要。
- Tempo / MegaETH / Berachain が同じパターンを使う理由: 各々が異なる深さのカスタマイズ（Tempo 浅、MegaETH 深、Berachain 中）でも Reth fork なし で済む = extension モデルは深さに依存しない。MegaETH は MDBX を SALT で完全置換 + 別 validator binary を書きつつ
megaeth-labs/rethは 0 ahead, 7666 behind。
合格基準
- 2 モデル（fork / extension）の差を即答できる。
- 7 カスタマイズスロットを言える。
- Berachain が「fork ではなく extend」と正しく言える。
- Tempo の
0 ahead, 1374 behindの意味を即答できる。 - 4 実例の深さ順を言える。
まとめ（3行）
- Fork model（geth 流）はドリフトコスト超線形、Extension model（reth 流）は局所化 — Reth アーキ全体が extension 軸。
- 7 カスタマイズスロット（ChainSpec / ConfigureEvm / PayloadBuilder / Pool / RPC / Consensus / Add-ons）+ 他は reth が提供 + 必要分だけ別 crate で impl。
- Tempo / MegaETH / Berachain / Seismic / Sova すべて Reth fork なし = extension モデルは深さに依存しない実証。