Overview of Ethereum Scalability Solutions

Published in

IBBC.io

12 min readJul 25, 2018

In order to reach the so desired mass adoption, crypto-currencies have to overcome a major road block: the low number of transactions per second (TPS) they can currently process. This lack of scalability of the current blockchains draws a lot of attention in the crypto-sphere and the promise of a TPS rate equivalent to what centralized services such as PayPal or Visa offer is made by many altcoins in order to carve out a place under the spotlights.

Until now though, no one has been able to demonstrate such transaction rate in a real production environment. Indeed, the scalability problem has to do with the idea that current blockchains have to find the right balance between these 3 properties:

Decentralization
Scalability
Security

Increasing one means decreasing at least one of the others. However, in order for the Ethereum to fulfill its ambitions (be the world decentralized computer), it must shift this paradigm and increase the current 10–15 TPS. Well aware of this, the community is currently mainly working on three different, yet complementary solutions: Casper FFG, Plasma and Sharding.

In the rest of this article we will try to simply present these solutions and give an overview of the current state of development.

Casper FFG

Casper FFG (standing for Friendly Finality Gadget) is the name of a new block verification protocol that would, among other things described below, mark the shift of Ethereum to Proof-of-Stake (PoS).

In addition to be a step toward scalability, the adoption of PoS will supposedly bring many benefits such as solving the high energy consumption issue, mining pool centralization, etc.

Casper is not new as the first version of the paper was written in September 2014. It has seen multiple edits and the latest version was published in November 2017. However, Casper induces massive change in the way Ethereum works, requires a hard fork and thus must be very thoroughly tested. This explains why the adoption of such protocol is somewhat slow.

How Ethereum work under Casper FFG?

Under Casper FFG, Proof-of-Work (PoW) and Proof-of-Stake (PoS) are going to run in parallel, the former for block proposition and the latter for block verification. Under “normal circumstances”, we expect that the proposal mechanism (PoW) will typically propose blocks one after the other in a linked list (i.e., each “parent” block having one and only one “child” block). But in the case of network latency or deliberate attacks, the proposal mechanism will inevitably occasionally produce multiple children of the same parent. Casper’s role is to choose a single child from each parent, thus choosing one canonical chain from the block tree.

Miners (PoW) and validators (PoS) have a key role to secure the system and thus need an incentive to play that role.

Miners receive the typical block reward when they “mine” a block. However, the current 3 ETH block reward will be diminished to 0.6 ETH.
Validators receive a reward function of the amount of ETH they place as collateral of their vote (Cf. Below). If they misbehave (either vote wrongly or go offline) they get penalized. Rewards and penalties have not been finalized by the Ethereum team yet. An initial suggestion is that, assuming 10 million ETHs are deposited: the reward for staying online and voting would be 0%-5% per year; the penalty for going offline would be 5–10% per year or more in extreme circumstances; and the penalty for making conflicting votes would range from 1% to 100% and getting logged out.

Casper introduces with several new concepts:

Checkpoints: The genesis block is a checkpoint, and every block whose height in the block tree (or block number) is an exact multiple of 100 is also a checkpoint. The “checkpoint height” of a block with block height 100 ∗ k is simply k. Casper only considers the subtree of checkpoints forming the checkpoint tree.
Supermajority link: ordered pair of checkpoints (a, b) such that at least two third of validators (weighted by deposit) have published votes with source a and target b.
A checkpoint c is called justified if there exists a supermajority link from a justified checkpoint and c.
A checkpoint c is called finalized if it is justified and there is a supermajority link c → c ′ where c ′ is a direct child of c.

Validators must follow these 2 fundamental Commandments:

I. A validator must not publish two distinct votes for the same target height.

II. A validator must not vote within the span of its other votes (cf. Figure below).

The thick arrows represent the supermajority links between checkpoints. Here, we see that this figure violates Commandment II as there is a supermajority links between a2 and a3 (with respective height 3 and 4) and a supermajority link between b2 and b3 (with heights 2 and 5). Here we see:

Any validator who violates either of these commandments gets their deposit slashed.

One can prove that it is impossible for two conflicting checkpoints to be finalized without ≥ 1/3 of the validators violating one of the two Casper Commandments.

For all stakeholders the fork choice rule is: follow the chain containing the justified checkpoint of the greatest height.

