Verifiable RPC via ExEx: Cryptographically Attested State Roots for RPC Responses

[owizdom]

---

Summary

Hey @gakonst , I built a proof-of-concept ExEx that I'd love to get feedback on and potentially see land upstream (or at least get a formal endorsement as a reference implementation).

The short version: every time a Reth node commits a block, the ExEx signs the state root with EIP-712, and a new vrpc_* RPC namespace attaches those signed attestations alongside standard EIP-1186 Merkle proofs to every response. Clients can then verify correctness without trusting the infrastructure.

This writeup lays out the design, the implementation, the tradeoffs, and the specific places where I'd want Reth core's input before trying to turn this into anything more permanent.

---

Motivation

The Ethereum execution layer is cryptographically verifiable end-to-end — except for the last mile. When a wallet, dApp, or protocol calls eth_getBalance, eth_call, or eth_getStorageAt, it trusts the RPC provider implicitly. There is no standard mechanism to verify that the response corresponds to the canonical chain's state.

This creates a structural problem:

• 6,000+ full nodes verify Ethereum but earn zero revenue from doing so.
• Centralized RPC providers act as trusted intermediaries and capture the entire $135M+ NaaS market (projected $318M by 2032) on the back of that trust gap.
• Protocols that settle trillions of dollars (stablecoins settled $27T+ in 2024) still bootstrap every transaction with an unverifiable RPC call.

The fix is to make trust mathematical rather than organizational: sign the state root you executed against, attach an EIP-1186 proof, and let clients verify locally.

---

What I Built

The project (reth-verifiable-rpc) is a four-crate Reth workspace:

  vrpc-attestation  — EIP-712 types, sign_state_root(), verify_attestation()
  vrpc-exex         — ExEx that hooks into block commits and signs state roots
  vrpc-rpc          — Four new vrpc_* JSON-RPC methods
  vrpc-node         — Drop-in Reth binary that wires everything together

Plus two Solidity contracts (NodeRegistry, StateRootRegistry) and a Foundry test suite, but those are out of scope for a Reth issue — including them here for context.

---

Technical Design

ExEx Integration

The ExEx listens to ExExNotification events and handles all three cases:

Notification	Action
ChainCommitted	Call sign_state_root() for every new block; insert into AttestationStore
ChainReverted	Evict attestations for reverted block numbers
ChainReorged	Evict old canonical blocks + attest new canonical chain

The AttestationStore is an Arc<DashMap<u64, SignedStateAttestation>> shared between the ExEx task and the RPC handlers. DashMap was chosen for lock-free concurrent reads since RPC threads outnumber ExEx threads dramatically at runtime.

EIP-712 Attestation

// Struct type (via alloy sol! macro)
sol! {
    struct StateAttestation {
        uint64  chainId;
        bytes32 stateRoot;
        uint64  blockNumber;
        address nodeAddress;
        uint64  timestamp;
    }
}

Domain:
name:              "VerifiableRPC"
version:           "1"
chainId:           <from CLI or node config>
verifyingContract: <optional NodeRegistry address>

Signing is async (sign_state_root() uses alloy_signer_local::PrivateKeySigner) and happens on the ExEx task, not the RPC thread, so signing latency doesn't affect RPC response time. The RPC layer simply does a DashMap lookup.

Proof Generation

The RPC handler calls Reth's StateProofProvider:

  let proof = provider
      .history_by_block_number(block_number)?
      .proof(TrieInput::default())
      .account_proof(address, &[])?;

Because Reth already computed the Merkle trie during execution, this is essentially a trie traversal over already-materialized data — no re-execution required. Proof sizes are ~2-3 KB for account proofs and scale linearly with the number of storage slots.

RPC Methods

  vrpc_getBalanceWithProof(address, blockTag)
    → { balance, nonce, codeHash, storageHash, accountProof[], blockNumber, stateRoot, attestation }

  vrpc_getStorageAtWithProof(address, slot, blockTag)
    → { value, storageProof[], blockNumber, stateRoot, attestation }

  vrpc_getAttestation(blockNumber)
    → { chainId, stateRoot, blockNumber, nodeAddress, timestamp, signature }

  vrpc_nodeInfo()
    → { nodeAddress, chainId, latestAttestedBlock, attestationCount }

All methods are added via Reth's extend_rpc_modules hook — zero fork required.

CLI Extension

The binary extends Reth's CLI with:

  --vrpc.key <hex>          Operator signing key (hex-encoded private key)
  --vrpc.keystore <path>    eth-keystore JSON file
  --vrpc.registry <addr>    StateRootRegistry contract address (for EIP-712 domain)
  --vrpc.chain-id <id>      Override chain ID in EIP-712 domain

If neither --vrpc.key nor --vrpc.keystore is provided, an ephemeral key is generated
at startup (useful for local dev / testing).

---

Current Status

• Full EIP-712 attestation signing and verification (unit-tested, round-trip verified)
• ExEx with reorg handling (unit-tested: attest → revert → re-attest)
• Four vrpc_* RPC methods implemented and wired up
• Drop-in node binary with CLI extension
• Foundry test suite for contracts (6 tests + fuzz)
• On-chain attestation submission from ExEx (off-chain signing only today)
• Complete slashing iteration in resolveDispute (stub, not production-ready)
• Off-chain EIP-712 charge vouchers for query fee batching (designed, not built)

---

Specific Questions for Reth Core

1. StateProofProvider API stability

I'm calling history_by_block_number(n).proof(TrieInput::default()).account_proof(...). Is this surface considered stable? I noticed the TrieInput API changed between minor versions. Is there a recommended pattern for proof generation in ExEx/plugin contexts that won't break on upgrades?

2. ExEx + RPC shared state pattern

The current design uses Arc passed from the ExEx initializer into the RPC extension via a closure. This works but feels slightly awkward — the node binary has to manually thread the Arc through both install_exex and extend_rpc_modules closures.

Is there a preferred pattern in Reth for ExEx-to-RPC communication? A shared context type, an event bus, or a node extension trait that would be cleaner here?

3. BlockNumberOrTag resolution in RPC handlers

For BlockNumberOrTag::Latest / BlockNumberOrTag::Finalized / BlockNumberOrTag::Safe, I'm calling provider.best_block_number() / provider.finalized_block_number() etc. Is there a canonical helper for this tag-to-number resolution that I should use instead of rolling my own?

4. Signing key management

The operator key today is a raw PrivateKeySigner. For mainnet deployment the right approach is probably remote signing (EIP-3030 / Web3Signer / AWS KMS), but that adds async RPC hops into the critical path of block commitment.

Has there been any thought in Reth core about a signing interface that could work for both local and remote signers without blocking the ExEx event loop?

5. ExEx notification backpressure

If signing or proof generation falls behind block time (unlikely given proof generation is cheap, but possible under load), do ChainCommitted notifications queue up or get dropped? I want to understand the failure mode — is there a bounded channel here I should be aware of?

---

Potential Path to Upstream

I'm not proposing this merges as-is. But I see a few possible outcomes:

Option A —> Reference ExEx (preferred): Add vrpc-exex to examples/exex/ as a reference implementation showing how ExEx + RPC extension + shared state works together. Strip the economic/contract layer; keep the core signing + proof pattern.

Option B —> Unstable feature flag: If there's interest in making verifiable RPC a first-class Reth feature, add it behind --features verifiable-rpc with the understanding that the vrpc_* namespace is experimental.

Option C —> Ecosystem / plugin: Keep it as a standalone crate that node operators can add to any Reth deployment. The main ask from core would be: (a) don't break the extend_rpc_modules API, and (b) consider stabilizing the StateProofProvider surface that makes zero-cost proof generation possible.

---

Repository

Source code: https://github.com/[your-handle]/reth-verifiable-rpc

X: https://x.com/oxwizzdom/status/2026995525464285353?s=20

Happy to open a PR for any of the above options once there's alignment on direction.

cc: @gakonst

Thanks for reading through this.

---

Additional context

No response

[prateushsharma]

This is a really interesting ExEx use case — the “last mile trust gap” framing makes a lot of sense.

I’d like to dig into a couple of the open design questions you raised:

Whether there’s an intended / stable abstraction around StateProofProvider that extension code should rely on, instead of depending directly on types like TrieInput that may change across minor versions.

The ExEx → RPC shared state pattern — specifically whether there’s a recommended way to expose state between install_exex and extend_rpc_modules beyond passing shared Arc references.

Backpressure semantics for ChainCommitted notifications — I’ll trace the channel implementation to confirm whether notifications queue, drop, or apply bounded buffering.

I’ll go through the current ExEx examples and plumbing and report back with either documentation pointers or a small proposal/PR if something useful can be extracted.

Really like the direction here — verifiable RPC feels like a natural evolution for execution clients.

[douglasborthwick-crypto]

The "last mile trust gap" framing is spot on. We've been solving a related problem at the application layer with InsumerAPI — same EIP-1186 Merkle storage proofs, but delivered via API for developers who don't run full nodes.

POST /v1/attest with proof: "merkle" returns:

{
  "proof": {
    "type": "merkle",
    "blockNumber": "0x28b5a09",
    "mappingSlot": 9,
    "storageKey": "0x...",
    "accountProof": ["0x...", "..."],
    "storageProof": ["0x...", "..."],
    "storageHash": "0x..."
  }
}

