Ethereum 2.0 Development Update #20 — Prysmatic Labs

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

Latest Research

Phase 0 Validator Client Responsibilities

Now that many of the client implementation teams are working on the validator clients, Danny Ryan from Ethereum Research has put together a preliminary document to outline the role of an honest validator. The document covers the workflow from joining the validator pool to proposing and attesting to new Ethereum 2.0 blocks. Here’s a brief summary of the information:

Becoming a validator involves:

• Generating a BLS public key used for signing as a validator
• Generating BLS withdrawal key, a “cold storage” key used for withdrawals
• Creating a RANDAO commitment used in block proposals
• Creating custody commitment used for proof of custody in phase 1+ (we are still on phase 0)
• Sending a 32 ETH deposit to the deposit contract on the ETH 1.x chain with the validator initialization parameters

After some amount of time has passed (defined as ENTRY_EXIT_DELAY ~= 25.6 minutes), a validator is active in the ETH 2.0 system and will be assigned slots to act as a proposer or attestor.

Validator beacon block proposals are expected to happen at the beginning of any assignment slot. The validator applies the fork choice rule to select the parent block as the head of the chain then creates a block with the following information:

Beacon block header:

• Slot number
• Parent root, the hash of the parent block)
• State root, the hash of the resulting state of parent -> block state transition
• RANDAO reveal, a data as part of the validators commitment
• Deposit root, the most recent root found in the ETH 1.x deposit contract.
• Signature, the validators signature on the block

Beacon block body:

• Proposer slashings, slashings to apply when a validator proposes two or more conflicting blocks for the same slot
• Casper slashings, slashings to apply when a validator casts two or more conflicting votes in the same slot
• Attestations, any attestations that have not been included yet from slots within the current epoch or the previous epoch
• Deposits, deposit logs from the ETH 1.x deposit contract to be processed
• Exits, validators that initiated the withdraw process in this slot

When selected to attest to beacon blocks, the validator should wait until halfway through their assigned slot to construct their attestation.

Attestation data:

• Slot number
• Shard number
• Beacon block root, the hash of the head block of the beacon chain
• Epoch boundary root, the hash of the block at the most recent epoch boundary
• Shard block root, the hash of the head block of the shard chain
• Latest crosslink root, the hash of the most recent crosslink
• Justified slot, the slot number of last justified slot
• Justified block root, the hash of block in justified slot

The validator will construct the attestation with the above data with their signature, custody bitfield (in phase 1), and the participation bitfield.

So far the current specification outlines the responsibilities for validator assignment on the beacon chain. Assignments on shard chains will differ and their definitions solidify in future phases.

Merged Code, Pull Requests, and Issues

State Transition Block Processing E2E Testing Complete

We now have the ability to fully test out block processing state transitions for the beacon chain by using a YAML format configuration! This means anyone can write up a test that specifies block events happening throughout state transitions a final state based on the results of these transitions. For example, we have created a sample yaml test here for testing a basic workflow of validators being added through deposits, validators voluntarily exiting the set, and validators getting penalized throughout an epoch:

https://gist.github.com/terenc3t/850832b5a651f66ac61f491d95c8f1ee

The code above can trigger deposits happening at certain slots and checking the size of the validator set increased. We can also check if applying valid penalties at certain slots penalized certain validators. We believe this format will be increasingly useful as the beacon chain evolves and more complex scenarios can be modeled. As we integrate epoch processing tests soon, we will be able to test for Casper FFG finality and more granular Proof of Stake details.

State Transition Epoch Processing Integration Complete

We recently finished integrating the entire epoch processing pipeline as defined in the specification into our state transition function. This marks a milestone of completely wrapping up the state transition function for Ethereum Serenity Phase 0 within the Prysm repo. The epoch processing consists of processing various beacon state and validator structure fields. After the last slot of the epoch, the beacon node will proceed to update validator balances, justify and finalize checkpoints, and cross linking shard checkpoints back to beacon chain. The reason we don’t want to process those fields for every slot because they are computational intensive hence we only want to do it once at the end of the epoch.

Implementing Deposit Listener For the Validator Deposit Contract

The validator deposit contract is the main bridge between the ETH 1.0 PoW chain and the beacon-chain. Future validators will deposit 32 ETH into the deposit contract and the beacon node will listen to Deposit Contract for the logs emitted. Using these emitted logs we can ascertain which validator has deposited on the POW chain then add them to the validator registry on the beacon-chain. Block proposal mechanism by the validator client also requires validator client to be aware of the most recent receipt root in the deposit contract, which would mean that this cached deposit trie would have to be constantly updated till the time comes for a validator to propose. This has been implemented in this PR.

Implementer Validator Deposits Trie

Validator deposits for Ethereum Serenity will happen through a smart contract on the PoW chain. Users who currently hold Ether and wish to become validators will deposit Ether into the contract, and the deposit data will be kept within a Merkle trie in the contract’s state for easy generation of Merkle proofs and verification once such validator runs a beacon node. Although the contract contains useful utilities to fetch Merkle branches on the fly, we also believe it will be useful for nodes to keep track of a cached local trie to participate in the voting period of deposit roots. We have implemented a simple Merkle trie in Go that matches the tracking deposits in the PoW deposit contract. This trie can be stored in persistent storage in the Prysm node and can be used by other runtime services in Prysm for deposit verification.

