Ethereum 2.0 Development Update #23 — Prysmatic Labs
Our biweekly updates written by the entire Prysmatic Labs team on the Ethereum 2.0 roadmap
Latest ETH2.0 Spec Updates
V0.4 Release
V0.4 (Clean Signing) was released earlier this week, in this spec update we introduced a new unified method of hashing ssh objects for signing. The additional logic for proof of custody was also added and now under reviewed. Matthew Slipper has proposed the initial version of wire protocol which is now under reviewed. Aside from those feature updates, many bugs and misc fixes went into V0.4, take a look and let us know if there’s any questions!
Merged Code, Pull Requests, and Issues
Validator client consistent improvements
While spending most of our time on beacon node runtime, it’s also important to maintain our validator client codebase for readability. We have been fixing validator runtime bugs and improving upon documentation so new contributors can smoothly pick up any issues. A few ideas we are currently investigating: one is to have validators query assignments of the next epoch as opposed to the current epoch.
This will give validator more buffer in case of a slow connection when him/she couldn’t get the assignment in time.
Attestation lifecycle: including in blocks, removing from DB
It is the beacon node’s responsibility to provide validators the attestations that have not been seen on the beacon chain. In Prysm we have designed a an operations pool to store fresh attestations in local DB. As attestations get broadcast on the beacon chain, Prysm’s sync service will first receive the attestation, verify the attestation passes pre-condition test, and then it forwards the attestation to the operation pool. When a proposer proposes, it simply requests for attestations from the pool to include them in the block. Then as blockchain service processes new block, it simply deletes the processed attestations from the pool so what’s in the pool is always fresh.
Testing beacon chain sync
We were finally able to test full sync of two beacon nodes using libp2p through a lot of hard work from our teammate Nishant. You can check out the latest PR which added these tests here.
Beacon node runtime fixes and common bugs implementers should watch out for
We’ve been getting closer and closer to getting our simple, local testnet of 8 validators and a beacon node advancing indefinitely. Throughout this process, we’ve run into many problems that aren’t immediately evident when translating the specification as is. In particular, validators should be very careful about fetching assignments as there can be weird conditions around epoch boundaries. That is, if there are 64 slots in an epoch and assignments are fetched exactly at slot 64, there’s a chance the assignments being fetched are from the previous epoch and not the current one. We’ve been tracing our code paths and tracking performance for our different services to ensure we don’t run into these issues, but we had a nasty bug due to these epoch boundary conditions. We are currently on track to resolving all these bugs as we proceed with more testnet plans.
Upcoming Work
Front-end for validator onboarding into our first testnet release
We want to make it easier for individuals to learn about how to become validators in Ethereum 2.0. One of our major initiatives as part of our testnet is to have a simple front-end that gives all the required details and instructions on acquiring test ETH, sending it to the deposit contract, and running a full-fledged validator client for the Ethereum 2.0 beacon chain.
Ensuring new validator deposits work in our testnet configuration
Our recent testing of our runtime has been restricted to having a set of initial validators sending test ETH into the deposit contract and starting the beacon chain. However, this is much different than the process for onboarding new validators after the chain has started. New validator deposits need to go through a voting process, in which current validators verify roots of the deposit Merkle trie in the deposit contract against block hashes from the ETH 1.0 chain.
If a deposit root gets enough votes, a proposer includes a “Deposit” object in a beacon block after a safe period of ETH 1.0 blocks pass by, and then the beacon node processes these deposits and activates the validator within an epoch or two. If you’re curious to read more about the exact mechanism behind this voting process, see the validator specification created by Danny Ryan here.
Finish/optimize beacon node state and block sync
Our current beacon node implementation typically follows the official specification very closely, meaning there are many optimizations to be made with respect to caching and avoiding repeated, expensive computation. Our runtime needs to be able to accommodate an ever-growing state object, minimize reads from our database, and prepare for having the worst case scenario (from our node’s perspective) of 4 million validators participating in the system. We’re still far from handling that worst case gracefully, but we’re making good progress to trace every inefficiency in our runtime and make sure we don’t run into nasty bugs while our testnet is up. That said, we have a lot of work to do to optimize the sync process between beacon nodes over p2p, which is a critical part of any blockchain.
State journaling to handle fork choice reorgs
The fork choice rule for the Ethereum 2.0 beacon chain is called Latest Message Driven GHOST (Greediest Heaviest Observed Sub-Tree). Much has been written about it over the past few months, but the important aspect of having a fork choice rule is being able to roll back the state and the blockchain to a previous point in time if that’s what the rule decides. For example, if the fork choice says the head should be a few hours behind, we need a mechanism to roll the state back effectively. In Ethereum 1.0, geth keeps a “journal” that is used to track important details of the state in case of a reorg. We plan on including this strategy in Prysm so we can easily revert if the fork choice rule tells our client to.
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
