Eth2.0 Working Groups

The Monday before Devcon IV saw around 80 blockchain developers and thinkers
attending Eth2.0 working groups in
Prague, with the aim of discussing what the Eth2.0 stack will look like.

Everyone from the Sigma Prime team was in attendance and dispersed between the
various working groups. Paul Hauner also lead one of the working groups on DoS
Attack Analysis.

The working groups served as a great opportunity for the various implementers
to get on the same page. Members of the lighthouse team have provided some of
their notes taken during these workshops, which are linked from the main Eth2.0
working groups page.

Parity and libp2p

The libp2p project was initially developed for the IPFS
project and written in
Golang. Since then,
the libp2p project has become its own project maintained by Protocol
Labs, somewhat separate from the IPFS project.
Compatible implementations have been written in several other
languages, such has JavaScript and Rust,
which are at various stages of maturity.

The implementation of most interest to Lighthouse is
rust-libp2p, which primarily
maintained by Parity due to its use in their
Polkadot and
Substrate projects. At Sigma Prime,
we have been working to extend the rust-libp2p implementation to include the
gossipsub
protocol.

While meeting with other Ethereum developers in Prague, the Lighthouse team
conferred with developers from Parity to co-ordinate our efforts. In summary,
it seems that Parity have plans to completely refactor rust-libp2p, which have
a high likelihood of rendering our planned contributions redundant. As such, we
have decided to allow a bit of time for development of the rust-libp2p project
to settle before allocating too much development time on it.

Validator Client Architectures

While at Devcon IV, we had several long discussions about how the validator
client should be structured. This led to the creation of an outline
document for what these
architectures might look like. Raul from Prysmatic Labs has posted the client
architecture notes from the Eth2.0 workshops,
so we will work to reconcile our document with this one over the coming weeks.

The purpose of these client architecture documents is to clearly identify the
abstract components that are interacting, and where the software for each of
these components should live. These decisions affect future scalability and
have significant implications when deciding how to deploy and secure an Eth2.0
validator client in a variety of scenarios.

Implementation of Basic Block Processing

In our previous update we
spoke about our progress with the block pre-processing
logic.
We have moved on to the next stage with this and have started implementation of
actual block processing logic, which involves much heavier lifting (from a
computational standpoint).

The concept here is to build a full block validator
function,
which can begin with a genesis block and accept new blocks to modify the system
state. After passing the block pre-processing checks, blocks must be parsed by
a block validator function and the state transitions within must be applied to
the current state of the blockchain.

This is a very involved task which is likely to take many weeks, so expect our
next few updates to elaborate on this.

Gitcoin PR Shout-outs

Over the last few weeks, we are very excited to have a number of contributors
join the Lighthouse project via the Gitcoin platform. If you are interested in
getting paid to contribute to the project, Gitcoin has funded several
Lighthouse
issues
via their platform. We would love to have more project contributors, so please
take a look and apply if you think you can help!

Notable shout-outs for contributions over the last two weeks includes: