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 of the protocol, some state of the VM is fully confirmed. Its hash is stored on the chain.
A participant in the protocol may make a disputed assertion (DA) that claims to start with some state hash, and subject to some technical premises, the VM may perform a specified number of computation steps that result in a specified new state hash, and the VM makes a specified payment and emits a specified log event during that computation. the DA may be valid (i.e., true) or invalid. The party formulating the DA will be required to make a deposit for the validity of the DA.
A contested assertion creates a decision point for the protocol
As shown on the left, the contested assertion creates a logical decision point that the protocol must eventually resolve. If the DA is valid, the system will enter a new state with a new state hash in the upper right corner, along with the side effects (payments and logs) specified in the DA. Or in the other branch, the DA is invalid; it is rejected and the state remains unchanged.
The previous Arbitrum protocol
The original Arbitrum protocol handled one disputed assertion at a time. the DA would be declared by some person, and then a challenge period would pass, during which anyone could challenge the DA . If there are no challenges, the DA will be confirmed; otherwise the disputed protocol will be run and the DA will be cancelled.
This is simple, but has two drawbacks. First, because only one DA can be active at a time, the speed of the VM’s processes will be limited. Essentially, processes must be stopped during each challenge. Second, a malicious actor could freeze the VM by intentionally challenging all DAs created by that VM. this would cost the attacker a range of costs, but if they were willing to pay such costs, they could, at least in some cases, delay progress for a long time.
The New, Already Improved Arbitrum Protocol
The new Arbitrum Rollup protocol addresses both of these shortcomings. Multiple DAs can be “pipelined” so that VMs can be computed as fast as the verification nodes simulate VMs. Second, as we will see below, a “malicious actor cannot slow down progress, they can only temporarily delay the identification of results in the chain, which are already “de-trusted results” for an honest actor.
How is this done?
Each state can have at most one DA following it. If a DA does not follow a state, then anyone can create a DA that follows it, thus creating a new branch point. The result will probably be a tree of possible futures.
Possible future trees
Another important part of the agreement is the pledge. Anyone can pledge a square box in the tree. By pledging a box, the user can assert that this box will eventually be confirmed by the protocol. The user asserts that the correct branch is used at each DA on the path from the current state to the box he or she has placed. If it is wrong, the user may lose your pledge deposit.
Pledge operations cannot be undone. A user may move his or her margin to the right – selecting up or down at each branch point – but not to the left, as that would be tantamount to revoking the pledge commitment he or she previously made.
The party making the disputed claim must pledge on a “DA Valid” successor to that DA. Usually, they can satisfy this requirement by moving the existing one to the right in order to place it on the desired successor square. (In the rare case that they are unable to do this, they can pledge an additional deposit on the desired square. Note, however, that they will be staked on two inconsistent paths, so they will eventually have to lose at least one of their two pledges – not a wise move to contradict themselves.)
Another detail about pledges is this:If the cube pledged by the user is confirmed and becomes an accepted history, the user has the option to reclaim their pledge deposit. This means that if the user is correct, he/she can keep his/her principal and wait for the system to “catch up” with him/her, and then the user will be able to recover his/her principal.
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, as it requires multiple parties to pledge on mutually inconsistent outcomes. Only one may be correct, and all others will lose their pledge margin. More likely, the “tree” is actually a valid DA chain, one after the other, with all pledges on the same outcome.
Deadline for pledges
We need the system to make a decision on each disputed assertion before too much time has elapsed. Therefore, when a DA is added to the chain to create a branch point, a deadline is associated with this DA. In the future, when the deadline is long enough, everyone will have time to check whether the DA is valid or not, and if they choose to do so, they can get an on-chain deal on the result of the DA. If anyone wants to take on the burden of supporting or opposing the validity of that DA, they must do so before the deadline. (Pledge bonds can still be introduced after the deadline, but they are not involved in deciding whether to support the DA.) Once the deadline is reached, all pledge bonds associated with deciding the DA will be known.
If Alice and Bob are pledged on different squares, then one of two things will be true. Either there will be a path moving to the right from one of them to the other – which means that their claims agree with each other – or there will be no such path. If there isn’t a path moving to the right connecting Alice and Bob’s squares, then they must disagree in some way. There will always be a unique point of contention between them – a unique DA on which one is pledged to be valid and the other is pledged to be invalid.
Alice and Bob are preparing a dispute
When a dispute arises between two parties, the system can initiate an interactive dispute resolution protocol between the parties.
As a result of the dispute resolution protocol, one party will be found to be incorrect. That party will lose their pledge deposit. The pledge deposit will be removed from the square it was on. A portion will be given to the other party to the dispute and the rest will be burned.
Multiple disputes can be played simultaneously, but each person who wants to pledge can only be involved in a maximum of one dispute at a time. Because the losing pledge deposit will be wiped out, each dispute reduces the number of disagreements in the system. The party that loses its pledge deposit can repledge if it wishes, but the new pledge deposit will not be able to affect a DA that has passed its pledge period. the result of this is that the dispute will gradually eliminate any disagreement about how to treat the DA after the DA’s pledge period has passed.
Confirmation of results
Once the pledge deadline for a DA has passed and all remaining timely (prior to the scheduled pledge deadline) pledges are located on the same branch of that DA, the system can confirm the outcome of that DA. the DA is either accepted or rejected and the current status moves to the appropriate square to the right of the DA. If the DA is confirmed as valid, its side effects (e.g. payment) will be realized on the chain, and that is how the VM’s status moves forward.
Usually, all parties act honestly because they do not want to lose their interest by pledging to a false statement. In a single chain, only valid DAs will be asserted and no one will pledge on any invalid branch of DAs. In this case, each DA can be asserted as soon as its pledge term expires.
Why it is de-trusted
An important property of Arbitrum Rollup is that it is de-trusted – an honest party can force the VM to run correctly and make progress. Why? Imagine that Alice always pledges on the real branch of each DA, and if the tree is empty, she asserts the DA.
Because Alice is pledged on the real branch, she will win every dispute she joins. If others disagree with Alice, they (a) either lose their pledge margin in a dispute unrelated to a third party, or (b) end up disputing Alice and losing their margin to her. Either way, all those who disagree with Alice will eventually lose their pledge margin. Only those who agree with Alice will survive, so Alice’s path through the tree will end up being the only one to pledge against it in a timely manner – and Alice’s path will be confirmed.
If Alice is honest, the green square will eventually be confirmed regardless of what anyone else does
Because the system is de-trusted in this case, if Alice pledges on a square and she knows that the path to that square is true, 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 the user does not pledge on a path, if she sees several people pledging on that path, and the user personally believes that at least one of those people is honest – the path is as good as the final path.
The benefits of de-trusting results
Why are de-trusted results valuable? This classic example comes from a previous discussion of other rollup protocols. Suppose a VM wants to pay a sum of money to Alice. The payment event is made on an honest path, but it takes a while for the in-chain confirmation to take place on the square where the payment occurs.
The result of de-trusting gives Alice immediate access to her money. If Bob has a sum of money that is not pledged, he can give it to Alice immediately, in exchange for Alice allocating future payments that have not yet been confirmed to Bob (plus paying Bob a minimum fee.) Bob can ensure this by pledging an honest result – and then he waits confidently for payments will eventually be confirmed. It’s not just Bob who can do this. Anyone with a margin 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 obtaining a margin.
The key is that the viability of this market mechanism depends on the end result of de-trusting. If “everyone” already knows that something will eventually be confirmed, then the delay in in-chain confirmation is less of a problem.
This applies not only to payments, but also to other things that VMs do. If a VM will issue a log entry announcing that something happened, then the result of the de-trust means that anyone can be sure that the log entry will be identified on the chain.
Because this system is de-trusted, a malicious actor cannot force an incorrect result. All they can do is slow down the process. Doing so requires them to sacrifice pledge margin, which can be costly if the pledge margin is large.
Suppose someone wants to launch a delayed attack and they are willing to sacrifice their pledge margin. What is the most serious 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. Nor can they prevent honest trusters from gaining the trust of de-trusting when the honest branch is finally confirmed.
All the attacker can do is to pledge on the false branch to delay the on-chain confirmation of the honest path. Each pledge they place creates more contention against the honest actor, who takes a large portion of the attacker’s pledge margin. Once all of the attacker’s pledge margin has been taken, the on-chain process continues.
What if the attacker sets multiple risks on the wrong result? Then these pledge margins will be taken one by one in the dispute. If more than one person is involved in the honest outcome, then all of these people can dispute the attacker and take away the attacker’s pledge margin in parallel. Note that everyone will clearly see what is happening and many will want to get in on the action by putting pledge margin on the honest outcome so they can join in the frenzy of people using the dispute to take the attacker’s pledge margin. If there are K people pledging on the honest side, the attacker will spend K pledge deposits to buy a period of disputed delay. If the attacker places more pledge deposits, this may attract more honest pledgers. This is a bad dynamic for the attacker.
Various optimizations have the potential to reduce the amount of on-chain bookkeeping required to operate the protocol and reduce the cost of on-chain gas.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/what-is-the-reason-for-arbitrum-being-hotly-debated/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.