Epoch Stake Root Sysvar

[Atamanov]

Idea: Epoch Stake Root (ESR) Sysvar

We propose introducing a new system variable, Epoch Stake Root (ESR).
This sysvar would store a Merkle root commitment to the validator set and stake distribution of the next epoch.

---

Motivation

The primary goal is to support light clients with a secure and efficient way to track validator set transitions.

Today, light clients face a fundamental challenge when crossing epoch boundaries:

• To determine the validator set for Epoch N+1, a client must:
  • Observe thousands of stake accounts during Epoch N.
  • Re-implement Solana’s runtime logic for stake warm-up and cooldown.
• This creates a large data and compute requirement, which undermines the viability of lightweight clients on mainnet.

The ESR solves this by collapsing all that complexity into a single, 32-byte on-chain commitment.

---

How It Works

1. Runtime calculation

   • At every epoch transition, the runtime already computes the finalized validator set and stake weights for the upcoming epoch.
   • This data exists in memory as part of the transition process.

2. Merkleization

   • A Merkle tree is constructed over the (validator_pubkey, stake) pairs.
   • The root is committed to the ESR sysvar.

3. Verification flow

   • A light client downloads the full validator list from any source (RPC, gossip, etc.).
   • It hashes the data locally and checks it against the ESR root.
   • The root itself is signed off by the current epoch’s validator set, ensuring continuity of trust from N → N+1.

---

Properties

• Data Availability

  • No additional lookups are required.
  • We are only hashing state that is already finalized at each epoch boundary.

• Frequency

  • This process occurs once per epoch (~2 days).
  • It does not introduce per-block or per-slot overhead.

• Performance

  • Merkleizing a few thousand entries is computationally cheap.
  • With parallelized implementations, the cost is negligible relative to the overall epoch transition workload.

---

Benefits

• Trust-minimized light clients

  • Enables clients to transition trust across epochs without relying on a centralized RPC or duplicating runtime logic.

• Compact verification

  • A single on-chain root replaces thousands of stake account lookups.

• Ecosystem impact

  • Low overhead for the runtime, high value for client developers.
  • Strengthens Solana’s ability to support lightweight, decentralized clients on constrained devices.

[buffalojoec]

I'm conceptually in favor of this idea. I'd like someone who has been thinking about the future of the epoch stakes cache and the implementation of the finalized epoch stake state mentioned in the post to weigh in. It would also be great for any Alpenglow folks to weigh in as well.

From my understanding, it seems like the validator set growth is expected to slow with the activation of Alpenglow, so that would help protect the Merkle tree implementation a bit from getting too slow. It's also probably good to include a minimum stake requirement for inclusion in the root, if this isn't already going to be part of Alpenglow.

I'm curious about the light client implementation, though. Is the idea to build some kind of relayer that runs on the validators, or can subscribe to account updates for changes in stake, and then serve validator stake for proof generation?

[Tamgros]

Similar question as Joe. It'd be good to know how this is positioned to be used in the actual light client. It's unclear to me how (validator, stake) leads to tx inclusion verification. Is the light client relying on some subset of the validator set as guardians and this sysvar assures their trustwrothiness?

Have you done any benchmarks on the perf impact? I know Alessandro and a few others have been tackling the slot rollover inefficiencies.

[Atamanov]

@buffalojoec Minimal stake makes a lot of sense to me.
@Tamgros , the way we’ve been approaching this in Twine is by building a consensus prover for Solana that already runs on both SP1 and Risc0 zkVMs on both the Mainnet and Devnet. It relies on an extended geyser interface to stream the data needed for the prover. The prover establishes trust by starting from a known checkpoint (which in practice would be an ESR commitment), and then proving continuous chain progress from that point forward.

We collect a chain of bank hashes and its components from the previous proof (or first checkpoint) and than the prover enforces constraints like:

1. Chain continuity: slots are strictly consecutive and each parent_bank_hash equals the previous slot's bank_hash.
2. Bank hash correctness: bank_hash = hash(hash(parent_bank_hash, signature_count, last_blockhash), cumulative_lthash).
3. LtHash transformation: final slot cumulative LtHash equals previous cumulative LtHash with changed account LtHashes mixed out/in.
4. LtHash checksum: final slot accounts_lthash_checksum equals checksum(cumulative LtHash).
5. ESR inclusion: every vote's vote account is proven via provided Merkle proof to be in the ESR root.
6. Vote validity: each vote is signed by required signers and votes for the final slot and its bank_hash (via pre-parsed fields).
7. Supermajority: unique validators of valid votes represent >= 2/3 of total active stake for the epoch.

One important clarification: the current prover doesn’t provide transaction inclusion proofs. It only verifies account state when changes occur. That’s usually sufficient for our need because state changes can be trivially induced (e.g. by sending 1 lamport to a monitored account), but it doesn’t extend to proving arbitrary tx inclusion at this stage.

So the ESR’s role here is pretty straightforward: it defines the validator set and stakes that the prover must check votes against. Once that’s locked in at the epoch boundary, the prover can verify continuity and supermajority stake without replaying stake-account logic.

The main value of ESR in this context is giving light clients and zk proofs a compact, verifiable foundation for validator set continuity between epochs — which is otherwise the biggest bottleneck in keeping these systems trust-minimized.

Currently to calculate ESR we have to either trust the RPC or monitor thousands (if not millions as of recently jaja) of accounts (for the mainnet). Sysvar described would make a lot of difference for us and those who'll follow.

If generally supported, I'll come up with an implementation along with the benchmarks. I believe nodes would be just fine creating the root each couple days. Would love to hear from the Alpenglow folks as well though.