Optimism & Arbitrum: Tracking Decentralization Progress

This report is the second installment in the Glass Half Full series, which focuses on the two leading optimistic rollups on Ethereum—Optimism & Arbitrum. The first installment of the series analyzed the growth and adoption across both rollups. The series will also evaluate the security and decentralization efforts of the primary OP Mainnet and Arbitrum Mainnet chains, compare the tech stacks behind both rollups, dive into the economics of each network, and discuss the broader outlook for Optimism and Arbitrum among the rest of the crypto landscape.

Key Points / Takeaways

• The primary responsibilities of optimistic rollup operators include sequencing, batch posting, proposing, and verifying – although distinct functions, most are performed by a single operator across most rollups as it stands today.

• When critics point to decentralization concerns with rollups, they are often referring not just to the single operator setup with sequencers/validators, but to the wider theme of rollup security in general. Three core focus areas for optimistic rollups to improve decentralization and security include: (i) implementing fraud proofs, (ii) expanding the operator set for validating and sequencing, and (iii) removing admin privileges & distributing control of the rollup through governance.

• Arbitrum has been leading Optimism across many of these efforts with an operational fraud proof system, expanded validator set, and established security council to oversee upgrades to the protocol. According to L2Beat’s “Stages” framework to assess rollup maturity & decentralization along a 0 – 2 grading system, Arbitrum qualifies as a “Stage 1” rollup, one level ahead of Optimism, which remains at “Stage 0”.

• Although Optimism has not had fraud proofs enabled for nearly two years, OP Labs has put considerable thought into their upcoming proof system “Cannon” to support the eventual adoption of zk-proofs that can then unlock low-latency connectivity for the Superchain in the future.

• A later stage goal for rollups to fully decentralize is to have decentralized sequencing, which is still actively being researched by the collective Ethereum community. Both Optimism and Arbitrum teams have engaged third parties to explore decentralized sequencer setups, such as Espresso’s shared sequencing solution.

• With growing adoption of rollup technology stacks by new chains (i.e., OP Stack chains under the Superchain and L3s with Arbitrum Orbit), it’s critical that the security considerations of the underlying protocols are made apparent to all potential builders/users. Rollups are core to Ethereum’s technical roadmap, and they should be held to the rigorous security and decentralization standards of the Ethereum community.

Intro

After years of hype across the Ethereum community, L2 season is now well underway. As we mentioned in our first installment of the Glass Half Full series, the leading optimistic rollups—Optimism and Arbitrum—already have robust ecosystems that have continued to expand; on the ZK side, the first zkEVMs launched for public access just months ago (i.e., zkSync Era & Polygon zkEVM – discussed in a separate report), and many other rollups or rollup-adjacent chains will soon become available on Mainnet. Rollups are core to Ethereum’s roadmap, serving as Ethereum’s premiere L2 scaling solution and primary onboarding network for new populations of users with plenty of buy-in already from major organizations.

With so many active and prospective scaling solutions emerging in the market, the fight is on to differentiate offerings and to attract developers for launching applications that will ultimately serve end users. Rollup teams have largely been working on incorporating features such as added coding language support or increased customizability for builders to launch their own dedicated chains to host various applications to best serve end users. Each protocol team has also presented differing longer-term visions of unifying their ecosystems: for our optimistic rollups, this includes Optimism Superchain and Arbitrum Orbit, respectively.

Given the rapid pace of rollup adoption, especially with the OP Stack and the new cohorts that are being brought on-chain for the first time by platforms like Base or Worldcoin, the security considerations of the underlying protocols should made apparent to all existing and potential builders and users of these technologies. We will dive into the differentiating features of each rollup’s tech stack in our next report, but first we dive into some of the often overlooked (or overstated) security components that are foundational to Optimism and Arbitrum protocols (i.e., centralized setups, fraud proofs, etc.), map out some of the major technical progress already achieved, and explore what’s included in the security/decentralization roadmaps.

Background: Rollup Fundamentals

What are rollups / how do they work?

A rollup is a scaling solution that processes transactions outside of the main Ethereum network and publishes the record of the transaction data on the Ethereum L1 mainnet. Rollups rely on the Ethereum mainnet for consensus, data availability, and settlement. The main value proposition of rollups is to move execution off the L1 while ensuring data availability so anyone can check for fraud by reconstructing the state of the rollup using public information and determine/verify its correct state. In other words, the goal of rollups is to minimize the data footprint on Ethereum to achieve greater scale and cheaper fees while still preserving the security properties of base layer.

Rollups typically come in two forms: (i) optimistic rollups (“ORUs”), and (ii) zero-knowledge rollups (“zk-rollups” or “ZKRUs”). The core difference between these two rollup types is their security models, or mainly in when the cost of proof generation or validation is paid. Optimistic rollups derive their name because submitted transaction batches are optimistically assumed to be valid by default; the cost of validation (i.e., generating a fraud/(fault) proof) is only paid if the posted data is disputed. In contrast, zero-knowledge rollups pay the cost of validation upfront by publishing a succinct validity proof for every state transition that is posted to the base layer.

Within optimistic rollups, we define ‘operators’ as the parties that move the rollup chain forward. The two primary types of operating roles within rollups: sequencers and proposers/verifiers.

