Introduction: Different types and similarities of Rollup for blockchain expansion

Author: Ed Felten

Translation & Proofreading: Min Min & A Jian

Source: Ethereum enthusiasts Editor's Note: Original title was "View | 170,000 Ethereum and 400,000 ENS Domain Names"

Rollup is one of the hottest ideas in terms of smart contract scalability in recent years. This idea has been proposed for some time, but only recently have several teams, including our Offchain Labs team, started to promote it vigorously. Let's take a few minutes to talk about what is rollup and what is the correlation between different solutions.

• Bitcoin-related products become popular among millennials, surpassing Disney and Microsoft stocks
• Japan's largest bank MUFG launches digital currency payment business, using MUFG Coin as a trading unit
• Ethereum 2.0 is really coming, stage 0 is expected to launch the mainnet in early 2020

Rollup is a universal method for scaling up open contracts (that is, contracts that everyone can see and interact with). On Rollup, the call to the contract and its arguments (actual parameters) are written on the chain as calldata, but the actual calculation and storage of the contract are done off-chain. Someone will post an assertion on the chain, asserting a series of operations that the contract will perform (such as a payment to be completed) and a hash value of the contract status after execution is completed. It can be said that this release of the on-chain assertion “rolls up” all calls and results into a single transaction that sends on-chain.

