Update docs for v0.3.0 (#1742)
## Issue Addressed
NA
## Proposed Changes
- Remove Metamask deposits from the docs.
- Restructure docs to be launchpad-centric.
- Remove references to sigp/lighthouse-docker.
- Add section about binaries.
## Additional Info
Please provide any additional information. For example, future considerations
or information useful for reviewers.
This commit is contained in:
Paul Hauner
parent
b69c63d486
commit
414138f137
@ -1,11 +1,11 @@
|
||||
# Summary
|
||||
|
||||
* [Introduction](./intro.md)
|
||||
* [Become a Validator](./become-a-validator.md)
|
||||
* [Using Docker](./become-a-validator-docker.md)
|
||||
* [Building from Source](./become-a-validator-source.md)
|
||||
* [Become a Testnet Validator](./testnet-validator.md)
|
||||
* [Installation](./installation.md)
|
||||
* [Pre-Built Binaries](./installation-binaries.md)
|
||||
* [Docker](./docker.md)
|
||||
* [Build from Source](./installation-source.md)
|
||||
* [Raspberry Pi 4](./pi.md)
|
||||
* [Cross-Compiling](./cross-compiling.md)
|
||||
* [Key Management](./key-management.md)
|
||||
|
||||
@ -1,121 +0,0 @@
|
||||
# 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.
|
||||
|
||||
## 0. Install Docker Compose
|
||||
|
||||
Docker Compose relies on Docker Engine for any meaningful work, so make sure you have Docker Engine installed either locally or remote, depending on your setup.
|
||||
|
||||
- On desktop systems like [Docker Desktop for Mac](https://docs.docker.com/docker-for-mac/install/) and [Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/install/), Docker Compose is included as part of those desktop installs, so the desktop install is all you need.
|
||||
|
||||
- On Linux systems, you'll need to first [install the Docker for your OS](https://docs.docker.com/install/#server) and then [follow the instuctions here](https://docs.docker.com/compose/install/#install-compose-on-linux-systems).
|
||||
|
||||
> For more on installing Compose, see [here](https://docs.docker.com/compose/install/).
|
||||
|
||||
|
||||
## 1. Clone the repository
|
||||
|
||||
Once you have Docker Compose installed, 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
|
||||
```
|
||||
|
||||
> To specify a non-default testnet add `TESTNET=<testnet>` to the above file. <testnet> can be `altona` or `medalla`.
|
||||
|
||||
_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 prefix the below command with `sudo`):
|
||||
|
||||
```bash
|
||||
docker-compose up
|
||||
```
|
||||
|
||||
Watch the output of this command for the `Decrypted validator keystore pubkey`
|
||||
log, as it contains your `voting_pubkey` -- the primary identifier for your new
|
||||
validator. This key is useful for finding your validator in block explorers.
|
||||
Here's an example of the log:
|
||||
|
||||
```bash
|
||||
validator_client_1 | Jun 01 00:29:24.418 INFO Decrypted validator keystore voting_pubkey: 0x9986ade7a974d2fe2d0fc84a8c04153873337d533d43a83439cab8ec276410686dd69aa808605a7324f34e52497a3f41
|
||||
```
|
||||
This is one of the earlier logs outputted, so you may have to scroll up or perform a search in your terminal to find it.
|
||||
|
||||
> Note: `docker-compose up` generates a new sub-directory -- to store your validator's deposit data, along with its voting and withdrawal keys -- in the `lighthouse-data/validators` directory. This sub-directory is identified by your validator's `voting_pubkey` (the same `voting_pubkey` you see in the logs). So this is another way you can find it.
|
||||
|
||||
> Note: the docker-compose setup includes a fast-synced geth node. So 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.
|
||||
|
||||
> Note: If you are participating in the genesis of a network (the network has
|
||||
> not launched yet) you will notice errors in the validator client. This is
|
||||
> because the beacon node not expose its HTTP API until
|
||||
> the genesis of the network is known (approx 2 days before the network
|
||||
> launches).
|
||||
|
||||
> Note: Docker exposes ports TCP 9000 and UDP 9000 by default. Although not
|
||||
> strictly required, we recommend setting up port forwards to expose these
|
||||
> ports publicly. For more information see the FAQ or the [Advanced Networking](advanced_networking.html)
|
||||
> section
|
||||
|
||||
To find an estimate for how long your beacon node will take to finish syncing, look for logs that look like this:
|
||||
|
||||
```bash
|
||||
beacon_node_1 | Mar 16 11:33:53.979 INFO Syncing
|
||||
est_time: 47 mins, speed: 16.67 slots/sec, distance: 47296 slots (7 days 14 hrs), peers: 3, service: slot_notifier
|
||||
```
|
||||
|
||||
You'll find the estimated time under `est_time`. In the example above, that's `47 mins`.
|
||||
|
||||
If your beacon node hasn't finished syncing yet, you'll see some ERRO messages indicating that your node hasn't synced yet:
|
||||
|
||||
```bash
|
||||
validator_client_1 | Mar 16 11:34:36.086 ERRO Beacon node is not synced current_epoch: 6999, node_head_epoch: 5531, service: duties
|
||||
```
|
||||
|
||||
It's safest to wait for your node to sync before moving on to the next step, otherwise your validator may activate before you're able to produce blocks and attestations (and you may be penalized as a result).
|
||||
|
||||
However, since it generally takes somewhere between [4 and 8 hours](./faq.md) after depositing for a validator to become active, if your `est_time` is less than 4 hours, you _should_ be fine to just move on to the next step. After all, this is a testnet and you're only risking Goerli ETH!
|
||||
|
||||
## Installation complete!
|
||||
|
||||
In the [next step](become-a-validator.html#2-submit-your-deposit-to-goerli) you'll need to upload your validator's deposit data. This data is stored in a file called `eth1_deposit_data.rlp`.
|
||||
|
||||
You'll find it in `lighthouse-docker/.lighthouse/validators/` -- in the sub-directory that corresponds to your validator's public key (`voting_pubkey`).
|
||||
|
||||
|
||||
> For example, if you ran [step 1](become-a-validator-docker.html#1-clone-the-repository) in `/home/karlm/`, and your validator's `voting_pubkey` is `0x8592c7..`, then you'll find your `eth1_deposit_data.rlp` file in the following directory:
|
||||
>
|
||||
>`/home/karlm/lighthouse-docker/.lighthouse/validators/0x8592c7../`
|
||||
|
||||
Once you've located `eth1_deposit_data.rlp`, you're ready to move on to [Become a Validator: Step 2](become-a-validator.html#2-submit-your-deposit-to-goerli).
|
||||
@ -1,219 +0,0 @@
|
||||
# Become a Validator: Building from Source
|
||||
|
||||
## 0. Install Rust
|
||||
If you don't have Rust installed already, visit [rustup.rs](https://rustup.rs/) to install it.
|
||||
|
||||
> Notes:
|
||||
> - If you're not familiar with Rust or you'd like more detailed instructions, see our [installation guide](./installation.md).
|
||||
> - Windows is presently only supported via [WSL](https://docs.microsoft.com/en-us/windows/wsl/about).
|
||||
|
||||
|
||||
## 1. Download and install Lighthouse
|
||||
|
||||
Once you have Rust installed, you can install Lighthouse with the following commands:
|
||||
|
||||
1. `git clone https://github.com/sigp/lighthouse.git`
|
||||
2. `cd lighthouse`
|
||||
4. `make`
|
||||
|
||||
You may need to open a new terminal window before running `make`.
|
||||
|
||||
You've completed this step when you can run `$ lighthouse --help` and see the
|
||||
help menu.
|
||||
|
||||
|
||||
## 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
|
||||
```
|
||||
|
||||
## 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 --testnet medalla beacon --staking
|
||||
```
|
||||
|
||||
> The `--testnet` parameter is optional. Omitting it will default to the
|
||||
> current public testnet. Set the value to the testnet you wish to run on.
|
||||
> Current values are either `altona` or `medalla`. This is true for all the
|
||||
> following commands in this document.
|
||||
|
||||
> Note: Lighthouse, by default, opens port 9000 over TCP and UDP. Although not
|
||||
> strictly required, we recommend setting up port forwards to expose these
|
||||
> ports publicly. For more information see the FAQ or the [Advanced Networking](advanced_networking.html)
|
||||
> section
|
||||
|
||||
|
||||
You can also pass an external http endpoint (e.g. Infura) for the Eth1 node using the `--eth1-endpoint` flag:
|
||||
|
||||
```bash
|
||||
lighthouse --testnet medalla beacon --staking --eth1-endpoint <ETH1-SERVER>
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
You'll know it's finished syncing once you see the following (truncated) log:
|
||||
|
||||
```
|
||||
Dec 09 12:27:06.010 INFO Synced
|
||||
slot: 16835, ...
|
||||
```
|
||||
|
||||
|
||||
## 4. Generate your validator key
|
||||
|
||||
First, [create a wallet](./wallet-create.md) that can be used to generate
|
||||
validator keys. Then, from that wallet [create a
|
||||
validator](./validator-create.md). A two-step example follows:
|
||||
|
||||
### 4.1 Create a Wallet
|
||||
|
||||
Create a wallet with:
|
||||
|
||||
```bash
|
||||
lighthouse --testnet medalla account wallet create
|
||||
```
|
||||
|
||||
You will be prompted for a wallet name and a password. The output will look like this:
|
||||
|
||||
```
|
||||
Your wallet's 24-word BIP-39 mnemonic is:
|
||||
|
||||
glad marble art pelican nurse large guilt response brave affair kite essence welcome gauge peace once picnic debris devote ticket blood bike solar junk
|
||||
|
||||
This mnemonic can be used to fully restore your wallet, should
|
||||
you lose the JSON file or your password.
|
||||
|
||||
It is very important that you DO NOT SHARE this mnemonic as it will
|
||||
reveal the private keys of all validators and keys generated with
|
||||
this wallet. That would be catastrophic.
|
||||
|
||||
It is also important to store a backup of this mnemonic so you can
|
||||
recover your private keys in the case of data loss. Writing it on
|
||||
a piece of paper and storing it in a safe place would be prudent.
|
||||
|
||||
Your wallet's UUID is:
|
||||
|
||||
1c8c13d5-d065-4ef7-bad3-14e9d8146140
|
||||
|
||||
You do not need to backup your UUID or keep it secret.
|
||||
```
|
||||
|
||||
**Don't forget to make a backup** of the 24-word BIP-39 mnemonic. It can be
|
||||
used to restore your validator if there is a data loss.
|
||||
|
||||
### 4.2 Create a Validator from the Wallet
|
||||
|
||||
Create a validator from the wallet with:
|
||||
|
||||
```bash
|
||||
lighthouse --testnet medalla account validator create --count 1
|
||||
```
|
||||
|
||||
Enter your wallet's name and password when prompted. The output will look like this:
|
||||
|
||||
```bash
|
||||
1/1 0x80f3dce8d6745a725d8442c9bc3ca0852e772394b898c95c134b94979ebb0af6f898d5c5f65b71be6889185c486918a7
|
||||
```
|
||||
|
||||
Take note of the _validator public key_ (the `0x` and 64 characters following
|
||||
it). It's the validator's primary identifier, and will be used to find your
|
||||
validator in block explorers. (The `1/1` at the start is saying it's one-of-one
|
||||
keys generated).
|
||||
|
||||
Once you've observed the validator public key, you've successfully generated a
|
||||
new sub-directory for your validator in the `.lighthouse/validators` directory.
|
||||
The sub-directory is identified by your validator's public key . And is used to
|
||||
store your validator's deposit data, along with its voting keys and other
|
||||
information.
|
||||
|
||||
|
||||
## 5. Start your validator client
|
||||
|
||||
> Note: If you are participating in the genesis of a network (the network has
|
||||
> not launched yet) you should skip this step and re-run this step two days before
|
||||
> the launch of the network. The beacon node does not expose its HTTP API until
|
||||
> the genesis of the network is known (approx 2 days before the network
|
||||
> launches).
|
||||
|
||||
Since the validator client stores private keys and signs messages generated by the beacon node, for security reasons it runs separately from it.
|
||||
|
||||
You'll need both your beacon node _and_ validator client running if you want to
|
||||
stake.
|
||||
|
||||
Start the validator client with:
|
||||
|
||||
```bash
|
||||
lighthouse --testnet medalla validator --auto-register
|
||||
```
|
||||
|
||||
The `--auto-register` flag registers your signing key with the slashing protection database, which
|
||||
keeps track of all the messages your validator signs. This flag should be used sparingly,
|
||||
as reusing the same key on multiple nodes can lead to your validator getting slashed. On subsequent
|
||||
runs you should leave off the `--auto-register` flag.
|
||||
|
||||
You know that your validator client is running and has found your validator keys from [step 3](become-a-validator-source.html#3-start-your-beacon-node) when you see the following logs:
|
||||
|
||||
```
|
||||
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, ...
|
||||
```
|
||||
|
||||
|
||||
To find an estimate for how long your beacon node will take to finish syncing, lookout for the following logs:
|
||||
|
||||
```bash
|
||||
beacon_node_1 | Mar 16 11:33:53.979 INFO Syncing
|
||||
est_time: 47 mins, speed: 16.67 slots/sec, distance: 47296 slots (7 days 14 hrs), peers: 3, service: slot_notifier
|
||||
```
|
||||
|
||||
You'll find the estimated time under `est_time`. In the example log above, that's `47 mins`.
|
||||
|
||||
If your beacon node hasn't finished syncing yet, you'll see some `ERRO`
|
||||
messages indicating that your node hasn't synced yet:
|
||||
|
||||
```bash
|
||||
validator_client_1 | Mar 16 11:34:36.086 ERRO Beacon node is not synced current_epoch: 6999, node_head_epoch: 5531, service: duties
|
||||
```
|
||||
|
||||
It's safest to wait for your node to sync before moving on to the next step, otherwise your validator may activate before you're able to produce blocks and attestations (and you may be penalized as a result).
|
||||
|
||||
However, since it generally takes somewhere between [4 and 8 hours](./faq.md) after depositing for a validator to become active, if your `est_time` is less than 4 hours, you _should_ be fine to just move on to the next step. After all, this is a testnet and you're only risking Goerli ETH!
|
||||
|
||||
## Installation complete!
|
||||
|
||||
In the [next step](become-a-validator.html#2-submit-your-deposit-to-goerli) you'll need to upload your validator's deposit data. This data is stored in a file called `eth1_deposit_data.rlp`.
|
||||
|
||||
You'll find it in `/home/.lighthouse/validators` -- in the sub-directory that corresponds to your validator's public key.
|
||||
|
||||
> For example, if your username is `karlm`, and your validator's public key (aka `voting_pubkey`) is `0x8592c7..`, then you'll find your `eth1_deposit_data.rlp` file in the following directory:
|
||||
>
|
||||
>`/home/karlm/.lighthouse/validators/0x8592c7../`
|
||||
|
||||
Once you've located your `eth1_deposit_data.rlp` file, you're ready to move on to [Become a Validator: Step 2](become-a-validator.html#2-submit-your-deposit-to-goerli).
|
||||
@ -1,96 +0,0 @@
|
||||
# Become an Ethereum 2.0 Validator
|
||||
|
||||
There are two public testnets currently available. [Medalla](https://github.com/goerli/medalla/tree/master/medalla) and [Altona](https://github.com/goerli/medalla/tree/master/altona). Lighthouse supports both out of the box and joining these multi-client testnets is easy if you're familiar with the terminal.
|
||||
|
||||
Lighthouse runs on Linux, MacOS and Windows and has a Docker work-flow to make
|
||||
things as simple as possible.
|
||||
|
||||
## 0. Acquire Goerli ETH
|
||||
Before you install Lighthouse, you'll need [Metamask](https://metamask.io/) and 32 gETH
|
||||
(Goerli ETH). We recommend the [mudit.blog
|
||||
faucet](https://faucet.goerli.mudit.blog/) for those familiar with Goerli, or
|
||||
[goerli.net](https://goerli.net/) for an overview of the testnet.
|
||||
|
||||
> If this is your first time using Metamask and/or interacting with an Ethereum test network, we recommend going through the beginning of [this guide](https://hack.aragon.org/docs/guides-use-metamask) first (up to the *Signing your first transaction with MetaMask* section).
|
||||
|
||||
## 1. Install and start Lighthouse
|
||||
|
||||
There are two, different ways to install and start a Lighthouse validator:
|
||||
|
||||
1. [Using `docker-compose`](./become-a-validator-docker.md): this is the easiest method.
|
||||
|
||||
2. [Building from source](./become-a-validator-source.md): this is a little more involved, however it
|
||||
gives a more hands-on experience.
|
||||
|
||||
Once you've completed **either one** of these steps, you can move onto the next step.
|
||||
|
||||
> Take note when running Lighthouse. Use the --testnet parameter to specify the testnet you whish to participate in. Medalla is currently the default, so make sure to use --testnet altona to join the Altona testnet.
|
||||
|
||||
## 2. Submit your deposit to Goerli
|
||||
|
||||
<div class="form-signin" id="uploadDiv">
|
||||
<p>Upload the <code>eth1_deposit_data.rlp</code> file from your validator
|
||||
directory (created in the previous step) to submit your 32 Goerli-ETH
|
||||
deposit using Metamask.</p>
|
||||
<p>Note that the method you used in step 1 will determine where this file is
|
||||
located.</p>
|
||||
<input id="fileInput" type="file" style="display: none">
|
||||
<button id="uploadButton" class="btn btn-lg btn-primary btn-block"
|
||||
type="submit">Upload and Submit Deposit</button>
|
||||
</div>
|
||||
|
||||
<div class="form-signin" id="waitingDiv" style="display: none">
|
||||
<p style="color: green">Your validator deposit was submitted and this step is complete.</p>
|
||||
<p>See the transaction on <a id="txLink" target="_blank"
|
||||
href="https://etherscan.io">Etherscan</a>
|
||||
or <a href="">reload</a> to perform another deposit.</p>
|
||||
</div>
|
||||
|
||||
<div class="form-signin" id="errorDiv" style="display: none">
|
||||
<h4 class="h3 mb-3 font-weight-normal">Error</h4>
|
||||
<p id="errorText" style="color: red">Unknown error.</p>
|
||||
<p style="color: red">Please refresh to reupload.</p>
|
||||
</div>
|
||||
|
||||
> This deposit is made using gETH (Goerli ETH) which has no real value. Please don't ever
|
||||
> send _real_ ETH to our deposit contract!
|
||||
|
||||
## 3. 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 slot:
|
||||
|
||||
```
|
||||
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 slot, 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).
|
||||
|
||||
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!
|
||||
|
||||
|
||||
<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 charset="utf-8"
|
||||
src="https://cdn.ethers.io/scripts/ethers-v4.min.js"
|
||||
type="text/javascript">
|
||||
</script>
|
||||
<script src="js/deposit.js"></script>
|
||||
@ -1,11 +1,7 @@
|
||||
# Docker Guide
|
||||
|
||||
This repository has a `Dockerfile` in the root which builds an image with the
|
||||
`lighthouse` binary installed.
|
||||
|
||||
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.
|
||||
`lighthouse` binary installed. A pre-built image is available on Docker Hub.
|
||||
|
||||
## Obtaining the Docker image
|
||||
|
||||
@ -20,10 +16,28 @@ Lighthouse maintains the
|
||||
Docker Hub repository which provides an easy way to run Lighthouse without
|
||||
building the image yourself.
|
||||
|
||||
Obtain the latest image with:
|
||||
|
||||
```bash
|
||||
$ docker pull sigp/lighthouse
|
||||
```
|
||||
|
||||
Download and test the image with:
|
||||
|
||||
```bash
|
||||
$ docker run sigp/lighthouse lighthouse --help
|
||||
$ docker run sigp/lighthouse lighthouse --version
|
||||
```
|
||||
|
||||
If you can see the latest [Lighthouse
|
||||
release](https://github.com/sigp/lighthouse/releases) version (see example
|
||||
below), then you've
|
||||
successfully installed Lighthouse via Docker.
|
||||
|
||||
#### Example Version Output
|
||||
|
||||
```
|
||||
Lighthouse vx.x.xx-xxxxxxxxx
|
||||
BLS Library: xxxx-xxxxxxx
|
||||
```
|
||||
|
||||
> Note: when you're running the Docker Hub image you're relying upon a
|
||||
|
||||
38
book/src/installation-binaries.md
Normal file
38
book/src/installation-binaries.md
Normal file
@ -0,0 +1,38 @@
|
||||
# Pre-built Binaries
|
||||
|
||||
Each Lighthouse release contains several downloadable binaries in the "Assets"
|
||||
section of the release. You can find the [releases
|
||||
on Github](https://github.com/sigp/lighthouse/releases).
|
||||
|
||||
> Note: binaries are not yet provided for MacOS or Windows native.
|
||||
|
||||
## Platforms
|
||||
|
||||
Binaries are supplied for two platforms:
|
||||
|
||||
- `x86_64-unknown-linux-gnu`: AMD/Intel 64-bit processors (most desktops, laptops, servers)
|
||||
- `aarch64-unknown-linux-gnu`: 64-bit ARM processors (Raspberry Pi 4)
|
||||
|
||||
Additionally there is also a `-portable` suffix which indicates if the `portable` feature is used:
|
||||
|
||||
- Without `portable`: uses modern CPU instructions to provide the fastest signature verification times (may cause `Illegal instruction` error on older CPUs)
|
||||
- With `portable`: approx. 20% slower, but should work on all modern 64-bit processors.
|
||||
|
||||
## Usage
|
||||
|
||||
Each binary is contained in a `.tar.gz` archive. For this example, lets use the
|
||||
`v0.2.13` release and assume the user needs a portable `x86_64` binary.
|
||||
|
||||
> Whilst this example uses `v0.2.13` we recommend always using the latest release.
|
||||
|
||||
### Steps
|
||||
|
||||
1. Go to the [Releases](https://github.com/sigp/lighthouse/releases) page and
|
||||
select the latest release.
|
||||
1. Download the `lighthouse-${VERSION}-x86_64-unknown-linux-gnu-portable.tar.gz` binary.
|
||||
1. Extract the archive:
|
||||
1. `cd Downloads`
|
||||
1. `tar -xvf lighthouse-${VERSION}-x86_64-unknown-linux-gnu.tar.gz`
|
||||
1. Test the binary with `./lighthouse --version` (it should print the version).
|
||||
1. (Optional) Move the `lighthouse` binary to a location in your `PATH`, so the `lighthouse` command can be called from anywhere.
|
||||
- E.g., `cp lighthouse /usr/bin`
|
||||
82
book/src/installation-source.md
Normal file
82
book/src/installation-source.md
Normal file
@ -0,0 +1,82 @@
|
||||
# Installation: Build from Source
|
||||
|
||||
Lighthouse builds on Linux, macOS, and Windows (via [WSL][] only).
|
||||
|
||||
Compilation should be easy. In fact, if you already have Rust installed all you
|
||||
need is:
|
||||
|
||||
- `git clone https://github.com/sigp/lighthouse.git`
|
||||
- `cd lighthouse`
|
||||
- `make`
|
||||
|
||||
If this doesn't work or is not clear enough, see the [Detailed
|
||||
Instructions](#detailed-instructions) below. If you have further issues, see
|
||||
[Troubleshooting](#troubleshooting). If you'd prefer to use Docker, see the
|
||||
[Docker Guide](./docker.md).
|
||||
|
||||
## Detailed Instructions
|
||||
|
||||
1. Install Rust and Cargo with [rustup](https://rustup.rs/).
|
||||
- Use the `stable` toolchain (it's the default).
|
||||
- Check the [Troubleshooting](#troubleshooting) section for additional
|
||||
dependencies (e.g., `cmake`).
|
||||
1. Clone the Lighthouse repository.
|
||||
- Run `$ git clone https://github.com/sigp/lighthouse.git`
|
||||
- Change into the newly created directory with `$ cd lighthouse`
|
||||
1. Build Lighthouse with `$ make`.
|
||||
1. Installation was successful if `$ lighthouse --help` displays the
|
||||
command-line documentation.
|
||||
|
||||
> First time compilation may take several minutes. If you experience any
|
||||
> failures, please reach out on [discord](https://discord.gg/cyAszAh) or
|
||||
> [create an issue](https://github.com/sigp/lighthouse/issues/new).
|
||||
|
||||
## Windows Support
|
||||
|
||||
Compiling or running Lighthouse natively on Windows is not currently supported. However,
|
||||
Lighthouse can run successfully under the [Windows Subsystem for Linux (WSL)][WSL]. If using
|
||||
Ubuntu under WSL, you can should install the Ubuntu dependencies listed in the [Dependencies
|
||||
(Ubuntu)](#dependencies-ubuntu) section.
|
||||
|
||||
[WSL]: https://docs.microsoft.com/en-us/windows/wsl/about
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Dependencies
|
||||
|
||||
#### Ubuntu
|
||||
|
||||
Several dependencies may be required to compile Lighthouse. The following
|
||||
packages may be required in addition a base Ubuntu Server installation:
|
||||
|
||||
```bash
|
||||
sudo apt install -y git gcc g++ make cmake pkg-config libssl-dev
|
||||
```
|
||||
|
||||
#### macOS
|
||||
|
||||
You will need `cmake`. You can install via homebrew:
|
||||
|
||||
brew install openssl cmake
|
||||
|
||||
### Command is not found
|
||||
|
||||
Lighthouse will be installed to `CARGO_HOME` or `$HOME/.cargo`. This directory
|
||||
needs to be on your `PATH` before you can run `$ lighthouse`.
|
||||
|
||||
See ["Configuring the `PATH` environment variable"
|
||||
(rust-lang.org)](https://www.rust-lang.org/tools/install) for more information.
|
||||
|
||||
### Compilation error
|
||||
|
||||
Make sure you are running the latest version of Rust. If you have installed Rust using rustup, simply type `$ rustup update`.
|
||||
|
||||
### OpenSSL
|
||||
|
||||
If you get a build failure relating to OpenSSL, try installing `openssl-dev` or
|
||||
`libssl-dev` using your OS package manager.
|
||||
|
||||
- Ubuntu: `$ apt-get install libssl-dev`.
|
||||
- Amazon Linux: `$ yum install openssl-devel`.
|
||||
|
||||
[WSL]: https://docs.microsoft.com/en-us/windows/wsl/about
|
||||
@ -1,73 +1,16 @@
|
||||
# 📦 Installation
|
||||
|
||||
Lighthouse runs on Linux, macOS, and Windows via [WSL][].
|
||||
Installation should be easy. In fact, if you already have Rust installed all you need is:
|
||||
Lighthouse runs on Linux, macOS, and Windows (via [WSL][] only).
|
||||
|
||||
- `git clone https://github.com/sigp/lighthouse.git`
|
||||
- `cd lighthouse`
|
||||
- `make`
|
||||
There are three core methods to obtain the Lighthouse application:
|
||||
|
||||
If this doesn't work or is not clear enough, see the [Detailed Instructions](#detailed-instructions). If you have further issues, see [Troubleshooting](#troubleshooting). If you'd prefer to use Docker, see the [Docker Guide](./docker.md).
|
||||
- [Pre-built binaries](./installation-binaries.md).
|
||||
- [Docker images](./docker.md).
|
||||
- [Building from source](./installation-source.md).
|
||||
|
||||
## Detailed Instructions
|
||||
Additionally, there are two extra guides for specific uses:
|
||||
|
||||
1. Install Rust and Cargo with [rustup](https://rustup.rs/).
|
||||
- Use the `stable` toolchain (it's the default).
|
||||
1. Clone the Lighthouse repository.
|
||||
- Run `$ git clone https://github.com/sigp/lighthouse.git`
|
||||
- Change into the newly created directory with `$ cd lighthouse`
|
||||
1. Build Lighthouse with `$ make`.
|
||||
1. Installation was successful if `$ lighthouse --help` displays the
|
||||
command-line documentation.
|
||||
|
||||
> First time compilation may take several minutes. If you experience any
|
||||
> failures, please reach out on [discord](https://discord.gg/cyAszAh) or
|
||||
> [create an issue](https://github.com/sigp/lighthouse/issues/new).
|
||||
|
||||
## Windows Support
|
||||
|
||||
Compiling or running Lighthouse natively on Windows is not currently supported. However,
|
||||
Lighthouse can run successfully under the [Windows Subsystem for Linux (WSL)][WSL]. If using
|
||||
Ubuntu under WSL, you can should install the Ubuntu dependencies listed in the [Dependencies
|
||||
(Ubuntu)](#dependencies-ubuntu) section.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Dependencies
|
||||
|
||||
#### Ubuntu
|
||||
|
||||
Several dependencies may be required to compile Lighthouse. The following
|
||||
packages may be required in addition a base Ubuntu Server installation:
|
||||
|
||||
```bash
|
||||
sudo apt install -y git gcc g++ make cmake pkg-config libssl-dev
|
||||
```
|
||||
|
||||
#### macOS
|
||||
|
||||
You will need `cmake`. You can install via homebrew:
|
||||
|
||||
brew install cmake
|
||||
|
||||
### Command is not found
|
||||
|
||||
Lighthouse will be installed to `CARGO_HOME` or `$HOME/.cargo`. This directory
|
||||
needs to be on your `PATH` before you can run `$ lighthouse`.
|
||||
|
||||
See ["Configuring the `PATH` environment variable"
|
||||
(rust-lang.org)](https://www.rust-lang.org/tools/install) for more information.
|
||||
|
||||
### Compilation error
|
||||
|
||||
Make sure you are running the latest version of Rust. If you have installed Rust using rustup, simply type `$ rustup update`.
|
||||
|
||||
### OpenSSL
|
||||
|
||||
If you get a build failure relating to OpenSSL, try installing `openssl-dev` or
|
||||
`libssl-dev` using your OS package manager.
|
||||
|
||||
- Ubuntu: `$ apt-get install libssl-dev`.
|
||||
- Amazon Linux: `$ yum install openssl-devel`.
|
||||
- [Rapsberry Pi 4 guide](./pi.md).
|
||||
- [Cross-compiling guide for developers](./cross-compiling.md).
|
||||
|
||||
[WSL]: https://docs.microsoft.com/en-us/windows/wsl/about
|
||||
|
||||
162
book/src/testnet-validator.md
Normal file
162
book/src/testnet-validator.md
Normal file
@ -0,0 +1,162 @@
|
||||
# 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.
|
||||
|
||||
## Supported Testnets
|
||||
|
||||
Lighthouse supports four testnets:
|
||||
|
||||
- [Medalla](https://github.com/goerli/medalla/tree/master/medalla) (default)
|
||||
- [Zinken](https://github.com/goerli/medalla/tree/master/zinken)
|
||||
- [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.,
|
||||
|
||||
- `lighthouse` (no flag): Medalla.
|
||||
- `lighthouse --testnet medalla`: Medalla.
|
||||
- `lighthouse --testnet zinken`: Zinken.
|
||||
|
||||
Using the correct `--testnet` 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.
|
||||
|
||||
> Note: In these documents we use `--testnet MY_TESTNET` for demonstration. You
|
||||
> must replace `MY_TESTNET` with a valid testnet name.
|
||||
|
||||
## 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/)
|
||||
- [Zinken launchpad](https://zinken.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 --testnet MY_TESTNET bn --staking
|
||||
```
|
||||
|
||||
```bash
|
||||
lighthouse --testnet MY_TESTNET vc
|
||||
```
|
||||
|
||||
#### Docker users
|
||||
|
||||
Those using Docker images can start the processes with:
|
||||
|
||||
```bash
|
||||
$ docker run \
|
||||
--network host \
|
||||
-v $HOME/.lighthouse:/root/.lighthouse sigp/lighthouse \
|
||||
lighthouse --testnet MY_TESTNET bn --staking --http-address 0.0.0.0
|
||||
```
|
||||
|
||||
```bash
|
||||
$ docker run \
|
||||
--network host \
|
||||
-v $HOME/.lighthouse:/root/.lighthouse \
|
||||
sigp/lighthouse \
|
||||
lighthouse --testnet MY_TESTNET 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!
|
||||
@ -1,4 +1,4 @@
|
||||
# Importing from the Ethereum 2.0 Launchpad
|
||||
# Importing from the Ethereum 2.0 Launch pad
|
||||
|
||||
The [Eth2 Lauchpad](https://github.com/ethereum/eth2.0-deposit) is a website
|
||||
from the Ethereum Foundation which guides users how to use the
|
||||
@ -20,7 +20,7 @@ Whilst following the steps on the website, users are instructed to download the
|
||||
repository. This `eth2-deposit-cli` script will generate the validator BLS keys
|
||||
into a `validator_keys` directory. We assume that the user's
|
||||
present-working-directory is the `eth2-deposit-cli` repository (this is where
|
||||
you will be if you just ran the `./deposit.sh` script from the Eth2 Launchpad
|
||||
you will be if you just ran the `./deposit.sh` script from the Eth2 Launch pad
|
||||
website). If this is not the case, simply change the `--directory` to point to
|
||||
the `validator_keys` directory.
|
||||
|
||||
@ -30,6 +30,9 @@ using the standard `validators` directory (specify a different one using
|
||||
|
||||
### 1. Run the `lighthouse account validator import` command.
|
||||
|
||||
Docker users should use the command from the [Docker](#docker)
|
||||
section, all other users can use:
|
||||
|
||||
|
||||
```bash
|
||||
lighthouse account validator import --directory validator_keys
|
||||
@ -85,3 +88,22 @@ INFO Enabled validator voting_pubkey: 0xa5e8702533f6d66422e042a0bf3471ab9b
|
||||
Once this log appears (and there are no errors) the `lighthouse vc` application
|
||||
will ensure that the validator starts performing its duties and being rewarded
|
||||
by the protocol. There is no more input required from the user.
|
||||
|
||||
## Docker
|
||||
|
||||
The `import` command is a little more complex for Docker users, but the example
|
||||
in this document can be substituted with:
|
||||
|
||||
```bash
|
||||
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
|
||||
```
|
||||
|
||||
Here we use two `-v` volumes to attach:
|
||||
|
||||
- `~/.lighthouse` on the host to `/root/.lighthouse` in the Docker container.
|
||||
- The `validator_keys` directory in the present working directory of the host
|
||||
to the `/root/validator_keys` directory of the Docker container.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user