Ethereum 2.0 Development Update #32 — Prysmatic Labs
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.
Attestation Aggregation
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!
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.
0x9B984D5a03980D8dc0a24506c968465424c81DbE
prysmatic.eth
Published at Thu, 08 Aug 2019 19:33:59 +0000
{flickr|100|campaign}