• Sequencers are dedicated nodes that receive and order user transactions. A sequencer aggregates L2 transactions, compresses them into batches, which are then posted to the L1. Sequencers are not necessarily responsible for computing the state of the rollup; only for committing to the ordering of transactions (though most sequencers are equipped to handle computing and other responsibilities).

• Validators will read the transaction data posted by the sequencer, process the transactions, and update the L2 state. Anyone can permissionlessly spin up a validating node that runs the open-source validator software to read/check the transaction data (no stake required), but only a special subset of validating nodes helps to secure the chain by posting staked assertions to the state of the chain:

  • Proposers will run the transaction inputs through the rollup’s State Transition Function and propose claims about the L2 state (‘Merkle root’ or ‘state-root’) which are submitted to the L1.

  • Verifiers then check the proposed claims against their own local state generated from the L2 transaction input data posted on L1 and, if there is a mismatch, can initiate the dispute resolution process by submitting a fraud proof to determine where the fault has occurred.

In summary, the sequencer receives user transactions and orders them by posting batches of transaction inputs on L1 (calldata), proposers will execute the posted transaction inputs locally and make claims about the transaction outputs (state roots), and verifiers will check that the proposed outputs are valid and can dispute any invalid claims as needed (via fraud proofs).

Note, while these are distinct roles described above, most of them are operated solely by the central teams behind each of the rollups as it stands today. However, breaking out these functions and responsibilities will be more useful as rollup teams aim to progressively decentralize their operational setups (discussed later in this report).

The typical lifecycle of an L2 transaction on an optimistic rollup:

1. Rollup users submit L2 transactions directly to the sequencer.

2. Sequencer executes the transaction locally on its copy of L2 chain following the rollup’s state transition function and provides near-instant transaction receipt (“soft confirmation”) to the user.

3. Sequencer orders transaction in off-chain inbox, compresses transaction input data into batches, and then publishes these batches of transaction data to an ‘inbox’ contract on the L1.

4. Validators read & process transaction inputs from the L1 Inbox on their local copy of L2 state using the rollup’s state transition function. Among this group, one active staked validator (i.e., a proposer) will post an assertion about the newly generated L2 state root to L1 that will be unresolved at first.

5. Other active validators (i.e., verifiers) using the same data inputs will then check the assertion from the proposer against their own local copy of the L2 chain.

   1. If there are no differences, verifiers do nothing, and the proposer’s assertion is confirmed on the L1 after the 7-day challenge period ends.

   2. If there is a difference, an active staked verifier may challenge the proposer’s assertion by submitting a fraud proof, which initiates the dispute resolution process to determine where the discrepancy is. The invalid commitment will then be replaced by another proposed commitment. A successful challenge does not rollback the rollup, it only affects the published commitments about the rollup’s state on L1 while the ordering of transactions remains unchanged.

Note: the process described is just the process for typical L2→L2 transactions, but there is a different transaction flow for L1→L2 transactions (i.e., deposits or bridging from Ethereum into the rollup) and L2→L1 transactions (i.e., withdrawals or exits from the rollup).

Core Concepts & FAQ

“Soft Finality” vs. “Hard Finality”

A common criticism of optimistic rollups is that posted transactions take one week to finalize on the L1. In practice, this 7-day period constraint only impacts settlement L2-to-L1 messages (i.e., withdrawals/exits from the rollup back to Ethereum). For standard L2→L2 transactions, rollup users experience near-instant confirmations, which are enabled by the sequencer’s promise not to extract MEV by front running user transactions.

Rollups typically employ an FCFS approach (first-come, first-serve) or a private mempool. By committing to fair ordering principles, the sequence of transactions can be known even before the sequenced batch is posted on the L1 (typically every ~1-2 minutes). Submitted transactions can be run through the state transition function once posted to the L2 sequencer feed (often occurs within seconds), achieving “soft finality” (“soft” since it’s based on trusting the sequencer to then post the batched transaction data to the L1 following the fair ordering principles).

Transactions may be considered to have “hard finality” once the sequenced batch is posted to the L1. At that point, the transaction ordering is fixed and cannot be changed – the sequencer will have no more input from that point on. Execution on rollups is ‘fully deterministic’ – meaning any node can reconstruct and validate the state of the chain using just the existing state of the rollup and the new transaction data from the sequencer once it is posted to the L1. Even though verifiers may initiate disputes over proposed outputs, the correct state is determined using the transaction inputs from batches posted on L1.

So “finality” can be subjective, depending on user’s level of trust in the sequencer, and may differ depending on the type of transaction. For standard L2 transactions, finality will typically range from 1-2 seconds for soft finality to ~2 minutes in most cases or longer depending on when batches are posted for L1 finality (still be subject to potential L1 reorgs).

Other FAQ

• When does the 7-day Challenge Period for Fraud Proofs come into play and why is it 7 days?

  • L2s must prove to the L1 that withdrawal claims are valid. Among rollups, ZK-rollups prove submit a cryptographic proof alongside each posted batch that a given claim is valid. With optimistic rollups, withdrawal claims must go through a lengthy challenge period (typically ~7 days) to allow sufficient time for validators to detect any invalid claims and to go through the fraud proof process. The one-week period is largely arbitrary (it was likely chosen as a conservative estimate that has now become standard for optimistic rollups) – however, the goal is to prevent malicious actors from coordinating an attack that prevents verifiers from being able to submit challenges (i.e., spamming the L1 to drive up gas prices or running DoS attacks on verifiers). Over a multi-day period, the costs of censorship by attacking the gas price would then quickly expand to a point where it likely becomes uneconomical for the attackers to attack the rollup.

• What protections do users have if the Sequencer goes down or censors?

  • As stated above, most sequencers currently operate on the promise that they will not re-order transactions or extract MEV, though they still potentially can reorder transactions, post invalid blocks and state commitments, or reject specific transactions from being included in a rollup block (censor). Verifiers serve as the primary defense against invalid state commitments – with a working fraud proof system, the security of the rollup requires just one honest verifier to check for invalid state commitments posted on mainnet (‘1-of-N honesty assumption’).

  • Aside from having working fraud proofs, rollups can implement additional safety mechanisms to protect users in the case of a sequencer failure or if batches stop posting. These safety measures include enabling users to submit transactions directly to the L1 (i.e., force inclusion) to bypass the sequencer after a select period of delayed sequencer submission or having backup options for other operators to fill in and continue moving the chain forward in case of downtime. If the sequencer is still operational but rollup batches stop posting to the L1, rollups can continue to operate and provide users with soft confirmations that will not have hard finality (which would primarily impact withdrawal transactions). Without some of these safety mechanisms implemented on the rollup, users may face risk of censorship by a malicious, centralized sequencer.

• Can a malicious sequencer steal my funds?

  • Sequencing and validating are distinct roles on a rollup performed by distinct entities (though they may be operated by a single operator). If there is an honest verifier capable of checking for fraud, then the worst a malicious sequencer can do is reorder transactions or delay a transaction’s inclusion. Without an honest verifier to check for fraud, then a malicious operator could steal funds by posting invalid blocks and state commitments. In addition, a permissioned system address capable of issuing upgrades can potentially steal user funds by making changes to critical system components.

• Can rollups inherit the same level of security as Ethereum?

  • L2s benefit from the immutability and censorship-resistance properties of Ethereum after posting data and settling transactions. Despite claims that L2s inherit the security guarantees of the L1, rollups will always come with an additional set of distinct risks separate from Ethereum. Even if rollups reach the point of maturity where users have sufficient safeguards against malicious operators and the operator set can be decentralized, rollup software that sits on top of Ethereum is still subject to bugs and rollup teams will require trusted admin controls or upgradeability capabilities to address any bugs and to improve upon the software. Upgradeability of the rollup will always subject rollup users to additional risks, but some of these risks can partially mitigated by removing admin controls or incorporating upgrade delays so users have sufficient time to react to any upgrades before they are implemented (discussed in greater detail in the following section).

With these core concepts explained, we can explore and compare the specific implementations of Optimism and Arbitrum.

Current Protocol Implementations / Planned Updates towards Decentralizing

When critics point to decentralization concerns with rollups, they are often referring not just to the operator setup with sequencers/validators, but to the wider theme of rollup security in general (i.e., what vulnerabilities are rollup users subjected to and how?).

Decentralization and security can be viewed across a wide range of vectors, but three core focus areas for optimistic rollups include:

• Implementing fraud proofs and iterating on dispute resolution process

• Expanding operator set for validating and sequencing

• Removing admin privileges & distributing control of the rollup through governance

Fraud Proofs

When both Optimism and Arbitrum first launched in 2021, both rollups had their own operational fraud proof mechanisms for dispute resolution: Optimism employed a re-executing transactions approach (involved executing all transactions included in a disputed batch on the L1) while Arbitrum employed a multi-round interactive proving method innovated by Offchain Labs that aimed to provide a more efficient dispute resolution process that minimized the computational work of the L1. (Fun fact: the name ‘Arbitrum’ comes from the word ‘arbitration’ or the process of settling disputes.)

As it stands today, fraud proofs have since been disabled on Optimism as the OP Labs team is working to implement a new proof system, while Offchain Labs has emphasized having a fully deployed fraud proof system since launch and has been working on improving it ever since with several meaningful system upgrades.

Optimism

In November 2021, as part its OVM 2.0 upgrade and targeted shift towards EVM-equivalence, the Optimism team disabled the existing fraud proof system on Optimism mainnet after discovering some vulnerabilities in its mechanism, noting that alternative proving systems worked on by others could be slotted into the system in the future (it’s worth highlighting that the blog post from October 2021 on EVM-equivalence presented much of the groundwork for the modularity thesis that is consistent with how the OP Stack is marketed today). OP Labs then began working on the proof-of-concept for Cannon, a new fraud proof implementation designed to meet the new ‘EVM-equivalence’ direction of the protocol.

According to some of the preliminary details published by OP Labs, Cannon employs an interactive dissection process to narrow down the disagreement in the instruction set to minimize data costs (similar to Arbitrum’s proving method). Cannon is written in Go and emulates a MIPS instruction set, which then compiles a subset of geth (“minigeth”) to then implement the EVM state transition function (so the EVM running on L2 behaves the same as EVM proven on L1). MIPS was chosen as a widely adopted industry architecture standard that can support modular proof designs so validity proofs can be slotted in easily in the future.

Fast forward nearly two years from when OP Labs began working on Cannon to today, Optimism still doesn’t have a working fraud proof system. The OP Labs team has stated that the Bedrock upgrade completed in June 2023 is a precursor to shipping fraud proofs and that Cannon is the next major technical milestone that they are prioritizing.