In order to enable new validators to join and some others to leave and prevent certain types of attacks, there is a withdrawal delay of approximately 4 months (15 000 epochs) for a validator to get back his deposit. If, during the withdrawal delay, the validator violates any commandment, the deposit is slashed.

I want to highlight 2 major features of this protocol.

Accountability

The voting power of a node is equal to its share of the total collateral put “at risk” by the entire system. If a validator violates a rule, we can detect the violation and know which validator violated the rule. Accountability allows us to penalize malfeasant validators, solving the “nothing at stake” problem that plagues chain-based PoS (v. PoW where the mining itself is expensive). Because PoS security is based on the size of the penalty, which can be set to greatly exceed the gains from the mining reward, PoS provides strictly stronger security incentives than proof of work.

Finality

One majors feature of Casper FFG is finality. In typical PoW system, each block stacking over the one containing your transaction makes it a little more difficult to rewrite history and invalidate your transaction. However, no matter how long you wait the block will never be finalized 100%. Casper FFG makes sure that a finalized block can never be reversed, no matter the voting power of the attacker.

How does Casper FFG make Ethereum more scalable?

Casper FFG is an amazingly complex and ambitious project that goes beyond scalability and has an impact on every aspect of Ethereum. Concerning scalability, we can mention the following:

PoS enables to diminish block time to a minimum as it is easier to get a a winner than in PoW.
Enables sharding (Cf. Below)

In Vitalik Buterin’s words:

“Casper remains imperfect. For example, a wholly compromised block proposal mechanism will prevent Casper from finalizing new blocks. Casper is an PoS-based strict security improvement to almost any PoW chain. The problems that Casper does not wholly solve, particularly related to 51% attacks, can still be corrected using user-activated soft forks. Future developments will undoubtedly improve Casper’s security and reduce the need for user-activated soft forks.”

Even though the first implementation of Casper proposes only a hybrid PoS as the block proposal mechanism is still built on PoW, Ethereum will certainly eventually move to a full PoS mechanism. No concrete implementation has been yet proposed.

Plasma

Plasma (aka. off-chain solution or layer-2 scaling) is a design pattern that pretends enabling the creation of secure blockchains built on top of the main Ethereum blockchain. Like payment channels in the Bitcoin Lightning Network, Plasma is a technique for conducting off-chain transactions while relying on the underlying Ethereum blockchain as its root for security.

As theses chains can themselves have children chains, this creates a tree of blockchains as shown below:

Each chain is independent and can have its own governance rule as long as it is reporting to its parent chain. A child chain can even have a centralized authority and theoretically remain fully secure as long the root chain is secure.

How does plasma work?

In order to create child chain on the Ethereum main chain you need to create a set of smart contracts. They contains the basic rules of the child-chain, record state hashes of the child-chain, and serve as a bridge that lets users move assets between the main-chain and the child-chain. This child-chain has its own consensus algorithm, independently from the Ethereum main-chain (can be PoS, Proof-of-Authority, etc.). Once the child-chain is running, the block creator(s) periodically commit a validation to the main-chain, essentially proofing that the current state of the child-chain is valid according to the consensus rules. These commitments are recorded on-chain in the Plasma root as a proof of what has happened in the child-chain. The user interacts with the child chains without never interacting directly with the main chain.

In order to make sure that this is secure and that all operations that happened on the child-chain can still be considered final, Plasma guarantees that every party can always withdraw their funds and assets back onto the main chain at any time. So even in the case of an attacker trying to take control over the network, the worst that can happen is they force you to leave the child-chain back to the main-chain. When a user is transacting in a Plasma Chain and wants to transfer their funds to the main-chain, they submit an “exit transaction” (i.e. a Merkle proof of their transaction history proving they own a certain amount of money) and attach a small bounty to it. At that moment, there is a “challenge period.” Essentially, you allow anyone to challenge your claim by submitting a proof which marks your claim as invalid or outdated (in Plasma this can be a Merkle proof of the transaction history; in the Lightning Network channels this can be a signed message from the other party). If your claim is invalidated within the challenge period, the challenger gets the bounty and your withdrawal is not accepted.

If a node on the child chain is fraudulent, before exiting your fund you can publish a fraud proof to the root contract to show that he cheated. This fraud proof would contain information about the previous block. Based on this and according to the state-transition rules of the child-chain contained in the root, you can show that block doesn’t properly follow from the previous state and thus that there is a fraud. If fraud is proven, the child-chain is “rolled back” to the previous block. We can also make sure that any block producer who signed off on the false block in any side chain gets penalized on-chain.

