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

Latest Research Updates

Lots of excellent research on state transitions were published in the last two weeks, we’ll go over the two of them below. The general idea is to leverage layer 2 solutions to help solve difficult in-protocol problems (e.g. how to achieve faster finality for cross-shard communications).

A minimal state execution proposal

Vitalik outlined a maximally simple layer 1 state execution framework which is intended to be abstract and work with smart contracts a layer higher. Vitalik described the interfaces ofthe state execution framework and what all the global state values should be. At the high level, each user contract tracks a total fee value, the contract also pays rent based on its total size, if the contract’s balance is less then 0, the contract is deleted. Towards the end, Vitalik suggested for every shard there can exist special utility contracts to return useful environmental data like shard data like block number, block hashes, general and claim receipts for cross-shard communications. To learn more, take a look here.

The intro of Vitalik’s post

A layer 2 computing model using optimistic state roots

As mentioned in this post, the low speed of cross-shard communication is a concern given it takes six minutes for a message to get across between shards. Vitalik described a layer 2 technique by storing multiple different copies of individual smart contract in the state and each contract copy has its own “dependency signature”. These dependency signatures provide explicit conditionals on claims about state roots in other shards, and once the shard knows what claims about the state is, the dependency then can be resolved. To learn more, take a look here.

Merged Code, Pull Requests, and Issues

Refactoring Beacon Node Processing

The official Ethereum Serenity specification has been under some heavy work after Devcon. A lot of teams coming together to figure out the direction the state of the art should take is no easy task, but we are getting close! At the time of writing, most of the changes being done to the current spec are bug fixes and smaller details related to validator exits, which marks a stark contrast from where Ethereum 2.0 was a little less than a year ago, when all we had was the Sharding FAQ.

Oh, fun! All the work so far for beacon node refactoring.

At Prysmatic, we have been carefully following the research changes to ensure we don’t write code that will get quickly deprecated. Despite this, we still have to undergo a medium refactoring effort to fix how our node works according to the latest improvements to state transitions and block processing for Serenity. If you’re curious to see what it means to translate the spec into real code, check out our tracking issue here

Simple Serialize Implementation for Ethereum Serenity

We finally have a first version of the Simple Serialize specification implemented in Prysm which will serve as the common serialization format across all of Ethereum Serenity. A big thanks goes to our teammate Jie Hou, who has created the implementation along with tests in his Pull Requests merged here

PR opened by Jie on Github. Thanks Jie!

Having Simple Serialize is one of the first steps towards having cross-client conformity tests. That is, we can make sure the code on Prysm and on other clients such as Lighthouse or Nimbus follows the same behavior by passing serialized objects between each other. This is going to be an exciting event to look forward to, as we are keeping cross-client compatibility top of mind while implementing common interfaces.

Combining Initial Sync and Live Sync

With the ongoing refactor of our Beacon Node, we realized that it would be ideal to modify how current sync services function. Previously we had split up sync services into two distinct services namely Initial Sync and Normal Sync due these two have different requirements. However, with these two services separated, we ran into issues running concurrently which led to a lot of added complexity on the startup of our node to determine which service to run and which service to switch off. With the merging of this PR, Prysm beacon node can run a simple query on the current chain head of the network and coordinates how sync will function namely querying for the state of the network when deciding whether to run initial sync or normal sync. This reduces the complexity in beacon node startup routines and makes sync simpler to work with. keep a look out for this issue being tackled which will enable batch syncing for our nodes.

Upcoming Work

Validator Client Roles and Responsibilities

A current area of work at Prysmatic is in determining the exact role of a validator client in syncing a shard chain. What is the difference between a beacon node and validator client? In particular, we posit that a beacon node is only responsible for keeping track of a validator set, shuffling a validator set into shard committees, and applying Casper Proof of Stake rewards and penalties based on a protocol. We envision a validator client is a piece of software that uses information from a beacon node to sync shard chains, perform validator responsibilities by allowing a user to interface with a hardware wallet or keystore, and will be a machine with much lighter resource requirements. We have put together a design document detailing the different roles in the system here.

BLS Signature Aggregation

One of our contributors, Julian from Phore project, completed a bounty for a pure Go implementation of BLS12–381 here. It is a great start for supporting a pure language implementation that gets over all the inconvenience of using CGo as an alternative. We’ve been very happy with Julian’s contribution and there is still a lot of room for optimization. If you are interested in making fast Go code even faster, take a look at the project and let us know on Discord about your contributions.

Misc

Beacon chain implementers call this Thursday

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