* Refactor documentation, ef_tests makefile * Add makefile to root * Tidy readme * Fix readme badges * Tidy logs * Add terminalize gif * Update readme image * Update readme image * Tidy logs * Update readme image * Update readme * Update readme * Fix book link * Update makefiles * Update book * Fix link in book * Add readme for book * Remove old docs, move api spec YAML * Fix eth2/ dir readme * Add readme for lcli * Add about this book section * Minor formatting improvements * Address mehdi's comments
4.7 KiB
Testnets
The Lighthouse CLI has a testnet sub-command to allow creating or connecting
to Eth2 beacon chain testnets.
For detailed documentation, use the --help flag on the CLI:
$ ./beacon_node testnet --help
$ ./validator_client testnet --help
Examples
All examples assume a working development environment and
commands are based in the target/release directory (this is the build dir for
cargo).
Start a beacon node given a validator count and genesis_time
To start a brand-new beacon node (with no history) use:
$ ./beacon_node testnet -f quick 8 <GENESIS_TIME>
Where GENESIS_TIME is in unix time.
Notes:
- This method conforms the "Quick-start genesis" method in the
ethereum/eth2.0-pmrepository.- The
-fflag ignores any existing database or configuration, backing them up before re-initializing.8is the validator count and1567222226is the genesis time.- See
$ ./beacon_node testnet quick --helpfor more configuration options.
Start a beacon node given a genesis state file
A genesis state can be read from file using the testnet file subcommand.
There are three supported formats:
ssz(default)jsonyaml
Start a new node using /tmp/genesis.ssz as the genesis state:
$ ./beacon_node testnet --spec minimal -f file ssz /tmp/genesis.ssz
Notes:
- The
-fflag ignores any existing database or configuration, backing them up before re-initializing.- See
$ ./beacon_node testnet file --helpfor more configuration options.- The
--specflag is required to allow SSZ parsing of fixed-length lists. Here theminimaleth2 specification is chosen, allowing for lower validator counts. See eth2.0-specs/configs for more info.
Start an auto-configured validator client
To start a brand-new validator client (with no history) use:
$ ./validator_client testnet -b insecure 0 8
Notes:
- The
-bflag means the validator client will "bootstrap" specs and config from the beacon node.- The
insecurecommand dictates that the interop keypairs will be used.- The
0 8indicates that this validator client should manage 8 validators, starting at validator 0 (the first deposited validator).- The validator client will try to connect to the beacon node at
localhost. See--helpto configure that address and other features.- The validator client will operate very unsafely in
testnetmode, happily swapping between chains and creating double-votes.
Exporting a genesis file
Genesis states can downloaded from a running Lighthouse node via the HTTP API. Three content-types are supported:
application/jsonapplication/yamlapplication/ssz
Using curl, a genesis state can be downloaded to /tmp/genesis.ssz:
$ curl --header "Content-Type: application/ssz" "localhost:5052/beacon/state/genesis" -o /tmp/genesis.ssz
Advanced
Below are some CLI commands useful when working with testnets.
Specify a boot node by multiaddr
You can specify a static list of multiaddrs when booting Lighthouse using
the --libp2p-addresses command.
Example:
$ ./beacon_node --libp2p-addresses /ip4/192.168.0.1/tcp/9000
Specify a boot node by ENR (Ethereum Name Record)
You can specify a static list of Discv5 addresses when booting Lighthouse using
the --boot-nodes command.
Example:
$ ./beacon_node --boot-nodes -IW4QB2Hi8TPuEzQ41Cdf1r2AUU1FFVFDBJdJyOkWk2qXpZfFZQy2YnJIyoT_5fnbtrXUouoskmydZl4pIg90clIkYUDgmlwhH8AAAGDdGNwgiMog3VkcIIjKIlzZWNwMjU2azGhAjg0-DsTkQynhJCRnLLttBK1RS78lmUkLa-wgzAi-Ob5
Avoid port clashes when starting nodes
Starting a second Lighthouse node on the same machine will fail due to TCP/UDP
port collisions. Use the -b (--port-bump) flag to increase all listening
ports by some n.
Example:
Increase all ports by 10 (using multiples of 10 is recommended).
$ ./beacon_node -b 10
Start a testnet with a custom slot time
Lighthouse can run at quite low slot times when there are few validators (e.g.,
500 ms slot times should be fine for 8 validators).
Example:
The -t (--slot-time) flag specifies the milliseconds per slot.
$ ./beacon_node testnet -t 500 recent 8
Note:
bootstraploads the slot time via HTTP and therefore conflicts with this flag.