Partnered With:

Detailed Explanation of Ethereum Layer 2 Expansion: Arbitrum Rollup

Read this article in 22 Minutes

Now that Ethereum pays so much attention to the Rollup scheme, you need to understand what is Arbitrum Rollup

Original Title: "Understanding the Working Principle of Arbitrum Rollup in One Article"

Original Source: Ethereum Enthusiast

Recently I published A blog post comparing Arbitrum Rollup with other competing rollup systems (Chinese translation). However, that article did not go into detail about how Arbitrum Rollup works, so the task of this article is to fill that gap.

In a word, Arbitrum Rollup is an off-chain protocol governed by contracts on the Ethereum chain. In order for their applications to run on Arbitrum Rollup, dApp developers need to write a set of contracts in Solidity, and then compile these contracts into executable code that can run on the Arbitrum virtual machine. It will run faster, which is what you and I expect.

Basics of Rollup

Let’s start with the basics. We use a Merkle Tree to organize the state of the virtual machine, so that the cryptographic hash value of the state of the virtual machine can be calculated. We store this hash on-chain, so at any point in the protocol, there will be some state of the virtual machine (via on-chain consensus) that is fully confirmed and finalized. The hash values of these finalized states are stored on the chain.

Participants in the protocol advance the state of the virtual machine by proposing a dispute assertion (Disputable Assertion, DA); At the beginning, based on some technical prerequisites, the virtual machine will perform a certain number of calculation steps, generate a new state hash, complete related payments during execution, and generate related log events. A dispute assertion may be valid (that is, believable) or invalid. Participants need to bet a deposit to ensure the validity of the assertion when making a dispute assertion. (More on betting and how it works later.)

- Dispute assertion will result in a decision for the protocol Point -

As shown in the figure above, raising a dispute assertion results in a protocol that must eventually Logical decision point for resolution. If the dispute assertion is valid, the system will enter the new state in the upper right corner of the diagram, including the new state hash value generated by the dispute assertion, and other incidental effects (generating corresponding payments and logs). If the dispute assertion is invalid, enter the branch in the lower right corner, the dispute assertion is rejected by the system, and the original state will not change.

Old Arbitrum protocol

The original Arbitrum protocol only processed A controversial assertion. After some participants make a dispute assertion, there will be a challenge period during which anyone can challenge the dispute assertion. If not challenged, the disputed assertion will be accepted by the system; otherwise, the dispute resolution protocol will be executed and the disputed assertion revoked (this is to prevent the proposer and the challenger from colluding to concoct the disputed result).

This is simple, but has two drawbacks. First, because only one dispute assertion is processed at a time, the processing speed of the virtual machine is very limited. During each challenge period, the normal processing flow essentially grinds to a halt. Second, a malicious actor can completely freeze a virtual machine by deliberately challenging all disputed assertions. The attacker needs to pay some deposit as a price, but if they want, they can delay the system for a long time (and profit) through this attack at least in certain specific scenarios.

NEW IMPROVED VERSION

The new Arbitrum Rollup introduced in this article of mine The protocol addresses the two drawbacks mentioned above. Through "pipelining" to process multiple dispute assertions, the processing speed of the virtual machine is as fast as the computing speed of the virtual machine simulated by the verification node. Second, as we will explain later, malicious actors cannot stall the system, they can only temporarily delay the on-chain confirmation of final results that have already been “trustlessly finalized” to honest nodes.

So, how do you do it? Then we have to go deeper...

Each state can be followed by at most one dispute assertion. If a state is not followed by a disputed assertion, then anyone can generate a disputed assertion followed by it as a new fork point. The result is a tree of parallel futures.

- Parallel Future Tree-

Betting

Another protocol The important part is betting. Anyone can place a bet behind a certain box (state) on the tree. Betting on a box means you are asserting that the box will eventually be confirmed by the protocol. In other words, you are asserting that the branch from the current state to the box you bet on is the correct one. If you are wrong, you can conceivably forfeit your deposit.

Bets cannot be undone. You can move your bet to the right - you can choose branches up or down after the fork point - but you can't move your bet to the left, because that is equivalent to rescinding the bet commitment you made earlier.

