gnosis/lighthouse
1
0
Fork 0
mirror of https://github.com/sigp/lighthouse.git synced 2026-06-29 10:54:24 +00:00
Code Issues Packages Projects Releases Wiki Activity

Change --testnet flag to --network (#1751)

Browse Source 
## Issue Addressed

- Resolves #1689

## Proposed Changes

TBC

## Additional Info

NA
This commit is contained in:
Paul Hauner
2020-11-23 23:54:03 +00:00
parent 7d644103c6
commit 21617aa87f
28 changed files with 110 additions and 128 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
book/src/api-vc-auth-header.md
View File

@@ -22,7 +22,7 @@ The API token can be obtained via two methods:
### Method 1: Reading from a file
The API token is stored as a file in the `validators` directory. For most users
this is `~/.lighthouse/{testnet}/validators/api-token.txt`. Here's an
this is `~/.lighthouse/{network}/validators/api-token.txt`. Here's an
example using the `cat` command to print the token to the terminal, but any
text editor will suffice:

4
book/src/docker.md
View File

@@ -67,10 +67,10 @@ $ docker run lighthouse:local lighthouse --help
You can run a Docker beacon node with the following command:
```bash
$ docker run -p 9000:9000 -p 127.0.0.1:5052:5052 -v $HOME/.lighthouse:/root/.lighthouse sigp/lighthouse lighthouse --testnet medalla beacon --http --http-address 0.0.0.0
$ docker run -p 9000:9000 -p 127.0.0.1:5052:5052 -v $HOME/.lighthouse:/root/.lighthouse sigp/lighthouse lighthouse --network medalla beacon --http --http-address 0.0.0.0
```
> To join the altona testnet, use --testnet altona instead.
> To join the altona testnet, use --network altona instead.
> The `-p` and `-v` and values are described below.

14
book/src/key-management.md
View File

@@ -42,12 +42,12 @@ keypairs. Creating a single validator looks like this:
- `lighthouse --testnet medalla account validator create --wallet-name wally --wallet-password wally.pass --count 1`
In step (1), we created a wallet in `~/.lighthouse/{testnet}/wallets` with the name
In step (1), we created a wallet in `~/.lighthouse/{network}/wallets` with the name
`wally`. We encrypted this using a pre-defined password in the
`wally.pass` file. Then, in step (2), we created one new validator in the
`~/.lighthouse/{testnet}/validators` directory using `wally` (unlocking it with
`~/.lighthouse/{network}/validators` directory using `wally` (unlocking it with
`wally.pass`) and storing the passwords to the validators voting key in
`~/.lighthouse/{testnet}/secrets`.
`~/.lighthouse/{network}/secrets`.
Thanks to the hierarchical key derivation scheme, we can delete all of the
aforementioned directories and then regenerate them as long as we remembered
@@ -65,16 +65,16 @@ There are three important directories in Lighthouse validator key management:
- `wallets/`: contains encrypted wallets which are used for hierarchical
key derivation.
- Defaults to `~/.lighthouse/{testnet}/wallets`
- Defaults to `~/.lighthouse/{network}/wallets`
- `validators/`: contains a directory for each validator containing
encrypted keystores and other validator-specific data.
- Defaults to `~/.lighthouse/{testnet}/validators`
- Defaults to `~/.lighthouse/{network}/validators`
- `secrets/`: since the validator signing keys are "hot", the validator process
needs access to the passwords to decrypt the keystores in the validators
dir. These passwords are stored here.
- Defaults to `~/.lighthouse/{testnet}/secrets`
- Defaults to `~/.lighthouse/{network}/secrets`
where `testnet` is the name of the testnet passed in the `--testnet` parameter (default is `medalla`).
where `network` is the name of the network passed in the `--network` parameter (default is `medalla`).
When the validator client boots, it searches the `validators/` for directories
containing voting keystores. When it discovers a keystore, it searches the

8
book/src/pi.md
View File

@@ -50,9 +50,11 @@ cd lighthouse
make
```
Compiling Lighthouse can take up to an hour. The safety guarantees provided by
the Rust language unfortunately result in a lengthy compilation time on a
low-spec CPU like a Raspberry Pi.
>
> Compiling Lighthouse can take up to an hour. The safety guarantees provided by the Rust language
unfortunately result in a lengthy compilation time on a low-spec CPU like a Raspberry Pi. For faster
compilation on low-spec hardware, try [cross-compiling](./cross-compiling.md) on a more powerful
computer (e.g., compile for RasPi from your desktop computer).
Once installation has finished, confirm Lighthouse is installed by viewing the
usage instructions with `lighthouse --help`.

39
book/src/testnet-validator.md
View File

@@ -9,25 +9,26 @@ DEPOSITS WITH LIGHTHOUSE. 🚨🚨🚨**
## Supported Testnets
Lighthouse supports four testnets:
Lighthouse supports the "mainnet" network and four test networks:
- [Medalla](https://github.com/goerli/medalla/tree/master/medalla) (default)
- [Pyrmont](https://github.com/protolambda/pyrmont)
- [Spadina](https://github.com/goerli/medalla/tree/master/spadina) (deprecated)
- [Altona](https://github.com/goerli/medalla/tree/master/altona) (deprecated)
When using Lighthouse, the `--testnet` flag selects a testnet. E.g.,
When using Lighthouse, the `--network` flag selects a network. E.g.,
- `lighthouse` (no flag): Medalla.
- `lighthouse --testnet medalla`: Medalla.
- `lighthouse --testnet pyrmont`: Pyrmont.
- `lighthouse --network mainnet`: Mainnet.
- `lighthouse --network medalla`: Medalla.
- `lighthouse --network pyrmont`: Pyrmont.
Using the correct `--testnet` flag is very important; using the wrong flag can
Using the correct `--network` flag is very important; using the wrong flag can
result in penalties, slashings or lost deposits. As a rule of thumb, always
provide a `--testnet` flag instead of relying on the default.
provide a `--network` flag instead of relying on the default.
> Note: In these documents we use `--testnet MY_TESTNET` for demonstration. You
> must replace `MY_TESTNET` with a valid testnet name.
> Note: In these documents we use `--network MY_NETWORK` for demonstration. You
> must replace `MY_NETWORK` with a valid network name. E.g., `--network pyrmont`.
## Joining a Testnet
@@ -112,14 +113,14 @@ Starting these processes is different for binary and docker users:
Those using the pre- or custom-built binaries can start the two processes with:
```bash
lighthouse --testnet MY_TESTNET bn --staking
lighthouse --network MY_NETWORK bn --staking
```
```bash
lighthouse --testnet MY_TESTNET vc
lighthouse --network MY_NETWORK vc
```
> Note: `~/.lighthouse/{testnet}` is the default directory which contains the keys and databases.
> Note: `~/.lighthouse/{network}` is the default directory which contains the keys and databases.
> To specify a custom dir, see [this](#custom-directories) section
#### Docker users
@@ -130,7 +131,7 @@ Those using Docker images can start the processes with:
$ docker run \
--network host \
-v $HOME/.lighthouse:/root/.lighthouse sigp/lighthouse \
lighthouse --testnet MY_TESTNET bn --staking --http-address 0.0.0.0
lighthouse --network MY_NETWORK bn --staking --http-address 0.0.0.0
```
```bash
@@ -138,7 +139,7 @@ $ docker run \
--network host \
-v $HOME/.lighthouse:/root/.lighthouse \
sigp/lighthouse \
lighthouse --testnet MY_TESTNET vc
lighthouse --network MY_NETWORK vc
```
### Step 6. Leave Lighthouse running
@@ -171,16 +172,16 @@ Happy staking!
## Custom directories
Users can override the default Lighthouse data directories (`~/.lighthouse/{testnet}`) using the `--datadir` flag. The custom data directory mirrors the structure of any testnet specific default directory (e.g. `~/.lighthouse/medalla`).
Users can override the default Lighthouse data directories (`~/.lighthouse/{network}`) using the `--datadir` flag. The custom data directory mirrors the structure of any network specific default directory (e.g. `~/.lighthouse/medalla`).
> Note: Users should specify different custom directories for different testnets.
> Note: Users should specify different custom directories for different networks.
Below is an example flow for importing validator keys, running a beacon node and validator client using a custom data directory `/var/lib/my-custom-dir` for the medalla testnet.
```bash
lighthouse --testnet medalla --datadir /var/lib/my-custom-dir account validator import --directory <PATH-TO-LAUNCHPAD-KEYS-DIRECTORY>
lighthouse --testnet medalla --datadir /var/lib/my-custom-dir bn --staking
lighthouse --testnet medalla --datadir /var/lib/my-custom-dir vc
lighthouse --network medalla --datadir /var/lib/my-custom-dir account validator import --directory <PATH-TO-LAUNCHPAD-KEYS-DIRECTORY>
lighthouse --network medalla --datadir /var/lib/my-custom-dir bn --staking
lighthouse --network medalla --datadir /var/lib/my-custom-dir vc
```
The first step creates a `validators` directory under `/var/lib/my-custom-dir` which contains the imported keys and [`validator_definitions.yml`](./validator-management.md).
After that, we simply run the beacon chain and validator client with the custom dir path.
After that, we simply run the beacon chain and validator client with the custom dir path.

39
book/src/validator-create.md
View File

@@ -21,10 +21,11 @@ lighthouse account validator create --help
Creates new validators from an existing EIP-2386 wallet using the EIP-2333 HD key derivation scheme.
USAGE:
lighthouse account_manager validator create [FLAGS] [OPTIONS] --wallet-name <WALLET_NAME> --wallet-password <WALLET_PASSWORD_PATH>
lighthouse account_manager validator create [FLAGS] [OPTIONS]
FLAGS:
-h, --help Prints help information
--stdin-inputs If present, read all user inputs from stdin instead of tty.
--store-withdrawal-keystore If present, the withdrawal keystore will be stored alongside the voting keypair.
It is generally recommended to *not* store the withdrawal key and instead
generate them from the wallet seed when required.
@@ -37,28 +38,34 @@ OPTIONS:
--count <VALIDATOR_COUNT>
The number of validators to create, regardless of how many already exist
-d, --datadir <DIR> Data directory for lighthouse keys and databases.
-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>
The verbosity level for emitting logs. [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)
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [default: mainnet] [possible values: medalla,
altona, spadina, pyrmont, mainnet, toledo]
--secrets-dir <SECRETS_DIR>
The path where the validator keystore passwords will be stored. Defaults to ~/.lighthouse/{testnet}/secrets
--testnet <testnet>
Name of network lighthouse will connect to [possible values: medalla, altona]
The path where the validator keystore passwords will be stored. Defaults to ~/.lighthouse/{network}/secrets
-s, --spec <DEPRECATED>
This flag is deprecated, it will be disallowed in a future release. This value is now derived from the
--network or --testnet-dir flags.
-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-dir <VALIDATOR_DIRECTORY>
The path where the validator directories will be created. Defaults to ~/.lighthouse/{testnet}/validators
--wallet-name <WALLET_NAME> Use the wallet identified by this name
--wallet-name <WALLET_NAME> Use the wallet identified by this name
--wallet-password <WALLET_PASSWORD_PATH>
A path to a file containing the password which will unlock the wallet.
--wallets-dir <wallets-dir>
A path containing Eth2 EIP-2386 wallets. Defaults to ~/.lighthouse/{network}/wallets
```
## Example
@@ -67,19 +74,17 @@ The example assumes that the `wally` wallet was generated from the
[wallet](./wallet-create.md) example.
```bash
lighthouse --testnet medalla account validator create --name wally --wallet-password wally.pass --count 1
lighthouse --network medalla account validator create --name wally --wallet-password wally.pass --count 1
```
This command will:
- Derive a single new BLS keypair from wallet `wally` in `~/.lighthouse/{testnet}/wallets`, updating it so that it generates a
new key next time.
- Create a new directory in `~/.lighthouse/{testnet}/validators` containing:
- Create a new directory in `~/.lighthouse/{network}/validators` containing:
- An encrypted keystore containing the validators voting keypair.
- An `eth1_deposit_data.rlp` assuming the default deposit amount (`32 ETH`
for most testnets and mainnet) which can be submitted to the deposit
contract for the medalla testnet. Other testnets can be set via the
`--testnet` CLI param.
- Store a password to the validators voting keypair in `~/.lighthouse/{testnet}/secrets`.
where `testnet` is the name of the testnet passed in the `--testnet` parameter (default is `medalla`).
contract for the Medalla testnet. Other testnets can be set via the
`--network` CLI param.
- Store a password to the validators voting keypair in `~/.lighthouse/{network}/secrets`.

4
book/src/validator-import-launchpad.md
View File

@@ -35,7 +35,7 @@ section, all other users can use:
```bash
lighthouse --testnet medalla account validator import --directory validator_keys
lighthouse --network medalla account validator import --directory validator_keys
```
Note: The user must specify the testnet that they are importing the keys for using the `--testnet` flag.
@@ -101,7 +101,7 @@ docker run -it \
-v $HOME/.lighthouse:/root/.lighthouse \
-v $(pwd)/validator_keys:/root/validator_keys \
sigp/lighthouse \
lighthouse --testnet medalla account validator import --directory /root/validator_keys
lighthouse --network MY_NETWORK account validator import --directory /root/validator_keys
```
Here we use two `-v` volumes to attach:

6
book/src/validator-management.md
View File

@@ -16,7 +16,7 @@ useful.
## Introducing the `validator_definitions.yml` file
The `validator_definitions.yml` file is located in the `validator-dir`, which
defaults to `~/.lighthouse/{testnet}/validators`. It is a
defaults to `~/.lighthouse/{network}/validators`. It is a
[YAML](https://en.wikipedia.org/wiki/YAML) encoded file defining exactly which
validators the validator client will (and won't) act for.
@@ -92,7 +92,7 @@ name identical to the `voting_public_key` value.
Lets assume the following directory structure:
```
~/.lighthouse/{testnet}/validators
~/.lighthouse/{network}/validators
├── john
│   └── voting-keystore.json
├── sally
@@ -135,7 +135,7 @@ In order for the validator client to decrypt the validators, they will need to
ensure their `secrets-dir` is organised as below:
```
~/.lighthouse/{testnet}/secrets
~/.lighthouse/{network}/secrets
├── 0xa5566f9ec3c6e1fdf362634ebec9ef7aceb0e460e5079714808388e5d48f4ae1e12897fed1bea951c17fa389d511e477
├── 0xaa440c566fcf34dedf233baf56cf5fb05bb420d9663b4208272545608c27c13d5b08174518c758ecd814f158f2b4a337
└── 0x87a580d31d7bc69069b55f5a01995a610dd391a26dc9e36e81057a17211983a79266800ab8531f21f1083d7d84085007