The OP Labs team has previously shared a decentralization roadmap in a blog post from February 2023, Optimism’s Path to Technical Decentralization, which laid out several target dates for decentralization goals. Regarding fraud proofs, OP Labs stated that “completing the precursors for fault proof decentralization will be a focus into 2024”, which includes implementation of the Cannon fraud proof program that executes the L2 state transition so that outputs can be programmatically verified on L1 and implementation of the proof VM so the proof program can be executed on L1.

While the team has continued to share new Cannon details in recent months, they have yet to provide a new update on their target date to reinstate fraud proofs on Optimism.

Arbitrum

Meanwhile, Arbitrum has maintained a working fraud proof system ever since launching.

As part of the Nitro update in August 2022, Offchain Labs upgraded its original network and fault proof system (now referred to as ‘Arbitrum Classic’). Compared to its prior iteration of Arbitrum, Nitro creates separate contexts for execution and proving. Nitro’s approach to proving involves, first, narrowing the dispute into a single block, and then compiling the Go code to WebAssembly (WASM) to run the state transition function (vs. Arbitrum Classic’s use of custom ‘AVM’ bytecode for running the L2 VM and the inputs used to prove fraud). Effectively, Nitro’s dispute resolution approach provides Arbitrum with greater efficiency improvements over Arbitrum Classic, resulting in more performant nodes and lower fees for end users.

There has been at least one instance of a successful fraud proof challenge after an attack had taken place on the Ethereum PoW chain following the Merge in September 2022.

Upcoming Changes to Proving Systems / Areas of Exploration

Optimism

In a July 2023 blog post, OP Labs shared further details about Cannon, noting that they are working on eventually adding multiple proof implementations for added security (i.e., FP programs based on different programming languages including geth and reth (Rust-based execution)). The team mentions how the modularity unlocked by Bedrock enables separation of different fault proof components, including the fraud proof program and the proof instruction set, can be adapted and optimized independently.

OP Labs also mentions in the blog post that the modular proof design creates a path to eventually adding ZK proofs (ZKPs) to support low latency bridges between OP Stack chains which are “critical to unlocking Superchain composability and therefore key to realizing the goal of enabling a unified and interconnected Superchain.” So effectively, the team views Cannon as the core messaging layer between rollups that are part of the Superchain vision with ZKPs as the more desirable proof type. To support this goal, Optimism is moving forward with two proposals from O(1) Labs and RISC Zero exploring how to integrate ZKPs to OP Stack chains.

In addition, Base is working with Paradigm to support the implementation of OP-reth, which will be used to build a second fault proof client.

Meanwhile, as the OP Labs team is working to re-instate just one proving system on OP mainnet, they have seemingly downplayed the importance of their rollup having working fraud proofs in relation to other security risks:

• According to Optimism docs regarding whether OP Mainnet has fault proofs (emphasis theirs): “No, OP Mainnet does not currently have fault proofs. Fault proofs do not meaningfully improve the security of a system if that system can be upgraded within the 7-day challenge window (“fast upgrade keys”). A system with fast upgrade keys, such as OP Mainnet, is fully dependent on the upgrade keys for security. OP Mainnet's goal is to be the first system that deploys fault proofs that can secure the system by themselves, without fast upgrade keys.”

• In a Twitter argument between Optimism and Arbitrum team members over Optimism’s lack of fraud proofs, OP Labs developer Kelvin Fichter writes: “In all this what I really don't understand is that Arbitrum still has a multisig in place that can rug users at any time. And there's an argument that the Arbitrum multisig is *less* secure because its participants are publicly known, making it easier to target signers.” (Admin controls / upgradeability discussed in later section)

Arbitrum

In February 2023, Offchain Labs announced Stylus, a next-gen general purpose programming environment and WASM virtual machine to enable builders to deploy programs written in other programming languages (i.e., Rust, C, C++) alongside Solidity dApps on Arbitrum chains. While the primary goal behind Stylus is to expand the way that builders can write programs in different languages, Stylus also has implications for proving on Arbitrum. Stylus serves as an extension to Nitro by supporting some of the added languages and tooling that compile to WASM for proving. Offchain Labs shared an update in May stating that they have they have already written a complete, working fraud prover for Stylus and that before the end of the year, they are planning to release a testnet and the source code that can be deployed on any Arbitrum-Nitro based chain. The team later released the code and public testnet for Stylus on 8/31/23 (“Arbitrum Day” or the second anniversary of Arbitrum’s mainnet launch), well ahead of its previous schedule.

In August 2023, Offchain Labs announced BOLD (Bounded Liquidity Delay), a new dispute protocol to enable permissionless validation for Arbitrum chains that protects against DoS attacks. The core features of BOLD are: (a) guarantees fixed upper bounds on confirmation times for settlement of ~7 days, and (b) ensures a single honest party can always win against malicious claims. BOLD has already been audited by Trail of Bits, but will need to go through further testing and approvals before the new challenge protocol can be adopted into Arbitrum chains. If BOLD were to be implemented, it could make Arbitrum the first optimistic rollup with permissionless fraud proof submission.

If testing of BOLD and Stylus goes well and the DAO votes for Arbitrum integrate these upgrades, the primary team will then look to accelerate deployments of L3 blockchains secured with Nitro’s fraud proofs to grow the Arbitrum Orbit ecosystem.

