d839b9d07e
Currently, we require genesis and a checkpoint block and state to start from an arbitrary slot - this PR relaxes this requirement so that we can start with a state alone. The current trusted-node-sync algorithm works by first downloading blocks until we find an epoch aligned non-empty slot, then downloads the state via slot. However, current [proposals](https://github.com/ethereum/beacon-APIs/pull/226) for checkpointing prefer finalized state as the main reference - this allows more simple access control and caching on the server side - in particular, this should help checkpoint-syncing from sources that have a fast `finalized` state download (like infura and teku) but are slow when accessing state via slot. Earlier versions of Nimbus will not be able to read databases created without a checkpoint block and genesis. In most cases, backfilling makes the database compatible except where genesis is also missing (custom networks). * backfill checkpoint block from libp2p instead of checkpoint source, when doing trusted node sync * allow starting the client without genesis / checkpoint block * perform epoch start slot lookahead when loading tail state, so as to deal with the case where the epoch start slot does not have a block * replace `--blockId` with `--state-id` in TNS command line * when replaying, also look at the parent of the last-known-block (even if we don't have the parent block data, we can still replay from a "parent" state) - in particular, this clears the way for implementing state pruning * deprecate `--finalized-checkpoint-block` option (no longer needed) |
||
|---|---|---|
| .. | ||
| altair | ||
| bellatrix | ||
| capella | ||
| phase0 | ||
| README.md | ||
| all_tests.nim | ||
| consensus_spec_tests_preset.nim | ||
| fixtures_utils.nim | ||
| test_fixture_fork_choice.nim | ||
| test_fixture_light_client_single_merkle_proof.nim | ||
| test_fixture_light_client_sync.nim | ||
| test_fixture_light_client_update_ranking.nim | ||
| test_fixture_ssz_generic_types.nim | ||
README.md
Tests based on scenarios generated from the consensus spec.