The general idea is that the side chains always get their authority from the parent-chain as the local courts of justice get their authority from higher courts. If you want to challenge the decision of a local court, you can still appeal and refer to the judgment of the higher court.

Benefits to scalability

The benefits in term of scalability and speed of second layer chains are fairly obvious as most of the transactions won’t have to be processed by the main-chain anymore and that side chains could also run under faster (less secure) consensus protocols.

On the side chain, because only a much smaller number of node process the transactions (potentially as few as one), fees can be much lower and operations can be faster.

Plasma will enable to put a lot of data currently unnecessarily processed by the main chain to side chains and thus save an enormous amount of processing power and memory for the Ethereum nodes. In addition to this, some nodes may be interested in running just a side chain which is much lighter than the full Ethereum chain. They will be able to participate to the Ethereum ecosystem without having the necessary computing power and data storage currently necessary to run a full node.

Plasma will certainly be the first of these 3 solutions to become a production reality as a first iteration (minimal viable plasma) should be released in Q3 or Q4 2018.

It must be understood that plasma is just a set of tools for people to implement their own massively scalable smart contract. It is not a protocol, it is a design pattern. One must also know that Plasma raises numerous controversies about its security and contribution to scalability. These controversies could be the object of another post.

Sharding

Sharding is a concept coming from database architecture. Applied to blockchain, sharding removes the need for the entire network of nodes to process every individual transaction.

Currently, in all blockchain protocols each node stores all states and processes all transactions. This provides a large amount of security, but greatly limits scalability: a blockchain cannot process more transactions than a single of its nodes can. The idea is to remove that constraint so that the system can process many transactions in parallel while remaining fully secure.

Sharding is a broad terminology and could be implemented in practice in various ways. Currently, no one uses sharding in production and the implementation that Ethereum would use remains entirely unknown. Nonetheless, you can find more details in this amazing FAQ page.

Let’s talk about couple of challenges raised by sharding:

How can cross shards transactions be handled?

The system would use receipts (a side-effect of a transaction that is not stored in the state of the system but is kept in a Merkle tree so that its existence can be easily verified to a node) in order to enable cross shards communication.

The FAQ gives a simple example:

Account A on shard M wishes to send 100 coins to account B on shard N:

Send a transaction on shard M which (i) deducts the balance of A by 100 coins, and (ii) creates a receipt.
Wait for the first transaction to be included.
Send a transaction on shard N which includes the Merkle proof of the receipt from (1). This transaction also checks in the state of shard N to make sure that this receipt is “unspent”; if it is, then it increases the balance of B by 100 coins and saves in the state that the receipt is spent.
Optionally, the transaction in (3) also saves a receipt, which can then be used to perform further actions on shard M that are contingent on the original operation succeeding.

How prevent easier 51% attacks?

Randomness is key to make sure that dividing the network into N shards won’t make it easier for attackers to join forces and reach the necessary voting power to dominate a shard (as you need N times less computing power / voting power to successfully complete an attack). Validators won’t be able to pick their shard and will be reshuffled “frequently”.

Sharding first needs Casper FFG to be put in place in order to be able to split the network into shards easily. Indeed, because validators need to “register” and lock a collateral, PoS gives the list of all validators with their respective voting power. The network can then be divided into shards based on that list. For this reason and because implementing sharding itself remains a huge challenge, don’t expect any production grade implementation of shards before 2020. All this is still pretty much ink on paper and the designs shown here are only examples of potential implementation of this powerful idea. Shards and potentially shards of shards (super-quadratic sharding) open the door for a massive increase in transaction rate in the future and is considered by many as the best currently under development solution for cracking scalability!

These three complementary solutions are still under development at the moment and lots of unknowns remain. Scalability is a hot topic and each potential solution becomes the object of debates and controversies. To my point of view, this shows that beyond the headlines and the roller-coaster of market caps there are amazing developers and strong communities focused on solving complex technical problems in order to bring this technology one step closer to its full disruptive potential.

Sources & other reads to go further

Casper FFG:

Plasma:

Sharding:

About us: IBBC is a community of crypto-enthusiasts looking for the next big thing. If you want to follow us and get access to more content, feel free to visit our space: https://medium.com/ibbc-io