Abstract

This constitutional AIP proposes upgrading both Arbitrum One and Arbitrum Nova to use a new dispute resolution protocol, called Arbitrum BoLD, and the addition of Infura to Arbitrum Nova’s validator whitelist. Specifically, this AIP combines the following two temperature check votes:

BoLD - permissionless validation for Arbitrum

This proposal requests the ArbitrumDAO to approve the upgrade of Arbitrum One and Arbitrum Nova to utilize Arbitrum BoLD: a new dispute resolution protocol that is designed to replace the currently deployed dispute resolution protocol. If this upgrade is approved, validators on Arbitrum One and Arbitrum Nova can use Arbitrum Nitro software to post assertions and to challenge invalid assertions. Note validation will be permissionless on Arbitrum One but remain permissioned on Arbitrum Nova (also elaborated on further down in this proposal).

This upgrade will ensure that any single honest party can always successfully defend against malicious claims to an Arbitrum chain’s state. Arbitrum BoLD represents the next step on the journey to having the Arbitrum technology stack being recognized as a Stage 2 Ethereum rollup.

The implementation of BoLD has been thoroughly tested and audited to ensure both its effectiveness and safety. Note that Orbit chains may choose to adopt Arbitrum BoLD as soon as the BoLD upgrade is generally available and formally supported, regardless of whether the ArbitrumDAO approves this proposal or not.

Whitelist Infura’s Nova Validator

This proposal requests that the ArbitrumDAO whitelist Infura’s Nova validator.

The addition of Infura to Arbitrum Nova’s validator whitelist will increase the number of active validators on Arbitrum Nova, enhancing the network’s overall security, stability, and reliability. Infura has a proven track record in running blockchain infrastructure and has already been participating on Arbitrum Nova’s Data Availability Committee (DAC), but was not previously whitelisted as a validator.

Motivation

The ArbitrumDAO should consider approving this AIP because both the adoption of Arbitrum BoLD and the whitelisting of Infura’s Arbitrum Nova validator will enhance the network’s security, stability, and resiliency. Both of these proposed changes will benefit all Arbitrum users, Arbitrum node operators, dApps on Arbitrum, and Arbitrum bridges.

Specifically, passing this governance proposal would mean that Arbitrum One and Arbitrum Nova will gain the following benefits:

• Permissionless validation for Arbitrum One - Today, the critical role of being a validator for Arbitrum One is currently restricted to a permissioned set of validators in order to prevent delay attacks on the current rollup protocol - a class of attacks where malicious actors can delay assertion confirmations if they, the malicious actors, are willing to sacrifice their stakes. However, since BoLD mitigates the risks of delay attacks using a different mechanism (i.e. by enforcing a fixed upper time bound on dispute resolution), reliance on a permissioned set of validators is no longer necessary. Therefore, passing this AIP and implementing BoLD to secure Arbitrum One would effectively enable permissionless validation, marking a key milestone for Arbitrum chains to be recognized as Stage 2 Rollups, a critical part of Arbitrum’s journey to full decentralization. Please see the dedicated section and recommendation for Arbitrum Nova below.
• Fixed delay time for assertion confirmation - The current dispute protocol for Arbitrum chains has a ~6.4 day challenge period, during which validators can dispute claims about the chain’s state. These claims about the chain’s state are called “assertions”. While assertions are confirmable after 1 challenge period, malicious actors can open many challenges to delay confirming these assertions in a type of attack known as a delay attack. BoLD guarantees that all assertions, if there is a dispute using the validating bridge contract, will be confirmed within a fixed time window of 2 challenge periods (~6.4 days each), 2 day grace period for the Security Council to intervene, and a small delta for computing challenges.
• Increased censorship resistance for Orbit L3s settling to Arbitrum One or Arbitrum Nova - As mentioned in the original Arbitrum BoLD Forum Post, the initial release of BoLD will come with a feature called ”Censorship Timeout” (originally called “Delay Buffer”). The Censorship Timeout feature provides stronger guarantees of censorship resistance for Arbitrum chains - especially those that settle to Arbitrum One and Nova - by introducing a programmatic way for the parent chain contracts to lower the force inclusion time window in cases where the L2 sequencer is offline or censoring. For Arbitrum One and Arbitrum Nova, it is proposed that this feature be enabled by default alongside BoLD’s upgrade. Please see the dedicated section on Censorship Timeout for more details.
• Preserves the current security primitives with a Safety-First approach - In the event of a dispute using BoLD, there is a 2 day “grace period” (also called the “challenge grace period”) that is applied to the winning assertion before it is confirmed. This time window allows time for the Security Council to intervene if there are any severe bugs in the BoLD contracts that would cause an invalid assertion to confirm.The duration of the grace period is configurable by the ArbitrumDAO and would initially be set to 2 days.
• Improved network stability and reliability for Arbitrum Nova with the addition of a new validator to the whitelist - The addition of Infura to Arbitrum Nova’s validator whitelist will increase the number of active validators on Arbitrum Nova, enhancing the network’s overall security, stability, and reliability. Infura has a proven track record in running blockchain infrastructure and has already been participating on Arbitrum Nova’s Data Availability Committee (DAC), but was not previously whitelisted as a validator.

Rationale

Enabling permissionless validation is a critical milestone on Arbitrum’s journey toward full decentralization, while maintaining network resiliency. These milestones help ensure Arbitrum technology remains the industry-leading choice for Ethereum scaling solutions. BoLD directly benefits users through guaranteed withdrawal times and enhanced security, while allowing anyone to participate in network validation. Meanwhile, the addition of Infura’s validator to the Arbitrum Nova whitelist will increase the number of active validators on Arbitrum Nova, enhancing the network’s overall reliability.

Specifically, this AIP is:

• Ethereum-aligned: BoLD would strengthen Arbitrum One’s connection to Ethereum by leveraging its security while making validation accessible to everyone - matching Ethereum’s core value of openness. Similarly, the addition of Infura’s validator to the Arbitrum Nova whitelist would support Ethereum’s commitment to decentralization by supporting a more diverse validator set.
• Sustainable: BoLD is meant to secure Arbitrum chains sustainably in the long-term, and there are already future investments and research expected following the initial launch to ensure BoLD and its security guarantees evolve alongside the Arbitrum protocol, technology, and community. Lastly, by leveraging Infura’s proven infrastructure, the proposal would help ensure long-term operational stability and network reliability for Arbitrum Nova.
• Secure: BoLD significantly enhances Arbitrum’s and rollup chains’ security by allowing more validators to monitor the network while maintaining Ethereum’s robust security guarantees. Meanwhile, expanding the validator set for Arbitrum Nova will allow the ArbitrumDAO to reap the benefits from Infura’s strong track record in blockchain infrastructure, adding an additional layer of trust and security to the network.
• Socially inclusive: Permissionless validation using BoLD would allow any entity, individual, or team in the community to participate in securing Arbitrum One. Validation is not restricted to a single address, as BoLD considers all entities that are proposing honest claims to be part of the same team. Where one honest validator may fall off, another one can take up its same responsibility. Similarly, by expanding validator participation through the addition of Infura to Arbitrum Nova’s validator whitelist, the proposal encourages greater inclusion and representation in the ecosystem.
• Technically inclusive: The BoLD protocol specification is publicly available here. The technology is permitted for use by anyone (i.e. permissionless) for the sole purpose of operating and developing an Arbitrum Nitro Instantiation. Meanwhile, expanding Arbitrum Nova’s validator set to include Infura will enable more ordinary teams and users to benefit from Infura’s robust infrastructure and expertise for their needs with no increase in hardware requirements or engineering changes for projects.
• User-focused: Users and developers would receive immediate security and withdrawal timing benefits with BoLD, requiring zero changes to their existing applications or workflows. As for the addition of Infura Arbitrum Nova’s validator set, developers and users alike will collectively benefit from improved network reliability and performance without additional overhead or complexities.
• Neutral and open: BoLD has been and will continue to be “built in the public”, in line with how Orbit and Stylus operate. This AIP is made in good faith to be neutral, transparent, factual, and open for anyone in the community to critique and inspect. Similarly, the proposal to add Infura’s validator to Arbitrum Nova’s whitelist was made transparently, fairly, and in good faith for the Arbitrum community - following the rules and guidelines set forth by the ArbitrumDAO’s constitution.

Arbitrum BoLD: Implementation, Formal Specification, and Censorship Timeout

