Ethereum 2.0 Development Update #33 — Prysmatic Labs
By: Terence Tsao
Tags: Blockchain, Golang, Scalability, Ethereum

Our biweekly updates written by the entire Prysmatic Labs team on the Ethereum 2.0 roadmap.

Our biweekly updates written by the entire Prysmatic Labs team on the Ethereum 2.0 roadmap.

Merged Code, Pull Requests, and Issues

Database Improvements & Refactoring

Our old database backend we have been using in Prysm grew unwieldy and had a whole array of problems that made it near impossible to maintain, extend, and debug. It started off simple, but throughout the past few months it had grown to contain more and more business logic in its methods that should’ve been kept elsewhere, with several methods doing 10+ different things. These complex methods are a blackbox from the outside, and they would often have unintended side effects not reflected by their name nor their documentation, such as saving data when it’s not clear the method should save anything at all. As such, as opted for a much needed refactor into a backend that will last the test of time.

We created a design document here with problems + solutions to create a revamped DB package, and after a lot of work, we completed it and we now have a swappable DB backend that was designed with a carefully defined interface, meaning someone could come in tomorrow and implement the same interface with a SQL backend, or a MongoDB backend. Having that capability is an important piece of any project, making it easier for future analytics/data gathering on Eth2.

Our DB refactor also includes nice ways to build filters for data objects via attributes, so for example, if one wants all the blocks from slot 10 to 100 that have a certain parent root, one can construct a trivial query that fetches that information efficiently from our DB.

Networking Spec Implementation

We’ve been implementing all of our networking related logic to meet an interop specification that was recently merged. Our design document for implementing this functionality has been reviewed and finalized. The highlights to take away are that a client in go has an advantage in networking as the majority of the components on the libp2p side are already built in the go-libp2p framework. That’s not to say this is a trivial effort! See our progress tracking issue with over 40 tasks and 23 pull requests merged already!

Integrate new fork choice to run time

Fork choice is arguably the most important component for run time. Without it working properly, running nodes will not come to a consensus on the current which will result in forks🍴, and that’s bad! We started this progressing tracking issue and we are almost halfway there! We started out by implementing fork choice as a service by using the latest fork choice spec, it combines effort with the DB from the latest improvements and refactoring proposal. Then, we benchmark the implementation to get a good idea on how it would perform in the wild. To test this extensively, we started a yaml driven test file which will help us define edge cases and catch potential runtime bugs. Finally we updated block chain service to interface with the new fork choice service and started working on important functions such as receive block and receive attestation.

Beacon Node Network Discovery V5

We have finally added for support for nodes with Discv5. Now Prysm nodes utilise Discv5 as the default peer discovery mechanism for discovering other peers. This is part of our effort to be up to date with the current networking spec so that we are able to be interoperable with other client teams. This effort is tracked over here. With this merged in we are able to integrate it into our current libp2p stack, with ENRs returned by discv5 being converted to multiaddrs and utilized to then open streams with other peers and exchange blocks, attestations and other beacon chain operations. This was implemented in this PR.

Upcoming Work

Finalizing Ethereum APIs

We have put in a lot of work into a standardized, well-documented source for Ethereum 2.0 RPC APIs that are implemented by the Prysm project in a public repo here. Most of the services are fully implemented, and now that we have completed revamping our DB, we’re able to wrap up a full implementation of the APIs in our project, making it so that other projects such as Mytchmatic™ can retrieve data from Prysm nodes to display anywhere! Follow the issue thread here to stay up to date. We really want to aim for standardization of Eth2 APIs and we believe the tooling and technologies we chose for the repo are industry standards Ethereum should adopt in production.

Beacon Chain Slashing Detection

Remember the Hash Slinging Slasher? Well it’s been quite a challenge to implement! The relevant data it needs for the weak subjectivity period (~8 months) would be over dozens of gigabytes! Thankfully, the Eth2.0 researchers gave the implementers some recommendations for designs on their slashing detection. This week, while trying to implement the double vote detection service, we have found a flaw in one of the proposed designs for double vote detection. While the suggested design had us store 1 bit per validator per epoch, this is unfortunately not enough information to accurately detect such cases. We have struggled to find a design that keeps the resource requirements (memory and storage) at a reasonable size. We’ve been working hard looking into possible solutions, and have settled on a good solution for the time being! People who intend to validate normally, no need to worry about these resource needs, this is only for people who wish to be slashing watchtowers for the network and earn whistleblower fees!

Interested in Contributing?

We are always looking for devs interested in helping us out. If you know Go or Solidity and want to contribute to the forefront of research on Ethereum, please drop us a line and we’d be more than happy to help onboard you :).

Check out our contributing guidelines and our open projects on Github. Each task and issue is grouped into the Phase 0 milestone along with a specific project it belongs to.

As always, follow us on Twitter or join our Discord server and let us know what you want to help with.

Official, Prysmatic Labs Ether Donation Address

0x9B984D5a03980D8dc0a24506c968465424c81DbE

Official, Prysmatic Labs ENS Name

prysmatic.eth