Skip to main content

Overview of BoLD

BoLD is a new dispute protocol for optimistic Rollups that enables permissionless validation for Arbitrum chains. BoLD stands for Bounded Liquidity Delay and is active on Arbitrum One, Arbitrum Nova, and Arbitrum Sepolia.

What exactly is BoLD?​

The previous dispute protocol used fraud proofs for challenges and was limited to a set of allowlisted validators.

When BoLD upgraded Arbitrum's previous dispute protocol, it changed some of the rules used by validators to open and resolve disputes about Arbitrum's state, ensuring only valid states receive confirmation on an Arbitrum chain's parent chain (Ethereum). It also allows anyone to participate in validating chain state (including challenges) and enhances security around child-to-parent chain messaging (including withdrawals).

Under BoLD, a bonded validator's responsibilities are to:

  • Post claims about an Arbitrum chain state to its parent chain (i.e., Ethereum)
  • Open challenges to dispute invalid claims made by other validators, and
  • Confirm valid claims by participating in and winning challenges

BoLD ensures that disputes are resolved within a fixed period (currently equivalent to two challenge periods, plus a two-day grace period for the Security Council to intervene if necessary, and a small delta for computation), effectively removing the risk of delay attacks and making withdrawals to a parent chain more secure.

BoLD uniquely offers time-bound, permissionless validation because a correct state assertion isn't tied to the validator that bonds their capital to a claim. This feature, coupled with the fact that the child chain states are entirely deterministic, can be proven on Ethereum, meaning that any number of honest parties can rely on BoLD to prove that their claim is correct. Lastly, BoLD does not change the fact that only a single honest party is required to defend Arbitrum.

BoLD enables Arbitrum to become a Stage 2 Rollup​

Inspired by Vitalik’s proposed milestones, the team over at L2BEAT has assembled a widely recognized framework for evaluating the development of Ethereum Rollups. Both Vitalik and the L2BEAT framework refer to the final stage of Rollup development as “Stage 2: No Training Wheels”. A critical criterion for being considered a Stage 2 Rollup is the ability to allow anyone to validate the child chain state and post fraud proofs to Ethereum without restrictions. This step is a key requirement for Stage 2 because it ensures “that a limited set of entities does not control the system and instead is subject to the collective scrutiny of the entire community”.

Pie slice

With BoLD at its core, Arbitrum charts a course toward Stage 2 Rollup recognition by addressing the currently yellow (above) State Validation wedge in L2BEAT's risk analysis pie chart. BoLD contributes to a more permissionless, efficient, and robust rollup ecosystem.

BoLD makes withdrawals safer to the parent chain​

BoLD safer withdrawals

BoLD introduces a time limit on the existing Rollup protocol for resolving disputes, effectively ensuring that challenges conclude within a 6.4-day window (the DAO can change this window for Arbitrum One and Nova). This conclusion is possible due to two reasons:

  1. BoLD’s design allows for challenges between the honest party and any number of malicious adversaries to happen in parallel, and
  2. The use of a time limit that will automatically confirm the honest party’s claims if the challenger fails to respond.

To summarize with an analogy and the diagram below: Arbitrum’s former dispute protocol assumed that any assertion that gets challenged must be defended against each unique challenger sequentially, like in a “1v1 tournament”. BoLD, on the other hand, enabled any single honest party to defend the correct state and guarantee a win, similar to an “all-vs-all battle royale” in which there must and will always be a single winner.

Before and after with BoLD
note

The timer/clocks above are arbitrary and instead represent the duration of challenges and the sequential nature of challenges today, but they can take place in parallel with BoLD. The durations of the challenges are independent of one another.

How does it work?​

The BoLD protocol provides the guardrails and rules for how validators challenge claims about the state of an Arbitrum chain. Since Arbitrum’s state is deterministic, there will always be only one correct state for a given input of onchain operations and transactions.

The beauty of BoLD’s design ensures that disputes are resolved within a fixed time window, eliminating the risk of delay attacks and ultimately enabling anyone to bond their funds to and successfully defend the singular correct state of Arbitrum.