Participants who make a disputed assertion place a bet on the successor box "Valid their assertion". Usually they can move existing bets to the right to meet the conditions of the box. (In rare cases (Translator's Note: such as their assertion being invalid and being successfully challenged) they cannot do this, they can place an extra bet on the required box. But note that they will be in conflict bet on both paths, so they end up losing at least one of their stakes - usually contradicting itself is not a wise move).

There is one more detail about betting: if the box you bet on is confirmed to be As part of the history of acceptance, you can choose to get your deposit back. This means that if you are correct, you can stop moving your bet until the system "catches up" to you, and then you get your deposit back.

- A more standard state tree - consisting of a chain of valid assertions-

At this point, you may be concerned that the tree of parallel futures is going to be very large and overgrown. This cannot happen in reality because it would require multiple bets with inconsistent outcomes. As long as one of them is honest, everyone else loses their deposit. More likely, the tree is actually a chain of valid DAs, one after the other, all bets on the same branch.

Bet Period

We need the system to A decision is made for each disputed assertion. So when a disputed assertion is added to the chain, creating a fork point, there will be a deadline associated with it. This period is long enough for anyone, if they wish, to check whether the disputed assertion is valid and generate a bet transaction on the chain. Anyone who wants to place a bet has to do so before the deadline expires (expired bets can still be on-chain, but they cannot determine the validity of that disputed assertion). Once the period expires, all bets that could determine the disputed assertion will be known.

Disputes

If Alice and Bob bet on different boxes, then the following two events , one of them must be true. Either one of the bets can move right to the other—meaning their assertions agree—or no such path can be found. If there is no right-moving path that connects Alice's and Bob's boxes, then they must have diverged. There must be a unique bifurcation point between them—a unique disputed assertion that one person bets on to be valid and another bets on its invalidity.

- There is a dispute between Alice and Bob-

When a dispute arises between two participants, the system can initiate an interaction dispute resolution agreement. I don't have enough space to describe this dispute resolution protocol here - suffice it to say that it is a dichotomous interaction protocol similar to what we have described in other Arbitrum documents.

The result of a dispute resolution agreement is that one participant will be found to be wrong. This participant's deposit will be forfeited. Bets are removed from the box they were placed on. Part of the deposit goes to the other party to the dispute, and the rest is burned.

Multiple disputes can be resolved at the same time, but each bettor can only participate in at most one dispute at a time. Each resolution of a dispute reduces the number of disagreements across the system, since the loser's bet is removed. Participants who lose their deposit can continue to place bets, but new bets cannot affect disputed assertions that the betting period has expired. This has the effect that after the betting window for a disputed assertion is over, any disagreement about how that assertion should be handled is resolved.

Result Confirmation

After the betting period of a certain dispute assertion expires, if all The bets submitted in time (and not yet deleted) all exist on the same branch from the assertion, then the system can be sure that the result of the assertion is true. The dispute assertion is either accepted or rejected, and the current state moves to the correct box to the right of the dispute assertion. If the dispute assertion is confirmed to be valid, its incidental effects, such as payment, will also take effect on the chain. This is how the state of the virtual machine moves forward.

Under normal circumstances, participants will be honest and obedient, and no one wants to lose their deposit due to a wrong bet. Only valid disputed assertions will be asserted by (other participants), forming a chain, and no one will bet on any invalid branch of the disputed assertion. In this case, all disputed assertions are confirmed as soon as the staking period has elapsed.

Why Trustless

An important property of Arbitrum Rollup is that it is trustless— — As long as there is one honest participant, the virtual machine state can be ensured to move forward correctly. Why, imagine Alice always betting on the correct branch, and if there are no disputed assertions, she asserts herself.

Since Alice always bets on the correct branch, she will win every time dispute. If anyone disagrees with Alice, they either (a) get into a dispute with an unrelated third party and lose their deposit, or (b) end up in a dispute with Alice and lose their deposit to Alice. In either case, everyone who disagrees with Alice loses their deposit. Only agreeing to Alice's bet will survive, so Alice's path on the tree will eventually be the only branch with a timely bet - and Alice's path will be confirmed.

- As long as Alice is honest, no matter what others do, the green box will be confirmed-

Because the system is trustless in this way, if Alice bets on a certain box, she must know that the path to this box is trustworthy, and Alice can be sure that this box will eventually will be confirmed. For Alice, this path is as if it has been finalized.

Even if you don't bet on a path, if you see several people betting on it Note, as long as you trust at least one honest person among them, you can be sure that this path will eventually be confirmed-for you, this path will be the same as being finalized.

The benefits of finality without trust

Why do you say no trust The finality of value? The classic example comes from the previous discussion of other rollup protocols. Suppose a virtual machine wants to pay Alice. The payment event happens on the honest path, but the box containing the payment still needs to wait some time to be confirmed on-chain.

The trustless finality allows Alice to get the money immediately. If Bob has money to spare, he can immediately pay Alice in exchange for Alice's undetermined receipt (plus pay Bob a small tip). Bob will only want to trade with Alice if he can be sure that Alice's payment will definitely happen. Bob can ensure this by betting on an honest outcome—so he has trustless confidence that the payment will eventually happen. It's not just Bob who can do this. Anyone with a bit of money can use this method to lend money to Alice or someone who has her needs. These people compete with each other by offering lower fees, so that the cost of Alice getting the money immediately is greatly reduced.

The point is that the viability of such a market mechanism depends on trustless finality. If "everyone" knew that the event would eventually be confirmed, the delay in on-chain confirmation wouldn't be as much of an inconvenience.

Not only for payment, but also for other things that virtual machines can do. If the virtual machine were to generate a log event to record what happened, trustless finality means that anyone can take action with certainty, because the log event will eventually be acknowledged on the chain.

Delay attack

Because this system is trustless, bad guys cannot forcibly make mistakes result. All they can do is slow down the system. Doing so requires them to pay a deposit, which can be costly if the deposit is large.

Imagine if someone would rather pay a deposit to launch a delay attack, what's the worst they can do?

The first thing to note is that the bad guys can't stop the good guys from continuing to build honest branches. And they can't prevent good guys from gaining trustless confidence that honest branches will eventually be confirmed.

All an attacker can do is stake on the wrong branch to delay on-chain confirmation of the honest path. Each of their bets creates a dispute with honest participants, who take a large portion of the attacker's deposit from the dispute. When the attacker's entire deposit is taken away, the chain confirmation will continue to move forward.

What if the attacker made multiple bets on the wrong outcome? Then these deposits will be taken away in one dispute after another. If there are multiple people betting on an honest outcome, those people can all enter into dispute resolution and take away the attacker's deposit in parallel. And it needs to be noted that everyone knows what happened, and many people want to join in and get a share, betting on the correct result to snatch the deposit from the attacker. If the honest party has K individuals betting, the attacker will consume K deposits during a dispute delay period. If the attacker bets more, it will likely attract more honest bettors. This spells disaster for an attacker.

Optimization

You can also do a lot of optimization to reduce the chain required to operate the protocol The amount of recorded data is reduced, the gas consumption on the chain is reduced, and the feeding frenzy caused by the attacker's delayed attack is easier to stage. I won't dwell on these optimizations here - this post is already long enough.