gnosis/lighthouse
1
0
Fork 0
mirror of https://github.com/sigp/lighthouse.git synced 2026-07-04 05:14:33 +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-11 13:15:06 +11:00
parent c8dc082ba8 2e8e160679
commit 8db17dac1d
114 changed files with 4419 additions and 2343 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
book/src/builders.md
View File

@@ -176,31 +176,6 @@ 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
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
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
most valuable payload offered by builders is only 0.1 ETH, the local execution engine's payload will be used.
Since the [Capella](https://ethereum.org/en/history/#capella) upgrade, a comparison of the external payload and local payload will be made according to the [engine_getPayloadV2](https://github.com/ethereum/execution-apis/blob/main/src/engine/shanghai.md#engine_getpayloadv2) API. The logic is as follows:
```
if local payload value >= builder payload value:
use local payload
else if builder payload value >= builder_profit_threshold or builder_profit_threshold == 0:
use builder payload
else:
use local payload
```
If you would like to always use the builder payload, you can add the flag `--always-prefer-builder-payload` to the beacon node.
## Checking your builder config
You can check that your builder is configured correctly by looking for these log messages.

28
book/src/help_bn.md
View File

@@ -9,8 +9,11 @@ USAGE:
lighthouse beacon_node [FLAGS] [OPTIONS]
FLAGS:
--always-prefer-builder-payload If set, the beacon node always uses the payload from the builder instead
of the local payload.
--allow-insecure-genesis-sync Enable syncing from genesis, which is generally insecure and incompatible
with data availability checks. Checkpoint syncing is the preferred method
for syncing a node. Only use this flag when testing. DO NOT use on
mainnet!
--always-prefer-builder-payload This flag is deprecated and has no effect.
--always-prepare-payload Send payload attributes with every fork choice update. This is intended
for use by block builders, relays and developers. You should set a fee
recipient on this BN and also consider adjusting the --prepare-payload-
@@ -29,6 +32,11 @@ FLAGS:
--disable-deposit-contract-sync Explictly 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
useful for detecting a duplicate validator key running elsewhere.
However, this may result in excessive warning logs if the validator is
broadcasting messages to multiple beacon nodes via the validator client
--broadcast flag. In this case, disabling these warn logs may be useful.
-x, --disable-enr-auto-update Discovery automatically updates the nodes local ENR with an external IP
address and port as seen by other peers on the network. This disables
this feature, fixing the ENR's IP/PORT to those specified on boot.
@@ -170,12 +178,8 @@ OPTIONS:
`SLOTS_PER_EPOCH`, it will NOT query any connected builders, and will use the local execution engine for
payload construction. [default: 8]
--builder-profit-threshold <WEI_VALUE>
The minimum reward in wei provided to the proposer by a block builder for an external payload to be
considered for inclusion in a proposal. If this threshold is not met, the local EE's payload will be used.
This is currently *NOT* in comparison to the value of the local EE's payload. It simply checks whether the
total proposer reward from an external payload is equal to or greater than this value. In the future, a
comparison to a local payload is likely to be added. Example: Use 250000000000000000 to set the threshold to
0.25 ETH. [default: 0]
This flag is deprecated and has no effect.
--builder-user-agent <STRING>
The HTTP user agent to send alongside requests to the builder URL. The default is Lighthouse's version
string.
@@ -308,14 +312,6 @@ OPTIONS:
--http-tls-key <http-tls-key>
The path of the private key to be used when serving the HTTP API server over TLS. Must not be password-
protected.
--ignore-builder-override-suggestion-threshold <PERCENTAGE>
When the EE advises Lighthouse to ignore the builder payload, this flag specifies a percentage threshold for
the difference between the reward from the builder payload and the local EE's payload. This threshold must
be met for Lighthouse to consider ignoring the EE's suggestion. If the reward from the builder's payload
doesn't exceed the local payload by at least this percentage, the local payload will be used. The conditions
under which the EE may make this suggestion depend on the EE's implementation, with the primary intent being
to safeguard against potential censorship attacks from builders. Setting this flag to 0 will cause
Lighthouse to always ignore the EE's suggestion. Default: 10.0 (equivalent to 10%). [default: 10.0]
--invalid-gossip-verified-blocks-path <PATH>
If a block succeeds gossip validation whilst failing full validation, store the block SSZ as a file at this
path. This feature is only recommended for developers. This directory is not pruned, users should be careful

4
book/src/help_vc.md
View File

@@ -56,6 +56,10 @@ 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.
--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
future.
--unencrypted-http-transport
This is a safety flag to ensure that the user is aware that the http transport is unencrypted and using a
custom HTTP address is unsafe.

4
book/src/redundancy.md
View File

@@ -101,6 +101,10 @@ from this list:
- `none`: Disable all broadcasting. This option only has an effect when provided alone, otherwise
it is ignored. Not recommended except for expert tweakers.
Broadcasting attestation, blocks and sync committee messages may result in excessive warning logs in the beacon node
due to duplicate gossip messages. In this case, it may be desirable to disable warning logs for duplicates using the
beacon node `--disable-duplicate-warn-logs` flag.
The default is `--broadcast subscriptions`. To also broadcast blocks for example, use
`--broadcast subscriptions,blocks`.