レッスン6 — Reth vs Geth / Alloy vs ethers-rs — 置き換えの根拠
問い
Reth は Geth（Go）の置き換えを狙う、Alloy は ethers-rs（先行 Rust ライブラリ）の置き換えを狙う。なぜ既存があるのに置き換えるか？ 性能 + 設計 + メンテナンスの 3 軸で根拠を整理。
原理（最小モデル）
- Reth vs Geth — 性能差. Reth の sync は Geth より 2-3 倍速い（実測ベンチ）、Rust の所有権 + ゼロコスト抽象化 + 並列化容易が原因、メモリ使用も少ない。
- Reth vs Geth — モジュラリティ. Reth SDK でフルノードを SDK 化、precompile / state machine / consensus を差し替え可能 → Hyperliquid が perp 専用 L1、Tempo が決済 L1 構築、Geth は monolithic で改造範囲限定。
- Alloy vs ethers-rs — 設計. Alloy は Network ジェネリック（Ethereum / Optimism / カスタム L2 横断）+ Provider trait + Filler 層状合成、ethers-rs は Ethereum 固定 + 内部ハードコード、拡張性で根本差。
- Alloy vs ethers-rs — メンテナンス. ethers-rs は元メンテナが Foundry チーム抜けて停滞、Alloy は Paradigm 中心の活発開発（commit 頻度 + issue 応答）、エコシステムが移行中。
- 置き換えタイミング. 新規プロジェクトは Reth + Alloy 推奨、既存 Geth / ethers-rs プロジェクトは移行コスト見合いで段階的に、Foundry / Hyperliquid / 主要 rollup は移行済み。
具体例 + ステップで組み立てる
Reth vs Geth / Alloy vs ethers-rs — 置き換えの根拠
プロジェクトの地図は前レッスンで描いた。次の問いはこれである。なぜチームは古い選択肢から積極的に移行するのか。 Geth は 10 年間 Ethereum を走らせ、ethers-rs は長らく Rust Ethereum ライブラリの定番だった。それでも新しいインフラは Reth と Alloy 上に作られる。その理由を、置き換え1件ずつ見る。
1. Reth vs Geth
Geth (Go-Ethereum) は元祖の execution client である。2015 年から mainnet を走らせ続け、現在も execution client シェア 40〜50% を握り、開発チームも強い。Reth は「より良い Geth」ではない。 Geth が構造的にできないことで価値を出す、別種の設計である。
| 性質 | Geth | Reth | なぜ重要か |
|---|---|---|---|
| 言語 | Go | Rust | Cargo workspace で revm をライブラリとして単独利用できる。Geth の execution engine はノードに溶接され再利用しにくい。 |
| アーキテクチャ | 強結合 | モジュラな crate (revm、alloy、reth-stages、reth-network、reth-rpc など) | ノード全体ではなく 1つの crate（例: カスタム executor）だけを fork できる。App-chain / L1 fork パターンの中核である。 |
| 状態ストレージ | LevelDB ベース、進化中 | MDBX (メモリマップ B+tree) | コンパクション負荷下でも読み取りレイテンシが安定する。Geth は archive node のコンパクション停滞に長く苦戦してきた。 |
| 実行エンジン | go-ethereum のインタープリター | revm (Rust、ライブラリ志向) | revm は Foundry、Hyperliquid の HyperEVM、Rustベース MEV スタックで再利用される。Geth のインタープリターは Geth 外での消費がほぼない。 |
| 同期戦略 | Snap sync | Staged sync (10 段パイプライン) | バッチ全体で I/O を償却するため、初期同期が速く、カスタムステージで拡張もしやすい。 |
| 拡張 API | 公式にメンテされた仕組みなし | ExEx (Execution Extensions) — インプロセスの Rust フック | ノード 内側で ノード速度のインデクサ・MEV ボット・リスクエンジンを動かせ、RPC を経由しません。Geth には等価物がありません。 |
| チェーン fork | 困難 (Geth 全体を fork する必要) | 容易 (Reth SDK で 1 コンポーネントだけ差し替え) | Hyperliquid の HyperEVM、Tempo、MegaETH、Base (OP-Reth)、Berachain がこのパターンで作られる。 |
| 再利用範囲 | Geth のコードは Geth が使う | revm、alloy、reth-* crate は 100 超のプロジェクトで再利用 | 触れる Rust EVM ツールの多くは、これら crate のいずれかの上に乗る。 |
決済優先の独自トランザクション順序付けを持つL1を ship する場面を想像してほしい。fork するのはRethで、しかも全体ではない。Reth crate に依存したまま Pool と Payload だけを差し替える。Geth なら全コードベースをforkし、長期リベース税と巨大コード保守を抱える。これを Tempo が実践し、前レッスンで挙げた Reth ベース L1 も同型を採る。
Reth は Geth を退位させるために作られたのではない。 次世代チェーンが上に乗る 基盤 として作られた。Reth と Geth はそもそも別カテゴリである。
2. Alloy vs ethers-rs
ethers-rs は 2020〜2024 年に Rust Ethereum ライブラリの定番だった。2024 年半ば、メンテナ（Georgios Konstantopoulos / Paradigm）が Alloy 移行を進めるため ethers-rs を deprecate した。これは美的判断ではなく、ethers-rs が構造的に届かない性質を狙った再設計である。
| 性質 | ethers-rs | Alloy | なぜ重要か |
|---|---|---|---|
| モジュラ性 | モノリシックな crate | 細かい crate 群 | 必要分だけ依存に加えられ、Cargo依存ツリーが縮む。 |
| 非同期スタイル | async-trait（呼び出しごとに Box 確保） | ネイティブ async trait + ProviderCall (確保なし) | ホットパス（MEV、RPC）で呼び出しごとの確保が減り体感差が出る。 |
| マルチチェーン | Ethereum 専用型 | Network トレイトで抽象化 | 同じ Provider コードが Ethereum / Optimism / 独自L2で動く。 |
| 型のエルゴノミクス | 独自型、revmと別系列 | revm の Address、U256、B256 をそのまま使用 | alloy + revm + reth で型がそろい、変換ボイラープレートが減る。 |
| ウォレット / 署名者の合成 | 単一Provider設計に密結合 | Signer + Filler を ProviderBuilder で重ねる | 署名・nonce管理・ガス推定を分離して合成できる。 |
手続きマクロ (sol!) | 外部 crate、結合は緩い | 第一級、alloy 全体で使われる | Solidity 型を Rust 側でコンパイル時に定義でき、手書きの ABI struct が要りません。 |
| メンテナンス | Paradigm 内の 1 人、時間も限定 | Paradigm が予算をつけ、コミュニティも参加 | 開発が活発で、PR の回りが速く、ロードマップも明確。 |
2026年に新しい MEV searcher を書く立場を想像すると、Alloy を選ぶ理由は明確である。(a) revm と型共有できる、(b) クラウドKMSやHWウォレットを独自 Signer として差し込める、(c) 型パラメータ1つで Optimism / Base / 任意Reth系L2へ展開できる、(d) ethers-rs に Paradigm 由来の新規修正が来ない。ethers-rs に残る理由は惰性が中心 である。
3. 2 つの置き換えに共通するパターン
Geth と ethers-rs が悪いわけではない。Rust EVM エコシステムが若かった時代に、「合成可能性」より「まず動かす」を優先した設計の産物である。
Reth と Alloy は同じ設計判断を共有する。完全性より合成性である。 どちらも内部を crate として切り出し、下流プロジェクトが混ぜて差し替えられる。Geth と ethers-rs は完成品利用前提、Reth と Alloy は拡張基盤前提で設計される。
これが、このカリキュラム後半が存在する構造的理由である。続く Inside Revm / Reth / Alloy は、その基盤を読むスキルを教える。 読めれば作れる。それが Geth と ethers-rs が構造的に提供しにくかったレバレッジである。
このレッスン後に残すべき答えは2つである。決済優先L1チームが Geth ではなく Reth を fork する理由、そして 2026 年の新規 MEV searcher が ethers-rs ではなく Alloy を選ぶ理由である。どちらも上表に答えがある。
次へ
本レッスンで Module 0 は完了: レッスン 0 の systems-engineering 枠、プロジェクト map（Reth / Revm / Alloy）、Solana / Solidity onramp、そして本レッスンの substitution case。Module 1 で Rust をマシンにセットアップ、ソース読みを始められる状態にする。最初の alloy-rs/alloy ファイルを開いた瞬間から、レッスン 0 の枠が報われ始める。
まとめ（3行）
- Reth vs Geth = 2-3 倍速い + SDK モジュラリティ（Hyperliquid / Tempo 等で実例）、Alloy vs ethers-rs = Network ジェネリック + 活発メンテナンス。
- 新規は Reth + Alloy 推奨、既存は移行コスト見合い、Foundry / Hyperliquid / 主要 rollup は移行済み = エコシステムが Rust スタックに動いている。
- なぜ学ぶか（業界トレンド + キャリア複利 + 性能 + 設計）が固まった、次モジュールで Rust 環境セットアップ。