Ethereum 2.0 Development Update #17 — Prysmatic Labs
Our biweekly updates written by the entire Prysmatic Labs team on the Ethereum 2.0 Serenity roadmap
Latest Research Updates
Encumbents: Instant Cross-Shard Payments
Vitalik showed another approach on ETHResearch towards having fast cross-shard transactions for end users. In particular, this uses the notion of creating a global “receipt” object, which tracks a credit/debit of ETH from a particular account. Given the finality of cross-links takes 6 minutes, which is not feasible for instant transfers, we can actually get around this by issuing a certain queue of special objects within an account model known as “encumbents”. What this means is this that if Alice sends Bob a transaction and Bob’s account is on a separate shard, a receipt is created and a queue is added on Bob’s account related to the receipts detailing what Bob is able to spend. This is more of an end-user optimization approach that makes it possible for interactions like these to occur without needing to wait 6 minutes for cross-link finality on a shard. This scheme gets notoriously more complex the more transaction hops occur, but it is a neat idea explained in detail in the post.
See more on the ETHResearch thread here.
STARK-friendly Hash Functions
Given the plan to support zero-knowledge proofs called zkSTARKs into Ethereum, Vitalik has outlined a proposal for a hash function to use in ETH 2.0 Serenity that will be STARK-friendly. That is, it is composed of “simple operations within a finite field”. Having this sort of hash function can also serve as the backbone of the Verifiable Delay Function (VDF) that will serve as the cryptographic primitive of strong pseudorandomness in Serenity.
Merged Code, Pull Requests, and Issues
Refactoring Serenity to Use a Single State
At the conception of the ETH2.0 roadmap, the original plan was to have two different state representations that captured occurrences across the beacon nodes in the network known as the Crystallized State and the Active State. In particular, the Crystallized State would only change once per cycle transition and would be responsible for items such as validator set rotation and tracking important items related to finality of blocks. The active state would change on a per-block interval and would be tasked with tracking attestations on beacon blocks and the RANDAO hash revealed by validators to use as the source of randomness for shuffling in the next cycle transition.
The reason this distinction occurred was due to the difficulty and inefficiencies of merklizing a single state. However, further optimizations have changed the Serenity spec to use only a single BeaconState object. We have completed this refactor in a major pull request the greater simplifies the system. Now, there is a single BeaconState in Prysm that tracks all relevant items of the beacon chain’s lifecycle. See the PR here.
Beacon Node P2P Bootnodes & Relay Nodes
As we get closer to being able to run our beacon nodes on a testnet, we have begun our foray into building the p2p infrastructure required for beacon nodes to find each other as peers and establish a standard DHT-style approach for p2p. We plan on creating a cluster of beacon nodes on Kubernetes that we can use to ensure the system works as expected from genesis.
We have created a p2p bootnode using libp2p as well as a relay node that will help nodes find each other appropriately across the network. See the relevant PR’s here.
Initial Beacon Node Sync
With the merging in of this PR, we now allow nodes to query other nodes about the latest chain head in their local chain, so as to determine whether a node is synced or not. With this PR merged in this allows nodes to determine whether to run initial or normal sync. Consequently, this unblocked this PR to be merged, which allowed initial sync to effectively function with a simulator as previously new nodes entering the network were unable to sync to the current chain head. With the PR being merged this problem was solved and nodes are now able to sync with their peers.
BLS Implementation Completed
We have completed a Go wrapper around a BLS12–381 implementation in C++ created by @herumi on Github. Our repo allows any Go project to import the package and use BLS for signature aggregation and verification, which will be critical for Prysm. The problem is this library requires users to have a C dependency known as libgmp installed on their machines. We have created a bounty that will allow us to package it without this dependency here.
Additionally, @meyer9 is working on a bounty for a pure Go implementation of BLS12–381, as that will solve a lot of ills of using C with Go that we have encountered so far. Follow the issue thread here for more information.
Running Validator Shuffling Tests Using E2E Test Runner
One of our new contributors, @houjieth, has completed a bounty for running validator shuffling tests using an e2e test suite we created in Prysm. We will be using this test suite to ensure critical components such as fork choice and block processing work as expected. This test suite works in YAML format and makes it easy for anyone to write appropriate tests without being familiar with the inner Golang details of the Prysm client. We will be using this for cross-client conformity tests moving forward.
See the PR here.
Upcoming Work
Validator Client Refactor
Our goal with our v0.0.0 release was to get a basic, local beacon node + validator client working and shuffling validators on shards at every cycle. However, the validators in our demo didn’t do much as they did not have the ability to broadcast attestations and connect to other validators in other to process and vote on the data they are assigned to. Our current validator client has not been updated in a while as we have been focusing on aligning our beacon node with the spec appropriately.
Validator Registration Contract Updates
Some of our upcoming work relates to bootstrapping the Beacon Chain system by allowing holders of ETH on the proof of work chain to deposit 32 ETH into a Validator Registration Contract. This contract will track deposits until they reach a minimum threshold of participating ETH and will then issue a chain_start log, which beacon nodes can listen to and determine when they must begin their responsibilities. We will be updating our contract implementation to match the latest one defined in the spec here.
E2E Tests for Running the Beacon Chain / Validator System
Currently, we use a simulator attached to our beacon nodes in development that allow us to see if the system functions properly in a “real environment” where there are other beacon nodes connected as peers broadcasting blocks between each other. We aim to have a system that does not require a simulator to function in preparation for our testnet and for that, we will be leveraging our YAML test suite to create end-to-end tests of our system so we can always be confident a merge on the master branch will maintain integrity at runtime.
Simple Serialize vs. Protobufs Revisited
There was an extensive discussion on Github by our teammate Yutaro on whether we should be using protobufs or simple serialize for the p2p wire protocol. The majority voiced their concerns around protobufs, arguing they add a lot of complexity and bloat as a third party format to Ethereum. At Prysm, we understand the need for all clients to be aligned on certain implementation details especially at the p2p layer, and we will support both Simple Serialize and Protobufs. We can allow all prysm <-> prysm communication to use protos by detecting a special prefix in the p2p handshake, and simple serialize for all other communication between other clients. This will give us a better idea of runtime efficiencies of using protos so we can revisit the topic in the future.
Ethereum Serenity Implementers Call #7
The next ETH 2.0 implementers call is this Thursday! Check out the stream link and topics of discussion in the issue 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
