Ethereum’s security,
everywhere.
Proof that an Ethereum checkpoint was finalised by two thirds of the full validator set. Any chain that verifies a SNARK reads Ethereum state with Ethereum’s own security.
The problem
Every Ethereum light client shipping today trusts the same 512 validators.
Helios, SP1 Helios and Telepathy all verify the Altair sync committee: 512 validators, resampled every 27 hours. The lit dot is all of them, to scale.
Sample size is not the problem. Sync committee messages are not slashable. Altair defines no slashing condition for them. A corrupted committee can sign a header for a chain that does not exist and lose nothing.
A million BLS signatures per epoch was out of reach in 2021. That has changed.
The difference
What the proof is actually backed by.
| Property | Sync committee light clients | zkasper |
|---|---|---|
| Signers | Sync committee512, rotating ~27h | zkasperFull validator set |
| Slashable | Sync committeeNo | zkasperYes |
| Security backing | Sync committeeHonest-majority assumption on a small sample | zkasper~1/3 of total stake at risk |
Forging the proof is an economic problem, not a cryptographic one. It costs a third of all staked ETH, slashed. That is the collateral securing Ethereum itself.
How it works
Five stages, folded into one proof.
The beacon chain stores validators in an SSZ tree, 40 levels deep, hashed with SHA-256. zkasper keeps a parallel accumulator: 22 levels, Poseidon2 over Goldilocks.
-
Bootstrap
Build the accumulator from a trusted beacon state.
-
Epoch diff
Carry it forward one epoch, tracking exact effective balances.
-
Slot proof
Check one slot’s attestations in a single multi-pairing.
-
Justification
Fold an epoch’s slot proofs. Check the two-thirds threshold.
-
Finalisation
Pair two justifications. That is Casper FFG finality.
Slot proofs run in parallel as attestations arrive. Target: Zisk.
Live
Watch an epoch get proven.
An epoch is not proven in one batch. Group proofs cover ranges of attestation slots and run as those slots arrive; each fold extends a running aggregate. At T — the moment two thirds of the stake has attested — one final proof absorbs whatever arrived too late to fold, proves the crossing slot inline, and emits the finalisation. Everything else already happened. T2 − T is the only latency a consumer waits on, and roughly a quarter of the epoch is never proven at all, because the threshold arrives first.
Reading the proof feed…
attestations held T, threshold crossed never proven not yet attested
- —
- T2 − T, measured
- —
- Stake attested
- —
- Finalised by zkasper
Stages, as they land
No stage has run since the feed came up.
Proven epochs
The feed lists no proven epochs yet.
Read from the prover’s own feed. Nothing here is simulated: when the daemon is not proving, this section says so and shows no numbers. The schedule models 5.5 s for T2 − T; the figure above is measured, or absent.
Engineering
Measured, not estimated.
Measured on real mainnet data: 960,974 active validators, 99.7% attesting balance.
- 4.85×
- Accumulator node vs SSZ node Poseidon2 at 7,462 cost units against SHA-256 at 36,207 — and 22 levels instead of 40.
- 19.9×
- Public key aggregation Driving the raw curve-add precompile at 2,730, against 54,241 through the safe wrapper.
- 167×
- Accumulator work per slot A slot proof opens the validators that did not attest, not the ones that did.
- 4.5s
- One slot, proven Measured on an RTX 5090, warm prover, Zisk v1.1.0-alpha.
- 123
- Tests passing Verified against real mainnet state.
Cost units are Zisk trace area, hardware-independent. End-to-end proving latency is still being measured and is not quoted here.
Built
- Five circuits, bootstrap to finalisation
- Poseidon2-Goldilocks accumulator
- One multi-pairing per slot
- Recursive composition, outputs bound
- Witness generator on live beacon data
- Streaming pipeline to the finality threshold
Shipping next
- EVM and Solana verifiers
- Continuous mainnet proving
- Light client integration