Operator setup

Arbitrum has been leading Optimism on in-house research and the implementation of decentralized operator setups.

Currently on both OP Mainnet and Arbitrum One, there is essentially no distinct separation between the entities that perform the sequencing, batch posting, and proposing state outputs – each of these functions is solely operated by the central Optimism Foundation and Offchain Labs teams, respectively. Anyone is still free to spin up a validating node on either of these rollups, but verification or the ability to challenge invalid state roots is still limited across both rollups:

• On Optimism, while the Cannon fraud proof system is still under development, no validators can challenge an invalid proposed state root if an invalid state is detected.

• On the other hand, Arbitrum has a permissioned set of verifiers that are capable of submitting fraud proofs (expanded validator set first added in November 2022). Aside from Offchain Labs itself, the permissioned set of staked validators on Arbitrum include 12 other reputable organizations including: Consensys, Ethereum Foundation, L2BEAT, Mycelium, P2P, Quicknode, Distributed Ledgers Research Centre (DLRC) at Institute for the Future (IFF), and Unit 410. See Arbitrum docs for allowlisted validators.

Transaction ordering policy: At the time of their mainnet launches, both Optimism and Arbitrum followed FCFS ordering policies, which Arbitrum still uses today, ignoring any priority fees. Following the Bedrock upgrade in June 2023, which introduced 2s fixed block times and EIP-1559 style pricing, Optimism’s sequencer now orders transactions through a mempool based on gas price (base & priority fees) – the mempool is kept private to avoid opening opportunities for MEV.

Importance of Decentralizing Rollup Operators and Challenges to Implementation

The importance of decentralizing the operator set is to limit single point of failure and to provide rollup users with greater security assurances over the liveness and censorship-resistance. Having a decentralized set of operators on the rollup adds to the resilience and fault tolerance of the rollup.

Offchain Labs states in their docs that, in their view, decentralized validation is more significant than decentralized sequencing: “An Arbitrum Rollup chain with a centralized Sequencer could theoretically still be trustless! Which is to say — the more important thing than decentralizing the Sequencer, i.e., the thing you ought to care more about — is decentralizing the Validators.”

While the security implications of decentralizing the roles of sequencers, proposers, and validators should not be neglected, there are also meaningful trade-offs or challenges to decentralizing rollup operators such as:

• A distributed set of sequencers may add to transaction latency or could collect MEV. A core benefit of having a centralized sequencer is the ability to provide users with fast transaction confirmations (assuming they are trusted not to re-order transactions). Transaction latency is minimized under this approach since the ordering of transactions is known once published to the Sequencer feed on L2 before they are batched to the L1. Optimism & Arbitrum’s sequencers are currently trusted not to collect MEV, but with a distributed set of sequencers, some could potentially front-run or sandwich user transactions or else they would need to come to consensus on transaction ordering, which could add latency to transactions and harm the core UX advantage of having near-instant transaction receipts or result in greater overhead costs for the rollup.

• Permissionless validation may subject the rollup to delay attacks. The security of the rollup requires just one honest verifier to check that the proposer posted the correct L2 state on mainnet (1-of-N honesty assumption). While having more parties that can submit fraud proofs is an important redundancy for security, permissionless validation where anyone can submit a fraud proof would potentially subject rollups to Denial-of-Service attacks from malicious parties aiming to delay finalization of transactions on the L1.

Several different approaches to decentralizing sequencers are being explored, some of which include making changes to the ordering algorithms and sequencer selection methodology (i.e., Proof-of-Authority, auction-based, stake-based using own rollup token, distributed validator technology, etc.) and changes to the network architecture or adoption of other technologies that may outsource certain responsibilities to other protocols (i.e., based rollups or shared sequencing models). The different approaches will have different economic and structural implications for rollups including MEV protection, governance, and interoperability or composability across multiple rollup chains. Research is still being conducted across these approaches to decentralize the sequencer on how to effectively manage some of the security trade-offs, overhead costs and UX considerations (we will explore some of these approaches in greater detail in a separate report).

Future plans / Areas of Exploration related to Decentralizing Operators

Optimism

Optimism’s adoption of Cannon’s new fraud proof system will have timing implications for expanding the set of proposers/verifiers. In Optimism’s docs on protocol specs, they share some specifics around how to eventually decentralize the sequencer, which will first involve having a single sequencer role at a time that will rotate among a set of sequencers. “The precise mechanic for sequencer rotation is not yet finalized” but will involve: (i) an economic mechanism that creates a competitive market for sequencing, and (ii) a governance mechanism to keep sequencers aligned with the long-term health of the network. The next step would then be to support multiple concurrent sequencers.

However, as the Optimism Collective pushes for greater adoption of the OP Stack by a growing number of networks, the Optimism Foundation aims to explore cross-chain interoperability solutions to unite OP Stack chains under the collective Superchain as a long-term goal after decentralization of OP Mainnet.

