Update validator guide for mainnet (#1951)
## Issue Addressed NA ## Proposed Changes Updates the validator guide to provide instructions for mainnet users. ## Additional Info - ~~Blocked on #1751~~
This commit is contained in:
Paul Hauner
parent
a171fb8843
commit
e504645767
50
README.md
50
README.md
@ -10,19 +10,19 @@ An open-source Ethereum 2.0 client, written in Rust and maintained by Sigma Prim
|
||||
[Chat Link]: https://discord.gg/cyAszAh
|
||||
[Book Status]:https://img.shields.io/badge/user--docs-master-informational
|
||||
[Book Link]: https://lighthouse-book.sigmaprime.io
|
||||
[stable]: https://github.com/sigp/lighthouse/tree/stable
|
||||
[unstable]: https://github.com/sigp/lighthouse/tree/unstable
|
||||
[blog]: https://lighthouse.sigmaprime.io
|
||||
|
||||
[Documentation](https://lighthouse-book.sigmaprime.io)
|
||||
|
||||
|
||||
|
||||
**🚨🚨🚨 Note: Lighthouse is not *yet* ready to produce mainnet deposits. The developers will require some
|
||||
time to test against the mainnet deposit contract, once it is released. DO NOT SUBMIT VALIDATOR
|
||||
DEPOSITS WITH LIGHTHOUSE. 🚨🚨🚨**
|
||||
|
||||
## Overview
|
||||
|
||||
Lighthouse is:
|
||||
|
||||
- Ready for use on Eth2 mainnet.
|
||||
- Fully open-source, licensed under Apache 2.0.
|
||||
- Security-focused. Fuzzing has begun and security reviews are underway.
|
||||
- Built in [Rust](https://www.rust-lang.org), a modern language providing unique safety guarantees and
|
||||
@ -32,44 +32,28 @@ Lighthouse is:
|
||||
- Actively involved in the specification and security analysis of the
|
||||
Ethereum 2.0 specification.
|
||||
|
||||
Like all Ethereum 2.0 clients, Lighthouse is a work-in-progress.
|
||||
|
||||
## Eth2 Deposit Contract
|
||||
|
||||
The Lighthouse team acknowledges
|
||||
[`0x00000000219ab540356cBB839Cbe05303d7705Fa`](https://etherscan.io/address/0x00000000219ab540356cbb839cbe05303d7705fa)
|
||||
as the canonical Eth2 deposit contract address.
|
||||
|
||||
## Development Status
|
||||
|
||||
Current development overview:
|
||||
|
||||
- Specification `v1.0.0` implemented, optimized and passing test vectors.
|
||||
- Rust-native libp2p with Gossipsub and Discv5.
|
||||
- RESTful JSON API via HTTP server.
|
||||
- Events via WebSocket.
|
||||
- Metrics via Prometheus.
|
||||
|
||||
### Roadmap
|
||||
|
||||
- ~~**April 2019**: Inital single-client testnets.~~
|
||||
- ~~**September 2019**: Inter-operability with other Ethereum 2.0 clients.~~
|
||||
- ~~**Q1 2020**: `lighthouse-0.1.0` release: All major phase 0 features implemented.~~
|
||||
- ~~**Q2 2020**: Public, multi-client testnet with user-facing functionality.~~
|
||||
- ~~**Q2 2020**: Third-party security review.~~
|
||||
- ~~**Q4 2020**: Long-lived, multi-client Beacon Chain testnet~~
|
||||
- **Q4 2020**: Additional third-party security reviews.
|
||||
- **Q4 2020**: Production Beacon Chain (tentative).
|
||||
|
||||
|
||||
## Documentation
|
||||
|
||||
The [Lighthouse Book](https://lighthouse-book.sigmaprime.io) contains information
|
||||
for testnet users and developers.
|
||||
The [Lighthouse Book](https://lighthouse-book.sigmaprime.io) contains information for users and
|
||||
developers.
|
||||
|
||||
If you'd like some background on Sigma Prime, please see the [Lighthouse Update
|
||||
\#00](https://lighthouse.sigmaprime.io/update-00.html) blog post or
|
||||
[sigmaprime.io](https://sigmaprime.io).
|
||||
The Lighthouse team maintains a blog at [lighthouse.sigmaprime.io][blog] which contains periodical
|
||||
progress updates, roadmap insights and interesting findings.
|
||||
|
||||
## Branches
|
||||
|
||||
Lighthouse maintains two permanent branches:
|
||||
|
||||
- [`stable`][stable]: Always points to the latest stable release.
|
||||
- This is ideal for most users.
|
||||
- [`unstable`][unstable]: Used for development, contains the latest PRs.
|
||||
- Developers should base thier PRs on this branch.
|
||||
|
||||
## Contributing
|
||||
|
||||
|
||||
@ -1,7 +1,8 @@
|
||||
# Summary
|
||||
|
||||
* [Introduction](./intro.md)
|
||||
* [Become a Testnet Validator](./testnet-validator.md)
|
||||
* [Become a Validator](./mainnet-validator.md)
|
||||
* [Become a Testnet Validator](./testnet-validator.md)
|
||||
* [Installation](./installation.md)
|
||||
* [System Requirements](./system-requirements.md)
|
||||
* [Pre-Built Binaries](./installation-binaries.md)
|
||||
@ -27,6 +28,7 @@
|
||||
* [Signature Header](./api-vc-sig-header.md)
|
||||
* [Prometheus Metrics](./advanced_metrics.md)
|
||||
* [Advanced Usage](./advanced.md)
|
||||
* [Custom Data Directories](./advanced-datadir.md)
|
||||
* [Database Configuration](./advanced_database.md)
|
||||
* [Local Testnets](./local-testnets.md)
|
||||
* [Advanced Networking](./advanced_networking.md)
|
||||
|
||||
15
book/src/advanced-datadir.md
Normal file
15
book/src/advanced-datadir.md
Normal file
@ -0,0 +1,15 @@
|
||||
## Custom Data Directories
|
||||
|
||||
Users can override the default Lighthouse data directories (e.g., `~/.lighthouse/mainnet`) using the `--datadir` flag. The custom data directory mirrors the structure of any network specific default directory (e.g. `~/.lighthouse/mainnet`).
|
||||
|
||||
> 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 Mainnet network.
|
||||
|
||||
```bash
|
||||
lighthouse --network mainnet --datadir /var/lib/my-custom-dir account validator import --directory <PATH-TO-LAUNCHPAD-KEYS-DIRECTORY>
|
||||
lighthouse --network mainnet --datadir /var/lib/my-custom-dir bn --staking
|
||||
lighthouse --network mainnet --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.
|
||||
@ -4,6 +4,8 @@
|
||||
|
||||
[Chat Badge]: https://img.shields.io/badge/chat-discord-%237289da
|
||||
[Chat Link]: https://discord.gg/cyAszAh
|
||||
[stable]: https://github.com/sigp/lighthouse/tree/stable
|
||||
[unstable]: https://github.com/sigp/lighthouse/tree/unstable
|
||||
|
||||
|
||||
Lighthouse welcomes contributions. If you are interested in contributing to the
|
||||
@ -24,6 +26,15 @@ To start contributing,
|
||||
If you have questions, please reach out via
|
||||
[Discord](https://discord.gg/cyAszAh).
|
||||
|
||||
## Branches
|
||||
|
||||
Lighthouse maintains two permanent branches:
|
||||
|
||||
- [`stable`][stable]: Always points to the latest stable release.
|
||||
- This is ideal for most users.
|
||||
- [`unstable`][unstable]: Used for development, contains the latest PRs.
|
||||
- Developers should base thier PRs on this branch.
|
||||
|
||||
## Ethereum 2.0
|
||||
|
||||
Lighthouse is an implementation of the Ethereum 2.0 specification, as defined
|
||||
|
||||
@ -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 --network 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 mainnet beacon --http --http-address 0.0.0.0
|
||||
```
|
||||
|
||||
> To join the altona testnet, use --network altona instead.
|
||||
> To join the Pyrmont testnet, use `--network pyrmont` instead.
|
||||
|
||||
> The `-p` and `-v` and values are described below.
|
||||
|
||||
|
||||
@ -118,7 +118,7 @@ testnet configuration settings. Ensure that the network you wish to connect to
|
||||
is correct (the beacon node outputs the network it is connecting to in the
|
||||
initial boot-up log lines). On top of this, ensure that you are not using the
|
||||
same `datadir` as a previous network. I.e if you have been running the
|
||||
`medalla` testnet and are now trying to join a new testnet but using the same
|
||||
`pyrmont` testnet and are now trying to join a new testnet but using the same
|
||||
`datadir` (the `datadir` is also printed out in the beacon node's logs on
|
||||
boot-up).
|
||||
|
||||
|
||||
@ -6,6 +6,7 @@ Compilation should be easy. In fact, if you already have Rust installed all you
|
||||
need is:
|
||||
|
||||
- `git clone https://github.com/sigp/lighthouse.git`
|
||||
- `git checkout stable`
|
||||
- `cd lighthouse`
|
||||
- `make`
|
||||
|
||||
|
||||
@ -13,15 +13,12 @@ clients to form a resilient and decentralized proof-of-stake blockchain.
|
||||
We implement the specification as defined in the
|
||||
[ethereum/eth2.0-specs](https://github.com/ethereum/eth2.0-specs) repository.
|
||||
|
||||
**🚨🚨🚨 Note: Lighthouse is not *yet* ready to produce mainnet deposits. The developers will require some
|
||||
time to test against the mainnet deposit contract, once it is released. DO NOT SUBMIT VALIDATOR
|
||||
DEPOSITS WITH LIGHTHOUSE. 🚨🚨🚨**
|
||||
|
||||
## Topics
|
||||
|
||||
You may read this book from start to finish, or jump to some of these topics:
|
||||
|
||||
- Follow the [Installation Guide](./installation.md) to install Lighthouse.
|
||||
- Learn about [becoming a mainnet validator](./mainnet-validator.md).
|
||||
- Get hacking with the [Development Environment Guide](./setup.md).
|
||||
- Utilize the whole stack by starting a [local testnet](./local-testnets.md).
|
||||
- Query the [RESTful HTTP API](./api.md) using `curl`.
|
||||
|
||||
@ -1,5 +1,10 @@
|
||||
# Key Management
|
||||
|
||||
[launchpad]: https://launchpad.ethereum.org/
|
||||
|
||||
>
|
||||
> **Note: we recommend using the [Eth2 launchpad][launchpad] to create validators.**
|
||||
|
||||
Lighthouse uses a _hierarchical_ key management system for producing validator
|
||||
keys. It is hierarchical because each validator key can be _derived_ from a
|
||||
master key, making the validators keys _children_ of the master key. This
|
||||
@ -37,9 +42,9 @@ items, starting at one easy-to-backup mnemonic and ending with multiple
|
||||
keypairs. Creating a single validator looks like this:
|
||||
|
||||
1. Create a **wallet** and record the **mnemonic**:
|
||||
- `lighthouse --testnet medalla account wallet create --name wally --password-file wally.pass`
|
||||
- `lighthouse --network pyrmont account wallet create --name wally --password-file wally.pass`
|
||||
1. Create the voting and withdrawal **keystores** for one validator:
|
||||
- `lighthouse --testnet medalla account validator create --wallet-name wally --wallet-password wally.pass --count 1`
|
||||
- `lighthouse --network pyrmont account validator create --wallet-name wally --wallet-password wally.pass --count 1`
|
||||
|
||||
|
||||
In step (1), we created a wallet in `~/.lighthouse/{network}/wallets` with the name
|
||||
@ -72,9 +77,7 @@ There are three important directories in Lighthouse validator key management:
|
||||
- `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/{network}/secrets`
|
||||
|
||||
where `network` is the name of the network passed in the `--network` parameter (default is `medalla`).
|
||||
- Defaults to `~/.lighthouse/{network}/secrets` where `network` is the name of the network passed in the `--network` parameter (default is `mainnet`).
|
||||
|
||||
When the validator client boots, it searches the `validators/` for directories
|
||||
containing voting keystores. When it discovers a keystore, it searches the
|
||||
|
||||
@ -43,12 +43,12 @@ keystores that correspond to one or more indices in the mnemonic:
|
||||
|
||||
|
||||
For each of the indices recovered in the above commands, a directory will be
|
||||
created in the `--validator-dir` location (default `~/.lighthouse/{testnet}/validators`)
|
||||
created in the `--validator-dir` location (default `~/.lighthouse/{network}/validators`)
|
||||
which contains all the information necessary to run a validator using the
|
||||
`lighthouse vc` command. The password to this new keystore will be placed in
|
||||
the `--secrets-dir` (default `~/.lighthouse/{testnet}/secrets`).
|
||||
the `--secrets-dir` (default `~/.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 Eth2 network passed in the `--network` parameter (default is `mainnet`).
|
||||
|
||||
## Recover a EIP-2386 wallet
|
||||
|
||||
|
||||
195
book/src/mainnet-validator.md
Normal file
195
book/src/mainnet-validator.md
Normal file
@ -0,0 +1,195 @@
|
||||
# Become an Eth2 Mainnet Validator
|
||||
|
||||
[launchpad]: https://launchpad.ethereum.org/
|
||||
[lh-book]: https://lighthouse-book.sigmaprime.io/
|
||||
[testnet-validator]: ./testnet-validator.md
|
||||
[custom-datadir]: ./custom-datadir.md
|
||||
[license]: https://github.com/sigp/lighthouse/blob/master/LICENSE
|
||||
[slashing]: ./slashing-protection.md
|
||||
[discord]: https://discord.gg/cyAszAh
|
||||
|
||||
Becoming an Eth2 validator is rewarding, but it's not for the faint of heart. You'll need to be
|
||||
familiar with the rules of staking (e.g., rewards, penalties, etc.) and also configuring and
|
||||
managing servers. You'll also need at least 32 ETH!
|
||||
|
||||
For those with an understanding of Eth2 and server maintenance, you'll find that running Lighthouse
|
||||
is easy. Install it, start it, monitor it and keep it updated. You shouldn't need to interact
|
||||
with it on a day-to-day basis.
|
||||
|
||||
Being educated is critical to validator success. Before submitting your mainnet deposit, we
|
||||
recommend:
|
||||
|
||||
- Thoroughly exploring the [Eth2 Launchpad][launchpad] website
|
||||
- Try running through the deposit process *without* actually submitting a deposit.
|
||||
- Reading through this documentation, especially the [Slashing Protection][slashing] section.
|
||||
- Running a [testnet validator][testnet-validator].
|
||||
- Performing a web search and doing your own research.
|
||||
|
||||
By far, the best technical learning experience is to run a [Testnet Validator][testnet-validator].
|
||||
You can get hands-on experience with all the tools and it's a great way to test your staking
|
||||
hardware. We recommend *all* mainnet validators to run a testnet validator initially; 32 ETH is a
|
||||
significant outlay and joining a testnet is a great way to "try before you buy".
|
||||
|
||||
Remember, if you get stuck you can always reach out on our [Discord][discord].
|
||||
|
||||
>
|
||||
> **Please note**: the Lighthouse team does not take any responsibility for losses or damages
|
||||
> occured through the use of Lighthouse. We have an experienced internal security team and have
|
||||
> undergone multiple third-party security-reviews, however the possibility of bugs or malicious
|
||||
> interference remains a real and constant threat. Validators should be prepared to lose some rewards
|
||||
> due to the actions of other actors on the Eth2 network or software bugs. See the
|
||||
> [software license][license] for more detail on liability.
|
||||
|
||||
## Using Lighthouse for Mainnet
|
||||
|
||||
When using Lighthouse, the `--network` flag selects a network. E.g.,
|
||||
|
||||
- `lighthouse` (no flag): Mainnet.
|
||||
- `lighthouse --network mainnet`: Mainnet.
|
||||
- `lighthouse --network pyrmont`: Pyrmont (testnet).
|
||||
|
||||
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 `--network` flag instead of relying on the default.
|
||||
|
||||
## Joining a Testnet
|
||||
|
||||
There are five primary steps to become a testnet validator:
|
||||
|
||||
1. Create validator keys and submit deposits.
|
||||
1. Start an Eth1 client.
|
||||
1. Install Lighthouse.
|
||||
1. Import the validator keys into Lighthouse.
|
||||
1. Start Lighthouse.
|
||||
1. Leave Lighthouse running.
|
||||
|
||||
Each of these primary steps has several intermediate steps, so we recommend
|
||||
setting aside one or two hours for this process.
|
||||
|
||||
### Step 1. Create validator keys
|
||||
|
||||
The Ethereum Foundation provides an "Eth2 launch pad" for creating validator keypairs and submitting
|
||||
deposits:
|
||||
|
||||
- [Eth2 Launchpad][launchpad]
|
||||
|
||||
Please follow the steps on the launch pad site to generate validator keys and submit deposits. Make
|
||||
sure you select "Lighthouse" as your client.
|
||||
|
||||
Move to the next step once you have completed the steps on the launch pad,
|
||||
including generating keys via the Python CLI and submitting gETH/ETH deposits.
|
||||
|
||||
### Step 2. Start an Eth1 client
|
||||
|
||||
Since Eth2 relies upon the Eth1 chain for validator on-boarding, all Eth2 validators must have a
|
||||
connection to an Eth1 node.
|
||||
|
||||
We provide instructions for using Geth, but you could use any client that implements the JSON RPC
|
||||
via HTTP. A fast-synced node is sufficient.
|
||||
|
||||
#### Installing Geth
|
||||
|
||||
If you're using a Mac, follow the instructions [listed
|
||||
here](https://github.com/ethereum/go-ethereum/wiki/Installation-Instructions-for-Mac) to install
|
||||
geth. Otherwise [see here](https://github.com/ethereum/go-ethereum/wiki/Installing-Geth).
|
||||
|
||||
#### Starting Geth
|
||||
|
||||
Once you have geth installed, use this command to start your Eth1 node:
|
||||
|
||||
```bash
|
||||
geth --http
|
||||
```
|
||||
|
||||
### Step 3. Install Lighthouse
|
||||
|
||||
*Note: Lighthouse only supports Windows via WSL.*
|
||||
|
||||
Follow the [Lighthouse Installation Instructions](./installation.md) to install
|
||||
Lighthouse from one of the available options.
|
||||
|
||||
Proceed to the next step once you've successfully installed Lighthouse and viewed
|
||||
its `--version` info.
|
||||
|
||||
> Note: Some of the instructions vary when using Docker, ensure you follow the
|
||||
> appropriate sections later in this guide.
|
||||
|
||||
### Step 4. Import validator keys to Lighthouse
|
||||
|
||||
When Lighthouse is installed, follow the [Importing from the Ethereum 2.0 Launch
|
||||
pad](./validator-import-launchpad.md) instructions so the validator client can
|
||||
perform your validator duties.
|
||||
|
||||
Proceed to the next step once you've successfully imported all validators.
|
||||
|
||||
### Step 5. Start Lighthouse
|
||||
|
||||
For staking, one needs to run two Lighthouse processes:
|
||||
|
||||
- `lighthouse bn`: the "beacon node" which connects to the P2P network and
|
||||
verifies blocks.
|
||||
- `lighthouse vc`: the "validator client" which manages validators, using data
|
||||
obtained from the beacon node via a HTTP API.
|
||||
|
||||
Starting these processes is different for binary and docker users:
|
||||
|
||||
#### Binary users
|
||||
|
||||
Those using the pre- or custom-built binaries can start the two processes with:
|
||||
|
||||
```bash
|
||||
lighthouse --network mainnet bn --staking
|
||||
```
|
||||
|
||||
```bash
|
||||
lighthouse --network mainnet vc
|
||||
```
|
||||
|
||||
> Note: `~/.lighthouse/mainnet` is the default directory which contains the keys and databases.
|
||||
> To specify a custom dir, see [Custom Directories][custom-datadir].
|
||||
|
||||
#### Docker users
|
||||
|
||||
Those using Docker images can start the processes with:
|
||||
|
||||
```bash
|
||||
$ docker run \
|
||||
--network host \
|
||||
-v $HOME/.lighthouse:/root/.lighthouse sigp/lighthouse \
|
||||
lighthouse --network mainnet bn --staking --http-address 0.0.0.0
|
||||
```
|
||||
|
||||
```bash
|
||||
$ docker run \
|
||||
--network host \
|
||||
-v $HOME/.lighthouse:/root/.lighthouse \
|
||||
sigp/lighthouse \
|
||||
lighthouse --network mainnet vc
|
||||
```
|
||||
|
||||
### Step 6. Leave Lighthouse running
|
||||
|
||||
Leave your beacon node and validator client running and you'll see logs as the
|
||||
beacon node stays synced with the network while the validator client produces
|
||||
blocks and attestations.
|
||||
|
||||
It will take 4-8+ hours for the beacon chain to process and activate your
|
||||
validator, however you'll know you're active when the validator client starts
|
||||
successfully publishing attestations each epoch:
|
||||
|
||||
```
|
||||
Dec 03 08:49:40.053 INFO Successfully published attestation slot: 98, committee_index: 0, head_block: 0xa208…7fd5,
|
||||
```
|
||||
|
||||
Although you'll produce an attestation each epoch, it's less common to produce a
|
||||
block. Watch for the block production logs too:
|
||||
|
||||
```
|
||||
Dec 03 08:49:36.225 INFO Successfully published block slot: 98, attestations: 2, deposits: 0, service: block
|
||||
```
|
||||
|
||||
If you see any `ERRO` (error) logs, please reach out on
|
||||
[Discord](https://discord.gg/cyAszAh) or [create an
|
||||
issue](https://github.com/sigp/lighthouse/issues/new).
|
||||
|
||||
Happy staking!
|
||||
@ -47,6 +47,7 @@ command).
|
||||
```bash
|
||||
git clone https://github.com/sigp/lighthouse.git
|
||||
cd lighthouse
|
||||
git checkout stable
|
||||
make
|
||||
```
|
||||
|
||||
|
||||
@ -40,7 +40,7 @@ The slasher has several configuration options that control its functioning.
|
||||
* Argument: path to directory
|
||||
|
||||
By default the slasher stores data in the `slasher_db` directory inside the beacon node's datadir,
|
||||
e.g. `~/.lighthouse/{testnet}/beacon/slasher_db`. You can use this flag to change that storage
|
||||
e.g. `~/.lighthouse/{network}/beacon/slasher_db`. You can use this flag to change that storage
|
||||
directory.
|
||||
|
||||
### History Length
|
||||
|
||||
@ -97,8 +97,8 @@ The validator client needs to be stopped in order to export.
|
||||
If the slashing protection database cannot be found, it will manifest in an error like this:
|
||||
|
||||
```
|
||||
Oct 12 14:41:26.415 CRIT Failed to start validator client reason: Failed to open slashing protection database: SQLError("Unable to open database: Error(Some(\"unable to open database file: /home/karlm/.lighthouse/medalla/validators/slashing_protection.sqlite\"))").
|
||||
Ensure that `slashing_protection.sqlite` is in "/home/karlm/.lighthouse/medalla/validators" folder
|
||||
Oct 12 14:41:26.415 CRIT Failed to start validator client reason: Failed to open slashing protection database: SQLError("Unable to open database: Error(Some(\"unable to open database file: /home/karlm/.lighthouse/mainnet/validators/slashing_protection.sqlite\"))").
|
||||
Ensure that `slashing_protection.sqlite` is in "/home/karlm/.lighthouse/mainnet/validators" folder
|
||||
```
|
||||
|
||||
Usually this indicates that during some manual intervention the slashing database has been
|
||||
@ -108,7 +108,7 @@ never see this error (see [Initialization](#initialization)).
|
||||
|
||||
The safest way to remedy this error is to find your old slashing protection database and move
|
||||
it to the correct location. In our example that would be
|
||||
`~/.lighthouse/medalla/validators/slashing_protection.sqlite`. You can search for your old database
|
||||
`~/.lighthouse/mainnet/validators/slashing_protection.sqlite`. You can search for your old database
|
||||
using a tool like `find`, `fd`, or your file manager's GUI. Ask on the Lighthouse Discord if you're
|
||||
not sure.
|
||||
|
||||
|
||||
@ -1,187 +1,23 @@
|
||||
# Become a Testnet Validator
|
||||
|
||||
Joining an Eth2 testnet is a great way to get familiar with staking in Phase 0.
|
||||
All users should experiment with a testnet prior to staking mainnet ETH.
|
||||
[mainnet-validator]: ./mainnet-validator.md
|
||||
[pyrmont-launchpad]: https://pyrmont.launchpad.ethereum.org/
|
||||
|
||||
**🚨🚨🚨 Note: Lighthouse is not *yet* ready to produce mainnet deposits. The developers will require some
|
||||
time to test against the mainnet deposit contract, once it is released. DO NOT SUBMIT VALIDATOR
|
||||
DEPOSITS WITH LIGHTHOUSE. 🚨🚨🚨**
|
||||
Joining an Eth2 testnet is a great way to get familiar with staking in Phase 0. All users should
|
||||
experiment with a testnet prior to staking mainnet ETH.
|
||||
|
||||
## Supported Testnets
|
||||
To join a testnet, you can follow the [Become an Eth2 Mainnet Validator][mainnet-validator]
|
||||
instructions but with a few differences:
|
||||
|
||||
Lighthouse supports the "mainnet" network and four test networks:
|
||||
1. Use the appropriate Eth2 launchpad website:
|
||||
- [Pyrmont][pyrmont-launchpad]
|
||||
1. Instead of `--network mainnet`, use the appropriate network flag:
|
||||
- `--network pyrmont`: Pyrmont.
|
||||
1. Use a Goerli Eth1 node instead of a mainnet one:
|
||||
- For Geth, this means using `geth --goerli --http`.
|
||||
1. Notice that Lighthouse will store its files in a different directory by default:
|
||||
- `~/.lighthouse/pyrmont`: Pyrmont.
|
||||
|
||||
- [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 `--network` flag selects a network. E.g.,
|
||||
|
||||
- `lighthouse` (no flag): Medalla.
|
||||
- `lighthouse --network mainnet`: Mainnet.
|
||||
- `lighthouse --network medalla`: Medalla.
|
||||
- `lighthouse --network pyrmont`: Pyrmont.
|
||||
|
||||
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 `--network` flag instead of relying on the default.
|
||||
|
||||
> 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
|
||||
|
||||
There are five primary steps to become a testnet validator:
|
||||
|
||||
1. Create validator keys and submit deposits.
|
||||
1. Start an Eth1 client.
|
||||
1. Install Lighthouse.
|
||||
1. Import the validator keys into Lighthouse.
|
||||
1. Start Lighthouse.
|
||||
1. Leave Lighthouse running.
|
||||
|
||||
Each of these primary steps has several intermediate steps, so we recommend
|
||||
setting aside one or two hours for this process.
|
||||
|
||||
### Step 1. Create validator keys
|
||||
|
||||
The Ethereum Foundation provides an "Eth2 launch pad" for each active testnet:
|
||||
|
||||
- [Medalla launchpad](https://medalla.launchpad.ethereum.org/)
|
||||
- [Pyrmont launchpad](https://pyrmont.launchpad.ethereum.org/)
|
||||
|
||||
Please follow the steps on the appropriate launch pad site to generate
|
||||
validator keys and submit deposits. Make sure you select "Lighthouse" as your
|
||||
client.
|
||||
|
||||
Move to the next step once you have completed the steps on the launch pad,
|
||||
including generating keys via the Python CLI and submitting gETH/ETH deposits.
|
||||
|
||||
### Step 2. Start an Eth1 client
|
||||
|
||||
Since Eth2 relies upon the Eth1 chain for validator on-boarding, all Eth2 validators must have a connection to an Eth1 node.
|
||||
|
||||
We provide instructions for using Geth (the Eth1 client that, by chance, we ended up testing with), but you could use any client that implements the JSON RPC via HTTP. A fast-synced node should be sufficient.
|
||||
|
||||
#### Installing Geth
|
||||
|
||||
If you're using a Mac, follow the instructions [listed here](https://github.com/ethereum/go-ethereum/wiki/Installation-Instructions-for-Mac) to install geth. Otherwise [see here](https://github.com/ethereum/go-ethereum/wiki/Installing-Geth).
|
||||
|
||||
#### Starting Geth
|
||||
|
||||
Once you have geth installed, use this command to start your Eth1 node:
|
||||
|
||||
```bash
|
||||
geth --goerli --http
|
||||
```
|
||||
|
||||
### Step 3. Install Lighthouse
|
||||
|
||||
*Note: Lighthouse only supports Windows via WSL.*
|
||||
|
||||
Follow the [Lighthouse Installation Instructions](./installation.md) to install
|
||||
Lighthouse from one of the available options.
|
||||
|
||||
Proceed to the next step once you've successfully installed Lighthouse and view
|
||||
its `--version` info.
|
||||
|
||||
> Note: Some of the instructions vary when using Docker, ensure you follow the
|
||||
> appropriate sections later in this guide.
|
||||
|
||||
### Step 4. Import validator keys to Lighthouse
|
||||
|
||||
When Lighthouse is installed, follow the [Importing from the Ethereum 2.0 Launch
|
||||
pad](./validator-import-launchpad.md) instructions so the validator client can
|
||||
perform your validator duties.
|
||||
|
||||
Proceed to the next step once you've successfully imported all validators.
|
||||
|
||||
### Step 5. Start Lighthouse
|
||||
|
||||
For staking, one needs to run two Lighthouse processes:
|
||||
|
||||
- `lighthouse bn`: the "beacon node" which connects to the P2P network and
|
||||
verifies blocks.
|
||||
- `lighthouse vc`: the "validator client" which manages validators, using data
|
||||
obtained from the beacon node via a HTTP API.
|
||||
|
||||
Starting these processes is different for binary and docker users:
|
||||
|
||||
#### Binary users
|
||||
|
||||
Those using the pre- or custom-built binaries can start the two processes with:
|
||||
|
||||
```bash
|
||||
lighthouse --network MY_NETWORK bn --staking
|
||||
```
|
||||
|
||||
```bash
|
||||
lighthouse --network MY_NETWORK vc
|
||||
```
|
||||
|
||||
> 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
|
||||
|
||||
Those using Docker images can start the processes with:
|
||||
|
||||
```bash
|
||||
$ docker run \
|
||||
--network host \
|
||||
-v $HOME/.lighthouse:/root/.lighthouse sigp/lighthouse \
|
||||
lighthouse --network MY_NETWORK bn --staking --http-address 0.0.0.0
|
||||
```
|
||||
|
||||
```bash
|
||||
$ docker run \
|
||||
--network host \
|
||||
-v $HOME/.lighthouse:/root/.lighthouse \
|
||||
sigp/lighthouse \
|
||||
lighthouse --network MY_NETWORK vc
|
||||
```
|
||||
|
||||
### Step 6. Leave Lighthouse running
|
||||
|
||||
Leave your beacon node and validator client running and you'll see logs as the
|
||||
beacon node stays synced with the network while the validator client produces
|
||||
blocks and attestations.
|
||||
|
||||
It will take 4-8+ hours for the beacon chain to process and activate your
|
||||
validator, however you'll know you're active when the validator client starts
|
||||
successfully publishing attestations each epoch:
|
||||
|
||||
```
|
||||
Dec 03 08:49:40.053 INFO Successfully published attestation slot: 98, committee_index: 0, head_block: 0xa208…7fd5,
|
||||
```
|
||||
|
||||
Although you'll produce an attestation each epoch, it's less common to produce a
|
||||
block. Watch for the block production logs too:
|
||||
|
||||
```
|
||||
Dec 03 08:49:36.225 INFO Successfully published block slot: 98, attestations: 2, deposits: 0, service: block
|
||||
```
|
||||
|
||||
If you see any `ERRO` (error) logs, please reach out on
|
||||
[Discord](https://discord.gg/cyAszAh) or [create an
|
||||
issue](https://github.com/sigp/lighthouse/issues/new).
|
||||
|
||||
Happy staking!
|
||||
|
||||
|
||||
## Custom directories
|
||||
|
||||
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 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 --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.
|
||||
>
|
||||
> **Never use real ETH to join a testnet!** All of the testnets listed here use Goerli ETH which is
|
||||
> basically worthless. This allows experimentation without real-world costs.
|
||||
|
||||
@ -1,8 +1,9 @@
|
||||
# Create a validator
|
||||
|
||||
**🚨🚨🚨 Note: Lighthouse is not *yet* ready to produce mainnet deposits. The developers will require some
|
||||
time to test against the mainnet deposit contract, once it is released. DO NOT SUBMIT VALIDATOR
|
||||
DEPOSITS WITH LIGHTHOUSE. 🚨🚨🚨**
|
||||
[launchpad]: https://launchpad.ethereum.org/
|
||||
|
||||
>
|
||||
> **Note: we recommend using the [Eth2 launchpad][launchpad] to create validators.**
|
||||
|
||||
Validators are fundamentally represented by a BLS keypair. In Lighthouse, we
|
||||
use a [wallet](./wallet-create.md) to generate these keypairs. Once a wallet
|
||||
@ -74,17 +75,17 @@ The example assumes that the `wally` wallet was generated from the
|
||||
[wallet](./wallet-create.md) example.
|
||||
|
||||
```bash
|
||||
lighthouse --network medalla account validator create --name wally --wallet-password wally.pass --count 1
|
||||
lighthouse --network pyrmont 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
|
||||
- Derive a single new BLS keypair from wallet `wally` in `~/.lighthouse/{network}/wallets`, updating it so that it generates a
|
||||
new key next time.
|
||||
- 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
|
||||
contract for the Pyrmont testnet. Other testnets can be set via the
|
||||
`--network` CLI param.
|
||||
- Store a password to the validators voting keypair in `~/.lighthouse/{network}/secrets`.
|
||||
|
||||
@ -25,7 +25,7 @@ website). If this is not the case, simply change the `--directory` to point to
|
||||
the `validator_keys` directory.
|
||||
|
||||
Now, assuming that the user is in the `eth2-deposit-cli` directory and they're
|
||||
using the default (`~/.lighthouse/{testnet}/validators`) `validators` directory (specify a different one using
|
||||
using the default (`~/.lighthouse/{network}/validators`) `validators` directory (specify a different one using
|
||||
`--validators-dir` flag), they can follow these steps:
|
||||
|
||||
### 1. Run the `lighthouse account validator import` command.
|
||||
@ -35,10 +35,10 @@ section, all other users can use:
|
||||
|
||||
|
||||
```bash
|
||||
lighthouse --network medalla account validator import --directory validator_keys
|
||||
lighthouse --network mainnet account validator import --directory validator_keys
|
||||
```
|
||||
|
||||
Note: The user must specify the testnet that they are importing the keys for using the `--testnet` flag.
|
||||
Note: The user must specify the Eth2 network that they are importing the keys for using the `--network` flag.
|
||||
|
||||
|
||||
After which they will be prompted for a password for each keystore discovered:
|
||||
|
||||
@ -27,7 +27,7 @@ In order to initiate an exit, users can use the `lighthouse account validator ex
|
||||
|
||||
- The `--beacon-node` flag is used to specify a beacon chain HTTP endpoint that confirms to the [Eth2.0 Standard API](https://ethereum.github.io/eth2.0-APIs/) specifications. That beacon node will be used to validate and propagate the voluntary exit. The default value for this flag is `http://localhost:5052`.
|
||||
|
||||
- The `--testnet` flag is used to specify a particular testnet (default is `medalla`).
|
||||
- The `--network` flag is used to specify a particular Eth2 network (default is `pyrmont`).
|
||||
|
||||
- The `--password-file` flag is used to specify the path to the file containing the password for the voting keystore. If this flag is not provided, the user will be prompted to enter the password.
|
||||
|
||||
|
||||
@ -1,5 +1,10 @@
|
||||
# Create a wallet
|
||||
|
||||
[launchpad]: https://launchpad.ethereum.org/
|
||||
|
||||
>
|
||||
> **Note: we recommend using the [Eth2 launchpad][launchpad] to create validators.**
|
||||
|
||||
A wallet allows for generating practically unlimited validators from an
|
||||
easy-to-remember 24-word string (a mnemonic). As long as that mnemonic is
|
||||
backed up, all validator keys can be trivially re-generated.
|
||||
@ -54,11 +59,11 @@ OPTIONS:
|
||||
|
||||
## Example
|
||||
|
||||
Creates a new wallet named `wally` and saves it in `~/.lighthouse/medalla/wallets` with a randomly generated password saved
|
||||
Creates a new wallet named `wally` and saves it in `~/.lighthouse/pyrmont/wallets` with a randomly generated password saved
|
||||
to `./wallet.pass`:
|
||||
|
||||
```bash
|
||||
lighthouse --testnet medalla account wallet create --name wally --password-file wally.pass
|
||||
lighthouse --network pyrmont account wallet create --name wally --password-file wally.pass
|
||||
```
|
||||
|
||||
> Notes:
|
||||
|
||||
Loading…
Reference in New Issue
Block a user