9667dc2f03
## Issue Addressed Closes #1891 Closes #1784 ## Proposed Changes Implement checkpoint sync for Lighthouse, enabling it to start from a weak subjectivity checkpoint. ## Additional Info - [x] Return unavailable status for out-of-range blocks requested by peers (#2561) - [x] Implement sync daemon for fetching historical blocks (#2561) - [x] Verify chain hashes (either in `historical_blocks.rs` or the calling module) - [x] Consistency check for initial block + state - [x] Fetch the initial state and block from a beacon node HTTP endpoint - [x] Don't crash fetching beacon states by slot from the API - [x] Background service for state reconstruction, triggered by CLI flag or API call. Considered out of scope for this PR: - Drop the requirement to provide the `--checkpoint-block` (this would require some pretty heavy refactoring of block verification) Co-authored-by: Diva M <divma@protonmail.com>
3.5 KiB
Database Configuration
Lighthouse uses an efficient "split" database schema, whereby finalized states are stored separately from recent, unfinalized states. We refer to the portion of the database storing finalized states as the freezer or cold DB, and the portion storing recent states as the hot DB.
In both the hot and cold DBs, full BeaconState data structures are only stored periodically, and
intermediate states are reconstructed by quickly replaying blocks on top of the nearest state. For
example, to fetch a state at slot 7 the database might fetch a full state from slot 0, and replay
blocks from slots 1-7 while omitting redundant signature checks and Merkle root calculations. The
full states upon which blocks are replayed are referred to as restore points in the case of the
freezer DB, and epoch boundary states in the case of the hot DB.
The frequency at which the hot database stores full BeaconStates is fixed to one-state-per-epoch
in order to keep loads of recent states performant. For the freezer DB, the frequency is
configurable via the --slots-per-restore-point CLI flag, which is the topic of the next section.
Freezer DB Space-time Trade-offs
Frequent restore points use more disk space but accelerate the loading of historical states. Conversely, infrequent restore points use much less space, but cause the loading of historical states to slow down dramatically. A lower slots per restore point value (SPRP) corresponds to more frequent restore points, while a higher SPRP corresponds to less frequent. The table below shows some example values.
| Use Case | SPRP | Yearly Disk Usage | Load Historical State |
|---|---|---|---|
| Block explorer/analysis | 32 | 1.4 TB | 155 ms |
| Default | 2048 | 23.1 GB | 10.2 s |
| Validator only | 8192 | 5.7 GB | 41 s |
As you can see, it's a high-stakes trade-off! The relationships to disk usage and historical state load time are both linear – doubling SPRP halves disk usage and doubles load time. The minimum SPRP is 32, and the maximum is 8192.
The values shown in the table are approximate, calculated using a simple heuristic: each
BeaconState consumes around 18MB of disk space, and each block replayed takes around 5ms. The
Yearly Disk Usage column shows the approx size of the freezer DB alone (hot DB not included),
and the Load Historical State time is the worst-case load time for a state in the last slot of
an epoch.
To configure your Lighthouse node's database with a non-default SPRP, run your Beacon Node with
the --slots-per-restore-point flag:
lighthouse beacon_node --slots-per-restore-point 8192
Glossary
- Freezer DB: part of the database storing finalized states. States are stored in a sparser format, and usually less frequently than in the hot DB.
- Cold DB: see Freezer DB.
- Hot DB: part of the database storing recent states, all blocks, and other runtime data. Full states are stored every epoch.
- Restore Point: a full
BeaconStatestored periodically in the freezer DB. - Slots Per Restore Point (SPRP): the number of slots between restore points in the freezer DB.
- Split Slot: the slot at which states are divided between the hot and the cold DBs. All states from slots less than the split slot are in the freezer, while all states with slots greater than or equal to the split slot are in the hot DB.