cerc-io/lighthouse
16
0
Fork 0
Code Issues 1 Pull Requests Packages Projects Releases Wiki Activity

Update docs for testnet3 (#773)

Browse Source 
* 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:
Paul Hauner 2020-01-10 13:56:48 +11:00 committed by GitHub
parent efd73230cf
commit 698af6d7ec
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
8 changed files with 297 additions and 130 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@ -12,8 +12,8 @@ An open-source Ethereum 2.0 client, written in Rust and maintained by Sigma Prim
[Book Link]: http://lighthouse-book.sigmaprime.io/ [Book Link]: http://lighthouse-book.sigmaprime.io/
[RustDoc Status]:https://img.shields.io/badge/code--docs-master-orange [RustDoc Status]:https://img.shields.io/badge/code--docs-master-orange
[RustDoc Link]: http://lighthouse-docs.sigmaprime.io/ [RustDoc Link]: http://lighthouse-docs.sigmaprime.io/
[Swagger Badge]: https://img.shields.io/badge/Open%20API-0.2.0-success [Swagger Badge]: https://img.shields.io/badge/testnet--explorer-beaconcha.in-informational
[Swagger Link]: https://app.swaggerhub.com/apis-docs/spble/lighthouse_rest_api/0.2.0 [Swagger Link]: https://lighthouse-testnet3.beaconcha.in/
[Documentation](http://lighthouse-book.sigmaprime.io/) [Documentation](http://lighthouse-book.sigmaprime.io/)

4
beacon_node/client/src/notifier.rs
View File

@ -122,9 +122,9 @@ pub fn spawn_notifier<T: BeaconChainTypes>(
log, log,
"Syncing"; "Syncing";
"peers" => peer_count_pretty(connected_peer_count), "peers" => peer_count_pretty(connected_peer_count),
"est_time" => estimated_time_pretty(speedo.estimated_time_till_slot(current_slot)), "distance" => distance,
"speed" => sync_speed_pretty(speedo.slots_per_second()), "speed" => sync_speed_pretty(speedo.slots_per_second()),
"distance" => distance "est_time" => estimated_time_pretty(speedo.estimated_time_till_slot(current_slot)),
); );
return Ok(()); return Ok(());

2
beacon_node/src/cli.rs
View File

@ -189,7 +189,7 @@ pub fn cli_app<'a, 'b>() -> App<'a, 'b> {
.value_name("HTTP-ENDPOINT") .value_name("HTTP-ENDPOINT")
.help("Specifies the server for a web3 connection to the Eth1 chain.") .help("Specifies the server for a web3 connection to the Eth1 chain.")
.takes_value(true) .takes_value(true)
.default_value("https://goerli.public.sigp.io") .default_value("http://127.0.0.1:8545")
) )
.arg( .arg(
Arg::with_name("slots-per-restore-point") Arg::with_name("slots-per-restore-point")

2
book/src/SUMMARY.md
View File

@ -2,6 +2,8 @@
* [Introduction](./intro.md) * [Introduction](./intro.md)
* [Become a Validator](./become-a-validator.md) * [Become a Validator](./become-a-validator.md)
* [Using Docker](./become-a-validator-docker.md)
* [Building from Source](./become-a-validator-source.md)
* [Installation](./installation.md) * [Installation](./installation.md)
* [Docker](./docker.md) * [Docker](./docker.md)
* [CLI](./cli.md) * [CLI](./cli.md)

67
book/src/become-a-validator-docker.md Normal file
View File

@ -0,0 +1,67 @@
# Become a Validator: Using Docker
Sigma Prime maintains the
[sigp/lighthouse-docker](https://github.com/sigp/lighthouse-docker) repository
which provides an easy way to run Lighthouse without building the Lighthouse
binary yourself.
> Note: when you're running the Docker Hub image you're relying upon a
> pre-built binary instead of building from source. If you want the highest
> assurance you're running the _real_ Lighthouse,
> [build the docker image yourself](./docker.md) instead. You'll need some
> experience with docker-compose to integrate your locally built docker image
> with the docker-compose environment.
### 1. Clone the repository
Once you have docker-compose
[installed](https://docs.docker.com/compose/install/), clone the
[sigp/lighthouse-docker](https://github.com/sigp/lighthouse-docker) repository.
```bash
$ git clone https://github.com/sigp/lighthouse-docker
$ cd lighthouse-docker
```
### 2. Configure the docker environment
Then, create a file named `.env` with the following contents (these values are
documented
[here](https://github.com/sigp/lighthouse-docker/blob/master/default.env)):
```bash
DEBUG_LEVEL=info
START_GETH=true
START_VALIDATOR=true
VALIDATOR_COUNT=1
VOTING_ETH1_NODE=http://geth:8545
DEPOSIT_VALUE=3200000000
```
_This `.env` file should live in the `lighthouse-docker` directory alongside the
`docker-compose.yml` file_.
### 3. Start Lighthouse
Start the docker-compose environment (you may need to use `sudo`):
```bash
$ docker-compose up
```
> Note: the docker-compose setup includes a fast-synced geth node. You can
> expect the `beacon_node` to log some eth1-related errors whilst the geth node
> boots and becomes synced. This will only happen on the first start of the
> compose environment or if geth loses sync.
### 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 the root of the `lighthouse-docker`
repository. For example, if you ran Step 1 in `/home/karlm/` then you can find
your validator directory in
`/home/karlm/lighthouse-docker/.lighthouse/validators/`.
You can now go to [Become a Validator: Step 2](become-a-validator.html#2-submit-your-deposit-to-goerli).

132
book/src/become-a-validator-source.md Normal file
View 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).

138
book/src/become-a-validator.md
View File

@ -1,135 +1,33 @@
# Become an Ethereum 2.0 Validator* # Become an Ethereum 2.0 Validator*
---
**The lighthouse testnet is currently down, we expect to raise a new one soon.
See [Lighthouse Update #20](https://lighthouse.sigmaprime.io/update-20.html)
for more information.**
---
_* Testnet validator_ _* Testnet validator_
Running Lighthouse validator is easy if you're familiar with the terminal. It Running Lighthouse validator is easy if you're familiar with the terminal. It
runs on Linux, MacOS and Windows. runs on Linux, MacOS and Windows and we have a Docker work-flow.
Before you start, you'll need [Metamask](https://metamask.io/) and 3.2 gETH Before you start, you'll need [Metamask](https://metamask.io/) and 3.2 gETH
(Goerli ETH). We recommend the [mudit.blog (Goerli ETH). We recommend the [mudit.blog
faucet](https://faucet.goerli.mudit.blog/) for those familiar with Goerli, or faucet](https://faucet.goerli.mudit.blog/) for those familiar with Goerli, or
[goerli.net](https://goerli.net/) for an overview of the testnet. [goerli.net](https://goerli.net/) for an overview of the testnet.
### 1. Download and install Lighthouse ## 1. Install and start Lighthouse
If you already have Rust installed, you can install Lighthouse with the There are two, different ways to install and start a Lighthouse validator:
following three commands:
- `$ git clone https://github.com/sigp/lighthouse.git` - [Using `docker-compose`](./become-a-validator-docker.md): this is the easiest method.
- `$ cd lighthouse` - [Building from source](./become-a-validator-source.md): this is a little more involved, however it
- `$ make` gives a more hands-on experience.
You've completed this step when you can run `$ lighthouse --help` and see the Once you have completed **only one** of these steps, move onto the next step.
help menu.
> - If you're not familiar with Rust or you'd like more detailed instructions, see ## 2. Submit your deposit to Goerli
> the [Installation Guide](./installation.md).
> - The [Docker Guide](./docker.md) is great if you have Docker installed and would
> like to avoid installing Rust.
### 2. 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 distance: 16837 slots (2 days 8 hrs), ...
```
Don't be overly concerned about the "distance" because "est_time" for syncing will be much lower.
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.
> - We are hosting a public Goerli archive node and have set this as the
> default, but you can specify your own Eth1 node using the `--eth1-endpoint`
> flag. Presently we require the node to be a full archive node, but we're
> working to [fix](https://github.com/sigp/lighthouse/issues/637) this.
### 3. 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).
### 4. 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.
### 5. Submit your deposit
<div class="form-signin" id="uploadDiv"> <div class="form-signin" id="uploadDiv">
<p>Upload the <code>eth1_deposit_data.rlp</code> file from your validator <p>Upload the <code>eth1_deposit_data.rlp</code> file from your validator
directory (created in step 3) to submit your 3.2 Goerli-ETH directory (created in Step 1) to submit your 3.2 Goerli-ETH
deposit using Metamask.</p> deposit using Metamask.</p>
<p>Hint: it's generally in the <code>$HOME/.lighthouse/validators/0x...</code> directory</p> <p>Hint: the method used in Step 1 will determine where this file is
located.</p>
<input id="fileInput" type="file" style="display: none"> <input id="fileInput" type="file" style="display: none">
<button id="uploadButton" class="btn btn-lg btn-primary btn-block" <button id="uploadButton" class="btn btn-lg btn-primary btn-block"
type="submit">Upload and Submit Deposit</button> type="submit">Upload and Submit Deposit</button>
@ -150,15 +48,15 @@ next step. After all, this is a testnet and you're only risking Goerli ETH.
> This deposit is using gETH (Goerli ETH) which has no real value. Don't ever > This deposit is using gETH (Goerli ETH) which has no real value. Don't ever
> send _real_ ETH to our deposit contract! > send _real_ ETH to our deposit contract!
## Next steps ## 3. Leave Lighthouse running
Leave your beacon node and validator client running and you'll see logs as the Leave your beacon node and validator client running and you'll see logs as the
beacon node keeps synced with the network and the validator client produces beacon node keeps synced with the network and the validator client produces
blocks and attestations. blocks and attestations.
It will take some time (minutes to hours) for the beacon chain to process and It will take 4-8+ hours for the beacon chain to process and activate your
activate your validator, however you'll know you're active when the validator validator, however you'll know you're active when the validator client starts
client starts successfully publishing attestations each slot: successfully publishing attestations each slot:
``` ```
Dec 03 08:49:40.053 INFO Successfully published attestation slot: 98, committee_index: 0, head_block: 0xa208…7fd5, Dec 03 08:49:40.053 INFO Successfully published attestation slot: 98, committee_index: 0, head_block: 0xa208…7fd5,
@ -175,11 +73,13 @@ If you see any `ERRO` (error) logs, please reach out on
[Discord](https://discord.gg/cyAszAh) or [create an [Discord](https://discord.gg/cyAszAh) or [create an
issue](https://github.com/sigp/lighthouse/issues/new). issue](https://github.com/sigp/lighthouse/issues/new).
Don't forget to checkout the open-source block explorer for the Lighthouse
testnet at
[lighthouse-testnet3.beaconcha.in](https://lighthouse-testnet3.beaconcha.in/).
Happy staking! Happy staking!
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script> <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js"></script> <script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js"></script>
<script charset="utf-8" <script charset="utf-8"

78
book/src/docker.md
View File

@ -3,17 +3,83 @@
This repository has a `Dockerfile` in the root which builds an image with the This repository has a `Dockerfile` in the root which builds an image with the
`lighthouse` binary installed. `lighthouse` binary installed.
To use the image, first build it (this will likely take several minutes): A pre-built image is available on Docker Hub and the
[sigp/lighthouse](https://github.com/sigp/lighthouse-docker) repository
contains a full-featured `docker-compose` environment.
## Obtaining the Docker image
There are two ways to obtain the docker image, either via Docker Hub or
building the image from source. Once you have obtained the docker image via one
of these methods, proceed to [Using the Docker image](#using-the-docker-image).
### Docker Hub
Lighthouse maintains the
[sigp/lighthouse](https://hub.docker.com/repository/docker/sigp/lighthouse/)
Docker Hub repository which provides an easy way to run Lighthouse without
building the image yourself.
Download and test the image with:
```bash ```bash
$ docker build . -t lighthouse $ docker run sigp/lighthouse lighthouse --help
``` ```
Once it's built, run it with: > Note: when you're running the Docker Hub image you're relying upon a
> pre-built binary instead of building from source.
### Building the Docker Image
To build the image from source, navigate to
the root of the repository and run:
```bash ```bash
$ docker run lighthouse lighthouse --help $ docker build . -t lighthouse:local
``` ```
_Note: the first `lighthouse` is the name of the tag we created earlier. The The build will likely take several minutes. Once it's built, test it with:
second `lighthouse` refers to the binary installed in the image._
```bash
$ docker run lighthouse:local lighthouse --help
```
## Using the Docker image
You can run a Docker beacon node with the following command:
```bash
$ docker run -p 9000:9000 -p 5052:5052 -v $HOME/.lighthouse:/root/.lighthouse sigp/lighthouse lighthouse beacon --http
```
> The `-p` and `-v` and values are described below.
### Volumes
Lighthouse uses the `/root/.lighthouse` directory inside the Docker image to
store the configuration, database and validator keys. Users will generally want
to create a bind-mount volume to ensure this directory persists between `docker
run` commands.
The following example runs a beacon node with the data directory
mapped to the users home directory:
```bash
$ docker run -v $HOME/.lighthouse:/root/.lighthouse sigp/lighthouse lighthouse beacon
```
### Ports
In order to be a good peer and serve other peers you should expose port `9000`.
Use the `-p` flag to do this:
```bash
$ docker run -p 9000:9000 sigp/lighthouse lighthouse beacon
```
If you use the `--http` flag you may also want to expose the HTTP port with `-p
5052:5052`.
```bash
$ docker run -p 9000:9000 -p 5052:5052 sigp/lighthouse lighthouse beacon --http
```