This Fortnight in Lighthouse...
As usual, we have been busy keeping up with the ever-expanding Ethereum 2.0 specification and managing development on Lighthouse. In this fortnight we:
- Officially became a proud Ethereum Grantee.
- Received support from Gitcoin in the form of issue bounties.
- Ramped up our integration of security into our development cycle with the addition of fuzzing tools.
- Began focusing on implementing libp2p Gossipsub, the present contender for the network layer of Ethereum 2.0. We've been implementing gossipsub in the Parity-maintained rust-libp2p library.
- Approved and merged our block pre-processing logic.
- Added a Contributors Guide to assist and encourage developers to join us on our Eth 2.0 journey.
- Corrected an issue in the shuffling specification.
The Sigma Prime team will be Berlin this week for the Web3 Summit and Prague next week for Devcon 4. Come say hello if you spot any of us!
Contributing to Lighthouse
We added a Contributors Guide and have had a number of developers take interest in the project. As an open-source project, we're ecstatic to have community participation on this project at all levels. If you're interested in the project and want to help out (regardless of experience) come chat with us on our dedicated gitter.
In particular, we'd like to give a shout-out to the devs that have been helping us out the last fortnight (in alphabetical order),
- aj07: improving docs for on-boarding contributors.
- g-r-a-n-t: cleaning up our SSZ implementation.
- johnomarkid: improving docs for on-boarding contributors.
- pinkiebell: updated the shuffling algorithm and imported our first YAML test vectors.
- ralexstokes: working on improving/replacing our bitfield implementation.
Lighthouse and Security
Security is imperative for any blockchain client, especially for Ethereum 2.0 clients which must remain online and active to perpetually vote and attest blocks on the beacon chain.
Consider the case that a malformed or malicious block is propagated across the network and crashes a number clients due to some unexpected input in an internal function of the client. A number of nasty things would eventuate, including validator penalties for being offline and increased block times due to absent block proposers.
To discover and address issues such as these, over the last fortnight we have started adding fuzzing tools into our development cycle in an attempt to discover any such vulnerabilities as the code gets built. Mehdi Zerouali has written a quick write-up discussing some of the tools and concepts in this blog post.
Gitcoin Bounties
Gitcoin has graciously added bounties to Lighthouse issues to further encourage community support. Thanks Gitcoin! In the following weeks, you can expect to see more in-depth and involved funded issues which that will be designed for on-boarding long-term contributors as we progress in lighthouse's development. In the meantime, you can check out the collection of funded issues (many of them are good for beginners) here: Lighthouse's funded Issues.
Lighthouse's Networking Stack
We've begun re-addressing the base networking components to be used in lighthouse. Specifically, we're addressing and building the networking layer that enables the clients to discover and communicate with each other over the internet. The general consensus thus far is for all Ethereum 2.0 clients to use libp2p's gossipsub protocol. Unfortunately for us, there is no Rust implementation. Although there are workarounds (such as using a libp2p daemon) we have started looking into extending Rust's implementation of libp2p (rust-libp2p) to include the desired gossipsub protocol. Expect an update on the progress of this in the next post!
What To Expect Next
In the following fortnight our main focus will be the following:
- Implementing more of the state transition logic of the Eth 2.0 spec.
- Integrating the fuzzing toolsets and applying them to specific completed crates in the repository.
- Extending rust-libp2p to include the gossipsub protocol.
- Implementing the FFG fork-choice rule.