Ethereum 2.0 Development Update #24 — Prysmatic Labs
Our biweekly updates written by the entire Prysmatic Labs team on the Ethereum 2.0 roadmap
Merged Code, Pull Requests, and Issues
Phase 0 Beacon Node + Validator Runtime Update
Since the last update, we have been working extensively on getting a phase 0 blockchain that can run forever and is resilient to crashes and bugs that attempt to take the system down. We have been constantly identifying pitfalls in our approaches, dealing with edge cases that can and will pop up in production, and overall ensuring we have enough monitoring technology to understand everything happening in the network at any point in time. We’ve been leveraging the incredible prometheus and jaeger monitoring tools which allow us to track any metric we want from our nodes as well as look at what functions take up the longest in any section of our runtime.
Every day, we get closer and closer to our testnet release and want to ensure we have a solid framework for tracking how the network performs in real life settings. Meanwhile, we’ve been hard at work with mega tracking issues on Github that help us get our bearings on any last details that need to be done.
Implemented LMD Ghost fork
We have implemented a minimal viable fork choice framework. The fork choice framework consists of the following:
- A store object that contains the set of attestations and blocks which the local beacon node has observed and verified
- A latest attestation object that tracks individual validators latest attestation (i.e. which validator vote on what block?)
- A saved finalized head (a finalized block with highest epoch) and justified head (descendant block of finalized block with highest epoch that has been justified)
- A get ancestor method for getting ancestor block of a input block using the slot number
- A get children method to get child blocks of a input block
From the above tools we can run LMD GHOST starting at any justified state and justified block and traverse down the block tree to calculate head. The head will then get retrieved by attester and proposer to fulfill their assignments. If you are interested, please take a look at the beacon chain fork choice spec.
LMD Ghost benchmark numbers
Given our initial test net is configured with one shard, eight slots per epoch and eight validators, it’s important to have an idea on how long it takes to apply the fork choice rule to compute the head. The preliminary benchmark results are documented here, and the overall optimization improvement plan is getting tracked here.
BenchmarkLMDGhost_8Slots_8Validators-4 2000 830608 ns/op
BenchmarkLMDGhost_32Slots_8Validators-4 2000 817344 ns/op
BenchmarkLMDGhost_32Slots_64Validators-4 20 98993536 ns/op
BenchmarkLMDGhost_64Slots_16384Validators-4 1 111040152382 ns/opPlease do keep in mind these numbers include typical DB read/write latencies which can be improved by caching. With these numbers, we are confident our fork choice will work in a 8 validators set up. And In the meantime, we need to optimize the fork choice as we scale up to 100,000’s of validators.
New Validator Activation & Sparse Merkle Trie Tools
One of the most important features of Ethereum 2.0 phase 0 is to allow anyone who currently holds Ether to deposit 32 into a Deposit Contract which will then queue that user as a validator into our system. The way we ensure there is integrity between the deposit and the people running our node is through Merkle proofs and BLS signature verification using a certain private key as a deposit data into the contract. New validator deposits into Ethereum 2.0 however, need to be carefully processed as there could be a chain split or a reorg in the Ethereum 1.0 chain when they happened. This is why the current spec has a voting period in which current validators vote on block hashes from the 1.0 chain up to which we can include deposits safely. We have finished updating our code base to match these changes and new validators can now get activated within Prysm!
See the pull request that made this happen here.
Beacon Node Sync Fixes
In preparation for our testnet we have been fixing up our sync service so that our beacon node will be able to perform both regular sync and an initial sync. The major PRs that we have tackled over the last few weeks have handled skipped slots in sync, syncing from the last finalized state over here and here. Previously our sync protocol didn’t handle skipped slots, so whenever we sent out a request for a range of blocks, and that range had a skipped slot, the node would not be able to sync. Also we would perform state sync from the current slot instead of the last finalized epoch which would cause issues when requesting for a state when another node was undergoing a state transition. This was vulnerable to re-orgs and forks, with this issue in mind we now only sync finalized states between nodes.
Upcoming Work
Complete End-to-End Testing
Although testnet is on the way, most of the debugging work we have done has been quite painful as it’s difficult to track down a small bug that only occurs when you have a real, running network. If we don’t have a way to consistently monitor the effects of any changes we make in our master branch, we could break our runtime accidentally and we want to catch that before it happens. We’ve been using mega-tracking issues such as this one on Github to make sure we don’t miss little details that can catch us off-guard.
Having a complete end-to-end test suite that runs periodically would help fix a ton of issues, as we would know if any changes break our runtime without us having to set it up every time. Our teammate Preston is currently working on setting an extensive e2e tool for Prysm that would run a real network and verify the chain can advance to a certain threshold.
Current State of Sync and What is Next
Matthew Slipper has released the first draft of the Phase 0 wire protocol discussed in this issue and PR . This is very exciting as with a solid spec out for networking it will give all the different clients a firm basis on how to communicate with each other. The draft goes into details on how requests and responses for the different data structures should be handled, how handshake between two nodes connecting should occur and how clients would sync with each other. This is important as this is the first step towards having a future cross-client testnet for Phase 0.
Miscellaneous
We are very pleased to announce that Ivan Martinez has joined us as a core contributor. Ivan has been steadily contributed to prysm on the side for the last 6 months and really demonstrated his passion for the project. We are super excited and proud to have him as part of the family. In his own words.
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, drop us a line here or on 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