The following link, BoLD Implementation Deep Dive, explains how BoLD is implemented and how it works at a high level. To read about the formal specification and mathematical safety proofs for the protocol, check out the official BoLD whitepaper. Additionally, the following link, Economics of Disputes in Arbitrum BoLD, presents the nuances and details around the economics in the current proposed design of BoLD. The section on the Economics of Disputes in Arbitrum BoLD covers topics such as: why bonds are important, how bond sizes were calculated, how to think about their magnitude in the context of designing a dispute resolution protocol and various ways the system is designed to ensure honest parties are incentivized to participate in challenges.

Censorship Timeout

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

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

To explain how this feature improves the security of Arbitrum Orbit L3s settling to Arbitrum One and Arbitrum Nova, consider the 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 they could bypass 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 implementing a time threshold that is decremented when unexpected delays in assertion posting occur due to one (or all) of the above mentioned cases of censorship or sequencer outage. Once that time threshold is met, the force inclusion window is lowered - effectively enabling entities to make moves without the 24 hour delay-per-move.

Under reasonable parameterization, the sequencer could be offline or censoring for 24 hours twice before the force inclusion window is effectively dropped from 24 hours to a minimum inclusion period. The force inclusion window gradually (over weeks) replenishes to its original value over time as long as the sequencer is on “good behavior”. An example of “good behavior” could be the default and normal sequencing of messages without unexpected delays.

Below are the initial, proposed parameter values for the Censorship Timeout feature:

