Eleven questions to ask your rollup provider
You’re an Ethereum developer, and you’re rollup-curious. You’re tempted by the scalability and low cost of rollup solutions, but you’re not sure how to evaluate the various proposals out there. You wonder how much of the rollup talk is just hot air.
Here’s a list of eleven questions you can ask about any rollup system. They’ll help you understand the pros and cons of each, and they’ll help you spot any gotchas.
For each question, I’ll talk about why it matters and how systems might differ. Then I’ll answer the question for Arbitrum Rollup, the system just released by our team at Offchain Labs.
- Does it support general smart contracts?
Some rollup systems are specialized to specific types of transactions, such as payments. Some others might support general contracts “in principle” but require you in practice to hand-write contracts to use their unfamiliar abstractions, or if you already have a contract, to rewrite it. There’s nothing wrong with specialization, if you want only what the specialized system is offering. But it’s important to be clear about what a system lets you do.
Arbitrum Rollup supports general smart contracts. The Arbitrum compiler takes contracts written in Solidity and compiles them to run on an Arbitrum Rollup chain.
2. Can you move Eth and tokens in and out easily?
Many applications want to handle and transfer real value. Supporting that requires the ability to move Eth and tokens into a rollup chain, transfer them within the chain, and then withdraw them on demand.
Arbitrum Rollup provides a token bridge capability to every rollup chain, automatically. The token bridge supports deposits of Eth, ERC-20 fungible tokens, and ERC-721 non-fungible tokens into a chain. Arbitrum Rollup supports ownership and transfer of these tokens with a rollup chain, and on-demand withdrawal through the token bridge. The withdrawal capability is censorship-resistant, like the rest of Arbitrum Rollup.
3. How much does it move off-chain?
The whole point of rollup is to take computation and storage that would normally be done on-chain, and move them off-chain. All rollup systems put clients’ call data on-chain — that’s what makes rollup rollup — but systems differ in how much other data and computation have to happen on-chain.
Some systems require posting more information on-chain for each transaction call. Some require the on-chain rollup contract to verify consistency or formatting of additional data. Some require the on-chain contract to track the movement of Eth or tokens within a rollup chain.
Arbitrum Rollup doesn’t require any additional on-chain data per transaction. The rollup contract only needs to post on-chain once for each rollup block it makes. The other advantage of Arbitrum in this department is that because the Arbitrum compiler generates code for each chain, it can put some of the bookkeeping, dispatching, and parsing code into the rollup chain, rather than having to run it on-chain.
4. Does it resist censorship?
In a censorship attack, a malicious actor tries to prevent certain client transactions from getting recognized and executed. In Ethereum, miners can already engage in censorship, though Ethereum relies on incentives and competition between miners to mitigate this risk. Ideally, your rollup system will be as censorship-resistant as the underlying Ethereum chain.
One pitfall here is relying on a single “operator” who has to do something with a client transaction call before that call can be processed by the rollup chain. This operator will have the power to block or delay transactions it doesn’t like, unless there is some mechanism to prevent it.
Arbitrum Rollup gives each chain an Inbox. Any client can post an on-chain transaction to add a call to the chain’s Inbox, and the Arbitrum protocol ensures that the chain will process calls in the Inbox in the order they were posted. The on-chain rollup contract only needs to track a hash accumulator of the Inbox contents, which is cheap and easy to do. Once a call is in the chain’s Inbox, anybody can move the chain’s state forward to make the chain process its Inbox. The only realistic way to censor an Arbitrum Rollup transaction is by censoring the underlying Ethereum chain.
5. Does it limit the amount of computation in a transaction, or the amount of storage in a contract?
A major goal of moving to an off-chain solution is to allow transactions to do more computation and contracts to have more storage than would be possible and affordable on-chain. So it’s best if a system doesn’t artificially limit those things.
One thing that often limits the computation available to a transaction is the possibility that a transaction might need to be re-run or verified on-chain. That would be impossible for a transaction that used more than one block’s worth of gas. (Actually, the limit on gas would have to be lower, because the on-chain component would have to emulate the execution of the transaction, rather than executing it directly. Direct execution is generally impossible because the transaction’s storage is not directly available on-chain, so storage reads and writes in the transaction can’t be run directly — the system would need to rewrite the transaction’s code somehow to make it runnable on-chain.)
Arbitrum Rollup doesn’t impose any artificial limit on computation in a transaction, nor on storage in a contract. It’s never necessary to run more than one step of execution of a contract’s code on-chain, so there is no per-transaction gas limit. And storage is completely off-chain, so again there is no artificial limit.
6. Can malicious actors slow down the chain’s progress?
Contracts on rollup offer the hope of making progress faster than would be possible on main-chain. Your rollup system ought to go fast if everybody is behaving honestly. But what if a malicious party decides they want to keep your contract from serving client calls and getting its computational work done. Can they stop the rollup chain so your contract can’t make progress for a while?
Most systems will have some kind of staking system, and will cause a party creating malicious delays to lose their stake. Often a party who is willing to lose multiple stakes will be able to buy multiple intervals of delay. Sure, you can try to deter this by making the stake large, but that carries costs too (see the next question). You want a system that allows contracts to keep working even if somebody is trying to stop them.
Arbitrum Rollup allows contracts to keep going if somebody tries to delay progress by asserting a bogus rollup block or causing a bogus dispute about the validity of a block. During a dispute, the system maintains both states of the world, and both states can evolve forward quickly. The dispute process will eventually determine which branch is the right one, and the wrong branch will be pruned.
7. How large do stakes have to be?
This one is pretty self-explanatory. Any rollup that is optimistic — and these days, that is any rollup that can do general contracts — will require actors to put down stakes which will be confiscated if they misbehave.
The stakes need to be big enough to deter bad behavior, including attempts to sneak through an invalid rollup block, as well as tactics to delay the chain’s progress. How big the stake needs to be will depend on the design of the protocol: Some protocols are naturally more resistant to certain attacks, so they need a smaller stake to deter those attacks. Be sure that the designer justifies why their stake is large enough, so they’re not just reducing the stake for appearances’ sake.
Arbitrum Rollup recommends setting the stake on a chain equal to 2% of the value held in that chain. Our modeling suggests that with the recommended challenge period of 3 hours, an invalid-assertion attack will succeed no more than 0.2% of the time. Setting the penalty for a failed attack equal to ten times the expected gain is enough to deter the attack.
8. Does it guarantee safety and progress trustlessly?
Any protocol will produce good results if everyone in the world behaves honestly. But what happens if somebody is malicious? What if a lot of people are malicious? You want a protocol that doesn’t fail or freeze.
The idea is trustless safety and progress. Let’s break that down. Trustless means that you get a result as long as you, yourself, behave honestly, and the underlying Ethereum chain operates correctly. Safety means that contracts won’t behave incorrectly. Progress means that a contract keeps making progress — it doesn’t freeze or somebody get locked out forever from executing. So trustless safety and progress means that even if all rollup participants but you are malicious, you can still force contracts to make progress, and to do it correctly.
Arbitrum Rollup guarantees trustless safety and progress. An honest party can stake on correct outcomes, and can win any challenges against those outcomes, so an Arbitrum chain will always make progress, safely, as long as one honest staker is present. And that staker can be you, or somebody else you trust.
9. Does it provide trustless finality?
Rollup systems can take some time to fully confirm transactions, because they have to leave time for a block to be challenged, and the deadline to file a challenge may be long due to worries about censorship attacks. In the meantime, after a transaction has been posted in a block, but before it is fully confirmed, you’d like to be able to get some guarantee that the transaction will eventually be confirmed. (This assumes the transaction is valid and is part of a valid block — otherwise it doesn’t deserve confirmation and had better not be confirmed, ever.)
Trustless finality means that if a transaction has been posted, and that transaction is valid and its predecessors on-chain are valid, then you, by yourself, can ensure the transaction is eventually confirmed, even if everybody else is malicious.
Arbitrum Rollup offers trustless finality. If a block is valid and you stake on it (or if somebody you trust stakes on it), then you can be sure that it will be confirmed.
10. Does it rely on unusual data availability assumptions?
The original conception of rollup had the calldata for all client calls posted on the main Ethereum chain. This has the advantage of allowing anyone to see the calls, and therefore to follow along with the execution of contracts and to independently verify the correctness of claimed rollup blocks that are posted to the main chain.
Some newer rollup schemes try to move that calldata off-chain. This will work out fine, if that data is always, always available. The question for these schemes is: How certain can users be about data availability? What additional assumptions about data availability do users have to make, in order for the system to be trustable?
Arbitrum Rollup does not make any extra data availability assumptions. Everything needed to follow along and verify execution is posted on the main Ethereum chain as calldata.
11. Is it available now?
If you want a rollup system for general contracts that is available and works now, Arbitrum Rollup is the only game in town. You can download the open-source code, read the developer docs, and get started!
