An article to understand the expansion plan of Ethereum: Rollup working principle

Participants of the protocol can make an arguable assertion (DA), which claims that, starting from a certain state hash, under some technical preconditions, a virtual machine can perform a specified number of computational steps to obtain a specified new The state is hashed, and the virtual machine makes the specified payment and emits the specified log event during the calculation. DA may be valid (i.e. real) or invalid. The party making the DA will be required to make a deposit for the validity of the DA. (More on stakes and how they work below.)

As shown in the diagram above, a disputable assertion creates a logical decision point that the protocol ultimately resolves. If the DA is valid, the system will enter a new state in the upper right corner, with a new state hash, and with the side effects (payments and logs) specified in the DA. Or on another branch, the DA is invalid, it is rejected and the status is unchanged.

secondary title"Old Arbitrum protocol"The original Arbitrum protocol processes arguable assertions one at a time. A party would propose a DA, and then there would be a challenge period during which anyone could challenge the DA. If no one challenges, the DA is confirmed; otherwise, the dispute protocol is run, and the DA is canceled (for safety, in case the proposer and challenger collude

disputed outcome).

This is simple, but has two drawbacks. First, since there can only be one lawsuit at a time, the rate at which the VM can progress will be limited. Essentially, progress must be halted during each challenge period. Second, a malicious party can freeze a virtual machine by deliberately challenging all DAs made for that virtual machine. This will cost the attacker a series of stakes, but if they are willing to pay the price, they can keep progress for a long time in at least some cases.

first level title"new and improved"text"pipelining"。

unreliable end result

How did that happen? Let's dig into the new protocol...

image description

stake

secondary title

Another important part of the protocol is staking. Anyone can place a stake on a square in the tree. By staking a square, you are asserting that the square will eventually be confirmed by the protocol. In other words, you are asserting that you have taken the correct branch for every DA on the path from the current state to the square you are staking. If you are wrong, you can expect to lose your stake.

text"The staking action cannot be undone. You can move your stake to the right -- choosing up or down at each branch point -- but you can't move your stake to the left, as that would amount to undoing your previously made stake commitment."The party making an arguable assertion needs to be in the DA's

DA is valid"The heir goes to staking. Typically, they can satisfy this requirement by moving the existing bet to the right, placing it on the desired succession square. In rare cases, if they are unable to do so, they may place an additional stake on the desired square. But beware, they'll be staking on two paths that don't agree, so they'll end up losing at least one of the two stakes - contradicting yourself isn't wise). )"One more detail about the bet: if the square you bet on is confirmed and becomes accepted history, you can choose to get your bet back. This means that if you are correct, you can leave your bet in place and wait for the system

catch up"You, then you get your bet back."At this point, you might be concerned that the dendrogram of possibilities is going to be very large and 'leafy'. This cannot happen in practice because it would require multiple parties to bet on mutually inconsistent outcomes. Only one of them can be right, and everyone else loses their stake. More likely, this

Effectively a chain of DAs, one after the other, and all bets are on the same outcome.

We need the system to reach a decision on each contestable assertion before it takes too long. So, when a DA is added to the chain, creating a branch point, there will be a deadline associated with that DA. This deadline is far enough in the future that if you choose to do this, you will have time to check whether the DA is valid, and get a transaction on the chain to bet on the result of this DA. If someone wants to commit a bet for or against the validity of this DA, they must do so by the deadline. (After the deadline, interests can still be introduced, but they are not involved in deciding for or against the DA.) Once the deadline is reached, all interests involved in deciding the claim will be informed.

dispute

dispute

If Alice and Bob are in different locations, then one of two things is true. Either there is a path to the right from one of them to the other -- implying that their claims are aligned -- or there is no such path. If there isn't a right-moving path connecting Alice's and Bob's squares, then they must disagree on something. There will always be a unique point of contention between them - a unique DA for which one of them bets that the DA works and the other that it doesn't.

Whenever a dispute arises between two parties, the system can initiate an interactive dispute resolution protocol between the two parties. I don't have space to describe the dispute resolution protocol here - suffice it to say that it's a two-stage interactive protocol similar to what we've described in other Arbitrum documents.

