Ethereum's important expansion plan: Optimistic Rollup status report (middle)

Author: Daniel Goldman (Daniel Goldmann) free software engineer, technical consultant, author, translator: Emma, Snow Lu proofreading: Samuel

Full EVM: Layer 2 virtual machine

In order to keep Layer 2 smart contract calculations trust-free, there must be a backup solution that performs this calculation in Layer 1 in some form. It can be seen that ORU supports the complete EVM, and Layer 2 needs its own virtual machine, which can be executed in the EVM basic layer. For this reason, it is not easy to create and implement high performance. In short, EVM was not designed to operate on its own. You can learn some of these challenges from the EIP, it also discusses the possibility of modifying the EVM to incorporate this feature directly, and Kelvin Fitcher's overview of this issue in Plamsa.

Therefore, all five complete EVM projects have created their own modified versions of EVM for Layer 2 execution. In order to ensure the reliability and predictability of fraud proofs, the execution of VMs must be deterministic; that is, the proof must be able to accurately reproduce the circumstances in which the fraud was originally discovered. Therefore, non-deterministic operations must be completely modified or deleted, such as checking block height, difficulty, and timestamp. Similarly, the opcodes used for contract creation or destruction need to be deleted because this logic is special. Therefore, before deploying to the ORU chain, the Layer 1 contract on the ORU may require some minor modifications to the Solidity code.

• Bitcoin hardcore OG meets secretly every year, this is their hot topic of discussion this year
• Analysis: XRP price is related to its Twitter activity, and has a stronger correlation with gold than BTC
• Gold, BTC plunged, why did hedging tools fail?

Fraud certificate

All complete EVM ORUs have some basic commonalities in how to promote fraud proofs: the status of the ORU chain is regularly sorted and submitted, as is the hash of the calculation operation, including performing state transitions. (In all practice, the responsibility to generate and verify state-root commits rests with the operator, not the user). The fraud proof used this data to some extent to show that the steps submitted did not actually properly transition the initial state to the final state.

The main difference in full EVM practice is the degree to which they deal with these fraud proofs. The ORU must essentially contain enough call data, so that fraud can be discovered immediately, and finally the consensus of the main chain can be obtained. However, the process of performing this fraud certificate varies by construction.

In a single-round (sometimes confusingly called "non-interactive") fraud proofing scheme, fraud can always be proven in a single transaction or in multiple transactions by a single party. The advantage of this is that it can "settle disputes" immediately, without any troublesome carrier, so it does not require a deposit of fraudulent prover, and it is easy to operate. Fraud is obvious in multiple rounds of fraud proofs, but several interactive steps are required between the fraud proofer and the block producer. The benefit of this is that the cost of Gas is lower (and in some cases lower), and the cost of data on the chain may also be lower.

Single round fraud certificate

ORUs from Nutberry, Optimism, and Celer all support single-round fraud proofs. This requires that each transaction must be submitted to a serialized post-state root. In Optimism's model, Celer is also directly affected. If fraud is detected, the fraud prover will publish the initial state and final state of the transaction (slot) and let the main chain fully execute the transaction. (This process is very similar to the stateless client model for verifying Ethereum blocks ). Ideally, transactions require only a minimum of time to prove fraud. But in principle, transactions may need to read a lot of state data. If fraud proof requires a lot of data and / or calculations and it is difficult to place it on the main chain block, Optimism can split the proof into multiple transactions (note that these transactions are still submitted by fraud provers. Therefore, from In a sense, this extra step is not eligible for "interaction.")

Nutberry's approach is similar, but uses a " gated computing " model to execute contracts. Smart contracts are patched to include checkpoints. In this model, the transaction submits multiple more detailed intermediate state roots, which may require more data, but perform fraud proofs in smaller blocks of data.

Multiple rounds of fraud certification

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

In the Interstate One example, the transaction contains a state root, and the Merkle root is submitted to the corresponding step when it is published, rather than the step itself. In a sense, this submission is a secondary "optimistic" assumption. The operator will post the EVM message stack in the call data only when the verifier asks a question, and the verifier can use this information to briefly prove fraud. In the worst case, this process takes a total of 3 rounds and requires that the call data is linearly related to the number of steps in the transaction involved (compared to a single round of fraud proof, linear data is required in all cases).

The most advanced in terms of interactivity enhancement is Offchain Labs' Arbitrum Rollup, which can minimize the footprint on the chain. With Arbitrum, only blocks, not transactions, need to submit a state root. Like Interstate, these include the calculation of the submitted hash value. If the two parties make conflicting claims, they will enter into a dispute; in that dispute they will interactively find a single calculation step for invalid execution (if fraud, there must be at least one invalid step in principle).

They perform an effective binary search on the stack until the fraud is isolated: that is, the fraud prover requests the state hash at a point halfway through the stack, then bisects the stack and repeats Known invalid half. This process is repeated until there is only one invalid operation remaining, and then the operation is performed on-chain. Therefore, in the worst case, this process requires (n) log steps (where n is the operand) and requires a minimum of Layer 1 calculations.

