gnosis/lighthouse
1
0
Fork 0
mirror of https://github.com/sigp/lighthouse.git synced 2026-04-19 05:48:31 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'unstable' into validator-manager

Browse Source
This commit is contained in:
Paul Hauner
2022-10-31 14:09:25 +11:00
parent dbe2fa4c1b fcfd02aeec
commit 958d1e49f2
163 changed files with 4086 additions and 3104 deletions
Download Patch File Download Diff File Expand all files Collapse all files

77
book/src/builders.md
View File

@@ -45,24 +45,24 @@ relays, run one of the following services and configure lighthouse to use it wit
## Validator Client Configuration
In the validator client you can configure gas limit and fee recipient on a per-validator basis. If no gas limit is
configured, Lighthouse will use a default gas limit of 30,000,000, which is the current default value used in execution
engines. You can also enable or disable use of external builders on a per-validator basis rather than using
In the validator client you can configure gas limit and fee recipient on a per-validator basis. If no gas limit is
configured, Lighthouse will use a default gas limit of 30,000,000, which is the current default value used in execution
engines. You can also enable or disable use of external builders on a per-validator basis rather than using
`--builder-proposals`, which enables external builders for all validators. In order to manage these configurations
per-validator, you can either make updates to the `validator_definitions.yml` file or you can use the HTTP requests
described below.
Both the gas limit and fee recipient will be passed along as suggestions to connected builders. If there is a discrepancy
in either, it will *not* keep you from proposing a block with the builder. This is because the bounds on gas limit are
calculated based on prior execution blocks, so an honest external builder will make sure that even if your
requested gas limit value is out of the specified range, a valid gas limit in the direction of your request will be
calculated based on prior execution blocks, so an honest external builder will make sure that even if your
requested gas limit value is out of the specified range, a valid gas limit in the direction of your request will be
used in constructing the block. Depending on the connected relay, payment to the proposer might be in the form of a
transaction within the block to the fee recipient, so a discrepancy in fee recipient might not indicate that there
is something afoot.
transaction within the block to the fee recipient, so a discrepancy in fee recipient might not indicate that there
is something afoot.
> Note: The gas limit configured here is effectively a vote on block size, so the configuration should not be taken lightly.
> Note: The gas limit configured here is effectively a vote on block size, so the configuration should not be taken lightly.
> 30,000,000 is currently seen as a value balancing block size with how expensive it is for
> the network to validate blocks. So if you don't feel comfortable making an informed "vote", using the default value is
> the network to validate blocks. So if you don't feel comfortable making an informed "vote", using the default value is
> encouraged. We will update the default value if the community reaches a rough consensus on a new value.
### Set Gas Limit via HTTP
@@ -157,20 +157,71 @@ By default, Lighthouse is strict with these conditions, but we encourage users t
- `--builder-fallback-disable-checks` - This flag disables all checks related to chain health. This means the builder
API will always be used for payload construction, regardless of recent chain conditions.
## Builder Profit Threshold
## Builder Profit Threshold
If you are generally uneasy with the risks associated with outsourced payload production (liveness/censorship) but would
consider using it for the chance of out-sized rewards, this flag may be useful:
`--builder-profit-threshold <WEI_VALUE>`
The number provided indicates the minimum reward that an external payload must provide the proposer for it to be considered
The number provided indicates the minimum reward that an external payload must provide the proposer for it to be considered
for inclusion in a proposal. For example, if you'd only like to use an external payload for a reward of >= 0.25 ETH, you
would provide your beacon node with `--builder-profit-threshold 250000000000000000`. If it's your turn to propose and the
would provide your beacon node with `--builder-profit-threshold 250000000000000000`. If it's your turn to propose and the
most valuable payload offered by builders is only 0.1 ETH, the local execution engine's payload will be used. Currently,
this threshold just looks at the value of the external payload. No comparison to the local payload is made, although
this threshold just looks at the value of the external payload. No comparison to the local payload is made, although
this feature will likely be added in the future.
## Checking your builder config
You can check that your builder is configured correctly by looking for these log messages.
On start-up, the beacon node will log if a builder is configured:
```
INFO Connected to external block builder
```
At regular intervals the validator client will log that it successfully registered its validators
with the builder network:
```
INFO Published validator registrations to the builder network
```
When you succesfully propose a block using a builder, you will see this log on the beacon node:
```
INFO Successfully published a block to the builder network
```
If you don't see that message around the time of your proposals, check your beacon node logs
for `INFO` and `WARN` messages indicating why the builder was not used.
Examples of messages indicating fallback to a locally produced block are:
```
INFO No payload provided by connected builder.
```
```
WARN Unable to retrieve a payload from a connected builder
```
```
INFO The value offered by the connected builder does not meet the configured profit threshold.
```
```
INFO Due to poor chain health the local execution engine will be used for payload construction.
```
In case of fallback you should see a log indicating that the locally produced payload was
used in place of one from the builder:
```
INFO Reconstructing a full block using a local payload
```
[mev-rs]: https://github.com/ralexstokes/mev-rs
[mev-boost]: https://github.com/flashbots/mev-boost
[gas-limit-api]: https://ethereum.github.io/keymanager-APIs/#/Gas%20Limit

