Comparing 3 Promising Layer 2 Solutions Based on Optimistic Rollups

In the past few months, the price of ETH has surged, and the usage of the Ethereum network has significantly increased. The main culprits for this trend have been the renewed interest in NFTs and the consolidation of DeFi applications, along with the outstanding growth of the cryptocurrency market. This has resulted in a number of “not so pleasant” consequences for DApp developers in the Ethereum ecosystem: mainly, the network’s inability to accommodate the increase in usage leading to high gas costs (even more if you want your transaction to be validated in the next few blocks). At the time of writing, the average gas fee in the Ethereum mainnet is approximately $15.

This new scenario we are facing in the Ethereum ecosystem has shifted layer 2 improvements overnight from a “nice to have” feature to an “utmost requirement” for Dapps to be able to operate sustainably in terms of performance and cost. 

Fortunately, we already have several consistent layer 2 platforms and protocols to help us in this quest. One of the most promising foundational constructions to build layer 2 solutions are optimistic rollups. Many projects are built upon them, but how can we choose the layer 2 solution based on optimistic rollups that best fulfill our needs? This publication is an attempt to answer that question, making a comparison of the three promising layer 2 solutions based on optimistic rollups. Let’s jump right into it!

What are rollups? And why are they optimistic?

In order to be able to compare different layer 2 solutions based on rollups, we first need to make a quick detour to understand what optimistic rollups are. Rollups are solutions that bundle (or “roll up”) sidechain or off-chain transactions into a single transaction that is then committed to L1. To secure all of these bundled transactions, and to make them individually verifiable, a cryptographic proof is generated from the bundle.

A requirement for rollups to work is to have some kind of Ethereum-compatible independent blockchain, with a reduced number of nodes or with additional features for high-performance, that is responsible for handling signature verification, contract execution, etc. This makes the independent blockchain able to verify the validity of the transactions that are afterwards bundled for their commitment in the main Ethereum chain. L2 rollup sidechains are responsible for verification and contract execution, while the L1 exclusively stores immutable transaction data.

In Optimistic Rollups, participants are “optimistic” about the validity of the transaction being performed in the sidechain. There is no need for additional computation by aggregators to commit sidechain transactions into the main chain. 

And how can we be sure that sidechain transactions are actually valid? 

Optimistic rollups use fraud-proofs to ensure that all transactions are legitimate. If someone notices a fraudulent transaction from an aggregator, the rollup can be challenged by sending a fraud-proof to run the transaction’s computation and verify its validity. This means that instead of performing a verification for every single transaction, like in other rollup solutions like ZK-rollups, we only perform the proof computation if we have suspicions that a transaction is fraudulent.

This significantly reduces the gas costs compared to ZK-rollups, and opens the door to the ability of achieving x10-x100 improvements in the transaction throughput. After an invalid block has been committed and a fraud proof is finalized, the chain in layer 2 can be rolled back and resumed from the previous non-fraudulent block.

(Source: coinmarketcap.com)

Introducing the comparison contenders

After this brief introduction to rollups, we have all the foundations we need to tackle our layer 2 comparison. For this comparison, I selected three of the layer 2 solutions that, in my opinion, have a more interesting set of features for DApp developers (i.e. the ones I would personally consider to deploy my own applications).

All of them share (more or less) the same building blocks: 

• an Ethereum compatible VM to run users’ Solidity contracts in L2;
• sequencer/aggregators responsible for batching transactions from L2 from bundles that are then committed at L1;
• a set of L1 smart contracts to orchestrate the interaction and commit the data from L2;
• the use of different fraud-proofs for peers to be able to refute invalid or forged transactions committed by aggregators;
• and the use of a stake to orchestrate the incentive and the economics of the L2 system.

Despite having building blocks in common, the three solutions differ significantly in the way they implement the rollup protocol. Let’s have a look at each of them in detail to get up to speed for our comparison.

1. Optimism:

Optimism leverages all the existing tooling in the Ethereum ecosystem, and modifies it to implement their optimistic protocol and layer 2 solution.

• VM: Their L2 VM is the Optimism VM (OVM), which is a modification of the Ethereum VM (EVM) which replaces context-dependent EVM opcodes with new opcodes suitable for L2 contract execution. The VM behaves as a sandboxed environment which guarantees deterministic smart contract execution and state transition between L1 and L2.

• Client: Optimism also modifies the wide-spread Ethereum client, Geth, so it can be used as a client for the L2 chain. This client modifies messages so that they are understood by other L2 clients, and it includes all the processes required for the sequencing and batching of transactions in order to build the rollup.

• Rollup construction: For their rollup construction, Optimism uses the Geth client as a single sequencer. In Optimism, transaction data is compressed and then sent to the Sequencer Entry point contract on L2. The sequencer is responsible for “rolling up” these transactions in a “batch” and publishing the data on Ethereum, providing data availability so that even if the sequencer disappears, a new sequencer can be launched to continue from where things were left off. Anyone can send new transactions to L1, and these transactions are added in a L1 contract that behaves as a “append-only log” for every L2 transaction.

• Verification: For each transaction published by the sequencer, a verifier is responsible for downloading that transaction and applying it against their local state. If everything matches, they do nothing, but if there’s a mismatch, the verifier needs to submit on-chain all the valid previous transactions, and re-execute any state root published to show that the published state root was actually wrong. If the fraud verification succeeds, the wrong states and batches are pruned from L1.

• Economic model: The sequencer of batches at every epoc need to be marked as collateralized by a smart contract called the bond manager. To become a collateralized sequencer, a fixed amount of ETH needs to be staked in the contract. 
  
  This stake is slashed every time fraud is detected for a sequencer. Sequencers can recover this stake after 7 days of depositing, the moment from which the batches for the sequencer can be considered final, as no verification and slash is possible anymore. If fraud is successfully proven, a percentage (X%) of the proposer’s bond gets burned and the remaining (1-X)% gets distributed proportionally to every user that provided data for the fraud proof. 
  
  This economic model prevents sequencers from going rogue, but doesn’t address the potential case where verifiers send lots of fraud proofs for a large number of different batches on an attempt to the chain (forcing a lot of L1 computations).

2. Arbitrium:

• VM and client: Arbitrium implements the Arbitrium Virtual Machine. The AVM is responsible for running L2 contracts and keeping their state. The state of the VM is organized as a Merkle Tree, and execution is done in the generated state transitions over this Merkle Tree. Arbitrium also implements its own custom L2 client.

• Rollup construction: Arbitrium uses a single on-chain contract to orchestrate its rollup protocol. At any point in the protocol, there is some state of the VM that is fully confirmed and final, i.e. its hash is stored on-chain. New transactions in L2 trigger an update of the state of this Merkle Tree that stores every state in the chain. To validate the stored states, participants of the protocol can make what is called in Arbitrium a Disputable Assertion (DA) to attest starting from some state-hash, the VM is able to execute a specified number of steps of computation resulting in a specified new hash-state (with its corresponding contract execution, payments and event emission). The DA may end up being valid (i.e. the computation is successful), or invalid. If the DA is valid, the system will enter a new state, with a new state hash in the tree, and its corresponding side-effects (payments and logs) specified in the DA. If the DA is invalid, the branch is rejected and the state is unchanged. Each state can have at most one DA following from it. If a DA has no following state, then anybody can create a DA that follows it, creating a new branch point. The result will be a tree of possible futures. So we can see that while Optimism uses several L1 smart contracts to commit the state and execution at the L2, the L1 construction for Arbitrium’s rollup is based on the storage in L1 of a history of state roots that commits the state of the L2 chain.

(source:

https://medium.com/offchainlabs/how-arbitrum-rollup-works-39788e1ed73f

 )

• Economic model: Staking plays a key role in Arbitrium’s rollup. Anybody can put a stake on one of the states of the tree. By staking on a state (squares depicted in the figure) you are asserting that that state will eventually be confirmed by the protocol. In other words, you’re asserting that you have taken the correct branch at each DA along the path from the current state to the square you’re staked on. If you are wrong, your stake will be slashed. You can move your stake to the right, choosing up or down the branch, but you can’t move to the left because that would amount to undoing a staking commitment that you made earlier; or bet on two parallel branches at the same time. The stake of participants staking on the wrong branch is distributed between the ones that staked in the accepted branch. The construction of the protocol ensures that eventually all independent histories (branches) will come together to a DA where disputes will eventually be resolved.
• Verification: Once a DA’s staking deadline has passed, and all of the timely (placed before the staking deadline) stakes that remain are on the same branch from that DA, the system can confirm the result of that DA. The DA is either accepted or rejected, and the current state moves to the appropriate square to the right of the DA. If the DA is confirmed as valid, its side-effects, such as payments, are effectuated on-chain. This is how the state of the VM moves forward. The protocol is completely trustless, as any participant is entitled to verify the state of the VM by staking on the branch thinks is right.

3. Metis:

VM and client: Metis uses an EVM-compatible virtual machine, the Metis VM (MVM). The MVM differs significantly in terms of functionality and features to all the VMs from the projects above. In the MVM, computing and storage at L2 are completely decoupled. Metis introduces the concept of Decentralized Autonomous Companies (DACs). DACs are independent entities in the system that can represent, for instance, large scale enterprises that perform many of their day-to-day operations over the platform). DACs are key for the operation of Metis. When a new DAC is instantiated in the system, a new storage layer is specifically created for the DAC. Thus, DACs have their own storage with a view of their chain interactions.

Metis’ L2 computing layer (i.e. block mining, consensus, cross-layer communications, etc.), on the other hand, its shared by all the DACs in the network, but it includes an interesting feature: the fact that all of the computing processes are implemented as individual services (following a microservice approach) allows the computation layer to be scaled up and down according to the overall network’s needs and throughput. 

