mirror of
https://github.com/sigp/lighthouse.git
synced 2026-04-20 22:38:34 +00:00
upgrade clap to v4.5 (#5273)
* 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:
@@ -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>
|
||||
|
||||
Reference in New Issue
Block a user