gnosis/lighthouse
1
0
Fork 0
mirror of https://github.com/sigp/lighthouse.git synced 2026-03-24 07:14:46 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'origin/unstable' into tree-states

Browse Source
This commit is contained in:
Michael Sproul
2024-01-25 15:10:19 +11:00
parent 6262be7219 1be5253610
commit 262e5f22bc
91 changed files with 2255 additions and 654 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
book/src/api-vc-endpoints.md
View File

@@ -427,7 +427,7 @@ Example Response Body
## `PATCH /lighthouse/validators/:voting_pubkey`
Update some values for the validator with `voting_pubkey`. Possible fields: `enabled`, `gas_limit`, `builder_proposals`,
Update some values for the validator with `voting_pubkey`. Possible fields: `enabled`, `gas_limit`, `builder_proposals`, `builder_boost_factor`, `prefer_builder_proposals`
and `graffiti`. The following example updates a validator from `enabled: true` to `enabled: false`.
### HTTP Specification

18
book/src/builders.md
View File

@@ -31,6 +31,18 @@ blinded blocks, you should use the following flag:
lighthouse vc --builder-proposals
```
With the `--builder-proposals` flag, the validator client will ask for blinded blocks for all validators it manages.
```
lighthouse vc --prefer-builder-proposals
```
With the `--prefer-builder-proposals` flag, the validator client will always prefer blinded blocks, regardless of the payload value, for all validators it manages.
```
lighthouse vc --builder-boost-factor <INTEGER>
```
With the `--builder-boost-factor` flag, a percentage multiplier is applied to the builder's payload value when choosing between a
builder payload header and payload from the paired execution node.
In order to configure whether a validator queries for blinded blocks check out [this section.](#validator-client-configuration)
## Multiple builders
@@ -46,9 +58,9 @@ relays, run one of the following services and configure lighthouse to use it wit
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.
`--builder-proposals`, `--builder-boost-factor` or `--prefer-builder-proposals`, which apply builder related preferences 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

6
book/src/database-migrations.md
View File

@@ -16,7 +16,8 @@ validator client or the slasher**.
| Lighthouse version | Release date | Schema version | Downgrade available? |
|--------------------|--------------|----------------|----------------------|
| v4.6.0 | Dec 2023 | v18 | yes before Deneb |
| v4.6.0 | Dec 2023 | v19 | yes before Deneb |
| v4.6.0-rc.0 | Dec 2023 | v18 | yes before Deneb |
| v4.5.0 | Sep 2023 | v17 | yes |
| v4.4.0 | Aug 2023 | v17 | yes |
| v4.3.0 | Jul 2023 | v17 | yes |
@@ -192,7 +193,8 @@ Here are the steps to prune historic states:
| Lighthouse version | Release date | Schema version | Downgrade available? |
|--------------------|--------------|----------------|-------------------------------------|
| v4.6.0 | Dec 2023 | v18 | yes before Deneb |
| v4.6.0 | Dec 2023 | v19 | yes before Deneb |
| v4.6.0-rc.0 | Dec 2023 | v18 | yes before Deneb |
| v4.5.0 | Sep 2023 | v17 | yes |
| v4.4.0 | Aug 2023 | v17 | yes |
| v4.3.0 | Jul 2023 | v17 | yes |

2
book/src/help_bn.md
View File

@@ -29,7 +29,7 @@ FLAGS:
contention which degrades staking performance. Stakers should generally
choose to avoid this flag since backfill sync is not required for
staking.
--disable-deposit-contract-sync Explictly disables syncing of deposit logs from the execution node. This
--disable-deposit-contract-sync Explicitly disables syncing of deposit logs from the execution node. This
overrides any previous option that depends on it. Useful if you intend to
run a non-validating beacon node.
--disable-duplicate-warn-logs Disable warning logs for duplicate gossip messages. The WARN level log is

4
book/src/help_general.md
View File

@@ -13,8 +13,8 @@ FLAGS:
--disable-malloc-tuning If present, do not configure the system allocator. Providing this flag will
generally increase memory usage, it should only be provided when debugging
specific memory allocation issues.
-l Enables environment logging giving access to sub-protocol logs such as discv5
and libp2p
-l DEPRECATED Enables environment logging giving access to sub-protocol logs such
as discv5 and libp2p
-h, --help Prints help information
--log-color Force outputting colors when emitting logs to the terminal.
--logfile-compress If present, compress old log files. This can help reduce the space needed to

6
book/src/help_vc.md
View File

@@ -56,6 +56,9 @@ FLAGS:
machine. Note that logs can often contain sensitive information about your validator and so this flag should
be used with caution. For Windows users, the log file permissions will be inherited from the parent folder.
--metrics Enable the Prometheus metrics HTTP server. Disabled by default.
--prefer-builder-proposals
If this flag is set, Lighthouse will always prefer blocks constructed by builders, regardless of payload
value.
--produce-block-v3
Enable block production via the block v3 endpoint for this validator client. This should only be enabled
when paired with a beacon node that has this endpoint implemented. This flag will be enabled by default in
@@ -80,6 +83,9 @@ OPTIONS:
Comma-separated list of beacon API topics to broadcast to all beacon nodes. Possible values are: none,
attestations, blocks, subscriptions, sync-committee. Default (when flag is omitted) is to broadcast
subscriptions only.
--builder-boost-factor <UINT64>
Defines the boost factor, a percentage multiplier to apply to the builder's payload value when choosing
between a builder payload header and payload from the local execution node.
--builder-registration-timestamp-override <builder-registration-timestamp-override>
This flag takes a unix timestamp value that will be used to override the timestamp used in the builder api
registration

10
book/src/help_vm_create.md
View File

@@ -42,6 +42,9 @@ OPTIONS:
A HTTP(S) address of a beacon node using the beacon-API. If this value is provided, an error will be raised
if any validator key here is already known as a validator by that beacon node. This helps prevent the same
validator being created twice and therefore slashable conditions.
--builder-boost-factor <UINT64>
Defines the boost factor, a percentage multiplier to apply to the builder's payload value when choosing
between a builder payload header and payload from the local execution node.
--builder-proposals <builder-proposals>
When provided, all created validators will attempt to create blocks via builder rather than the local EL.
[possible values: true, false]
@@ -93,13 +96,18 @@ OPTIONS:
--logfile-max-size <SIZE>
The maximum size (in MB) each log file can grow to before rotating. If set to 0, background file logging is
disabled. [default: 200]
--mnemonic-path <MNEMONIC_PATH> If present, the mnemonic will be read in from this file.
--mnemonic-path <MNEMONIC_PATH>
If present, the mnemonic will be read in from this file.
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, prater, goerli, gnosis,
chiado, sepolia, holesky]
--output-path <DIRECTORY>
The path to a directory where the validator and (optionally) deposits files will be created. The directory
will be created if it does not exist.
--prefer-builder-proposals <prefer-builder-proposals>
If this flag is set, Lighthouse will always prefer blocks constructed by builders, regardless of payload
value. [possible values: true, false]
--safe-slots-to-import-optimistically <INTEGER>
Used to coordinate manual overrides of the SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY parameter. This flag should
only be used if the user has a clear understanding that the broad Ethereum community has elected to override

8
book/src/help_vm_move.md
View File

@@ -26,10 +26,13 @@ FLAGS:
-V, --version Prints version information
OPTIONS:
--builder-boost-factor <UINT64>
Defines the boost factor, a percentage multiplier to apply to the builder's payload value when choosing
between a builder payload header and payload from the local execution node.
--builder-proposals <builder-proposals>
When provided, all created validators will attempt to create blocks via builder rather than the local EL.
[possible values: true, false]
--count <VALIDATOR_COUNT> The number of validators to move.
--count <VALIDATOR_COUNT> The number of validators to move.
-d, --datadir <DIR>
Used to specify a custom root data directory for lighthouse keys and databases. Defaults to
$HOME/.lighthouse/{network} where network is the value of the `network` flag Note: Users should specify
@@ -75,6 +78,9 @@ OPTIONS:
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, prater, goerli, gnosis,
chiado, sepolia, holesky]
--prefer-builder-proposals <prefer-builder-proposals>
If this flag is set, Lighthouse will always prefer blocks constructed by builders, regardless of payload
value. [possible values: true, false]
--safe-slots-to-import-optimistically <INTEGER>
Used to coordinate manual overrides of the SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY parameter. This flag should
only be used if the user has a clear understanding that the broad Ethereum community has elected to override

2
book/src/redundancy.md
View File

@@ -97,7 +97,7 @@ from this list:
setup this is the first option we would recommend enabling.
- `sync-committee`: Send sync committee signatures & aggregates to all beacon nodes. This can
improve propagation of sync committee messages with similar tradeoffs to broadcasting
attestations, although occuring less often due to the infrequency of sync committee duties.
attestations, although occurring less often due to the infrequency of sync committee duties.
- `none`: Disable all broadcasting. This option only has an effect when provided alone, otherwise
it is ignored. Not recommended except for expert tweakers.

2
book/src/slasher.md
View File

@@ -71,7 +71,7 @@ If an MDBX database is already found on disk, then Lighthouse will try to use it
in a log at start-up:
```
INFO Slasher backend overriden reason: database exists, configured_backend: lmdb, overriden_backend: mdbx
INFO Slasher backend overridden reason: database exists, configured_backend: lmdb, overridden_backend: mdbx
```
If the running Lighthouse binary doesn't have the MDBX backend enabled but an existing database is

2
book/src/validator-manager-create.md
View File

@@ -139,7 +139,7 @@ In order to import the validators, the location of the VC `api-token.txt` file
must be known. The location of the file varies, but it is located in the
"validator directory" of your data directory. For example:
`~/.lighthouse/mainnet/validators/api-token.txt`. We will use `<API-TOKEN-PATH>`
to subsitute this value. If you are unsure of the `api-token.txt` path, you can run `curl http://localhost:5062/lighthouse/auth` which will show the path.
to substitute this value. If you are unsure of the `api-token.txt` path, you can run `curl http://localhost:5062/lighthouse/auth` which will show the path.
Once the VC is running, use the `import` command to import the validators to the VC: