Ethereum's Important Expansion Plan: Optimistic Rollup Status Report (Middle)
Complete EVM: Layer 2 Virtual Machine
In order for Layer 2 smart contract computations to remain trustless, there must be a fallback to performing such computations at Layer 1 in some form. It can be seen that ORU supports a complete EVM, and Layer 2 needs its own virtual machine, which can be executed in the basic layer of EVM, and the creation and implementation of high performance for this is not an easy task. In short, the EVM was not designed to run on its own. You can download fromEIPRead about some of these challenges in , which also discusses the possibility of modifying the EVM to incorporate this functionality directly, andKelvin Fitcher's overview of this issue in Plamsa。
Therefore, all five full EVM projects create their own modified versions of the EVM for Layer 2 implementation. To ensure reliable and predictable fraud proofs, the execution of VMs must be deterministic; that is, at the time of proof it must be able to accurately reproduce the circumstances under which the fraud was originally discovered. Therefore, non-deterministic operations must be completely modified or removed, for example, checking block height, difficulty and timestamp. Likewise, opcodes for contract creation or destruction also need to be removed, since this logic is special. Therefore, the Layer 1 contracts on ORU may require some minor modifications to the Solidity code before being deployed to the ORU chain.
proof of fraud
All full EVM ORUs share some basic commonality in how they facilitate fraud proofs: the state of the ORU chain is periodically sorted and committed, as is the hash of computation operations, including performing state transitions. (In all practices, the commit responsibility for generating and verifying the state-root falls on the operator, not the user). Fraud proofs use this data in part to show that the steps submitted did not actually correctly transform the initial state into the final state.
The main difference in full EVM practice is how interactively they handle these fraud proofs. The ORU must essentially contain enough call data so that fraudulent behavior can be detected immediately and eventually get the consensus of the main chain. However, the process for performing this fraud proof varies from construction to construction.
In single-round (sometimes, confusingly called "non-interactive") fraud proof schemes, fraud can always be proven in a single transaction, or in multiple transactions by a single party. The advantage of this is that disputes can be "resolved" instantly, there are no hassle vectors, so no bond is required for fraudulent provers, and it's simple to operate. Fraud is obvious in multiple rounds of fraud proofs, but several interaction steps are required between the fraud prover and the block producer. The advantage of this is that the gas cost is lower (in some cases lower), and the data cost on the chain may also be lower.
Single Round Fraud Proof
Nutberry, Optimism, and Celer's ORUs all support single-round fraud proofs. This requires that every transaction must be committed to a serialized post-state root. In Optimism's model, Celer is also directly affected, and if fraud is detected, the fraud prover publishes the transaction's initial state and the time (slot) of the final state, and lets the main chain fully execute the transaction. (This flow is similar to the stateless client used to validate Ethereum blocksstateless clientmodels are very similar). Ideally, a transaction would require only a minimal amount of state time (slot) to prove fraudulent. But in principle, transactions may need to read large amounts of state data. If a fraud proof is data and/or computationally intensive and hard to put on the main chain block, then Optimism can split the proof into multiple transactions (note that these transactions are still submitted by the fraud prover. So, from In a sense, this extra step doesn't qualify as "interactive".)
Nutberry's approach is similar, but uses a "gated calculation (gated computing)” model to execute contracts. Smart contracts are patched to include checkpoints. In this model, transactions commit to multiple more granular intermediate state roots, possibly requiring more data, but in smaller chunks Execute fraud proof.
Multiple rounds of fraud proof
The prover needs to interact with the fraud prover in multiple steps to decide whether multiple rounds of fraud proofs are true. The key, as defined by ORU, is to publish enough data that any honest participant or observer can determine from the outset which side is telling the truth, thereby predicting the outcome of the challenge period.
In the case of Interstate One, the transaction contains a state root, and the Merkle root is submitted to the corresponding execution step when publishing, rather than to the step itself. In a sense, this submission is a secondary "optimistic" assumption. Only when the verifier asks a question does the operator post the EVM message stack in the call data, which the verifier can use to briefly prove fraud. In the worst case, this process takes a total of 3 rounds and requires call data linear in the number of steps in the transactions involved (compared to single-round fraud proofs which require linear data in all cases).
State-of-the-art in enhancing interactivity is Offchain Labs’ Arbitrum Rollup, which minimizes the on-chain footprint. With Arbitrum, only blocks, not transactions, need to be committed to the state root. Like Interstate, these also include the calculation of commit hashes. If two parties make contradictory claims, they enter a dispute in which they interactively find out a single computational step that was performed invalidly (if there is fraud, at least one invalid step must in principle exist).
They do this by doing an efficient binary search in the stack until the fraud has been isolated: i.e., the fraud prover walks through the stack, requests a state hash at a point halfway, then bisects the stack and repeats half known to be invalid. This process is repeated until there is only one invalid operation left, which is then executed on-chain. Therefore, in the worst case, this process requires (n) log steps (where n is the number of operands) and requires minimal Layer 1 computation.
A surprising property of this approach is that there is no need to suspend the rest of the system despite the ongoing dispute. Users and block producers can continue to transact as usual. "Controversy" can be thought of as a branch in a tree of possibilities. Honest users can verify and determine which party is honest, and build on that to see how the dispute will ultimately be resolved. Therefore, the duration of the dispute does not delay the rest of the system. For more information, seeHow Arbitrum Rollup Works。
Application Specific Rollups
The ORU project supports more restricted functionality while seeking to optimize around more specific use cases: tokenized payments, decentralized exchanges, private payments, and mass migrations. Each of the four protocols is distinct and will be explored separately.
Fuel ("Bitcoin on the Blockchain")
Fuel is implementing a payments-centric, UTXO-based ORU sidechain with a data model similar to Bitcoin. This design needs to balance some smart contract features in favor of simplicity and cheaper verification and fraud proof. In fact, many of the thoughts on Fuel vs. full EVM ORU tradeoffs are similar to Bitcoin vs. Ethereum tradeoffs.
Like Bitcoin, the state of the Fuel chain is implicitly defined as the collection of all unspent transaction outputs; no state root serialization is required. Models supporting succinct fraud proofs with Greg Maxwell in 2014Greg Maxwell in 2014The model originally proposed for Bitcoin is similar (and found again in 2019 by John Adler aloneand independently rediscovered by John Adler in 2019); Transactions are very similar to Bitcoin transactions, but contain an additional data field that specifies where each input is processed. With this data area, one or two inclusion proofs can be used to prove all cases of fraud (double spending attacks, fake inputs, etc.) in one round. In addition to low-cost fraud proofs, the UTXO model also promises higher performance verification - better state access patterns and parallelism (compared to synchronously done verification EVM execution).
herehere）。
ANON's ZK-Optimistic-Rollup ("ZCash on the Blockchain")
herehere); Fund claims take the form of UTXO-style "issuances"; payments result in new issuances and create "nullifiers" that record that the issuance is used to prevent future double spending. Transactions also include ZK-SNARKs that can be proven to satisfy all validity conditions without actually revealing any details to observers.
To maintain succinct fraud proofs, ZK-ORU has a feature not found in ZCash: revocation notices are stored in a Sparse Merkle tree and updated with each new ORU block. This makes it easy to prove membership (committed) and non-membership (uncommitted). As with all other ORUs, computations are optimistically delayed, including the verification of the SNARKS itself. All cases of fraud, including invalid SNARKs, can be proven in just one step.
Note that the burden of generating the SNARK falls on the user; ANON expects a client to spend 10-30 seconds generating the SNARK.
(Also note that despite similar names and components, ZK-Optimistic-Rollup is actually distinct from ZK-Rollup in that it does not necessarily provide privacy protection, does not use fraud proofs, and uses operator-generated SNARKs to prove its Validity. Welcome to cryptocurrency.)
WCL's ORU Hub
This ORU operation is intended to be the standard for batch transactions between rollup chains, and is a means for users to voluntarily migrate their funds to upgrade contracts.
The operation itself is a simple, account-only payment-based chain that, like Fuel, provides cheap fraud proof and data validation. The main purpose of this construction is to establish a standard architecture to be able to transfer directly between different chains, i.e. without having to withdraw funds from one chain and re-deposit to another chain. This can be achieved by supporting batch deposits and establishing unidirectional cross-connects between chains. As soon as a validator on the destination chain detects fraud on the originating chain, the payment can be considered final without any additional delay. This is in line with research around ETH 2.0 cross-shard communicationETH 2.0 cross shard communicationThe logic is similar.
While the main planned use case is upgradability, a potential other use case for this mechanism is migration between separate, distinct, live rollup chains, and we need to do more research on this. More details about the precise protocol for inter-chain migration of rollups, and the canonical chains that need to be confirmed, are yet to be made public, and will be linked here in the future.
IDEX 2.0
The unique feature of IDEX is that they use ORU as the best expansion version of the project that has been put into production. The IDEX contract is currently running on the main network. The state module used by the IDEX contract (state) than any other Ethereum application.
The rollup chain of IDEX 2.0 supports the registration order type decentralized exchange function, and is built around this specific use case. The chain is responsible for executing orders, maintaining user balances, allowing setup to occur other functions such as more advanced order types, automated trading engines, etc.
Validators in IDEX's ORU must have IDEX tokens. Validators submit receipts attesting to published blocks and are rewarded and/or penalized 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 own tokens (the analysis of the cryptoeconomic model is outside the scope of this article; for more information, please refer to the IDEX 2.0 white paperDEX 2.0 whitepaper）。
In the protocol, block producers only upload the Merkle root of the block as an initial input, and only publish the block content to the call data when challenged. Since the availability of rollup block data cannot be guaranteed on-chain, this does not quite fit the definition of "Optimistic Rollup" above; in fact, they refer to it as "Optimized RollupOptimized Optimistic Rollup’. Once the call data is released, there is an additional step or two to prove fraud. The trust/security implications of this approach are discussed below.
Author: Daniel Goldman (Daniel Goldman) freelance software engineer, technical consultant, author
Proofreading: Samuel
Proofreading: Samuel
