owned this note
owned this note
Published
Linked with GitHub
# Starting a Lighthouse Eth1-Based Testnet
Requirements:
- The [sigp/lighthouse](http://github.com/sigp/lighthouse) repository, with the `lighthouse` binary built (run `make` in the repo root).
- [lcli: lighthouse CLI](https://github.com/sigp/lighthouse/tree/master/lcli): a developer tool that is used for most parts of the testnet configuration. From the from the root of the `lighthouse` directory, run `cargo install --path lcli`. Ensure it's installed by running `lcli --help`.
- A local Geth node (fast-synced is fine). `lcli` assumes it is available on `localhost:8545`, you can tell it otherwise using the `--eth1-endpoint` flag.
- On your Geth node, an account at `accounts[0]` with some göETH for deploying contracts and submitting deposits. You should have the password to this account available in a file on disk. We'll use the `$ETH1_PASSWORD_FILE` to refer to this location (e.g., `/home/karlm/my-password.txt`).
- [Docker Compose](https://docs.docker.com/compose/), if you happen to choose the paths that involve it (it's the easiest way).
- The [sigp/lighthouse-docker](https://github.com/sigp/lighthouse-docker) repository, if you choose the docker-compose path.
## 1. Deploy an eth1 deposit contract
You can deploy an instance of the [sigp/unsafe-eth2-deposit-contract](https://github.com/sigp/unsafe-eth2-deposit-contract) using the following command:
`$ lcli deploy-deposit-contract --password $ETH1_PASSWORD_FILE`
If successful, it will print the address of the newly created contract to the CLI. It will also print the block the contract was deployed at.
> Note: The deposit contract is "unsafe" because the owner can call a function to refund all the ETH at any time. This is very useful for testnets.
## 2. Produce a testnet configuration
Use the `lcli new-testnet` command to produce an [eth2-testnets](https://github.com/eth2-clients/eth2-testnets) directory; this directory will define your testnet. Lighthouse nodes that wish to connect to your testnet can use this directory via the `--testnet-dir` flag.
### Example
Approximately this command was used to start the lighthouse "testnet5" testnet (some values changed for the sake of these docs).
The directory will be placed in the default location of `~/.lighthouse/testnet`.
**Important: substitute the `--deposit-contract-address` and `--deposit-contract-deploy-block` with the values generated in the previous step.**
```bash
$ lcli \
new-testnet \
--min-genesis-time 0 \
--min-genesis-delay 3600 \
--min-genesis-active-validator-count 16 \
--min-deposit-amount 10000000 \
--max-effective-balance 3200000000 \
--effective-balance-increment 100000000 \
--ejection-balance 1600000000 \
--eth1-follow-distance 16 \
--genesis-fork-version 0x01030307 \
--deposit-contract-address 0xa4d8bee071d57ccf47d2bf9f2cc8dd9151e21e42 \
--deposit-contract-deploy-block 2175173
```
## 3. Submit validator deposits and start the beacon node & validator client
Create your validator public keys and submit their deposits to the eth1 chain.
Here you can choose your own destiny; [use docker-compose](#using-docker-compose) or do it [manually](#manually).
### Using docker-compose
In the root of the `sigp/lighthouse-docker` repository, create a `.env` file like this:
**TODO: this file says to use `localhost:5052` for the eth1 node, that won't work. It needs to be able to hit the eth1 node on the host somehow..**
```bash
# The logging level.
#
# Set to `debug` or `trace` for detailed information.
DEBUG_LEVEL=debug
# Set to anything other than empty to start the validator client.
START_VALIDATOR=true
# Validator settings
#
# The following settings are only required if `START_VALIDATOR` is enabled and
# `VALIDATOR_COUNT` is greater than zero.
# The number of validators that should be created on first boot.
VALIDATOR_COUNT=16
# Set to anything other than empty to start a geth instance.
#
# Only required if `VALIDATOR_COUNT` is greater than zero or `VOTING_ETH1_NODE`
# is not set to some external geth node.
START_GETH=true
# This is the node that beacon nodes should use whilst they are running and
# producing blocks. Does not require any accounts.
VOTING_ETH1_NODE=http://geth:8545
# The amount in gwei that will be deposited to initialize the validator.
#
# This must reflect the amount transferred with the deposit transaction,
# otherwise the contract will reject the transaction.
DEPOSIT_VALUE=3200000000
# Set to anything other than empty to submit the deposits to the eth1 chain.
#
# Leave this empty if you intend to submit the deposit via the Lighthouse docs
# (Metamask).
SEND_DEPOSITS=true
# Password to ETH1 account with deposit ETH.
PASSWORD_FILE=/home/karlm/my-password.txt
# This node is used for submitting deposits and is required to have an account
# at index 0 with some Goerli ETH. The eth1 node should run with equivalent configuration:
#
# geth --goerli --rpc --rpcapi web3,personal,eth --allow-insecure-unlock --rpcaddr 0.0.0.0
#
# Only necessary if `SEND_DEPOSITS == true`
DEPOSITS_ETH1_NODE=http://localhost:8545
```
Once this file is created, run:
`$ docker-compose up -d && docker-compose logs --follow`
This should perform the following actions:
1. Generate 16x validator keys
2. Create an eth1 deposit for each of those validator keys.
3. Start a beacon node
4. Start a validator client running those 16 validators.
## Manually
Only follow this step if you didn't follow the previous docker-compose step.
### 3.1 Use `lighthouse account` to generate validator keys and submit deposits
This command will create `16` validators, each with a 3.2 ETH deposit using the eth1 node at `localhost:8545`.
```bash
$ lighthouse \
account \
validator \
new \
--send-deposits \
--password $ETH1_PASSWORD_FILE \
--deposit-value 3200000000 \
random \
16
```
> Note: this command will first generate the validator keys then submit the deposits to the eth1 chain. If any of these deposits fail, the process will exit. There is presently no clear way to recover from this situation (but it is recoverable). Reach out on our Discord if this happens to you.
### 3.2 Start a beacon node
This will start a beacon node that's running the HTTP API (`--http`) on `127.0.0.1:5052` and connecting to an eth1 node (`--eth1`) at `localhost:8545`.
`$ lighthouse bn --http --eth1`
### 3.3 Start a validator client
This will start a validator client using the keys we generated two steps earlier and connecting to the beacon node we started in the previous step.
`$ lighthouse vc`
## 4. Generate a `genesis.ssz` file
_This step is technically optional, but it will complete the testnet dir we generated in step 2._
Run `$ lcli eth1-genesis` and wait for it to exit successfully.
This will connect to your eth1 node on `localhost:8545` and wait until sufficient deposits have been made to your deposit contract. Then, it will create a genesis `BeaconState` and save it as `genesis.ssz` in your testnet dir (probably at `.lighthouse/testnet`).
## 5. Wait for the beacon chain to start
The beacon chain genesis time will be set to between `MIN_GENESIS_DELAY` and `MIN_GENESIS_DELAY * 2` seconds from the timestamp of the eth1 block which first includes `MIN_GENESIS_ACTIVE_VALIDATOR_COUNT` validators. Once this arrives, your validators should start producing blocks and the chain will start!