Arbitrum BOLD

BOLD (Bounded Liquidity Delay): a dispute protocol that facilitates permissionless validation for Arbitrum chains. The code and specification are now available on Github here!

BOLD allows Arbitrum-technology chains to:

1. Guarantee safety and liveness of their chain.
2. Minimize latency to settle states.
3. Prevent dishonest parties from raising the cost for honest ones.

Optimistic Rollup chains, such as Arbitrum One and Nova, that support fraud proofs settle their state to Ethereum. Validators, a set of entities, post claims about the L2 state they have verified as true to a smart contract. During a 7-day period, other validators can challenge these claims, triggering a dispute resolution process. Once a claim is confirmed, that L2 state is considered correct on Ethereum. This validation process is the reason why assets can be bridged between Arbitrum chains and Ethereum L1 with a 7-day delay. A challenge protocol involves parties submitting fraud proofs to Ethereum to determine the correct result of L2 execution.

However, validation on Arbitrum One and Nova via fraud proofs today is permissioned because their dispute protocols are vulnerable to denial-of-service attacks. A malicious validator can repeatedly spend funds to prevent assertions from being confirmed, therefore delaying withdrawals from L2 to L1 for as long as they’re willing. Ed Felten from our team has previously written about Delay Attacks on Rollup Protocols and their severity here.

A new approach to validation that introduces a fixed, upper bound of 7 days for additional delay on confirmations without succumbing to delay attacks has been developed. BOLD can make the validation of Arbitrum chains safely permissionless, advancing them several steps up the decentralization ladder. This approach empowers a single, honest validator to prevail in disputes on Ethereum against any number of adversaries.

The code and research specification are now available on Github here. This contribution is made to the Arbitrum Nitro codebase for development and testing. Soon, there will be an announcement on both local devnets for the community to try and a public testnet for the protocol!

Introducing BOLD

Every layer 2 system has to address the challenges of delays when settling its state to Ethereum. BOLD represents an evolution of Arbitrum’s dispute system, culminating in a much more robust approach. To our knowledge, BOLD is the first practical challenge protocol that supports efficient all-versus-all disputes. It:

(a) Guarantees fixed upper bounds on confirmation times for Optimistic Rollups’ settlement, and

(b) Ensures that a single honest party globally can prevail against any number of malicious claims.

Disputes in BOLD are tied to the deterministic execution of an L2 state, not to a particular staker or entity. This means that anyone who agrees with a state can defend it until a single point of disagreement is found. Due to the deterministic nature of the honest L2 state, honest parties will always prevail when participating, as malicious entities cannot fabricate proofs of execution.

For detailed information on how BOLD works and what makes it special, check out our research specification available on GitHub here.

Code Is Now Available

Today, we’re excited to announce that the public code implementation of BOLD is available, along with the publication of our research specification explaining the protocol’s internals on GitHub. The codebase comprises a complete implementation of a challenge manager that not only posts assertions about an L2’s state but can also engage in challenges against any number of malicious adversaries and confirm the correct state.

Our implementation is modular and can be seamlessly integrated into Arbitrum Orbit chains or Arbitrum One/Nova if the DAO decides to adopt it. When integrated into an L2 validator node, BOLD encapsulates all logic required to participate in challenges, post assertions about L2 states to Rollup contracts on Ethereum, and confirm such assertions.

BOLD has undergone an audit by Trail of Bits, and our audit report is included in the repository here. The codebase follows the same licensing as Arbitrum Nitro at this time, as there is a plan to integrate the code as a dependency that Arbitrum technology chains can easily use — batteries included.

BOLD Architecture

In elucidating how all components of BOLD seamlessly integrate, it’s beneficial to consider the software that operates an actual validator for Arbitrum: Arbitrum Nitro. Some of its key responsibilities include:

• Executing incoming transactions from an Inbox contract and generating post-states in accordance with the L2 state transition.
• Submitting transaction batches to Ethereum L1 via a contract known as the SequencerInbox.
• Validating transactions and submitting claims, referred to as assertions, about the L2 state at regular intervals to Ethereum. This submission is directed to a contract known asRollupCore.sol.
• Challenging incorrect assertions posted by dishonest validators toRollupCore.sol.

Most importantly, Arbitrum technology is transitioning into a more modular architecture, wherein specific components can function as standalone binaries. This approach enhances resilience and facilitates easier modifications in the future. BOLD serves as a component of Nitro, responsible for posting assertions and challenging invalid ones. As such, it relies on other segments of the Nitro node to furnish it with the necessary state data. The BOLD repository is an independent project on GitHub, distinct from Nitro. It can be seamlessly integrated into Nitro chains as a dependency, fulfilling its designated roles.

How it Works

The BOLD Challenge Manager interacts with several components of an Arbitrum node, enabling it to execute challenge moves and submit history commitments to the contracts on Ethereum. In our code, we abstract away those L2 node components via a small interface called the L2 State Provider.

Recall that the core primitive of the protocol is challenge edges, where an edge represents a start and end history commitment to an Arbitrum chain. Participants in the protocol can make moves on challenges, and validators can engage in many challenges concurrently. In other words, our software needs to track edges within a challenge and their lifecycle to effectively counter malicious entities.

Our detailed architecture is as follows:

How it Works:

1. Assertion Poster: Frequently takes validated messages from the L2 validator and posts them on-chain.
2. Assertion Scanner: Checks smart contracts on Ethereum for newly posted assertions and compares them against the local Nitro node’s DB. This is facilitated through an abstraction known as an L2 State Provider (withinassertions/scanner.go).
3. Challenge Manager: If there is a disagreement with an assertion, it submits an on-chain challenge by creating a level zero edge and tracks that edge as a go routine.
4. Chain Watcher: In the background, scans for other created edges on-chain and spawns edge tracker goroutines for honest edges that are not yet being tracked.

Each edge is tracked as a goroutine called an Edge Tracker. Edge trackers are self-contained goroutines that wake up at specified tick intervals and use a finite state machine to decide what challenge move to take. For example, after an edge is created, it will attempt to bisect, confirm via one-step proof, or create a subchallenge depending on its current state.

The finite state machine of an edge tracker looks like this, with its final state beingConfirmed:

Once a level zero edge for a challenge on an assertion is confirmed, the assertion can then be confirmed and the honest party will emerge victorious.

Conclusion

In conclusion, BOLD emerges as a promising solution within the Arbitrum ecosystem, addressing critical issues surrounding permissioned validation and denial-of-service vulnerabilities. Its innovative approach, introducing a fixed delay without succumbing to delay attacks, sets the stage for safer and more decentralized validation processes. With the public availability of BOLD’s code and a commitment to modular architecture, the Arbitrum community can look forward to enhanced resilience and adaptability. As BOLD steps into the spotlight, its challenge protocol, efficient dispute resolution, and integration potential signify a significant stride towards the evolution of Arbitrum technology. Explore the available resources on GitHub for a deeper understanding of BOLD’s internals and consider its role in shaping the future of decentralized validation on Arbitrum chains.