Exploring the evolution and design reasons of Rollup expansion solutions

Original author: ORFEO

L2 project has once again become the focus of attention.

As a representative of the Rollup expansion route in L2, after Arbitrum’s airdrop, zkSync Era has come online. Behind the continuous new designs and roadmaps, what is the main line of Rollup and what is the evolution? Let’s sort it out today.

This article covers:

  • Scalability of L1 from the perspective of a third grader

  • Designing a Rollup solution from scratch

  • How to use zero-knowledge proof to further evolve Rollup

Starting with an analogy

Compared with Bitcoin and Ethereum, the biggest complaints from ordinary users since their inception are:

  • Slow: The lane is narrow, and once there are too many cars, it becomes congested and impassable.

  • Expensive: The toll during off-peak hours is not cheap. If you want to cross quickly during peak hours, you need to use “cash capacity” and pay the miners to take a helicopter to pick you up.

The two complaints are due to two factors in blockchain design:

  • Block capacity: Similar to lanes, the larger the block capacity, the more cars it can accommodate, and the less likely it is to be congested.

  • Incentive mechanism: Even with a wider lane, there is still a possibility of congestion. At this time, who should be allowed to pass first? It depends on who has an emergency and is willing to pay more, such as calling an ambulance, which costs several hundred dollars per trip.

If the blockchain can really be like a lane, then the fundamental solution is naturally to expand the lane, and use price measures to guide the departure time to ease the congestion, and those who are not in a hurry should not go out first.

However, expanding the lane and increasing the block capacity, although an attractive solution for traffic efficiency, is actually a case of treating symptoms instead of the root cause in blockchain design. This is because the larger the block capacity, the higher the hardware requirements for miners, and the fewer miners that can meet the requirements; following this line of thinking, if you want to process thousands of transactions per second like Visa, you will eventually create another centralized Visa, which is contrary to the core purpose of blockchain trust.

Are there other solutions? Yes, in addition to time optimization, we can also optimize in space, including but not limited to:

  • Opening different lanes, with large trucks on one, small cars on another, and buses on another, without interfering with each other – based on this idea, we can have different chains (main chains, side chains, or Plasma) with their own strengths.

  • Optimizing route design, appropriately diverting traffic, and avoiding congestion in the city center – based on this idea, we can have sharding.

  • Why do we have to go out? Remote meetings can achieve consensus, and sign agreements offline – based on this idea, we can have state channels.

  • Not everyone has to drive when going out, you can carpool or take public transportation – based on this idea, we have Rollup, the main protagonist of this article.

As a bus on the blockchain, Rollup’s key is actually saving space and gasoline (Gas, pun intended):

  • Saving space, so it is not easy to get congested, and the tolls per person are much less than driving alone;

  • Saving gasoline, so the ticket price is affordable, and everyone can afford it.

In this way, Rollup solves the two pain points of “slow” and “expensive”.

Now, let’s return to the blockchain and take a look at the specific plan for Rollup.

Design a Rollup plan from scratch

Rather than peeking at the standard answer (which doesn’t exist), let’s create some suspense. Imagine receiving the task of designing Rollup for Ethereum, what would you do?

Let’s start with reducing computational costs (saving gasoline) and reducing storage costs (saving space), and propose a more radical solution first, called Rollup 1.0.

Rollup 1.0

Rollup 1.0 includes three key points:

  • There is a service provider (Operator) that specializes in collecting everyone’s “carpooling” transactions (Transaction), and when the pool is full, or when the agreed time is up, the transactions are “dispatched”, taking into account both price and timeliness;

  • All the calculations involved in the transactions submitted by everyone are performed off the chain by this service provider, because off-chain calculations are faster than on-chain calculations, and calculations are often the largest cost in on-chain, which can save a lot of money;

  • After the calculation is completed, the updated state (such as everyone’s latest balance in their accounts) is stored on the chain, reducing storage costs by a lot.

Simply put, it is to collect everyone’s transaction requests regularly and quantitatively, calculate them off-chain, and only solidify the calculation results on-chain.

