gnosis/lighthouse
1
0
Fork 0
mirror of https://github.com/sigp/lighthouse.git synced 2026-05-07 08:52:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

Remove checkpoint alignment requirements and enable historic state pruning (#4610)

Browse Source 
## Issue Addressed

Closes #3210
Closes #3211

## Proposed Changes

- Checkpoint sync from the latest finalized state regardless of its alignment.
- Add the `block_root` to the database's split point. This is _only_ added to the in-memory split in order to avoid a schema migration. See `load_split`.
- Add a new method to the DB called `get_advanced_state`, which looks up a state _by block root_, with a `state_root` as fallback. Using this method prevents accidental accesses of the split's unadvanced state, which does not exist in the hot DB and is not guaranteed to exist in the freezer DB at all. Previously Lighthouse would look up this state _from the freezer DB_, even if it was required for block/attestation processing, which was suboptimal.
- Replace several state look-ups in block and attestation processing with `get_advanced_state` so that they can't hit the split block's unadvanced state.
- Do not store any states in the freezer database by default. All states will be deleted upon being evicted from the hot database unless `--reconstruct-historic-states` is set. The anchor info which was previously used for checkpoint sync is used to implement this, including when syncing from genesis.

## Additional Info

Needs further testing. I want to stress-test the pruned database under Hydra.

The `get_advanced_state` method is intended to become more relevant over time: `tree-states` includes an identically named method that returns advanced states from its in-memory cache.

Co-authored-by: realbigsean <seananderson33@gmail.com>
This commit is contained in:
Michael Sproul
2023-08-21 05:02:32 +00:00
parent 687c58fde0
commit 20067b9465
25 changed files with 633 additions and 301 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
book/src/checkpoint-sync.md
View File

@@ -75,7 +75,7 @@ Once backfill is complete, a `INFO Historical block download complete` log will
> Note: Since [v4.1.0](https://github.com/sigp/lighthouse/releases/tag/v4.1.0), Lighthouse implements rate-limited backfilling to mitigate validator performance issues after a recent checkpoint sync. This means that the speed at which historical blocks are downloaded is limited, typically to less than 20 slots/sec. This will not affect validator performance. However, if you would still prefer to sync the chain as fast as possible, you can add the flag `--disable-backfill-rate-limiting` to the beacon node.
> Note: Since [v4.2.0](https://github.com/sigp/lighthouse/releases/tag/v4.2.0), Lighthouse limits the backfill sync to only sync backwards to the weak subjectivity point (approximately 5 months). This will help to save disk space. However, if you would like to sync back to the genesis, you can add the flag `--genesis-backfill` to the beacon node.
> Note: Since [v4.2.0](https://github.com/sigp/lighthouse/releases/tag/v4.2.0), Lighthouse limits the backfill sync to only sync backwards to the weak subjectivity point (approximately 5 months). This will help to save disk space. However, if you would like to sync back to the genesis, you can add the flag `--genesis-backfill` to the beacon node.
## FAQ
@@ -116,8 +116,9 @@ states:
database. Additionally, the genesis block is always available.
* `state_lower_limit`: All states with slots _less than or equal to_ this value are available in
the database. The minimum value is 0, indicating that the genesis state is always available.
* `state_upper_limit`: All states with slots _greater than or equal to_ this value are available
in the database.
* `state_upper_limit`: All states with slots _greater than or equal to_ `min(split.slot,
state_upper_limit)` are available in the database. In the case where the `state_upper_limit` is
higher than the `split.slot`, this means states are not being written to the freezer database.
Reconstruction runs from the state lower limit to the upper limit, narrowing the window of
unavailable states as it goes. It will log messages like the following to show its progress:
@@ -153,18 +154,8 @@ To manually specify a checkpoint use the following two flags:
* `--checkpoint-state`: accepts an SSZ-encoded `BeaconState` blob
* `--checkpoint-block`: accepts an SSZ-encoded `SignedBeaconBlock` blob
_Both_ the state and block must be provided and **must** adhere to the [Alignment
Requirements](#alignment-requirements) described below.
### Alignment Requirements
* The block must be a finalized block from an epoch boundary, i.e. `block.slot() % 32 == 0`.
* The state must be the state corresponding to `block` with `state.slot() == block.slot()`
and `state.hash_tree_root() == block.state_root()`.
These requirements are imposed to align with Lighthouse's database schema, and notably exclude
finalized blocks from skipped slots. You can avoid alignment issues by using
[Automatic Checkpoint Sync](#automatic-checkpoint-sync), which will search for a suitable block
and state pair.
_Both_ the state and block must be provided and the state **must** match the block. The
state may be from the same slot as the block (unadvanced), or advanced to an epoch boundary,
in which case it will be assumed to be finalized at that epoch.
[weak-subj]: https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/