mirror of
https://gitlab.com/pulsechaincom/lighthouse-pulse.git
synced 2024-12-22 03:30:38 +00:00
Add newly created mdbook
This commit is contained in:
parent
5f0509be50
commit
14ea6f7710
1
book/.gitignore
vendored
Normal file
1
book/.gitignore
vendored
Normal file
@ -0,0 +1 @@
|
||||
book
|
6
book/book.toml
Normal file
6
book/book.toml
Normal file
@ -0,0 +1,6 @@
|
||||
[book]
|
||||
authors = ["Paul Hauner"]
|
||||
language = "en"
|
||||
multilingual = false
|
||||
src = "src"
|
||||
title = "Lighthouse"
|
7
book/src/SUMMARY.md
Normal file
7
book/src/SUMMARY.md
Normal file
@ -0,0 +1,7 @@
|
||||
# Summary
|
||||
|
||||
* [Introduction](./intro.md)
|
||||
* [Development Environment](./setup.md)
|
||||
* [Testnets](./testnets.md)
|
||||
* [Simple local testnet](./testnets.md)
|
||||
* [Interop](./interop.md)
|
70
book/src/interop.md
Normal file
70
book/src/interop.md
Normal file
@ -0,0 +1,70 @@
|
||||
# Lighthouse Interop Guide
|
||||
|
||||
This guide is intended for other Ethereum 2.0 client developers performing
|
||||
inter-operability testing with Lighthouse.
|
||||
|
||||
To allow for faster iteration cycles without the "merging to master" overhead,
|
||||
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.**
|
||||
|
||||
## Environment
|
||||
|
||||
All that is required for inter-op is a built and tested [development
|
||||
environment](setup). 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.
|
||||
|
||||
## Interop Procedure
|
||||
|
||||
The following scenarios are documented:
|
||||
|
||||
- [Starting a "quick-start" beacon node](#quick-start-beacon-node) from a
|
||||
`(validator_count, genesis)` tuple.
|
||||
- [Starting a validator client](#validator-client) with `n` interop keypairs.
|
||||
- [Starting a node from a genesis state file](#starting-from-a-genesis-file).
|
||||
- [Exporting a genesis state file](#exporting-a-genesis-file) from a running Lighthouse
|
||||
node.
|
||||
|
||||
First, setup a Lighthouse development environment and navigate to the
|
||||
`target/release` directory (this is where the binaries are located).
|
||||
|
||||
#### Quick-start Beacon Node
|
||||
|
||||
|
||||
To start the node (each time creating a fresh database and configuration in
|
||||
`~/.lighthouse`), use:
|
||||
|
||||
```
|
||||
$ ./beacon_node testnet -f quick 8 1567222226
|
||||
```
|
||||
|
||||
>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.
|
||||
|
||||
#### Validator Client
|
||||
|
||||
**TODO**
|
||||
|
||||
#### Starting from a genesis file
|
||||
|
||||
**TODO**
|
||||
|
||||
#### Exporting a genesis file
|
||||
|
||||
**TODO**
|
47
book/src/intro.md
Normal file
47
book/src/intro.md
Normal file
@ -0,0 +1,47 @@
|
||||
# Lighthouse Documentation
|
||||
|
||||
[![Build Status]][Build Link] [![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
|
||||
[Doc Link]: http://lighthouse-docs.sigmaprime.io/
|
||||
|
||||
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.
|
||||
|
||||
## Developer Resources
|
||||
|
||||
Documentation is provided for **researchers and developers** working on
|
||||
Ethereum 2.0 and assumes prior knowledge on the topic.
|
||||
|
||||
- Get started with [development environment setup](setup.html).
|
||||
- [Run a simple testnet](testnets.html) in Only Three CLI Commands™.
|
||||
- Read about our interop workflow.
|
||||
- API?
|
||||
|
||||
## Release
|
||||
|
||||
Ethereum 2.0 is not fully specified or implemented and as such, Lighthouse is
|
||||
still **under development**.
|
||||
|
||||
We are on-track to provide a public, multi-client testnet in late-2019 and an
|
||||
initial production-grade blockchain in 2020.
|
||||
|
||||
## Features
|
||||
|
||||
Lighthouse has been in development since mid-2018 and has an extensive feature
|
||||
set:
|
||||
|
||||
- Libp2p networking stack, featuring Discovery v5.
|
||||
- Optimized `BeaconChain` state machine, up-to-date and
|
||||
passing all tests.
|
||||
- RESTful HTTP API.
|
||||
- Documented and feature-rich CLI interface.
|
||||
- Capable of running small, local testnets with 250ms slot times.
|
||||
- Detailed metrics exposed in the Prometheus format.
|
65
book/src/setup.md
Normal file
65
book/src/setup.md
Normal file
@ -0,0 +1,65 @@
|
||||
# Development Environment Setup
|
||||
|
||||
Follow this guide to get a Lighthouse development environment up-and-running.
|
||||
|
||||
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 build dependencies using your package manager.
|
||||
- `$ <package-manager> clang protobuf libssl-dev cmake git-lfs`
|
||||
- Ensure [git-lfs](https://git-lfs.github.com/) is installed with `git lfs
|
||||
install`.
|
||||
1. Clone the [sigp/lighthouse](https://github.com/sigp/lighthouse), ensuring to
|
||||
**initialize submodules**.
|
||||
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.
|
||||
|
||||
_Note: first-time compilation may take several minutes._
|
||||
|
||||
## Detailed instructions
|
||||
|
||||
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
|
||||
- `git-lfs`: The Git extension for [Large File
|
||||
Support](https://git-lfs.github.com/) (required for Ethereum Foundation
|
||||
test vectors).
|
||||
1. Clone the repository with submodules: `git clone --recursive
|
||||
https://github.com/sigp/lighthouse`. If you're already cloned the repo,
|
||||
ensure testing submodules are present: `$ git submodule init; git
|
||||
submodule update`
|
||||
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`.
|
||||
|
||||
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"`.
|
64
book/src/testnets.md
Normal file
64
book/src/testnets.md
Normal file
@ -0,0 +1,64 @@
|
||||
# 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.
|
||||
|
||||
1. Start the first node: `$ ./beacon_node testnet -f recent 8`
|
||||
1. Start a validator client: **TODO**
|
||||
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
|
||||
```
|
||||
|
||||
> 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**
|
||||
|
||||
## 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
|
||||
```
|
||||
|
||||
> 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