Update interop docs with val client CLI
This commit is contained in:
parent
457e04f1e0
commit
d445ae6ee8
@ -46,20 +46,36 @@ To start the node (each time creating a fresh database and configuration in
|
||||
```
|
||||
$ ./beacon_node testnet -f quick 8 1567222226
|
||||
```
|
||||
|
||||
>This method conforms the ["Quick-start
|
||||
> Notes:
|
||||
>
|
||||
> - This method conforms the ["Quick-start
|
||||
genesis"](https://github.com/ethereum/eth2.0-pm/tree/6e41fcf383ebeb5125938850d8e9b4e9888389b4/interop/mocked_start#quick-start-genesis)
|
||||
method in the `ethereum/eth2.0-pm` repository.
|
||||
>
|
||||
> The `-f` flag ignores any existing database or configuration, backing them up
|
||||
before re-initializing. `8` is the validator count and `1567222226` is the
|
||||
genesis time.
|
||||
>
|
||||
> See `$ ./beacon_node testnet quick --help` for more configuration options.
|
||||
> - The `-f` flag ignores any existing database or configuration, backing them
|
||||
> up before re-initializing.
|
||||
> - `8` is the validator count and `1567222226` is the genesis time.
|
||||
> - See `$ ./beacon_node testnet quick --help` for more configuration options.
|
||||
|
||||
#### Validator Client
|
||||
|
||||
**TODO**
|
||||
Start the validator client with:
|
||||
|
||||
```
|
||||
$ ./validator_client testnet -b insecure 0 8
|
||||
```
|
||||
> Notes:
|
||||
>
|
||||
> - The `-b` flag means the validator client will "bootstrap" specs and config
|
||||
> from the beacon node.
|
||||
> - The `insecure` command means the [interop
|
||||
> keypairs](https://github.com/ethereum/eth2.0-pm/tree/6e41fcf383ebeb5125938850d8e9b4e9888389b4/interop/mocked_start#pubkeyprivkey-generation)
|
||||
> will be used.
|
||||
> - The `0 8` indicates 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 `--help` to configure that address and other features.
|
||||
> - The validator client will operate very loosely in `testnet` mode, happily
|
||||
> swapping between chains and creating double-votes.
|
||||
|
||||
#### Starting from a genesis file
|
||||
|
||||
|
@ -12,7 +12,7 @@ Setup a development environment, build the project and navigate to the
|
||||
`target/release` directory.
|
||||
|
||||
1. Start the first node: `$ ./beacon_node testnet -f recent 8`
|
||||
1. Start a validator client: **TODO**
|
||||
1. Start a validator client: `$ ./validator_client testnet -b insecure 0 8`
|
||||
1. Start another node `$ ./beacon_node -b 10 testnet -f bootstrap http://localhost:5052`
|
||||
|
||||
_Repeat #3 to add more nodes._
|
||||
@ -30,16 +30,32 @@ Start a new node (creating a fresh database and configuration in `~/.lighthouse`
|
||||
$ ./beacon_node testnet -f recent 8
|
||||
```
|
||||
|
||||
> The `-f` flag ignores any existing database or configuration, backing them up
|
||||
before re-initializing. `8` is number of validators with deposits in the
|
||||
genesis state.
|
||||
> Notes:
|
||||
>
|
||||
> See `$ ./beacon_node testnet recent --help` for more configuration options,
|
||||
including `minimal`/`mainnet` specification.
|
||||
> - The `-f` flag ignores any existing database or configuration, backing them
|
||||
> up before re-initializing.
|
||||
> - `8` is number of validators with deposits in the genesis state.
|
||||
> - See `$ ./beacon_node testnet recent --help` for more configuration options,
|
||||
> including `minimal`/`mainnet` specification.
|
||||
|
||||
## Starting the Validator Client
|
||||
|
||||
**TODO**
|
||||
In a new terminal window, start the validator client with:
|
||||
|
||||
```
|
||||
$ ./validator_client testnet -b insecure 0 8
|
||||
```
|
||||
|
||||
> Notes:
|
||||
>
|
||||
> - The `-b` flag means the validator client will "bootstrap" specs and config
|
||||
> from the beacon node.
|
||||
> - The `insecure` command uses predictable, well-known private keys. Since
|
||||
> this is just a local testnet, these are fine.
|
||||
> - The `0 8` indicates 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 `--help` to configure that address and other features.
|
||||
|
||||
## Adding another Beacon Node
|
||||
|
||||
@ -53,12 +69,12 @@ In a new terminal terminal, run:
|
||||
$ ./beacon_node -b 10 testnet -r bootstrap http://localhost:5052
|
||||
```
|
||||
|
||||
> The `-b` (or `--port-bump`) increases all the listening TCP/UDP ports of the
|
||||
new node to `10` higher. Your first node's HTTP server was at TCP `5052` but
|
||||
this one will be at `5062`.
|
||||
> Notes:
|
||||
>
|
||||
> The `-r` flag creates a new data directory in your home with a random string
|
||||
appended, to avoid conflicting with any other running node.
|
||||
>
|
||||
> The HTTP address is the API of the first node. The new node will download
|
||||
configuration via HTTP before starting sync via libp2p.
|
||||
> - The `-b` (or `--port-bump`) increases all the listening TCP/UDP ports of
|
||||
> the new node to `10` higher. Your first node's HTTP server was at TCP
|
||||
> `5052` but this one will be at `5062`.
|
||||
> - The `-r` flag creates a new data directory in your home with a random
|
||||
> string appended, to avoid conflicting with any other running node.
|
||||
> - The HTTP address is the API of the first node. The new node will download
|
||||
> configuration via HTTP before starting sync via libp2p.
|
||||
|
Loading…
Reference in New Issue
Block a user