The Foundation has introduced several Foundation Missions, which are request for proposals (RFPs) for projects to build upon the core infrastructure of Optimism. In addition to the proposals from O(1) Labs and RISC Zero to integrate ZKPs mentioned earlier, the OP Collective has also accepted a proposal from Espresso & Caldera to build the OP Stack’s Leader Election proof-of-concept with the goal of bringing decentralized sequencing to the OP Stack – as of 9/8/23, the Espresso Sequencer testnet has been integrated with the OP Stack (note: the Espresso team is also collaborating with Offchain Labs on a shared sequencing solution as explained below). View the Github for other RFPs from the Optimism Foundation and other ecosystem contributions.

Arbitrum

Offchain Labs states in their docs that “overtime, we expect governance to expand the whitelist and eventually be removed entirely” and that they eventually plan to replace the single Sequencer with a distributed committee of Sequencers who come to consensus on transaction ordering.

The BOLD dispute protocol introduced by Offchain Labs discussed earlier also aims to address the risks of DoS attacks so that submitting fraud proofs can be permissionless (an improvement from the current whitelisted setup).

In March 2023, Offchain Labs published a blog post on a new proposed transaction ordering policy for Arbitrum called Time Boost, which proposes adding a time boost to the FCFS ordering policy (0.5 seconds) to prevent “latency racing behavior” where MEV searchers spend significant resources to get closer to the sequencer for a competitive edge in getting transactions included. Offchain Labs notes that they would want a transaction ordering policy to have properties including: (i) secret mempool to prevent front-running, (ii) low latency, (iii) short-term bidding to prevent latency racing behavior that could advantage the most resourceful organizations, and (iv) compatible with decentralization so the policy can be adapted to work with a distributed sequencer set in the future.

On 9/11/23, Offchain Labs announced that they are working with Espresso (who is already working closely with the Optimism team) “to bring a production-ready, open-sourced, and distributed implementation of Timeboost that can be adopted by any network and can integrate directly with the Espresso Sequencer.” The teams emphasized in their announcement that they aim to provide Timeboost and shared sequencing support not just to Arbitrum chains but to all Ethereum rollups.

Safety Mechanisms, Governance, and Admin Controls

Along with efforts to incorporate robust fraud proof systems and decentralize operators, both Optimism and Arbitrum have implemented several safety mechanisms or exit options to users for protection of their assets in case of unplanned network downtime, sequencer failure or censorship, or other cases of operator failure:

• ‘Force inclusion’ of transactions on the L1. If the sequencer is failing to post transaction batches or if they are withholding specific transactions from posted batches on the L1, rollup users may have the ability to force include transactions from L2 to L1 after a certain amount of time has passed from transaction submission to the sequencer.

  • Optimism (post-Bedrock) enables the ability to force include transactions on the L1 after 12 hours from submission to the sequencer (pre-Bedrock, Optimism users could submit transactions to an L1 queue to be posted later by the Sequencer in case of network downtime, but they lacked censorship-resistance as they could not bypass the Sequencer for force inclusion on the L1).

  • On Arbitrum, forced inclusion becomes available to users after 24 hours of transaction submission to the sequencer.

• External actors that can publish L2 state roots on L1 / submit fraud proofs in case of proposer failure. In these instances, transactions may still be processed on L2, but they may not fully settle on L1 (lacking ‘hard finality’), which restricts withdrawals. Most sequencer operators on rollups are also responsible for publishing L2 state roots on L1, but in the event of failure, rollups should have a list of external actors that can step in as backups, if needed.

  • Optimism users currently have limited recourse in case of proposer failure as publishing L2 state roots on L1 is handled solely by a single centralized operator.

  • Arbitrum enables anyone to become a proposer after ~6d 9h of inactivity from the current set of 13 whitelisted Proposers.

Governance and Permissioned Roles

After launching the OP and ARB tokens, both Optimism and Arbitrum have built out governance systems to facilitate community-driven management of the protocols and ecosystems. Both protocols have a working Constitution in place that outlines the governing provisions and the principles for the governance systems.

The Optimism Collective splits governance into two parties: (i) the Token House, which votes on grant program distributions and protocol upgrades based on token-voting governance, and (ii) the Citizen’s House, responsible for retroactive public goods funding (RetroPGF) where voting power relies on identity-based governance where one elected Citizen has just one vote. Any protocol upgrades approved by the Token House are subject to a veto by the Citizen’s House. Governance of Optimism is guided by the Collective’s Working Constitution as well as the Collective’s Operating Manual which outlines the authority and responsibilities of all governing bodies. The Optimism Foundation is responsible for “stewarding the early evolution of Collective self-governance”.

The Arbitrum DAO allows ARB token holders to vote on DAO proposals (AIPs) where the weight of any voter is proportional to the amount of ARB tokens that they hold/represent. The Arbitrum DAO Constitution, which sets the rules for how the DAO will operate, has already been amended since its adoption following a DAO vote.

The Optimism Collective and the Arbitrum DAO enable token holders to approve upgrades to the protocol, though final decisions for significant actions approved by the DAOs may still be overruled by certain privileged parties. These privileged parties also have certain administrative controls such as the ability to quickly push upgrades without notice. This presents a clear risk, as described in the Optimism post referenced above, and while ideally this upgrade capability would only be used to address critical bugs, it could also be abused to effectively steal user funds by making changes to system contracts (i.e., the bridge contract or storage contracts).

