Skip to content

Conversation

@Atamanov
Copy link

@Atamanov Atamanov commented Nov 4, 2025

Introduce a new sysvar, Epoch Stake Root (ESR), that calculates a Merkle root commitment to the finalized validator set and effective stake distribution for the next epoch (N+1) and makes it available on-chain. The ESR is written exactly once per epoch at the epoch boundary when the runtime finalizes the upcoming epoch’s effective stakes. The sysvar also includes a minimum inclusion threshold and dual stake totals to support percentage calculations.

@Atamanov Atamanov marked this pull request as draft November 4, 2025 14:45
Introduce a new sysvar, Epoch Stake Root (ESR), that calculates a Merkle root commitment to the finalized validator set and effective stake distribution for the next epoch (N+1) and makes it available on-chain. The ESR is written exactly once per epoch at the epoch boundary when the runtime finalizes the upcoming epoch’s effective stakes. The sysvar also includes a minimum inclusion threshold and dual stake totals to support percentage calculations.
@Atamanov Atamanov force-pushed the 0360-epoch-state-root branch from 650a78b to a192213 Compare November 4, 2025 14:49
@Atamanov Atamanov marked this pull request as ready for review November 4, 2025 14:49
@deanmlittle deanmlittle changed the title SIMD-0360: Epoch Stake Root (ESR) Sysvar SIMD-0400: Epoch Stake Root (ESR) Sysvar Nov 14, 2025
@deanmlittle
Copy link
Contributor

Awesome. I proposed something similar to a few people recently. This would certainly improve the SIMD voting process, amongst a few other things.

Changes after the discussion with @deanmlittle
@Atamanov
Copy link
Author

Fixed @deanmlittle

Copy link
Contributor

@t-nelson t-nelson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we're proposing that the validator do non-protocol work, under consensus, at the most compute-contended time, to support support light-clients, which have been fundamentally broken by switching the state commitment to lattice hash?

@Atamanov
Copy link
Author

Thanks for the review. A few points:

1. ESR is protocol work

Verifying consensus requires knowing the validator set. Validators use epoch_stakes to verify vote signatures and weight fork choice. ESR commits to this same data, enabling external verification of consensus itself.

The runtime is the only place this can be done correctly. External processes would need to re-implement stake warmup/cooldown, activation rate limits, and match exactly what the leader schedule uses. Any divergence = security vulnerability.

2. The data already exists—ESR just commits to it

EpochStakes is already computed at epoch boundaries for leader schedule. ESR hashes this already-in-memory (vote_pubkey, stake) map: ~3-9ms of SHA-256 on ~1-3k entries, once every ~2 days.

3. LT-Hash compatibility

ESR and lattice hash are orthogonal:

  • LT-Hash: account state commitment
  • ESR: validator set commitment (needed to verify vote signatures regardless of state commitment scheme)

We have a fully working light-client implementation on mainnet using an Agave fork that computes validator set proofs off-chain. ESR provides the minimal on-chain commitment to the validation set which could be used as the root of trust.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants