Serenity Now!

2018 was a tumultuous year for Ethereum, as the leading blockchain smart contract platform went through both impressive growth and extended stagnation. ICOs were the major driver of volatility earlier in the year, with projects raising on Ethereum in order to fund their development. As the year went on, the ICO market slowed and scepticism about the network’s failure to address its scalability issues began to influence market sentiment. The message was clear from investors — update the protocol.

These scalability problems stem almost entirely from the protocol’s current low transaction processing rate of ~ 15 transactions per second. Mainstream digital payment processing systems operate in the thousands of transactions per second, and Ethereum’s ambitious goals of operating enterprise smart contracts will require an order of magnitude more than that. The Serenity update (or Ethereum 2.0) targets Ethereum’s processing efficiency, implementing two major technical upgrades in order to do this.

Serenity’s innovation is considered the culmination of all Ethereum research up until now. Vitalik’s keynote at Devcon 4 in November of 2018 outlined the content of the update, finally clarifying exactly what to expect from the protocol in the longer term future. We will break down each part below:

Casper (Proof of Stake)

The Casper update is Ethereum’s implementation of Proof of Stake (PoS), a new mining algorithm which changes the way in which blocks are allocated to validators. Currently Ethereum operates on a version of a Proof of Work (PoW), whereby blocks are allocated to miners based on the solving of a resource heavy mathematical equation. PoS instead randomises block allocation based on the amount of currency staked, rather than the amount of computational power.

The complexity of Casper’s implementation has been a major roadblock in the development of Serenity, as the Ethereum development team has looked at both Friendly Finality Gadget (FFG) Casper and Correct by Construction (CBC) Casper.

FFG Casper was the original proposed PoS system where mining partially relied on Proof of Work and Proof of Stake separately. The blocks are mined as normal via the ethhash mining algorithm, but every 50 blocks finality is assessed by staking validators. The idea was that each update to FFG would then reduce the number of blocks for PoS finality checks (from 50 downwards) — thereby easing the transition into the a pure PoS system. This will play a small role in the transition of the network from PoS to PoW, but it is unlikely we will see the protocol relying on FFG Casper for a long period of time.

From a scaling perspective, pure PoS Casper (FFG) is efficient by reducing the computational load on active Ethereum nodes. PoW networks rely on constant confirmations of consensus on all blocks within a network, meaning that nodes are constantly validating the entire blockchain — on top of the already costly process of block mining. By confirming finality at checkpoints, Casper massively reduces the burden of confirmation on all nodes, as only a small part of the blockchain need be considered by each individual node. Additionally, this system works like a checkpoint system would on a PoW chain, preventing reorganisation attacks like we saw in the recent BCH Hash War.

In relation to other PoS systems, Casper targets availability in the form of “liveness” of its validators, rather than consistency — something which the Cosmos PoS system Tendermint prioritises. It has harsher punishment mechanisms than normal blockchains, as the protocol targets a game theory outcome where the dominant strategy of all validators is to follow the consensus. Whilst most systems have economic costs for malevolent behaviour, they haven’t typically been sufficient in producing this game theory outcome.

Sharding

The second major facet of Serenity’s scaling solution is the implementation of a sharding system. Sharding is the seperation of the Ethereum blockchain into discrete partitions named shards, each containing their own independent state and transaction history. Each individual shard has its own nodes, and each shard would serve as its own blockchain — meaning that the potential transaction throughput of the shards is far higher than the traditional mainchain based system.

The multistage transition to sharding has been outlined in detail on the Ethereum github (here), and there are 3 main phases. The first, the ‘beacon chain’ phase constitutes two seperate blockchains — the PoW former mainchain and the new FFG Casper driven beacon chain. This phase is slated for 2019, but will likely not last long as it is considered a transition phase. The second phase, shard chains, brings the introduction sharding to Ethereum. This phase is expected to reach mainnet sometime after 2019 — potentially 2020 or 2021.

The basic system of sharding works as follows — Validators stake their Ethereum (proposed that 32 Ether is the stake) into a ‘validator contract’ onto the main Ethereum blockchain. They are then randomly assigned an individual shard to validate on, being rewarded based on their validation relative to consensus. Where the complexity is introduced is in the communication between shards, as individual shards need to consider what is occuring elsewhere as to avoid the double spend problem — along with numerous other similar attack vectors. This is done via the use of ‘proposers’ who mediate the cross-links between shards — monitoring the following sets of information:

• What collation the shard belongs to (e.g. shard 10)
• Information about the current state of the shard before all transactions are applied
• Information about what the state of the shard will be after all transactions are applied
• Signatures from at least 2/3 of all collators on the shard affirming shard blocks were legitimate

The next step from the cross-links system is the implementation of receipts. These regulate the confirmation of transactions across shards, as each transaction is assigned a receipt — with its validity easily checked across multiple shards via merkle trees. This means that even without transaction confirmation, the protocol can check the validity of a state change just by evaluating a transaction’s merkle receipt.

With validators, proposers, cross-links and receipts, Ethereum has a complete framework for creating and regulating shards in a way that will increase Ethereum scalability substantially. Probably the most interesting part of this potential implementation is quadratic sharding — whereby the network progresses from just shards to shards of shards, increasing scaling potential exponentially.

Other Changes

Whilst Casper and Sharding are the two major features of Serenity, there are a number of other smaller updates that will be applied as part of it. Probably the biggest of these minor changes is the Ethereum flavoured web assembly (EWASM). EWASM is simply the creation of a web assembly standard for Ethereum, allowing for a more sophisticated range of Ethereum applications to be developed natively on web platforms. By connecting the Ethereum VM directly to web platforms, the performance of state changes on the network is greatly improved. This part of the update will be coupled with a full scale migration of Ethereum 1.0 accounts to Ethereum 2.0 systems, and is slated as phase 2 of the Serenity update. The release of this will be in the longer term, as the previous two phases obviously must come first.

From an investor point of view, it is difficult to know what to expect from the market in response to Serenity. The best course of action seems to be a wait-and-see approach, as these scalability solutions have only been floated in theory — not in reality. The timeframe of these updates are key, as many speculate Ethereum will lose its first mover advantage in the time it takes for these to be implemented. We will certainly be monitoring the situation closely, given the amount of ICO capital tied to the success of the network.