Lesson 3 — Reth, Revm, Alloy — three pillars
Question
Three projects, three roles. Reth = full node, Revm = execution engine, Alloy = types + RPC + signers (a library set). Which layer does each fill, and how do they depend on each other?
Principle (minimum model)
- Reth = the full node (top layer). P2P + DB + consensus integration + EVM execution + RPC server. A complete product; users run a binary.
- Revm = the execution engine (middle layer). An EVM bytecode interpreter; doesn't carry state — it asks for state via the Database trait. Embedded in Reth / Foundry / Hyperliquid / Tempo.
- Alloy = the type foundation (bottom layer). Primitives like
Address/U256/B256.Providerfor RPC.Signerfor signatures. The substrate that dapps / indexers / MEV bots build on. Reth and Revm both depend on Alloy types. - Dependency direction. Alloy ← Revm ← Reth. Alloy is the lowest; Reth is the highest; each can be used independently.
- Learning order. Beginner = touch all three lightly → Intermediate (Inside Revm / Inside Reth / Inside Alloy) for the deep dive. Order is free; the dependency-order recommendation is Alloy → Revm → Reth.
Worked example + steps
Reth, Revm, Alloy — three pillars
These three names get muddled all the time, but they play very different roles. The cleanest analogy: building a car.
| Project | Role | Analogy |
|---|---|---|
| Alloy | Library suite (types, signing, RPC) | Engine, tires, screws |
| Revm | EVM execution engine | Combustion chamber |
| Reth | Full node implementation | The finished car |
Direction of dependency
- Reth depends on Alloy and Revm internally.
- "Learning Reth" automatically means touching Alloy and Revm.
graph TD
Reth["Reth — full node"]
Revm["Revm — EVM execution engine"]
Alloy["Alloy — primitives, signing, RPC"]
Reth -->|uses| Revm
Reth -->|uses| Alloy
Revm -->|uses| Alloy
What each one is for
Alloy (you'll touch this most often)
- Primitives like
Address,U256 - Signing via
PrivateKeySigner(EIP-191, EIP-712, etc.) - JSON-RPC clients via
Provider - The successor to
ethers-rs
Revm
- Smart contract simulation (compute outcomes before paying gas)
- Custom execution engines (custom opcodes, custom gas)
- High-speed tracing and backtesting
Reth
- Run a stock Ethereum full node
- Hook into the execution loop with ExEx (Execution Extensions)
- Use as the foundation for your own App-chain
Where Reth fits in the EVM client landscape
Reth is not the only Ethereum execution client — and not the dominant one yet. Per clientdiversity.org (May 2026):
| Client | Approx. share | Language |
|---|---|---|
| Geth | ~50% | Go |
| Nethermind | ~25% | C# |
| Besu | ~9% | Java |
| Reth | ~7-12% | Rust |
| Erigon | ~7% | Go |
Two things follow from this picture:
-
Reth is emerging, not dominant. It grew from <1% at its 2023 release to today's ~7-12% in three years — a fast trajectory, but Geth still serves the majority of mainnet RPC calls you make. The Alloy code you write will mostly talk to Geth-served chains in production. That's fine — Alloy speaks to any execution client over JSON-RPC.
-
Revm-based simulation needs to match what production clients do. When you run a transaction in a local Revm fork (the pattern you'll use in Intermediate + Building tiers), the result has to match what a Geth or Nethermind node would produce for the same transaction. This usually just works — Revm follows the EVM spec — but the discipline of validating Revm against a non-Revm provider is a production must. The Building tier capstone covers this.
So when you hear "the Rust EVM stack," read it as emerging + extensible, not as "winner take all." The reason Paradigm + Hyperliquid + Tempo build on Reth/Revm is what they enable (modularity, embeddability, performance), not market share.
Suggested learning order
Alloy → Revm → Reth
Going micro (types) → middle (execution) → macro (whole node) is the path of least friction.
The next tier of this course (Fundamentals) starts by getting your hands on Alloy directly. But before we set up Rust, one objection that always comes up is worth addressing head-on: "Solana is also Rust — why bother with EVM at all?" That's the next lesson.
Summary (3 lines)
- Three projects: Reth full node (top, binary) + Revm execution engine (middle, library) + Alloy type foundation (bottom, primitives + RPC + Signer).
- Dependency direction: Alloy ← Revm ← Reth. Each can be used independently. Hyperliquid / Foundry embed Revm; dapps / indexers use Alloy.
- Deep dive in the three Intermediate courses. Recommended order: Alloy → Revm → Reth. Next lesson: why not Solana.