Ethereum 2.0 Casper+Sharding Development Update #14 — Prysmatic Labs
Our biweekly updates written by the entire Prysmatic Labs team on Ethereum 2.0
Research Updates
Minimal VDF Randomness Beacon
In this write up, Justin Drake outlines the design for using a hardware-based implementation of verifiable delay function (VDF) on top of biasable RANDAO to create a strong entropy of unbiased random number generation.
RANDAO is a biasable entropy due to last validator has the option to either reveal or not reveal its seed, if a single user gets a hold of last 2 validators, it has 4 options to XOR and affect the out some of final seed. By hooking RANDAO output to the VDF input, we can turn RANDAO into a stronger and unbisable entropy as long as we meet the safety and liveness arguments. For more info, check out Justin’s write up here
Merged Code, Pull Requests, and Issues
Beacon Chain Validator Assignments Public API
We have finished a public API to query assignments on shards for any given subset of validators using gRPC. For example, if we want to fetch the list of what shard/slot the set of validators corresponding to public keys A, B, C, and D, we can send a gRPC request to a beacon node and get a nicely packaged response of shardID and slot assignments. We leverage this as part of our validator client in order to determine when to perform proposal/attestation responsibilities.
See more in our Pull Request here.
Attestation Processing/Relaying/Aggregation
We have decided to let a beacon node do all the hard work around attestation processing and aggregation such that validator clients can simply receive aggregated attestations from the beacon node directly. Operations such as gathering and aggregating attestations are independent from block processing and fork choice rule. There’s no good reason for node to hang onto blocks that are in a fork prior to finalization, but there’s incentives for node to hang onto attestations from at least 4 months to watch for slashing. Attestation service should be its own routine and this will ease the burden on validator clients. In the future, p2p interactions between validator clients will allow for relaying and syncing of attestations
Genesis Config from JSON
We merged in an option of providing a genesis.json file to initialize a beacon chain with an initial validator set. In production, the system will start through a defined genesis config file as this approach is also the standard for the current Ethereum implementations. We created a basic, reference genesis.json including 10 validators for local development purposes here.
Upcoming Work
Full Fork-Choice Implementation
Up next, we are implementing and designing a version of the fork-choice rule used in ETH2.0 as outlined by Vitalik’s latest ETHResearch post on the matter here. The main trade-offs between various versions are in implementation complexity, resistance to manipulation from collusion, and efficient finality guarantees. Expect a lot more work on this topic in the coming weeks.
P2P Serialization for ETH2.0
Despite the various talks on what serialization format to use for ETH2.0, there are still some concerns raised with respect to using something as barebones as Vitalik’s SimpleSerialize format. Alexey Akhunov from turbo-geth raised concerns in the latest implementers call and you can read more notes about this issue here.
For those unfamiliar, teams are deciding on a viable alternative to RLP (the encoding Ethereum 1.0 uses today), such as protobufs, flatbuffers, etc. The tentative format that was decided was a new approach called Simple Serialize.
Refactoring DB With Bolt
Finally, we are continuing to work on refactoring the data layer of the application. The first phase will be to move all database operations into a dedicated db package without switching from LevelDB. This refactor will have the additional benefit of simplifying the code, particularly in areas where the service layer is used as an additional layer of abstraction for database operations. The second phase will be to modify the db package to switch from LevelDB to Bolt. Although in our previous update we stated our preference for Bolt over Badger, after some helpful feedback from the author of Badger, we plan on benchmarking both database implementations to compare the two over real workloads.
Miscellaneous
ETH2.0 Implementers Call
The fourth biweekly ETH2.0 implementer call happened last thursday and here’s the Notes. Besides our regular client updates. Raul from protocol labs joined us to introduce libp2p daemon which is modular networking stack, it allows developers to build higher level abstractions like UNIX sockets to top. Danny from EF and Paul from lighthouse also shared their block processing timing results to verify we can process signature at scales. Check out the recordings
What’s Happening in ETH2.0 by Ben Edgington
Ben Edgington from Consensys has started publishing this great compilation of everything happening ETH2.0 development in a google doc shared here. This is a great resource for those interested in having byte-sized summaries and bullet points of the types of work being done by the different teams involved.
Prysmatic Labs Website Revamp $1000 Bounty
A special thanks to Gitcoin for putting up a bounty to revamp our website, prysmaticlabs.com. We’ve seen an exceptional response from the community within hours of the bounty posting and we are humbled. Our website is in desperate need of a refresh compared to other projects and our team simply doesn’t have the time to dedicate to modern web design. We can’t wait to see what contributors come up with!
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
