In this three post series, I am going to be talking about Plasma with increasing levels of complexity. In this post, I will introduce the need for scalability, and how the ideal solutions are being envisioned in the community and by the Ethereum Foundation.

Scalability has been a hot topic in the cryptosphere for the past few months and has been mentioned several times as a holy grail towards achieving mass adoption. Through this series of posts, I am going to try to unveil several aspects of Plasma, why it is needed, and where it is currently in terms of technical readiness and implementation details.

Let’s start with the “WHY”

There is no doubt that Ethereum needs to scale up significantly, in order to take on payment providers like Visa and Mastercard, while also making sure that DAPPs which are trying to disrupt the incumbents (like Facebook, LinkedIn, Uber, Airbnb to name a few) can achieve the scale of these web applications. Just to reinforce the scale which needs to be achieved by Ethereum, here are a few numbers —

Throughput : ETH 15 TPS vs Visa 40,000–50,000 TPS

Volume : ETH ~500,000 vs Visa 150 million transactions.

Metrics assuming US $0.5 tx fee and these were running on Ethereum:

Uber: 5.5 Million tx/day, daily spend: $2.25 Million Amazon: 1.6 Million tx/day, daily spend: $800,000 USD

These numbers are staggering, and clearly demonstrate that current DAPPs (including Indorse) simply cannot achieve this scale with the current stack.

“HOW” can we achieve tremendous scalability?

Current efforts towards scalability can be divided into 2 distinct categories —

The first category is Layer 1 (on chain) solutions

The first set of efforts being done by the researchers at Ethereum Foundation rests on the layer 1 solutions. By “Layer 1” solutions, I mean that the solutions are based on the blockchain directly. Essentially, these solutions will try to achieve better scalability on the blockchain itself, and make the throughput faster. Two of the important solutions at Layer 1 are —

Proof of Stake (PoS) Sharding

One of the interesting properties in other implementations of sharding done by different blockchains is that the throughput achieved by increasing the number of shards is not linear since we need to consider the latencies and communication delays between the different shards.

PoS is an alternative to PoW, which is being used currently by Bitcoin and Ethereum blockchains. PoS itself is supposed to be faster and more efficient than it’s counterpart and will in itself lead to a marginal scalability on the blockchain layer itself. Sharding, on the other hand, is an attempt to essentially parallelize the transaction processing within the mining nodes by dividing the validation of transactions and block creation amongst different shards (sets or clusters of mining nodes), thus increasing the throughput significantly.

The second category is Layer 2 (off-chain) solutions

The second category of solutions is off-chain solutions. These solutions do not solve the scalability issue at the blockchain layer itself, but rather in an off-chain manner. For instance, instead of worrying about whether the blockchain itself is using a PoW or PoS protocol, these solutions would make sure that the transaction throughput is higher regardless. Currently, there are two main solutions which are trying to achieve the same end result — scalability.

State channels (Raiden network) Plasma

While the Raiden network is based on the concept of state channels, Plasma is a protocol which allows creating essentially what could be termed as “sidechains”, which default to the root chain for security guarantees. Raiden network is a separate effort which does not come under the ambit of the Ethereum Foundation. Plasma is being developed and championed by Ethereum Foundation. The white paper for Plasma was written by Joseph Poon and Vitalik Buterin last year. Since then, they have also come up with a Plasma MVP, which can be found here.

While the concept of Plasma is quite interesting, it is important to understand what it is and what it is not. Essentially, Plasma in itself is just a specification and introduces and spec’s out the concepts and best practices. The individual implementations are being worked on by several companies and teams, including companies like OmiseGo, Bankex, Pegasys (a team under Consensys) and even Loom Network.

In the next post, I will go into more details about the Plasma MVP and also touch upon the various implementations of Plasma being developed by the various teams.