Ethereum 2.0 Development Update #28— Prysmatic Labs
Our biweekly updates written by the entire Prysmatic Labs team on the Ethereum 2.0 roadmap
Known Bugs & Fixes
Our initial testnet launch has been a great success for us and has been incredibly useful in improving the Prysm runtime. Community members frequently hop into our Discord channel and suggest logging improvements, standardization, and more for production clients to become robust enough for secure usage.
Our original release targeted version 0.4 of the Ethereum 2.0 Phase 0 specification, which is radically different from the latest spec, version 0.6. In the previous version, several bugs arose in our state transition function and fork choice algorithm to determine the best chain. Many users have encountered these errors throughout their experience, although most of them can be easily resolved by restarting a node that gets into a faulty condition and syncing with other peers.
Future Testnet Plans
Instead of spending all our time debugging the v0.4 version of the spec, the team has taken a step back over the past month to focus 100% on ensuring our code matches the latest specification of Ethereum 2.0. For this to occur, we need to conform to a set of common tests created by the ETH2 research team here. These tests are a big leap for all teams to get closer to a multi-client testnet. This means we can all be sure we conform to the same protocol despite having implementations in different languages, and have real clients talk to each other like Geth and Parity do today.
In the short term, however, our main focus is a v0.6 Prysm testnet, which will be fully updated to conform with the aforementioned tests as well as fix the known bugs from our current testnet for our users. This release will have much better UX, be more resilient, and be a lot closer to what mainnet Prysm clients will look like. As always, join our discord or follow us here on medium to stay updated on our new releases.
Merged Code, Pull Requests, and Issues
Rapid Progress Towards Latest v0.6 Specification
The team has been working at high velocity on aligning with v0.6, and we have closed down nearly every piece of our mega-tracking issue on Github for this. In short, v0.6 of Eth2 phase 0 greatly simplifies the state transition function and cracks down on important bugs from previous versions. This represents a major milestone as it is a lot more concise, easy to understand, and clear about its design decisions compared to previous versions. Unfortunately for us, this has meant a major refactor of our core codebase but the benefits it will bring far outweigh the time required to update our code.
This refactor affects the core pieces of Eth2 proof of stake and its data structures for the better. We have successfully split the work between the team and are on track to merge all the changes into the master branch very soon.
Ethereum 2.0 Data API
The development of our data access API has been an informal and as-needed design. This strategy has been working well as it would have been a poor choice to commit to an API design while the specification for Ethereum 2.0 is rapidly changing. With less than 2 months to a frozen Ethereum 2.0 spec, we can expect only minor changes to the data structures and needs of the system. It’s time to formalize and solidify a data access API such that block explorers, data analytics, and other applications can start building on top of Ethereum 2.0 clients to display meaningful data to end users.
We’ve started collecting use cases in this product requirements document. We’d love to hear your feedback if there are any missing use cases here or any specific asks for phase 0. The detailed design on the API server schema will start in the coming weeks and then client developers will commit and converge on a single schema.
P2P Connection Manager Design
We’re working with Protocol Labs to provide our feedback on what we envision for our peer connection management. This manager is similar to the peer management in the Parity or go-ethereum clients where a certain maximum number of peers are allowed to connect before some constraints are enforced.
Epoch Processing Massive Optimizations
Epoch processing was taking a while due to the nature of searching through attestations to find the one with the lowest inclusion delay to calculate proposer rewards. Since then we have begun to cache major processing components such as shuffled indices, epoch start shard, active validator indices, count, as well as the active balance and total balance of a given epoch. We were able to shorten the slow processing time from 70s all the way down to 2s over 100 iterations. To follow our optimization efforts, check out #2737 and #2753.
Update Our Runtime to Latest Spec
With all the continuous updates to v0.6, a lot of core components of both our beacon node and validator clients have changed. This has lead to our node runtime breaking, due to the fact that our deposit contract has changed quite a bit, validator public keys are now in G1 instead of G2, and other big changes. This has lead to some differences in how a beacon node will now function and interact with the validator client and vice versa.
In the journey to update our clients to the latest spec, it will also involve fixing runtime bugs that pop up due to the changes. This is being handled in this PR.
Update Simple Serialize (SSZ) to Latest v0.6 Specification
While we've had SSZ implemented since February (at mainly v0.2.0 of the spec), we've run into issues optimizing our implementation and ensuring it can serve as a full replacement to our current serialization solution. As of now it's only used for block root and state root, when it should be used for most if not all of our serializing in Prysm.
A properly implemented SSZ important for a multi-client test net, so we've been focusing on aligning our SSZ to the latest spec! The most notable changes include the addition of `signing_root` for signing data without its "signature" field (in BeaconChainBlock for example), and a rather drastic change to the main `hash_tree_root` function which is the main function used for serializing data in Eth2. You can view this tracking issue for more details. We will perform benchmarks after these updates are complete so we can decide if further improvements to our implementation will be needed.
On top of this, we've moved SSZ to its own repo now under the name go-ssz! This makes it easier for contributors to submit issues, make PRs, and in general makes organizing for go-ssz much cleaner.
Prysmatic at Scaling ETH Workshop Toronto
Some of the top scalability researchers are meeting this week in Toronto at ScalingETH! A one of a kind event. Preston van Loon and Terence Tsao are attending from our team, so please stop by and say hi! The talks from the conference are being recorded on YouTube here:
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