Lesson 6 — Reth vs Geth / Alloy vs ethers-rs — the substitution case
Question
Reth targets to replace Geth (Go). Alloy targets to replace ethers-rs (the earlier Rust library). Why replace existing things? Performance + design + maintenance — three axes that justify the substitution.
Principle (minimum model)
- Reth vs Geth — performance. Reth syncs 2–3× faster than Geth (measured). Rust ownership + zero-cost abstractions + parallelism are the reason; memory footprint is also smaller.
- Reth vs Geth — modularity. Reth SDK turns a full node into an SDK. Precompiles / state machine / consensus are all swappable → Hyperliquid built a perp-specific L1 on top; Tempo built a settlement L1. Geth is monolithic; modification is bounded.
- Alloy vs ethers-rs — design. Alloy is Network-generic (Ethereum / Optimism / custom L2 all under one type system) + Provider trait + Filler stacking. ethers-rs is Ethereum-fixed + internally hardcoded; extensibility differs structurally.
- Alloy vs ethers-rs — maintenance. ethers-rs stalled when its maintainer joined the Foundry team. Alloy is actively developed by Paradigm (commit frequency + issue response); the ecosystem is migrating.
- Substitution timing. New projects → Reth + Alloy recommended. Existing Geth / ethers-rs projects → migrate based on cost-benefit; Foundry / Hyperliquid / major rollups have already migrated.
Worked example + steps
Reth vs Geth / Alloy vs ethers-rs — the substitution case
You've placed the projects on a map. Now the next-most-asked question: why are teams actively migrating off the older alternatives? Geth has run Ethereum for a decade. ethers-rs was the Rust Ethereum library for years. Yet new infrastructure is being built on Reth and Alloy. This lesson is why — substitution by substitution.
1. Reth vs Geth
Geth (Go-Ethereum) is the original execution client. It's run mainnet since 2015, holds ~40–50% of execution client share, and the team behind it is excellent. Reth is not "Geth but better." It's a different design that earns its place by what Geth structurally can't do.
| Property | Geth | Reth | Why it matters |
|---|---|---|---|
| Language | Go | Rust | Cargo workspaces let you import revm as a library and use it standalone — Geth's execution engine is welded to the node and can't be reused. |
| Architecture | Tightly coupled | Modular crates (revm, alloy, reth-stages, reth-network, reth-rpc, etc.) | You can fork one crate (e.g., custom executor) without forking the entire node — central to the App-chain / L1 fork pattern. |
| State storage | LevelDB-based, evolving | MDBX (memory-mapped B+tree) | Stable read latency under heavy compaction. Geth has historically struggled with compaction stalls on archive nodes. |
| Execution engine | go-ethereum's interpreter | revm (Rust, library-first) | revm is reused by Foundry, Hyperliquid's HyperEVM, every Rust-based MEV stack — Geth's interpreter has no consumers outside Geth itself. |
| Sync strategy | Snap sync | Staged sync (10-stage pipeline) | Staged sync amortizes I/O across whole batches; faster initial sync and easier to extend with custom stages. |
| Extension API | None publicly maintained | ExEx (Execution Extensions) — in-process Rust hooks | Build node-speed indexers, MEV bots, risk engines inside the node, no RPC round trips. Geth has nothing equivalent. |
| Chain forking | Hard (entire fork-of-Geth) | Easy (Reth SDK: swap one component, keep the rest) | Hyperliquid's HyperEVM, Tempo, MegaETH, Base (OP-Reth), Berachain all use this pattern. |
| Reuse footprint | Geth's code is used by Geth | Reth's components (revm, alloy, reth-* crates) are reused by 100+ projects | Every Rust EVM tool you'll touch is built on top of one of these crates. |
Concretely: a team shipping a payments-priority L1 with custom transaction ordering forks Reth — and they don't even fork the whole thing. They depend on Reth's crates and replace only the Pool and Payload components. With Geth they'd fork the whole codebase, accept the rebase tax forever, and inherit a 200K-line surface they don't want to maintain. This is exactly what Tempo does, and what every other Reth-based L1 in the table from the previous lesson does.
Reth wasn't built to dethrone Geth. It was built to be the substrate the next generation of chains builds on. That's a different category.
2. Alloy vs ethers-rs
ethers-rs was the Rust Ethereum library from ~2020 to 2024. Then in mid-2024, ethers-rs's maintainer (Georgios Konstantopoulos / Paradigm) deprecated it in favour of Alloy. The migration wasn't gradual or aesthetic — it was a deliberate redesign with specific properties ethers-rs structurally couldn't deliver.
| Property | ethers-rs | Alloy | Why it matters |
|---|---|---|---|
| Modularity | Monolithic crates | Many small crates (alloy-provider, alloy-network, alloy-primitives, alloy-signer, alloy-rpc-types, ...) | You pull in only what you need; Cargo bloat shrinks dramatically. |
| Async style | async-trait (allocates Box per call) | Native async traits + ProviderCall (zero-cost) | Hot paths (MEV, RPC servers) measurably benefit from no per-call allocation. |
| Multi-chain | Ethereum-only types | Network trait abstracts chain primitives | Same Provider code works on Ethereum, Optimism, custom L2s — Inside Alloy walks this. |
| Type ergonomics | Bespoke types, separate from revm | Uses revm's Address, U256, B256 directly | One set of types across alloy + revm + reth. No conversion boilerplate. |
| Wallet / signer composability | Coupled to one Provider design | Signer + Filler traits compose via ProviderBuilder | Custom signing, nonce management, gas estimation layer cleanly. Inside Alloy's Signer chain teaches this. |
Procedural macros (sol!) | External crate, looser integration | First-class, used throughout alloy | Define Solidity types in Rust at compile time; no manual ABI structs. Used in every Rust Solidity-interop project. |
| Maintainership | One person at Paradigm, time-limited | Funded Paradigm project + community | Active development, fast PR turnaround, clear roadmap. |
If you're writing a new MEV searcher in 2026, you'd choose Alloy because (a) you share types with revm (and your fork simulation lives in revm), (b) you can compose your own Signer with cloud KMS or hardware without rewriting the Provider, (c) your code runs on Optimism / Base / any Reth-based L2 with one type parameter change, and (d) ethers-rs no longer receives bug fixes from Paradigm. Inertia is the only reason to stick with ethers-rs, and inertia gets weaker every quarter.
3. The pattern across both substitutions
Geth and ethers-rs are not bad. They're products of an earlier moment in the Rust EVM ecosystem — when the priority was "make it work" rather than "make it composable across N downstream projects."
Reth and Alloy share a deliberate design choice: composability over completeness. Both expose internal pieces as library crates that downstream projects can mix, match, and replace. Geth and ethers-rs were designed as products to be consumed; Reth and Alloy are designed as substrates to be extended.
This is the structural reason the rest of this curriculum exists. The lessons that come next — Inside Revm, Inside Reth, Inside Alloy — teach you to read the substrate. Once you can read it, you can build on it. That's the leverage Geth and ethers-rs structurally couldn't offer.
Two reads of the same pattern: payments-priority L1s fork Reth instead of Geth because Reth's crates compose; new MEV searchers pick Alloy over ethers-rs because Alloy shares types with revm and stays maintained. Both are decisions about substrates versus products — keep that lens for the rest of the curriculum.
Next up
With this lesson, Module 0 is complete: the systems-engineering frame from lesson 0, the project map (Reth / Revm / Alloy), the Solana / Solidity onramps, and now the substitution case. Module 1 sets up Rust on your machine so you can start reading source. The frame from lesson 0 starts paying off the moment you open the first alloy-rs/alloy file.
Summary (3 lines)
- Reth vs Geth: 2–3× faster sync + SDK modularity (Hyperliquid / Tempo as case studies). Alloy vs ethers-rs: Network-generic design + active Paradigm maintenance.
- New projects → Reth + Alloy. Existing Geth / ethers-rs migrate based on cost-benefit. Foundry / Hyperliquid / major rollups have migrated.
- Module 1 next: Rust environment setup (rustup + VS Code + rust-analyzer).