NewsFlash Articles Data Fundraising BlockBeats Pro

Arbitrum's secret weapon: Interactive fraud proof

Read this article in 9 Minutes

The key principle behind the interactive proof is that if Alice and Bob have a dispute, Alice and Bob should do as much off-chain work as possible to resolve the dispute, rather than burden the L1 contract.

原文标题：《 Interactive Fraud Proofs: Arbitrum's Secret Sauce 》

原文来源： Offchain Labs Medium

原文作者： Offchain Labs

Ah Jian is a fan of Ethereum

Arbitrum One has been open in the main network, we plan to launch a series of articles, explain the internal components of Arbitrum. This article is excerpted from & NBSP; Inside Arbitrum, the original in-depth explanation of the working principle of Arbitrum.

Around & have spent Optimistic Rollups, the most important design decision is how to resolve controversy. Suppose Alice asserts that Rollup will produce a result, but Bob disagrees, how does the protocol decide, and who submits the result?

There are basically two types of processing methods: interactive proof or re-execution of the transaction. Arbitrum chose interactive proof, we think this method is more efficient, but also more flexible. Other design of Arbitrum also basically follow this principle.

Since 2014, we have been developing interactive fraud proof (and Arbitrum). The basic mechanism is described in NBSP; In a paper published in 2018, although now we've made a lot of upgrades.

Interactive proof

The idea of the interactive proof is to have Alice and Bob participate in a turn-based protocol guided by an L1 contract, resolving their differences using the minimal overhead required by any L1 contract.

Arbitrum's method is based on the analysis of disputes. If Alice's assertion involves N execution steps, let her expose two assertions involving N/2 steps each, and let Bob choose one to challenge. That cut the size of the dispute in half. This process continues, with each turn reducing the size of the dispute by half until the scope of the dispute becomes an execution step. Note that up to this point, the L1 boot contract does not have to consider what is actually being performed. Only when the dispute is narrowed down to a single execution step does the L1 bootstrap contract need to understand what instruction that step is to execute and whether Alice's assertion about that step is true to resolve the dispute.

Reexecute transaction

Another option is to have a Rollup block with a status hash assertion after every transaction in the block. Then, in the disputed case, the L1 guidance contract will simulate the execution of the entire transaction to see if the result is consistent with Alice's assertion.

Why is interactive proof better?

We strongly believe that interactive proof is a better approach for the following reasons.

In the optimistic case, interactive proof is more efficient. Because interactive proofs can resolve disputes larger than one transaction, a rollup block can contain only one assertion about the resulting state of the chain after all the contents of that block are executed. In contrast, the re-execute method requires that each transaction within the block be followed by a state assertion. If there are hundreds or thousands of transactions in a rollup block, there will be a significant difference in the space footprint of the L1 block between the two methods -- a major part of the rollup cost.

In the pessimistic case, interactive proof is also more efficient: if there is a dispute, the L1 guidance contract simply checks that Alice and Bob are "going in the right direction", such as Alice really splitting the n-step assertion into two half-step assertions. (The bootstrap contract doesn't have to calculate the correctness of Alice's assertion, Bob does it, down the chain.) You just need to re-execute an instruction. In contrast, in the re-execute transaction mode, the L1 bootstrap contract needs to simulate the execution of the entire transaction.

Higher transaction level gas limit: Interactive proof can get rid of Ethereum's gas limit for a single transaction; Even if the gas consumption of a transaction is too large to be put into the Ethereum block, it is still possible to put into the Arbitrum block. Rollup's Gas Limit certainly can't be infinite, but it can still be much larger than what the Ethereum main chain allows.

As far as Ethereum is concerned, the only drawback of large-gas-capacity Arbitrum transactions is that it may need to run more interactive steps (again, only in controversial cases). In contrast, for rollup transactions in re-execution mode, the gas limit must be smaller than ethereum's block gas limit, otherwise the transaction cannot be simulated within an Ethereum transaction (and simulated execution consumes more gas than performing it directly in Ethereum).

No limit on contract size: Interactive proof does not require the creation of an Ethereum contract for every L2 contract, and therefore does not require the contract to conform to the limitations of the Ethereum contract. For the disputed contract of Arbitrum, the operation of deploying a contract on L2 is also a combination of a series of calculation processes, which is no different from other operations. In contrast, the SIZE of the L2 contract in re-execution mode is smaller than what can be allowed on the Ethereum main chain, because to simulate the execution of a contract requires the contract to be instrumentable, and the copied code must be able to fit into an Ethereum contract.

Greater implementation flexibility. Interactive proofs allow for greater implementation flexibility, for example, by adding instructions that do not yet exist in EVM. The necessary functionality is nothing more than the ability to verify a single step on Ethereum. The re-execution mode is strictly constrained by EVM.

The interactive proof method is the core of the design of Arbitrum

Most of the design of Arbitrum is opportunity-driven opened by the interactive proof method. If you are wondering why they exist when learning the characteristics of Arbitrum, there are two simple thinking directions: "is this feature used to support interactive proof?" "And" How is this feature made possible using interactive proofs?" Most of the "why" of Arbitrum are related to interactive proof.