Team 8: Decentralized Sequencing

  • Track Number: 8

  • Track Name: Decentralized sequencing

  • Challenge Statement: Lack of information for the Arbitrum DAO to make informed decisions on centralized vs decentralized sequencing.

  • Members: gets from Espresso, @sam.ng from Node Guardians, Hayden from @BlockworksResearch

  • Team Lead contact name or alias: @getsie

Abstract

Currently there is a lack of information for the Arbitrum DAO to make informed decisions regarding decentralizing the sequencer. Our proposed track sought to surface relevant information and recommend gradual steps toward decentralizing aspects of the Arbitrum sequencer, such as enabling faster bridging via decentralized preconfirmations.

Motivation

Arbitrum’s sequencer is centralized, and while this might serve the purposes of the community today, it is necessary for the DAO to consider the implications of decentralizing the sequencer. In addition, Offchain Labs and Espresso are collaborating on r&d towards decentralizing Timeboost, suggesting the necessity for the DAO to begin having such discussions.

Key Terms

Sequencer: entity responsible for collecting and ordering users’ transactions

Liveness (uptime):

  • the Arbitrum One chain keeps processing user transaction
  • censorship resistance i.e honest transactions get included in Arbitrum without bias towards individual users or applications.

Finality:

  • guarantee that a transaction does not revert
  • latency: time to achieve finality
  • pre-confirmation: a promise that a user’s transaction will eventually be a part of the finalized Arbitrum state. Can also be seen as a type of finality.

Rationale

The Arbitrum sequencer has two primary tasks: ordering transactions into blocks, and providing a guarantee that blocks won’t revert prior to posting a batch to Ethereum. In other words, the sequencer is in charge of building blocks and of providing a preconfirmation.

Block building entails choosing which transactions to include, thus a centralized sequencer has control over which transactions end up making it into the Arbitrum chain. This leads to the first critique: a lack of censorship resistance and neutrality.

Beyond censorship, the fact that only a single sequencer can build blocks means that if that sequencer goes down, the Arbitrum chain is effectively halted till the sequencer comes back online (barring using the escape hatch). This is commonly referred to as the liveness property of a protocol.

Decentralizing block building can thus improve upon the status quo, by improving the censorship resistance and liveness guarantees of Arbitrum.

The preconfirmation provided by the centralized sequencer provides best in class UX for the vast majority of transactions on Arbitrum, however, third-party bridges often don’t want to rely on this preconfirmation, especially for high volume transactions. This is to avoid the risk of an issue with the centralized sequencer causing a bridging transaction to revert, which can lead to an economic loss.

Instead, these bridges default to waiting for a batch that includes a bridging transaction from Arbitrum to finalize on Ethereum, which ensures that it wont revert. This is why third-party bridges often take 15+ minutes to bridge funds out of Arbitrum.

It is possible to retain centralized control over block building, but add a decentralized preconfirmation protocol to gradually decentralize the sequencer over time. We’d like to propose for the Arbitrum DAO to consider integrating decentralized preconfirmations as a first step towards decentralized sequencing. This imposes minimal changes to how the protocol presently works. Instead it can be seen as an additive layer of security.

As an example of how this might works, imagine a new consensus protocol similar to the one employed by the Ethereum L1, except this new consensus protocol reaches finality in a manner of seconds. Arbitrum blocks will then receive a preconfirmation from this new consensus protocol, prior to being posted to Ethereum. This allows third-party bridges to safely settle transactions in a matter of seconds. It is worth noting that Arbitrum can still maintain its 0.2s block time in this design.

By implementing decentralized preconfirmations as a first step, the DAO can improve UX around bridging, and give itself more time to explore the trade-off space related to completely decentralizing the sequencer. Below we’d like to introduce some of those trade-offs as a starting point for further discussion.

Tradeoffs

Centralized Sequencing:

Pros:

  • Already live today, no extra work needed.
  • Guarantees fast pre-confirmation (the speed at which you receive notification from your wallet when you submit a transaction on Arbitrum).

Cons:

  • Trust issues: Reliance on the sequencer not to censor or reorder transactions.
  • Increased downtime risk (which has occurred a few times in the past for Arbitrum).
  • Regulatory vulnerabilities.
  • Geographical centralization (co-location and regulatory risks)
  • Slower bridging for high-value transactions.

Decentralized Sequencing:

Pros:

  • Real-time liveness/censorship resistance: If one operator goes down or censors transactions, another can step in to ensure the chain continues processing transactions.
  • Practical liveness/censorship resistance: If the sequencer goes down and there are no other sequencers, users would need to force include their transactions (see this proposal). This would involve direct interaction with Ethereum, which is a) longer (24 hours) and b) more costly. In scenarios where time equals money, this could be very detrimental for certain users.
  • Regulatory: Regulatory guidance around centralized operators (even for permissionless systems) has not been provided. While there are no immediate requirements, this is an area to be mindful of going forward.
  • Ethos: Truly decentralized applications include broad community participation and ownership. Permissionless and decentralized operators further this goal.
  • Bridging: Faster finality for high value bridged transactions

Cons:

  • Potentially slower pre-confirmations
  • New code stack introduces potential new risks.

Desirability:

Linea Case Study: A few weeks ago, a hacker drained an application on Linea, causing the loss of user funds. The Linea team had to stop the sequencer to censor the hacker’s addresses. In this case, operating a centralized sequencer serves as a tool to mitigate the damage from exploits.

On the other hand, if there had been significant price movement during that period, lending protocols could not have liquidated positions, potentially causing bad debt - an undesirable outcome. This situation also highlights how, even though the hacker would have been able to fully drain users’ funds, decentralized sequencing could prevent a scenario in which other users accumulate bad debt.

These are trade-offs that the DAO should weigh when considering the implications of decentralizing the sequencer. However, we do know that the protocol takes a less opinionated stance with a decentralized sequencer. It is worth noting that merely decentralizing the preconfirmations has no impact on this question.

Potential Further Work

Offchain Labs and Espresso are already working on a decentralized version of Timeboost which can enable decentralized sequencing. This means that at some point the DAO will have to make a decision on this topic.

Our goal is to continue the work and discussions raised here and from an earlier GovHack proposal in order to scope a path toward potentially decentralizing the sequencer. The first step we introduce is decentralized preconfirmations for faster bridging. Other potential work includes:

  • Investigate the economics of centralized sequencing vs decentralized sequencing.
    • How will the protocol bootstrap and/or reward Timeboost operators?
    • Can we measure the economic trade-offs?
  • Highlight the mechanism design of centralized Timeboost, decentralized Timeboost, and Timeboost’s compatibility with Espresso.

Final thoughts

After discussing with community members and the expert panel at GovHack, we have decided to continue working on this proposal asynchronously. This effort will involve consulting with delegates, other community members, Offchain Labs, and Espresso. Our aim is to gather and present the necessary information to facilitate informed decision-making for the DAO.

3 Likes

I appreciate the thorough analysis and thoughtful approach presented in this proposal. @sam.ng The potential benefits of decentralizing the sequencer, such as improved censorship resistance, liveness guarantees, and faster bridging for high-value transactions, are compelling. However, it is crucial to carefully weigh these benefits against the potential drawbacks, such as slower pre-confirmations and new code stack risks.
To ensure a well-informed decision, I would like to see further investigation into the economics of centralized vs. decentralized sequencing, as well as a detailed exploration of the mechanism design of centralized Timeboost, decentralized Timeboost, and Timeboost’s compatibility with Espresso. This information will help the DAO better understand the implications of decentralizing the sequencer and make a more informed decision.
Additionally, I would encourage the team to engage in open and transparent discussions with the community, delegates, and other stakeholders to gather diverse perspectives and insights. This collaborative approach will help build consensus and ensure that the final decision aligns with the long-term vision and values.