This article explains in simple terms the scalability problem in the Ethereum network, presenting the Plasma solution based on State Channels.

Allow me more transaction per second, Ethereum!

The objective of the Ethereum network since the beginning was an ambitious one: become the next evolution of the web ecosystem, a collection of nodes, which execute code that everyone can use in a secure, transparent and completely decentralized manner, the Web 3.0.

However, even if Ethereum is a great platform due to all the potential of the smart contracts, right now it’s not free of burdens that prevent it to achieve the objective and become a completely usable system for every kind of mainstream application. One of these problems is the extensively mentioned: scalability of the blockchain.

The general definition of scalability depends on each particular problem, but as stated here, can be understood as the capability of a system, network, or process to handle a growing amount of work, or its potential expand to accommodate that particular growth.

In the particular case of Ethereum, normally scalability is associated with the throughput of the network, the transactions per seconds that the system can manage.

Currently, Ethereum can process roughly ~15–20 transactions per second, depending on how much data is attached to each transaction. Just comparing with payment-related systems, VISA, MasterCard and PayPal can process in the order of thousands of transactions per second. But considering the throughput of general web platforms, Google manages ~70,000 searches per second, Twitter ~7000 tweets publications per second, Instagram ~1000 photos upload, and so on.

The big picture is clear, if Ethereum wants to become the Web 3.0, it needs to improve its scalability.This article explains in simple terms the scalability problem in the Ethereum network, presenting the Plasma solution based on State Channels.

Different options to scale the system

Of course, the Ethereum researchers are aware of the scalability problem of the network and are working continuously to solve it.

The adopted approaches to this task can be classified in two groups:

Layer 1 strategies: Those that depend on changing the base-level protocol.

Those that depend on changing the base-level protocol. Layer 2 strategies: Those trying to implement a solution on top of the existing infrastructure.

This article will spin around the second group, Layer 2 strategies, but it’s important to not ignore the main Layer 1 representative: Sharding.

Currently every node of the network needs to process every transaction, executing the code contained in the smart contracts. This is clearly not computationally efficient.

To improve this with Sharding the network is divided in separated groups called Shards, with nodes processing independently transactions for each one of them. Consequently, the nature of the system becomes parallel. This means the original number of transaction per second the network was able to handle can now be multiplied by the total number of Shards.

Extensive explanations of Sharding can be found here and here.

From State Channels to Plasma

If there is a certainty in Ethereum, it’s that if no 51% attack occurs the network is completely secure, and if a smart contract is deployed, the code will be always executed as defined.

The second approach to scale the network leverages this inherent security as a checkpoint; the last step to assure the integrity of the network, but still just another step of a more extensive process that does not occur within the limits of the original blockchain.

From this previous reasoning derives the concept of State Channel. Here’s a practical example of a state channel:

Let’s imagine that a company decides to develop a 1 vs 1 turn-based battle game using crypto-collectibles as the main characters.

Each character will have a set of attacks based in their visual characteristics. Using those attacks turn-by-turn, they will try to defeat each other. Each player — the owner of the crypto-collectible — puts in 0.1 ETH as an ante to participate in the battle, and if their character wins, they will win the entire prize.

A typical implementation using Ethereum would include a smart contract where the users register both crypto-collectibles and block the 0.1 ETH.

Turn-by-turn, each player submits a transaction to execute an attack and, when the life of one of the characters goes to zero, the game is finished and the winner claims the prize of 0.2 ETH from the smart contract.

The problem with this solution is that for every attack, each player will need to wait for the execution of the transaction and pay the gas cost associated. Also, if a lot of people are playing the game, the Ethereum network will become congested, raising significantly the gas cost to play the game (and also to use the rest of the Ethereum smart contracts).

On the other hand, there is a more efficient implementation of the game based on the concept of State Channels.

As in the previous approach, there’s a smart contract in the Ethereum network where the players register their crypto-collectibles, placing at the same time the 0.1 ETH that will shape the prize. This smart contract will know the rules of the game, such as when the game is over, when one of the characters has zero life, or how many points of damage a particular attack causes.

As before, after registering their characters in the Ethereum smart contract, the players will start playing the game, creating and sending transactions describing the attack selected on each turn.

Until now, everything looks more or less similar compared with the previous solution, however with one important difference, just after the settlement of the characters in the smart contract, an offline communication channel is created, the State Channel.

Within this channel the transactions between the players will have the same format as a normal transaction, describing a state change in the game and containing a nonce to keep the sequentiality. But they will not be sent to the smart contract, instead they will be sent through the Internet between the players without touching the blockchain.

The game goes on and, after 10 attacks for each player, one of the crypto-collectible loses. At that moment, one of the players makes one single transaction to the Ethereum smart contract, submitting the final state of the game that contains the entire sequence of the off-chain transactions, closing the State Channel.

The smart contract checks that the transactions submitted are legit, taking into account the programmed rules, and then releases the prize to the winner of the battle.

To be sure that nobody is cheating (e.g. a player who lost tries to send an alternate final state that shows they were winning) the smart contract checks the consistency of the sequence of transactions, a period of time called “challenge period” is opened, where the participant that didn’t submit the final state has the opportunity to appeal the legitimacy of that final state by showing the correct version, as proof a transaction with a bigger nonce, that shows there were more transactions after the final sent by the cheater.

Set of State Channels connected to a blockchain

The advantage of the state channels solution is clear: using pure Ethereum smart contracts, the number of transactions — supposing a game of 10 movements for each player — would be 10 + 10 + 2 (movements + movements + register of the crypto-collectible and transfer of the prize) = 22 transactions.

Using a state channel to conduct the game, the number of transactions, supposing the same set-up and without any player trying to cheat at the end, is 2 + 1 (just the register of the crypto-collectibles and the transfer of the prize to open the channel, and the submission of the final state, closing the state channel) = 3 transactions.

Even more, having 100 movements in the game, the number of transactions in the Ethereum smart contract would remain three, including game settlement, opening and closing of the channel. The scenario could be even more complex, having a tournament with multiple players instead of only two, opening a state channel at the beginning of the tournament, doing all the transactions of the different games of the tournament off-chain and, at the end, registering the final state closing the channel.

Even though state channels are not yet flawless, because the challenge system to appeal a result depends on the availability of the appealing person who needs to be connected to the blockchain to appeal, the potential scalability of the general concept has no limits in terms of off-chain interactions.

The idea of State Channels started with payment channels in Bitcoin’s Lightning network, then was followed by Ethereum’s Raiden network, however Plasma is what could really change Ethereum as we know it.

Plasma. Blockchains tied to Blockchains

The idea of Plasma comes from the minds of Vitalik Buterin and Joseph Poon, first described in the paper Plasma: Autonomous Smart Contract, published on August 11 2017. The concept behind Plasma is completely based on the state channels, but it follows a different approach.

Plasma is composed by two fundamental pieces: the Plasma Root Chain and the Child Chains. Both are full-fledged blockchains, normally with the former being the Ethereum Main Network and the latter some other implementation with a different consensus mechanism such as Proof of Authority or Proof of Stake.

In the Root Chain there is a smart contract that knows the rules of the state transitions in the Child Chains (analogous to the rules of our previous crypto-collectibles battle game).

This smart contract will register the state of each Child Chain in form of block hashes originated in the Child Chain, and submitted periodically to the Root Chain smart contract by the entity or entities validating the blocks in the Child Chains.

Hierarchical blockchains using Plasma

Therefore, the flow of a Plasma-based application would be:

An entity creates a smart contract in the Root Chain (Ethereum for example) to register block hashes and the state transition logic of the future Child Chain.

The entity spawns a Child Chain and deploys some smart contracts that run the logic of, for example, the crypto-collectibles battle game.

To play the game players register their characters in smart contracts in the Root Chain, then they are reproduced in the Child Chain smart contracts and blocked in the Root Chain, and after that, the players interact only with the Child Chain.

All the time, the players have the right to “withdraw” the assets (the characters) from the Child Chain to the Root Chain. This mechanism is one of the fundamental parts of Plasma, because even if the entity creating and validating blocks in the Child Chain tries to produce a block with incorrect data, for example trying to steal an asset, the real owner can always withdraw the asset to the Root Chain, exiting the Child Chain. Even more, there is mechanism where everyone can submit fraud proofs to the Root Chain smart contract, causing a penalization on the entity who produced the “fake block” and rolling-back it.

There are multiple ways to try to cheat for the block producer in the Child Chain, but the secureness of the system relays always in the capacity

One of the only problems in Plasma is the edge situation where someone detects fraud in a block of the Child Chain, a fraud proof is submitted and every participant tries to exit.

Having all the participants trying to exit at the same time could create congestion, and combined with the limited time to exit after the submission of the previous fraud proof (called challenge period), some participants could not execute their transactions on time and their funds could be blocked or stolen.

The Ethereum researchers are continuously working on improving the model. Solutions to this last issue such as a responsive challenge time linked to the requirements of withdrawals on each moment have been proposed.

In brief, one thing is for sure, with Plasma the scalability potential of Ethereum is enormous, as the concept of having a Root Blockchain with associated Child Chains can be extended to an hierarchical model with several layers of Child Chains executing parallel computation.

Improving Plasma with Plasma Cash

Even if the Plasma system is completely viable, there are some practicalities that could be improved:

If a participant wants to be certain there is no fraud related with their assets, they need to monitor all the time the blocks are on the Child Chain, even for those that should not contain transactions related to their own assets.

A two-step process is needed to actually use the assets in the Child Chain: the user “deposits” the assets in the smart contract of the Root Chain and after that, they need to confirm that they received the replicated asset in the Child Chain.

If an entity wants to “steal” funds in the Child Chain, and in consequence get the rights to “withdraw” from the smart contract in the Root Chain, they only need to create the fake block and submit a single withdrawal transaction to the smart contract. The process is significantly quicker.

In march of 2018, Vitalik Buterin and Karl Floersch came up with an improved version of the original Plasma idea that solves or mitigates the previous drawbacks; they called it Plasma Cash. This new version completely focused on the implementation details of the system changes with fundamental parts.

With the new Plasma Cash approach, each deposit on the Root Chain is an indivisible coin, which can’t be merged and has an unique ID, simulating cash bills with serial numbers. At the moment of registering transactions in the Root Chain, they are not recorded in a binary Merkle tree in sequential order (using the transaction index), but rather in a Sparse Merkle Tree indexed by the ID of the coin. This provides a history of transactions for each coin deposit.

The advantages of Plasma Cash in relation to the previously mentioned issues in Plasma are:

Each participant doesn’t need to monitor and check the validity of all the blocks, they only need to receive (from the validator of the blocks) a proof of non-inclusion for their coin in those block, stating that they don’t contain any transactions related with it.

To use the amount deposited in the Child Chain, only one step is needed: the deposit in the smart contract of the Root Chain that creates and assign the ID to the coin.

If an entity wants to “steal” some funds, having them represented by multiple coins (for example 10 coins of 10 ETH), they will need to submit the “withdrawal” transaction for each of those coins.

The fundamental drawback of Plasma Cash is consequence of the indivisibility of the coins. If an user has a coin of 10 ETH, with this model it is not possible to use only 1 ETH in the Child Chain, because by definition each coin is indivisible.

There is continuous research in this field, and even if the problem is not solved yet, the solution could go through and allow coin IDs to support decimals or introduce a model of coin change providers (accounts that provide enough granularity to spend smaller amounts than the coin a user possess).

Conclusion

In summary, it’s clear that the Ethereum network needs to incorporate a solution that scales the system and fulfills the needs of continuously growing number of users.

Amongst the possible solutions, the ones based on the theory of state channels like Plasma and an improved version Plasma Cash, even during research phase, are already promising based on the solid concepts that support them.

The potential of having an hierarchical model of linked blockchains is enormous and during the next months, we will probably see several projects based on these ideas, like the ones of OmiseGO, Loom Network, and why not, maybe ETHLend.