Skip to main content

The Sequencer and Censorship Resistance

The Sequencer is a pivotal component of the Arbitrum stack, responsible for efficiently ordering and processing transactions. It plays a crucial role in providing users with fast transaction confirmations while maintaining the security and integrity of the blockchain. In Arbitrum, the Sequencer orders incoming transactions and manages the batching, compression, and posting of transaction data to the parent chain, optimizing costs and performance.

Sequencer operations

In this section, we will explore the Sequencer's operations in detail. The topics covered include:

By examining these aspects, you will understand the Sequencer’s role within the Arbitrum ecosystem, including how it enhances transaction throughput, reduces latency, and maintains a fair and decentralized network.

Sequencing and broadcasting​

The Sequencer feed is a critical component of the Nitro architecture. It enables real-time dissemination of transaction data as they are accepted and ordered by the Sequencer. It allows users and nodes to receive immediate updates on transaction sequencing, facilitating rapid transaction confirmations and enhancing the network’s overall responsiveness.

How the Sequencer publishes the sequence​

The Sequencer communicates the transaction sequence through two primary channels:

  1. Real-time sequencer feed: A live broadcast that publishes transactions instantly as they are sequenced. Nodes and clients subscribed to this feed receive immediate notifications, allowing them to process transactions without delay.
  2. Batches posted on the parent chain: At regular intervals, the Sequencer aggregates transactions and posts them to the parent chain for finality. Refer to the Batch posting section for detailed information on this process.
Sequencer feed

Real-time Sequencer feed​

The real-time feed represents the Sequencer’s commitment to process transactions in a specific order. By subscribing to this feed, nodes and clients can:

  • Receive immediate notifications: Get instant updates on newly sequenced transactions and their ordering.
  • Process transactions promptly: Utilize the sequenced transactions to update the state locally, enabling rapid application responses and user interactions.
  • Benefit from soft finality: Gain provisional assurance about transaction acceptance and ordering before the parent chain reaches finality.

This mechanism is particularly valuable for applications requiring low latency and high throughput, such as decentralized exchanges or real-time gaming platforms.

Soft finality and trust model​

“Soft finality” refers to the preliminary confirmation of transactions based on the Sequencer’s real-time feed. Key aspects include:

  • Dependence on Sequencer integrity: The feed’s accuracy and reliability depend on the Sequencer operating honestly and without significant downtime.
  • Immediate user feedback: Users can act on transaction confirmations swiftly, improving the user experience.
  • Eventual consistency with the parent chain: While the real-time feed provides quick updates, ultimate security, and finality are established once transactions are posted to and finalized on the parent chain. Refer to the Finality section for an in-depth discussion.

Understanding this trust model is essential. While we expect the Sequencer to behave correctly, users and developers should know that soft finality depends on this assumption. In scenarios where absolute certainty is required, parties may wait for transactions to achieve finality on the parent chain.

Role of the Sequencer feed in the network​

The Sequencer feed serves several vital functions within the Arbitrum ecosystem:

  • State synchronization: Nodes use the feed to keep their state up to date with the latest network state, ensuring consistency across the decentralized platform.
  • Application development: Developers can build applications that respond instantly to network events, enabling features such as live updates, instant notifications, and real-time analytics.
  • Ecosystem transparency: The feed promotes transparency and trust within the community by providing visibility into transaction sequencing and network activity.

Considerations and limitations​

While the Sequencer feed offers significant advantages, consider the following:

  • Reliance on Sequencer availability: The effectiveness of the real-time feed depends on the Sequencer’s uptime and responsiveness. Network issues or Sequencer downtime can delay transaction visibility.
  • Provisional nature of soft finality: Until transactions reach finality on the parent chain, there is a small risk that the provisional ordering provided by the feed could change in exceptional circumstances.
  • Security implications: For high-stakes transactions where security is paramount (e.g., deposits and withdrawals on centralized exchanges), users may prefer to wait for confirmation on the parent chain, even with the longer latency.

Developers and users should design their applications and interactions with these factors in mind, choosing the appropriate balance between speed and certainty based on their requirements.

Delayed messages on the Sequencer feed​