This solution perfectly solves the two major pain points of “slow” and “expensive”, but seems to have spawned new problems:

  • Motivation problem (Incentive): Who provides “carpooling” services and what are the benefits.

  • Censorship problem: What should I do if the service provider deliberately does not process my order (or hangs up, quits, etc.);

  • Fraud problem: If the service provider commits fraud, tampering with the calculation results, causing me to transfer money to others and the money being embezzled by him, what should I do.

For these three new problems, we can iterate a version of the solution.

Rollup 2.0

The motivation issue is best addressed by using money. Any problem that can be solved with money is not a problem. Service providers can share the cost of “carpooling” and charge a little “tip” on top of that, and it is still a win-win situation between the “carpoolers” and the service providers.

The censorship issue is a bit more tricky, but the solution is common in the blockchain field, which is decentralization. A group of people are all service providers, which is better than having only one service provider; anyone can be a service provider, which is better than a fixed group of people being service providers. In this play mode, if all service providers are not obedient, you can also be a service provider yourself, or go directly to L1 for arbitration.

The fraud issue is a bit more difficult. It can be split into two issues—one is how to identify fraud, and the other is how to prevent fraud.

First, to identify fraud , we need to know everyone’s transaction (Transaction) data and the state (State) before the transaction, so as to calculate the new state (State’) after the transaction, compare it with the new state stored by the service provider on the chain, and if they are the same, the service provider is honest; otherwise, he is lying. However, we do not know the transaction data because they are not on the chain. This means that we can only be suspicious and unable to judge whether the service provider is honest.

