Lesson 11 — The 6 components — what each one unlocks

Question

6 components: Consensus / Network / Pool / Executor / Validator / RPC. Each is a trait you can implement. What customising each one unlocks.

Principle (minimum model)

• Consensus. Replace Ethereum PoS with anything (PoL / HotStuff / Custom). bera-reth uses this.
• Network. Customise the P2P stack (devp2p / libp2p / custom). HyperLiquid uses this.
• Pool. Transaction mempool policy. Tempo uses this for stable-coin filtering.
• Executor. EVM execution. revm is the default; you could swap to a custom interpreter (revmc JIT).
• Validator. Block / tx validation. Custom L2s differ here (Optimism / Arbitrum).
• RPC. JSON-RPC server. Add custom methods (per-chain features).
• Default impls. Reth provides default Ethereum impls for all 6. You replace only what you customise.
• Composition. Each component depends on others via trait bounds. The type system ensures you compose them correctly.

Worked example + steps

The 6 components — what each one unlocks

Tempo is building a payments L1 on Reth. Berachain ships bera-reth. MegaETH is building a high-throughput L1 on Reth. Hyperliquid runs HyperEVM (their own Reth-adjacent execution layer). None of them forked Reth — they each swapped a few of Reth's 6 components and inherited the rest. That's the SDK's whole pitch: don't rewrite a Rust EVM client, swap the parts that matter to your thesis. This lesson walks those 6 components — and shows what each swap unlocked for production chains.

The empirical proof, today:

Every chain that touches Reth uses upstream-as-library. The customizations live entirely in their own crates.

flowchart TB
    Builder["builder · .with_types"] --> Comps[".with_components"]
    Comps --> Pool["pool — admission rules"]
    Comps --> Net["network — P2P"]
    Comps --> Exec["executor — EVM, opcodes, gas"]
    Comps --> Cons["consensus — PoS / HyperBFT / etc."]
    Comps --> Payload["payload — block building"]
    Comps --> AddOns["add-ons — RPC + ExEx"]
    AddOns --> Launch[".launch — your chain"]

The 6 components, walked

Each gets a *Builder trait — PoolBuilder, NetworkBuilder, etc. — that the SDK calls during .launch() to construct the actual subsystem.

Hyperliquid HyperEVM — what they swap

• consensus — They run HyperBFT (their own Byzantine-fault-tolerant consensus protocol), not Ethereum PoS. The consensus subsystem is replaced.
• executor — Order-book-coupled execution: certain opcodes interact with the perp order book that lives alongside the EVM. Custom executor.
• pool — Admission rules tuned for high-frequency perp updates.
• everything else — Reth defaults.

Tempo — what they swap

Tempo's source is now public (tempoxyz/tempo — 900+★, "the blockchain for payments"). Worth knowing before you open it: their Reth fork at tempoxyz/reth is 0 commits ahead, 1374 commits behind upstream Paradigm Reth. They did not fork Reth at all. The entire payments-specific customization lives in the tempoxyz/tempo crate, which depends on upstream Reth as a library.

That's the strongest possible empirical proof of the SDK's pitch — and it tells you exactly which components Paradigm's design enabled them to swap without touching the 80% they inherit:

• pool — Payment-prioritized lanes. A merchant payment shouldn't wait behind a high-gas DeFi tx; the pool surfaces them differently.
• payload — Block construction tuned for payment-finality patterns.
• add_ons — Custom RPC namespaces for payment-specific endpoints, plus integration with the Machine Payments Protocol (their HTTP-402 layer for agent payments).
• consensus / executor — Reth defaults are sufficient; they did not need a custom EVM or custom consensus.

Adjacent novel surfaces worth knowing they shipped (not direct Reth component swaps, but enabled by the unmodified Reth dependency):

• Zones — confidential blockchains anchored to Tempo, with encrypted deposits/withdrawals and 250ms block times. Compliance policies (TIP-403) inherited from L1.
• tidx — PostgreSQL+ClickHouse hybrid indexer for hot point lookups + analytics.

The pattern: swap the parts that match your thesis, keep everything else. Tempo's thesis is payments-priority; the components they swap reflect that. They didn't need a custom executor (no custom opcodes) or custom consensus (standard L1 PoS works), so they didn't write those.

Berachain (bera-reth) — what they swap

• consensus — Proof of Liquidity: validators stake liquidity into BEX (their DEX) instead of staking the native token alone. The consensus rules differ from Ethereum PoS.
• executor — Coupled with PoL, so reward distribution interacts with execution differently.
• add_ons — DEX-aware RPC namespaces.
• everything else — Reth defaults.

berachain/bera-reth is interesting structurally too: it's not even a GitHub fork of upstream Reth — it's a fresh repo that depends on Reth crates. Even cleaner expression of "compose, don't fork" than the empty-fork pattern Tempo and MegaETH use.

MegaETH — what they swap

MegaETH (megaeth-labs/) is a 100K+ TPS L1 thesis built on Reth. The customization is deeper than Tempo's because the thesis (raw throughput) reaches further into execution and storage:

• executor — JIT/AOT compiled EVM on the sequencer (built on Paradigm's revmc). megaeth-labs/mega-evm wraps revm with MegaETH-specific specs.
• storage / state — They replaced MDBX with SALT (Small Authentication Large Trie) — an authenticated KV store that holds ~3B items in 1 GB of memory and eliminates random disk I/O during state-root updates. This is not one of the standard 6 component slots; SALT plugs in via Reth's storage abstractions.
• validators run a different binary — megaeth-labs/stateless-validator verifies blocks statelessly using SALT witnesses, so validators need a fraction of sequencer hardware.
• consensus / pool / network — Reth defaults plus their performance optimizations.

The MegaETH picture is important pedagogically because it shows the SDK's ceiling: how deep customization can go without forking core Reth. Tempo swaps a few components and keeps everything else. MegaETH replaces the EVM executor and the storage layer and still doesn't fork Reth (megaeth-labs/reth: 0 ahead, 7666 behind).

The pattern: swap what your thesis demands

If you can articulate your chain's thesis in one sentence, you can usually map it to 1–3 component swaps:

🔍 Find in repo. Open EthereumNode::components()'s definition. The default builders for each component are listed there — that's the menu of "what comes for free."

What stays constant: the load-bearing 80%

The components you don't swap are the bulk of the value:

• Sync orchestrator (the Stage pipeline you read in Module 1)
• MDBX schema and storage layer
• Header download, sender recovery, hashing, Merkle, indexes
• JSON-RPC server runtime, engine API server
• Tokio runtime, tracing, metrics

This is why "compose, don't fork" is the only viable maintenance story for an L1 you intend to run for years. Paradigm's updates flow into the 80%; your fork-shaped surface area stays in the 20% you wrote.

Recall before the quiz

Without scrolling:

1. Of the 6 components, which would Hyperliquid most heavily customize, and why?
2. Why is pool the right component to swap for payments-priority, not consensus?
3. What's the maintenance argument for "compose, don't fork"?
4. Sketch the minimum set of components you'd swap to ship a privacy-focused L1.

The next lesson is a quiz. Engage with these recalls now if any answer is shaky.

Summary (3 lines)

• 6 components: Consensus / Network / Pool / Executor / Validator / RPC. Default impls for all 6; replace selectively.
• bera-reth (Consensus) / HyperLiquid (Network) / Tempo (Pool) / custom L2s (Validator) — each customises a few.
• Type-system composition. Next: quiz.