Lighthouse Update #00

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:

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
libp2pgossipsub 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.