The Optimistic Layer 2 Wars

By Alfonso de la Rocha

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.

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).


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

  • 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).


  • 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.
  • 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.


  • 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.
  • 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.

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:

Writer: Alfonso de la Rocha

Layer 2 protocol to run Decentralized Economies

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store