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

upgrade clap to v4.5 (#5273)

Browse Source 
* upgrade clap to v4.5

* cli fixes

* Merge branch 'unstable' of https://github.com/sigp/lighthouse into upgrade-clap-cli

* value parser for mnemonic

* Merge branch 'unstable' of https://github.com/sigp/lighthouse into upgrade-clap-cli

* merge unstable

* default --format val

* fix eth sim

* fix eth sim

* merge conflicts

* resolve beta compiler issue

* add num args, version

* add custom flag parser, make rate limiter flags clap friendly

* remove unneeded check

* fmt

* update

* alphabetic order

* resolve merge conflict

* fix test

* resolve conflicts

* fix test

* revert removed if statement

* fmt got me again

* fix broken flag

* make cli

* make cli

* update

* remove -e files

* update

* cli help updates

* Merge branch 'unstable' of https://github.com/sigp/lighthouse into upgrade-clap-cli

* cli help updates

* md files

* merge conflict

* merge conflicts

* md

* help text, text width, and a few flag fixes

* fmt

* merge

* revert

* revert

* resolve merge conflicts

* merge conflicts

* revert simulator changes

* require at least one arg

* fix eth sim cli

* resolve merge conflicts

* book changes

* md changes

* cli check

* cli check

* retry cli check

* retry cli check

* Merge branch 'unstable' of https://github.com/sigp/lighthouse into upgrade-clap-cli

* cli

* Merge remote-tracking branch 'origin/unstable' into upgrade-clap-cli

* Update CLI docs for Goerli removal

* Fix cargo lock
This commit is contained in:
Eitan Seri-Levi
2024-05-28 07:46:39 +02:00
committed by GitHub
parent 6a7305a487
commit df983a83e1
61 changed files with 4036 additions and 2868 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1079
book/src/help_bn.md
View File

File diff suppressed because it is too large Load Diff

230
book/src/help_general.md
View File

@@ -1,109 +1,141 @@
# Lighthouse General Commands
```
Sigma Prime <contact@sigmaprime.io>
Ethereum 2.0 client by Sigma Prime. Provides a full-featured beacon node, a validator client and utilities for managing
validator accounts.
Ethereum 2.0 client by Sigma Prime. Provides a full-featured beacon node, a
validator client and utilities for managing validator accounts.
USAGE:
lighthouse [FLAGS] [OPTIONS] [SUBCOMMAND]
Usage: lighthouse [OPTIONS] [COMMAND]
FLAGS:
--disable-log-timestamp If present, do not include timestamps in logging output.
--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 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
store old logs.
--logfile-no-restricted-perms If present, log files will be generated as world-readable meaning they can be
read by any user on the 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.
-V, --version Prints version information
Commands:
account_manager
Utilities for generating and managing Ethereum 2.0 accounts. [aliases:
a, am, account, account_manager]
beacon_node
The primary component which connects to the Ethereum 2.0 P2P network
and downloads, verifies and stores blocks. Provides a HTTP API for
querying the beacon chain and publishing messages to the network.
[aliases: b, bn, beacon]
boot_node
Start a special Lighthouse process that only serves as a discv5
boot-node. This process will *not* import blocks or perform most
typical beacon node functions. Instead, it will simply run the discv5
service and assist nodes on the network to discover each other. This
is the recommended way to provide a network boot-node since it has a
reduced attack surface compared to a full beacon node.
database_manager
Manage a beacon node database [aliases: db]
validator_client
When connected to a beacon node, performs the duties of a staked
validator (e.g., proposing blocks and attestations). [aliases: v, vc,
validator]
validator_manager
Utilities for managing a Lighthouse validator client via the HTTP API.
[aliases: vm, validator-manager, validator_manager]
help
Print this message or the help of the given subcommand(s)
OPTIONS:
-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
separate custom datadirs for different networks.
--debug-level <LEVEL>
Specifies the verbosity level used when emitting logs to the terminal. [default: info] [possible values:
info, debug, trace, warn, error, crit]
--genesis-state-url <URL>
A URL of a beacon-API compatible server from which to download the genesis state. Checkpoint sync server
URLs can generally be used with this flag. If not supplied, a default URL or the --checkpoint-sync-url may
be used. If the genesis state is already included in this binary then this value will be ignored.
--genesis-state-url-timeout <SECONDS>
The timeout in seconds for the request to --genesis-state-url. [default: 180]
Options:
-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 separate
custom datadirs for different networks.
--debug-level <LEVEL>
Specifies the verbosity level used when emitting logs to the terminal.
[default: info] [possible values: info, debug, trace, warn, error,
crit]
--genesis-state-url <URL>
A URL of a beacon-API compatible server from which to download the
genesis state. Checkpoint sync server URLs can generally be used with
this flag. If not supplied, a default URL or the --checkpoint-sync-url
may be used. If the genesis state is already included in this binary
then this value will be ignored.
--genesis-state-url-timeout <SECONDS>
The timeout in seconds for the request to --genesis-state-url.
[default: 180]
--log-format <FORMAT>
Specifies the log format used when emitting logs to the terminal.
[possible values: JSON]
--logfile <FILE>
File path where the log file will be stored. Once it grows to the
value specified in `--logfile-max-size` a new log file is generated
where future logs are stored. Once the number of log files exceeds the
value specified in `--logfile-max-number` the oldest log file will be
overwritten.
--logfile-debug-level <LEVEL>
The verbosity level used when emitting logs to the log file. [default:
debug] [possible values: info, debug, trace, warn, error, crit]
--logfile-format <FORMAT>
Specifies the log format used when emitting logs to the logfile.
[possible values: DEFAULT, JSON]
--logfile-max-number <COUNT>
The maximum number of log files that will be stored. If set to 0,
background file logging is disabled. [default: 5]
--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]
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible
values: mainnet, gnosis, chiado, sepolia, holesky]
--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 this parameter in the event of an
attack at the PoS transition block. Incorrect use of this flag can
cause your node to possibly accept an invalid chain or sync more
slowly. Be extremely careful with this flag.
-t, --testnet-dir <DIR>
Path to directory containing eth2_testnet specs. Defaults to a
hard-coded Lighthouse testnet. Only effective if there is no existing
database.
--terminal-block-hash-epoch-override <EPOCH>
Used to coordinate manual overrides to the
TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH parameter. This flag should only
be used if the user has a clear understanding that the broad Ethereum
community has elected to override the terminal PoW block. Incorrect
use of this flag will cause your node to experience a consensus
failure. Be extremely careful with this flag.
--terminal-block-hash-override <TERMINAL_BLOCK_HASH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH
parameter. This flag should only be used if the user has a clear
understanding that the broad Ethereum community has elected to
override the terminal PoW block. Incorrect use of this flag will cause
your node to experience a consensus failure. Be extremely careful with
this flag.
--terminal-total-difficulty-override <INTEGER>
Used to coordinate manual overrides to the TERMINAL_TOTAL_DIFFICULTY
parameter. Accepts a 256-bit decimal integer (not a hex value). This
flag should only be used if the user has a clear understanding that
the broad Ethereum community has elected to override the terminal
difficulty. Incorrect use of this flag will cause your node to
experience a consensus failure. Be extremely careful with this flag.
-V, --version
Print version
--log-format <FORMAT>
Specifies the log format used when emitting logs to the terminal. [possible values: JSON]
--logfile <FILE>
File path where the log file will be stored. Once it grows to the value specified in `--logfile-max-size` a
new log file is generated where future logs are stored. Once the number of log files exceeds the value
specified in `--logfile-max-number` the oldest log file will be overwritten.
--logfile-debug-level <LEVEL>
The verbosity level used when emitting logs to the log file. [default: debug] [possible values: info,
debug, trace, warn, error, crit]
--logfile-format <FORMAT>
Specifies the log format used when emitting logs to the logfile. [possible values: DEFAULT, JSON]
--logfile-max-number <COUNT>
The maximum number of log files that will be stored. If set to 0, background file logging is disabled.
[default: 5]
--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]
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, gnosis, chiado, sepolia,
holesky]
--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
this parameter in the event of an attack at the PoS transition block. Incorrect use of this flag can cause
your node to possibly accept an invalid chain or sync more slowly. Be extremely careful with this flag.
--terminal-block-hash-epoch-override <EPOCH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH parameter. This flag should
only be used if the user has a clear understanding that the broad Ethereum community has elected to override
the terminal PoW block. Incorrect use of this flag will cause your node to experience a consensus failure.
Be extremely careful with this flag.
--terminal-block-hash-override <TERMINAL_BLOCK_HASH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH parameter. This flag should only be used if
the user has a clear understanding that the broad Ethereum community has elected to override the terminal
PoW block. Incorrect use of this flag will cause your node to experience a consensus failure. Be extremely
careful with this flag.
--terminal-total-difficulty-override <INTEGER>
Used to coordinate manual overrides to the TERMINAL_TOTAL_DIFFICULTY parameter. Accepts a 256-bit decimal
integer (not a hex value). This flag should only be used if the user has a clear understanding that the
broad Ethereum community has elected to override the terminal difficulty. Incorrect use of this flag will
cause your node to experience a consensus failure. Be extremely careful with this flag.
-t, --testnet-dir <DIR>
Path to directory containing eth2_testnet specs. Defaults to a hard-coded Lighthouse testnet. Only effective
if there is no existing database.
SUBCOMMANDS:
account_manager Utilities for generating and managing Ethereum 2.0 accounts. [aliases: a, am, account,
account_manager]
beacon_node The primary component which connects to the Ethereum 2.0 P2P network and downloads,
verifies and stores blocks. Provides a HTTP API for querying the beacon chain and
publishing messages to the network. [aliases: b, bn, beacon]
boot_node Start a special Lighthouse process that only serves as a discv5 boot-node. This process
will *not* import blocks or perform most typical beacon node functions. Instead, it will
simply run the discv5 service and assist nodes on the network to discover each other. This
is the recommended way to provide a network boot-node since it has a reduced attack surface
compared to a full beacon node.
database_manager Manage a beacon node database [aliases: db]
help Prints this message or the help of the given subcommand(s)
validator_client When connected to a beacon node, performs the duties of a staked validator (e.g., proposing
blocks and attestations). [aliases: v, vc, validator]
validator_manager Utilities for managing a Lighthouse validator client via the HTTP API. [aliases: vm,
validator-manager, validator_manager]
Flags:
--disable-log-timestamp
If present, do not include timestamps in logging output.
--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.
-h, --help
Prints help information
-l
DEPRECATED Enables environment logging giving access to sub-protocol
logs such as discv5 and libp2p
--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 store old logs.
--logfile-no-restricted-perms
If present, log files will be generated as world-readable meaning they
can be read by any user on the 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.
```
<style> .content main {max-width:88%;} </style>

490
book/src/help_vc.md
View File

@@ -1,227 +1,281 @@
# Validator Client
```
When connected to a beacon node, performs the duties of a staked validator (e.g., proposing blocks and attestations).
When connected to a beacon node, performs the duties of a staked validator
(e.g., proposing blocks and attestations).
USAGE:
lighthouse validator_client [FLAGS] [OPTIONS]
Usage: lighthouse validator_client [OPTIONS]
FLAGS:
--builder-proposals
If this flag is set, Lighthouse will query the Beacon Node for only block headers during proposals and will
sign over headers. Useful for outsourcing execution payload construction during proposals.
--disable-auto-discover
If present, do not attempt to discover new validators in the validators-dir. Validators will need to be
manually added to the validator_definitions.yml file.
--disable-log-timestamp If present, do not include timestamps in logging output.
--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.
--disable-run-on-all
DEPRECATED. Use --broadcast. By default, Lighthouse publishes attestation, sync committee subscriptions and
proposer preparation messages to all beacon nodes provided in the `--beacon-nodes flag`. This option changes
that behaviour such that these api calls only go out to the first available and synced beacon node
--disable-slashing-protection-web3signer
Disable Lighthouse's slashing protection for all web3signer keys. This can reduce the I/O burden on the VC
but is only safe if slashing protection is enabled on the remote signer and is implemented correctly. DO NOT
ENABLE THIS FLAG UNLESS YOU ARE CERTAIN THAT SLASHING PROTECTION IS ENABLED ON THE REMOTE SIGNER. YOU WILL
GET SLASHED IF YOU USE THIS FLAG WITHOUT ENABLING WEB3SIGNER'S SLASHING PROTECTION.
--distributed
Enables functionality required for running the validator in a distributed validator cluster.
Options:
--beacon-nodes <NETWORK_ADDRESSES>
Comma-separated addresses to one or more beacon node HTTP APIs.
Default is http://localhost:5052.
--beacon-nodes-tls-certs <CERTIFICATE-FILES>
Comma-separated paths to custom TLS certificates to use when
connecting to a beacon node (and/or proposer node). These certificates
must be in PEM format and are used in addition to the OS trust store.
Commas must only be used as a delimiter, and must not be part of the
certificate path.
--broadcast <API_TOPICS>
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
-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 separate
custom datadirs for different networks.
--debug-level <LEVEL>
Specifies the verbosity level used when emitting logs to the terminal.
[default: info] [possible values: info, debug, trace, warn, error,
crit]
--gas-limit <INTEGER>
The gas limit to be used in all builder proposals for all validators
managed by this validator client. Note this will not necessarily be
used if the gas limit set here moves too far from the previous block's
gas limit. [default: 30,000,000]
--genesis-state-url <URL>
A URL of a beacon-API compatible server from which to download the
genesis state. Checkpoint sync server URLs can generally be used with
this flag. If not supplied, a default URL or the --checkpoint-sync-url
may be used. If the genesis state is already included in this binary
then this value will be ignored.
--genesis-state-url-timeout <SECONDS>
The timeout in seconds for the request to --genesis-state-url.
[default: 180]
--graffiti <GRAFFITI>
Specify your custom graffiti to be included in blocks.
--graffiti-file <GRAFFITI-FILE>
Specify a graffiti file to load validator graffitis from.
--http-address <ADDRESS>
Set the address for the HTTP address. The HTTP server is not encrypted
and therefore it is unsafe to publish on a public network. When this
flag is used, it additionally requires the explicit use of the
`--unencrypted-http-transport` flag to ensure the user is aware of the
risks involved. For access via the Internet, users should apply
transport-layer security like a HTTPS reverse-proxy or SSH tunnelling.
--http-allow-origin <ORIGIN>
Set the value of the Access-Control-Allow-Origin response HTTP header.
Use * to allow any origin (not recommended in production). If no value
is supplied, the CORS allowed origin is set to the listen address of
this server (e.g., http://localhost:5062).
--http-port <PORT>
Set the listen TCP port for the RESTful HTTP API server.
--log-format <FORMAT>
Specifies the log format used when emitting logs to the terminal.
[possible values: JSON]
--logfile <FILE>
File path where the log file will be stored. Once it grows to the
value specified in `--logfile-max-size` a new log file is generated
where future logs are stored. Once the number of log files exceeds the
value specified in `--logfile-max-number` the oldest log file will be
overwritten.
--logfile-debug-level <LEVEL>
The verbosity level used when emitting logs to the log file. [default:
debug] [possible values: info, debug, trace, warn, error, crit]
--logfile-format <FORMAT>
Specifies the log format used when emitting logs to the logfile.
[possible values: DEFAULT, JSON]
--logfile-max-number <COUNT>
The maximum number of log files that will be stored. If set to 0,
background file logging is disabled. [default: 5]
--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]
--metrics-address <ADDRESS>
Set the listen address for the Prometheus metrics HTTP server.
--metrics-allow-origin <ORIGIN>
Set the value of the Access-Control-Allow-Origin response HTTP header.
Use * to allow any origin (not recommended in production). If no value
is supplied, the CORS allowed origin is set to the listen address of
this server (e.g., http://localhost:5064).
--metrics-port <PORT>
Set the listen TCP port for the Prometheus metrics HTTP server.
--monitoring-endpoint <ADDRESS>
Enables the monitoring service for sending system metrics to a remote
endpoint. This can be used to monitor your setup on certain services
(e.g. beaconcha.in). This flag sets the endpoint where the beacon node
metrics will be sent. Note: This will send information to a remote
sever which may identify and associate your validators, IP address and
other personal information. Always use a HTTPS connection and never
provide an untrusted URL.
--monitoring-endpoint-period <SECONDS>
Defines how many seconds to wait between each message sent to the
monitoring-endpoint. Default: 60s
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible
values: mainnet, gnosis, chiado, sepolia, holesky]
--proposer-nodes <NETWORK_ADDRESSES>
Comma-separated addresses to one or more beacon node HTTP APIs. These
specify nodes that are used to send beacon block proposals. A failure
will revert back to the standard beacon nodes specified in
--beacon-nodes.
--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 this parameter in the event of an
attack at the PoS transition block. Incorrect use of this flag can
cause your node to possibly accept an invalid chain or sync more
slowly. Be extremely careful with this flag.
--secrets-dir <SECRETS_DIRECTORY>
The directory which contains the password to unlock the validator
voting keypairs. Each password should be contained in a file where the
name is the 0x-prefixed hex representation of the validators voting
public key. Defaults to ~/.lighthouse/{network}/secrets.
--suggested-fee-recipient <FEE-RECIPIENT>
Once the merge has happened, this address will receive transaction
fees from blocks proposed by this validator client. If a fee recipient
is configured in the validator definitions it takes priority over this
value.
-t, --testnet-dir <DIR>
Path to directory containing eth2_testnet specs. Defaults to a
hard-coded Lighthouse testnet. Only effective if there is no existing
database.
--terminal-block-hash-epoch-override <EPOCH>
Used to coordinate manual overrides to the
TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH parameter. This flag should only
be used if the user has a clear understanding that the broad Ethereum
community has elected to override the terminal PoW block. Incorrect
use of this flag will cause your node to experience a consensus
failure. Be extremely careful with this flag.
--terminal-block-hash-override <TERMINAL_BLOCK_HASH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH
parameter. This flag should only be used if the user has a clear
understanding that the broad Ethereum community has elected to
override the terminal PoW block. Incorrect use of this flag will cause
your node to experience a consensus failure. Be extremely careful with
this flag.
--terminal-total-difficulty-override <INTEGER>
Used to coordinate manual overrides to the TERMINAL_TOTAL_DIFFICULTY
parameter. Accepts a 256-bit decimal integer (not a hex value). This
flag should only be used if the user has a clear understanding that
the broad Ethereum community has elected to override the terminal
difficulty. Incorrect use of this flag will cause your node to
experience a consensus failure. Be extremely careful with this flag.
--validator-registration-batch-size <INTEGER>
Defines the number of validators per validator/register_validator
request sent to the BN. This value can be reduced to avoid timeouts
from builders. [default: 500]
--validators-dir <VALIDATORS_DIR>
The directory which contains the validator keystores, deposit data for
each validator along with the common slashing protection database and
the validator_definitions.yml
--web3-signer-keep-alive-timeout <MILLIS>
Keep-alive timeout for each web3signer connection. Set to 'null' to
never timeout [default: 20000]
--web3-signer-max-idle-connections <COUNT>
Maximum number of idle connections to maintain per web3signer host.
Default is unlimited.
--enable-doppelganger-protection
If this flag is set, Lighthouse will delay startup for three epochs and monitor for messages on the network
by any of the validators managed by this client. This will result in three (possibly four) epochs worth of
missed attestations. If an attestation is detected during this period, it means it is very likely that you
are running a second validator client with the same keys. This validator client will immediately shutdown if
this is detected in order to avoid potentially committing a slashable offense. Use this flag in order to
ENABLE this functionality, without this flag Lighthouse will begin attesting immediately.
--enable-high-validator-count-metrics
Enable per validator metrics for > 64 validators. Note: This flag is automatically enabled for <= 64
validators. Enabling this metric for higher validator counts will lead to higher volume of prometheus
metrics being collected.
-h, --help Prints help information
--http Enable the RESTful HTTP API server. Disabled by default.
--http-allow-keystore-export
If present, allow access to the DELETE /lighthouse/keystores HTTP API method, which allows exporting
keystores and passwords to HTTP API consumers who have access to the API token. This method is useful for
exporting validators, however it should be used with caution since it exposes private key data to authorized
users.
--http-store-passwords-in-secrets-dir
If present, any validators created via the HTTP will have keystore passwords stored in the secrets-dir
rather than the validator definitions file.
--init-slashing-protection
If present, do not require the slashing protection database to exist before running. You SHOULD NOT use this
flag unless you're certain that a new slashing protection database is required. Usually, your database will
have been initialized when you imported your validator keys. If you misplace your database and then run with
this flag you risk being slashed.
--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 store old logs.
--logfile-no-restricted-perms
If present, log files will be generated as world-readable meaning they can be read by any user on the
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
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.
--use-long-timeouts
If present, the validator client will use longer timeouts for requests made to the beacon node. This flag is
generally not recommended, longer timeouts can cause missed duties when fallbacks are used.
-V, --version Prints version information
OPTIONS:
--beacon-nodes <NETWORK_ADDRESSES>
Comma-separated addresses to one or more beacon node HTTP APIs. Default is http://localhost:5052.
--beacon-nodes-tls-certs <CERTIFICATE-FILES>
Comma-separated paths to custom TLS certificates to use when connecting to a beacon node (and/or proposer
node). These certificates must be in PEM format and are used in addition to the OS trust store. Commas must
only be used as a delimiter, and must not be part of the certificate path.
--broadcast <API_TOPICS>
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
-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
separate custom datadirs for different networks.
--debug-level <LEVEL>
Specifies the verbosity level used when emitting logs to the terminal. [default: info] [possible values:
info, debug, trace, warn, error, crit]
--gas-limit <INTEGER>
The gas limit to be used in all builder proposals for all validators managed by this validator client. Note
this will not necessarily be used if the gas limit set here moves too far from the previous block's gas
limit. [default: 30,000,000]
--genesis-state-url <URL>
A URL of a beacon-API compatible server from which to download the genesis state. Checkpoint sync server
URLs can generally be used with this flag. If not supplied, a default URL or the --checkpoint-sync-url may
be used. If the genesis state is already included in this binary then this value will be ignored.
--genesis-state-url-timeout <SECONDS>
The timeout in seconds for the request to --genesis-state-url. [default: 180]
--graffiti <GRAFFITI>
Specify your custom graffiti to be included in blocks.
--graffiti-file <GRAFFITI-FILE>
Specify a graffiti file to load validator graffitis from.
--http-address <ADDRESS>
Set the address for the HTTP address. The HTTP server is not encrypted and therefore it is unsafe to publish
on a public network. When this flag is used, it additionally requires the explicit use of the
`--unencrypted-http-transport` flag to ensure the user is aware of the risks involved. For access via the
Internet, users should apply transport-layer security like a HTTPS reverse-proxy or SSH tunnelling.
--http-allow-origin <ORIGIN>
Set the value of the Access-Control-Allow-Origin response HTTP header. Use * to allow any origin (not
recommended in production). If no value is supplied, the CORS allowed origin is set to the listen address of
this server (e.g., http://localhost:5062).
--http-port <PORT>
Set the listen TCP port for the RESTful HTTP API server.
--latency-measurement-service <BOOLEAN>
Set to 'true' to enable a service that periodically attempts to measure latency to BNs. Set to 'false' to
disable. [default: true]
--log-format <FORMAT>
Specifies the log format used when emitting logs to the terminal. [possible values: JSON]
--logfile <FILE>
File path where the log file will be stored. Once it grows to the value specified in `--logfile-max-size` a
new log file is generated where future logs are stored. Once the number of log files exceeds the value
specified in `--logfile-max-number` the oldest log file will be overwritten.
--logfile-debug-level <LEVEL>
The verbosity level used when emitting logs to the log file. [default: debug] [possible values: info,
debug, trace, warn, error, crit]
--logfile-format <FORMAT>
Specifies the log format used when emitting logs to the logfile. [possible values: DEFAULT, JSON]
--logfile-max-number <COUNT>
The maximum number of log files that will be stored. If set to 0, background file logging is disabled.
[default: 5]
--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]
--metrics-address <ADDRESS>
Set the listen address for the Prometheus metrics HTTP server.
--metrics-allow-origin <ORIGIN>
Set the value of the Access-Control-Allow-Origin response HTTP header. Use * to allow any origin (not
recommended in production). If no value is supplied, the CORS allowed origin is set to the listen address of
this server (e.g., http://localhost:5064).
--metrics-port <PORT>
Set the listen TCP port for the Prometheus metrics HTTP server.
--monitoring-endpoint <ADDRESS>
Enables the monitoring service for sending system metrics to a remote endpoint. This can be used to monitor
your setup on certain services (e.g. beaconcha.in). This flag sets the endpoint where the beacon node
metrics will be sent. Note: This will send information to a remote sever which may identify and associate
your validators, IP address and other personal information. Always use a HTTPS connection and never provide
an untrusted URL.
--monitoring-endpoint-period <SECONDS>
Defines how many seconds to wait between each message sent to the monitoring-endpoint. Default: 60s
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, gnosis, chiado, sepolia,
holesky]
--proposer-nodes <NETWORK_ADDRESSES>
Comma-separated addresses to one or more beacon node HTTP APIs. These specify nodes that are used to send
beacon block proposals. A failure will revert back to the standard beacon nodes specified in --beacon-nodes.
--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
this parameter in the event of an attack at the PoS transition block. Incorrect use of this flag can cause
your node to possibly accept an invalid chain or sync more slowly. Be extremely careful with this flag.
--secrets-dir <SECRETS_DIRECTORY>
The directory which contains the password to unlock the validator voting keypairs. Each password should be
contained in a file where the name is the 0x-prefixed hex representation of the validators voting public
key. Defaults to ~/.lighthouse/{network}/secrets.
--suggested-fee-recipient <FEE-RECIPIENT>
Once the merge has happened, this address will receive transaction fees from blocks proposed by this
validator client. If a fee recipient is configured in the validator definitions it takes priority over this
value.
--terminal-block-hash-epoch-override <EPOCH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH parameter. This flag should
only be used if the user has a clear understanding that the broad Ethereum community has elected to override
the terminal PoW block. Incorrect use of this flag will cause your node to experience a consensus failure.
Be extremely careful with this flag.
--terminal-block-hash-override <TERMINAL_BLOCK_HASH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH parameter. This flag should only be used if
the user has a clear understanding that the broad Ethereum community has elected to override the terminal
PoW block. Incorrect use of this flag will cause your node to experience a consensus failure. Be extremely
careful with this flag.
--terminal-total-difficulty-override <INTEGER>
Used to coordinate manual overrides to the TERMINAL_TOTAL_DIFFICULTY parameter. Accepts a 256-bit decimal
integer (not a hex value). This flag should only be used if the user has a clear understanding that the
broad Ethereum community has elected to override the terminal difficulty. Incorrect use of this flag will
cause your node to experience a consensus failure. Be extremely careful with this flag.
-t, --testnet-dir <DIR>
Path to directory containing eth2_testnet specs. Defaults to a hard-coded Lighthouse testnet. Only effective
if there is no existing database.
--validator-registration-batch-size <INTEGER>
Defines the number of validators per validator/register_validator request sent to the BN. This value can be
reduced to avoid timeouts from builders. [default: 500]
--validators-dir <VALIDATORS_DIR>
The directory which contains the validator keystores, deposit data for each validator along with the common
slashing protection database and the validator_definitions.yml
--web3-signer-keep-alive-timeout <MILLIS>
Keep-alive timeout for each web3signer connection. Set to 'null' to never timeout [default: 20000]
--web3-signer-max-idle-connections <COUNT>
Maximum number of idle connections to maintain per web3signer host. Default is unlimited.
Flags:
--builder-proposals
If this flag is set, Lighthouse will query the Beacon Node for only
block headers during proposals and will sign over headers. Useful for
outsourcing execution payload construction during proposals.
--disable-auto-discover
If present, do not attempt to discover new validators in the
validators-dir. Validators will need to be manually added to the
validator_definitions.yml file.
--disable-latency-measurement-service
Disables the service that periodically attempts to measure latency to
BNs.
--disable-log-timestamp
If present, do not include timestamps in logging output.
--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.
--disable-run-on-all
DEPRECATED. Use --broadcast. By default, Lighthouse publishes
attestation, sync committee subscriptions and proposer preparation
messages to all beacon nodes provided in the `--beacon-nodes flag`.
This option changes that behaviour such that these api calls only go
out to the first available and synced beacon node
--disable-slashing-protection-web3signer
Disable Lighthouse's slashing protection for all web3signer keys. This
can reduce the I/O burden on the VC but is only safe if slashing
protection is enabled on the remote signer and is implemented
correctly. DO NOT ENABLE THIS FLAG UNLESS YOU ARE CERTAIN THAT
SLASHING PROTECTION IS ENABLED ON THE REMOTE SIGNER. YOU WILL GET
SLASHED IF YOU USE THIS FLAG WITHOUT ENABLING WEB3SIGNER'S SLASHING
PROTECTION.
--distributed
Enables functionality required for running the validator in a
distributed validator cluster.
--enable-doppelganger-protection
If this flag is set, Lighthouse will delay startup for three epochs
and monitor for messages on the network by any of the validators
managed by this client. This will result in three (possibly four)
epochs worth of missed attestations. If an attestation is detected
during this period, it means it is very likely that you are running a
second validator client with the same keys. This validator client will
immediately shutdown if this is detected in order to avoid potentially
committing a slashable offense. Use this flag in order to ENABLE this
functionality, without this flag Lighthouse will begin attesting
immediately.
--enable-high-validator-count-metrics
Enable per validator metrics for > 64 validators. Note: This flag is
automatically enabled for <= 64 validators. Enabling this metric for
higher validator counts will lead to higher volume of prometheus
metrics being collected.
-h, --help
Prints help information
--http
Enable the RESTful HTTP API server. Disabled by default.
--http-allow-keystore-export
If present, allow access to the DELETE /lighthouse/keystores HTTP API
method, which allows exporting keystores and passwords to HTTP API
consumers who have access to the API token. This method is useful for
exporting validators, however it should be used with caution since it
exposes private key data to authorized users.
--http-store-passwords-in-secrets-dir
If present, any validators created via the HTTP will have keystore
passwords stored in the secrets-dir rather than the validator
definitions file.
--init-slashing-protection
If present, do not require the slashing protection database to exist
before running. You SHOULD NOT use this flag unless you're certain
that a new slashing protection database is required. Usually, your
database will have been initialized when you imported your validator
keys. If you misplace your database and then run with this flag you
risk being slashed.
--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 store old logs.
--logfile-no-restricted-perms
If present, log files will be generated as world-readable meaning they
can be read by any user on the 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 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.
--use-long-timeouts
If present, the validator client will use longer timeouts for requests
made to the beacon node. This flag is generally not recommended,
longer timeouts can cause missed duties when fallbacks are used.
```
<style> .content main {max-width:88%;} </style>

205
book/src/help_vm.md
View File

@@ -3,97 +3,126 @@
```
Utilities for managing a Lighthouse validator client via the HTTP API.
USAGE:
lighthouse validator_manager [FLAGS] [OPTIONS] [SUBCOMMAND]
Usage: lighthouse validator_manager [OPTIONS] [COMMAND]
FLAGS:
--disable-log-timestamp If present, do not include timestamps in logging output.
--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.
-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
store old logs.
--logfile-no-restricted-perms If present, log files will be generated as world-readable meaning they can be
read by any user on the 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.
-V, --version Prints version information
Commands:
create
Creates new validators from BIP-39 mnemonic. A JSON file will be
created which contains all the validator keystores and other validator
data. This file can then be imported to a validator client using the
"import-validators" command. Another, optional JSON file is created
which contains a list of validator deposits in the same format as the
"ethereum/staking-deposit-cli" tool.
import
Uploads validators to a validator client using the HTTP API. The
validators are defined in a JSON file which can be generated using the
"create-validators" command.
move
Uploads validators to a validator client using the HTTP API. The
validators are defined in a JSON file which can be generated using the
"create-validators" command. This command only supports validators
signing via a keystore on the local file system (i.e., not Web3Signer
validators).
help
Print this message or the help of the given subcommand(s)
OPTIONS:
-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
separate custom datadirs for different networks.
--debug-level <LEVEL>
Specifies the verbosity level used when emitting logs to the terminal. [default: info] [possible values:
info, debug, trace, warn, error, crit]
--genesis-state-url <URL>
A URL of a beacon-API compatible server from which to download the genesis state. Checkpoint sync server
URLs can generally be used with this flag. If not supplied, a default URL or the --checkpoint-sync-url may
be used. If the genesis state is already included in this binary then this value will be ignored.
--genesis-state-url-timeout <SECONDS>
The timeout in seconds for the request to --genesis-state-url. [default: 180]
Options:
-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 separate
custom datadirs for different networks.
--debug-level <LEVEL>
Specifies the verbosity level used when emitting logs to the terminal.
[default: info] [possible values: info, debug, trace, warn, error,
crit]
--genesis-state-url <URL>
A URL of a beacon-API compatible server from which to download the
genesis state. Checkpoint sync server URLs can generally be used with
this flag. If not supplied, a default URL or the --checkpoint-sync-url
may be used. If the genesis state is already included in this binary
then this value will be ignored.
--genesis-state-url-timeout <SECONDS>
The timeout in seconds for the request to --genesis-state-url.
[default: 180]
--log-format <FORMAT>
Specifies the log format used when emitting logs to the terminal.
[possible values: JSON]
--logfile <FILE>
File path where the log file will be stored. Once it grows to the
value specified in `--logfile-max-size` a new log file is generated
where future logs are stored. Once the number of log files exceeds the
value specified in `--logfile-max-number` the oldest log file will be
overwritten.
--logfile-debug-level <LEVEL>
The verbosity level used when emitting logs to the log file. [default:
debug] [possible values: info, debug, trace, warn, error, crit]
--logfile-format <FORMAT>
Specifies the log format used when emitting logs to the logfile.
[possible values: DEFAULT, JSON]
--logfile-max-number <COUNT>
The maximum number of log files that will be stored. If set to 0,
background file logging is disabled. [default: 5]
--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]
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible
values: mainnet, gnosis, chiado, sepolia, holesky]
--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 this parameter in the event of an
attack at the PoS transition block. Incorrect use of this flag can
cause your node to possibly accept an invalid chain or sync more
slowly. Be extremely careful with this flag.
-t, --testnet-dir <DIR>
Path to directory containing eth2_testnet specs. Defaults to a
hard-coded Lighthouse testnet. Only effective if there is no existing
database.
--terminal-block-hash-epoch-override <EPOCH>
Used to coordinate manual overrides to the
TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH parameter. This flag should only
be used if the user has a clear understanding that the broad Ethereum
community has elected to override the terminal PoW block. Incorrect
use of this flag will cause your node to experience a consensus
failure. Be extremely careful with this flag.
--terminal-block-hash-override <TERMINAL_BLOCK_HASH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH
parameter. This flag should only be used if the user has a clear
understanding that the broad Ethereum community has elected to
override the terminal PoW block. Incorrect use of this flag will cause
your node to experience a consensus failure. Be extremely careful with
this flag.
--terminal-total-difficulty-override <INTEGER>
Used to coordinate manual overrides to the TERMINAL_TOTAL_DIFFICULTY
parameter. Accepts a 256-bit decimal integer (not a hex value). This
flag should only be used if the user has a clear understanding that
the broad Ethereum community has elected to override the terminal
difficulty. Incorrect use of this flag will cause your node to
experience a consensus failure. Be extremely careful with this flag.
--log-format <FORMAT>
Specifies the log format used when emitting logs to the terminal. [possible values: JSON]
--logfile <FILE>
File path where the log file will be stored. Once it grows to the value specified in `--logfile-max-size` a
new log file is generated where future logs are stored. Once the number of log files exceeds the value
specified in `--logfile-max-number` the oldest log file will be overwritten.
--logfile-debug-level <LEVEL>
The verbosity level used when emitting logs to the log file. [default: debug] [possible values: info,
debug, trace, warn, error, crit]
--logfile-format <FORMAT>
Specifies the log format used when emitting logs to the logfile. [possible values: DEFAULT, JSON]
--logfile-max-number <COUNT>
The maximum number of log files that will be stored. If set to 0, background file logging is disabled.
[default: 5]
--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]
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, gnosis, chiado, sepolia,
holesky]
--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
this parameter in the event of an attack at the PoS transition block. Incorrect use of this flag can cause
your node to possibly accept an invalid chain or sync more slowly. Be extremely careful with this flag.
--terminal-block-hash-epoch-override <EPOCH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH parameter. This flag should
only be used if the user has a clear understanding that the broad Ethereum community has elected to override
the terminal PoW block. Incorrect use of this flag will cause your node to experience a consensus failure.
Be extremely careful with this flag.
--terminal-block-hash-override <TERMINAL_BLOCK_HASH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH parameter. This flag should only be used if
the user has a clear understanding that the broad Ethereum community has elected to override the terminal
PoW block. Incorrect use of this flag will cause your node to experience a consensus failure. Be extremely
careful with this flag.
--terminal-total-difficulty-override <INTEGER>
Used to coordinate manual overrides to the TERMINAL_TOTAL_DIFFICULTY parameter. Accepts a 256-bit decimal
integer (not a hex value). This flag should only be used if the user has a clear understanding that the
broad Ethereum community has elected to override the terminal difficulty. Incorrect use of this flag will
cause your node to experience a consensus failure. Be extremely careful with this flag.
-t, --testnet-dir <DIR>
Path to directory containing eth2_testnet specs. Defaults to a hard-coded Lighthouse testnet. Only effective
if there is no existing database.
SUBCOMMANDS:
create Creates new validators from BIP-39 mnemonic. A JSON file will be created which contains all the
validator keystores and other validator data. This file can then be imported to a validator client
using the "import-validators" command. Another, optional JSON file is created which contains a list of
validator deposits in the same format as the "ethereum/staking-deposit-cli" tool.
help Prints this message or the help of the given subcommand(s)
import Uploads validators to a validator client using the HTTP API. The validators are defined in a JSON file
which can be generated using the "create-validators" command.
move Uploads validators to a validator client using the HTTP API. The validators are defined in a JSON file
which can be generated using the "create-validators" command. This command only supports validators
signing via a keystore on the local file system (i.e., not Web3Signer validators).
Flags:
--disable-log-timestamp
If present, do not include timestamps in logging output.
--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.
-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 store old logs.
--logfile-no-restricted-perms
If present, log files will be generated as world-readable meaning they
can be read by any user on the 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.
```
<style> .content main {max-width:88%;} </style>

290
book/src/help_vm_create.md
View File

@@ -1,139 +1,169 @@
# Validator Manager Create
```
Creates new validators from BIP-39 mnemonic. A JSON file will be created which contains all the validator keystores and
other validator data. This file can then be imported to a validator client using the "import-validators" command.
Another, optional JSON file is created which contains a list of validator deposits in the same format as the
"ethereum/staking-deposit-cli" tool.
Creates new validators from BIP-39 mnemonic. A JSON file will be created which
contains all the validator keystores and other validator data. This file can
then be imported to a validator client using the "import-validators" command.
Another, optional JSON file is created which contains a list of validator
deposits in the same format as the "ethereum/staking-deposit-cli" tool.
USAGE:
lighthouse validator_manager create [FLAGS] [OPTIONS] --output-path <DIRECTORY>
Usage: lighthouse validator_manager create [OPTIONS] --output-path <DIRECTORY>
FLAGS:
--disable-deposits When provided don't generate the deposits JSON file that is commonly used
for submitting validator deposits via a web UI. Using this flag will save
several seconds per validator if the user has an alternate strategy for
submitting deposits.
--disable-log-timestamp If present, do not include timestamps in logging output.
--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.
--force-bls-withdrawal-credentials If present, allows BLS withdrawal credentials rather than an execution
address. This is not recommended.
-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 store old logs.
--logfile-no-restricted-perms If present, log files will be generated as world-readable meaning they can
be read by any user on the 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.
--specify-voting-keystore-password If present, the user will be prompted to enter the voting keystore
password that will be used to encrypt the voting keystores. If this flag
is not provided, a random password will be used. It is not necessary to
keep backups of voting keystore passwords if the mnemonic is safely backed
up.
--stdin-inputs If present, read all user inputs from stdin instead of tty.
-V, --version Prints version information
Options:
--beacon-node <HTTP_ADDRESS>
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]
--count <VALIDATOR_COUNT>
The number of validators to create, regardless of how many already
exist
-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 separate
custom datadirs for different networks.
--debug-level <LEVEL>
Specifies the verbosity level used when emitting logs to the terminal.
[default: info] [possible values: info, debug, trace, warn, error,
crit]
--deposit-gwei <DEPOSIT_GWEI>
The GWEI value of the deposit amount. Defaults to the minimum amount
required for an active validator (MAX_EFFECTIVE_BALANCE)
--eth1-withdrawal-address <ETH1_ADDRESS>
If this field is set, the given eth1 address will be used to create
the withdrawal credentials. Otherwise, it will generate withdrawal
credentials with the mnemonic-derived withdrawal public key in
EIP-2334 format.
--first-index <FIRST_INDEX>
The first of consecutive key indexes you wish to create. [default: 0]
--gas-limit <UINT64>
All created validators will use this gas limit. It is recommended to
leave this as the default value by not specifying this flag.
--genesis-state-url <URL>
A URL of a beacon-API compatible server from which to download the
genesis state. Checkpoint sync server URLs can generally be used with
this flag. If not supplied, a default URL or the --checkpoint-sync-url
may be used. If the genesis state is already included in this binary
then this value will be ignored.
--genesis-state-url-timeout <SECONDS>
The timeout in seconds for the request to --genesis-state-url.
[default: 180]
--log-format <FORMAT>
Specifies the log format used when emitting logs to the terminal.
[possible values: JSON]
--logfile <FILE>
File path where the log file will be stored. Once it grows to the
value specified in `--logfile-max-size` a new log file is generated
where future logs are stored. Once the number of log files exceeds the
value specified in `--logfile-max-number` the oldest log file will be
overwritten.
--logfile-debug-level <LEVEL>
The verbosity level used when emitting logs to the log file. [default:
debug] [possible values: info, debug, trace, warn, error, crit]
--logfile-format <FORMAT>
Specifies the log format used when emitting logs to the logfile.
[possible values: DEFAULT, JSON]
--logfile-max-number <COUNT>
The maximum number of log files that will be stored. If set to 0,
background file logging is disabled. [default: 5]
--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.
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible
values: mainnet, 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 this parameter in the event of an
attack at the PoS transition block. Incorrect use of this flag can
cause your node to possibly accept an invalid chain or sync more
slowly. Be extremely careful with this flag.
--suggested-fee-recipient <ETH1_ADDRESS>
All created validators will use this value for the suggested fee
recipient. Omit this flag to use the default value from the VC.
-t, --testnet-dir <DIR>
Path to directory containing eth2_testnet specs. Defaults to a
hard-coded Lighthouse testnet. Only effective if there is no existing
database.
--terminal-block-hash-epoch-override <EPOCH>
Used to coordinate manual overrides to the
TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH parameter. This flag should only
be used if the user has a clear understanding that the broad Ethereum
community has elected to override the terminal PoW block. Incorrect
use of this flag will cause your node to experience a consensus
failure. Be extremely careful with this flag.
--terminal-block-hash-override <TERMINAL_BLOCK_HASH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH
parameter. This flag should only be used if the user has a clear
understanding that the broad Ethereum community has elected to
override the terminal PoW block. Incorrect use of this flag will cause
your node to experience a consensus failure. Be extremely careful with
this flag.
--terminal-total-difficulty-override <INTEGER>
Used to coordinate manual overrides to the TERMINAL_TOTAL_DIFFICULTY
parameter. Accepts a 256-bit decimal integer (not a hex value). This
flag should only be used if the user has a clear understanding that
the broad Ethereum community has elected to override the terminal
difficulty. Incorrect use of this flag will cause your node to
experience a consensus failure. Be extremely careful with this flag.
OPTIONS:
--beacon-node <HTTP_ADDRESS>
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]
--count <VALIDATOR_COUNT>
The number of validators to create, regardless of how many already exist
-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
separate custom datadirs for different networks.
--debug-level <LEVEL>
Specifies the verbosity level used when emitting logs to the terminal. [default: info] [possible values:
info, debug, trace, warn, error, crit]
--deposit-gwei <DEPOSIT_GWEI>
The GWEI value of the deposit amount. Defaults to the minimum amount required for an active validator
(MAX_EFFECTIVE_BALANCE)
--eth1-withdrawal-address <ETH1_ADDRESS>
If this field is set, the given eth1 address will be used to create the withdrawal credentials. Otherwise,
it will generate withdrawal credentials with the mnemonic-derived withdrawal public key in EIP-2334 format.
--first-index <FIRST_INDEX>
The first of consecutive key indexes you wish to create. [default: 0]
--gas-limit <UINT64>
All created validators will use this gas limit. It is recommended to leave this as the default value by not
specifying this flag.
--genesis-state-url <URL>
A URL of a beacon-API compatible server from which to download the genesis state. Checkpoint sync server
URLs can generally be used with this flag. If not supplied, a default URL or the --checkpoint-sync-url may
be used. If the genesis state is already included in this binary then this value will be ignored.
--genesis-state-url-timeout <SECONDS>
The timeout in seconds for the request to --genesis-state-url. [default: 180]
--log-format <FORMAT>
Specifies the log format used when emitting logs to the terminal. [possible values: JSON]
--logfile <FILE>
File path where the log file will be stored. Once it grows to the value specified in `--logfile-max-size` a
new log file is generated where future logs are stored. Once the number of log files exceeds the value
specified in `--logfile-max-number` the oldest log file will be overwritten.
--logfile-debug-level <LEVEL>
The verbosity level used when emitting logs to the log file. [default: debug] [possible values: info,
debug, trace, warn, error, crit]
--logfile-format <FORMAT>
Specifies the log format used when emitting logs to the logfile. [possible values: DEFAULT, JSON]
--logfile-max-number <COUNT>
The maximum number of log files that will be stored. If set to 0, background file logging is disabled.
[default: 5]
--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.
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, 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
this parameter in the event of an attack at the PoS transition block. Incorrect use of this flag can cause
your node to possibly accept an invalid chain or sync more slowly. Be extremely careful with this flag.
--suggested-fee-recipient <ETH1_ADDRESS>
All created validators will use this value for the suggested fee recipient. Omit this flag to use the
default value from the VC.
--terminal-block-hash-epoch-override <EPOCH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH parameter. This flag should
only be used if the user has a clear understanding that the broad Ethereum community has elected to override
the terminal PoW block. Incorrect use of this flag will cause your node to experience a consensus failure.
Be extremely careful with this flag.
--terminal-block-hash-override <TERMINAL_BLOCK_HASH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH parameter. This flag should only be used if
the user has a clear understanding that the broad Ethereum community has elected to override the terminal
PoW block. Incorrect use of this flag will cause your node to experience a consensus failure. Be extremely
careful with this flag.
--terminal-total-difficulty-override <INTEGER>
Used to coordinate manual overrides to the TERMINAL_TOTAL_DIFFICULTY parameter. Accepts a 256-bit decimal
integer (not a hex value). This flag should only be used if the user has a clear understanding that the
broad Ethereum community has elected to override the terminal difficulty. Incorrect use of this flag will
cause your node to experience a consensus failure. Be extremely careful with this flag.
-t, --testnet-dir <DIR>
Path to directory containing eth2_testnet specs. Defaults to a hard-coded Lighthouse testnet. Only effective
if there is no existing database.
Flags:
--disable-deposits
When provided don't generate the deposits JSON file that is commonly
used for submitting validator deposits via a web UI. Using this flag
will save several seconds per validator if the user has an alternate
strategy for submitting deposits.
--disable-log-timestamp
If present, do not include timestamps in logging output.
--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.
--force-bls-withdrawal-credentials
If present, allows BLS withdrawal credentials rather than an execution
address. This is not recommended.
-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 store old logs.
--logfile-no-restricted-perms
If present, log files will be generated as world-readable meaning they
can be read by any user on the 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.
--specify-voting-keystore-password
If present, the user will be prompted to enter the voting keystore
password that will be used to encrypt the voting keystores. If this
flag is not provided, a random password will be used. It is not
necessary to keep backups of voting keystore passwords if the mnemonic
is safely backed up.
--stdin-inputs
If present, read all user inputs from stdin instead of tty.
```
<style> .content main {max-width:88%;} </style>

211
book/src/help_vm_import.md
View File

@@ -1,103 +1,126 @@
# Validator Manager Import
```
Uploads validators to a validator client using the HTTP API. The validators are defined in a JSON file which can be
generated using the "create-validators" command.
Uploads validators to a validator client using the HTTP API. The validators are
defined in a JSON file which can be generated using the "create-validators"
command.
USAGE:
lighthouse validator_manager import [FLAGS] [OPTIONS] --validators-file <PATH_TO_JSON_FILE>
Usage: lighthouse validator_manager import [OPTIONS] --validators-file <PATH_TO_JSON_FILE>
FLAGS:
--disable-log-timestamp If present, do not include timestamps in logging output.
--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.
-h, --help Prints help information
--ignore-duplicates If present, ignore any validators which already exist on the VC. Without this
flag, the process will terminate without making any changes. This flag should
be used with caution, whilst it does not directly cause slashable conditions,
it might be an indicator that something is amiss. Users should also be careful
to avoid submitting duplicate deposits for validators that already exist on the
VC.
--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
store old logs.
--logfile-no-restricted-perms If present, log files will be generated as world-readable meaning they can be
read by any user on the 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.
-V, --version Prints version information
Options:
-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 separate
custom datadirs for different networks.
--debug-level <LEVEL>
Specifies the verbosity level used when emitting logs to the terminal.
[default: info] [possible values: info, debug, trace, warn, error,
crit]
--genesis-state-url <URL>
A URL of a beacon-API compatible server from which to download the
genesis state. Checkpoint sync server URLs can generally be used with
this flag. If not supplied, a default URL or the --checkpoint-sync-url
may be used. If the genesis state is already included in this binary
then this value will be ignored.
--genesis-state-url-timeout <SECONDS>
The timeout in seconds for the request to --genesis-state-url.
[default: 180]
--log-format <FORMAT>
Specifies the log format used when emitting logs to the terminal.
[possible values: JSON]
--logfile <FILE>
File path where the log file will be stored. Once it grows to the
value specified in `--logfile-max-size` a new log file is generated
where future logs are stored. Once the number of log files exceeds the
value specified in `--logfile-max-number` the oldest log file will be
overwritten.
--logfile-debug-level <LEVEL>
The verbosity level used when emitting logs to the log file. [default:
debug] [possible values: info, debug, trace, warn, error, crit]
--logfile-format <FORMAT>
Specifies the log format used when emitting logs to the logfile.
[possible values: DEFAULT, JSON]
--logfile-max-number <COUNT>
The maximum number of log files that will be stored. If set to 0,
background file logging is disabled. [default: 5]
--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]
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible
values: mainnet, gnosis, chiado, sepolia, holesky]
--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 this parameter in the event of an
attack at the PoS transition block. Incorrect use of this flag can
cause your node to possibly accept an invalid chain or sync more
slowly. Be extremely careful with this flag.
-t, --testnet-dir <DIR>
Path to directory containing eth2_testnet specs. Defaults to a
hard-coded Lighthouse testnet. Only effective if there is no existing
database.
--terminal-block-hash-epoch-override <EPOCH>
Used to coordinate manual overrides to the
TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH parameter. This flag should only
be used if the user has a clear understanding that the broad Ethereum
community has elected to override the terminal PoW block. Incorrect
use of this flag will cause your node to experience a consensus
failure. Be extremely careful with this flag.
--terminal-block-hash-override <TERMINAL_BLOCK_HASH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH
parameter. This flag should only be used if the user has a clear
understanding that the broad Ethereum community has elected to
override the terminal PoW block. Incorrect use of this flag will cause
your node to experience a consensus failure. Be extremely careful with
this flag.
--terminal-total-difficulty-override <INTEGER>
Used to coordinate manual overrides to the TERMINAL_TOTAL_DIFFICULTY
parameter. Accepts a 256-bit decimal integer (not a hex value). This
flag should only be used if the user has a clear understanding that
the broad Ethereum community has elected to override the terminal
difficulty. Incorrect use of this flag will cause your node to
experience a consensus failure. Be extremely careful with this flag.
--validators-file <PATH_TO_JSON_FILE>
The path to a JSON file containing a list of validators to be imported
to the validator client. This file is usually named "validators.json".
--vc-token <PATH>
The file containing a token required by the validator client.
--vc-url <HTTP_ADDRESS>
A HTTP(S) address of a validator client using the keymanager-API. If
this value is not supplied then a 'dry run' will be conducted where no
changes are made to the validator client. [default:
http://localhost:5062]
OPTIONS:
-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
separate custom datadirs for different networks.
--debug-level <LEVEL>
Specifies the verbosity level used when emitting logs to the terminal. [default: info] [possible values:
info, debug, trace, warn, error, crit]
--genesis-state-url <URL>
A URL of a beacon-API compatible server from which to download the genesis state. Checkpoint sync server
URLs can generally be used with this flag. If not supplied, a default URL or the --checkpoint-sync-url may
be used. If the genesis state is already included in this binary then this value will be ignored.
--genesis-state-url-timeout <SECONDS>
The timeout in seconds for the request to --genesis-state-url. [default: 180]
--log-format <FORMAT>
Specifies the log format used when emitting logs to the terminal. [possible values: JSON]
--logfile <FILE>
File path where the log file will be stored. Once it grows to the value specified in `--logfile-max-size` a
new log file is generated where future logs are stored. Once the number of log files exceeds the value
specified in `--logfile-max-number` the oldest log file will be overwritten.
--logfile-debug-level <LEVEL>
The verbosity level used when emitting logs to the log file. [default: debug] [possible values: info,
debug, trace, warn, error, crit]
--logfile-format <FORMAT>
Specifies the log format used when emitting logs to the logfile. [possible values: DEFAULT, JSON]
--logfile-max-number <COUNT>
The maximum number of log files that will be stored. If set to 0, background file logging is disabled.
[default: 5]
--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]
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, gnosis, chiado, sepolia,
holesky]
--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
this parameter in the event of an attack at the PoS transition block. Incorrect use of this flag can cause
your node to possibly accept an invalid chain or sync more slowly. Be extremely careful with this flag.
--terminal-block-hash-epoch-override <EPOCH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH parameter. This flag should
only be used if the user has a clear understanding that the broad Ethereum community has elected to override
the terminal PoW block. Incorrect use of this flag will cause your node to experience a consensus failure.
Be extremely careful with this flag.
--terminal-block-hash-override <TERMINAL_BLOCK_HASH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH parameter. This flag should only be used if
the user has a clear understanding that the broad Ethereum community has elected to override the terminal
PoW block. Incorrect use of this flag will cause your node to experience a consensus failure. Be extremely
careful with this flag.
--terminal-total-difficulty-override <INTEGER>
Used to coordinate manual overrides to the TERMINAL_TOTAL_DIFFICULTY parameter. Accepts a 256-bit decimal
integer (not a hex value). This flag should only be used if the user has a clear understanding that the
broad Ethereum community has elected to override the terminal difficulty. Incorrect use of this flag will
cause your node to experience a consensus failure. Be extremely careful with this flag.
-t, --testnet-dir <DIR>
Path to directory containing eth2_testnet specs. Defaults to a hard-coded Lighthouse testnet. Only effective
if there is no existing database.
--validators-file <PATH_TO_JSON_FILE>
The path to a JSON file containing a list of validators to be imported to the validator client. This file is
usually named "validators.json".
--vc-token <PATH>
The file containing a token required by the validator client.
--vc-url <HTTP_ADDRESS>
A HTTP(S) address of a validator client using the keymanager-API. If this value is not supplied then a 'dry
run' will be conducted where no changes are made to the validator client. [default: http://localhost:5062]
Flags:
--disable-log-timestamp
If present, do not include timestamps in logging output.
--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.
-h, --help
Prints help information
--ignore-duplicates
If present, ignore any validators which already exist on the VC.
Without this flag, the process will terminate without making any
changes. This flag should be used with caution, whilst it does not
directly cause slashable conditions, it might be an indicator that
something is amiss. Users should also be careful to avoid submitting
duplicate deposits for validators that already exist on the VC.
--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 store old logs.
--logfile-no-restricted-perms
If present, log files will be generated as world-readable meaning they
can be read by any user on the 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.
```
<style> .content main {max-width:88%;} </style>

247
book/src/help_vm_move.md
View File

@@ -1,120 +1,147 @@
# Validator Manager Move
```
Uploads validators to a validator client using the HTTP API. The validators are defined in a JSON file which can be
generated using the "create-validators" command. This command only supports validators signing via a keystore on the
Uploads validators to a validator client using the HTTP API. The validators are
defined in a JSON file which can be generated using the "create-validators"
command. This command only supports validators signing via a keystore on the
local file system (i.e., not Web3Signer validators).
USAGE:
lighthouse validator_manager move [FLAGS] [OPTIONS] --dest-vc-token <PATH> --dest-vc-url <HTTP_ADDRESS> --src-vc-token <PATH> --src-vc-url <HTTP_ADDRESS>
Usage: lighthouse validator_manager move [OPTIONS] --src-vc-token <PATH> --src-vc-url <HTTP_ADDRESS> --dest-vc-token <PATH> --dest-vc-url <HTTP_ADDRESS>
FLAGS:
--disable-log-timestamp If present, do not include timestamps in logging output.
--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.
-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
store old logs.
--logfile-no-restricted-perms If present, log files will be generated as world-readable meaning they can be
read by any user on the 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.
--stdin-inputs If present, read all user inputs from stdin instead of tty.
-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.
-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 separate
custom datadirs for different networks.
--debug-level <LEVEL>
Specifies the verbosity level used when emitting logs to the terminal.
[default: info] [possible values: info, debug, trace, warn, error,
crit]
--dest-vc-token <PATH>
The file containing a token required by the destination validator
client.
--dest-vc-url <HTTP_ADDRESS>
A HTTP(S) address of a validator client using the keymanager-API. This
validator client is the "destination" and will have new validators
added as they are removed from the "source" validator client.
--gas-limit <UINT64>
All created validators will use this gas limit. It is recommended to
leave this as the default value by not specifying this flag.
--genesis-state-url <URL>
A URL of a beacon-API compatible server from which to download the
genesis state. Checkpoint sync server URLs can generally be used with
this flag. If not supplied, a default URL or the --checkpoint-sync-url
may be used. If the genesis state is already included in this binary
then this value will be ignored.
--genesis-state-url-timeout <SECONDS>
The timeout in seconds for the request to --genesis-state-url.
[default: 180]
--log-format <FORMAT>
Specifies the log format used when emitting logs to the terminal.
[possible values: JSON]
--logfile <FILE>
File path where the log file will be stored. Once it grows to the
value specified in `--logfile-max-size` a new log file is generated
where future logs are stored. Once the number of log files exceeds the
value specified in `--logfile-max-number` the oldest log file will be
overwritten.
--logfile-debug-level <LEVEL>
The verbosity level used when emitting logs to the log file. [default:
debug] [possible values: info, debug, trace, warn, error, crit]
--logfile-format <FORMAT>
Specifies the log format used when emitting logs to the logfile.
[possible values: DEFAULT, JSON]
--logfile-max-number <COUNT>
The maximum number of log files that will be stored. If set to 0,
background file logging is disabled. [default: 5]
--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]
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible
values: mainnet, 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 this parameter in the event of an
attack at the PoS transition block. Incorrect use of this flag can
cause your node to possibly accept an invalid chain or sync more
slowly. Be extremely careful with this flag.
--src-vc-token <PATH>
The file containing a token required by the source validator client.
--src-vc-url <HTTP_ADDRESS>
A HTTP(S) address of a validator client using the keymanager-API. This
validator client is the "source" and contains the validators that are
to be moved.
--stdin-inputs
If present, read all user inputs from stdin instead of tty.
--suggested-fee-recipient <ETH1_ADDRESS>
All created validators will use this value for the suggested fee
recipient. Omit this flag to use the default value from the VC.
-t, --testnet-dir <DIR>
Path to directory containing eth2_testnet specs. Defaults to a
hard-coded Lighthouse testnet. Only effective if there is no existing
database.
--terminal-block-hash-epoch-override <EPOCH>
Used to coordinate manual overrides to the
TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH parameter. This flag should only
be used if the user has a clear understanding that the broad Ethereum
community has elected to override the terminal PoW block. Incorrect
use of this flag will cause your node to experience a consensus
failure. Be extremely careful with this flag.
--terminal-block-hash-override <TERMINAL_BLOCK_HASH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH
parameter. This flag should only be used if the user has a clear
understanding that the broad Ethereum community has elected to
override the terminal PoW block. Incorrect use of this flag will cause
your node to experience a consensus failure. Be extremely careful with
this flag.
--terminal-total-difficulty-override <INTEGER>
Used to coordinate manual overrides to the TERMINAL_TOTAL_DIFFICULTY
parameter. Accepts a 256-bit decimal integer (not a hex value). This
flag should only be used if the user has a clear understanding that
the broad Ethereum community has elected to override the terminal
difficulty. Incorrect use of this flag will cause your node to
experience a consensus failure. Be extremely careful with this flag.
--validators <STRING>
The validators to be moved. Either a list of 0x-prefixed validator
pubkeys or the keyword "all".
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.
-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
separate custom datadirs for different networks.
--debug-level <LEVEL>
Specifies the verbosity level used when emitting logs to the terminal. [default: info] [possible values:
info, debug, trace, warn, error, crit]
--dest-vc-token <PATH>
The file containing a token required by the destination validator client.
--dest-vc-url <HTTP_ADDRESS>
A HTTP(S) address of a validator client using the keymanager-API. This validator client is the "destination"
and will have new validators added as they are removed from the "source" validator client.
--gas-limit <UINT64>
All created validators will use this gas limit. It is recommended to leave this as the default value by not
specifying this flag.
--genesis-state-url <URL>
A URL of a beacon-API compatible server from which to download the genesis state. Checkpoint sync server
URLs can generally be used with this flag. If not supplied, a default URL or the --checkpoint-sync-url may
be used. If the genesis state is already included in this binary then this value will be ignored.
--genesis-state-url-timeout <SECONDS>
The timeout in seconds for the request to --genesis-state-url. [default: 180]
--log-format <FORMAT>
Specifies the log format used when emitting logs to the terminal. [possible values: JSON]
--logfile <FILE>
File path where the log file will be stored. Once it grows to the value specified in `--logfile-max-size` a
new log file is generated where future logs are stored. Once the number of log files exceeds the value
specified in `--logfile-max-number` the oldest log file will be overwritten.
--logfile-debug-level <LEVEL>
The verbosity level used when emitting logs to the log file. [default: debug] [possible values: info,
debug, trace, warn, error, crit]
--logfile-format <FORMAT>
Specifies the log format used when emitting logs to the logfile. [possible values: DEFAULT, JSON]
--logfile-max-number <COUNT>
The maximum number of log files that will be stored. If set to 0, background file logging is disabled.
[default: 5]
--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]
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, 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
this parameter in the event of an attack at the PoS transition block. Incorrect use of this flag can cause
your node to possibly accept an invalid chain or sync more slowly. Be extremely careful with this flag.
--src-vc-token <PATH>
The file containing a token required by the source validator client.
--src-vc-url <HTTP_ADDRESS>
A HTTP(S) address of a validator client using the keymanager-API. This validator client is the "source" and
contains the validators that are to be moved.
--suggested-fee-recipient <ETH1_ADDRESS>
All created validators will use this value for the suggested fee recipient. Omit this flag to use the
default value from the VC.
--terminal-block-hash-epoch-override <EPOCH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH parameter. This flag should
only be used if the user has a clear understanding that the broad Ethereum community has elected to override
the terminal PoW block. Incorrect use of this flag will cause your node to experience a consensus failure.
Be extremely careful with this flag.
--terminal-block-hash-override <TERMINAL_BLOCK_HASH>
Used to coordinate manual overrides to the TERMINAL_BLOCK_HASH parameter. This flag should only be used if
the user has a clear understanding that the broad Ethereum community has elected to override the terminal
PoW block. Incorrect use of this flag will cause your node to experience a consensus failure. Be extremely
careful with this flag.
--terminal-total-difficulty-override <INTEGER>
Used to coordinate manual overrides to the TERMINAL_TOTAL_DIFFICULTY parameter. Accepts a 256-bit decimal
integer (not a hex value). This flag should only be used if the user has a clear understanding that the
broad Ethereum community has elected to override the terminal difficulty. Incorrect use of this flag will
cause your node to experience a consensus failure. Be extremely careful with this flag.
-t, --testnet-dir <DIR>
Path to directory containing eth2_testnet specs. Defaults to a hard-coded Lighthouse testnet. Only effective
if there is no existing database.
--validators <STRING>
The validators to be moved. Either a list of 0x-prefixed validator pubkeys or the keyword "all".
Flags:
--disable-log-timestamp
If present, do not include timestamps in logging output.
--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.
-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 store old logs.
--logfile-no-restricted-perms
If present, log files will be generated as world-readable meaning they
can be read by any user on the 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.
```
<style> .content main {max-width:88%;} </style>