d727e55abe
## Issue Addressed `BlocksByRange` requests were the main culprit of a series of timeouts to peer's requests in general because they produce build up in the router's processor. Those were moved to the blocking executor but a task is being spawned for each; also not ideal since the amount of resources we give to those is not controlled ## Proposed Changes - Move `BlocksByRange` and `BlocksByRoots` to the `beacon_processor`. The processor crafts the responses and sends them. - Move too the processing of `StatusMessage`s from other peers. This is a fast operation but it can also build up and won't scale if we keep it in the router (processing one at the time). These don't need to send an answer, so there is no harm in processing them "later" if that were to happen. Sending responses to status requests is still in the router, so we answer as soon as we see them. - Some "extras" that are basically clean up: - Split the `Worker` logic in sync methods (chain processing and rpc blocks), gossip methods (the majority of methods) and rpc methods (the new ones) - Move the `status_message` function previously provided by the router's processor to a more central place since it is used by the router, sync, network_context and beacon_processor - Some spelling ## Additional Info What's left to decide/test more thoroughly is the length of the queues and the priority rules. @paulhauner suggested at some point to put status above attestations, and @AgeManning had described an importance of "protecting gossipsub" so my solution is leaving status requests in the router and RPC methods below attestations. Slashings and Exits are at the end. |
||
|---|---|---|
| .github | ||
| account_manager | ||
| beacon_node | ||
| book | ||
| boot_node | ||
| common | ||
| consensus | ||
| crypto | ||
| hooks | ||
| lcli | ||
| lighthouse | ||
| remote_signer | ||
| scripts | ||
| testing | ||
| validator_client | ||
| .dockerignore | ||
| .editorconfig | ||
| .gitignore | ||
| .gitmodules | ||
| bors.toml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CONTRIBUTING.md | ||
| Cross.toml | ||
| Dockerfile | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
Lighthouse: Ethereum 2.0
An open-source Ethereum 2.0 client, written in Rust and maintained by Sigma Prime.
🚨🚨🚨 Note: Lighthouse is not yet ready to produce mainnet deposits. The developers will require some time to test against the mainnet deposit contract, once it is released. DO NOT SUBMIT VALIDATOR DEPOSITS WITH LIGHTHOUSE. 🚨🚨🚨
Overview
Lighthouse is:
- Fully open-source, licensed under Apache 2.0.
- Security-focused. Fuzzing has begun and security reviews are underway.
- 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 involved in the specification and security analysis of the Ethereum 2.0 specification.
Like all Ethereum 2.0 clients, Lighthouse is a work-in-progress.
Eth2 Deposit Contract
The Lighthouse team acknowledges
0x00000000219ab540356cBB839Cbe05303d7705Fa
as the canonical Eth2 deposit contract address.
Development Status
Current development overview:
- Specification
v1.0.0implemented, optimized and passing test vectors. - Rust-native libp2p with Gossipsub and Discv5.
- RESTful JSON API via HTTP server.
- Events via WebSocket.
- Metrics via Prometheus.
Roadmap
April 2019: Inital single-client testnets.September 2019: Inter-operability with other Ethereum 2.0 clients.Q1 2020:lighthouse-0.1.0release: All major phase 0 features implemented.Q2 2020: Public, multi-client testnet with user-facing functionality.Q2 2020: Third-party security review.Q4 2020: Long-lived, multi-client Beacon Chain testnet- Q4 2020: Additional third-party security reviews.
- Q4 2020: Production Beacon Chain (tentative).
Documentation
The Lighthouse Book contains information for testnet users and developers.
If you'd like some background on Sigma Prime, please see the Lighthouse Update #00 blog post or sigmaprime.io.
Contributing
Lighthouse welcomes contributors.
If you are looking to contribute, please head to the Contributing section of the Lighthouse book.
Contact
The best place for discussion is the Lighthouse Discord server. Alternatively, you may use the sigp/lighthouse gitter.
Sign up to the Lighthouse Development Updates mailing list for email notifications about releases, network status and other important information.
Encrypt sensitive messages using our PGP key.
Donations
Lighthouse is an open-source project and a public good. Funding public goods is hard and we're grateful for the donations we receive from the community via:
- Gitcoin Grants.
- Ethereum address:
0x25c4a76E7d118705e7Ea2e9b7d8C59930d8aCD3b(donation.sigmaprime.eth).