Post-Devcon IV Update
The past two weeks have seen a temporary slow-down in development while most developers attended the Web3 Summit in Berlin and Devcon IV in Prague.
Summary of the activity by Sigma Prime over the last 2-3 weeks:
- Attendance to the Eth2.0 Working Groups.
- Discussions with Parity regarding libp2p Assessing architectures for validator clients.
- Implementation of a basic block processing function.
- Have received several PRs for issues listed on Gitcoin.
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 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: