Optimism, Arbitrum and Metis Layer2 Solution Analysis

2021-06-15 17:23

Read this article in 24 Minutes

AI summary

View the summary

原文标题：《 The Optimistic Layer 2 Wars 》

原文来源：编译实验室 TranspilerLab.DAC

Originally written by Alfonso de la Rocha

Original text: Perry Wang

In the first half of this year, the new bull market in the cryptocurrency market, the rising popularity of NFT, the continued ferment of Defi craze and the continuous stack of Defi Lego made the price of Ethereum go up continuously, while the network usage also reached a new high. But it has also led to many "unpleasant" consequences for dApp developers in the Ethereum ecosystem, with the overburdened network leading to high Gas costs. Because of this, the Layer 2 (L2) scaling solution has been transformed overnight from a "can have" feature to a "most urgent need" to keep the DAPP running in terms of performance and cost.

Fortunately, we have several solid L2 platforms and protocols in place to help us do this. One of the infrastructures to build the L2 solution is the Optimistic Rollup. Many projects are built on this technology, but how to choose an L2 solution based on Optimistic Rollup that best meets our needs? This paper attempts to answer this question by comparing three promising L2 solutions based on Optimistic Rollups. Let's get right down to business!

What is Optimistic Rollup?

In order to be able to compare different L2 solutions based on Rollup, we first need to briefly describe what an Optimistic Rollup is. Rollup is a solution for bundling (or "Rollup") side chain or out-of-chain transactions into a single transaction, which is then committed to Layer 1 (L1). In order to protect all of these bundled transactions and make them individually verifiable, encryption proofs are generated in the bundling.

One requirement for Rollup to be effective is to have some sort of ethereum compatible stand-alone blockchain with a reduced number of nodes or high-performance add-on features that handle signature verification, contract execution, etc. Transactions are then bundled and submitted to the Ethereum mainchain, and the independent blockchain verifies the validity of those transactions. L2 Rollup side chains are responsible for validation and contract execution, while L1 specializes in storing immutable transaction data.

In the Optimistic Rollup solution, participants are "Optimistic" about the effectiveness of the trades being executed in the side chain. The aggregator commits side chain transactions to the main chain without additional computation. How do we know that side chain transactions are actually valid? Optimistic Rollup uses proof of fraud to ensure that all transactions are legitimate. If someone notices a fraudulent transaction from the aggregator, they can challenge this Rollup by sending a fraudulent proof to run the transaction calculation and verify its validity. This means that, unlike in other Rollup solutions such as ZK-Rollup, where validation is performed on every transaction, we only perform proof calculations when we suspect that the transaction is fraudulent. This significantly reduces Gas costs compared to the ZK-Rollup solution and opens the door to a 10-fold or even 100-fold jump in transaction throughput. After the proof of fraud is confirmed, the block is determined to be invalid. The chain in L2 can be rolled back and reverted to the previous block that did not contain fraud.

A comparative presentation of the relevant solutions

After a brief introduction to Rollup, we have all the basics we need to compare L2 solutions. For comparison purposes, I chose three of the L2 solutions that, in my opinion, provide a more interesting set of features for dApp developers (which I would personally consider deploying in my own apps).

They all (more or less) share the same module: an etherium-compatible virtual machine (VM) for running users' Solidity contracts in L2; The collator/aggregator is responsible for batching the set of transactions from L2 and committing them on L1; A set of L1 smart contracts for orchestrating interactions and delivering data from L2; Peer to peer transactions can use a variety of different proof of fraud to refute invalid or bogus transactions submitted by the aggregator; And use pledges to coordinate the incentives and economic activities of the L2 system.

Despite sharing the same module, the three solutions differ greatly in the way they implement the Rollup protocol. Let's speed up our comparison by examining each in detail.

Optimism:

Optimism takes advantage of all existing tools in the Ethereum ecosystem and modifies them to implement their Optimistic protocol and L2 solution.

VM: Their L2 VM is Optimistic VM (OVM), which is a modified variant of the Ethereum VM (EVM) that replaces the scenario-specific EVM opcodes with new opcodes suitable for L2 contract execution. The VM acts as a sandbox environment, guaranteeing the execution of deterministic smart contracts and state transitions between L1 and L2.

Client: Optimism Also modifies the widely used Ethereum client Geth so that it can be used as a client for the L2 chain. This client modifies the messages so that other L2 clients can understand them, and it includes all the processes needed to sort and batch the transactions to build the Rollup.