6
book/src/cross-compiling.md
View File

@@ -44,3 +44,9 @@ in `lighthouse/target/aarch64-unknown-linux-gnu/release`.
When using the makefile the set of features used for building can be controlled with
the environment variable `CROSS_FEATURES`. See [Feature
Flags](./installation-source.md#feature-flags) for available features.
## Compilation Profiles
When using the makefile the build profile can be controlled with the environment variable
`CROSS_PROFILE`. See [Compilation Profiles](./installation-source.md#compilation-profiles) for
available profiles.

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

@@ -16,7 +16,7 @@ operating system.
Install the following packages:
```bash
sudo apt install -y git gcc g++ make cmake pkg-config llvm-dev libclang-dev clang
sudo apt install -y git gcc g++ make cmake pkg-config llvm-dev libclang-dev clang protobuf-compiler
```
> Note: Lighthouse requires CMake v3.12 or newer, which isn't available in the package repositories
@@ -32,13 +32,18 @@ sudo apt install -y git gcc g++ make cmake pkg-config llvm-dev libclang-dev clan
brew install cmake
```
1. Install protoc using Homebrew:
```
brew install protobuf
```
[Homebrew]: https://brew.sh/
#### Windows
1. Install [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git).
1. Install the [Chocolatey](https://chocolatey.org/install) package manager for Windows.
1. Install Make, CMake and LLVM using Chocolatey:
1. Install Make, CMake, LLVM and protoc using Chocolatey:
```
choco install make
@@ -52,10 +57,13 @@ choco install cmake --installargs 'ADD_CMAKE_TO_PATH=System'
choco install llvm
```
```
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
@@ -112,7 +120,7 @@ You can customise the features that Lighthouse is built with using the `FEATURES
variable. E.g.
```
env FEATURES="gnosis,slasher-lmdb" make
FEATURES=gnosis,slasher-lmdb make
```
Commonly used features include:
@@ -123,6 +131,25 @@ Commonly used features include:
* `slasher-mdbx`: support for the MDBX slasher backend (enabled by default).
* `slasher-lmdb`: support for the LMDB slasher backend.
## Compilation Profiles
You can customise the compiler settings used to compile Lighthouse via
[Cargo profiles](https://doc.rust-lang.org/cargo/reference/profiles.html).
Lighthouse includes several profiles which can be selected via the `PROFILE` environment variable.
* `release`: default for source builds, enables most optimisations while not taking too long to
compile.
* `maxperf`: default for binary releases, enables aggressive optimisations including full LTO.
Although compiling with this profile improves some benchmarks by around 20% compared to `release`,
it imposes a _significant_ cost at compile time and is only recommended if you have a fast CPU.
To compile with `maxperf`:
```
PROFILE=maxperf make
```
## Troubleshooting
### Command is not found

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

@@ -48,6 +48,10 @@ If you set up an execution engine with `--execution-endpoint` then you *must* pr
using `--execution-jwt`. This is a mandatory form of authentication that ensures that Lighthouse
has authority to control the execution engine.
> Tip: the --execution-jwt-secret-key <STRING> flag can be used instead of --execution-jwt <FILE>.
> This is useful, for example, for users who wish to inject the value into a Docker container without
> needing to pass a jwt secret file.
The execution engine connection must be **exclusive**, i.e. you must have one execution node
per beacon node. The reason for this is that the beacon node _controls_ the execution node. Please
see the [FAQ](#faq) for further information about why many:1 and 1:many configurations are not

2
book/src/setup.md
View File

@@ -14,6 +14,8 @@ The additional requirements for developers are:
don't have `ganache` available on your `PATH` or if ganache is older than v7.
- [`cmake`](https://cmake.org/cmake/help/latest/command/install.html). Used by
some dependencies. See [`Installation Guide`](./installation.md) for more info.
- [`protoc`](https://github.com/protocolbuffers/protobuf/releases) required for
the networking stack.
- [`java 11 runtime`](https://openjdk.java.net/projects/jdk/). 11 is the minimum,
used by web3signer_tests.