mirror of
https://github.com/sigp/lighthouse.git
synced 2026-03-03 00:31:50 +00:00
Refactor docs into mdbook (#547)
* 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
This commit is contained in:
Paul Hauner
17
book/README.md
Normal file
17
book/README.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# Lighthouse Book
|
||||
|
||||
Contains an [mdBook](https://github.com/rust-lang-nursery/mdBook) that serves
|
||||
as the primary source of Lighthouse user documentation.
|
||||
|
||||
The book is hosted at [lighthouse-book.sigmaprime.io](http://lighthouse-book.sigmaprime.io).
|
||||
|
||||
## Usage
|
||||
|
||||
The [mdBook docs](https://github.com/rust-lang-nursery/mdBook#usage) are the
|
||||
best source of information for building the book.
|
||||
|
||||
### Example
|
||||
|
||||
1. Install mdBook: `$ cargo install mdbook`
|
||||
1. Build the book, open it in a browser and build after file changes: `$ mdbook
|
||||
watch --open`
|
||||
@@ -3,4 +3,4 @@ authors = ["Paul Hauner"]
|
||||
language = "en"
|
||||
multilingual = false
|
||||
src = "src"
|
||||
title = "Lighthouse"
|
||||
title = "Lighthouse Book"
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
# Summary
|
||||
|
||||
* [Introduction](./intro.md)
|
||||
* [Development Environment](./setup.md)
|
||||
* [Websocket Interface](./websockets.md)
|
||||
* [Simple Local Testnet](./simple-testnet.md)
|
||||
* [Interop](./interop.md)
|
||||
* [Environment](./interop-environment.md)
|
||||
* [CLI Overview](./interop-cli.md)
|
||||
* [Scenarios](./interop-scenarios.md)
|
||||
* [Cheat-sheet](./interop-cheat-sheet.md)
|
||||
* [CLI](./cli.md)
|
||||
* [Testnets](./testnets.md)
|
||||
* [Simple Local Testnet](./simple-testnet.md)
|
||||
* [API](./api.md)
|
||||
* [HTTP (RESTful JSON)](./http.md)
|
||||
* [WebSocket](./websockets.md)
|
||||
* [Contributing](./contributing.md)
|
||||
* [Development Environment](./setup.md)
|
||||
* [CI & Testing](./ci.md)
|
||||
|
||||
13
book/src/api.md
Normal file
13
book/src/api.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# APIs
|
||||
|
||||
The Lighthouse `beacon_node` provides two APIs for local consumption:
|
||||
|
||||
- A [RESTful JSON HTTP API](http.html) which provides beacon chain, node and network
|
||||
information.
|
||||
- A read-only [WebSocket API](websockets.html) providing beacon chain events, as they occur.
|
||||
|
||||
|
||||
## Security
|
||||
|
||||
These endpoints are not designed to be exposed to the public Internet or
|
||||
untrusted users. They may pose a considerable DoS attack vector when used improperly.
|
||||
33
book/src/ci.md
Normal file
33
book/src/ci.md
Normal file
@@ -0,0 +1,33 @@
|
||||
# Contiguous Integration (CI) and Testing
|
||||
|
||||
Lighthouse uses a self-hosted Gitlab CI server to run tests and deploy docs.
|
||||
|
||||
For security reasons, **CI will only be run automatically for Lighthouse
|
||||
maintainers.** Contributors without maintainer privileges will need to have CI
|
||||
triggered for them prior to a PR being merged.
|
||||
|
||||
You can see the full set of tests we run in the
|
||||
[gitlab-ci.yml](https://github.com/sigp/lighthouse/blob/master/.gitlab-ci.yml)
|
||||
file. The following two commands should complete successfully before CI can
|
||||
pass:
|
||||
|
||||
```bash
|
||||
$ cargo test --all --all-features
|
||||
$ cargo fmt --all --check
|
||||
```
|
||||
|
||||
_Note: Travis CI is also used, however it does not run the full test suite._
|
||||
|
||||
### Ethereum 2.0 Spec Tests
|
||||
|
||||
The
|
||||
[ethereum/eth2.0-spec-tests](https://github.com/ethereum/eth2.0-spec-tests/)
|
||||
repository contains a large set of tests that verify Lighthouse behaviour
|
||||
against the Ethereum Foundation specifications.
|
||||
|
||||
These tests are quite large (100's of MB), so we don't download them by
|
||||
default. Developers should ensure they have downloaded these tests using the
|
||||
`Makefile` in
|
||||
[tests/ef_tests](https://github.com/sigp/lighthouse/tree/master/tests/ef_tests).
|
||||
|
||||
**Failures in these tests should prevent CI from passing.**
|
||||
62
book/src/cli.md
Normal file
62
book/src/cli.md
Normal file
@@ -0,0 +1,62 @@
|
||||
# Command-Line Interface (CLI)
|
||||
|
||||
Lighthouse a collection of CLI applications. The two primary binaries are:
|
||||
|
||||
- `beacon_node`: the largest and most fundamental component which connects to
|
||||
the p2p network, processes messages and tracks the head of the beacon
|
||||
chain.
|
||||
- `validator_client`: a lightweight but important component which loads a validators private
|
||||
key and signs messages using a `beacon_node` as a source-of-truth.
|
||||
|
||||
There are also some ancillary binaries:
|
||||
|
||||
- `account_manager`: generates cryptographic keys.
|
||||
- `lcli`: a general-purpose utility for troubleshooting Lighthouse state
|
||||
transitions (developer tool).
|
||||
|
||||
## Installation
|
||||
|
||||
Presently, we recommend building Lighthouse using the `$ cargo build --release
|
||||
--all` command and executing binaries from the
|
||||
`<lighthouse-repository>/target/release` directory.
|
||||
|
||||
## Documentation
|
||||
|
||||
Each binary supports the `--help` flag, this is the best source of
|
||||
documentation.
|
||||
|
||||
|
||||
```bash
|
||||
$ ./beacon_node --help
|
||||
```
|
||||
|
||||
```bash
|
||||
$ ./validator_client --help
|
||||
```
|
||||
|
||||
```bash
|
||||
$ ./account_manager --help
|
||||
```
|
||||
|
||||
```bash
|
||||
$ ./lcli --help
|
||||
```
|
||||
|
||||
## Beacon Node
|
||||
|
||||
The `beacon_node` CLI has two primary tasks:
|
||||
|
||||
- **Resuming** an existing database with `$ ./beacon_node`.
|
||||
- **Creating** a new testnet database using `$ ./beacon_node testnet`.
|
||||
|
||||
## Creating a new database
|
||||
|
||||
Use the `$./beacon_node testnet` command (see [testnets](./testnets.md) for more
|
||||
information).
|
||||
|
||||
## Resuming from an existing database
|
||||
|
||||
Once a database has been created, it can be resumed by running `$ ./beacon_node`.
|
||||
|
||||
Presently, this command will fail if no existing database is found. You must
|
||||
use the `$ ./beacon_node testnet` command to create a new database.
|
||||
118
book/src/contributing.md
Normal file
118
book/src/contributing.md
Normal file
@@ -0,0 +1,118 @@
|
||||
# Contributing to Lighthouse
|
||||
|
||||
[![Chat Badge]][Chat Link]
|
||||
|
||||
[Chat Badge]: https://img.shields.io/badge/chat-discord-%237289da
|
||||
[Chat Link]: https://discord.gg/cyAszAh
|
||||
|
||||
|
||||
Lighthouse welcomes contributions. If you are interested in contributing to the
|
||||
Ethereum ecosystem, and you want to learn Rust, Lighthouse is a great project
|
||||
to work on.
|
||||
|
||||
To start contributing,
|
||||
|
||||
1. Setup a [development environment](./setup.md).
|
||||
2. Browse through the [open issues](https://github.com/sigp/lighthouse/issues)
|
||||
(tip: look for the [good first
|
||||
issue](https://github.com/sigp/lighthouse/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)
|
||||
tag).
|
||||
3. Comment on an issue before starting work.
|
||||
4. Share your work via a pull-request.
|
||||
|
||||
If you have questions, please reach out via
|
||||
[Discord](https://discord.gg/cyAszAh).
|
||||
|
||||
## Ethereum 2.0
|
||||
|
||||
Lighthouse is an implementation of the Ethereum 2.0 specification, as defined
|
||||
in the [ethereum/eth2.0-specs](https://github.com/ethereum/eth2.0-specs)
|
||||
repository.
|
||||
|
||||
We recommend reading Danny Ryan's (incomplete) [Phase 0 for
|
||||
Humans](https://notes.ethereum.org/@djrtwo/Bkn3zpwxB?type=view) before diving
|
||||
into the canonical spec.
|
||||
|
||||
## Rust
|
||||
|
||||
Lighthouse adheres to Rust code conventions as outlined in the [**Rust
|
||||
Styleguide**](https://github.com/rust-dev-tools/fmt-rfcs/blob/master/guide/guide.md).
|
||||
|
||||
Please use [clippy](https://github.com/rust-lang/rust-clippy) and
|
||||
[rustfmt](https://github.com/rust-lang/rustfmt) to detect common mistakes and
|
||||
inconsistent code formatting:
|
||||
|
||||
```bash
|
||||
$ cargo clippy --all
|
||||
$ cargo fmt --all --check
|
||||
```
|
||||
|
||||
### Panics
|
||||
|
||||
Generally, **panics should be avoided at all costs**. Lighthouse operates in an
|
||||
adversarial environment (the Internet) and it's a severe vulnerability if
|
||||
people on the Internet can cause Lighthouse to crash via a panic.
|
||||
|
||||
Always prefer returning a `Result` or `Option` over causing a panic. For
|
||||
example, prefer `array.get(1)?` over `array[1]`.
|
||||
|
||||
If you know there won't be a panic but can't express that to the compiler,
|
||||
use `.expect("Helpful message")` instead of `.unwrap()`. Always provide
|
||||
detailed reasoning in a nearby comment when making assumptions about panics.
|
||||
|
||||
### TODOs
|
||||
|
||||
All `TODO` statements should be accompanied by a GitHub issue.
|
||||
|
||||
```rust
|
||||
pub fn my_function(&mut self, _something &[u8]) -> Result<String, Error> {
|
||||
// TODO: something_here
|
||||
// https://github.com/sigp/lighthouse/issues/XX
|
||||
}
|
||||
```
|
||||
|
||||
### Comments
|
||||
|
||||
**General Comments**
|
||||
|
||||
* Prefer line (``//``) comments to block comments (``/* ... */``)
|
||||
* Comments can appear on the line prior to the item or after a trailing space.
|
||||
```rust
|
||||
// Comment for this struct
|
||||
struct Lighthouse {}
|
||||
fn make_blockchain() {} // A comment on the same line after a space
|
||||
```
|
||||
|
||||
**Doc Comments**
|
||||
|
||||
* The ``///`` is used to generate comments for Docs.
|
||||
* The comments should come before attributes.
|
||||
|
||||
```rust
|
||||
/// Stores the core configuration for this Lighthouse instance.
|
||||
/// This struct is general, other components may implement more
|
||||
/// specialized config structs.
|
||||
#[derive(Clone)]
|
||||
pub struct LighthouseConfig {
|
||||
pub data_dir: PathBuf,
|
||||
pub p2p_listen_port: u16,
|
||||
}
|
||||
```
|
||||
|
||||
### Rust Resources
|
||||
|
||||
Rust is an extremely powerful, low-level programming language that provides
|
||||
freedom and performance to create powerful projects. The [Rust
|
||||
Book](https://doc.rust-lang.org/stable/book/) provides insight into the Rust
|
||||
language and some of the coding style to follow (As well as acting as a great
|
||||
introduction and tutorial for the language).
|
||||
|
||||
Rust has a steep learning curve, but there are many resources to help. We
|
||||
suggest:
|
||||
|
||||
* [Rust Book](https://doc.rust-lang.org/stable/book/)
|
||||
* [Rust by example](https://doc.rust-lang.org/stable/rust-by-example/)
|
||||
* [Learning Rust With Entirely Too Many Linked Lists](http://cglab.ca/~abeinges/blah/too-many-lists/book/)
|
||||
* [Rustlings](https://github.com/rustlings/rustlings)
|
||||
* [Rust Exercism](https://exercism.io/tracks/rust)
|
||||
* [Learn X in Y minutes - Rust](https://learnxinyminutes.com/docs/rust/)
|
||||
85
book/src/http.md
Normal file
85
book/src/http.md
Normal file
@@ -0,0 +1,85 @@
|
||||
# HTTP API
|
||||
|
||||
[![Swagger Badge]][Swagger Link]
|
||||
|
||||
[Swagger Badge]: https://img.shields.io/badge/Open%20API-0.2.0-success
|
||||
[Swagger Link]: https://app.swaggerhub.com/apis-docs/spble/lighthouse_rest_api/0.2.0
|
||||
|
||||
|
||||
**The Lighthouse API is documented in Open API format and is available at
|
||||
[SwaggerHub: Lighthouse REST
|
||||
API](https://app.swaggerhub.com/apis-docs/spble/lighthouse_rest_api/0.2.0).**
|
||||
|
||||
By default, a Lighthouse `beacon_node` exposes a HTTP server on `localhost:5052`.
|
||||
|
||||
The following CLI flags control the HTTP server:
|
||||
|
||||
- `--no-api`: disable the HTTP server.
|
||||
- `--api-port`: specify the listen port of the server.
|
||||
- `--api-address`: specify the listen address of the server.
|
||||
|
||||
## Examples
|
||||
|
||||
In addition to the complete Open API docs (see above), some examples are
|
||||
provided below.
|
||||
|
||||
_Examples assume there is a Lighthouse node exposing a HTTP API on
|
||||
`localhost:5052`. Responses are JSON._
|
||||
|
||||
### Get the node's beacon chain head
|
||||
|
||||
```bash
|
||||
$ curl localhost:5052/beacon/head
|
||||
|
||||
{"slot":0,"block_root":"0x827bf71805540aa13f6d8c7d18b41b287b2094a4d7a28cbb8deb061dbf5df4f5","state_root":"0x90a78d73294bc9c7519a64e1912161be0e823eb472012ff54204e15a4d717fa5"}%
|
||||
```
|
||||
|
||||
### Get the node's finalized checkpoint
|
||||
|
||||
```bash
|
||||
$ curl localhost:5052/beacon/latest_finalized_checkpoint
|
||||
|
||||
{"epoch":0,"root":"0x0000000000000000000000000000000000000000000000000000000000000000"}%
|
||||
```
|
||||
|
||||
### Get the node's ENR
|
||||
|
||||
```bash
|
||||
$ curl localhost:5052/network/enr
|
||||
|
||||
"-IW4QFyf1VlY5pZs0xZuvKMRZ9_cdl9WMCDAAJXZiZiuGcfRYoU40VPrYDLQj5prneJIz3zcbTjHp9BbThc-yiymJO8HgmlwhH8AAAGDdGNwgiMog3VkcIIjKIlzZWNwMjU2azGhAjg0-DsTkQynhJCRnLLttBK1RS78lmUkLa-wgzAi-Ob5"%
|
||||
```
|
||||
|
||||
### Get a list of connected peer ids
|
||||
|
||||
```bash
|
||||
$ curl localhost:5052/network/peers
|
||||
|
||||
["QmeMFRTWfo3KbVG7dEBXGhyRMa29yfmnJBXW84rKuGEhuL"]%
|
||||
```
|
||||
|
||||
### Get the node's peer id
|
||||
|
||||
```bash
|
||||
$ curl localhost:5052/network/peer_id
|
||||
|
||||
"QmRD1qs2AqNNRdBcGHUGpUGkpih5cmdL32mhh22Sy79xsJ"%
|
||||
```
|
||||
|
||||
### Get the list of listening libp2p addresses
|
||||
|
||||
Lists all the libp2p multiaddrs that the node is listening on.
|
||||
|
||||
```bash
|
||||
$ curl localhost:5052/network/listen_addresses
|
||||
|
||||
["/ip4/127.0.0.1/tcp/9000","/ip4/192.168.1.121/tcp/9000","/ip4/172.17.0.1/tcp/9000","/ip4/172.42.0.1/tcp/9000","/ip6/::1/tcp/9000","/ip6/fdd3:c293:1bc::203/tcp/9000","/ip6/fdd3:c293:1bc:0:9aa9:b2ea:c610:44db/tcp/9000"]%
|
||||
```
|
||||
|
||||
### Pretty-print the genesis state and state root
|
||||
|
||||
Returns the genesis state and state root in your terminal, in YAML.
|
||||
|
||||
```bash
|
||||
$ curl --header "Content-Type: application/yaml" "localhost:5052/beacon/state?slot=0"
|
||||
```
|
||||
@@ -1,149 +0,0 @@
|
||||
# Interop Cheat-sheet
|
||||
|
||||
This document contains a list of tips and tricks that may be useful during
|
||||
interop testing.
|
||||
|
||||
- When starting a beacon node:
|
||||
- [Specify a boot node by multiaddr](#boot-node-multiaddr)
|
||||
- [Specify a boot node by ENR](#boot-node-enr)
|
||||
- [Avoid port clashes when starting multiple nodes](#port-bump)
|
||||
- [Specify a custom slot time](#slot-time)
|
||||
- Using the beacon node HTTP API:
|
||||
- [Pretty-print the genesis state and state root](#http-state)
|
||||
- [Curl a node's ENR](#http-enr)
|
||||
- [Curl a node's connected peers](#http-peer-ids)
|
||||
- [Curl a node's local peer id](#http-peer-id)
|
||||
- [Curl a node's listening multiaddrs](#http-listen-addresses)
|
||||
- [Curl a node's beacon chain head](#http-head)
|
||||
- [Curl a node's finalized checkpoint](#http-finalized)
|
||||
|
||||
## Category: CLI
|
||||
|
||||
The `--help` command provides detail on the CLI interface. Here are some
|
||||
interop-specific CLI commands.
|
||||
|
||||
<a name="boot-node-multiaddr"></a>
|
||||
### 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
|
||||
```
|
||||
|
||||
<a name="boot-node-enr"></a>
|
||||
### Specify a boot node by ENR
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
<a name="port-bump"></a>
|
||||
### 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
|
||||
```
|
||||
|
||||
<a name="slot-time"></a>
|
||||
### 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: `bootstrap` loads the slot time via HTTP and therefore conflicts with
|
||||
> this flag.
|
||||
|
||||
## Category: HTTP API
|
||||
|
||||
Examples assume there is a Lighthouse node exposing a HTTP API on
|
||||
`localhost:5052`. Responses are JSON.
|
||||
|
||||
<a name="http-state"></a>
|
||||
### Pretty-print the genesis state and state root
|
||||
|
||||
Returns the genesis state and state root in your terminal, in YAML.
|
||||
|
||||
```
|
||||
$ curl --header "Content-Type: application/yaml" "localhost:5052/beacon/state?slot=0"
|
||||
```
|
||||
|
||||
<a name="http-enr"></a>
|
||||
### Get the node's ENR
|
||||
|
||||
```
|
||||
$ curl localhost:5052/network/enr
|
||||
|
||||
"-IW4QFyf1VlY5pZs0xZuvKMRZ9_cdl9WMCDAAJXZiZiuGcfRYoU40VPrYDLQj5prneJIz3zcbTjHp9BbThc-yiymJO8HgmlwhH8AAAGDdGNwgiMog3VkcIIjKIlzZWNwMjU2azGhAjg0-DsTkQynhJCRnLLttBK1RS78lmUkLa-wgzAi-Ob5"%
|
||||
```
|
||||
|
||||
<a name="http-peer-ids"></a>
|
||||
### Get a list of connected peer ids
|
||||
|
||||
```
|
||||
$ curl localhost:5052/network/peers
|
||||
|
||||
["QmeMFRTWfo3KbVG7dEBXGhyRMa29yfmnJBXW84rKuGEhuL"]%
|
||||
```
|
||||
|
||||
<a name="http-peer-id"></a>
|
||||
### Get the node's peer id
|
||||
|
||||
```
|
||||
curl localhost:5052/network/peer_id
|
||||
|
||||
"QmRD1qs2AqNNRdBcGHUGpUGkpih5cmdL32mhh22Sy79xsJ"%
|
||||
```
|
||||
|
||||
<a name="http-listen-addresses"></a>
|
||||
### Get the list of listening libp2p addresses
|
||||
|
||||
Lists all the libp2p multiaddrs that the node is listening on.
|
||||
|
||||
```
|
||||
curl localhost:5052/network/listen_addresses
|
||||
|
||||
["/ip4/127.0.0.1/tcp/9000","/ip4/192.168.1.121/tcp/9000","/ip4/172.17.0.1/tcp/9000","/ip4/172.42.0.1/tcp/9000","/ip6/::1/tcp/9000","/ip6/fdd3:c293:1bc::203/tcp/9000","/ip6/fdd3:c293:1bc:0:9aa9:b2ea:c610:44db/tcp/9000"]%
|
||||
```
|
||||
|
||||
<a name="http-head"></a>
|
||||
### Get the node's beacon chain head
|
||||
|
||||
```
|
||||
curl localhost:5052/beacon/head
|
||||
|
||||
{"slot":0,"block_root":"0x827bf71805540aa13f6d8c7d18b41b287b2094a4d7a28cbb8deb061dbf5df4f5","state_root":"0x90a78d73294bc9c7519a64e1912161be0e823eb472012ff54204e15a4d717fa5"}%
|
||||
```
|
||||
|
||||
<a name="http-finalized"></a>
|
||||
### Get the node's finalized checkpoint
|
||||
|
||||
```
|
||||
curl localhost:5052/beacon/latest_finalized_checkpoint
|
||||
|
||||
{"epoch":0,"root":"0x0000000000000000000000000000000000000000000000000000000000000000"}%
|
||||
```
|
||||
@@ -1,29 +0,0 @@
|
||||
# Interop CLI Overview
|
||||
|
||||
The Lighthouse CLI has two primary tasks:
|
||||
|
||||
- **Resuming** an existing database with `$ ./beacon_node`.
|
||||
- **Creating** a new testnet database using `$ ./beacon_node testnet`.
|
||||
|
||||
_See [Scenarios](./interop-scenarios.md) for methods we've anticipated will be
|
||||
used interop._
|
||||
|
||||
## Creating a new database
|
||||
|
||||
There are several methods for creating a new beacon node database:
|
||||
|
||||
- `quick`: using the `(validator_client, genesis_time)` tuple.
|
||||
- `recent`: as above but `genesis_time` is set to the start of some recent time
|
||||
window.
|
||||
- `file`: loads the genesis file from disk in one of multiple formats.
|
||||
- `bootstrap`: a Lighthouse-specific method where we connect to a running node
|
||||
and download it's specification and genesis state via the HTTP API.
|
||||
|
||||
See `$ ./beacon_node testnet --help` for more detail.
|
||||
|
||||
## Resuming from an existing database
|
||||
|
||||
Once a database has been created, it can be resumed by running `$ ./beacon_node`.
|
||||
|
||||
Presently, this command will fail if no existing database is found. You must
|
||||
use the `$ ./beacon_node testnet` command to create a new database.
|
||||
@@ -1,30 +0,0 @@
|
||||
# Interop Environment
|
||||
|
||||
All that is required for inter-op is a built and tested [development
|
||||
environment](./setup.md).
|
||||
|
||||
## Repositories
|
||||
|
||||
You will only require the [sigp/lighthouse](http://github.com/sigp/lighthouse)
|
||||
library.
|
||||
|
||||
To allow for faster build/test iterations we will use the
|
||||
[`interop`](https://github.com/sigp/lighthouse/tree/interop) branch of
|
||||
[sigp/lighthouse](https://github.com/sigp/lighthouse/tree/interop) for
|
||||
September 2019 interop. **Please use ensure you `git checkout interop` after
|
||||
cloning the repo.**
|
||||
|
||||
## File System
|
||||
|
||||
When lighthouse boots, it will create the following
|
||||
directories:
|
||||
|
||||
- `~/.lighthouse`: database and configuration for the beacon node.
|
||||
- `~/.lighthouse-validator`: database and configuration for the validator
|
||||
client.
|
||||
|
||||
After building the binaries with `cargo build --release --all`, there will be a
|
||||
`target/release` directory in the root of the Lighthouse repository. This is
|
||||
where the `beacon_node` and `validator_client` binaries are located.
|
||||
|
||||
You do not need to create any of these directories manually.
|
||||
@@ -1,101 +0,0 @@
|
||||
# Interop Scenarios
|
||||
|
||||
Here we demonstrate some expected interop scenarios.
|
||||
|
||||
All scenarios assume a working [development environment](./setup.md) and
|
||||
commands are based in the `target/release` directory (this is the build dir for
|
||||
`cargo`).
|
||||
|
||||
Additional functions can be found in the [interop
|
||||
cheat-sheet](./interop-cheat-sheet.md).
|
||||
|
||||
### Table of contents
|
||||
|
||||
- [Starting from a`validator_count, genesis_time` tuple](#quick-start)
|
||||
- [Starting a node from a genesis state file](#state-file)
|
||||
- [Starting a validator client](#val-client)
|
||||
- [Exporting a genesis state file](#export) from a running Lighthouse
|
||||
node
|
||||
|
||||
|
||||
<a name="quick-start"></a>
|
||||
### Start 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](https://duckduckgo.com/?q=unix+time&t=ffab&ia=answer).
|
||||
|
||||
> 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.
|
||||
|
||||
<a name="state-file"></a>
|
||||
### Start 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)
|
||||
- `json`
|
||||
- `yaml`
|
||||
|
||||
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 `-f` flag ignores any existing database or configuration, backing them
|
||||
> up before re-initializing.
|
||||
> - See `$ ./beacon_node testnet file --help` for more configuration options.
|
||||
> - The `--spec` flag is required to allow SSZ parsing of fixed-length lists.
|
||||
|
||||
<a name="val-client"></a>
|
||||
### 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 `-b` flag means the validator client will "bootstrap" specs and config
|
||||
> from the beacon node.
|
||||
> - The `insecure` command dictates that 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 unsafely in `testnet` mode, happily
|
||||
> swapping between chains and creating double-votes.
|
||||
|
||||
<a name="export"></a>
|
||||
### Exporting a genesis file
|
||||
|
||||
Genesis states can downloaded from a running Lighthouse node via the HTTP API. Three content-types are supported:
|
||||
|
||||
- `application/json`
|
||||
- `application/yaml`
|
||||
- `application/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
|
||||
```
|
||||
@@ -1,11 +0,0 @@
|
||||
# Lighthouse Interop Guide
|
||||
|
||||
This guide is intended for other Ethereum 2.0 client developers performing
|
||||
inter-operability testing with Lighthouse.
|
||||
|
||||
## Chapters
|
||||
|
||||
- Read about the required [development environment](./interop-environment.md).
|
||||
- Get an [overview](./interop-cli.md) of the Lighthouse CLI.
|
||||
- See how we expect to handle some [interop scenarios](./interop-scenarios.md).
|
||||
- See the [interop cheat-sheet](./interop-cheat-sheet.md) for useful CLI tips.
|
||||
@@ -1,9 +1,9 @@
|
||||
# Lighthouse Documentation
|
||||
# Lighthouse Book
|
||||
|
||||
[![Build Status]][Build Link] [![Doc Status]][Doc Link] [![Chat Badge]][Chat Link]
|
||||
_Documentation for Lighthouse users and developers._
|
||||
|
||||
[![Doc Status]][Doc Link] [![Chat Badge]][Chat Link]
|
||||
|
||||
[Build Status]: https://gitlab.sigmaprime.io/sigp/lighthouse/badges/master/build.svg
|
||||
[Build Link]: https://gitlab.sigmaprime.io/sigp/lighthouse/pipelines
|
||||
[Chat Badge]: https://img.shields.io/badge/chat-discord-%237289da
|
||||
[Chat Link]: https://discord.gg/cyAszAh
|
||||
[Doc Status]:https://img.shields.io/badge/rust--docs-master-orange
|
||||
@@ -12,16 +12,27 @@
|
||||
Lighthouse is an **Ethereum 2.0 client** that connects to other Ethereum 2.0
|
||||
clients to form a resilient and decentralized proof-of-stake blockchain.
|
||||
|
||||
It is written in Rust, maintained by Sigma Prime and funded by the Ethereum
|
||||
Foundation, Consensys and other individuals and organisations.
|
||||
We implement the specification as defined in the
|
||||
[ethereum/eth2.0-specs](https://github.com/ethereum/eth2.0-specs) repository.
|
||||
|
||||
## Developer Resources
|
||||
## Topics
|
||||
|
||||
Documentation is presently targeted at **researchers and developers**. It
|
||||
assumes significant prior knowledge of Ethereum 2.0.
|
||||
|
||||
Topics:
|
||||
You may read this book from start to finish, or jump to some of these topics:
|
||||
|
||||
- Get started with [development environment setup](./setup.md).
|
||||
- See the [interop docs](./interop.md).
|
||||
- [Run a simple testnet](./simple-testnet.md) in Only Three CLI Commands™.
|
||||
- Utilize the whole stack by starting a [simple local testnet](./simple-testnet.md).
|
||||
- Query the [RESTful HTTP API](./http.md) using `curl`.
|
||||
- Listen to events with the [JSON WebSocket API](./websockets.md).
|
||||
- View the [Rust code docs](http://lighthouse-docs.sigmaprime.io/).
|
||||
|
||||
|
||||
Prospective contributors can read the [Contributing](./contributing.md) section
|
||||
to understand how we develop and test Lighthouse.
|
||||
|
||||
## About this Book
|
||||
|
||||
This book is open source, contribute at
|
||||
[github.com/sigp/lighthouse/book](https://github.com/sigp/lighthouse/tree/master/book).
|
||||
|
||||
The Lighthouse CI/CD system maintains a hosted version of the `master` branch
|
||||
at [lighthouse-book.sigmaprime.io](http://lighthouse-book.sigmaprime.io).
|
||||
|
||||
@@ -1,81 +1,29 @@
|
||||
# Development Environment Setup
|
||||
|
||||
Follow this guide to get a Lighthouse development environment up-and-running.
|
||||
## Linux, MacOS & Windows
|
||||
|
||||
See the [Quick instructions](#quick-instructions) for a summary or the
|
||||
[Detailed instructions](#detailed-instructions) for clarification.
|
||||
|
||||
## Quick instructions
|
||||
|
||||
1. Install Rust + Cargo with [rustup](https://rustup.rs/).
|
||||
1. Install Rust and Cargo with [rustup](https://rustup.rs/).
|
||||
- Use the `stable` toolchain (it's the default).
|
||||
1. Install build dependencies using your package manager.
|
||||
- `$ <package-manager> clang protobuf libssl-dev cmake`
|
||||
1. Clone the [sigp/lighthouse](https://github.com/sigp/lighthouse).
|
||||
1. In the root of the repo, run the tests with `cargo test --all --release`.
|
||||
1. Then, build the binaries with `cargo build --all --release`.
|
||||
1. Lighthouse is now fully built and tested.
|
||||
- `clang`, `protobuf`, `libssl-dev`, `cmake`
|
||||
1. Clone the [github.com/sigp/lighthouse](https://github.com/sigp/lighthouse)
|
||||
repository.
|
||||
1. Run `$ make` to build Lighthouse.
|
||||
1. Run `$ make test` to run the test suite
|
||||
- If you experience any failures, please reach out on
|
||||
[discord](https://discord.gg/cyAszAh).
|
||||
- Developers use `$ make test-full` to ensure you have the full set of
|
||||
test vectors.
|
||||
|
||||
_Note: first-time compilation may take several minutes._
|
||||
> - The `beacon_node`, `validator_client` and other binaries are created in
|
||||
> `target/release` directory.
|
||||
> - First-time compilation may take several minutes.
|
||||
|
||||
## Detailed instructions
|
||||
### Windows
|
||||
|
||||
A fully-featured development environment can be achieved with the following
|
||||
steps:
|
||||
|
||||
1. Install [rustup](https://rustup.rs/).
|
||||
1. Use the command `rustup show` to get information about the Rust
|
||||
installation. You should see that the active tool-chain is the stable
|
||||
version.
|
||||
- Updates can be performed using` rustup update`, Lighthouse generally
|
||||
requires a recent version of Rust.
|
||||
1. Install build dependencies (Arch packages are listed here, your
|
||||
distribution will likely be similar):
|
||||
- `clang`: required by RocksDB.
|
||||
- `protobuf`: required for protobuf serialization (gRPC)
|
||||
- `libssl-dev`: also gRPC
|
||||
- `cmake`: required for building protobuf
|
||||
1. Clone the repository with submodules: `git clone
|
||||
https://github.com/sigp/lighthouse`.
|
||||
1. Change directory to the root of the repository.
|
||||
1. Run the test suite with `cargo test --all --release`. The build and test
|
||||
process can take several minutes. If you experience any failures on
|
||||
`master`, please raise an
|
||||
[issue](https://github.com/sigp/lighthouse/issues).
|
||||
|
||||
### Notes:
|
||||
|
||||
Lighthouse targets Rust `stable` but generally runs on `nightly` too.
|
||||
|
||||
#### Note for Windows users:
|
||||
|
||||
Perl may also be required to build lighthouse. You can install [Strawberry
|
||||
Perl](http://strawberryperl.com/), or alternatively use a choco install command
|
||||
`choco install strawberryperl`.
|
||||
Perl may also be required to build Lighthouse. You can install [Strawberry
|
||||
Perl](http://strawberryperl.com/), or alternatively if you're using the [Chocolatey](https://chocolatey.org/) package manager for Windows, use the following choco install command: `choco install strawberryperl`.
|
||||
|
||||
Additionally, the dependency `protoc-grpcio v0.3.1` is reported to have issues
|
||||
compiling in Windows. You can specify a known working version by editing
|
||||
version in `protos/Cargo.toml` section to `protoc-grpcio = "<=0.3.0"`.
|
||||
|
||||
## eth2.0-spec-tests
|
||||
|
||||
The
|
||||
[ethereum/eth2.0-spec-tests](https://github.com/ethereum/eth2.0-spec-tests/)
|
||||
repository contains a large set of tests that verify Lighthouse behaviour
|
||||
against the Ethereum Foundation specifications.
|
||||
|
||||
The `tests/ef_tests` crate runs these tests and it has some interesting
|
||||
behaviours:
|
||||
|
||||
- If the `tests/ef_tests/eth2.0-spec-tests` directory is not present, all tests
|
||||
indicate a `pass` when they did not actually run.
|
||||
- If that directory _is_ present, the tests are executed faithfully, failing if
|
||||
a discrepancy is found.
|
||||
|
||||
The `tests/ef_tests/eth2.0-spec-tests` directory is not present by default. To
|
||||
obtain it, use the Makefile in the root of the repository:
|
||||
|
||||
```
|
||||
make ef_tests
|
||||
```
|
||||
|
||||
_Note: this will download 100+ MB of test files from the [ethereum/eth2.0-spec-tests](https://github.com/ethereum/eth2.0-spec-tests/)._
|
||||
|
||||
@@ -1,32 +1,24 @@
|
||||
# Simple Local Testnet
|
||||
|
||||
You can setup a local, two-node testnet in **Only Three CLI Commands™**.
|
||||
|
||||
Follow the [Quick instructions](#tldr) version if you're confident, or see
|
||||
[Detailed instructions](#detail) for more.
|
||||
|
||||
|
||||
## Quick instructions
|
||||
|
||||
Setup a development environment, build the project and navigate to the
|
||||
`target/release` directory.
|
||||
With a functional [development environment](./setup.md), starting a local multi-node
|
||||
testnet is easy:
|
||||
|
||||
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`
|
||||
1. Start more nodes with `$ ./beacon_node -b 10 testnet -f bootstrap
|
||||
http://localhost:5052`
|
||||
- Increment the `-b` value by `10` for each additional node.
|
||||
|
||||
_Repeat #3 to add more nodes._
|
||||
|
||||
## Detailed instructions
|
||||
## 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
|
||||
## Starting a beacon node
|
||||
|
||||
Start a new node (creating a fresh database and configuration in `~/.lighthouse`), using:
|
||||
|
||||
```
|
||||
```bash
|
||||
$ ./beacon_node testnet -f recent 8
|
||||
```
|
||||
|
||||
@@ -38,11 +30,11 @@ $ ./beacon_node testnet -f recent 8
|
||||
> - See `$ ./beacon_node testnet recent --help` for more configuration options,
|
||||
> including `minimal`/`mainnet` specification.
|
||||
|
||||
## Starting the Validator Client
|
||||
## Starting a validator client
|
||||
|
||||
In a new terminal window, start the validator client with:
|
||||
|
||||
```
|
||||
```bash
|
||||
$ ./validator_client testnet -b insecure 0 8
|
||||
```
|
||||
|
||||
@@ -57,15 +49,15 @@ $ ./validator_client testnet -b insecure 0 8
|
||||
> - 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
|
||||
## 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:
|
||||
In a new terminal window, run:
|
||||
|
||||
|
||||
```
|
||||
```bash
|
||||
$ ./beacon_node -b 10 testnet -r bootstrap
|
||||
```
|
||||
|
||||
|
||||
@@ -1,10 +1,158 @@
|
||||
# Testnets
|
||||
|
||||
Lighthouse does not offer a public testnet _yet_. In the meantime, it's easy to
|
||||
start a local testnet:
|
||||
The Lighthouse CLI has a `testnet` sub-command to allow creating or connecting
|
||||
to Eth2 beacon chain testnets.
|
||||
|
||||
- [Run a simple testnet](testnets.html) in Only Three CLI Commands™.
|
||||
- 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
|
||||
built-in metrics and monitoring dashboards, all from your local machine.
|
||||
For detailed documentation, use the `--help` flag on the CLI:
|
||||
|
||||
```bash
|
||||
$ ./beacon_node testnet --help
|
||||
```
|
||||
|
||||
```bash
|
||||
$ ./validator_client testnet --help
|
||||
```
|
||||
|
||||
## Examples
|
||||
|
||||
All examples assume a working [development environment](./setup.md) 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:
|
||||
|
||||
```bash
|
||||
$ ./beacon_node testnet -f quick 8 <GENESIS_TIME>
|
||||
```
|
||||
|
||||
Where `GENESIS_TIME` is in [unix time](https://duckduckgo.com/?q=unix+time&t=ffab&ia=answer).
|
||||
|
||||
> 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.
|
||||
|
||||
### 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)
|
||||
- `json`
|
||||
- `yaml`
|
||||
|
||||
Start a new node using `/tmp/genesis.ssz` as the genesis state:
|
||||
|
||||
```bash
|
||||
$ ./beacon_node testnet --spec minimal -f file ssz /tmp/genesis.ssz
|
||||
```
|
||||
|
||||
> Notes:
|
||||
>
|
||||
> - The `-f` flag ignores any existing database or configuration, backing them
|
||||
> up before re-initializing.
|
||||
> - See `$ ./beacon_node testnet file --help` for more configuration options.
|
||||
> - The `--spec` flag is required to allow SSZ parsing of fixed-length lists.
|
||||
> Here the `minimal` eth2 specification is chosen, allowing for lower
|
||||
> validator counts. See
|
||||
> [eth2.0-specs/configs](https://github.com/ethereum/eth2.0-specs/tree/dev/configs)
|
||||
> for more info.
|
||||
|
||||
### Start an auto-configured validator client
|
||||
|
||||
To start a brand-new validator client (with no history) use:
|
||||
|
||||
```bash
|
||||
$ ./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 dictates that 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 unsafely in `testnet` mode, 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/json`
|
||||
- `application/yaml`
|
||||
- `application/ssz`
|
||||
|
||||
Using `curl`, a genesis state can be downloaded to `/tmp/genesis.ssz`:
|
||||
|
||||
```bash
|
||||
$ 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:
|
||||
|
||||
```bash
|
||||
$ ./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:
|
||||
|
||||
```bash
|
||||
$ ./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).
|
||||
|
||||
```bash
|
||||
$ ./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.
|
||||
|
||||
```bash
|
||||
$ ./beacon_node testnet -t 500 recent 8
|
||||
```
|
||||
|
||||
> Note: `bootstrap` loads the slot time via HTTP and therefore conflicts with
|
||||
> this flag.
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Websocket Interface
|
||||
# Websocket API
|
||||
|
||||
By default, a Lighthouse `beacon_node` exposes a websocket server on `localhost:5053`.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user