0c3fdcd57c
* Renamed fork_choice::process_attestation_from_block * Processing attestation in fork choice * Retrieving state from store and checking signature * Looser check on beacon state validity. * Cleaned up get_attestation_state * Expanded fork choice api to provide latest validator message. * Checking if the an attestation contains a latest message * Correct process_attestation error handling. * Copy paste error in comment fixed. * Tidy ancestor iterators * Getting attestation slot via helper method * Refactored attestation creation in test utils * Revert "Refactored attestation creation in test utils" This reverts commit 4d277fe4239a7194758b18fb5c00dfe0b8231306. * Integration tests for free attestation processing * Implicit conflicts resolved. * formatting * Do first pass on Grants code * Add another attestation processing test * Tidy attestation processing * Remove old code fragment * Add non-compiling half finished changes * Simplify, fix bugs, add tests for chain iters * Remove attestation processing from op pool * Fix bug with fork choice, tidy * Fix overly restrictive check in fork choice. * Ensure committee cache is build during attn proc * Ignore unknown blocks at fork choice * Various minor fixes * Make fork choice write lock in to read lock * Remove unused method * Tidy comments * Fix attestation prod. target roots change * Fix compile error in store iters * Reject any attestation prior to finalization * Begin metrics refactor * Move beacon_chain to new metrics structure. * Make metrics not panic if already defined * Use global prometheus gather at rest api * Unify common metric fns into a crate * Add heavy metering to block processing * Remove hypen from prometheus metric name * Add more beacon chain metrics * Add beacon chain persistence metric * Prune op pool on finalization * Add extra prom beacon chain metrics * Prefix BeaconChain metrics with "beacon_" * Add more store metrics * Add basic metrics to libp2p * Add metrics to HTTP server * Remove old `http_server` crate * Update metrics names to be more like standard * Fix broken beacon chain metrics, add slot clock metrics * Add lighthouse_metrics gather fn * Remove http args * Fix wrong state given to op pool prune * Make prom metric names more consistent * Add more metrics, tidy existing metrics * Fix store block read metrics * Tidy attestation metrics * Fix minor PR comments * Fix minor PR comments * Remove duplicated attestation finalization check * Remove awkward `let` statement * Add first attempts at HTTP bootstrap * Add beacon_block methods to rest api * Fix serde for block.body.grafitti * Allow travis failures on beta (see desc) There's a non-backward compatible change in `cargo fmt`. Stable and beta do not agree. * Add network routes to API * Fix rustc warnings * Add best_slot method * Add --bootstrap arg to beacon node * Get bootstrapper working for ENR address * Store intermediate states during block processing * Allow bootstrapper to scrape libp2p address * Update bootstrapper libp2p address finding * Add comments * Tidy API to be more consistent with recent decisions * Address some review comments * Make BeaconChainTypes Send + Sync + 'static * Add `/network/listen_port` API endpoint * Abandon starting the node if libp2p doesn't start * Update bootstrapper for API changes * Remove unnecessary trait bounds |
||
|---|---|---|
| .github | ||
| account_manager | ||
| beacon_node | ||
| docs | ||
| eth2 | ||
| protos | ||
| tests | ||
| validator_client | ||
| .editorconfig | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .gitmodules | ||
| .travis.yml | ||
| Cargo.toml | ||
| CONTRIBUTING.md | ||
| Dockerfile | ||
| LICENSE | ||
| README.md | ||
Lighthouse: Ethereum 2.0
An open-source Ethereum 2.0 client, written in Rust and maintained by Sigma Prime.
Overview
Lighthouse is:
- Fully open-source, licensed under Apache 2.0.
- Security-focused, fuzzing has begun and security reviews are planned for late-2019.
- Built in Rust, a modern language providing unique safety guarantees and excellent performance (comparable to C++).
- Funded by various organisations, including Sigma Prime, the Ethereum Foundation, ConsenSys and private individuals.
- Actively working to promote an inter-operable, multi-client Ethereum 2.0.
Development Status
Lighthouse, like all Ethereum 2.0 clients, is a work-in-progress. Instructions are provided for running the client, however these instructions are designed for developers and researchers working on the project. We do not (yet) provide user-facing functionality.
Current development overview:
- Specification
v0.8.1implemented, optimized and passing test vectors. - Rust-native libp2p with Gossipsub and Discv5.
- Metrics via Prometheus.
- Basic gRPC API, soon to be replaced with RESTful HTTP/JSON.
Roadmap
- Early-September 2019:
lighthouse-0.0.1release: A stable testnet for developers with a useful HTTP API. - September 2019: Inter-operability with other Ethereum 2.0 clients.
- October 2019: Public, multi-client testnet with user-facing functionality.
- January 2020: Production Beacon Chain testnet.
Usage
Lighthouse consists of multiple binaries:
beacon_node/: produces and verifies blocks from the P2P connected validators and the P2P network. Provides an API for external services to interact with Ethereum 2.0.validator_client/: connects to abeacon_nodeand performs the role of a proof-of-stake validator.account_manager/: a stand-alone component providing key management and creation for validators.
Simple Local Testnet
Note: these instructions are intended for developers and researchers. We do not yet support end-users.
In this example we use the account_manager to create some keys, launch two
beacon_node instances and connect a validator_client to one. The two
beacon_nodes should stay in sync and build a Beacon Chain.
First, clone this repository, setup a development environment and navigate to the root directory of this repository.
Then, run $ cargo build --all --release and navigate to the target/release
directory and follow the steps:
1. Generate Validator Keys
Generate 16 validator keys and store them in ~/.lighthouse-validator:
$ ./account_manager -d ~/.lighthouse-validator generate_deterministic -i 0 -n 16
Note: these keys are for development only. The secret keys are deterministically generated from low integers. Assume they are public knowledge.
2. Start a Beacon Node
This node will act as the boot node and provide an API for the
validator_client.
$ ./beacon_node --recent-genesis --rpc
Note: --recent-genesis defines the genesis time as either the start of the
current hour, or half-way through the current hour (whichever is most recent).
This makes it very easy to create a testnet, but does not allow nodes to
connect if they were started in separate 30-minute windows.
3. Start Another Beacon Node
In another terminal window, start another boot that will connect to the running node.
The running node will display it's ENR as a base64 string. This ENR, by default, has a target address of 127.0.0.1 meaning that any new node will connect to this node via 127.0.0.1. If a boot node should be connected to on a different address, it should be run with the --discovery-address CLI flag to specify how other nodes may connect to it.
$ ./beacon_node -r --boot-nodes <boot-node-ENR> --listen-address 127.0.0.1 --port 9001 --datadir /tmp/.lighthouse
Here is the ENR string displayed in the terminal from the first node. The ENR can also be obtained from it's default directory .lighthouse/network/enr.dat.
The --datadir flag tells this Beacon Node to store it's files in a different
directory. If you're on a system that doesn't have a /tmp dir (e.g., Mac,
Windows), substitute this with any directory that has write access.
Note that all future created nodes can use the same boot-node ENR. Once connected to the boot node, all nodes should discover and connect with each other.
4. Start a Validator Client
In a third terminal window, start a validator client:
$ ./validator_client
You should be able to observe the validator signing blocks, the boot node processing these blocks and publishing them to the other node. If you have issues, try restarting the beacon nodes to ensure they have the same genesis time. Alternatively, raise an issue and include your terminal output.
Further Reading
- About Lighthouse: Goals, Ideology and Ethos surrounding this implementation.
- What is Ethereum Serenity: an introduction to Ethereum Serenity.
- Lighthouse Technical Documentation: The Rust generated documentation, updated regularly.
If you'd like some background on Sigma Prime, please see the Lighthouse Update #00 blog post or the company website.
Directory Structure
beacon_node/: the "Beacon Node" binary and crates exclusively associated with it.docs/: documentation related to the repository. This includes contributor guides, etc. (It does not include code documentation, which can be produced withcargo doc).eth2/: Crates containing common logic across the Lighthouse project. For example: Ethereum 2.0 types (BeaconBlock,BeaconState, etc) and SimpleSerialize (SSZ).protos/: protobuf/gRPC definitions that are common across the Lighthouse project.validator_client/: the "Validator Client" binary and crates exclusively associated with it.tests/: code specific to testing, most notably contains the Ethereum Foundation test vectors.
Contributing
Lighthouse welcomes contributors.
If you are looking to contribute, please head to our onboarding documentation.
If you'd like to contribute, try having a look through the open issues (tip: look for the good first issue tag) and ping us on the gitter channel. We need your support!
Contact
The best place for discussion is the Lighthouse Discord server. Alternatively, you may use the sigp/lighthouse gitter.
Donations
If you support the cause, we accept donations to help fund development:
0x25c4a76E7d118705e7Ea2e9b7d8C59930d8aCD3b (donation.sigmaprime.eth)