Ethereum 2.0 Development Update #26 — Prysmatic Labs
Our biweekly updates written by the entire Prysmatic Labs team on the Ethereum 2.0 roadmap
Testnet Updates
Massive Bug Fixes & Efficiency Improvements
The past two weeks have had our best development velocity ever, merging in dozens of critical bug fixes and efficiency improvements. We improved the efficiency of our state transition function by 400x from the naive implementation, leading to massive improvements in our runtime and our cloud testnet.
We fixed extensive number of bugs in attestation processing and in fork resolution. Previously, if there was a forked chain that went through a reorg, our system would not be able to eventually resolve. We cleaned up a variety of issues and now our cluster is a lot more stable against network partitions and unexpected faults. Using Go’s awesome cpu and memory profiling tools, we continue to find bottlenecks that will lead to a great improvement in user experience.
Increased Network Resilience
In preparation for our testnet, there has been a concerted focus on having our network to be resilient under forks. Validators and beacon nodes can go offline resulting in attestations and blocks not being able to be broadcasted and relayed to other nodes. This can lead to network forks and resolving them would be very important to bring consensus within the network. The last two weeks we have generally been focused on fixing consensus bugs in our nodes, so that in the case of a fork, our nodes are still able to eventually come to agreement on the current state of the network.
Merged Code, Pull Requests, and Issues
Optimize LMD GHOST fork-choice rule
Being able to use flamegraphs and go’s awesome profiling tools for memory and cpu usage has allowed us to find some incredible bottlenecks throughout our code base. In particular, we optimized our fork choice rule by over 20x, reducing the need to fetch the beacon chain’s state or blocks. Fork choice only depends on attestation targets, which correspond to each validator’s vote, for the purpose of vote counting. There is no need to fetch entire blocks from the DB for this purpose, as mere block hashes and slot numbers will suffice.
Our code went from this:
To this:
Greater Usability of Our Validator and Beacon Nodes
After a lot of feedback from external contributors and other developers, we have been greatly improving the usability and logging of our beacon node and validator client. Running a system and having to input a bunch of CLI flags makes for a bad experience. Users should be able to run a validator by copying a simple command and not requiring any other domain knowledge. Aside from that, our logging has become a lot more informative and useful, making it easier to know exactly what happens in the Eth2.0 runtime.
More Prysm Benchmarks!
On top of the block benchmarks team member Ivan Martinez completed last update, he has now completed the benchmarks for the epoch processing conditions we expect for the phase 0 testnet. This has allowed us to continue to look into what epoch operations need further optimization in order to ensure they are completed within the allotted time. Operations in particular like Attestation Inclusion and Crosslinks processing are extremely unoptimized and there has already been work completed on improving them.
Simple Serialize Caching Complete
Simple serialize that has been introduced as part of the eth 2.0 spec as a simple way to communicate and share data between nodes while supporting light clients has a tree hashing functions that creates the signature of the ssz data. These hash functions are very costly to run over large objects. Our improvement is to store serialized byte array hash and its tree hash tuples in LRU cache. That way branches of object trees that are frequently reused are cached and pulled instead of recomputed.
Upcoming Work
Full Features of v0.6 Integrated Into Runtime
Good news! There’s a freeze date for phase 0 beacon chain spec! We believe now is the time to start integrating spec v0.6 into run time. In parallel to launching a testnet, the team has been hard at work at updating our state transition functions to v0.6 to align with the spec. Following issue was created to track each core function that needs to get an update into run time. The timeline of the overall progress is 3 weeks (ETA end of May) to have v0.6 fully integrated to the run time. If you are interested to work on implementing the latest phase 0 spec, don’t hesitate to reach out to us! This is a lot of fun!
Miscellaneous
New Updates to the v0.6 Beacon Chain Spec!
So what is included in the v0.6? Spring cleaning is what the title says! Most of the changes are cleaning up and simplifying the spec logic so it can be easily understood. Deposit contract and fork choice specs are also its own files. More tests were written for the executable spec. Here is the detailed change list
Preston & Ivan at First-Ever Web3 Developers Miami Meetup
Our teammate, Preston, joined Ivan in Miami to give an overview of Ethereum 2.0 in the first ever Web3 Developers Miami Meetup and it was an incredible event!
Want us to speak at your meetup? Drop in our discord channel or ping on twitter to let us know!
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
