Different ways to scale Ethereum main chain

Introduction

State channel, Plasma and Rollups are a way to scale up transactions on Ethereum blockcain. In this article we will build our understanding from ground up.

Problem

Currently Ethereum blockchain suffers from two big problems:

Scalability
Gas price

People are trying to come up with ways to solve these issues in differnt ways:

Solution

Convert to Proof of Stake

This approach requires changing the way the node validators come to concensus regarding the data on the blockchain.

The benefit of this solution is that while in proof of work algorithm, the concensus mechanism automatically tunes its difficulty level so that mining a block necessarily takes a fixed amount of time, proof of stake does not have that artificial time restiction. As long the validators have sufficiant amount of token staked in the network to go rouge, the mining process can be as quick as possible.

Increase the block size

This solution suggests increasing the block size so that more transaction data can be added to each block. This way number of transactions per block would increase and thereby increasing the throughput.

However, if the data in the block increases then it would be more difficult to validate all the transactions in the block. The increased computation power required to validate all the transactions in the block will mean only few validations will be capable of perfoming this. This would result in a more centralized network.

Change the way blockchain is used

Instead of putting all the transaction data in the blockchain, put them off chain in a "layer 2 protocol", and at regular intervals provide proof of the transactions to the main chain. For this, deploy a smart contract on the main chian. This smart contract has two functions:

Process the deposit and withdrawal of funds
Validate the proofs submitted by Layer 2 (validating proof should be cheaper than generating the proof)

State Channel

To increase the throughput of main chain the concept of state channel was developed. State channels help two parties who want to get into a long duration of rapid transactions. Say, a zero-sum-game between Alice and Bob where the outcome of each round needs to be saved to Blockchain. In this example, both Alice and Bob deposit some money (say $5 each, the pot now has $10) to the on-chain smart contract and then begin playing. At the end of each round, the outcome is signed by both parties and saved. The outcome message might contain the following information:

The round number
The winner
Total amount won by Alice till now
Total amount won by Bob till now
Signature of Alice
Signature of Bob

Whenever a party wants to exit the game, they submit the latest signed message to the on-chain smartcontract. The smartcontract verifies the signature and transfers the relavant amounts to each players account.

Say, at the end of round 10 Alice has won 6 times and Bob has won 4 times, while winning amount for each round was $0.5. So Alice should now get:

$5 (her original money) + 6 (number of rounds won) * $0.5 (prize money per round)
= $8

Correspondingly Bob should get the remaining $2 from the pot.

The final message submitted by Alice to the smartcontract might look something like this:

The round number: 10
The winner: Alice
Total amount won by Alice till now: $8
Total amount won by Bob till now: $2
Signature of Alice
Signature of Bob

Once the smart contract has verified the signature it is ready to release the funds to both players. An important feature of State Channel now comes into play. The smart contract now goes into a time lock for a pre determined time. During this time, smart contract waits for Bob to submit a counter message.

Why: The smart contract doesn't know that there were only 10 rounds played between Alice and Bob. What if there were actually 15 rounds played between them and in the last 5 rounds, Bob managed to get all his money back and then some. The time lock is provided for Bob to submit another message which might look something like this:

The round number: 15
The winner: Bob
Total amount won by Alice till now: $1
Total amount won by Bob till now: $9
Signature of Alice
Signature of Bob

Basically, the smart contract waits for Bob to produce another message (signed by both players) where the round number is higher than what Alice had submitted.

In this approach there are only 2 main chain transactions but the number of payments made between Alice and Bob is arbitrary. Also, the throughput depends on how fast the signed messages can be sent between them.

While this approach works great for payments between two parties, issues arise when one of the participants in the payment channel wants to send some funds to a third party not involved in the payment channel.

Another restrictions on channel is that there needs to be clear logical ownership rules for the assets under transaction. In case of payments it is clear who the token belongs to at each point during the transaction. However, for cases like uniswap, payment channel cannot be used since we don't have clear ownership of assets inn that case.

