Sigma Prime maintains the 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 instead. You'll need some experience with docker-compose to integrate your locally built docker image with the docker-compose environment.
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.
For more on installing Compose, see here.
Once you have Docker Compose installed, clone the sigp/lighthouse-docker repository:
git clone https://github.com/sigp/lighthouse-docker cd lighthouse-docker
Then, create a file named
.env with the following contents (these values are
DEBUG_LEVEL=info START_GETH=true START_VALIDATOR=true VALIDATOR_COUNT=1 VOTING_ETH1_NODE=http://geth:8545 DEPOSIT_VALUE=3200000000
.env file should live in the
lighthouse-docker directory alongside the
Start the docker-compose environment (you may need to prefix the below command with
Watch the output of this command for the
Saved new validator to disk 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:
validator_client_1 | Jan 10 12:06:05.632 INFO Saved new validator to disk voting_pubkey: 0x8fc28504448783b10b0a7f5a321505b07ad2ad8d6a8430b8868a0fcdedee43766bee725855506626085776e020dfa472
This is one of the first logs outputted, so you may have to scroll up or perform a search in your terminal to find it.
docker-compose upgenerates a new sub-directory -- to store your validator's deposit data, along with its voting and withdrawal keys -- in the
.lighthouse/validatorsdirectory. This sub-directory is identified by your validator's
voting_pubkeyyou 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_nodeto 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.
To find an estimate for how long your beacon node will take to finish syncing, look for logs that look like this:
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
If your beacon node hasn't finished syncing yet, you'll see some ERRO messages indicating that your node hasn't synced yet:
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 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!
In the next step you'll need to upload your validator's deposit data. This data is stored in a file called
You'll find it in
lighthouse-docker/.lighthouse/validators/ -- in the sub-directory that corresponds to your validator's public key (
For example, if you ran step 1 in
/home/karlm/, and your validator's
0x8592c7.., then you'll find your
eth1_deposit_data.rlpfile in the following directory:
Once you've located
eth1_deposit_data.rlp, you're ready to move on to Become a Validator: Step 2.