Eventually, both rollup teams aim to eventually limit the roles of these privileged parties with the end goal of having a fully decentralized, permissionless and trustless rollup. Progressive steps to decentralize control/upgradeability of the rollups may include expansion of the set of multisig participants (likely evolving from a small group of core developers to a ‘Security Council’ or community-controlled multisig comprised of a larger set of diverse participants). The capabilities of any such Security Council should be confined to pushing upgrades to address critical system vulnerabilities only. Any other routine upgrades should be finalized by the DAO and put behind a time-lock to provide users with sufficient time to exit the system in case of malicious code upgrades.

• Optimism is currently secured by a 5-7 multisig managed by an anonymous set of individuals, which, according to the team, is to protect their identities and to make the multisig more difficult to compromise. The multisig controllers can upgrade contracts without delay. See Optimism’s OPerating Manual for more detail on various types of governance proposals and their approved thresholds.

• With the launch of the ARB token in March 2023, Arbitrum transitioned its security from a 4-6 multisig (presumably mostly controlled by Offchain Labs members) to a 9-12 multisig controlled by a Security Council comprised of known, trusted individuals including several members outside of Offchain Labs, which are then divided into two cohorts of 6 members (for non-critical routine upgrades, only 7-12 Security Council signatures are required). Election cycles for the Arbitrum DAO to determine the trusted members of one of the two Security Council cohorts are slated to occur every six months – the first round of elections started on September 15 following the approval of AIP-6.

  • DAO-initiated votes to upgrade contracts are subject to delay, allowing time for users to exit before the proposal is executed, though any approved proposals can be cancelled by the Security Council, which can also upgrade contracts without delay. Read this post from the Arbitrum Foundation for more detail on the Security Council processes and responsibilities.

Security & Governance Roadmap Items

Optimism

Optimism laid out its roadmap to decentralizing in a blog post from February 2023, Optimism’s Path to Technical Decentralization, which laid out several target dates for decentralization goals:

• OP Labs has stated that they hope to deliver what they consider to be ‘baseline decentralization’ by the end of this year, which includes permissionless output proposals and relinquishing custody of the bridge upgrade keys to a security council.

• They also noted in their post that “completing the precursors for fault proof decentralization will be a focus into 2024”.

• After achieving both these milestones, they then plan to shift their focus to “other high-level themes such as deploying additional proof systems on Mainnet, phasing out the attestor network, removing upgrade keys, and decentralizing the sequencer.”

