Ethereum 2.0 Casper+Sharding Development Update #15 — Prysmatic Labs
Our biweekly updates written by the entire Prysmatic Labs team on Ethereum 2.0
Merged Code, Pull Requests, and Issues
Minimal Viable RANDAO Implementation
We have implemented RANDAO from the latest beacon chain spec. This RANDAO scheme is mainly used by the proposers to generate in-protocol randomness. Whenever a proposer gets assigned to propose a block, it peels off the first layer of the previously committed onion hashes, and which the hash is included as part of the proposed block.
When a beacon node receives the proposed block, part of the block processing responsibility of a beacon node is to verify the hash of RANDAO reveal from the block and compare that with the current RANDAO reveal from the proposer stored in crystalized state. If it’s not, the beacon node can safely discard the block knowing it’s not correct.
Whenever a beacon node receives the block, the node XORs the RANDAO seed of a block with the current RANDAO seed in active state. In another word, beacon node tracks RANDAO seed every slot and when validator set transition happens, beacon node uses the most up-to-date RANDAO seed to sample a new set of validator committees for the next cycle. We have implemented the basic functionality of a RANDAO in this PR.
New Special Record Object
This new special record object is used for validators to notify every node in the beacon chain a special event has happened such as validator logging out or validator slashing. These special records are part of beacon block and active state. During beacon block processing, a beacon node extends the list of special record object for active state with those included in the block. During state recalculation, beacon node goes through each special record inside the active state to update each validator state whether a validator was logging out or getting slashed. The special record object is also used to update each validator RANDAO seed. We have utilized special record object in this PR.
Validator Rotation
A validator set change can happen after state recalculation if the following conditions meet. During validator set change, beacon node updates validators status and recalculates the total ETH that has been penalized in the last withdrawal periods, it also recalculates validators penalties if they were slashed. We have implemented validator rotations in this PR.
Refactor Crystallized State
Previously a lot of the Casper mechanisms such as applying validator rewards/penalties and the shuffling of validators was located in the types package. This made it hard to effectively debug our code as the types package was meant to be a wrapper for our Protobuf primitives. With all the Casper logic being brought into the package, we had a hard time to debug tests. After this PR was merged most of the core logic was moved to the Casper package, with the methods in the type package instead now calling functions from the Casper package to perform vote tallying or applying validator rewards. This is detailed here PR.
Upcoming Work
Implementing SSZ
One of the requirements for a consensus algorithm is that the data being agreed upon is universally consistent. Ethereum 1.0 uses an encoding scheme called Recursive Length Prefix (RLP), but we’re taking advantage of the clean slate we’ve been given with Ethereum 2.0 by implementing a new encoding scheme called Simple Serialize (SSZ). There’s an in-progress description in ethereum’s spec repo, as well as some working implementations in several languages. We’re going to begin work on our implementation of SSZ this week, and looking forward to seeing how it performs against RLP.
Implement Private Key Management
An upcoming PR will deal with private key management by the beacon client and validator client. A basic functionality that we are aiming for would be for a user to store their keys securely in a client and be able to access their private key by unlocking a keystore. This will be very similar to how Geth manages its keys. Our primary aim is for validators to be able to certify their POW chain key through their validator client key. A validator client spins up using a private key which is verified by that validator’s mainchain private key. We intend to encrypt the private keys using the AES-128-CBC algorithm which is the same one currently used by ETH 1.0 clients to encrypt their private keys. This is a tracking issue for the PR.
BLS Signature Aggregation
We have begun integrating BLS Signature Aggregation into our repo. Following the work was already done by teams such as Lighthouse and the Python implementation of the beacon chain by the EF, we are leveraging external, low-level crypto libraries and creating a wrapper in Go over BLS12–381. We are leveraging Dfinity’s random-beacon chain playground as a reference implementation over the herumi/bls library on Github. Integrating BLS will unlock a massive set of possibilities in Prysm, as we’ll finally be able to benchmark block attestation processing at scale, giving a better idea of the scalability benefits of Ethereum 2.0.
GHOST Fork Choice Rule
We have begun a non-trivial fork choice rule based on GHOST as specified by the current Ethereum 2.0 spec. Given there is still pending research on whether to use Immediate Message Driven Ghost vs. Latest Message Driven, we are implementing our block scoring function to consider a block’s last finalized slot, last justified slot, and current slot. This nontrivial fork choice rule would trigger possible chain reorgs, in which a block with a smaller slot number could actually be determined as canonical. In this case, a node would have to reorganize its current head recursively in order to maintain an effective chain state. In the meantime, having an initial implementation of GHOST will allow us to benchmark interesting results about the beacon chain at scale in tandem with attestation block processing after signature aggregation is complete.
Miscellaneous
ETH2.0 Implementers Call #5
The biweekly ETH2.0 implementers call #5 happened last Thursday. Check it out for client and research updates. The recording is here.
Wave IV Grant
Ethereum foundation announced Prysmatic Labs received a new grant of 500k for client diversity. Consider we started with just a version and a small Github repo 7 months ago, we are both proud and humbled by this achievement. We’ll keep working hard to make ETH2.0 a reality.
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