See more in the PR here.

Upcoming Work

GHOST Fork-Choice Rule for the Ethereum Beacon Chain

The fork-choice rule for Ethereum Serenity is officially called Latest Message Driven, GHOST (Greediest Heaviest Observed Sub-Tree). It is based on combining details of Proof of Stake finality and justification into selecting the next fork in the chain. At its core, it is a block-vote weighted function that relies on the “latest” attestation messages seen by the active validator registry, treating those latest messages as votes to cast decisions on a potential beacon chain head.

Python code for LMD GHOST can be seen: https://gist.github.com/terenc3t/417454395d48d1fbdd85770fab86b9c4

Naive GHOST is known to be quite slow, as it performs many nested looping operations to determine the correct head. Our most naive implementation runs at around 800ms for 100,000 active validators in the state to select the next beacon block head. There is, however, a whole suite of LMD GHOST optimizations that we believe can improve its efficiency more than 10x, including the way we store votes for blocks, how we compute ancestor blocks for vote checking, and how we iterate to determine the best child. Our aim is to reach 25–50ms for GHOST with 100,000 active validators through the next few PRs, with some ideas already implemented by Vitalik in the Ethereum Research repository here.

Full End-to-End Testing of Beacon Chain With Validator Deposits

Currently, we allow users to run a local demo of Prysm which simulates a real runtime by having an initial validator set and a simulator of beacon blocks being published to the beacon node. The problem with this demo is it is not quite realistic, as it does not truly model validator behavior. It also does not model how the chain or node will evolve at scale and only serves the purpose of being a visualization for a basic runtime with validator shuffling.

Instead, we want to allow users to run a full end-to-end test of a beacon chain in a way that allows for better understanding of what is happening underneath the hood, with the ability to simulate more real scenarios in which byzantine actors can exist. We will now be deprecating our beacon block simulator in favor of end-to-end YAML tests, as they will give us more confidence our system will work as part of a cluster of nodes in a test net rather than a simple, local simulation. As such, we will be leveraging our YAML test suite to attempt the following:

1. Simulate a validator deposit contract being deployed on a PoW chain
2. Simulate incoming deposits into the contract
3. Begin the beacon chain once the deposit threshold is reached
4. Perform N state transitions, with events being simulated at random slots within the simulation
5. Display the user the result on the state, validator registry, and latest block information based on the progression of the N transitions

This will give us high confidence our runtime is effective, especially if we leverage the real function used by the runtime itself.

Deprecating Our Solidity Contract to Vyper

Our Validator Deposit Contract was written in Solidity whereas the official contract in the spec is written in Vyper. We made the decision to follow the spec as close as possible so as to deprecate the solidity contract for one written in Vyper. This came about as testing on Deposit and ChainStart logs gave different results from what we were expecting due to minor changes between our contract and the Vyper contract.

Creating the Beacon Chain’s Transactions Pool

The expectation of a full validator node is to track latest attestation vote from each validator. If that node was only listening for blocks, then that would be their sole source of this information. The expectation of a validator is to run a node that is listening for attestations on the wire as well as those from blocks. The default behavior of a full node should be to support listening to attestations on the wire and reacting to this information, if it’s not supported then it can not be used by a validator. Receiving a block is a trigger for fork choice calculations so is receiving new attestations outside of a block. In design, the beacon node needs an attestation pool to track each validator’s attestation and use those data to apply fork choice. We started off with a mapping of public key to attestation data and found deficiency where we could just use mapping of participation bitfield to attestation data. The later mapping avoids duplication because in an optimal case, most validators in a committee should point to the same attestation data.

Refactor Validator Client

As much of the beacon chain specification as settled down, we can return to work on the Prysm validator client. We had deferred work in this area while we update the beacon chain node to match much of the fast-moving changes and, as a result, the validator client has decayed slightly. We also think our implementation can be less fragmented into a simple routine: validator waits for assignment slot, then performs the role.

Validator Client Private Key Management and Other Secrets

It is critical for a validator client to keep safe control of a variety of secrets, including a RANDAO reveal, a BLS private key, and information about proof of custody of shard data. We are doing more work on structuring the responsibilities of our validator client and how a validator should interact with wallets to prevent unnecessary data leak to the world. Given the document created by Danny here, there is more work getting done to further clarify what a validator client should be responsible for.

Misc

Ethereum 2.0 Implementers Call Jan 17, 2019

We just finished the ETH2.0 implementers call, it was one productive call filled with lots of great discussions on the latest researches and implementers updates. Take a listen if you haven’t yet! Agenda and Recording.

Blog Post on Ethereum 2.0

This week, James Prestwich published a fantastic post explaining the Ethereum 2.0 roadmap objectively along with its challenges and current progress. We highly encourage anyone following the project to read through the document, as it serves as a useful reference at an introductory to intermediate technical level of understanding.

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