How Arbitrum Rollup works
Recently I posted on how Arbitrum Rollup compares to competing systems. But I didn’t say much about how Arbitrum Rollup works. My mission in this post: to fix that by filling in details.
Arbitrum Rollup is an off-chain protocol that is managed by an on-chain Ethereum contract. A dapp developer has a group of contracts that are written in Solidity, and the developer has compiled the contracts into an Arbitrum Virtual Machine (VM) to run on Arbitrum Rollup. You want them to run fast.
Basics of Rollup
Let’s start with the basics. The state of your VM is organized as a Merkle Tree, so a cryptographic hash of the VM’s state can be computed. At any point in the protocol, there is some state of the VM that is fully confirmed and final. Its hash is stored on-chain.
A participant in the protocol can make a Disputable Assertion (DA) which claims that starting in some state-hash, and with some technical preconditions, the VM can execute a specified number of steps of computation, resulting in a specified new state-hash, and with the VM making specified payments and emitting specified log events during that computation. The DA might be valid (i.e., truthful) or invalid. The party making the DA will be required to stake a deposit on the validity of the DA. (More on stakes and how they work below.)
As depicted on the left, a Disputable Assertion creates a logical decision point that the protocol will eventually have to resolve. If the DA is valid, the system will enter a new state on the upper right, with a new state hash, and with the side-effects (payments and logs) specified in the DA. Or on the other branch the DA is invalid; it is rejected and the state is unchanged.
The old Arbitrum protocol
The original Arbitrum protocol dealt with Disputable Assertions one at a time. A DA would be asserted by some party, then a challenge period would elapse, during which anybody could challenge the DA. If there was no challenge, the DA would be confirmed; otherwise the dispute protocol would be run and the DA would be canceled (to be safe in case the asserter and challenger were colluding to “cook” the dispute result).
This was simple but had two drawbacks. First, because only one DA could be active at a time, the rate of progress of a VM would be limited. Essentially, progress had to stop during each challenge period. Second, a malicious party could freeze a VM by deliberately challenging all DAs made for that VM. This would cost the attacker a series of stakes, but if they were willing to pay this cost they could hold up progress for a long time, in at least some scenarios.
New and improved
The new Arbitrum Rollup protocol, which I’m describing in this post, addresses both of those drawbacks. Multiple DAs can be “pipelined” so that a VM can progress just as fast as validating nodes can emulate the VM’s computations. Second, as we’ll see below, a bad actor can’t slow up progress, they can only temporarily delay on-chain recognition of outcomes that are already “trustlessly final” for honest parties.
How does that work? Let’s dig into the new protocol….
Each state can have at most one DA following from it. If a DA has no following state, then anybody can create a DA that follows it, creating a new branch point. The result will be a tree of possible futures.
Staking
Another important part of the protocol is staking. Anybody can put a stake on one of the square boxes in the tree. By staking on a square you are asserting that that square will eventually be confirmed by the protocol. In other words, you’re asserting that you have taken the correct branch at each DA along the path from the current state to the square you’re staked on. If you are wrong, you can expect to lose your stake.
Staking actions cannot be undone. You can move your stake to the right — choosing to go up or down at each branch point — but you can’t move to the left because that would amount to undoing a staking commitment that you made earlier.
The party who makes a Disputable Assertion is required to stake on the “DA valid” successor of that DA. Normally they’ll be able to satisfy this requirement by moving an existing stake to the right to put it onto the required successor square. (In the rare case where they can’t do that, they can put down an extra stake on the required square. But note that they would then be staked on two inconsistent paths, so that they would eventually have to lose at least one of the two stakes — it’s not a smart move to contradict yourself.)
One more detail about stakes: if the square you are staked on is confirmed and becomes the accepted history, you have the option of recovering your stake. That means that if you are correct, you can keep your stake where it is and wait for the system to “catch up” with you, and then you’ll be able to recover your stake.
At this point you might be worried that the tree of possibilities can get very large and branch-y. That’s not likely to happen in practice, because it would require multiple parties to stake on outcomes that are mutually inconsistent. Only one of them can be correct, and everybody else will lose their stake. More likely is that the “tree” is really a chain of valid DAs, one after another, and all of the stakes are on the same outcomes.
Staking Deadlines
We need the system to make a decision about each Disputable Assertion before too much time passes. So when a DA is added to the chain, creating a branch point, a deadline is associated with that DA. The deadline is far enough in the future that everyone will have time to check whether the DA is valid and get a transaction on-chain to stake on an outcome of the DA, if they choose to do so. If anyone wants to commit themselves to a stake for or against the validity of that DA, they must do so before the deadline. (Stakes can still be introduced after the deadline, but they do not participate in deciding for or against that DA.) Once the deadline has been reached, all of the stakes relevant to deciding that DA will be known.
Disputes
If Alice and Bob are staked on different squares, one of two things will be true. Either there will be a rightward-moving path from one of them to the other — meaning their claims are consistent with each other — or there will not be such a path. If there is not a rightward-moving path connecting Alice and Bob’s squares, then they must disagree about something. There will always be a unique point of dispute between them — a unique DA for which one of them is staked on that DA being valid and the other is staked on it being invalid.
Whenever there is a dispute between two parties, the system can start an interactive dispute resolution protocol between them. I don’t have space to describe the dispute resolution protocol here — suffice it to say that it is a bisection-type interactive protocol similar to what we have described in other Arbitrum documents.
The result of the dispute resolution protocol is that one party will be found to be incorrect. That party will forfeit their stake. The stake will be erased from the square it is on. Part of it will be given to the other party in the dispute, and the rest will be burned.
Multiple disputes can be going on at the same time, but each staker can be in at most one dispute at a time. Because losers’ stakes will be erased, each dispute will reduce the amount of disagreement in the system. Parties who lose their stakes can re-stake if they want, but the new stakes won’t be able to affect DAs whose staking deadlines have already passed. The effect of this is that after a DA’s staking deadline has passed, disputes will progressively eliminate any disagreement about how to treat that DA.
Confirming Results
Once a DA’s staking deadline has passed, and all of the timely (placed before the staking deadline) stakes that remain are on the same branch from that DA, the system can confirm the result of that DA. The DA is either accepted or rejected, and the current state moves to the appropriate square to the right of the DA. If the DA is confirmed as valid, its side-effects, such as payments, are effectuated on-chain. This is how the state of the VM moves forward.
In the common case, parties will behave honestly, because they won’t want to lose their stakes by staking on false claims. Only valid DAs will be asserted, in a single chain, and nobody will stake on the invalid branch of any DA. In this case, every DA can be confirmed immediately when its staking deadline expires.
Why It’s Trustless
An important property of Arbitrum Rollup is that it’s trustless — a single honest party can force the VM to behave correctly and make progress. To see why, imagine that Alice always stakes on the truthful branch at each DA, and she asserts DAs if the tree ever gets empty.
Because Alice is staked on true branches, she will win every dispute she gets into. If anybody else disagrees with Alice, they will either (a) lose their stake in an unrelated dispute with a third party, or (b) eventually get into a dispute with Alice and lose their stake to her. Either way, everyone who disagrees with Alice will eventually lose their stake. Only stakes that agree with Alice will survive, so Alice’s path through the tree will eventually be the only one that has timely stakes on it — and Alice’s path will be confirmed.
Because the system is trustless in this way, if Alice is staked on a square and she knows the path to that square is truthful, Alice can be certain that the square she is on will eventually be confirmed. As far as Alice is concerned, that path is as good as final.
Even if you’re not staked on a path, if you see that several people are staked on it, and you trust that at least one of those people is honest, then you can be sure that that path will be confirmed eventually — as far as you are concerned, that path is as good as final.
Benefits of trustless finality
Why is it valuable to have trustless finality for outcomes? The classic example comes from previous discussions of other rollup protocols. Suppose a VM is going to make a payment to Alice. The payment event is on the honest path, but it’s going to be a while before the square where the payment happens will be confirmed on-chain.
Trustless finality gives Alice a way to get her money right away. If Bob has unencumbered money, he can give it to Alice immediately, in exchange for Alice assigning the future not-yet-confirmed payment to Bob (plus paying Bob a minimal fee). Bob will only want to do that if he can be sure that the payment will actually happen. Bob can make sure of that by staking on the honest outcome — then he will have trustless confidence that the payment will eventually happen. It’s not only Bob who can do that. Anybody who has funds can lend them to Alice and others like her, in the same way. Those people can compete with each other by offering lower fees, driving down Alice’s cost to get her funds right away.
The key point is that the viability of this kind of market mechanism depends on trustless finality. The delay in on-chain confirmation of a thing is less of an inconvenience if “everybody” already knows that that thing will eventually be confirmed.
This is true not only for payments but for other things a VM does. If the VM is going to emit a log item announcing that something has happened, trustless finality means that anyone can act with certainty that the log item will be recognized on-chain.
Delay attacks
Because the system is trustless, bad actors can’t force an incorrect outcome. What they can try to do is slow down progress. Doing this requires them to sacrifice stakes, which will be costly if the stake amount is significant.
Let’s imagine that somebody is motivated to launch delay attacks, and they’re willing to sacrifice stakes. What is the worst damage they can do?
The first thing to note is that bad actors can’t prevent honest parties from continuing to build out the honest branch of the tree. And they can’t prevent honest parties from gaining trustless confidence in the eventual confirmation of the honest branch.
All that an attacker can do is to stake on false branches to delay on-chain confirmation of the honest path. Each stake they place will create one more dispute against an honest party, in which the honest party takes a big chunk of the attacker’s stake. Once all of the attacker’s stakes have been taken, on-chain progress will continue.
What if the attacker places multiple stakes on false outcomes? Then those stakes will have to be taken one by one in disputes. If there are multiple people staked on the honest outcome, those people can all enter disputes against the attackers, working in parallel to take the attacker stakes. And notice that it will be obvious to everyone what is happening, and lots of people will want to get in on the action, staking on the true outcome so they can join the feeding frenzy of people using disputes to grab attacker stakes. If there are K people staking on the honest side, it will cost the attacker K stakes to buy one dispute period of delay. If the attacker puts down even more stakes, that will likely attract even more honest stakers. That’s a bad dynamic for the attacker.
Optimizations
Various optimizations are possible to reduce the amount of on-chain bookkeeping that is necessary to operate the protocol, to reduce the on-chain gas cost, and to make beneficial feeding frenzies against delay attackers easier to mount. I won’t drill down into the optimizations here — this post is already long enough.
Path forward
We’re building this at Offchain Labs. Expect this Arbitrum Rollup protocol to be pushed out to our open source codebase soon. We’re happy to answer questions. And oh by the way, if you want to help build things like this, we’re hiring.
