gnosis/lighthouse
1
0
Fork 0
mirror of https://github.com/sigp/lighthouse.git synced 2026-04-20 14:28:37 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'unstable' into merge-unstable-to-deneb-20230822

Browse Source 
# Conflicts:
#	beacon_node/beacon_chain/src/builder.rs
#	beacon_node/beacon_chain/tests/store_tests.rs
#	beacon_node/client/src/builder.rs
#	beacon_node/src/config.rs
#	beacon_node/store/src/hot_cold_store.rs
#	lighthouse/tests/beacon_node.rs
This commit is contained in:
Jimmy Chen
2023-08-22 21:20:47 +10:00
parent 49d7fdfed1 f92b856cd1
commit 8a6f171b2a
41 changed files with 729 additions and 375 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/

2
book/src/setup.md
View File

@@ -9,7 +9,7 @@ particularly useful for development but still a good way to ensure you have the
base dependencies.
The additional requirements for developers are:
- [`anvil`](https://github.com/foundry-rs/foundry/tree/master/anvil). This is used to
- [`anvil`](https://github.com/foundry-rs/foundry/tree/master/crates/anvil). This is used to
simulate the execution chain during tests. You'll get failures during tests if you
don't have `anvil` available on your `PATH`.
- [`cmake`](https://cmake.org/cmake/help/latest/command/install.html). Used by