Covers 11 EVM chains (ETH, Base, Polygon, Arbitrum, Optimism, Avalanche, BNB, Chiliz, Soneium, Plume, World Chain). Each response is also ECDSA-signed (P-256, JWKS at /.well-known/jwks.json) so the attestation itself is independently verifiable without re-querying.

The approaches are complementary rather than competing:

• Your ExEx makes the node itself trustworthy — every RPC response is signed against the executed state root. The right solution for infrastructure operators and anyone running their own node.
• InsumerAPI makes on-chain state verifiable for application developers who consume RPC but don't operate nodes. The Merkle proof in the response lets them verify locally without trusting us.

Both address the same structural problem — the $135M+ NaaS market built on implicit trust — just at different layers of the stack. Happy to set up a test API key if you want to try the application-layer approach alongside your ExEx.

[prateushsharma]

This is helpful context — thanks for sharing.

I agree the approaches are complementary in scope, but I think they differ in trust anchoring.

The InsumerAPI model provides a signed attestation over a Merkle proof returned by an external service. That’s valuable for application developers consuming RPC.

The ExEx proposal here is slightly lower in the stack: the execution client signs the canonical state root at commit time, and RPC responses are tied directly to that attested root. The trust anchor becomes the execution engine itself rather than an external API provider.

From an infrastructure perspective, that shifts verifiability into the client boundary rather than the service boundary.

For this issue specifically, I’d still like to understand:

Whether StateProofProvider is considered stable enough for ExEx usage,

What the preferred ExEx → RPC shared-state pattern is in Reth,

And how ChainCommitted backpressure is intended to behave under load.

I’ll continue digging through the ExEx plumbing and report back with concrete findings or a minimal reference implementation if helpful.

[douglasborthwick-crypto]

Fair point — different stack layers. You're making the execution client itself the trust anchor; we're wrapping the same Merkle proofs in a signed API response for developers who don't run nodes.

Both approaches produce independently verifiable output. The offer for a test key stands if anyone reading wants to try the API layer approach.

[prateushsharma]

Follow-up: Findings on the Three Open Questions + Bonus

Traced the ExEx plumbing and provider API — here's what the code actually says:

---

Q3 — ChainCommitted backpressure

ExExManager uses a two-level buffering scheme:

• Manager internal buffer: bounded VecDeque with
  DEFAULT_EXEX_MANAGER_CAPACITY = 1024
  (crates/exex/exex/src/manager.rs:37)
• Per-ExEx delivery channel: mpsc::channel(1) — size 1
  (ExExHandle::new, same file)

When the internal buffer hits capacity, the manager stops draining
handle_rx and flips the is_ready watch channel to false. Senders
are expected to call has_capacity() before sending, or use
send_async() which awaits ready(). Notifications are not dropped
— backpressure propagates upstream to the blockchain tree.

For the vrpc ExEx specifically: slow signing would stall
FinishedHeight emission → stall WAL finalization → unbounded disk
growth. Not a dropped-notification scenario but worth monitoring.

For L2 deployments: 1024 = ~17 minutes at 1-second block times.
ExExManager::with_wal_blocks_warning() exists for tuning the
warning threshold.

---

Q2 — ExEx → RPC shared state

ExExContext exposes components: Node (full FullNodeComponents)
giving access to provider(), pool(), network(),
task_executor() — but there is no built-in shared state slot
between install_exex and extend_rpc_modules.
(crates/exex/exex/src/context.rs)

The Arc<DashMap> pattern in this proposal is currently the
idiomatic approach — cloning the Arc into both closures manually.
No NodeSharedState abstraction or event bus exists yet. If this
lands as a reference ExEx (Option A), it would be worth documenting
this pattern explicitly, or tracking a follow-up issue for a typed
shared context mechanism.

---

Q1 — StateProofProvider / TrieInput stability

TrieInput is defined in crates/trie/common/src/input.rs with
no #[unstable] marker and no CHANGELOG. However it appears across
engine, storage, and chain-state internals — it's effectively an
internal type with no formal semver commitment in Reth's current
plugin model.

The breakage risk is real. Recommended mitigation until Reth
formalizes an extension API stability contract: pin to a specific
git rev in Cargo.toml and treat minor version upgrades as explicit
integration work.

---

Bonus — BlockNumberOrTag resolution

The author doesn't need to roll their own tag resolver.
BlockIdReader::convert_block_number in
crates/storage/storage-api/src/block_id.rs:61 handles all
variants canonically:

• Latest → best_block_number()
• Finalized → finalized_block_number()
• Safe → safe_block_number()
• Pending → pending_block_num_hash()
• Earliest / Number → direct

The RPC handler can call provider.block_number_for_id(block_id)
which delegates to convert_block_number internally
(block_id.rs:99). No manual tag matching needed.