Rollup build: For its Rollup build, Optimism uses the Geth client as a single collator. In Optimism, the transaction data is compressed and then sent to the Sequencer entryPoint contract on L2. The collator is responsible for "Rollup" these "batch" transactions and publishing the data to Ethereum, providing data availability, in which case even if the collator disappears, a new collator can be started to pick up where it left off. Anyone can send a new transaction to L1 and these transactions are added to the L1 contract, which acts as a "append-only log" for each L2 transaction.

Validation: For each transaction published by the collator, the verifier is responsible for downloading the transaction and applying it to its local state. If everything matches, the verifier does nothing, but if it doesn't, the verifier needs to commit all valid previous transactions on the chain and reexecute any published state roots to show that the published state roots are actually incorrect. If fraud validation is successful, the faulty status and batch is removed from L1.

Economic model: EPOC's batch scheduler needs a smart contract called a bond manager to mark as collated for each time period. To become a collator for an existing mortgage, you need to pledge a fixed amount of ETH in the contract. Each time a collator detects fraud, its pledged assets are reduced. The collator's pledged assets can be taken back after 7 days of storage, and the batch of the collator stops at this point, and validation is no longer possible because it is no longer possible to reduce its assets. If the fraud is successfully proved, a certain percentage (X%) of the proposer's deposit will be destroyed and the remaining (1-x)% will be distributed pro rata to each user who provides the data for the proof of fraud. This economic model prevents rogue behavior on the collator, but does not address the possibility that a verifier tries to send a large number of fraudulent proofs in a large number of different batches to the L1 chain (forcing a large number of L1 calculations).

Arbitrum:

VM and client: Arbitrum implements the Arbitrum Virtual Machine (AVM). The AVM is responsible for running L2 contracts and saving their state. The state of the VM is organized into a Merkle tree and executed in the state transitions generated by this Merkle tree. Arbitrum also implements its own custom L2 client.

Rollup build: Arbitrum orchestrates its Rollup protocol using a single on-chain contract. At any point in the protocol, there is some VM fully recognized and final state, for example, its hash value is stored on the chain. A new transaction in L2 triggers a state update of the Merkle tree for each state in the storage chain. To verify the state of the store, participants in the protocol can present what is called a disputed assertion (DA) in Arbitrum to prove that, starting with a state hash, the VM is able to perform a specified number of computational steps, resulting in a specified new hash state (and its corresponding contract execution, payment, and event emission). The DA may end up being valid (that is, calculated successfully) or not. If the DA is valid, the system enters a new state, and there will be a new state hash in the tree, along with the corresponding side effects (payment and log) specified in the DA. If DA is invalid, the branch is rejected and the state remains the same. Each state can have at most one DA following it. If a DA has no follow state, then anyone can create a DA that follows it, creating a new branch point. The result will be a tree of future possibilities. So we can see that while Optimism uses multiple L1 smart contracts in L2 commit state and execution, the L1 build of the Arbitrum Rollup is based on the storage of the state root history in L1, which confirms the state of the L2 chain.

Economic Model: Pledge plays a key role in the Rollup of Arbitrum. Anyone can pledge one of the state trees. By pledging a state (the square in the figure), you can assert that the state will eventually be confirmed by the protocol. In other words, you are asserting that you have adopted the correct branch on each DA along the path from the current state to the square you are pledging. If you are wrong, your pledge will be reduced. You can move your pledge to the right, choosing up or down branches, but you can't move to the left, as this is equivalent to canceling your previous pledge; Or two parallel branches can be pledged simultaneously. Participants who pledge on the wrong branch will have their pledged assets distributed among participants who pledge on the accepted branch. The protocol is constructed to ensure that eventually all independent histories (branches) will converge into one DA that will ultimately resolve all disputes.

Verification: The system can confirm the results of a DA once the pledge period of the DA has expired and all of the timely (committed prior to the pledge deadline) pledges are on the same branch of the DA. The DA is either accepted or rejected, and the current status moves to the appropriate square to the right of the DA. If the DA is validated, the side effects (such as payment) will be realized on the chain. This is how the VM state moves forward. This protocol is completely trustless because any participant has the right to verify the state of the VM on the branch that they think is correct.

Metis:

VM and client: Metis uses the EVM-compatible virtual machine Metis VM (MVM). MVM is quite different from all the VMs in the above projects in terms of functionality and features. In MVM, L2 computation and storage are completely decoupled. Metis introduced the concept of Decentralized Autonomous Corporation (DAC). A DAC is a separate entity within a system that can represent, for example, a large enterprise that performs many of its day-to-day operations through the platform. DAC is key to Metis's operations. When a new DAC is instantiated in the system, a new storage layer is created specifically for the DAC. Therefore, with chain interaction in mind, DAC has its own storage space.