In July 2023, the Optimism Collective introduced the “Law of Chains”, a common set of standards and guiding principles for Optimism and other protocols included in the Superchain. The Law of Chains is meant to serve as an opt-in social contract that applies to users, Chain Governors (parties responsible for deploying or configuring an OP Chain, and Chain Servicers (sequencers, proposers, and challengers). The initial version of the Law of Chains emphasizes user protections – for example, the User Protection to security, uptime, and liveness would be violated by a Chain Servicer that “Illegitimately censors, reorders, or limits transactions (i.e., by running off-chain sequencing code that is not approved by Optimism Governance, or by colluding with L1 validators to artificially inflate sequencer batch submission costs) in order to extract a profit or violate User Protections.”

As the second core developer to the OP Stack after OP Labs, Base committed to assisting the Optimism Collective in forming a Security Council to execute upgrades for the Superchain, aiming to submit a governance proposal to perform this transition in “early 2024”. Aside from the Security Council, Base is also actively contributing to technical improvements towards decentralization goals, most notably fraud proofs, but also building Pessimism to improve technical risk monitoring and safety of the OP Stack. Base is launching with a ‘2-2 layered multisig’ for contract upgrades shared by the Optimism Foundation and Base Upgrade multisigs as well as a ‘1-2 challenger key structure’ that enables the Base team or Optimism Foundation to delete invalid output proposals if needed.

Arbitrum

At launch, Offchain Labs considered Arbitrum to be in “Mainnet Beta” given the various levels of control retained by privileged parties that include contract upgradeability, ability to pause the system, and validator whitelisting. The docs originally stated (have now been removed): “We believe temporarily maintaining these capabilities is the only responsible way to launch while we continue to harden our system; as we progressively decentralized, these controls will be phased and eventually eliminated entirely.”

The Security Council currently has the power to execute upgrades without delay for emergency actions. Over time as Arbitrum’s technology matures and the risk of facing critical vulnerabilities is reduced, the Arbitrum DAO can curtail or eliminate the Security Council's power to perform Emergency Actions via approval and implementation of a Constitutional AIP.

Stages Framework to Assess Rollup Maturity & Decentralization Progress

In November 2022, Vitalik published a blog post Proposed milestones for rollups taking off training wheels, which categorizes rollups into three separate stages depending on their level of centralized control (aka “training wheels required”), as a way to assess rollup tech maturity and progress towards decentralizing.

Building on top Vitalik’s framework mentioned above, L2Beat released their own framework for evaluating the maturity of rollups called Stages, which includes a series of qualifications and detailed criteria for rollups at each stage. We summarize some of the key risk factors and components that go into their proposed rollup maturity scoring systems:

According to L2Beat’s assessment, Arbitrum currently leads as a ‘Stage 1’ rollup vs. Optimism which is still at ‘Stage 0’. Arbitrum currently leads ALL general-purpose L2s as meeting the ‘Stage 1’ criteria (dYdX and zkSync Lite are also listed as Stage 1 though the functionality of each is limited to just exchange or payments applications). L2Beat’s scoring assessment for Optimism and Arbitrum along the five scoring categories is summarized below:

According to L2Beat, Optimism will have to address the following issues to move from Stage 0 to Stage 1:

• The proof system is still under development

• Users’ withdrawals can be censored by the permissioned operators

• Upgrades executed by actors with more centralized control than a Security Council provide less than 7d for users to exit if the permissioned operator is down or censoring.

Arbitrum, which already meets the Stage 1 criteria listed above, will have to address the following items before it can move from Stage 1 to Stage 2:

• Fraud proof submission is open only to whitelisted actors

• Upgrades unrelated to on-chain provable bugs provide less than 30d to exit

• The Security Council’s actions are not confined to on-chain provable bugs

Other security concerns with rollups

Compared to a single operator setup that handles all core functions (i.e., sequencing, batch posting, proposing state roots, and verification), a rollup with a decentralized operator setup provides some redundancies to strengthen the resilience of rollups and protects against malicious actions by the controlling party. In addition, having working fraud proofs, the capabilities to self-propose and force inclusion of transactions to the L1, or other escape hatches will provide user protection against potential misbehavior by trusted operators.

In the ideal case, these safety measures are never needed. However, their presence may still provide rollup builders and users with more comfort knowing that these rollup safety measures are well-understood, reliable security mechanisms, or that whatever approach used to decentralize the sequencer set will not subject users to an unfavorable risk trade-off with unanticipated vulnerabilities.

As it stands today, there has not been much empirical evidence of the core security protections adopted by rollup teams working in practice – there have been limited instances of successful fraud proofs defending against invalid state roots and Optimism and Arbitrum have never experienced extended periods of sequencer failure or proposer failure for the force-include or self-propose functions to be activated based on current adopted parameters (i.e., > 12-24 hours of an offline / censoring sequencer or > 6+ days of inactivity, respectively).

We also note that for categories such Sequencer Failure (graded green as part of L2Beat’s framework), simply having force-inclusion as a failsafe option may not be sufficient for most end users that are still exposed to other meaningful risks. For DeFi users (currently most addresses across rollups), exiting to the L1 isn’t very practical or feasible when holding time-sensitive trading positions or when holding rollup-native assets that cannot be bridged back to Ethereum. Ideally, over time the time requirements to call any of these failsafe functions would be shortened considerably from their existing intervals and would also be made easily available to non-technical users.

While the Stages frameworks by Vitalik and L2Beat provide important technical milestones to keep the primary development teams behind rollups accountable to their communities and users, they do not fully reflect some the inherent security risks with using rollups, which include software or code bugs. Arbitrum, for example, has experienced at least three instances this year that have temporarily impacted the finalization of transactions:

• 5/12/23 – Prysm bug affected Ethereum mainnet finality, impacting all rollups

• 6/7/23 – software bug where the sequencer was not refunded after batch reverted

• 8/17/23 – geth bug that prevented batch poster from escalating transaction fee during congestion period

The consequences of these incidents were limited to withdrawals reliant on L1 finality – even though batch posting was impacted, Arbitrum’s network was still operational as the sequencer continued to accept and provide “soft” confirmations to users. Having a decentralized operator set would not have been useful in these instances if all operators were built upon the same software and followed the same rules as the central operator. There is certainly merit in Optimism’s stated objective of eventually supporting multi-client, multi-proof implementations – still, before Optimism can have multiple proof implementations, they first need to have one functioning proof system in production, which they have yet to deliver.

Outlook

Rollups are core to Ethereum’s technical roadmap, and they need to be rightfully held to high security and decentralization standards by the Ethereum community. Yet, as it stands today, all rollups rely on centralized setups that lack important security protections for their users. Rollup users are inherently placing a lot of trust in the central parties that operate the protocols.

As it relates to fraud proofs and efforts to decentralize, the two leading optimistic rollup protocols seem to be appropriately named: the name ‘Arbitrum’ is based on the word “arbitration”, suggesting dispute resolution is core to identity of the protocol – Offchain Labs has implemented a functional fraud proof system on Arbitrum since mainnet launch, and were the first rollup team to open up proposing and verification to a permissioned set of validators. More recently, they introduced a solution to enable permissionless validation with BOLD. On the other hand, Optimism is seemingly optimistic that it can continue to operate and push adoption of the OP stack without having working fraud proofs and while maintaining a centralized operator set up.

In Optimism’s defense for not having implemented fraud proofs yet, they are set on an ambitious path with the Superchain vision, and they view the proof system as the global communication layer to connect all OP Stack chains. The OP Labs team has been working on the Cannon fault proof system ever since disabling fraud proofs in November 2021 and appear to have given it considerable thought. And with their open-source policy, they have been able to outsource research to third parties for viable solutions with various proof mechanisms including ZKPs or decentralized sequencing so that they could potentially be adopted into the OP Stack in the future. For Optimism, decentralization goals are not viewed independently of cross-chain interoperability aspirations with the Superchain.

Still, no matter how ambitious the end goals are for the protocol, it’s important that the protocol meets some basic security requirements, especially if the technology is seeing rapid adoption like in the case of Optimism with the OP Stack. L2Beat’s framework maps out some of goals that all rollups should strive for and highlights some of the shortcomings with the current implementations of different protocols to help keep the core development teams accountable. The path for rollups to decentralize is long and difficult, but it’s a journey that all should strive for.