レッスン3 — Reth・Revm・Alloy の三つ巴
問い
3 プロジェクトの役割分担を整理する。Reth = フルノード、Revm = 実行エンジン、Alloy = 型 + RPC + 署名のライブラリ群。それぞれが Ethereum スタックのどの層を担い、どこで他に依存するか?
原理(最小モデル)
- Reth = フルノード(最上層). P2P + DB + コンセンサス統合 + EVM 実行 + RPC server、完成品、ユーザーは binary を動かす。
- Revm = 実行エンジン(中間層). EVM bytecode インタープリター、状態は持たず Database トレイトで外部供給、Reth / Foundry / Hyperliquid / Tempo が組み込み。
- Alloy = 型基盤(最下層).
Address/U256/B256等の primitive、Providerで RPC、Signerで署名、dapp / インデクサ / MEV ボットの土台、Reth と Revm も alloy 型に依存。 - 依存方向. Alloy ← Revm ← Reth、Alloy が一番下、Reth が一番上、各々独立に使える。
- 学習順. Beginner で 3 つ同時に薄く触れる → 中級 3 コース(Inside Revm / Inside Reth / Inside Alloy)で深掘り、順序自由(依存的には Alloy → Revm → Reth が推奨)。
具体例 + ステップで組み立てる
Reth・Revm・Alloyの三つ巴
3つの名前は混同されがちだが、役割はまったく違う。「自動車を作る」 で例えるとシンプルである。
| プロジェクト | 役割 | 例え |
|---|---|---|
| Alloy | ライブラリ群(型、署名、RPC) | エンジン、タイヤ、ネジ |
| Revm | EVM実行エンジン | 燃焼室(命令を実行する場所) |
| Reth | フルノード実装 | 完成した自動車 |
依存の方向
- Reth は内部で Alloy と Revm を全面的に採用している。
- つまり「Rethを学ぶ=Alloy/Revmにも触れる」となる。
graph TD
Reth["Reth — フルノード"]
Revm["Revm — EVM 実行エンジン"]
Alloy["Alloy — プリミティブ・署名・RPC"]
Reth -->|uses| Revm
Reth -->|uses| Alloy
Revm -->|uses| Alloy
それぞれの「使い道」
Alloy(最も触れる機会が多い)
- Address、U256 などEthereumの基本データ型
- PrivateKeySigner によるEIP-712などの署名
- Provider によるJSON-RPC通信
- ETHers-rs の事実上の後継
Revm
- スマートコントラクトの シミュレーション(取引前に結果を計算)
- カスタムOpcodeを追加した 専用実行エンジン の構築
- バックテストや高速トレース
Reth
- 標準的なEthereumフルノードとして動かす
- ExEx (Execution Extensions) で実行ループにフックして拡張
- 独自のApp-chainの基盤として使う
EVM クライアント市場での Reth の位置
Reth は 唯一の Ethereum execution client ではなく、まだ支配的でもありません。clientdiversity.org(2026年5月時点)から:
| クライアント | 概算シェア | 言語 |
|---|---|---|
| Geth | ~50% | Go |
| Nethermind | ~25% | C# |
| Besu | ~9% | Java |
| Reth | ~7-12% | Rust |
| Erigon | ~7% | Go |
ここから2つの結論が出ます:
- Rethは新興であり、支配的ではない。 2023年リリース時の<1%から3年で~7-12%へ成長したのは速いが、mainnetのRPCコール大半を捌くのは依然Gethである。本番で書くAlloyコードの大半は、Gethが応答するチェーンと通信する。 これは問題ではなく、AlloyはJSON-RPC経由でどのexecution clientとも話せる。
- Revmベースのシミュレーションは本番クライアント挙動と一致する必要がある。 ローカルRevm forkでtxを実行する場合(中級 + Building tierのパターン)、結果はGethやNethermindで同じtxを処理した結果と一致すべきである。通常はそうなるが、Revm結果を非Revm providerに対して検証する 規律は本番運用で必須である。Building tierのcapstoneで扱う。
つまり「Rust EVMスタック」は 新興かつ拡張可能 と捉えるべきで、「勝者総取り」ではない。Paradigm・Hyperliquid・TempoがReth/Revm上に積む理由は市場シェアではなく、モジュラリティ・組み込みやすさ・性能にある。
学習の順番
Alloy → Revm → Reth
理由:「ミクロ(型)→ ミドル(実行)→ マクロ(ノード全体)」と進むのが最も挫折しにくいから。
このコースの次のティアであるFundamentalsで、まずAlloyから手を動かす。ただしRust環境を整える前に、よく出る疑問を1つ片付ける。「SolanaもRustなのに、なぜEVMか?」 を次のレッスンで扱う。
まとめ(3行)
- 3 プロジェクト = Reth フルノード(最上層、binary)+ Revm 実行エンジン(中間層、ライブラリ)+ Alloy 型基盤(最下層、primitive + RPC + Signer)。
- 依存方向 = Alloy ← Revm ← Reth、各々独立に使える、Hyperliquid / Foundry が Revm を組み込み、dapp / インデクサが Alloy を使う。
- 中級 3 コース(Inside Revm / Inside Reth / Inside Alloy)で深掘り、推奨順は Alloy → Revm → Reth、次はなぜ Solana でなく Ethereum (Rust)。