Metis L2 computing layer (or block mining, consensus, cross layer communication, etc.), on the other hand, by the network of all sharing DAC, but an interesting feature: it contains all the calculation process is implemented as a separate service (follow the service method) make calculating layer and according to the requirements of the whole network throughput of expansion and shrinkage. In addition, MVM introduces the role of vendors who can register and contribute computing power to make L2 builds truly decentralized (these vendors can be thought of as a sort for the Moderator platform). Providers will receive incentives based on the blocks produced. Finally, one really powerful feature included in the MVM and Metis client that is not available on other L2 platforms is support not only for contract execution, but also for decentralized storage related to smart contract computing. Thus, Metis integrates with the IPFS network through the IPFS parser in MVM, which allows contracts to point to immutable data stored in IPFS. For example, this can be used to point to confidential data stored in an IPFS network.

Rollup build: In Metis, sorting and batching L2 transactions is done not by a single collator, but by a pool of collators. A randomly selected set of collators will Rollup the state root and commit the transaction to the L1 public chain. At L1, Metis deploys a set of contracts to coordinate batch commits from L2 to L1.

Economic model: Each collator needs to pledge a certain number of Metis tokens to qualify. The fact that the Metis ecosystem has strong real economic connections, with potentially billions of dollars in transaction value, requires the use of dynamic bond thresholds (DBTs) to relate the risks and rewards of malicious behavior to the real economic value managed by the DAC participating in the transaction. The DBT is calculated based on the maximum economic capacity of the DAC assigned to the collator. The economic capacity of a DAC is calculated based on its total balance. Therefore, if the number of Metis Tokens (MT) pledged in a particular collator is lower than the DBT of the DAC assigned to it, it will not be able to conduct bulk transactions for that DAC. The sorting of the DAC is blocked until a qualified collator is found in the collator pool. A new deposit or withdrawal of a DAC balance triggers an automatic update of its DBT. Therefore, new withdrawals from the DAC balance will result in a reduction in the DBT required by the collator and vice versa. This ensures that the collateral in the required collator always follows the actual economic value of the DAC.

Verification: For validation purposes, the Metis platform introduced the concept of L2 Rangers into its MVM. L2 Rangers are members of a special DAC that samples a series of blocks and validates the status root against transactions that are regularly assigned by random DAC. Rangers not only validate the sequential transformations of other DAC, but also validate their own DAC (they monitor themselves). The Ranger will be rewarded with some Metis Tokens (MT) for each validation it completes. A successful challenge to the state of the chain (such as proof of fraud) gives the verifier a cut of the bonds confiscated by the "malicious" collator. On the other hand, a failed challenge will cause the Ranger validator to lose its own bond and ultimately fail to access MVM_RANGERS.

Both the collator and the verifier need a collateral verification method, which solves one of the key problems we found in the verification process of the Optimistic Platform, that is, if the verifier generates a false fraud proof, since the verifier does not pledge assets, they will not be punished. Good coordination between mortgage collators and validators, such as L2 Rangers, also reduces the validation window to improve network efficiency. For a protocol such as Optimism, a transaction cannot be determined finality until the verification window has passed and the verifier has enough time to send all the proofs. This is a direct consequence of the verifier having no collateral. Although there is an incentive to detect invalid status updates, there is no serious penalty for misconduct as a verifier. So, in order to prevent potential misconduct, the final sex window was increased to "let everyone have a say." This is not necessary in Metis because the verifier is secured and misbehavior on their part could result in a loss of funds. Both the verifier and the collator feel the "pain" of shortening the final confirmation window, which is why Metis can verify a transaction in a few hours, rather than seven days for other protocols like Optimism.

Let's compare all the competitors side by side to get a general idea:

Comparison of L2 solutions (by Alfonso de la Rocha)

As shown in the table (and described in our explanation above), these three platforms are well suited to having your dApp supported by the Ethereum mainnet as a high-performance L2 solution supported by L1. The decision may depend on the performance, scalability, flexibility, and functional requirements of your dApp. Of the three platforms we've described, Metis is the most feature-rich: it supports decentralized storage by default and includes additional performance and security mechanisms. The decoupling of storage, the use of DAC, and the dynamic DBT solution make it ideal for companies of all sizes.

Optimism is a good choice for Ethereum supremacists because it uses all the tools in the Ethereum ecosystem (no new concepts required). Finally, Arbitrum's permission-free commitment to state history validation makes it a really effective and interesting proposal that delivers faster validation times than the standard Rollup architecture, and thus protects against latency attacks (though still a bit slower than Metis due to its flat architecture).

In a word, there is no single correct answer and only a stable Optimistic L2 platform can be selected. I hope this comparison article has helped you make a more informed decision about your L2 solution, whether to plan to deploy a new dApp or migrate from L1 to L2.