Ethereum Sharding Biweekly Development Update #4 — Prysmatic Labs

Published in

Prysmatic Labs

6 min readMay 15, 2018

Lots of exciting news to share since our last update. Let’s dive into latest research discussions from Ethereum research team, and talk what Prysmatic Labs has been working on. Without further ado, let’s begin. 👏

Latest Sharding Research

Proof of Custody

A critique against the notary scheme currently followed in the minimal sharding protocol is the susceptibility of these agents towards the “validator’s dilemma”, wherein agents are incentivized to be “lazy” and trust the work of other validators when making coordinated decisions. Specifically, notaries are tasked with checking data availability of collation headers submitted to the SMC during their assigned period. This means notaries have to download headers via a shardp2p network and commit their votes after confirming availability.

Proposers can try to game validators by publishing unavailable proposals and then challenging lazy validators to take their deposits.

In order to prevent abuse of collation availability traps, the responsibility of notaries is extended to also provide a “Merkle root of a signature tree, where each signature in the signature tree is the signature of the corresponding chunk of the original collation data.” (ETHResearch) This means that at challenge time, notaries must have the fully available collation data in order to construct a signature tree of all its chunks.

Safe Notary Pool Sizes: RANDAO Exploration

When notary pool sizes are too small a few things can happen: A small pool would result in the notary requiring a large amount of bandwidth. The amount of bandwidth required by each notary is inversely proportional to the size of the pool, so in order to be sufficiently decentralized the notary pool should be large enough so that the bandwidth required should be manageable with a non -exceptional internet connection.

Secondly the notary pool size has a direct effect on the capital requirements in order to take over notarisation and revert/censor transactions. An acceptable notary pool size would be one that required a minimum acceptable capital threshold for a takeover of the chain.

In Vitalik’s RANDAO analysis he looked at how vulnerable the RANDAO chain was comparatively to a POW(Proof of Work) chain. The result of the exercise was that an attacker with a 40% of stake on the RANDAO chain can effectively revert transactions; to achieve the same result on a POW chain they would require 50% of the hashpower. On the other hand if the chain utilised a 2/2 notarization committee, the attacker would need to up their stake to 46% on the chain to be able to effectively censor transactions.

See the latest threads on this in the public ethereum/sharding Gitter channel.

Merged Code, Pull Requests, and Issues

Updated Documentation

Our sharding README has been completely updated to reflect the current focus of sharding research and the minimal sharding protocol we are working on. We have included sections on notaries, responsibilities of each actor in our system, and more.

Latest Sharding Manager Contract functions

We have finished aligning the Sharding Manager Contract to the minimal sharding protocol in #97. We have implemented addHeader and submitVote functions. With these functions, proposer can submit collations by calling addHeader, and broadcast collation bodies through the sharding p2p network. Then selected notary can vote for the collation header that has a fully available collation body. The collation gets accepted to the main chain when it reaches quorum size.

A full suite of tests was developed to verify the Sharding Manager Contract is working correctly.

Current & Upcoming Work

We are currently working on the following code:

Creating a Shard struct with necessary methods for data availability checking, saving/fetching collations into a ShardDB, and more. Pull Request #100
Extending the Proposer clients to interact with the latest SMC changes through Go bindings. Pull Request #111
Implementing the “Proof of Custody” mechanism as mentioned in the sharding research. Issue #112
Storing shard chaindata locally and allowing clients to reproduce it when asked for certain collations via shardp2p. Issue #109

First Bounty Closed

25 days ago, we started a bounty with the Gitcoin team in order to come up with a front-end explorer for a sharded Ethereum blockchain. Our requirements aimed it to be similar to an extended ethstats.net for sharding, or a standalone interface. Specifically, the functionality would include:

The ability to inspect transaction load on n number of shards
The ability to visualize cross-shard interactions
The ability to see number of nodes and distribution of nodes across shards
The ability to see collations happening in each period for each shard
The ability to inspect the size of canonical shard chains

A week ago, we closed the bounty and awarded 0.31 ETH to @ConnorChristie for his great work on this! Check out his design here and our Github issue that started the discussion here.

New Grant Announcement

We are very humbled to be accepted into the Aragon Nest grant program! As part of this award, we have been granted $100,000 in ETH and $50,000 in ANT upon delivering on our sharding milestones. These grants and donations make it possible for us to contribute to the community, put out bounties, and encourage open source developers to participate. So we offer a big “thanks!” to Aragon! Be sure to check out their GitHub page and apply for Nest if you’re an open source contributor or team of contributors in the Ethereum ecosystem.

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, collator node tasks, etc.).

As always, follow us on Twitter, drop us a line here or on our Gitter chat and let us know what you want to help with — we need all the collaboration we can get! 🎉