Next, to prevent fraud , the best way is to make fraud impossible, which is difficult unless the chain checks the service provider’s calculation every time, but then there is no “carpooling” advantage. So we can only step back and make the cost of fraud very high, making service providers hesitate (have skin in the game), such as depositing a stake, and confiscating it if fraud is found. (This method is called social consensus and belongs to game-based security, which was also mentioned in “Weekly Report #3”.)

Rollup 3.0

Rollup 2.0 worked well, but the fraud detection issue was not resolved.

As previously hypothesized, in order to detect fraud, we must have access to transaction data. Therefore, this data must be put on the chain just like the state data.

So who will discover fraud? Obviously, this cannot be done by ordinary users because it is impossible for everyone to monitor service providers 24/7. Therefore, it can only be done by professional “bounty hunters” (validators). If a “bounty hunter” reports fraud within 7 days after the service provider “dispatches” a task and the report is verified to be true, the transaction will be rolled back and the service provider will be punished. Of course, “bounty hunters” also need to be incentivized. For example, after discovering fraud, part of the service provider’s deposit will be given to the “bounty hunter” (only part, to avoid collusion between the service provider and the bounty hunter).

Rollup 4.0

By the Rollup 3.0 stage, the entire solution is up and running, but new costs have been introduced. So far, costs include:

  • Costs (including costs and “tips”) to service providers;

  • Cost of on-chain storage of transaction and state data;

  • Calculation cost of verifying the “bounty hunter” when they believe that a service provider is committing fraud.

Next, let’s take a look at which costs can be optimized.

Transaction Data

Through specific methods, multiple transactions can be aggregated together, occupying less space than the total space occupied by each transaction.

Using the simplest ETH transfer transaction as an example, let’s break down the content of each transaction. We can see that the signature occupies the largest space proportion. We can combine the signatures of all transactions (Key Aggregation), which saves a significant amount of storage costs (similar to Schnorr in Bitcoin). In addition, we can also optimize other parts, such as discarding the Nonce, and when “carpooling”, choosing “fat and thin” and “seamless” “carpoolers” as much as possible to maximize the use of “car space”.

Source: https://vitalik.ca/general/2021/01/05/rollup.html

With just a few tweaks, the size of each ETH transfer transaction can be reduced from 112 bytes to 12 bytes, nearly one-tenth of the original size. Of course, there are other methods that can be used to further compress transaction data.

In practice, we can deploy a contract on the chain and insert a method:

function storeTxData(bytes calldata data) external { // Do nothing }

After each successful “carpooling” operation, the merged and compressed transaction data is passed to this method as calldata. Calldata does not need to be saved permanently, and after the public challenge period of social consensus, it can be pruned without any consequences. Calldata is very cheap, and with the implementation of EIPs such as Danksharding and Data Blob, it will become even cheaper. This form of using L1 for data storage and distribution (Data Availability) will become more formal.

State data

Since the transaction data has been uploaded to the chain, anyone can calculate the updated state based on the transaction data. Therefore, state data is not as necessary. We can only keep the Merkel Root of the state data, so that ordinary users (“carpoolers”) can directly apply for withdrawal from L1 when the service provider does not cooperate, and prove their account balance with Merkel Proof.

Fraud arbitration cost

When a bounty hunter reports that a service provider is fraudulent, the on-chain contract calculates (replays) once and compares the resulting state. This is theoretically feasible. However, first, the cost is not low (although it is already good), and second, the total gas of the transactions in the Rollup “carpooling order” may exceed the gas limit of Ethereum, making it impossible to verify.

Therefore, arbitration needs to be reduced, and the way to reduce it is to perform unnecessary computing operations off-chain. One solution is called Interactive Proving, which roughly follows these steps:

  • The bounty hunter pays a deposit, reports and splits the entire calculation process into n segments in order, and indicates that the service provider is fraudulent in the k-th segment (1 ≤ k ≤ n);

  • The service provider breaks down the k-th segment and points out where the bounty hunter’s calculation is wrong;

  • Repeat this process until the calculation operation can no longer be broken down, such as when the bounty hunter thinks 1 + 1 = 2, and the service provider thinks 1 + 1 = 3;

  • At this point, the on-chain contract intervenes, calculates 1 + 1, obtains 2, and determines that the service provider is fraudulent, confiscating its deposit and rewarding part of it to the bounty hunter.

(Throughout the process, if one party fails to reply within a certain time, that party loses.)

This way, the entire arbitration cost on the chain is very, very low.

So far, we have constructed a complete Rollup solution. Because this solution assumes that the service provider is honest unless there is a “bounty hunter” report, this faction is called optimistic Rollup.

So, is our Rollup 4.0 the best solution?

Rollup evolution

After multiple rounds of iteration, Rollup 4.0 still has some imperfections:

  • Fraud needs “bounty hunters” to discover, but if there is no fraud for a long time, the “bounty hunters” may go out of business because there is no profit, so there is a gap (although it is unlikely, because the application merchants and other related interest parties of the Rollup chain are most likely to act as “bounty hunters”);

  • To be sure there is no fraud, based on social consensus, you need to wait several days, which affects withdrawal and other operations;

  • There is quite a lot of data on the chain, so there is still a cost;

  • Currently relying on a layer of Rollup to expand, the throughput may only be increased by 10 times, is it possible to be higher?

Is there a solution that can make fraud impossible, make finality faster, make less data that needs to be on the chain, and make scaling up by another order of magnitude? The desired results are simply too much, but there is indeed a class of solutions that can almost meet all imaginable needs—Zero Knowledge Rollup (referred to as ZK-Rollup).

ZK-Rollup is a Rollup approach that uses zero-knowledge proof (ZKP). The so-called ZKP refers to the technology that makes the other party believe that you know this information without revealing any sensitive information. There are two favorite analogies for explaining ZKP:

  • Imagine in a medieval European town, I have a treasure map that marks a treasure. In order to prove to you that I have a treasure map but not let you know the exact location of the treasure, I blindfold you, drag you onto a carriage, and drive around the town for half an hour to ensure that you lose your sense of direction. Finally, we arrive at the destination, let you take a look at the treasure, and then take you back along the winding road. This is a naive form of ZKP.

  • Another analogy is more common. Assuming that there is a Sudoku puzzle, I know the answer and you don’t, but you don’t believe that I know it; I want to prove to you that I know it, but I don’t want you to know the answer. What to do? I can put the Sudoku on the table, put the public numbers face up, and the numbers that need to be filled face down, and let you choose whether to check my answer by row or by column. If you choose by row, I will put the numbers of each row together, scramble them, and show you that each row is from 1 to 9. Repeat a few times, no problem, so you can believe that I most likely know the answer. This is one of the interactive proof methods of ZKP (because it is difficult for the blockchain to achieve real-time on-chain interaction, non-interactive proof is generally used, relying on hash functions to generate random challenges).

In simple terms, the core idea of ZKP is that the Prover first hides the secret knowledge, “buys and sells” (Commits), and then the Verifier initiates a random challenge. If the Prover can successfully pass the challenge, then it is highly likely that they have the corresponding secret knowledge.

ZKP has 3 requirements:

  • If the Prover lies, then it is highly unlikely that they can pass the challenge (Soundness);

  • If the Prover has knowledge, then they can pass the challenge (Completeness);

  • During the interaction between the two parties, the Prover will not disclose any useful information (Zero-knowledgeness).

To meet these 3 requirements, ZKP uses a variety of NP-hard problems, including the simplest prime factorization and discrete logarithm (such as Schnorr).

ZKP is not a technology born for blockchain, but it can be used for L2 expansion, mainly because a good ZKP has the following useful features:

  • The Prover (service provider) can quickly provide a proof, thereby ensuring high off-chain computing efficiency and not becoming a bottleneck;

  • The size of the proof is small, or at least proportional to the amount of computation to be proved, and is as little affected by the amount of data as possible, thereby reducing on-chain storage costs;

  • The Verifier (L1 contract) can quickly verify whether the proof is valid, thereby reducing on-chain computing costs.

Using these features, our Rollup solution can:

  • No longer need “bounty hunters”, L1 contracts can discover fraud on the spot;

  • As long as the ZKP verification is valid, withdrawals can be made immediately, and the finality is reduced from the sky level to the minute level;

  • Only the state difference is uploaded on chain, the space is small, and the storage cost is low (an additional bonus – privacy is also improved);

  • By customizing software and hardware optimizations for the proof and verification process, the scalability can be further improved.

Of course, any security mechanism will have potential prerequisites, and ZKP is not a panacea for blockchain. ZKP still has many limitations that need to be gradually overcome, such as:

  • Speaking of zk-SNARK, the most common application on the blockchain, many schemes require the introduction of as many prestigious people or companies as possible at the beginning to do a Trusted Setup to generate a truly random number and ensure that the generation process is verifiable but not fully public (such as in the Power of Tau ceremony, where only one trusted party is required, but it is still considered a flaw). Of course, some new zk-SNARK schemes, as well as later improved zk-STARKs, can solve this problem, but sometimes new problems are introduced.

  • Many problems are difficult to summarize as ZKP problems, which also means that programmability has not been well solved for a long time. It is difficult to achieve ZKP that is fully compatible with EVM on Ethereum, or even if it can be achieved, it will be affected in other aspects (such as verification efficiency).

Source: https://medium.com/minaprotocol/meet-pickles-snark-enabling-smart-contract-on-coda-protocol-7 ede 3 b 54 c 250

This is also why, in the ZK-Rollup, which is a future-oriented expansion field, every progress is valuable and worthy of celebration.

Source: https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-e d5 e 48842 fbf


As far as the future of expansion is concerned, I think that the layered design, including Rollup, is a more reliable idea compared to the native expansion of L1. Modularization, each layer solves the concerns of each layer, and the risk is smaller than constantly stacking on the already “iron plate” (monolithic) L1; and, theoretically, the decentralization lost by the underlying L1 due to expansion is unlikely to be compensated in the upper layer. Moreover, the idea of ​​layered design has seemingly successful applications in areas outside of the blockchain. The point of view may not be correct, but this is my current understanding.

In this article, an attempt is made to comb through the thinking process and design reasons for the Rollup expansion plan in a project-agnostic tone. Due to limited level, some places are still somewhat rigid, and may not only fail to explain well, but also increase understanding difficulties; as a rapidly changing vertical field, many new developments may not be known and considered in time. Sincerely welcome friends to correct and exchange.

Like what you're reading? Subscribe to our top stories.

We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!

Follow us on Twitter, Facebook, YouTube, and TikTok.


Was this article helpful?

93 out of 132 found this helpful

Gambling Chain Logo
Digital Asset Investment
Real world, Metaverse and Network.
Build Daos that bring Decentralized finance to more and more persons Who love Web3.
Website and other Media Daos

Products used

GC Wallet

Send targeted currencies to the right people at the right time.