Arbitrum Rollup is an off-chain protocol managed by a contract on the Ethereum chain.
Original Title: “How Arbitrum Rollup Works”
Author: Ed Felten translation & proofreading: counter-insurgency & A sword
I recently published a blog post comparing Arbitrum Rollup with other competing rollup systems ( Chinese translation ). However, that article did not detail the working principle of Arbitrum Rollup, so the task of this article is to fill this gap.
In a word, Arbitrum Rollup is an off-chain protocol managed by a contract 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 be run on the Arbitrum virtual machine. It will run faster. This is what you and I expect.
Rollup basics
Let’s start with the basics. We use Merkle Tree to organize the state of the virtual machine, so we can calculate the cryptographic hash value of the virtual machine state. We store this hash value on the chain, so at any point in the agreement, the state of some virtual machines (through chain consensus) will be fully confirmed and finalized. These hash values of the final state are stored on the chain.
The participants of the agreement advance the state of the virtual machine by proposing a Disputable Assertion (DA); the assertion states that starting from some state hash, based on some technical premises, the virtual machine will execute a certain amount In the calculation step, a new state hash is generated, and related payments are completed during execution, and related log events are generated. Disputed assertions may be valid (that is, believable) or invalid. Participants need to bet a deposit to ensure the validity of the assertion when making a disputed assertion. (More about betting and how it works will be introduced later.)
Dispute assertions will make the agreement a decision point
As shown in the figure above, making a dispute assertion will produce a logical decision point that the agreement must ultimately resolve. If the dispute assertion is valid, the system will enter the new state in the upper right corner of the figure, including the new state hash value generated by the dispute assertion, and other collateral 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.
The old Arbitrum protocol
The original Arbitrum protocol only handled one dispute assertion at a time. After some participants make a disputed assertion, there will be a challenge period during which anyone can challenge the disputed assertion. If it is not challenged, the dispute assertion will be accepted by the system; otherwise, the dispute resolution agreement will be executed and the dispute assertion will be cancelled (this is to prevent the proposer and the challenger from conspiring to concoct the dispute result).
This is simple, but there are two disadvantages. 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 will basically stall. Second, malicious participants can completely freeze virtual machines by deliberately challenging all disputed assertions. Attackers need to pay some deposits as a price, but as long as they want, they can at least delay the system (and profit) through this attack for a long time in certain scenarios.
New and improved version
The new Arbitrum Rollup protocol introduced in this article solves the above two shortcomings. Through “pipelining” to process multiple disputed assertions, the verification node simulates how fast the virtual machine can be processed, and how fast the virtual machine can be processed. Second, as we will explain later, malicious participants cannot delay the system. They can only temporarily delay the on-chain confirmation of the final results, but these results have long been “finalized without trust” for honest nodes.
So, how do you do it? Then I have to go a little deeper…
At most one dispute assertion can follow each state. If there is no disputed assertion behind a state, then anyone can generate a disputed assertion to follow as a new bifurcation point. The result is a parallel future tree.
Parallel Future Tree
Bet
Another important part of the agreement is betting. Anyone can place a bet behind a certain box (state) on the tree. A bet on a box means that you are asserting that the box will eventually be confirmed by the agreement. In other words, you are asserting that the branch from the current state to the box where you bet is the correct branch. If you are wrong, you can imagine that your deposit will be fined.
The bet cannot be revoked. You can move your bet to the right-you can choose the branch up or down after the bifurcation point-but you can’t move the bet to the left, because this is equivalent to revoking your previous bet promise.
Participants making disputed assertions must bet on the succession box that “recognizes their assertions as valid”. Usually they can move the existing bet to the right to the box that meets the conditions. (In rare cases (Translator’s Note: For example, their assertion is invalid and successfully challenged) they can’t do this, they can place an extra bet on the required box. But note that they will conflict Bet on the two paths, so in the end they will lose at least one deposit-usually contradictory is not a wise move).
There is one more detail about the bet: if the box you bet on is confirmed as part of the accepted history, you can choose to withdraw the deposit. This means that if you are correct, you can stop moving your bet until the system “catches up” you, and then you can withdraw your deposit.
A more standard state tree-consisting of a series of valid assertions
At this point, you might be worried that the parallel future tree will become very large and luxuriant. This is impossible in reality, because it requires multiple bets on inconsistent results. As long as one of them is honest, everyone else will lose their deposit. More likely, this tree is actually a chain of valid DAs, one after the other, all bets are on the same branch.
Bet period
We need the system to make a decision on each disputed assertion in the shortest possible time. So when a controversial assertion is added to the chain and a fork is generated, there will be a deadline associated with it. This period is long enough, and anyone who wants to have enough time to check whether the disputed assertion is valid and generate a bet transaction on the chain. Anyone who wants to bet must complete the operation before the time limit expires (expired bets can still be chained, but they cannot determine the validity of the disputed assertion). Once the period expires, all bets that can determine the disputed assertion will be known.
dispute
If Alice and Bob bet on different boxes, then one of the following two events must be true. Either one of the bets can move to the right to the other-meaning their assertions are consistent-or no such path can be found. If there is no path to the right that connects the boxes of Alice and Bob, they must diverge. They must be able to find a unique bifurcation point-a unique controversial assertion, one bet that this assertion is valid, and another bet that it is invalid.
There is a dispute between Alice and Bob
When a dispute occurs between two participants, the system can initiate an interactive dispute resolution agreement. I don’t have enough space here to describe this dispute resolution agreement-I just want to say that this is a dichotomy interactive agreement similar to what we have described in other Arbitrum documents.
The result of the dispute resolution agreement is that one participant will be found to be wrong. The participant’s deposit will be fined. The bet will be deleted from the box where it is located. Part of the deposit will be given to the other party in the dispute, and the rest will be burned.
Multiple disputes can be resolved at the same time, but each bettor can only participate in one dispute at a time. Because losers’ bets will be deleted, each dispute resolved will reduce the number of disagreements in the entire system. Participants who have lost their deposit can continue to bet, but the new bet cannot affect the disputed assertion that the betting period has expired. The effect of this is that after the betting window for a disputed assertion ends, all disagreements about how to handle the assertion will be eliminated.
Result confirmation
After the betting period of a disputed assertion expires, if all bets submitted in time (and have not been deleted) exist on the same branch from the assertion, then the system can be sure that the result of the assertion is true . The disputed assertion is either accepted or rejected, and the current state will move to the correct box to the right of the disputed assertion. If the dispute assertion is confirmed to be valid, its collateral 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 abiding, and no one wants to lose their deposit due to betting mistakes. Only valid dispute assertions will be asserted by (other participants), forming a chain, and no one will bet on any invalid branch of the dispute assertion. In this case, all disputed assertions will be confirmed immediately after the betting period has passed.
Why no need to trust (Trustless)
An important property of Arbitrum Rollup is that there is no need for trust-as long as there is an honest participant, you can ensure that the virtual machine state advances correctly. Why? Imagine that Alice always bet on the correct branch. If there is no disputed assertion, she asserts herself.
Because Alice always bet on the correct branch, she will win every dispute. If anyone disagrees with Alice, they will either (a) have a dispute with an unrelated third party and lose the deposit, or (b) eventually have a dispute with Alice and lose the deposit to Alice. In either case, everyone who is inconsistent with Alice will lose their deposit. Only by agreeing to Alice’s bet can it survive, so Alice’s path on the tree will eventually become the only branch that has 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 credible, and Alice can be sure that this box will eventually be confirmed. For Alice, this path is the same as being finalized.
Even if you do not bet on a certain path, if you see several people betting on it, as long as you believe that there is at least one honest person among them, you can be sure that this path will eventually be confirmed-for you , This path is the same as being finalized.
The benefits of finality without trust
Why is the finality without trust worthwhile? The classic example comes from the previous discussion of other rollup protocols. Suppose a virtual machine wants to pay Alice. The payment event occurs on the honest path, but the box containing the payment still needs to wait some time to be confirmed on the chain.
The trustless finality allows Alice to get the money immediately. If Bob has the remaining money, he can immediately pay Alice in exchange for Alice’s unconfirmed receipt (plus a little tip paid to Bob). Bob only wants to trade with Alice if he can be sure that this collection of Alice will happen. Bob can ensure this by betting on honest results-so that he has no trust in confidence that the payment will eventually happen. It’s not just Bob that 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’s immediate money is greatly reduced.
The key is that the feasibility of this market mechanism depends on trustless finality. If “everyone” knows that this event will eventually be confirmed, then the delay of confirmation on the chain will not cause so much inconvenience.
Not only for payments, but also for other things that virtual machines can do. If the virtual machine is 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 recognized on the chain.
Delayed attack
Because this system is trustless, bad guys cannot forcefully create wrong results. All they can do is delay the system. Doing so requires them to pay a deposit, and if the amount of the deposit is huge, it is expensive.
Imagine if someone would rather pay a deposit to launch a delayed attack, what is the worst they can cause?
The first thing to note is that bad guys cannot stop good guys from continuing to build honest branches. And they cannot prevent good people from gaining trustless confidence that “the honest branch will eventually be confirmed.”
All the attacker can do is to bet on the wrong branch to delay the on-chain confirmation of the honest path. Every time they bet, they will have a dispute with honest participants, and honest participants will take a large part of the attacker’s deposit from the dispute. After all the deposits of the attacker are taken away, the chain confirmation will continue to move forward.
What happens if an attacker makes multiple bets on the wrong result? Then these deposits will be taken away in disputes one after another. If multiple people bet on honest results, these people can all enter the dispute resolution and take away the attacker’s deposit in parallel. And it needs to be noted that everyone is very clear about what happened. Many people want to join in and get a share of the pie, betting on the correct result to grab the deposit from the attacker. If the honest party has K individuals betting, during a dispute delay period, the attacker will consume K deposits. If the attacker places more bets, it is likely to attract more honest bets. This is a disaster for attackers.
optimization
Many optimizations can also be made to reduce the amount of on-chain accounting data required to operate the protocol, reduce gas consumption on the chain, and make it easier for attackers to delay the feeding frenzy caused by the attack. I won’t detail these optimizations here-this article is already long enough.
The way forward
Offchain Lab expects to push this Arbitrum Rollup protocol to the open source code base soon.
Original link:
https://medium.com/offchainlabs/how-arbitrum-rollup-works-39788e1ed73f
Source link: mp.weixin.qq.com
