Ethereum 2.0 Development Update #16 — Prysmatic Labs
Our biweekly updates written by the entire Prysmatic Labs team on Ethereum 2.0
Overview and Devcon Recap
Official Name for Ethereum 2.0: Serenity
Ethereum 2.0 is officially being renamed to Serenity, a name fit for an upgrade that will transform the years of work put into turning a current, smart-contract enabled blockchain into a scalable world computer. It is the culmination of years of work, research, and community conversations around how to completely overhaul an existing network in a highly experimental manner, and we couldn’t be more excited to be part of the movement making it happen.
At Prysmatic Labs, we will use the terms interchangeably to maintain a good level of context for new entrants and contributors that may not be as familiar with the Ethereum roadmap.
Devcon Recap
Devcon was an absolute blast and was the first time most of our team finally met in person, even though we’ve been reviewing each others’ code on Github for months!
There was a key focus on clarifying the Ethereum Serenity roadmap and making sure the community is more aware of the motivations and teams behind its implementation. Vitalik gave a keynote on the road so far and Justin Drake gave an overview of the ambitious project spearheaded by the Ethereum foundation on creating an unbiasable, global source of randomness through specialized Verifiable Delay Function (VDF) ASICs. Check it out, as this project will be a critical component for the Beacon Chain and Proof of Stake.
Some other important keynotes we recommend from the conference are:
- Cryptoeconomics at Scale by Karl Floersch
- Casper CBC Design Philosophy by Vlad Zamfir
- Ethereum Foundation Values by Aya Miyaguchi
- Decentralization Against Isolation by Glen Weyl
Serenity Working Groups in Prague
Before Devcon began, the different Serenity implementation teams gathered round and had a long day of breakout sessions going over critical design decisions of the protocol.
The teams then aggregated their notes into a set of markdown documents (thanks Ben Edgington for curating this in the the latest “What’s New in ETH2.0” notes!):
- Client Architectures & Common Validator Interface
- DoS Attack Analysis
- Libp2p Daemon
- UX/DevEx/PM
- Network Sig Aggregation
- Testing Formats
- Peer Discovery & Wire Protocol
A big win from that day was that all the different implementation teams were in the same room and able to discuss cross-client compatibility at an early stage.
Devcon Presentation Prysmatic Labs (Raul & Hsiao-Wei)
Our teammate Raul Jordan gave an update on our experience implementing Ethereum 2.0 alongside Hsiao-Wei Wang from the Ethereum Research team.
We received a lot of valuable feedback on the need for more documentation to explain design decisions in the Ethereum Serenity spec and to make it more accessible to those not following the technical discussions closely. Over the next few months there will be a greater push to clearly explain the design decisions behind the months of research put into the project so far.
Latest Research
Single State Root
Active and crystallized states are being merged. The decision was almost entirely to reduce protocol complexity and make all data structures in the beacon chain more light client friendly. Instead of passing around two states, adjusting RANDAO instantly instead of at the end of cycle, and remembering which field belongs to which state, we now only have one single state. This was not viable before because of re-hasing costs, but it is viable now because of the SSZ tree hashing proposal.
Alternative Staking Withdrawal Mechanisms
A Github Issue for a variable length withdrawal time has been posted here. The idea is to limit the number of withdrawals to 8 per transition. This allows the withdrawal time to be short in the average case, but longer when large amounts of validators withdraw simultaneously. The reason for increasing the processing time when validators leave en-masse is to increase the time it takes to execute a long range attack. Once a validator’s deposit is returned, the validator can equivocate on past blocks, meaning they can attest to multiple blocks without getting slashed. This isn’t an issue if only a small number can equivocate, since they won’t be able to reach the ⅔ threshold for finalization. However, this is an issue if a large number of validators withdraw at once, which this mechanism addresses by increasing the processing time for withdraws.
Merged Code, Pull Requests, and Issues
Simulated Test Runner for Chain Tests
An important part of Serenity is to ensure cross-client compatibility earlier rather than later. In particular, having cross-client conformity tests are a way we can detect breaking changes between clients on important items such as serialization, shuffling of validators, fork-choice, and more. The official spec proposes using a YAML format as a common way of defining Serenity tests which can then be fed into a test runner on each client to confirm their output.
We have merged in a simulated backend which can parse YAML tests for fork-choice here and have opened up a bounty to use this backend to also run validator shuffling YAML tests.
Check out our open Gitcoin bounty here.
RANDAO First Iteration Done
We have completed the first implementation of RANDAO. Changes include validator hash onions (pre-key commitments) and adding the RANDAO field to blocks. While processing attestations, the beacon node verifies the RANDAO reveal of the proposer and mixes the value with the previous block’s RANDAO field. During a cycle transition, the beacon node reshuffles the validator set with the RANDAO value of the most recent block.
Beacon Node P2P Bootnode
Part of client discovery tends to rely on a publicly accessible and well known service to provide the initial peers for bootstrapping a new client into the network. For this, we have built a simple bootnode service leveraging libp2p’s Kademlia DHT implementation. View the progress in this PR.
Validator Private Key Management
An important part of the validator client would be to manage the user’s private keys and allow users to sign data and verify their identity. We recently merged this in the following PR. With this PR merged in users can provide a keystore containing their private key and the validator client will be able to verify their identity and allow users to perform the roles of an attester or proposer. Keystore’s are stored and generated very similarly to how go-ethereum currently carries it out. This uses the AES-128-CTR algorithm to encrypt the user’s private key in the keystore.
One of our future goals would be to abstract the private key management from the validator client, where you could sign in to your validator using a resource-restricted device such as a phone, or a hardware wallet. Doing this would provide a more secure method for managing your private keys and running the validator client. Stay tuned to our future updates for upcoming work on this.
Upcoming Work
Continuing BLS Signature Aggregation Work
We are continuing to explore the best library to use for BLS Signature Aggregation, which is a critical component of Serenity. There are a bunch of C++ implementations out there, but we want to pick one that is the most modular, easy to configure, has the least overhead, and requires no additional system installations from our users. That is, we want people to be able to install it in other projects or for people to run Prysm without the need to have weird C libraries installed on their machine.
So far, Chia Network’s BLS-Signatures repo is the most promising and we are taking an active stance to make it friendly enough to use in our Prysm client. More updates on this to follow for the next update.
Prysm Testnet
Announced at Devcon, we’re working on building out our public test network for Prysm with a scheduled launch in the first quarter of 2019. This testnet will feature a mechanism for new beacon chain nodes and new validators to sync and participate with other Prysm clients. Initially, this network will -launch supporting only Prysm clients with multi-client support coming later in 2019. This launch will be a great opportunity to monitor resource requirements for running validators for long periods of time in a highly available configuration. More details to come on this topic in future updates!
More Spec Changes and Improvements
Coming up next, we are following changes to the spec very closely to make sure we continue having a fully-functioning beacon chain node which can advance the chain via Proof of Stake and rotate validators correctly across cycles (a cycle is a period of 16 second slots, currently set to 64 slots). A lot of work is being done to ensure shuffling functions properly and that state transitions are not broken due to internal logic flaws of how validators are handled by the protocol. Make sure to follow the official Ethereum 2.0 spec (Serenity) for latest updates on the topic.
Miscellaneous
Serenity Implementers Call
The next Serenity client implementers call will take place this Thursday, Nov 15 at 14:00 GMT. This one will have a lot of content and interesting follow-up conversations from Devcon, so follow the Github thread 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 :).
Check out our contributing guidelines and our open projects on Github. Each task and issue is grouped into the Phase 1 milestone along with a specific project it belongs to (smart contract related tasks, notary node tasks, etc.).
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 — we need all the collaboration we can get 🎉
Official, Prysmatic Labs Ether Donation Address
0x9B984D5a03980D8dc0a24506c968465424c81DbE
Official, Prysmatic Labs ENS Name
prysmatic.eth
