Our biweekly updates written by the entire Prysmatic Labs team on the Ethereum 2.0 roadmap

Latest ETH2.0 Spec Updates

V0.2 Release

There has been a ton of activity in the ETH2.0 repo. Kudos to Danny Ryan on creating this comprehensive release page. While it makes all the incremental changes easier to follow, it also helps developers track a release candidate code base to make sure they are up to date. Currently, most of the spec updates are bug fixes with minor optimizations, nothing drastic that requires ton of refactoring. See our tracking issue here.

Merged Code, Pull Requests, and Issues

Aligning with V0.2 spec

As we are getting very closely aligned with the V0.2 spec, the focus has been shifted to getting our validator runtime working and fixing bugs. We’ll still be paying very close attention to the incremental spec updates and picking up on important changes that have a direct impact on our test net deliverables. In the meantime we have opened tracking issues for aligning with V0.2 and future spec releases.

V0.1 Beacon Chain Running With 8 Validators Locally!

We were able to get our v0.1 beacon chain successfully running with 8 validators locally, deploying our deposit contract into the Goerli testnet, waiting for it to fill up with deposits, and getting the chainstart log fired into validators clients who were then assigned to propose or attest on beacon blocks. This is critical because it is the first piece to have a fully functional testnet!

As a result of this process, we encountered tons of bugs that required feature fixes to get this to work seamlessly. We outlined all of these problems in our tracking issue for our runtime here. This has helped us tremendously in taking a break from spec updates and core beacon chain improvements into fixing how our validators actually interact with the beacon node to propose, earn rewards, and do their job throughout their lifecycle.

Pending Deposits And Block Operations Pool

In Ethereum 1.0, we have the notion of a transaction pool. These are transactions that are held in memory (or on disk) which have not been included in the blockchain. In Ethereum 2.0, not only will we have transactions awaiting block inclusion, but we will also have validator deposits, slashings, attestations, and many other objects that await to be included in the next block.

For Prysm, we have implemented a preliminary deposit pool as a simple key/value store in memory which is populated from deposit logs received from the deposit contract on the proof of work chain. A validator can query the beacon chain node for pending deposits, include them into a block, and the beacon node will remove the deposits from the pool on block processing. A similar flow will be implemented for other types of block operations. Some will be an in-memory KV store and some will be stored on disk to persist throughout client restarts.

Deploying and testing the ETH2.0 deposit contract on the goerli testnet

We have finally started deploying and testing the ETH 2.0 deposit contract on the goerli testnet. By deploying the contract and submitting deposits to the contract , we were able to simulate how our client would function in a production environment in anticipation for our testnet. The beacon node would listen for logs from the contract and once it receives the requisite chain start log, it would kick-start the beacon chain and correspondingly allow the validator clients to start performing their duties.

With the contract current deployed in goerli and running, this has allowed us to test prysm’s deposit flow so as to ensure that it works as expected.

Deployed deposit contract with chain start even log emitted!

Proposer / Attestor Code Restructuring

Our code has gone through many changes over the last 6 months as the specification has continued to progress. Much of these changes have taken place in the beacon chain node binary while the validator client code decayed. We had a design where multiple parallel processes represented the validator’s roles, but this logic was difficult to follow, out of date, and generally prone to issues.

We’ve simplified and abstracted the validator logic to less than 50 lines of core logic. This main routine is easier to understand, follow, and debug than having multiple routines handling different responsibilities of a validator.

Check out the simplified validator logic here: https://gist.github.com/terenc3t/991465f3c54d8d22a380e2c5abc89e7a

Validator Account Credentials Creation Process Complete

We have been putting a lot more work into our validator client to ensure it can correctly form its credentials and store them similar to how geth does with its keystore. Now, before launching a validator client, users need to create a validator account which will print out a deposit data string. This data can be sent to the deposit contract via mMtamask to onboard the validator into Ethereum 2.0. To make this process nicer, we plan on creating a simple, clickable UI that does this for our validator users so there won’t be any need to copy around weird hex strings.

Allowing New Validators to Join Our Beacon Chain Local Configuration by Implementing ETH1 Deposit Root Voting Mechanism

Deposits once the chain has started are handled a bit differently by the beacon chain. Given it is really important for the network to reach consensus on which deposit roots are valid in the deposit contract, we implement a voting mechanism to vote no ETH1 deposit roots and block hashes for onboarding new validators. This voting process is outlined in the ETH1 data section of the validator specification here. We need to implement and test this voting process thoroughly for us to have high confidence new validators can join the Prysm network. This is one of our next implementation efforts.

Validator Assignments Lookahead

Currently, how validator look ahead works is that it gives a validator a minimum period of one epoch in order to get ready to either propose or attest. This is outlined in detail over here in the validator specification. Part of our current goal to align with validator specification, we intend to allow validator clients to have that lookahead time for their assignments so that they can be informed in advance in preparation for their duties and this would allow validator to start syncing with the expected shard in which they are needed to perform their duties.

Preventing Validator Slashing by Storing Previously Signed Data to Disk

The current validator spec is a treasure trove of information to learn more about the exact responsibilities a validator has in the Ethereum 2.0 lifecycle. We want our clients to protect validators against slashing in safest ways possible. The spec outlines:

To avoid “proposer slashings”, a validator must not sign two conflicting ProposalSignedData where conflicting is defined as having the same slot and shard but a different block_root. In phase 0, proposals are only made for the beacon chain (shard == BEACON_CHAIN_SHARD_NUMBER).

In phase 0, as long as the validator does not sign two different beacon chain proposals for the same slot, the validator is safe against proposer slashings.

Specifically, when signing an BeaconBlock, a validator should perform the following steps in the following order:

Save a record to hard disk that an beacon block has been signed for the slot=slot and shard=BEACON_CHAIN_SHARD_NUMBER.”

Some of our next priorities involve saving signed validator data to disk for easy retrieval by the client in case there is an unexpected shutdown or event at the required time of proposing.

Miscellaneous

Etherscan Supports Vyper Contract Verification!

We asked etherscan if they had this functionality on the new Goerli testnet. They didn’t have it or have any plans to work on it. However, after a few twitter DMs over a week, Etherscan added support for verifying Vyper contracts!

This is critical to support Ethereum 2.0 validator deposit contract. Here’s an example deployed on Goerli: link.

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 0 milestone along with a specific project it belongs to.

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.

Official, Prysmatic Labs Ether Donation Address

0x9B984D5a03980D8dc0a24506c968465424c81DbE

Official, Prysmatic Labs ENS Name

prysmatic.eth