One surprising feature of this approach is that, although the dispute is ongoing, there is no need to suspend the rest of the system. Users and block producers can continue to trade as usual. Think of "controversy" as a branch in the tree of possibilities. Honest users can verify and determine which party is honest, and build on that to understand how the dispute will ultimately be resolved. Therefore, the duration of the 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 restricted functions while seeking to optimize around more specific cases: token payments, decentralized transactions, private payments, and large-scale migrations. These four agreements are all different and will be discussed 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 needs to balance some functions of smart contracts to facilitate simplicity and cheaper verification and fraud proofs. In fact, many ideas about the trade-off between Fuel and the full EVM ORU are similar to the trade-off between Bitcoin and Ethereum.

Like 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 supporting concise fraud proofs is similar to the model originally proposed for Bitcoin by Greg Maxwell in 2014 (and discovered again by John Adler alone in 2019 ); the transaction is very similar to the Bitcoin transaction, but contains an additional A data area that specifies the processing location for each input. With this data area, one or two inclusion proofs can be used to prove all fraud cases (double payment attacks, false inputs, etc.) in a round. In addition to low-cost fraud proofs, the UTXO model is also expected to enable higher performance verification-better state access patterns and parallel space (compared to synchronously completed verification EVM execution).

Fuel will use a model to support ERC20 and ERC721 transmissions, which will reflect the colored coins proposal for Bitcoin. It also supports certain special transaction types, including atomic swaps of HTLCs. The plan eventually supports a more powerful stateless predicate scripting language that functions similarly to Bitcoin scripts.

ANK's ZK-Optimistic-Rollup ("ZCash on the blockchain")

Another unique ORU project is ANK's ZK-Optistic-Rollup, which supports E RC-20 and ERC-721 payment transactions and has the same privacy guarantee as ZCash's private address. This design has a lot in common with ZCash itself ; funding claims are in UTXO-style “issues”; new issuances and created “nullifiers” are generated by payments, recording that the issuance is used to prevent future double spending. The transaction also includes ZK-SNARK, which proves that it meets all validity conditions without actually revealing any details to the observer.

In order to maintain a concise proof of fraud, ZK-ORU has features not found in ZCash: revocation notifications are stored in the Sparse Merkle tree and updated with each new ORU block. This makes it easy to prove membership (submitted) and non-membership (unsubmitted). As with all other ORUs, calculations are optimistically delayed, including the validation of SNARKS itself. All fraud cases, including invalid SNARK, can be proven in one step.

Note that the responsibility for generating SNARKs rests with the user; ANON expects that a customer will spend 10-30 seconds generating SNARKs.

(Also note that despite similar names and components, ZK-Optimistic-Rollup is actually different from ZK-Rollup, which does not necessarily provide privacy protection, does not use proof of fraud, and uses operator-generated SNARK to prove its Effectiveness. Welcome to cryptocurrencies.)

WCL's ORU Hub

This ORU operation is intended to be a 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 chain. Like Fuel, it provides cheap fraud proofs and data verification. The main purpose of this structure is to establish a standard architecture so that it can be directly transferred between different chains, that is, it is not necessary to take out the money from one chain and then save it to another chain. This can be achieved by supporting bulk deposits and establishing cross-links between one-way chains. As long as the verifier on the destination chain finds fraud on the departure chain, the payment can be considered as the final payment without any additional delay. This is similar to the research of ETH 2.0 cross shard communication logic around ETH 2.0 cross- shard communication .

Although the main planned use case is scalability, the potential other use cases for this mechanism are to migrate between separate, different, real-time rollup chains, and we need to do more research on this. Regarding the precise agreement of the rollup chain migration, and the specification chain to be confirmed, more details have not been made public, and a link will be attached here in the future.

IDEX 2.0

IDEX is unique in 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 IDEX contract uses more state modules than any other Ethereum application. .

IDEX 2.0's rollup chain supports registered order-style decentralized transaction functions and is built around this specific use case. This chain is responsible for executing orders, maintaining user balances, allowing other functions to be set, such as more advanced order types, automated trading engines, etc.

The validator in IDEX's ORU must have an IDEX token. Validators submit a receipt to prove the published block and are rewarded and / or penalized based on their signature on a valid block and the issuance of a valid fraud certificate (if they choose to accept full "risk" verification). Rewards are paid using a portion of transaction fees and own tokens (analysis of cryptoeconomic models is beyond the scope of this article; for more information, see the IDEX 2.0 white paper DEX 2.0 whitepaper ).

In the protocol, the block producer only uploads the Merkle root of the block as an initial investment, and only publishes the block content to the call data when in doubt. Since the availability of rollup block data cannot be guaranteed on the chain, this does not fully meet the definition of "Optimistic Rollup" described above; in fact, they call it "Optimized Rolled Optimized ". Once call data is published, fraud can be proven in one or two additional steps. The impact of this method on trust / security is discussed below.

The third part will be launched soon.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!