レッスン9 — 6 コンポーネント — それぞれが何を解放するか
問い
Tempo / Berachain / MegaETH / Hyperliquid — どれも Reth を fork していない。Reth の 6 コンポーネントのうち数個だけ差し替え、残りを継承。SDK の最大の売り = Rust EVM クライアントを書き直すのではなく、自分の thesis に合う部分だけ差し替える — 各コンポーネントが何を解放するか？
原理（最小モデル）
- fork なしの経験的証拠. Tempo（0 ahead, 1374 behind） / MegaETH（0 ahead, 7666 behind） / Berachain（独立 repo、fork ですらない）。
- 6 コンポーネント. pool（受付・順序付け・追い出し）/ network（P2P・ピア）/ executor（EVM / Opcode / ガス）/ consensus（ブロック検証ルール）/ payload（ブロック構築）/ add_ons（RPC + ExEx）。
- Hyperliquid の差し替え. consensus（HyperBFT）+ executor（オーダーブック結合）+ pool（高頻度 perp 更新）。
- Tempo の差し替え. pool（payments 優先レーン）+ payload（payment finality）+ add_ons（payment RPC + MPP 統合）。consensus / executor は Reth デフォルト。
- Berachain（bera-reth）の差し替え. consensus（Proof of Liquidity、流動性 stake）+ executor（PoL 報酬分配）+ add_ons（DEX-aware RPC）。
- MegaETH の深いカスタマイズ. executor（JIT/AOT EVM、revmc ベース）+ storage（MDBX → SALT）+ バリデータ別バイナリ（stateless-validator）= それでも fork なし。
- Thesis → コンポーネント差し替えマッピング. チェーンの thesis 1 文で 1-3 コンポーネント差し替えに対応。
- 不変の 80%. sync オーケストレータ + MDBX スキーマ + ヘッダーダウンロード + sender 復元 + ハッシング + Merkle + インデックス + JSON-RPC ランタイム + engine API + Tokio + tracing + メトリクス = 価値の大半。
具体例
経験的証拠:
| Chain | Reth との関係 | 証拠 |
|---|---|---|
| Tempo | 空 fork | tempoxyz/reth: upstream に対して 0 commits ahead, 1374 behind |
| MegaETH | 空 fork | megaeth-labs/reth: upstream に対して 0 commits ahead, 7666 behind |
| Berachain | fork ですらない | berachain/bera-reth: Reth crate を依存として使う独立 repo |
builder フロー:
flowchart TB
Builder["builder · .with_types"] --> Comps[".with_components"]
Comps --> Pool["pool — 受付ルール"]
Comps --> Net["network — P2P"]
Comps --> Exec["executor — EVM/Opcode/ガス"]
Comps --> Cons["consensus — PoS / HyperBFT 等"]
Comps --> Payload["payload — ブロック構築"]
Comps --> AddOns["add-ons — RPC + ExEx"]
AddOns --> Launch[".launch — あなたのチェーン"]
6 コンポーネント表:
| コンポーネント | 差し替える対象 | 解放されるもの |
|---|---|---|
pool | tx 受付・順序付け・追い出し | 優先レーン、payments-first 順序、アプリ固有 MEV ルール |
network | P2P トランスポート、ピアポリシー | プライベートサブネット、許可リスト、独自プロトコル |
executor | EVM 設定 | カスタム Opcode、カスタム precompile、カスタムガス表 |
consensus | ブロック検証ルール | PoS → HyperBFT、PoA、Tendermint、何でも |
payload | ブロックビルダー | MEV-aware 順序、アプリ固有バッチング |
add_ons | ランタイム外拡張 | カスタム JSON-RPC namespace、ExEx インストール |
それぞれに *Builder トレイト（PoolBuilder、NetworkBuilder 等）、SDK が .launch() 中に呼び出してサブシステム構築。
Hyperliquid HyperEVM の差し替え:
consensus— Ethereum PoS ではなく HyperBFTexecutor— オーダーブック直結（Opcode が perp オーダーブックと相互作用）pool— 高頻度 perp 更新ルール- その他 — Reth デフォルト
Tempo の差し替え:
pool— payments 優先レーン（マーチャント決済が高 gas DeFi tx の後ろで待たされない）payload— payment finality パターンに合わせたブロック構築add_ons— payment RPC namespace + Machine Payments Protocol（HTTP-402 エージェント決済）統合consensus/executor— Reth デフォルトで十分
隣接 crate（Reth 差し替えそのものではないが、Reth 未改造依存で成立）:
- Zones — confidential blockchain、250ms ブロック、TIP-403 compliance
- tidx — PostgreSQL+ClickHouse ハイブリッドインデクサ
Berachain (bera-reth) の差し替え:
consensus— Proof of Liquidity（流動性を BEX stake）executor— PoL 報酬分配が実行と相互作用add_ons— DEX-aware RPC namespace- 構造: GitHub fork ですらなく、Reth crate を依存とする独立 repo = 「compose, don't fork」の最鮮明表現
MegaETH の深いカスタマイズ（thesis = 100K+ TPS L1）:
executor— JIT/AOT EVM（revmc ベース）、mega-evm が revm を MegaETH 仕様でラップ- storage / state — MDBX を SALT に置き換え（30 億アイテム / 1 GB メモリ、state-root ランダム I/O 排除）
- バリデータ別バイナリ — stateless-validator が SALT witness でステートレス検証
consensus/pool/network— Reth デフォルト + 性能最適化- それでも
megaeth-labs/reth: 0 ahead, 7666 behind
Thesis → コンポーネント差し替えマッピング:
| Thesis | 差し替えるコンポーネント |
|---|---|
| 「オーダーブック結合 perp 高速実行」 | consensus、executor、pool |
| 「payment-priority L1」 | pool、payload、add_ons |
| 「流動性 stake PoS」 | consensus、executor、add_ons |
| 「JIT EVM + stateless validator で 100K+ TPS」 | executor、storage layer、validator client |
| 「shielded tx プライバシー L1」 | pool、executor、add_ons（カスタム RPC） |
不変の 80%:
- Sync オーケストレータ（M1 で読んだ
Stageパイプライン） - MDBX スキーマとストレージレイヤ
- ヘッダーダウンロード、sender 復元、ハッシング、Merkle、インデックス
- JSON-RPC サーバーランタイム、engine API サーバー
- Tokio ランタイム、トレース、メトリクス
失敗例（誤解）
「全 6 コンポーネント差し替えが本物のカスタマイズ」— 間違い。Tempo は 3 つだけ差し替え。thesis が要求する部分だけ差し替える が正解、不要なコンポーネントを差し替えても無意味 + メンテコスト増。
「MegaETH の SALT は標準 6 スロットではないので不可能」— 間違い。Reth のストレージ抽象を経由してプラグイン、6 コンポーネントを超えるカスタマイズも fork なしで可能。SDK の天井は標準 6 スロットを大きく超える。
「Reth デフォルトでは性能不足」— 間違い。不変の 80% が価値の大半（sync、ストレージ、MPT、Tokio）= 数年の最適化結果。差し替えるべきは thesis 固有部分のみ。
ステップで組み立てる
Step 1: fork なし証拠
Tempo / MegaETH = 0 ahead、Berachain = 独立 repo（fork ですらない）。
Step 2: 6 コンポーネントを役割で言える
pool / network / executor / consensus / payload / add_ons。
Step 3: 実本番チェーンの差し替えパターン
Hyperliquid（3 = consensus + executor + pool）/ Tempo（3 = pool + payload + add_ons）/ Berachain（3 = consensus + executor + add_ons）/ MegaETH（深 = executor + storage + validator）。
Step 4: Thesis → 差し替えマッピング
チェーン thesis 1 文 = 1-3 コンポーネント差し替えに対応。
Step 5: 不変の 80% を理解
sync + ストレージ + MPT + RPC + Tokio = 価値の大半、ここを差し替えない。
答え合わせ
- Hyperliquid が最も大きくカスタマイズしたコンポーネント: consensus（HyperBFT）+ executor（オーダーブック結合）。全 Reth fork ではなく差し替えだけ にした理由 = それ以外（sync、MDBX、ヘッダーダウンロード、sender 復元、RPC）を upstream Reth に追従、Paradigm のアップデートを rebase 地獄なしに取り込む。
- Payments-priority に pool が正しい差し替え先である理由: 受付・順序付け・追い出しの場、merchant 決済を高 gas DeFi tx の前に出すレーンを定義可能。consensus はブロック検証ルール = 何が valid ブロックかを決める、優先順位ではない。
- 「fork ではなく組み立てる」の保守上の論拠: Paradigm の毎週 update が 80% に流れ込む + 自分の fork 由来の表面積は書いた 20% に留まる。何年も運用するチェーンで唯一の保守可能パス。
合格基準
- 6 コンポーネントを役割で即答できる。
- Hyperliquid / Tempo / Berachain / MegaETH の差し替えパターンを言える。
- Thesis → コンポーネントマッピングを 5 例で言える。
- 不変の 80% を 5 領域で言える。
- 「fork ではなく組み立てる」の保守上の論拠を 1 文で説明できる。
まとめ（3行）
- 6 コンポーネント（pool / network / executor / consensus / payload / add_ons）の差し替えで Tempo / Berachain / MegaETH / Hyperliquid が fork なし で出荷。
- Thesis が要求する 1-3 コンポーネントだけ差し替え、不変の 80%（sync + ストレージ + MPT + RPC + Tokio）は Reth 継承 = 数年の最適化結果を活用。
- MegaETH が SDK 天井実証（executor + storage + validator client 差し替え + 0 ahead 維持）、Berachain が「compose, don't fork」最鮮明表現（独立 repo）。