As illustrated in the diagram above, the Sequencer feed not only sends child-chain transactions posted directly to the Sequencer, but also incorporates parent-chain-submitted child-chain transactions. These include child chain messages submitted on the parent chain and retryable transactions. The Sequencer agent monitors the finalized messages submitted to the parent chain’s Delayed Inbox contract. Once finalized, it processes them as incoming messages to the feed, ensuring they are added as ordered transactions.

The Nitro node can be configured to add delayed inbox transactions immediately after they are submitted to the parent chain, even before finalization. However, this approach introduces the risk of a reorg on the child chain—if the transaction fails to finalize on the parent chain. To mitigate this risk, on Arbitrum One and Nova, the Sequencer includes these transactions in the feed only after they are finalized on the Ethereum chain.

You can also explore how the feed sends incoming messages via WebSocket and learn how to extract message data from the feed on this page: Read Sequencer Feed.

Batch posting​

Batch posting is a fundamental process for the Sequencer's operation in Arbitrum. It involves collecting multiple child chain transactions, organizing them into batches, compressing the data to reduce size, and sending these batches to the Sequencer Inbox contract on the parent chain. This mechanism is crucial for ensuring that transactions are securely recorded on the parent chain blockchain while optimizing for costs and performance.

In this section, we will explore the batch posting process in detail, covering the following topics:

  • Batching: How the Sequencer groups incoming transactions into batches for efficient processing and posting.
  • Compression: The methods used to compress transaction data, minimizing the amount of data that needs to be posted on the parent chain and thereby reducing costs.
  • Sending to Sequencer Inbox contract: The procedure for submitting compressed batches to the Sequencer Inbox contract on the parent chain, ensuring secure and reliable recording of transactions.

This section covers batch posting from the Sequencer's side. For the batch poster's internals, see The batch poster. That page traces one batch from the transaction streamer to the parent chain transaction.

Understanding batch posting is essential for grasping how Arbitrum achieves scalability and cost-efficiency without compromising security. By delving into these subtopics, you’ll gain insight into the Sequencer’s role in optimizing transaction throughput and minimizing fees, as well as the innovative solutions implemented to address the challenges of parent chain data pricing.

Batching and compression​

The Sequencer in Arbitrum is critical in collecting and organizing child chain transactions before posting them to the parent chain. The batching process is designed to optimize for both cost efficiency and timely transaction inclusion.

Batching

Transaction collection and ordering:​

  • Continuous reception: The Sequencer continuously receives transactions submitted by users.
  • Ordering: Transactions are ordered by the order in which they are received, ensuring deterministic transaction order. Chains can override this default first-come-first-served policy with Timeboost, which auctions an "express lane" for faster inclusion.
  • Buffering: Received transactions are temporarily stored in a buffer awaiting batch formation.

Batch formation criteria:​

  • Size thresholds: Batch formation occurs when accumulated transactions reach a predefined size limit. This limit ensures that the fixed costs of posting data to the parent chain are amortized over more transactions, improving cost efficiency.
  • Time constraints: The Sequencer also monitors the elapsed time since the last batch update to prevent undue delays. Upon reaching the maximum time threshold, the Sequencer will create a batch with the transactions collected so far, even if the batch doesn’t meet the size threshold.

Batch creation process:​

  • Aggregation: Once the batch-formation criteria (size or time threshold) are satisfied, the Sequencer aggregates buffered transactions into a single batch.
  • Metadata inclusion: The batch includes all necessary metadata for all transactions.
  • Preparation for compression: Batch preparation for the compression stage begins, with techniques that minimize data size before posting to the parent chain.

The batching mechanism allows the Sequencer to efficiently manage transactions by balancing the need for cost-effective parent chain posting with the requirement for prompt transaction processing. By strategically grouping transactions into batches based on size and time criteria, the Sequencer reduces per-transaction costs and enhances the overall scalability of the Arbitrum network.

Compression​

The Sequencer employs compression when forming transaction batches to optimize the data and cost of batches posted to the parent chain. Arbitrum uses the Brotli compression algorithm due to its high compression ratio and efficiency, crucial for reducing parent chain posting costs.

Compression

