What’s up with Rollup
Rollup is one of the hot ideas in smart contract scalability these days. The idea has been around for some time, but several groups, including ours at Offchain Labs, have been promoting it lately. Let’s take a few minutes to talk about what rollup is and how the different proposals relate.
Rollup is a general approach to scaling open contracts, that is, contracts that everyone can see and interact with. In rollup, calls to the contract and their arguments are written on-chain as calldata, but the actual computation and storage of the contract are done off-chain. Somebody posts on-chain an assertion about what the contract will do — a list of actions taken by the contract, such as payments made, and a cryptographic hash of its state after the contract has executed the calls that have already been posted on-chain. We can think of the assertion as “rolling up” all of the calls and their results into a single on-chain transaction.
Where rollup systems differ is in how they ensure that the assertions are correct. There are three basic approaches: noninteractive rollup (like ZK-Rollup), one-round interactive rollup (like the “optimistic rollup” proposal), and multi-round interactive rollup (like our Arbitrum Rollup).
Noninteractive rollup (e.g., ZK-Rollup)
Noninteractive rollup relies on succinct validity proofs. Every assertion is accompanied by an efficiently checkable proof (like a SNARK) which proves that the computations and results described in the assertion are correct. As an example, the ZK-Rollup system uses ZK-SNARKs, an efficiently checkable proof system that happens to be zero-knowledge. This is great for the miners and other observers, because the proofs are cheap to check and they establish correctness of the assertion immediately. But there is a big downside: creating the proofs is incredibly expensive, unless the transactions being asserted are very simple. So ZK-Rollup is a great approach for payment transactions, but it won’t be workable any time soon for nontrivial smart contract execution.
Rollup for Smart Contracts
To handle complex smart contracts, we’ll have to go with one of the interactive approaches. The idea here is that when the assertion is posted on-chain, the asserter posts a bond, and there is a time window in which validators can challenge the assertion, if they think it’s wrong. This is sometimes called a “fraud proof”. If the asserter is wrong, they will lose their bond.
In one-round interactive rollup — sometimes called “optimistic rollup” although that’s a slight misnomer because all interactive rollups are optimistic — the assertion includes a result for each call, and the challenger points to a specific call which it claims has the wrong result in the assertion. An on-chain contract emulates that one challenged call and checks whether the asserter’s claim about that call was wrong. If it was wrong, the whole assertion is canceled and the asserter forfeits their bond. If the challenge period expires with no successful challenges, the assertion is accepted and becomes final.
In multi-round interactive rollup, like our Arbitrum Rollup product, there is also a challenge window during which a challenger can post a bond and claim that the assertion was wrong. What follows is a back-and-forth interactive protocol between the asserter and the challenger, with an on-chain contract acting as a referee for the protocol. In the end the referee determines that one party made a false claim, and punishes that party by taking their bond. The idea is to minimize the amount of on-chain work to resolve the dispute by using an interactive protocol between the two disputants to narrow down the dispute as far as possible before the on-chain referee has to evaluate evidence about the contract’s behavior “on the merits”.
One-round vs. Multi-round Interactive Rollup
The choice between one-round (e.g., “optimistic rollup”) and multi-round (e.g., Arbitrum Rollup) boils down to a tradeoff between on-chain cost and time to resolve a dispute. A one-round approach requires emulating a full call on-chain, which can be expensive — and this limits contracts to calls that can be executed comfortably within Ethereum’s global gas limit. Multi-round eliminates this need by further narrowing the dispute until it is small enough to resolve cheaply on-chain — but at the cost of adding rounds to the dispute resolution protocol. Multi-round also writes a bit less data to chain in the common case.
What gets written to chain
Both one-round and multi-round interactive rollup need to write all of the calls to the contract and their data to chain, as calldata. They differ, though, in what they need to put on-chain as part of the assertion. Typically an assertion will cover multiple calls to contracts. One-round needs to include in the assertion the hash of the contract state after each call, so that each call can be challenged individually. Multi-round, by contrast, only needs to publish a single hash, of the contract’s state at the very end of the assertion. (Intermediate state hashes will be produced on-demand, but only in the unlikely case of a dispute.) This makes multi-round a bit cheaper in on-chain data cost.
Time and finality in one-round interactive rollup
In any kind of interactive rollup, the system must be resilient against censorship attacks. The worry is that an attacker might submit a false claim, then use a censorship attack to prevent all challenges to that claim from getting posted on chain, until the challenge period expires and the false claim is accepted. The solution to this is to make sure the challenge period is longer than the period over which a censorship attack can plausibly be sustained. (Other defenses can help, such as increasing the penalty for getting caught in a false claim, and encouraging would-be challengers to use replication and other systems approaches to defeat censorship.)
Depending on your assumptions about censorship attacks (which I’ll address in a future post), the challenge period might need to be quite long. For example, some systems postulate a one-week challenge period. That would mean that the rollup protocol would not confirm transactions until an entire week after they are submitted — only then would payments made by the transactions be treated as having happened on-chain.
How big of a problem is this? Maybe less than you would think. To see why, consider a valid assertion that has been put on-chain and is awaiting confirmation. You, or anybody, can check the assertion and see that it is valid. And you know that the protocol will always eventually confirm valid assertions. So even though the protocol hasn’t yet confirmed the assertion, everybody who is paying attention knows that the assertion will be confirmed, so they can treat it as “as good as confirmed”. They know it will be happening, and they can proceed accordingly.
As an example, if you are going to receive a payment from such a transaction, and everyone can tell that that payment is certain to occur, you can sign over that payment to somebody else, and they can be certain that it will be paid to them in the near future. It’s as good as real money, minus a small interest payment to compensate for the delay in confirmation.
The key point is that if even before it is confirmed, a valid transaction can become “trustlessly final” in the sense that anyone can be sure that its confirmation is inevitable.
Time and finality in multi-round interactive rollup
In multi-round rollup, the same thing can be true: the protocol can be designed so that a valid assertion becomes “trustlessly final” so that anyone can be sure that its confirmation is inevitable. The one difference is that in order to assure yourself of confirmation, you have to be prepared to participate in the protocol to defend the assertion — but as long as you are willing to do that, you, acting alone, can force the eventual confirmation of a valid assertion.
(As an aside about our Arbitrum Rollup product: although early versions of our Arbitrum technology did not provide this trustless finality guarantee, our newest version does. In our old protocol, every challenged assertion would be canceled just to be safe, in case the parties participating in the challenge were colluding to get the wrong challenge result. In the new protocol, any honest party can intervene to force a correct result from the challenge process, so a valid assertion can always survive challenges and be confirmed.)
(Also, there is a misconception out there that a multi-round protocol has to “stop the world” when there is a dispute, allowing a single malicious party to stop progress if it’s willing to lose deposits repeatedly. That’s not the case in our newest protocol. Parties can continue to assert the truth, and new assertions can gain trustless finality, whether or not disputes are going on. The only thing that gets slowed down — at substantial cost to the attacker — is official confirmation.)
How long does it take to confirm an assertion in multi-round rollup? In the common case, where a valid assertion is made and nobody challenges it, a single challenge period elapses before confirmation, just the same as in one-round rollup.
In the unusual case where the assertion is valid, yet somebody challenges it anyway, final confirmation is delayed for longer while the multi-round dispute protocol runs. The challenger is doomed to lose the challenge and forfeit their bond, but they do get to delay confirmation for a while. There is no effect on trustless finality, because everyone can tell from the beginning that the assertion is valid, and anybody can intervene if necessary to force confirmation of the valid assertion. The rest of the world will go on as normal, safe in the knowledge that the bogus challenge will fail.
Which rollup is best for you?
So which rollup method should you use? If you only want payment transactions, or at most very simple contracts, a noninteractive method like ZK-Rollup probably makes sense.
If you want to run nontrivial smart contracts, you’ll need an interactive rollup approach, so the choice is between one-round (like “optimistic rollup”) and multi-round (like Arbitrum Rollup). Both systems have the same extended period for final confirmation of assertions in the common case, and both offer trustless finality promptly for valid assertions. The advantage of one-round rollup is that it doesn’t allow “confirmation slowing” attacks where parties sacrifice a bond in order to delay final confirmation of assertions (despite trustless finality in all cases). The advantages of multi-round rollup are that (1) it has a smaller on-chain footprint in the common case, and (2) it can handle contracts with computation and storage that would exceed the Ethereum gas limit.
We at Offchain Labs think most people will prefer the lower on-chain cost and wider applicability of multi-round approaches like Arbitrum Rollup, especially because the disadvantage of multi-round can be mitigated by increasing the bond required for challenges, to deter confirmation delay attacks.
We also believe that multi-round approaches are easily to implement correctly. That’s why we expect to have a functional version of Arbitrum Rollup on testnet within the next few months, if not sooner.
