mirror of
https://github.com/sigp/lighthouse.git
synced 2026-03-15 10:52:43 +00:00
Update docs for testnet3 (#773)
* Start docker docs * Add progress * Update docker.md * Add note about geth syncing * Fix env to use geth * Update docs * Remove sigp goerli node * Change text about eth1 syncing * Address comments from @pscott * Add links to beaconcha.in * Add instructions for starting an eth1 node * Fix typo * Re-organise Syncing log
This commit is contained in:
132
book/src/become-a-validator-source.md
Normal file
132
book/src/become-a-validator-source.md
Normal file
@@ -0,0 +1,132 @@
|
||||
# Become an Validator: Building from Source
|
||||
|
||||
## 1. Download and install Lighthouse
|
||||
|
||||
If you already have Rust installed, you can install Lighthouse with the
|
||||
following three commands:
|
||||
|
||||
- `$ git clone https://github.com/sigp/lighthouse.git`
|
||||
- `$ cd lighthouse`
|
||||
- `$ make`
|
||||
|
||||
You've completed this step when you can run `$ lighthouse --help` and see the
|
||||
help menu.
|
||||
|
||||
> - If you're not familiar with Rust or you'd like more detailed instructions,
|
||||
> see the [Installation Guide](./installation.md) which contains a
|
||||
> [Troubleshooting](installation.html#troubleshooting) section.
|
||||
|
||||
## 2. Start an Eth1 client
|
||||
|
||||
As Eth2 relies upon the Eth1 chain for validator on-boarding and eventually
|
||||
Eth1 may use the Eth2 chain as a finality gadget, all Eth2 validators must have
|
||||
a connection to an Eth1 node.
|
||||
|
||||
We provide instructions for using Geth (this is, by chance, what we ended up
|
||||
testing with), but you could use any client that implements the JSON RPC via
|
||||
HTTP. At least for Geth, a fast-synced node is sufficient.
|
||||
|
||||
### Starting Geth
|
||||
|
||||
[Install geth](https://github.com/ethereum/go-ethereum/wiki/Installing-Geth)
|
||||
and then use this command (or equivalent) to start your Eth1 node:
|
||||
|
||||
```bash
|
||||
$ geth --goerli --rpc
|
||||
```
|
||||
|
||||
## 3. Start your Beacon Node
|
||||
|
||||
The beacon node is the core component of Eth2, it connects to other peers over
|
||||
the Internet and maintains a view of the chain.
|
||||
|
||||
Start your beacon node with:
|
||||
|
||||
```bash
|
||||
$ lighthouse beacon --eth1 --http
|
||||
```
|
||||
|
||||
Your beacon node has started syncing when you see the following (truncated)
|
||||
log:
|
||||
|
||||
```
|
||||
Dec 09 12:57:18.026 INFO Syncing est_time: 2 hrs ...
|
||||
```
|
||||
|
||||
The `distance` value reports the time since eth2 genesis, whilst the `est_time`
|
||||
reports an estimate of how long it will take your node to become synced.
|
||||
|
||||
It has finished syncing once you see the following (truncated) log:
|
||||
|
||||
```
|
||||
Dec 09 12:27:06.010 INFO Synced slot: 16835, ...
|
||||
```
|
||||
|
||||
> - The `--http` flag enables the HTTP API for the validator client.
|
||||
> - The `--eth1` flag tells the beacon node that it should sync with an Ethereum
|
||||
> 1 node (e.g., Geth). This is only required if you wish to run a validator.
|
||||
|
||||
## 4. Generate your validator key
|
||||
|
||||
Generate new validator BLS keypairs using:
|
||||
|
||||
```shell
|
||||
$ lighthouse account validator new random
|
||||
```
|
||||
|
||||
|
||||
You've completed this step when you see the equivalent line:
|
||||
|
||||
```
|
||||
Dec 02 21:42:01.337 INFO Generated validator directories count: 1, base_path: "/home/karl/.lighthouse/validators"
|
||||
```
|
||||
|
||||
> - This will generate a new _validator directory_ in the `.lighthouse/validators`
|
||||
> directory. Your validator directory will be identified by it's public key,
|
||||
> which looks something like `0xc483de...`. You'll need to find this directory
|
||||
> for the next step.
|
||||
> - These keys are good enough for the Lighthouse testnet, however they shouldn't
|
||||
> be considered secure until we've undergone a security audit (planned Jan
|
||||
> 2020).
|
||||
|
||||
## 5. Start your validator client
|
||||
|
||||
For security reasons, the validator client runs separately to the beacon node.
|
||||
The validator client stores private keys and signs messages generated by the
|
||||
beacon node.
|
||||
|
||||
You'll need both your beacon node _and_ validator client running if you want to
|
||||
stake.
|
||||
|
||||
Start the validator client with:
|
||||
|
||||
```bash
|
||||
$ lighthouse validator
|
||||
```
|
||||
|
||||
The validator client is running and has found your validator keys from step 3
|
||||
when you see the following log:
|
||||
|
||||
```
|
||||
Dec 09 13:08:59.171 INFO Loaded validator keypair store voting_validators: 1
|
||||
Dec 09 13:09:09.000 INFO Awaiting activation slot: 17787, ...
|
||||
```
|
||||
|
||||
If your beacon node hasn't finished syncing yet, you'll see some `ERRO`
|
||||
messages indicating that your node isn't synced yet. It is safest to wait for
|
||||
your node to sync before moving onto the next step, otherwise your validator
|
||||
may activate before you're able to produce blocks and attestations. However, it
|
||||
generally takes 4-8+ hours after deposit for a validator to become active. If
|
||||
your `est_time` is less than 4 hours, you _should_ be fine to just move to the
|
||||
next step. After all, this is a testnet and you're only risking Goerli ETH.
|
||||
|
||||
## Installation complete!
|
||||
|
||||
In the next step you'll need to locate your `eth1_deposit_data.rlp` file from
|
||||
your `.lighthouse/validators` directory.
|
||||
|
||||
The `./lighthouse` directory is in your `$HOME` directory. For example, if
|
||||
you're in Linux and your user is `karlm`, you can find your validator directory
|
||||
in `/home/karlm/.lighthouse/validators/`.
|
||||
|
||||
You can now go to [Become a Validator: Step 2](become-a-validator.html#2-submit-your-deposit-to-goerli).
|
||||
Reference in New Issue
Block a user