Ethereum 2.0 Development Update #21 — Prysmatic Labs
Our biweekly updates written by the entire Prysmatic Labs team on the Ethereum 2.0 roadmap
Prysmatic Labs at Aracon & Goerlicon!
3 members of the Prysmatic Labs team attended both Aracon and Goerlicon these past few days in Berlin. We were thrilled to see so many familiar faces and see the growth of the Aragon project as a focused team that prioritizes giving back to the community.
Our teammate Preston Van Loon gave a talk on what the Prysm project is and our plans moving forward, sticking to our announcement of a testnet in Q1 2019. Watch the stream of the whole event and Preston’s talk here.
Another amazing initiative that came out of ETHBerlin and happened after Aracon was the Goerlicon, a conference purely dedicated towards the launch of a new Proof of Authority testnet called the Goerli testnet for Ethereum. This was an entirely community-organized event full of amazing people that aim to maintain the ethos of decentralization.
Prysmatic Labs is honored to support the Goerli testnet with 3 Proof of Authority nodes. We plan on using the Goerli testETH to create a faucet that will onboard validators onto our ETH2.0 Prysm testnet.
Merged Code, Pull Requests, and Issues
Validator Client Initial Deposit and Account Creation
Now that the Validator Deposit Contract has stabilized in the spec, we have been focusing on getting our validator client’s runtime to work well. Now, you can create a validator client account, which will create 2 private keys: one for signing frequent data as a validator, and the other for withdrawing validator rewards into a shard in the future. We use Geth’s powerful keystore to store this data, and will be adding support for hardware wallets in the future.
After the client generates the keys, it outputs a hex data string which users can use to deposit 32 ETH into the Deposit Contract, queuing them as validators in ETH 2.0. Our nodes will listen for incoming deposits and wait for the validator to have an active status in the beacon chain’s state before it can do anything else.
Waiting for ChainStart and Kickstarting the Beacon Chain
The beacon chain for ETH 2.0 will only begin once a certain threshold of validator deposits is reached. That is, our nodes have to listen for ETH 1.0 logs from this contract to determine when they can start their runtime. We have implemented the entire listening logic and now have the ability to start the beacon node + all connected validator clients once the ChainStart deposit log is fired. This is critical for us to test in every way as it is how the real, production system will begin and give the green light to validator clients to begin performing their responsibilities as proposers or attesters.
Attestations Pool Implementation Complete
The expectation of a validator is to run a node that is listening for both attestations and blocks on the wire. Based on the newly received attestation on the wire, the beacon node reacts to determine fork choice. In other words, a beacon node with a connected validator client will be tracking each validator’s latest vote. Otherwise these validators cannot perform their duties as proposers and attesters.
From the fork choice spec:
“we need store as the type of storage object for the chain data and store be the set of attestations”
The store mentioned above is the attestation pool we are using to track individual validator’s latest attestation to design fork choice. The attestation with the higher slot number will replace the lower one. Here’s a minimal viable version we have designed over the last weekend. The next set of the tasks is to optimize this attestation pool for efficiency and design a clean up routine.
Waiting for Validator Activation
The next step in the beacon chain’s runtime is to listen for a validator client’s activation in the beacon state. Even if you register as a validator by depositing 32 ETH, you do not immediately become active. Instead, the beacon node needs to wait for your deposit to be voted on by other validators during a voting period, and then we have to wait a certain number of block confirmations on the Proof of Work chain before you are marked as “active”. Once this happens, the validator client will unblock its runtime and it will listen for attester/proposer assignments throughout its lifetime. This is our next step in our implementation.
Complete Proposer/Attester Functionality via RPC
Our teammate Preston Van Loon has been working on getting our validator client to propose and attest to blocks correctly based on incoming assignments from shuffling in the beacon node. The document prepared by Danny Ryan does an excellent job at explaining the exact role of a validator client and what it needs to do during its responsibilities.
Syncing a Beacon Block Operations Pool via P2P
Another big step for us is to allow nodes to sync block operations between each other via p2p. When a proposer needs to create a beacon block, instead of packaging transaction as miners currently do in ETH 1.0, proposers need to package what we call “block operations”. These are data structures specifying important events that have happened during the beacon chain’s lifetime, such as new validator deposits, proof of stake slashings, attestations on previously proposed beacon blocks, validator exits, and more. These will live in a structure called a “pool” similar to a transaction pool today in ETH 1.0 which will be broadcast between nodes via peer to peer networking. Our teammate Terence Tsao has already begun some of this in his PR:
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 :).
Official, Prysmatic Labs Ether Donation Address
Official, Prysmatic Labs ENS Name