Furthermore, the MVM introduced the role of providers that can sign up and contribute computing power to make Layer 2 construct truly decentralized (these providers can be seen as the sequencers from the Optimism platform). The provider will be incentivized based on the blocks produced. Finally, a really powerful feature included in the MVM and the Metis client which other L2 platforms lack is support, not only for contract execution, but for decentralized storage linked to the computation of smart contracts. 

Thus, Metis integrates with the IPFS network through an IPFS resolver in the MVM which allows contracts to point at immutable data stored in IPFS. This can be used, for instance, to point to confidential data stored in the IPFS network.

Metis architecture (source: Metis whitepaper)

• Rollup construction: In Metis, the sequencing and batching of L2 transactions is not done by a single sequencer but a pool. A pool of sequencers will be randomly selected to rollup the state roots and submit the transactions to L1. At L1, Metis deploys a set of contracts that orchestrate the commitment of batches of L2 to L1.

• Economic model: Each sequencer needs to stake a number of Metis Tokens to be qualified. The fact that the Metis ecosystem has strong, real economic connections, with transaction values that can be in the billions requires the use of a Dynamic Bond Threshold (DBT) so that the risk and reward of malicious behavior is linked to the real economic value managed by the DACs involved in the transactions. The DBT is calculated using as a base the maximum economic capacity of the DAC assigned to a sequencer. The economic capacity of a DAC is computed according to its total balance. Thus, if the number of staked Metis Token (MT) of a particular sequencer is below the DBT for the DAC it is assigned to, it won’t be able to batch transactions for that DAC. A DAC’s sequencing is blocked until an eligible sequencer is found in the sequencer pool. New deposits or withdrawals of funds from the DAC’s balance trigger automatic updates to its DBT. Consequently, new withdrawals to the DAC balance will reduce the required DBT of sequencers, and vice versa for new deposits. This ensures that the required sequencing collateral always follows the real economic value of a DAC.
• Verification: For verification purposes, the Metis platform introduces the concept of L2 Rangers in their MVM. L2 Rangers are members of a special DAC that are responsible for sampling a range of blocks and validate the state roots according to the transactions assigned periodically from a random DAC. Rangers not only validate sequenced transitions for other DACs, but they also do it for their own DAC (they overwatch themselves). Each completed validation from a Ranger is rewarded with some Metis Tokens (MT). A successful challenge (i.e. fraud proof) to a state of the chain awards the validator a portion of the “malicious” sequencers bond. On the other hand, a failed challenge will cause the Ranger validator to lose the bond and eventually lose access to MVM_RANGERS.

This verification method where both sequencers and verifiers need to be collateralized, this addresses one of the key issues we identified in the verification process of the Optimism platform, which is the lack of stake of verifiers in the generation of fake fraud proofs. The well-oiled coordination of collateralized sequencers and verifiers (i.e. L2 Rangers) also shortens the proofing window to enhance the network efficiency. 

Protocols such as the one proposed by Optimism, transactions can’t be considered final until the window of verification has passed, and verifiers have had enough time to send all the proofs. This is a direct consequence of verifiers not being collateralized. 

Despite being an incentive for detecting invalid state updates, there is no large penalization for misbehaving as a verifier. Thus, in order to prevent potential misbehaviors, the finality window is increased to “allow everyone to speak”. In Metis this is not needed because verifiers are collateralized, and a misbehavior from their side will be translated in a loss of funds. Verifiers as well as sequencers have “skin in the game”, and this enables a reduction of the finality window, and this is the reason for Metis being able to validate transactions in hours instead of the 7 days other protocols such as Optimism need.

Ready to compare!

So without further ado, let’s put all of our contenders side-by-side for a last general view of the situation:

As depicted in the table (and as described in our explanations from above), the three platforms are perfect fits to deploy your DApp in a performant L2 solution backed by the Ethereum mainnet as a L1. 

The specific decision will be potentially determined by your performance, scalability, flexibility, and feature requirements. Metis is the most feature-rich platform from the three we’ve described: it supports decentralized storage by default, and includes additional performance and security schemes.

The decoupling of storage, their use of DACs, and their dynamic DBT scheme, makes it a perfect fit for corporations (large or small). Optimism is a great option for Ethereum maximalists, as it uses every tool from the Ethereum ecosystem (no need for new concepts). Finally, Arbitrium’s permissionless staking for state history verification makes it a really efficient and interesting proposal that allows faster verification times than standard rollup constructions preventing delay attacks (although still a bit slower than Metis due to the flat architecture it uses).

In conclusion, there is no single right answer, but a consistent roaster of optimistic L2 platforms from which to choose. I hope this comparison helps you make a more informed decision of the L2 to choose if you are planning to deploy a new DApp, or migrating from L1 to L2.

Reference; https://adlrocha.medium.com/the-optimistic-layer-2-wars-5661f378885c

This article was written by Alfonso de la Rocha