• delay buffer = 14400 L1 blocks (2 days)
• threshold = 150 L1 blocks (30 minutes) for Arbitrum One and 300 L1 blocks (1 hour) for Arbitrum Nova
• replenish rate = 5% (meaning 1 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, Orbit chain owners can change the default parameters as they see fit for their use case.

Censorship Timeout was not specifically elaborated on in the original temperature check which passed on Snapshot but was mentioned in the original AIP forum post; we want to ensure that this important feature gets highlighted by adding it to this proposal text.

Recommendation for Arbitrum Nova’s use of BoLD

In addition to proposing that  both Arbitrum One and Nova upgrade to use BoLD, we also recommend the removal of the allowlist of validators for Arbitrum One while keeping Nova permissioned with a DAO-controlled allowlist of entities - unchanged from today for Nova. This update was made for two reasons:

First, Arbitrum Nova’s TVL is much lower than Arbitrum One’s TVL, (~$45.48M vs. ~$18.99B at the time of writing Dec 27 2024, from L2Beat). This means that the high bond sizes necessary for preventing spam and delay attacks would make up a significant proportion of Nova’s TVL, which we believe introduces a centralization risk as we would expect that very few parties would be incentivized to secure Nova. A solution here would be to lower the bond sizes, which brings us to the second reason: lower bond sizes reduce the costs of delay attacks (where malicious actors delay the chain’s progress) and therefore hurt the security of the chain. We believe enabling permissionless validation for Nova is not worth the capital requirement tradeoffs, given the unique security model of AnyTrust chains.

Notably, since Arbitrum Nova’s security already depends on at least one Data Availability Committee (DAC) member providing honest data availability, trusting the same committee to have at least one member provide honest validation does not add a major trust assumption. In the case where the entire DAC is also validating the chain, a feature the Offchain Labs team has been working on, Fast Withdrawals, would allow users to withdraw assets from Arbitrum Nova in ~15 minutes (effectively the same amount of time for L1 finality). This is made possible by the DAC attesting to and instantly confirming an assertion. We understand that Fast Withdrawals will be the subject of a separate AIP.

Addition of Infura’s validator to Arbitrum Nova’s validator whitelist: Implementation details

This proposal includes an on-chain action that will be executed, via a governance action contract, to add Infura’s validator address to Arbitrum Nova’s validator whitelist. For posterity, Infura’s validator address is: 0x0fF813f6BD577c3D1cDbE435baC0621BE6aE34B4.

Included in the proposal payload is a call to the SetValidatorsAction with Infura’s validator address. This action will be executed immediately after the primary BoLD Upgrade Action to set Infura as a whitelisted validator in the new Arbitrum Nova rollup contract.

Technical risks

Some of the technical risks of the BoLD upgrade include:

• Issues preventing liveness of challenges due to smart contract bugs in the new contracts. For instance, no honest validator is able to make a move when it should be able to;
• Safety issues where a malicious party is able to game the system and win due to logic errors in smart contracts;
• Logic bugs in the assertion smart contracts that could affect assertion confirmation and posting, which could delay withdrawals until it is fixed; and
• Bugs in bonding logic in the smart contracts that could lead to loss of funds due to logic errors in the Arbitrum Rollup and challenge manager smart contracts.

• Bugs in the one step proof logic: BoLD does not change how one step proofs work for Arbitrum chains.

Some of the technical risks that come with adding Infura’s validator to Arbitrum Nova’s validator whitelist are:

• Bugs in the SetValidatorsAction that could cause the whole upgrade to revert.
• An incorrectly specified validator address could cause the wrong validator to be whitelisted.

Implementation Plan

BoLD’s implementation has now been complete and merged into the Arbitrum Nitro codebase as of Nitro v3.3.0 and nitro-contracts 3.0.0. The BoLD dispute protocol is now deployed on a permissionless public testnet as of April 15, 2024 that settles to Ethereum Sepolia and has also been deployed on Arbitrum Sepolia as of Dec 11, 2024. Should this governance proposal pass, the target timelines for BoLD to get activated on Arbitrum One and Arbitrum Nova is expected to be on Feb 12, 2025 between GMT-5 09:00 to 12:00.These dates are tentative targets that will depend on the governance vote outcome.

Overall Cost

There is no cost for this proposal to the Arbitrum DAO.

References

• BoLD Gentle Introduction
• BoLD whitepaper, containing both the formal specification & mathematical safety proofs
• BoLD Implementation Deep Dive
• BoLD Economics Deep Dive
• Announcement blog for BoLD
• Solutions to delay attacks on Optimistic Rollups, a blog that highlights a core motivation behind BoLD’s development: Solutions to Delay Attacks on Rollups | by Offchain Labs | Offchain Labs | Medium
• Audit by Trail of Bits (Aug 2, 2023), covering the first implementation of BoLD, based on the first design
• Audit by Trail of Bits (May 2, 2024), covering the new BoLD protocol contracts, assertion pooling contract, and changes to the sequencer inbox for the Censorship Timeout feature (then called “Delay Buffer”)
• Audit Report by Code4rena (June 17, 2024), from the public audit competition
• Audit Report by Trail of Bits (Aug 5, 2024), covering fixes (from the previous audit) and additional optimizations made to the Arbitrum BoLD Solidity contracts.
• Audit Report by Trail of Bits (Oct 7, 2024), covering specific optimizations to make BoLD’s history commitments functions more efficient using fuzzing and differential testing techniques.
• Audit Report by Trail of Bits (Oct 30, 2024), covering further optimizations and changes to the Arbitrum BoLD Solidity contracts, including the review of potential impacts downstream of changes to support EIP-7702.
• Audit Report by Trail of Bits (Dec 26, 2024), covering the BoLD upgrade actions, BoLD proposal payload, and other various small changes as part of Nitro contracts v3.0.0

Where to Learn More about BoLD?

• There have been two governance calls on this proposal to date. You can see the meeting recordings here: governance call #1 and governance call #2
• Listen to the AMA recording on ‘Uncovering BoLD & Permissionless Validation’ that took place on April 18, here: x.com

BoLD FAQ Document

Following conversations with many stakeholders in the ArbitrumDAO and the wider ecosystem, we have consolidated together a list of Frequently Asked Questions (FAQ) and answers here about Arbitrum BoLD. This FAQ document will be iteratively updated as and when more common questions are raised.

Disclaimer about BoLD’s upgrade

If this AIP is approved, the confirmation timing on any withdrawal that is in-progress when the proposed BoLD upgrade is activated will be delayed until the first BoLD assertion is confirmed. This means that for any Arbitrum Rollup chain that upgrades to use BoLD, including Arbitrum One and Arbitrum Nova, all pending withdrawals to the parent chain, that were initiated before the upgrade, will be delayed by 1 challenge period, plus the time between when the withdrawal was initiated and the time that the BoLD upgrade takes place. This is because the upgrade would effectively “reset” the challenge period for transactions that are not yet finalized at the time.

For example, if the upgrade happened at time t, then a withdrawal initiated at a time t-2 days would need to wait an additional 6.4 days to be finalized, totaling 8.4 days (6.4 + 2 days) of maximum delay. Withdrawals that finalize before the upgrade takes place at time t would be unaffected. In other words, the maximum delay a withdrawal will experience leading up to the upgrade would be 12.8 days (two challenge periods).