To do anything more complex than simple paymenet transfers, the participants require large captial.

Once the withdrawal is triggered there is a lock period during which all parties need to submit their signed message in order to figure out what is the final balance. This lock period slows down the overall throuput of the system.

Plasma

Plasma is similar to Payment channel in that the transactions are done off chain, however, unlike in payment channel where the records of each round is signed and sent across as messages, in Plasma the information of each round is submitted to a sub chain (Plasma chain).

Say Alice and Bob have accounts on main chain and want to get into a series of transactions, doing so on Plasma would be cost effective for them. For doing so, they lock their asset inn a Plasma smart contract and get equivalant amount of tokens in the Plasma chain.

In the Plasma chain they can now go for any number of transactions and enjoy lower gas fees and higher throughput. When they are done with all the transactions they can request for the tokens to be submitted to the Plasma chain and equivalent amount be depositted to their account on main chain.

This solves some of the problems that Channels have. Now any number of parties can be included in the transaction at any point. There doesn't need to be a clear logical owner for an asset.

However, Plasma still couldn't solve the issue of lock period. If Alice wants to withdraw from the Plasma chain, she still needs to waits for a lock period.

Rollup

Rollup is built on the ideas of Plasma and solves the lock period issue. It consists of the Main chain where a Rollup contract is deployed. This smart contract contains a state variable which stores the value of the merkel root hash of the latest batch.

A batch primarily contains 3 things

Previous batch hash
Current batch hash
Transaction proof

Since anyone from the rollup chain can submit the batch, to verify if the batch is correct, both Optimistic Rollup and ZK Rollup solve this problem in a slighly different way.

Optimistic Rollup: This strategy uses Fraud Proof. In this strategy, each batch contains the compressed transactions done in the Rollup chain that make up the batch. Since the transactions are present in batch, anyone can verify if the rollup is correct. The verification can be done post facto as well. If, however, an error is detected later on then all the batches submitted on the main chain post the erroneous batch are discarded.
ZK Rollup: This strategy uses Validity proof. Every batch contains a ZK Proof of the transactions included in the batch. The proof generation in itself can be quite intensive, but the proof verification is very quick. So the verification is done as soon as the batch is submitted to the main chain.

There are however some ways to select who can submit batches on the rollup chain.

Anyone: This is the simplest approach. Anyone can submit the batch, however only one batch is selected per round. While this is easy to implement, it leads to a lot of wasted efforts in generating Transaction Proof.
Centralized Sequencer: In this approach, there is a single entity which generates the batch. This tends to be the most efficient solution, however, the most frowned upon by the Blockchain community (the reason is in the name).
Sequencer Auction: In this approach a new Sequencer is selected every few rounds (could be every our or every day). The selection process requires the participants bidding for the chance to perform the sequencing. The highest bidder gets to submit batches for next few rounds. The funds collected in this auction process can be redistributed in the network (DAO controlled by rollup)
Random Selection from PoS set: All those nodes interested in submitting the batch can stake some token. One sequencer is selected at random from the set of those. The probability of winning a chance to submit batch depends on the amount staked. The downside of this approach is a lot of funds is locked away and is unused. DPoS voting: In this approach a single sequencer is selected based on auction. However if they perform poorly, then they are voted out by the others.

Summary

There is a lot of interest in solving the Scalability and Gas price problem in Ethereum. People have come up with various approaches over time. Each solution tries to solve some unsolved problem from the previous solution and so the solutions has also kept evolving. We started with State Channel, evolved to Plasma and now we are at Rollup, where we have two different flavors, Optimistic Rollup and ZK Rollup.

Each concept in itself is slightly more complicated and more interesting from the previous one. It is an interesting area to keep an eye on since the final solution to the scalability might still be out there.

hypersign-protocol / whitepaper

Research on Zkrollups #8