With this post, we’re very excited to formally announce Lighthouse : an open-source Ethereum 2.0 client, written in Rust.
Lighthouse is embodied by a Github repository maintained by Sigma Prime, a team of developers and security professionals based in Sydney, Australia.
This post marks the first of many Lighthouse update posts where we will share our achievements, challenges and plans for the future. Today, we will introduce Sigma Prime, provide some fundamental information about the Lighthouse project, highlight some of the accomplishments of the project and outline a future for the project.
Sigma Prime
Sigma Prime (SigP, for short) was incorporated in late-October 2016, shortly after Ethereum Devcon 2 in Shanghai. Long prior, the founders had been working together in the crypto space: organising the Sydney Ethereum meetup, writing smart-contracts, building GPU miners and undertaking research.
During its first year, Sigma Prime saw itself develop two primary capacities; information security and software engineering. These activities were a reflection of the skill sets brought to the table by its founders and we see them as complimentary activities. The second year of SigP is nearing completion and has seen these skills flourish with the team performing security assessments on contracts and wallets, contributing to open-source, developing an encrypted messaging dApp, producing community resources and proudly providing cybersec services to the Ethereum Foundation.
Lighthouse Background
In early 2018 SigP started actively contributing to proof-of-stake (Casper) research. First, we produced a simple implementation of Casper TFG (“Vlad’s Casper”) — it simulated a set of nodes coming to consensus on a binary value and featured some Byzantine behaviour detection. Whilst working on TFG was very intellectually stimulating (huge credits to Vlad Zamfir et al. for their works), we saw that Casper FFG (“Vitalik’s Casper”) was most likely to be the first PoS mechanism to appear on Ethereum. Wishing to contribute in the immediate-term, we switched our focus to contributing on EIP-1011.
EIP-1011 was formally proposed and somewhat lead by Danny Ryan, an Ethereum Foundation researcher. EIP-1011 involved producing a Casper FFG voting smart-contract on-top-of the existing PoW mechanism. Danny was amazing in getting us involved and we quickly saw ourselves building testing frameworks, proposing changes to the Vyper contract and assisting in code review. It was not announced, but SigP had started efforts to build an open-source validator client.
In spite of all this hard work, EIP-1011 was short-lived and was deprecated in late-June 2018 in favour of the new “Ethereum 2.0” spec. Whilst it was disappointing to see some good code laid to rest, we respect this decision and see it as the best way to move forward. I won't go into detail here, but applying consensus-level voting to the PoW chain has many challenges including EVM bounds and new requirements for transaction ordering and gas-metering.
The Ethereum 2.0 spec captured our attention and we were confident that we could apply our resources to the project to help realise it. We immediately began porting the state transition logic in the ethereum/beacon_chain PoC over to Rust to ensure we had a crystal-clear understanding of the spec. We wrote this code in a repository named “rust_beacon_chain”.
At some point, we realised that we had the beginnings of a fully-fledged client on our hands and building that client out would provide great benefit to the ecosystem and greatly expand the skill set of our team. We decided to go ahead with the client build and renamed the repo to “Lighthouse”, figuring that a seaside lighthouse would be a “rusty beacon” of sorts. The project was born.
In the early days of Lighthouse we saw an overhaul of the spec which invalidated most of our Rust code. We’re completely fine with this and we expect this from a research project — we prefer to see depreciation instead of stubborn persistence. This highlights a core ethos of the Lighthouse project: we see Ethereum as a protocol, not a collection of products. We do not aim to ship our product as fast as possible, instead we aim to contribute to the establishment of a secure, decentralised and efficient protocol. Lighthouse must always prioritise the protocol over itself.
Accomplishments
Moving back to the present, we'd like to share with you the accomplishments of the project so far. These include both contributions to the protocol and development to our code base:
- Research on serialisation formats for p2p messaging.
- Discovery of a bias in the pseudo-random validated shuffling algorithm.
- Ongoing inquiries into the the validator role-assignment function.
- Implementation of a very basic libp2p floodsub network (to be replaced once research decides on a p2p layer).
- Development of a SimpleSerialize Rust library (this is the present network and consensus serializer).
- Drafts of a byte-array-based bitfield.
- Rust implementations of shuffling, validator role-assignment, state objects, and other beacon chain functions.
The Future
Looking forward, we are excited to continue to develop Lighthouse as the specification evolves. We’re presently implementing syncing logic and attempting to produce as many design artifacts as we can along the way (e.g., diagrams, functional requirements). The next two weeks should see some benchmarks on Beacon Chain block validation, progress on SimpleSerialize and documentation of the validator role-delegation function.
In the medium-term we’re eagerly awaiting the EF researchers decision on libp2p gossipsub as the p2p network layer. The last Eth 2.0 implementers call suggested a 90% likelihood of proceeding with gossipsub; if it is elected as the Eth 2.0 p2p layer, we look forward to assisting in the implementation of gossipsub in the Parity-maintained rust-libp2p library.
Summary
If you made it this far, thank you for taking the time to learn about our background and future plans. We look forward to sharing our progess and plans as we go on. Now we have introductions out of the way, future posts will be much more about the technology rather than Sigma Prime :)
If you have any questions or would like to contribute to the effort please feel free to drop into the Lighthouse Gitter or get involved in the code base.