Important Ethereum Scaling Plan: Optimistic Rollup Status Report (Part 2)

Author: Daniel Goldman Freelance software engineer, technical consultant, writer Translator: Emma, ​​Snow Lu Proofreader: Samuel

Full EVM: Layer 2 Virtual Machine

In order for Layer 2 smart contract computation to remain trustless, there must be a fallback to perform this computation in some form at Layer 1. It follows that for ORU to support the full EVM, Layer 2 needs its own virtual machine that can execute in the EVM base layer, and creating a high-performance implementation for this is not easy. In short, the EVM was not designed to run on its own. You can learn about some of these challenges from the EIP, which also discusses the possibility of modifying the EVM to directly incorporate this functionality, as well as Kelvin Fitcher's overview of this issue in Plamsa.

Therefore, all five full EVM projects created their own modified versions of the EVM for Layer 2 execution. To ensure the reliability and predictability of fraud proofs, the execution of the VMs must be deterministic; that is, it must be possible to accurately reproduce the situation in which the fraud was originally discovered when proving. Therefore, non-deterministic operations must be completely modified or removed, for example, checking block height, difficulty, and timestamps. Similarly, opcodes for contract creation or destruction also need to be removed because this logic is special. Therefore, Layer 1 contracts on ORU may require some minor modifications to the Solidity code before deploying to the ORU chain.

Fraud Proof

All full EVM ORUs share some basic commonalities in how they facilitate fraud proofs: the state of the ORU chain is periodically ordered and committed, as are hashes of operations computed, including those that perform state transitions. (In all practices, the responsibility for generating and verifying state-root commits falls on the operator, not the user.) Fraud proofs use this data in part to show that the steps committed did not actually correctly transform the initial state into the final state.

The main difference between full EVM implementations is the level of interactivity with which they handle these fraud proofs. The ORU essentially must contain enough call data so that fraud can be detected immediately and eventually reach consensus on the main chain. However, the process of executing this fraud proof varies from construction to construction.

In a single-round (sometimes, confusingly, called "non-interactive") fraud proof scheme, fraud can always be proven in a single transaction, or in multiple transactions by a single party. This has the benefit of immediate "dispute resolution", no hassle vectors, so no security deposit from the fraud prover is required, and it's simple to operate. In a multi-round fraud proof, the fraud is obvious, but several interactive steps are required between the fraud prover and the block producer. This has the benefit of lower gas costs (much lower in some cases), and potentially lower on-chain data costs.

Single-round fraud proof

Nutberry, Optimism, and Celer’s ORUs all support single-round fraud proofs. This requires that every transaction must be submitted to a serialized post-state root. In Optimism’s model, which Celer is also directly affected, if fraud is detected, the fraud prover publishes the initial and final state slots of the transaction and lets the main chain fully execute the transaction. (This process is very similar to the stateless client model used to verify Ethereum blocks). Ideally, a transaction only requires a minimal state slot to prove fraud. But in principle, a transaction may require reading a large amount of state data. If the fraud proof requires a lot of data and/or computation that makes it difficult to put it on the main chain block, Optimism can split the proof into multiple transactions (note that these transactions are still submitted by the fraud prover. So in a sense, this extra step does not qualify as "interactive.")

Nutberry's approach is similar, but uses a "gated computing" model to execute contracts. Smart contracts are patched to include checkpoints. In this model, transactions submit multiple, more granular intermediate state roots that may require more data but execute fraud proofs in smaller chunks.

Multiple rounds of fraud proofs

The prover needs to interact with the fraud prover in multiple steps to decide whether the fraud proof is true. According to ORU’s definition, the key is to publish enough data so that any honest participant or observer can determine which party is telling the truth from the beginning, thereby predicting the outcome of the challenge period.

In the case of Interstate One, transactions contain state roots, and when published they commit the Merkle roots to the steps that were executed, rather than to the steps themselves. In a sense, this commitment is a second-order "optimistic" assumption. Only when a validator asks a question does the operator post the EVM message stack in the call data, which the validator can use to briefly prove fraud. In the worst case, this process takes a total of 3 rounds and requires call data that is linear in the number of steps in the transaction involved (compared to single-round fraud proofs, which require linear data in all cases).

The most advanced in terms of increased interactivity is Offchain Labs’ Arbitrum Rollup, which minimizes the on-chain footprint. With Arbitrum, only blocks, not transactions, require state root submissions. As with Interstate, these also involve the computation of the submitted hashes. If two parties make conflicting claims, they enter a dispute, in which they interactively work out a single computational step that was invalidly executed (in principle, there must be at least one invalid step if there is fraud).

They do this by doing an efficient binary search in the stack until the fraud is isolated: that is, the fraud prover walks through the stack, requests the state hash at a point halfway through, then bisects the stack and repeats for the half that is known to be invalid. This process is repeated until only a single invalid operation remains, which is then executed on-chain. Thus, in the worst case, this process takes log(n) steps (where n is the number of operations), and requires minimal Layer 1 computation.

A surprising property of this approach is that the rest of the system does not need to be halted while a dispute is ongoing. Users and block producers can continue to transact as normal. Think of a “dispute” as a branch in a tree of possibilities. Honest users can verify and determine which party is honest, and build on that, understanding how the dispute will ultimately be resolved. Thus, the duration of a dispute does not delay the rest of the system. For more information, see How Arbitrum Rollup Works.

