FABRKNT
Reth 入門 — Rust Ethereum の世界へ
なぜRust Ethereumスタックなのか
レッスン 4 / 11·CONTENT10 分20 XP
コース
Reth 入門 — Rust Ethereum の世界へ
レッスンの役割
CONTENT
順序
4 / 11

レッスン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)エンジン、タイヤ、ネジ
RevmEVM実行エンジン燃焼室(命令を実行する場所)
Rethフルノード実装完成した自動車

依存の方向

  • Reth は内部で AlloyRevm を全面的に採用している。
  • つまり「Rethを学ぶ=Alloy/Revmにも触れる」となる。
graph TD
    Reth["Reth — フルノード"]
    Revm["Revm — EVM 実行エンジン"]
    Alloy["Alloy — プリミティブ・署名・RPC"]
    Reth -->|uses| Revm
    Reth -->|uses| Alloy
    Revm -->|uses| Alloy

それぞれの「使い道」

Alloy(最も触れる機会が多い)

  • AddressU256 など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つの結論が出ます:

  1. Rethは新興であり、支配的ではない。 2023年リリース時の<1%から3年で~7-12%へ成長したのは速いが、mainnetのRPCコール大半を捌くのは依然Gethである。本番で書くAlloyコードの大半は、Gethが応答するチェーンと通信する。 これは問題ではなく、AlloyはJSON-RPC経由でどのexecution clientとも話せる。
  2. 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)。