This article is reproduced from: Decentralized Financial Community; Author: ChinaDeFi; Reprinted with authorization.
Arbitrum Rollup is an off-chain protocol governed by an on-chain Ethereum contract. A dApp developer has a set of contracts written in Solidity, which the developer compiles into an Arbitrum virtual machine (VM) to run on Arbitrum Rollup. We want them to run fast.
The basics of Rollups
Let's start with the basics. The state of a VM is organized as a Merkle tree, so a cryptographic hash of the VM state can be computed. At any point in the protocol, some state of the VM is fully confirmed. Its hash is stored on-chain.
Participants of the protocol can make a disputed assertion (DA), which claims that starting with a certain state hash, under some technical prerequisites, the VM can perform a specified number of computational steps, resulting in a specified new state hash , and the VM makes the specified payment and emits the specified log event during that computation. DA may be valid (ie real) or invalid. The party making the DA will be required to deposit the validity of the DA.
A contested assertion creates a decision point for the protocol
As shown on the left, contested assertions create logical decision points at which the protocol must eventually be resolved. If the DA is valid, the system will enter a new state in the upper right corner, with a new state hash, and the side effects (payments and logs) specified in the DA. Or in another branch, the DA is invalid; it is rejected and the status remains the same.
Previous Arbitrum protocol
The original Arbitrum protocol handles dispute assertions one at a time. DA will be claimed by someone and then a challenge period will pass during which anyone can challenge DA. If there are no objections, the DA will be confirmed; otherwise, the dispute protocol will be run and the DA will be cancelled.
This is simple, but has two drawbacks. First, since only one DA can be active at a time, the VM's process speed will be limited. Essentially, the process must stop during each challenge. Second, a malicious actor can freeze a VM by deliberately challenging all DAs created by that VM. This will cost the attacker a range of costs, but if they are willing to pay that cost, they can delay progress for a long time, at least in some cases.
New, improved Arbitrum protocol
The new Arbitrum Rollup protocol addresses both of these shortcomings. Multiple DAs can be "pipelined" so that the VM can proceed as quickly as the computation of the validator emulates the VM. Second, as we will see below, a "malicious actor cannot slow down progress, they can only temporarily delay on-chain recognition of outcomes that are already "trustless outcomes" for honest actors .
How is this possible?
Each state can have at most one DA following it. If a DA does not follow state, then anyone can create a DA that follows it, thus creating a new branch point. The result might be a possible future tree.
pledge
pledge
Another important part of the protocol is staking. Anyone can stake on a square box on the tree. By staking a square, users can assert that the square will eventually be confirmed by the protocol. The user asserts that the correct branch is taken at each DA on the path from the current state to the square he placed. Get it wrong and the user could lose your stake deposit.
The pledge operation cannot be revoked. Users can move their deposit to the right—up or down at each branch point—but not to the left, as that would be tantamount to rescinding their previous pledge commitment.
The party making a disputed claim must stake on that DA's "DA valid" successor. Usually, they can satisfy this requirement by moving the existing one to the right to place it on the desired successor square. (In the rare case they are unable to do this, they can bet extra margin on the desired square. But note that they will be bet on two paths that do not coincide, so they will eventually have to lose At least one of the two pledges - it's not wise to contradict yourself.)
Another detail about the pledge is: if the block pledged by the user is confirmed and becomes an accepted historical record, the user can choose to withdraw his pledge deposit. This means that if the user is correct, they can keep their stake and wait for the system to "catch up" to themselves, and then the user is able to get their stake back.
A more typical state tree - a series of true assertions
At this point, the user may be concerned that the possibility tree may become very large and its branches. This is unlikely to happen in practice because it requires multiple parties to stake on mutually inconsistent outcomes. Only one can be correct, and everyone else loses their stake bond. More likely, the "tree" is actually a valid DA chain, one after the other, all staked on the same outcome.
Pledge Deadline
dispute
dispute
If Alice and Bob are bet on different squares, then one of two things will be true. Either there will be a path to the right, from one of them to the other—meaning that their claims are consistent with each other—or there will be no such path. If there isn't a right-moving path connecting Alice's and Bob's squares, then they must diverge in some way. There will always be a unique point of contention between them - a unique DA where one staked is valid while the other staked is invalid.
Alice and Bob are preparing for a dispute
When a dispute arises between two parties, the system can initiate an interactive dispute resolution protocol between the two parties.
As a result of the dispute resolution agreement, one party will be found to be incorrect. That party will lose their pledge bond. The pledge bond will be cleared from the square it is on. A portion will go to the other party to the dispute, and the rest will be burned.
Multiple disputes can be in progress at the same time, but each staker can only be involved in at most one dispute at a time. Each dispute reduces the number of disagreements in the system because the loser's stake deposit is wiped. The party who lost the pledge deposit can re-stake if they wish, but the new pledge deposit will not be able to affect the DA that has passed the pledge period. The upshot of this is that after the DA's staking period has passed, the dispute will gradually iron out any disagreement about how DA should be treated.
verify results
Once a DA's staking deadline has passed and all remaining timely (before the set staking deadline) stakes are on the same fork of that DA, the system can confirm the outcome 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 payment) will be implemented on-chain, and this is how the state of the VM moves forward.
Usually, parties will act honestly because they don’t want to lose their stake by staking false claims. In a single chain, only valid DA will be asserted and no one will stake on any invalid fork of DA. In this case, each DA can be confirmed immediately when its staking period expires.
why it is trustless
An important property of Arbitrum Rollup is that it is trustless - an honest party can force the VM to behave correctly and make progress. Why? Imagine that Alice always stakes on the real branch of each DA, and if the tree is empty, she asserts DA.
Because Alice is staked on the real branch, she wins every dispute she joins. If the others disagree with Alice, they (a) either lose their stake bond in a dispute unrelated to the third party, or (b) end up in a dispute with Alice and lose their bond to her. Either way, everyone who disagrees with Alice will end up losing their stake bond. Only those who agree with Alice will survive, so Alice's path through the tree will eventually be the only one who staked it in time - Alice's path will also be confirmed.
If Alice is honest, no matter what others do, the green square will eventually be confirmed
Because the system is trustless in this case, if Alice stakes on a square and she knows the path to that square is real, Alice can be sure that the square she is on will eventually be confirmed. For Alice, this path is as good as the final path.
Even if a user doesn't stake on a path, if he sees several people staking on that path, and the user himself believes that at least one of those people is honest - this path is as good as the final path.
Benefits of Distrusting Results
Why are trustless outcomes valuable? This classic example comes from previous discussions on other rollup protocols. Suppose a VM wants to pay Alice a sum of money. The payment event is made on the honest path, but it will be a while before the on-chain confirmation of the square where the payment occurred.
The result of distrusting gives Alice immediate access to her money. If Bob has unstaked money, he can immediately give it to Alice in exchange for Alice assigning future unconfirmed payments to Bob (plus paying Bob a minimum fee). Bob can ensure this by staking on an honest outcome — and then he can confidently wait for the payment to finally be confirmed. It's not just Bob who can do this. Anyone with a bond can lend to Alice and others like her in the same way. These people can compete with each other by offering lower fees, lowering Alice's cost of earning a bond.
The point is that the viability of this market mechanism depends on the end result of trustlessness. If "everyone" already knows that something will eventually be confirmed, then delays in on-chain confirmations are less of a nuisance.
This applies not only to payments, but to other things the VM does as well. If the VM will emit a log entry announcing that something happened, the trustless result means that anyone can be confident that the log entry will be identified on-chain.
delayed attack
Because the system is trustless, malicious actors cannot force an incorrect result. All they can do is slow down the process. Doing so requires them to sacrifice their staking deposit, which can be expensive if the staking deposit is large.
Suppose someone wants to launch a delay attack, they are willing to sacrifice the pledge bond. What is the worst damage they can do?
The first thing to note is that malicious actors cannot prevent honest actors from continuing to build honest branches of the tree. They also cannot prevent honest trusters from gaining untrustworthy trust when they finally confirm honest forks.
All an attacker can do is stake on a fake branch to delay on-chain confirmation of the honest path. Every stake they place creates more disputes for honest actors, who take away a large portion of the attacker's stake deposit. Once all of the attacker's stake bond is taken, the on-chain process continues.
optimization
optimization
Various optimizations have the potential to reduce the amount of on-chain bookkeeping required to operate the protocol and reduce on-chain gas costs.
