Ethereum 2.0 Casper and sharding: developer updates released

Prysmatic Labs, a team of blockchain engineers committed to scaling Ethereum, recently published a development update on their open source sharding client for Ethereum 2.0 Casper.

This week’s development update is a follow up of their previous update which deals with inefficiencies of cross-shard communications. The team had addressed the canonical “Hotel and train Problem” that occurs in cross-shard communications. As explained by Raul Jordan, a developer  at Prysmatic Labs in one of his recent interviews:

“[Hotel and train problem] which is that if you book a train and you book a hotel, you want both to go through or none at all. You don’t want to end up stuck with the hotel going through, but not your train or the train going through and not you’re hotel.”

Applying the same in the context of Ethereum, the developer further explained, if  there exists Transaction A that lives on one shard and depends on another Transaction B’s finalizing, residing on another shard, having different latencies, different parameters, different types of nodes traversing on them, there exists a chance of the whole system breaking down if one goes through and the other one does not. He also added that someone’s account on the network may end up receiving more Ether than what he/she actually owns. This whole scenario can create a major issue throughout the chain, he explained.

In their earlier report, the team also discussed how the aforementioned problem could be resolved using the concept of  ‘Cross-shard contract yanking’ explained by Vitalik Buterin in one of his recent sharding research post.

However, in its current report, the team further stated that the ‘Cross-shard contract yanking’ was imperfect in terms of accommodating latencies. The team was looking to offer cross-shard communication in one single transaction. As a solution they looked back at Vitalik Buterin’s latest sharding research post titled ‘Simple synchronous cross-shard’ transaction protocol.

In his post, Buterin explains that in order to achieve a single cross-shard communication transaction, it requires data and state separation due to the possibility of reorgs [block reorganizations].

Discussing Vitalik Buterin’s recent take on level-2 solutions, the team stated:

“At Prysmatic Labs, we stand right at the crossroads of all these important onsiderations. We take it very seriously as a mission within our team to build a robust protocol for Ethereum moving forward that can last the test of time.”

In the next section of the document, the team briefly explained the GitHub pull requests, merged codes and issues that were addressed or will be addressed in the future. The team has successfully aligned the codebase with its latest 2.1 specifications. The team went on to elaborate, how it has developed a solution for Beacon nodes to bootstrap from a genesis state.

Beacon nodes are random sidechains developed by the Prysmatic Lab team that stores hashes to main chain blocks in its own blocks. According to them, this sidechain will be a full “Proof of Stake” system that will implement Casper FFG and will provide a source of distributed randomness that allows the team to build a sharding system on top of it.

In the next section, the team mentioned that a DAG [Direct Acyclic Graph]  will store information of incoming blocks and its state. Moreover, as an improvement, one of the team members introduced a solution, which made the system go easy on memory requirements. The report read:

“Nishant Das from our team then took the initiative to improve the system and instead store all processed, incoming blocks into persistent storage and only keep a simple, in-memory slice of block hashes we have yet to process for the latest slot number and then apply the fork choice rule easily.”

The team also revealed that new and exciting developments are in the waiting for implementation in beacon chain v2.1 specification. The team also integrated a functionality within the beacon nodes to allow it to save blocks and states in the database.

The team’s upcoming work includes implementing a Peer to Peer [P2P] message interaction between Validators [Proposers/Attestors] in order to exchange information. Furthermore, they will also be working on advancing the Beacon Chain from Genesis without the use of a simulator. They stated:

“Currently, we have a simple simulator that broadcasts fake, test blocks in order to test the advancement of the beacon chain for development purposes. In order to get to a meaningful demo, we want the chain to advance properly through real proposals and attestations from genesis using a beacon node and a validator client connected via RPC.”