mirror of
https://gitlab.com/pulsechaincom/lighthouse-pulse.git
synced 2025-01-03 17:54:28 +00:00
Update book
This commit is contained in:
parent
a78b030f58
commit
aa3bc6bf67
@ -3,5 +3,6 @@
|
|||||||
* [Introduction](./intro.md)
|
* [Introduction](./intro.md)
|
||||||
* [Development Environment](./setup.md)
|
* [Development Environment](./setup.md)
|
||||||
* [Testnets](./testnets.md)
|
* [Testnets](./testnets.md)
|
||||||
* [Simple local testnet](./testnets.md)
|
* [Simple Local Testnet](./simple-testnet.md)
|
||||||
* [Interop](./interop.md)
|
* [Interop](./interop.md)
|
||||||
|
* [Interop Tips & Tricks](./interop-tips.md)
|
||||||
|
@ -67,14 +67,14 @@ $ ./validator_client testnet -b insecure 0 8
|
|||||||
>
|
>
|
||||||
> - The `-b` flag means the validator client will "bootstrap" specs and config
|
> - The `-b` flag means the validator client will "bootstrap" specs and config
|
||||||
> from the beacon node.
|
> from the beacon node.
|
||||||
> - The `insecure` command means the [interop
|
> - The `insecure` command dictates that the [interop
|
||||||
> keypairs](https://github.com/ethereum/eth2.0-pm/tree/6e41fcf383ebeb5125938850d8e9b4e9888389b4/interop/mocked_start#pubkeyprivkey-generation)
|
> keypairs](https://github.com/ethereum/eth2.0-pm/tree/6e41fcf383ebeb5125938850d8e9b4e9888389b4/interop/mocked_start#pubkeyprivkey-generation)
|
||||||
> will be used.
|
> will be used.
|
||||||
> - The `0 8` indicates that this validator client should manage 8 validators,
|
> - The `0 8` indicates that this validator client should manage 8 validators,
|
||||||
> starting at validator 0 (the first deposited validator).
|
> starting at validator 0 (the first deposited validator).
|
||||||
> - The validator client will try to connect to the beacon node at `localhost`.
|
> - The validator client will try to connect to the beacon node at `localhost`.
|
||||||
> See `--help` to configure that address and other features.
|
> See `--help` to configure that address and other features.
|
||||||
> - The validator client will operate very loosely in `testnet` mode, happily
|
> - The validator client will operate very unsafely in `testnet` mode, happily
|
||||||
> swapping between chains and creating double-votes.
|
> swapping between chains and creating double-votes.
|
||||||
|
|
||||||
#### Starting from a genesis file
|
#### Starting from a genesis file
|
||||||
|
@ -21,7 +21,7 @@ Documentation is provided for **researchers and developers** working on
|
|||||||
Ethereum 2.0 and assumes prior knowledge on the topic.
|
Ethereum 2.0 and assumes prior knowledge on the topic.
|
||||||
|
|
||||||
- Get started with [development environment setup](setup.html).
|
- Get started with [development environment setup](setup.html).
|
||||||
- [Run a simple testnet](testnets.html) in Only Three CLI Commands™.
|
- [Run a simple testnet](simple-testnet.html) in Only Three CLI Commands™.
|
||||||
- Read about our interop workflow.
|
- Read about our interop workflow.
|
||||||
- API?
|
- API?
|
||||||
|
|
||||||
|
@ -1,80 +1,10 @@
|
|||||||
# Simple Local Testnet
|
# Testnets
|
||||||
|
|
||||||
You can setup a local, two-node testnet in **Only Three CLI Commands™**.
|
Lighthouse does not offer a public testnet _yet_. In the meantime, it's easy to
|
||||||
|
start a local testnet:
|
||||||
|
|
||||||
Follow the [Quick instructions](#tldr) version if you're confident, or see
|
- [Run a simple testnet](testnets.html) in Only Three CLI Commands™.
|
||||||
[Detailed instructions](#detail) for more.
|
- Developers of other Eth2 clients should see the [interop guide](interop.html).
|
||||||
|
- The [sigp/lighthouse-docker](https://github.com/sigp/lighthouse-docker) repo
|
||||||
|
contains a `docker-compose` setup that runs a multi-node network with
|
||||||
## Quick instructions
|
built-in metrics and monitoring dashboards, all from your local machine.
|
||||||
|
|
||||||
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: `$ ./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._
|
|
||||||
|
|
||||||
## Detailed instructions
|
|
||||||
|
|
||||||
First, setup a Lighthouse development environment and navigate to the
|
|
||||||
`target/release` directory (this is where the binaries are located).
|
|
||||||
|
|
||||||
## Starting the Beacon Node
|
|
||||||
|
|
||||||
Start a new node (creating a fresh database and configuration in `~/.lighthouse`), using:
|
|
||||||
|
|
||||||
```
|
|
||||||
$ ./beacon_node testnet -f recent 8
|
|
||||||
```
|
|
||||||
|
|
||||||
> Notes:
|
|
||||||
>
|
|
||||||
> - 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
|
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
You may connect another (non-validating) node to your local network using the
|
|
||||||
lighthouse `bootstrap` command.
|
|
||||||
|
|
||||||
In a new terminal terminal, run:
|
|
||||||
|
|
||||||
|
|
||||||
```
|
|
||||||
$ ./beacon_node -b 10 testnet -r bootstrap http://localhost:5052
|
|
||||||
```
|
|
||||||
|
|
||||||
> Notes:
|
|
||||||
>
|
|
||||||
> - 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