The difference between different Rollup systems is the way to ensure correct assertion. There are three basic methods: non-interactive rollup (eg, ZK-Rollup), one round of interactive rollup (eg, "optimistic rollup" proposal), and multi-round interactive rollup (eg, our team's Arbitrum Rollup).

Non-interactive Rollup (eg ZK-Rollup)

Non-interactive rollups rely on concise proof of validity. Each assertion is accompanied by an easily verifiable certificate (eg, SNARK) to show that the calculations and results in the assertion are correct. For example, the ZK-Rollup system uses ZK-SNARKs, a zero-knowledge proof system that is easy to verify. This is friendly to miners and other observers, as the cost of verifying the proof is low and the accuracy of the assertion can be verified immediately. However, the zero-knowledge proof system also has a big disadvantage: Unless the transaction to be asserted is very simple, the cost of creating proofs is prohibitively high. Therefore, ZK-Rollup is very suitable for payment transactions, but for the execution of more complex smart contracts, the effect is not so good.

Rollup for smart contracts

For complex smart contracts, we must adopt an interactive approach. That is, if an assertion is to be published on the chain, the asserter (assertor) must pay a deposit and open a time window. If the verifier believes that the assertion is incorrect, it can challenge it within the window period. This is sometimes called "proof of error". If the asserter posts the wrong assertion, it will lose its own deposit.

A round of interactive rollups is also called "optimistic rollup", but it is a bit of a misnomer to say that because all interactive rollups are optimistic designs. In a round of interactive rollups, assertion contains the results of each call, and the challenger will indicate which call in the assertion gave the wrong result. The on-chain contract simulates the execution of the challenged call and verifies that the asserter's statement about the call is incorrect. If it is really wrong, cancel the entire assertion and fine the asserter's deposit. If an assertion is not successfully challenged by the end of the challenge period, it will be accepted and finalized.

In multi-round interactive rollups (for example, our team's Arbitrum Rollup product), there is also a challenge window period during which challengers can pay a deposit and declare that the assertion is wrong. Next, a back-and-forth interactive protocol between the asserter and the challenger will be triggered, and an on-chain contract will serve as the referee of the agreement. In the end, the arbitrator decides which party is wrong and fines its security deposit. This design is to minimize the amount of on-chain work required to resolve disputes. That is, before the arbitrators on the chain actually evaluate the contract's behavior, the scope of the dispute between the two parties is minimized through interactive agreements.

One Round Interactive Rollup vs. Multi Round Interactive Rollup

Ultimately, the choice between a round of interactive rollups (for example, "optimistic rollup") and a multi-round interactive rollup (for example, Arbitrum Rollup) is a trade-off between on-chain costs and time required to resolve a dispute. A round of interactive Rollup needs to simulate a complete call on the chain, and the cost may be very high-therefore, the call performed by the contract will be limited by the global gas limit of Ethereum. Multi-round interactive Rollup is not subject to this restriction, it will further narrow the scope of the dispute until it can be resolved on the chain at a lower cost. In general, multi-round interactive Rollup can also write less data on the chain.

Writing to the chain

One round of interactive Rollup and multi-round interactive Rollup need to write all the calls to the contract and their data to the chain, these are the call data. However, the difference between the two is that the data that needs to be put on the chain as an assertion is different. Generally speaking, assertion involves multiple calls to a contract. A round of interactive Rollup needs to add the hash value of each step to the assertion. This is so that each call can be challenged individually. In contrast, multi-round interactive Rollup only needs to add the hash value of the entire contract state at the end of the assertion. (Intermediate state hash values ​​will be generated on demand, but only in very rare cases of controversy.) In this way, the multi-round interactive Rollup's on-chain data cost will be slightly lower.

Challenge period and finality in a round of interactive Rollups

In any type of interactive Rollup, the system must be able to withstand censorship attacks. It is worrying that an attacker may submit a wrong statement and then launch a review attack to prevent all challenges against this statement from being posted on the chain until the end of the challenge period and the wrong statement is accepted. The solution to this is to ensure that the challenge period is longer than the duration of the review attack. (Defense measures can also be used, such as a higher fine for the party that issued the misstatement and encourage potential challengers to use censorship and other systematic methods to defend against censorship attacks.)

Given the above assumptions about censorship attacks (which I will explain in a future article), the challenge period can take a long time. For example, some systems set the challenge period to one week. That is, after the transaction is submitted, it takes a full week to get the Rollup agreement determined-until then, the payment completed through the transaction will not be considered to have happened on the chain.

Will this cause big problems? May be less than you think. To understand why, let's assume that a valid assertion has been posted on the chain and is awaiting confirmation. You or anyone else can verify the correctness of this assertion. And you know that the Rollup protocol finally confirms a valid assertion. Therefore, even though the Rollup protocol has not confirmed an assertion, everyone who follows it knows that the assertion will be confirmed and can be regarded as "confirmed". They all know it will be confirmed sooner or later, so they can move on.

For example, if you are going to receive a payment through this type of transaction, and everyone can be sure that the payment will definitely happen, you can sign the payment and transfer it to someone else, and the transferee can Make sure you will definitely receive this payment in the future. This is almost the same as cash. The only difference is that because it is delayed recognition, its value will be equal to the face value minus a small amount of interest.

The point is that a valid transaction can get "trustlessly final" even before it is confirmed. That is, anyone can be sure that the transaction will be confirmed.

Challenge period and finality in multi-round interactive Rollup

The same is true in multi-round interactive Rollups: the protocol is designed to make effective assertions trust-free certainty, so anyone can be sure that this assertion will be confirmed. The difference is that in order to ensure that the transaction is confirmed, you must be prepared to participate in the agreement to protect the assertion-as long as you are willing to do so, you alone can get a valid assertion to be finally confirmed.

(A side note specific to our Arbitrum Rollup product: Although earlier versions of Arbitrum technology did not provide this trust-free certainty, the latest version is available. In older versions of the protocol, each of the The challenged assertion will be cancelled to prevent the parties involved in the challenge from colluding to bring the wrong challenge result on the chain. In the new version of the protocol, all honest parties can force the correct result to pass the challenge period, so it is valid. The assertion will definitely pass the challenge and be confirmed.)

(It is also necessary to correct a misunderstanding here, as long as there is a dispute, the multi-round interactive Rollup protocol must "suspend the entire network", that is, if a malicious participant is willing to lose the deposit, the network process can always be blocked. This is not the case in the latest version of the agreement. The parties can continue to publish new assertions, regardless of whether the dispute continues, the new assertions can obtain trust-free certainty. It is only that the formal confirmation of the agreement has been slowed down-this requires the attacker Great price.)

How long does it take to confirm an assertion in a multi-round interactive Rollup protocol? Under normal circumstances, if a valid assertion is not challenged after it is released, it will only experience a challenge period before confirmation, like a round of interactive rollups.

If special circumstances arise, that is, the assertion is valid but still challenged, the final confirmation will be postponed under the influence of multiple rounds of dispute agreements. The challenger is destined to lose and lose the margin, but will push back the time of final confirmation. This will not affect the confidence-free certainty of assertion, because everyone can judge that the assertion is valid from the beginning, and can also confirm the valid assertion when necessary. The entire network will continue to operate as securely as usual, and everyone knows that this malicious challenge will eventually lose.

Which Rollup is Right for You?

So, what kind of Rollup system should you use? If it is only used for payment or a simple smart contract, a non-interactive system like ZK-Rollup is more suitable.

If you want to run more complex smart contracts, you need to choose from one round of interactive (for example, "optimistic rollup") and multi-round interactive (for example, Arbitrum Rollup) rollup systems. Under normal circumstances, both systems need to wait a long time for final confirmation of assertion, and will provide instant trust-free certainty for effective assertion. The advantage of a round of Rollup system is that it can resist the "delay confirmation" attack, and the perpetrator cannot postpone the final confirmation of the assertion by giving up the margin (in any case, assertion has trust-free certainty). The advantages of the multi-round Rollup system are (1) the space occupied by the chain is usually small, and (2) it can process contracts with a large amount of calculation and storage, and is not limited by the Ethereum gas limit.

Our Offchain Labs team believes that most people will like multi-roller Rollup systems with lower cost and wider applicability, such as Arbitrum Rollup, and the disadvantages of multi-roller Rollup systems can also be made up by increasing the margin required for the challenge. This defense delays confirmation attacks.

We also think that a multi-roll Rollup system is easy to implement correctly. That's why we hope to provide a functional version of Arbitrum Rollup on the testnet in the coming months (and even earlier).

(Finish)

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