Multiple disputes can be in progress at the same time, but each punter can only participate in a maximum of one dispute at a time. Each dispute reduces the amount of disagreement in the system because the loser's bet is wiped out. The party who lost the bet can re-bet if they wish, but the new bet will not be able to affect the DA whose betting period has passed. The effect of this is that after a DA's staking period has passed, the dispute will gradually iron out any disagreement about how that DA should be handled.

verify results

verify results

When a DA's betting deadline has passed, all remaining timely (before betting deadline) bets are on the same branch of that DA, and the system can confirm the outcome of that DA. The DA is accepted or rejected and the current status moves to the corresponding box to the right of the DA.

In general, parties will act honestly because they do not want to lose their bets by betting on bogus claims. Only valid DA will be asserted, and no one will bet on invalid branches of any DA on a single chain. In this case, each DA can be confirmed immediately after its staking period expires.

why it is trustless

why it is trustless

An important property of Arbitrum Rollup is that it is trustless - an honest party can force the virtual machine to behave correctly and make progress. To see why, imagine that Alice always bets on the true branch on every DA, and if the tree is ever empty, she asserts DA.

Because Alice is staking on the real tree, she wins every dispute she gets into. If others disagree with Alice, they either (a) lose their stake in an unrelated dispute with a third party, or (b) end up in a dispute with Alice and lose their stake to her. In either case, everyone who disagrees with Alice will eventually lose their stake. Only stakes that agree with Alice will survive, so Alice's path on the tree will eventually be the only one with a timely stake -- and Alice's path will be confirmed.

Because the system in this way is untrustworthy, if Alice is bet on a square, and she knows the path to that square is real, then Alice can be sure that the square she is on will eventually be confirmed. For Alice, that path appears to be final.

Even if you are not bet on a path, if you see several people bet on it, and you believe at least one of those people to be honest, then you can be sure that path will eventually be confirmed -- just For you, that path is the ultimate path.

The benefits of not trusting finality

Why is distrust of results valuable? The classic example comes from the previous discussion of other rollup protocols. Suppose a virtual machine wants to pay Alice. The payment event is on the honest path, but it will be a while before the block where the payment occurs is confirmed on-chain.

text"The result of trustlessness is to provide Alice with a way to get money immediately. If Bob has money to pay immediately, he can immediately give the money to Alice, in exchange for Alice assigning future unconfirmed payments to Bob (plus a minimum fee paid to Bob). Bob would only want to do this if he can be sure that the payment will actually happen. Bob can determine this by betting on an honest outcome—then he would have full confidence that the payment will eventually happen. It's not just Bob who can do this, anyone with funds can lend him. Anyone with funds can lend funds to Alice and others like her in the same way. These people can compete with each other by offering lower fees, making it cheaper for Alice to get funds immediately."The key point is that the viability of such a market mechanism depends on the outcome of trustlessness. if

This is true not only for payments, but also for other things that virtual machines do. If a virtual machine were to emit a log entry announcing that something had happened, the trustless result means that anyone can act with certainty that the log entry will be confirmed on-chain.

delayed attack

delayed attack

Because this system is trustless, bad guys cannot force wrong results. What they can try to do is slow down the progress. Doing so requires them to sacrifice stakes, which can be costly if the stakes are significant.

Let's imagine that someone has an incentive to launch a delay attack, and they're willing to sacrifice a stake. What's the worst damage they can do?

The first thing to note is that bad actors cannot prevent honest parties from continuing to build honest paths. And they also cannot prevent honest parties from gaining trustless confidence in the process of finalizing the honest branch.

What if the attacker places multiple bets on bogus outcomes? Then these bets must be won one by one in the dispute. If there are multiple people betting on an honest outcome, those people can all enter into disputes against the attacker while trying to take down the attacker's bet. And note, it will be clear to everyone what is going on, and many will want to get in on it, betting on the real outcome so they can join the feeding frenzy that uses disputes to grab stakes from attackers. If there are K people betting on the honest side, then the attacker will spend K stakes to buy one dispute period delay. If the attacker bets more, it will likely attract more honest bets. This is a bad dynamic for an attacker.

optimization

Various optimizations can be made to reduce the amount of on-chain bookkeeping required to operate the protocol, reduce on-chain gas costs, and make it easier to stage a beneficial feeding frenzy against latency attackers. I won't delve into these optimizations here, this post is long enough.

the way forward

first level title