The Optimistic Layer 2 Wars

What are rollups? And why are they optimistic?


Introducing the comparison contenders


  • 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 Entrypoint 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.
State Merkle Tree in Arbitrium (source: )
  • 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.
Dispute of two parallel branches (source: )
  • 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.
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.

Ready to compare!

L2 comparison (by Alfonso de la Rocha)




Research at Protocol Labs | Avid reader seeking for constant innovation. [] []

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Developing a DID Aggregator on Blockchain (Part Ⅱ)

Litentry Partners With Ontology, Strengthening Its Decentralized Identity and Credit Computation…

GridPlus’ GRID Token Now Available on Loopring Exchange

Quixxi Spotlight: Caroline Dempsey, Chief Marketing Officer

Recap of the Calypso Network AMA with Blockchain Space

Internet of Value Manifesto

What is Fanz?

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
Alfonso de la Rocha

Alfonso de la Rocha

Research at Protocol Labs | Avid reader seeking for constant innovation. [] []

More from Medium

Algogator.Finance V2 is live!

The pieces of the blockchain Lego

Weekly Pulse: Jan 7, 2021

Telos Swaps v3 technical primer