Compression level in the Brotli algorithm​

Brotli’s compression algorithm includes a parameter: compression level, which ranges from 0 to 11. This parameter allows you to balance two key factors:

  • Compression efficiency: Higher levels result in greater size reduction.
  • Computational cost: Higher levels require more processing power and time.

As the compression level increases, you can achieve better compression ratios at the expense of longer compression times.

Dynamic compression level setting​

The compression level on Arbitrum is dynamically adjusted based on the current backlog of batches waiting to be posted to the parent chain by the Sequencer. In scenarios where multiple batches are queued in the buffer, it is possible to adjust the compression level to improve throughput dynamically. When the buffer becomes overloaded with overdue batches, the compression level decreases. For the exact backlog thresholds and how compression interacts with parent chain pricing, see Compression levels.

This trade-off prioritizes speed over compression efficiency, enabling faster processing and transmission of pending batches. Doing so clears the buffer more quickly, ensuring smoother overall system performance.

Now that transactions are batched and compressed, they pass to the batch poster to transmit them to the parent chain.

Submitting to the Sequencer Inbox contract​

After batching and compressing transactions, the Sequencer posts these batches to the parent chain to ensure security and finality. This process involves the batch poster, an Externally Owned Account (EOA) controlled by the Sequencer. The batch poster is responsible for submitting the compressed transaction batches to the Sequencer Inbox contract on the parent chain. Batch posting costs are reimbursed through ArbOS's parent-chain pricer — see Parent chain gas pricing and ArbOS state.

The Sequencer uses two primary methods to send batches to the parent chain, depending on whether the chain supports EIP-4844 (Proto-Danksharding) and the current network conditions. For how the batch poster encodes a batch for each method and self-checks it before sending, see The batch is wrapped for the parent chain.

Submit to Sequencer inbox

1. Using blobs with addSequencerL2BatchFromBlobs​

  • Default approach: When the parent chain supports EIP-4844, the Sequencer utilizes blob transactions to post batches efficiently.
  • Method: The batch poster calls the addSequencerL2BatchFromBlobs function of the Sequencer Inbox contract.
  • Process:
    • Batch data gets included as blobs—large binary data structures optimized for scalability.
    • The transaction includes metadata about the batch but does not include the batch data itself in the calldata.
  • Benefits:
    • Cost efficiency: Blobs allow cheaper data inclusion than calldata, reducing gas costs.
    • Scalability: Leveraging blobs enhances the network's ability to handle large volumes of transactions.

2. Using calldata with addSequencerL2Batch​

  • Alternative approach: If the Blob Base Fee is significantly high or the blob space is constrained during batch posting, the Sequencer may opt to use calldata.
  • Method: The batch poster calls the addSequencerL2Batch function of the Sequencer Inbox contract.
  • Process:
    • The compressed batch transactions are included directly in the transaction's calldata.
  • Considerations:
    • Cost evaluation: The Sequencer dynamically assesses whether using calldata is more cost-effective than blobs based on current gas prices and blob fees.
    • Compatibility: If the parent chain does not support EIP-4844, this method is the default and only option for batch posting.
note

The Sequencer continuously monitors network conditions to select the most cost-effective batch posting method, ensuring optimal operation under varying conditions.

Authority and finality​

  • Exclusive access: Only authorized batch posters can call these methods on the Sequencer Inbox contract. The contract gates access through its isBatchPoster mapping, a role distinct from the Sequencer, though the same party typically operates both. This exclusivity ensures that no other party can include messages directly.
  • Soft-confirmation receipts: The Sequencer’s unique ability to immediately process and include transactions allows it to provide users with instant, “soft-confirmation” receipts
  • Parent chain finality: Once batches post, the transactions achieve parent-chain-level finality, secured by the parent chain’s consensus mechanism.

By efficiently sending compressed transaction batches to the Sequencer Inbox contract using the most cost-effective method available, the Sequencer ensures transactions are securely recorded on the parent chain. This process maintains the integrity and reliability of the network, enabling users to perform fast, secure transactions.

Finality​