Let’s dive into an overview of how BoLD actually works.

  1. An assertion is made: Validators begin by taking the most recent confirmed assertion, called Block A, and assert that some number of transactions afterward, using Nitro's deterministic State Transition Function (STF), will result in an end state, Block Z. If a validator claims that the end state represented by Block Z is correct, they will place their bond on Block Z and propose that state to its parent chain. (For more details on how bonding works, see BoLD technical deep dive). If no one disagrees after a certain period, known as the challenge period, then the state represented by the assertion Block Z is confirmed as the correct state of an Arbitrum chain. However, if someone disagrees with the end state Block Z, they can submit a challenge.
  2. A challenge is opened: When another validator observes and disagrees with the end state represented by Block Z, they can open a challenge by asserting and bonding capital to a claim on a different end state, represented by an assertion Block Y. At this point, there are now two asserted states: Block A → Block Z and Block A → Block Y. Each of these asserted states, at this point, is referred to as an edge, while a Merkle tree of asserted states from some start to endpoint (e.g., Block A → Block Z) is more formally known as a history commitment. It is important to note that Ethereum at this point has no notion of which edge(s) are correct or incorrect—edges are simply a portion of a claim made by a validator about the history of the chain from some end state all the way back to some initial state. Also note that because a bond posted by a validator is for an assertion rather than for the party that posted it, there can be any number of honest, anonymous parties who can open challenges to incorrect claims. It is important to note that bonds posted to open challenges get held in the Rollup contract. There is a prescribed procedure outlining the Arbitrum Foundation's expectations regarding the use of these funds; see Step 5 below for a summary.
  3. Multi-level, interactive dissection begins: To resolve the dispute, the disagreeing entities will need to agree on what the actual, correct asserted state should be. It would be tremendously expensive to re-execute and compare everything from Block A → Block Z and Block A → Block Y, especially since there could be potentially millions of transactions in between A, Z, and Y. Instead, entities take turns bisecting their respective history commitments until they arrive at a single step of instruction, where an arbiter, such as Ethereum, can declare a winner. Note that this system is very similar to how challenges worked previously—BoLD only changes some minor, but important, details in the resolution process. Let’s dive into what happens next:
    • Block challenges: When a challenge gets opened, edges are referred to as level-zero edges since they are at the granularity of Arbitrum blocks. The disputing parties take turns bisecting their historical commitments until they identify the specific block on which they disagree.
    • Big-step challenge: Now that the parties have narrowed down their dispute to a single block, the back-and-forth bisection exercise continues within that block. Note that this block is agreed upon by all parties to be a state that follows the initial state but precedes the final state. This time, however, the parties will narrow down on a specific range of instructions for the State Transition Function within the block—essentially working towards identifying a set of instructions within which their disagreement lies. Currently, this range is 2^23 steps of WASM instructions, which is the assembly of choice for validating Arbitrum chains.
    • One-step challenge: Within that range of 2^23 instructions, the back-and-forth bisecting continues until all parties arrive at a single step of instruction that they disagree on. At this point, the parties agree on the initial state of Arbitrum before the step, but disagree on the end state immediately after. Remember that since Arbitrum’s state is entirely deterministic, there is only one correct end state.
  4. One-step proof: Once a challenge is isolated down to a dispute about a single step, both parties run that step to produce, and then submit, a one-step proof to the OneStepProof smart contract on the parent chain (e.g., Ethereum). A one-step proof is a proof that a single step of computation results in a particular state. The smart contract on the parent chain will execute the disputed step to validate the correctness of the submitted proof from both parties. It is at this point that the honest party's proof will be deemed valid and its tree of edges will be confirmed by time, whereas the dishonest party's edges will be rejected due to a timeout.
  5. Confirmation: Once the honest one-step edge is confirmed, the protocol will work on confirming or rejecting the parent edges until it reaches the level-zero edge of the honest party. With the honest party’s level-zero edge now confirmed, their assertion bond is refundable. Meanwhile, the dishonest party has its bonds removed to ensure that dishonesty is always punished.
    • There is another way that a level-zero edge can get confirmed: time. At each of the mini-stages of the challenge (block challenge, big-step challenge, one-step challenge), a timer increments upwards towards some challenge period, T, defined by BoLD. This timer begins ticking for a party when they submit their bisected history commitment, and it continues until their challenger submits their bisected history commitment in response. An edge is automatically confirmed if the timer reaches T.
  6. Reimbursements for the honest party's parent chain gas costs and mini-bonds made at the other challenge levels are handled by the Arbitrum Foundation.

That’s it! We’ve now walked through each step that validators will take to dispute challenges under the BoLD protocol. One final note is that each of the steps explained above can run concurrently, which is one of the reasons why BoLD can guarantee a resolution to disputes within a fixed time frame.