gnosis/lighthouse
1
0
Fork 0
mirror of https://github.com/sigp/lighthouse.git synced 2026-04-26 09:13:41 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'unstable' into validator-manager

Browse Source
This commit is contained in:
Paul Hauner
2023-02-14 14:41:41 +11:00
parent 8ca7f321e3 fa1d4c7054
commit d278bab54f
162 changed files with 6028 additions and 2235 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -48,17 +48,6 @@ The Ethereum community provides various [public endpoints](https://eth-clients.g
lighthouse bn --checkpoint-sync-url https://example.com/ ...
```
### Use Infura as a remote beacon node provider
You can use Infura as the remote beacon node provider to load the initial checkpoint state.
1. Sign up for the free Infura ETH2 API using the `Create new project tab` on the [Infura dashboard](https://infura.io/dashboard).
2. Copy the HTTPS endpoint for the required network (Mainnet/Prater).
3. Use it as the url for the `--checkpoint-sync-url` flag. e.g.
```
lighthouse bn --checkpoint-sync-url https://<PROJECT-ID>:<PROJECT-SECRET>@eth2-beacon-mainnet.infura.io ...
```
## Backfilling Blocks
Once forwards sync completes, Lighthouse will commence a "backfill sync" to download the blocks
@@ -108,7 +97,7 @@ You can opt-in to reconstructing all of the historic states by providing the
The database keeps track of three markers to determine the availability of historic blocks and
states:
* `oldest_block_slot`: All blocks with slots less than or equal to this value are available in the
* `oldest_block_slot`: All blocks with slots greater than or equal to this value are available in the
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.

8
book/src/docker.md
View File

@@ -57,7 +57,7 @@ $ docker pull sigp/lighthouse:latest-modern
Image tags follow this format:
```
${version}${arch}${stability}${modernity}
${version}${arch}${stability}${modernity}${features}
```
The `version` is:
@@ -81,6 +81,12 @@ The `modernity` is:
* `-modern` for optimized builds
* empty for a `portable` unoptimized build
The `features` is:
* `-dev` for a development build with `minimal-spec` preset enabled.
* empty for a standard build with no custom feature enabled.
Examples:
* `latest-unstable-modern`: most recent `unstable` build for all modern CPUs (x86_64 or ARM)

7
book/src/installation-source.md
View File

@@ -64,6 +64,7 @@ choco install protoc
These dependencies are for compiling Lighthouse natively on Windows. Lighthouse can also run
successfully under the [Windows Subsystem for Linux (WSL)][WSL]. If using Ubuntu under WSL, you
should follow the instructions for Ubuntu listed in the [Dependencies (Ubuntu)](#ubuntu) section.
[WSL]: https://docs.microsoft.com/en-us/windows/wsl/about
## Build Lighthouse
@@ -128,8 +129,12 @@ Commonly used features include:
* `gnosis`: support for the Gnosis Beacon Chain.
* `portable`: support for legacy hardware.
* `modern`: support for exclusively modern hardware.
* `slasher-mdbx`: support for the MDBX slasher backend (enabled by default).
* `slasher-mdbx`: support for the MDBX slasher backend. Enabled by default.
* `slasher-lmdb`: support for the LMDB slasher backend.
* `jemalloc`: use [`jemalloc`][jemalloc] to allocate memory. Enabled by default on Linux and macOS.
Not supported on Windows.
[jemalloc]: https://jemalloc.net/
## Compilation Profiles

4
book/src/merge-migration.md
View File

@@ -58,7 +58,7 @@ supported.
Each execution engine has its own flags for configuring the engine API and JWT. Please consult
the relevant page for your execution engine for the required flags:
- [Geth: Connecting to Consensus Clients](https://geth.ethereum.org/docs/interface/consensus-clients)
- [Geth: Connecting to Consensus Clients](https://geth.ethereum.org/docs/getting-started/consensus-clients)
- [Nethermind: Running Nethermind Post Merge](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/running-nethermind-post-merge)
- [Besu: Prepare For The Merge](https://besu.hyperledger.org/en/stable/HowTo/Upgrade/Prepare-for-The-Merge/)
- [Erigon: Beacon Chain (Consensus Layer)](https://github.com/ledgerwatch/erigon#beacon-chain-consensus-layer)
@@ -203,5 +203,5 @@ guidance for specific setups.
- [Ethereum.org: The Merge](https://ethereum.org/en/upgrades/merge/)
- [Ethereum Staking Launchpad: Merge Readiness](https://launchpad.ethereum.org/en/merge-readiness).
- [CoinCashew: Ethereum Merge Upgrade Checklist](https://www.coincashew.com/coins/overview-eth/ethereum-merge-upgrade-checklist-for-home-stakers-and-validators)
- [EthDocker: Merge Preparation](https://eth-docker.net/docs/About/MergePrep/)
- [EthDocker: Merge Preparation](https://eth-docker.net/About/MergePrep/)
- [Remy Roy: How to join the Goerli/Prater merge testnet](https://github.com/remyroy/ethstaker/blob/main/merge-goerli-prater.md)

2
book/src/run_a_node.md
View File

@@ -26,7 +26,7 @@ has authority to control the execution engine.
Each execution engine has its own flags for configuring the engine API and JWT.
Please consult the relevant page of your execution engine for the required flags:
- [Geth: Connecting to Consensus Clients](https://geth.ethereum.org/docs/interface/consensus-clients)
- [Geth: Connecting to Consensus Clients](https://geth.ethereum.org/docs/getting-started/consensus-clients)
- [Nethermind: Running Nethermind & CL](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/running-nethermind-post-merge)
- [Besu: Connect to Mainnet](https://besu.hyperledger.org/en/stable/public-networks/get-started/connect/mainnet/)
- [Erigon: Beacon Chain (Consensus Layer)](https://github.com/ledgerwatch/erigon#beacon-chain-consensus-layer)

9
book/src/validator-inclusion.md
View File

@@ -59,14 +59,7 @@ The following fields are returned:
- `previous_epoch_head_attesting_gwei`: the total staked gwei that attested to a
head beacon block that is in the canonical chain.
From this data you can calculate some interesting figures:
#### Participation Rate
`previous_epoch_attesting_gwei / previous_epoch_active_gwei`
Expresses the ratio of validators that managed to have an attestation
voting upon the previous epoch included in a block.
From this data you can calculate:
#### Justification/Finalization Rate

6
book/src/voluntary-exit.md
View File

@@ -12,10 +12,10 @@ This number can be much higher depending on how many other validators are queued
## Withdrawal of exited funds
Even though users can perform a voluntary exit in phase 0, they **cannot withdraw their exited funds at this point in time**.
This implies that the staked funds are effectively **frozen** until withdrawals are enabled in future phases.
Even though users can currently perform a voluntary exit, they **cannot withdraw their exited funds at this point in time**.
This implies that the staked funds are effectively **frozen** until withdrawals are enabled in a future hard fork (Capella).
To understand the phased rollout strategy for Ethereum upgrades, please visit <https://ethereum.org/en/upgrades/#roadmap>.
To understand the rollout strategy for Ethereum upgrades, please visit <https://ethereum.org/en/upgrades>.