Arbitrum offers two levels of finality:

  1. Soft finality: The Sequencer’s real-time feed confirms transactions almost instantly, but those confirmations are provisional. They rely on the Sequencer sequencing honestly and staying available.
  2. Hard finality: The Sequencer's batches are posted to and finalized on the parent chain, and the batch's transactions inherit the parent chain's security. Final settlement happens when the Rollup protocol confirms the containing assertion, after the BoLD challenge period.

Posting a batch is not itself final settlement. The transaction data becomes available and inherits the parent chain’s data-layer security, but the resulting child chain state settles only once an assertion is confirmed.

For the full treatment—latency at each stage, the trust model behind each level, force inclusion, AnyTrust data availability, and guidance on which level your application should wait for—see Finality.

Censorship Timeout​

As mentioned in the original Arbitrum BoLD Forum Post, the initial release of Arbitrum BoLD will come with a feature called ”Censorship Timeout” (originally called “Delay Buffer”). For Arbitrum One and Nova, it is proposed that this feature be enabled by default alongside BoLD’s upgrade.

Censorship Timeout aims to limit the negative effects of:

  • Prolonged sequencer censorship, and/or,
  • Unexpected sequencer outages.

How the Censorship Timeout feature works​

To explain how this feature improves the security of chains settling to Arbitrum One and Nova, consider a scenario where an L3's parent chain sequencer (the L2 sequencer) is censoring or offline. In such a case, every assertion and/or sub-challenge move would need to wait 24 hours before bypassing the L2 sequencer (using the SequencerInbox's forceInclusion method described here). In this scenario, challenge resolution would be delayed by a time t where t = (24 hours) * number of moves for a challenge. To illustrate with sample numbers, if a challenge takes 50 sequential moves to resolve, then the delay would be 50 days.

The Censorship Timeout feature mitigates this by lowering the force inclusion threshold when unexpected delays in message inclusion occur due to one (or all) of the above-mentioned cases of censorship or a sequencer outage, enabling entities to make moves without the 24-hour delay-per-move.

The force inclusion window is the lesser of delayBuffer and delayBlocks, where delayBlocks is a constant currently set to 24 hours, and delayBuffer ranges from 30 minutes to 48 hours.

The delayBuffer value “grows and shrinks” depending on how long the Sequencer is offline or censoring transactions. As a way to measure this behavior, the delayBuffer is decremented by the difference between a delayed message’s delay beyond the threshold and how long it has been delayed (i.e., when some delayed messages are delayed by more than the threshold, the difference between the messages’ delay and the threshold is removed from the buffer). For example, if the threshold is 30 minutes and a message was delayed by 32 minutes, the delayBuffer is decremented by 2 minutes. The threshold is set to 30 minutes on Arbitrum One and 1 hour on Arbitrum Nova.

The delayBuffer replenishes at a linear rate when the sequencer is operating correctly at a nominal rate of one minute for every 20 minutes in which no messages are delayed beyond the threshold.

Below are the initial, proposed parameter values for the Censorship Timeout feature for Arbitrum One and Nova:

  • delay buffer = 14400 parent chain (Ethereum) blocks (2 days)
  • threshold = 150 L1 Ethereum blocks (30 minutes) for Arbitrum One and 300 parent chain (Ethereum) blocks (one hour) for Arbitrum Nova
  • replenish rate = 5% (meaning one day is replenished every 20 days or roughly a 95% uptime)

We believe that the Censorship Timeout feature provides stronger guarantees of censorship resistance for Arbitrum chains—especially those that settle to Arbitrum One or Arbitrum Nova. As always, chain owners can decide whether to utilize this feature for their chain and can also change the default parameters as they see fit for their use case.

Decentralized fair sequencing​

Arbitrum’s long-term vision includes transitioning from a centralized Sequencer to a decentralized, fair sequencing model. In this framework, a committee of servers (or validators) collectively determines transaction ordering, ensuring fairness, reducing the influence of any single party, and making it more resistant to manipulation. By requiring a supermajority, this approach distributes sequencing power among multiple honest participants, mitigates the risks of front-running or censorship, and aligns with broader blockchain principles of enhanced security, transparency, and decentralization. The Timeboost ordering policy is designed to be compatible with decentralized sequencing.