Application-Specific Rollups

The ORU project supports more limited functionality while seeking to optimize around more specific use cases: token payments, decentralized exchanges, private payments, and mass migration. Each of these four protocols is different and will be explored separately.

Fuel (“Bitcoin on the blockchain”)

Fuel is implementing a payment-centric, UTXO-based ORU sidechain with a data model similar to Bitcoin. This design requires balancing some features of smart contracts in favor of simplicity and cheaper verification and fraud proofs. In fact, many of the ideas about the tradeoffs of Fuel vs. full EVM ORU are similar to the tradeoffs of Bitcoin vs. Ethereum.

As with Bitcoin, the state of the Fuel chain is implicitly defined as the set of all unspent transaction outputs; no state root serialization is required. The model that supports succinct fraud proofs is similar to the one originally proposed for Bitcoin by Greg Maxwell in 2014 (and rediscovered separately by John Adler in 2019); transactions are very similar to Bitcoin transactions, but contain an additional data area that specifies where each input is processed. With this data area, all fraud cases (double-spend attacks, fake inputs, etc.) can be proven in a single round with one or two inclusion proofs. In addition to low-cost fraud proofs, the UTXO model also promises higher-performance verification - better state access patterns and parallelism space (compared to the verification EVM execution done synchronously).

Fuel will support ERC20 and ERC721 transfers using a model that mirrors the colored coins proposal for Bitcoin. It will also support certain specialized transaction types, including atomic swaps for HTLCs. The plan is to eventually support a more powerful stateless predicate scripting language similar in functionality to Bitcoin Script.

ANON’s ZK-Optimistic-Rollup (“ZCash on the blockchain”)

Another unique ORU project is ANON’s ZK-Optistic-Rollup, which supports ERC-20 and ERC-721 payment transactions with the same privacy guarantees as ZCash privacy addresses. The design has a lot in common with ZCash itself; funding claims take the form of UTXO-style “issues”; payments generate new issuances and create “nullifiers” that record the issuance to prevent future double spending. Transactions also include ZK-SNARKs, which prove that they meet all validity conditions without actually revealing any details to observers.

To maintain succinct fraud proofs, ZK-ORU has a feature not available in ZCash: revocation notices are stored in a Sparse Merkle tree and updated with each new ORU block. This allows easy proof of membership (committed) and non-membership (uncommitted). As with all other ORUs, computation is optimistically delayed, including the verification of the SNARKS themselves. All fraud cases, including invalid SNARKs, can be proven in a single step.

Note that the burden of generating a SNARK falls on the user; ANON estimates that it will take a client 10-30 seconds to generate a SNARK.

(Also note that despite the similarity in name and components, ZK-Optimistic-Rollup is actually different from ZK-Rollup, which does not necessarily provide privacy, does not use fraud proofs, and uses operator-generated SNARKs to prove its validity. Welcome to crypto.)

ORU Hub at WCL

The ORU operation is intended to become a standard for batching transactions between rollup chains and is a means for users to voluntarily migrate their funds to upgraded contracts.

The operation itself is a simple, account-only payment-based chain that, like Fuel, provides cheap fraud proofs and data verification. The main purpose of this construction is to establish a standard architecture to enable transfers between different chains directly, i.e., without having to withdraw money from one chain and then deposit it again on another chain. This can be achieved by supporting batch deposits and establishing one-way cross-chain connections. As long as the validator on the destination chain detects fraud on the departure chain, the payment can be considered final without any additional delays. This is similar to the research around ETH 2.0 cross shard communication ETH 2.0 cross shard communication logic.

While the primary planned use case is upgradability, another potential use case for this mechanism is migration between separate, distinct, live rollup chains, which requires more research. More details on the exact protocol for rollup inter-chain migration, and the canonical chains that need to be confirmed, are not yet publicly available, but will be linked here at a later date.

IDEX 2.0

What makes IDEX unique is that they use ORU as the best scalable version of a project that is already in production. The IDEX contract is currently running on the mainnet and uses more state modules than any other Ethereum application.

IDEX 2.0’s rollup chain supports order-based decentralized trading and is built around this specific use case. The chain is responsible for executing orders, maintaining user balances, and allowing for the setting of other features such as more advanced order types, automated trading engines, etc.

Validators in IDEX's ORU must have IDEX tokens. Validators submit receipts proving published blocks and are rewarded and/or punished based on their signatures on valid blocks and the issuance of valid fraud proofs (if they choose to accept full "risk" validation). Rewards are paid using a portion of transaction fees and their own tokens (analysis of cryptoeconomic models is beyond the scope of this article; for more information, see the IDEX 2.0 whitepaperDEX 2.0 whitepaper).

In the protocol, block producers only upload the Merkle root of the block as initial input, and only publish the block content to call data when challenged. Since the availability of rollup block data cannot be guaranteed on-chain, this does not fully meet the definition of "Optimistic Rollup" mentioned above; in fact, they call it "Optimizied Rollup". Once the call data is published, fraud can be proven with one or two additional steps. The impact of this approach on trust/security is discussed below.

The third part will be released soon.