Context
Clients don't always start from genesis. Checkpoint sync lets a node start from a recent finalized state and block. The fork choice store is initialized via `Store.from_anchor(anchor_state, anchor_block)`, where the anchor can be any valid (state, block) pair — not just genesis.
When initializing from a non-genesis anchor:
- The store's justified and finalized checkpoints come from the anchor state
- The head starts at the anchor block
- The store's block and state maps contain only the anchor
- All subsequent blocks build on this anchor
No spec test filler currently tests non-genesis store initialization.
What to test
Write a fork choice filler that:
- First, builds a chain from genesis to slot 10 (to create a valid mid-chain state)
- Uses the state and block at slot 10 as the anchor for a new store
- Builds additional blocks on top of the anchor (slots 11, 12, 13)
- Verifies the store behaves correctly with the non-genesis anchor
Alternative simpler approach
If the fork choice filler framework supports custom anchor states:
- Generate a pre-state at a non-zero slot
- Initialize the store from that state
- Build blocks on top
- Verify head, justified, and finalized checkpoints reference the anchor
Key assertions
- `StoreChecks(head_slot=Slot(10))` — initial head is at the anchor
- Justified/finalized checkpoints match the anchor state's checkpoints
- Blocks at slots 11+ are processed correctly on top of the anchor
- Head advances to the new blocks
Where to add the test
Create a new file: `tests/consensus/devnet/fc/test_checkpoint_sync.py`
Code skeleton
"""Checkpoint sync (non-genesis anchor) tests."""
from consensus_testing import (
BlockSpec,
BlockStep,
ForkChoiceTestFiller,
StoreChecks,
)
from lean_spec.subspecs.containers.slot import Slot
def test_store_from_non_genesis_anchor(
fork_choice_test: ForkChoiceTestFiller,
) -> None:
"""Store initializes correctly from a non-genesis anchor block and state."""
# TODO: Check if fork_choice_test supports a custom anchor_state parameter.
# If not, this test may need framework support to be added first.
#
# Alternative: build a long chain first, then use the filler's ability
# to verify store state at intermediate points.
pass
Note: This test may require framework support for custom anchor states. Check `ForkChoiceTest.make_fixture` in `packages/testing/src/consensus_testing/test_fixtures/fork_choice.py` to see if a custom anchor is supported. If not, consider opening a companion framework issue.
How to run
uv run fill --fork=devnet --clean -n auto -k test_store_from_non_genesis
References
- `Store.from_anchor`: `src/lean_spec/subspecs/forkchoice/store.py`
- Checkpoint sync concept: the anchor block's `state_root` must match `hash_tree_root(anchor_state)`
Context
Clients don't always start from genesis. Checkpoint sync lets a node start from a recent finalized state and block. The fork choice store is initialized via `Store.from_anchor(anchor_state, anchor_block)`, where the anchor can be any valid (state, block) pair — not just genesis.
When initializing from a non-genesis anchor:
No spec test filler currently tests non-genesis store initialization.
What to test
Write a fork choice filler that:
Alternative simpler approach
If the fork choice filler framework supports custom anchor states:
Key assertions
Where to add the test
Create a new file: `tests/consensus/devnet/fc/test_checkpoint_sync.py`
Code skeleton
How to run
References