Our biweekly updates written by the entire Prysmatic Labs team on the Ethereum 2.0 roadmap.
The Eth2 Networking Specification
With the Eth2 networking specification finally merged in here, all the different ETH2 clients finally have a fleshed out specification through which they can communicate. This is a big step towards interoperability between with all the different Eth2 clients. With the network specification specified, the 3 major things that clients can now focus on implementing are, discovery of external peers, message propagation in the network and the request and response of messages from peers and vice-versa.
The specification specifies two sets of requirements one for interoperability for multi-client testnets and the other for mainnet. The reason this is done is so that clients can implement the most functional and non-complex features that would allow them to communicate with other clients for testnets. Some of the stated requirements for mainnet are still being debated and finalized so the interop requirements serve as a minimum to get clients communicating with each other.
Merged Code, Pull Requests, and Issues
Eth2 Fork Choice Rule (Latest Message Driven GHOST)
We have updated Prysm fork choice rule to align with the latest fork choice spec. There’s a branch which uses the updated fork choice from the spec freeze. With this update, we were able to remove 4000 lines of code and simplify most of the block processing and attestation processing logic. We are excited to be able to battle test this in the run time. In parallel we are going to evaluate various fork choice optimization techniques as outlined. The overall progress can be tracked here
Fork Detection Tool
As important as updating fork choice to latest spec, it’s also important to have good testing utility around fork choice. We have developed a simple tool to poll head for all the beacon nodes via gRPC end points to check when head diverges from one another. We believe this will serve great benefit for testing fork choice in production environment as well as in a complicated set up. The tool is hosted here
Cache-Optimized, Simple Serialize
Ethereum 2.0 has a very neat way of computing state roots and other data structures through its serialization algorithm, SSZ (Simple Serialize). Given the entire beacon state can grow to worst case scenarios of 400Mb, we don’t want to be constantly taking sha256 hashes of that giant data structure. Also, we don’t want to have to manipulate it as a giant blob of information every time we require modifications of the state itself. Instead, we have a Merkleization approach where we compute a tree from serializations of each of the state’s fields, which can be cached for performance.
That is, every single time we mutate a single field of the state, we don’t need to recompute hashes of the entire thing, as we can cache them and only compute a new hash of the field we mutated. This gives us a massive performance boost which we weren’t fully leveraging in Prysm. We now have updated our SSZ to properly use this caching mechanism, making it fast for us to compute the state root at runtime and in tests, which is exactly what we needed to build a more robust testnet. You can check out the updates and progress here. Thanks to Protolambda on all the help with the approach!
V0.8.1 Testnet Release
We are now on track to deploy a v0.8.1 version of our testnet very soon! This will contain a bunch of latest research and features from the spec as well as the new fork choice rule which will eliminate the majority of bugs we saw in our previous runs. We are now able to handle a much larger load of validators, as we have optimized the cryptography required to aggregate signatures into a single value in Prysm, as well as radical improvements to our APIs, sync, and the underlying core behind Ethereum 2.0’s powerful state transitions. Additionally, we are fully compliant with conformity spec tests, giving us confidence our beacon chain will run as the research intends it to. Any new bugs we find will likely be attributed to our own mistakes in Prysm rather than a spec research problem beyond the scope of our codebase. Stay tuned by following us on medium and on twitter to find out when the new release is out.
Previously in Prysm, we’ve been submitting attestations to the network that only contain the signature of 1 validator, this can become more expensive in runtime as the amount of attestations being created increases with more validators.
Within ETH 2.0, one of the awesome features of using BLS12–381 for private keys and signatures is its ability to aggregate (combine) signed messages of similar plaintexts. This can allow an entire committee’s attestations to be compressed to one signature! Using aggregation, we can reduce the load of processing attestations by almost 90%! This has been one of the largest blockers to help performance when there’s a large amount of validators so we’re really excited to see how much more performant the client becomes with more validators.
Prysm’s Slashing Functionality & Design
Currently in our testnet, if a validator creates a slashable attestation or block, there are no whistleblowers on the network to catch them and submit a proof of their slashing to the beacon chain. Danny Ryan made a fantastic explanation explaining how to store the information needed to detect slashing in as optimally as possible.
Protolambda conducted some great research on using quadratic trees and manhattan distance to store a small subset of validator attestation data that will support detection of wrong doers in the network. The storage needs for policing the POS are substantial (~8 months of aggregated attestations). In order to enable low storage nodes to run easily we have added a flag and created a client server topology between a high storage node and a low storage node that will enable everyone to detect, get the proof from a high storage node and whistleblow about bad actors in the network. We are so excited and already started implementing the Hash Slinging Slasher (credits to Preston Van Loon): which will be a high storage node that supports smaller nodes in policing the network.
BLS Optimizations: 50x Improvement!
One of the recent bottlenecks in Prysm has been processing aggregated validator signatures with our BLS library, written by Julian Meyer from Phoreproject. This library came together through a Gitcoin bounty and has been a great library as the existing alternatives involved complicated compilation with go and C++. Recent benchmarks showed that this library was taking ~850 milliseconds to verify a message with aggregated signatures from 128 private keys, a typical sized message for mainnet eth2. In comparison, the rust library from Apache Milagro could achieve the same task in just ~7.8 milliseconds. As we were exploring various options, including calling the rust Milagro library directly, ETH 2.0 researcher Protolambda looked at the differences between the two libraries and found some discrepancies in the order of operations. Protolambda modified the phoreproject to reduce the total multiplications in the method and brought the benchmark time to under 18 milliseconds!
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 :).
Official, Prysmatic Labs Ether Donation Address
Official, Prysmatic Labs ENS Name