Ethereum finality, proven and priced.
ConnectingA zero-knowledge proof that a checkpoint was finalised by two thirds of the full validator set — not the 512 of the sync committee. Every epoch this prover closes lands below as it closes, with the time it took, what it cost and the proof itself.
Reading the proof feed…
- —
- Epochs proven
- —
- Median T2 − T
- —
- Median cost per epoch
- —
- Proof size
The epoch in flight
- —
- Stake attested
- —
- Finalised by zkasper
Where the prover time goes
T2 − T, epoch by epoch
Every epoch
T2 − T is the only latency a consumer waits on: from the moment two thirds of the stake has attested to the moment a postable proof of it exists. Everything else happens before that. Open a row for every stage it ran and the material to check the proof yourself.
The feed lists no proven epochs yet.
Verified on another chain
Each of these is a zkasper finalisation proof checked by a program on another chain, which is what the proof is for. The numbers are the submitter’s reading of the transaction receipt, forwarded unchanged.
Why not the sync committee512 validators, and nothing at stake
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.
| 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.
The pipelineStages, 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.
-
Epoch diff
Carry the accumulator forward one epoch, tracking exact effective balances.
-
Committee
Fix the epoch’s 32 slot committees from the RANDAO mix of two epochs back.
-
Slot proof
Check one slot’s attestations in a single multi-pairing.
-
Justification
Fold an epoch’s work. Check the two-thirds threshold.
-
Finalisation
Pair two justifications. That is Casper FFG finality.
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. Roughly a quarter of the epoch is never proven at all, because the threshold arrives first. The rail on the right is that happening, and the chart above is where the time actually went. Target: Zisk.
Measured, not estimatedCircuit numbers, on real mainnet data
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. Every latency and price on this page is the running prover’s own measurement, not these.
Built
- Five circuits, epoch diff 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
Verify it yourselfNothing here has to be taken on trust
- Open any epoch above and read its
verifyblock. - Fetch the proof words from
/v1/proofs/<epoch>. - Build the guest at that commit with that Zisk version; its verification key must equal
program_vk. zkasper_common::recursion::verify_child(&words, &program_vk, &public_bytes).- Ask any beacon node whether the proven root really is the checkpoint of that epoch.
- Recompute the accumulator chain digest from the epoch list and compare it with
/v1/status.
Steps 1 to 5 need nothing from zkasper but the bytes the API serves. Step 6 is what makes a series of proofs a chain rather than a pile.