Final development update

Project: Consensus client built in Elixir
Team: Martín, Tomas A, Tomas G, Paul-Henry

Project repository: https://github.com/lambdaclass/lambda_ethereum_consensus

Abstract

Our initial goal was to complete an MVP for a consensus client in elixir in this 4 months of the EPF. We chose elixir because it's a highly reliable functional programming language intended to maintain predictability and stable throughput under high-demand conditions, used in projects like Whatsapp and Discord. We intended to build this for capella, using checkpoint sync to avoid supporting the previous hard forks for the MVP (we intend to add them later down the line when we complete all of the node features).

What we faced

We came accross several issues:

• The specs are diff-based, so there's no a single official source for the current state in capella (although the eth2book by Ben Edgnington was a great resource in this matter).
• Many problems to solve out of the scope of the specs:
  • Persistence storage (e.g. with key value stores like levelDB).
  • Peer scoring. Many peers were dropping us and debugging that was non-trivial, as they don't send clear messages with the reasons.
  • We need to maintain peer scoring ourselves, as many peers we connect to don't send useful data to us.
• LibP2P as a huge library that we weren't going to be able to implement ourselves in this four months (lest that became our whole project). We ended up using go-libp2p, with NIFs (Native Implemented functions) but then moved to ports (a separate OS process supervised as if it was an erlang process) as it had more robust runtime guarantees.

Status Report

As we are on the same team, this section is identical to the one submitted by Martin Paulucci.

Our initial (very ambitious) goal was to get an MVP/prototype of the Consensus client working during the duration of the program. We have made great progress, and I think we are very close to that goal, which just a few weeks left.

What’s done and what’s missing

• Done:
• In progress:
• Not started:

Building Blocks

• SSZ
• BLS
• Randao
• Sync Committees

Networking & Infra

• LibP2P
• Spec Test framework
• Storage
• Observability
• CI/CD

Beacon Chain

• Incoming requests:
• Outgoing requests:
• Pending blocks processing
• Checkpoint Sync
• Block syncing
• Engine API
• Beacon API

State Transition

• Genesis state
• Block processing
• Slot processing
• Epoch processing

Fork Choice

• Store setup
• On block event handler
• On tick event handler
• On attestation event handler
• On attestation slashing handler
• Head of chain calculation

Validator

• Block proposal
• Attestation
• Attestation aggregation

Community

During this time we have decided to invest heavily in the community, which we think will be pay dividends in the long run. We decided to be very active and create a telegram group from day 1 (https://t.me/lambdaconsensus). Today that group has more than four hundred members.

Additionally, we released a 4 month bootcamp. We performed dozens of interviews and ended up selecting 4 participans. That bootcamp is ongoing now.

• We have a telegram group with 400+(!) members
• We started a 4 month bootcamp

Future of the Project

The idea of the project is to continue and become another option for stakers to participate in the Ethereum Network. The funding of the project will be provided by LambdaClass.

We would like to release an MVP by EOY or early Q1 2024.

Conclusion

While the MVP that we were expecting at the beginning of the project is not quite there yet, we made great progress in both integration points like networking and state transition functionality, which is a very time consuming task, both in coding hours and spec-study hours.

The most underestimated parts of the roadmap where parts outside of the specs, regarding state management and networking. The spec features estimations were reasonably good.

A big part of this EPF project was also about building a latin-american team that was very knowledgeable about core topics, and that task was successful regardless of the state of the code.

As for the project, we will continue working on it and make sure it is complete regardless of the EPF coming to an end.

Feedback

I'm very grateful for the EPF and the foundation in general for their support on this project. While working on this was already a goal of us, the EPF was the event that made us take the step to start it.

The fellowship in general was a very useful tools, specially the talks with tutors and guests on the tuesday working hour calls. The fact that they were recorded was also very useful, as I sometimes had conflicts and wasn't able to attend, but I gained much insight from listening to them asynchrounously.

Finally, I'd like to thank Josh and Mario for their work on this, and for their effort on following up on everyone's situation to make sure that everyone's making progress and not getting behind on their goals and obligations, as well as the help on organizing the trips to Istambul and Prague.