Weak-Subjectivity Checkpoint Execution Proof Sync
When joining the network a node must validate execution payloads from weak-subjectivity checkpoint to head:
| Sync policy |
Proof bytes over one WS window |
| 1 proof per payload |
~26.9 GiB |
| 2 proofs per payload |
~53.9 GiB |
| 4 proofs per payload |
~107.8 GiB |
Assuming the Electra WS reference period of 3,532 epochs, 32 slots per epoch, 113,024 slots, and 250 KiB per execution proof.
- Naive sync scales linearly with both the weak-subjectivity window length and the proof policy.
- Recursive direction — add a
RecursiveExecutionProof layer above base ExecutionProof.
- Chain-prefix authentication — use a Merkle tree or MMR over proven beacon roots to authenticate that a block is part of the proven chain prefix.
- Network simplification — a single proof for the chain tip can authenticate the full prefix, including the checkpoint-to-tip range, removing most requirements for historical execution-proof req/resp.
- Next steps — spec the chain-prefix / checkpoint-membership scheme, then implement the proof-sync path.