BoLD FAQ

Frequently asked questions about BoLD (FAQ)

Q: How does bonding work?

The entities responsible for posting assertions about Arbitrum state to Ethereum are called validators. If posting assertions were free, anyone could create conflicting assertions at will to delay withdrawals by 14 days instead of 7. As such, Arbitrum requires validators to put in a “security deposit”, known as a bond, to be allowed to post assertions. Validators can withdraw their bond as soon as their latest posted assertion receives confirmation, and they will then end their responsibilities. These bonds can be any ERC-20 token. They should be set to a large enough value (for example, 200 WETH) to make it economically infeasible for an adversary to attack an Arbitrum chain and to mitigate against spam (that would otherwise delay confirmations). Requiring a high bond to post assertions about Arbitrum seems centralized, as we are replacing an allowlist of validators with a system that requires a large financial commitment to participate. To address this, there is a contract that anyone can use to deploy a bonding pool as a way of crowdsourcing funds from others who wish to help defend Arbitrum but who may not individually be able to put up the large upfront bond itself. The use of bonding pools, coupled with the fact that there can be any number of honest anonymous parties ready to defend Arbitrum, means that these high bond values do not harm decentralization.

Q: Why are the bond sizes so high for Arbitrum One?

There are two types of “bonds” in BoLD: assertion and challenge. The sizes below are carefully calculated and set for Arbitrum One, using a variety of factors, including TVL, to optimize a balance between the cost for honest parties and the security of the protocol. As always, the exact bond sizes for an Arbitrum chain using BoLD are entirely up to the chain owner to decide, if they choose to adopt BoLD at all.

Assertion bond sizes

Assertion bond sizes are akin to a “security deposit” that an entity deposits to fulfill the role of a proposer (that is, a validator who proposes state assertions to the parent chain). The bond sizes are high because the proposer assumes significant responsibility: they must ensure the chain progresses. Accordingly, the bond also acts as a deterrent to delay attacks, where the attacker would sacrifice the bond to cause roughly a week of delay in a group of withdrawals. If the bond is too small or free, there may not be enough deterrence against this type of attack. Validators who choose to be proposers can withdraw their bond as soon as the protocol has confirmed their most recent posted assertion. We expect there to be very few proposers for Arbitrum One, as only one is enough for the chain's safety and full functionality.

Challenge bond sizes

If someone disagrees with a posted assertion from a proposer, they can pool funds together to propose their assertion that represents the correct history of the chain. Upon doing so, a challenge between the two claims will begin. Anyone can participate in the challenge, as it is permissionless. To resolve a challenge, participants will incur compute and gas costs due to the interactive fraud proof game. Additionally, certain moves within a challenge require an extra bond to prevent resource exhaustion and spam from adversaries. These moves within a challenge require smaller, challenge bonds. The proposed challenge bonds for Arbitrum One are 1,110 ETH to fully resolve a dispute, which will also be reimbursed upon confirmation of the protocol's assertions.

The rationale for the specific challenge bond size is based on a concept known as a “resource ratio,” defined as the cost ratio between an adversary and an honest party when participating in the interactive fraud-proof game. Selecting this value ensured that the malicious party would pay 10 times the honest party's marginal costs. This resource ratio, coupled with the fact that an honest party will always have its bonds refunded while a malicious party loses everything, helps prevent and deter attacks from the outset.

To summarize with a scenario, this effectively means that defending against a $1B attack would require ~$100M of bonds. The ~$100M would be reimbursed upon winning a challenge, while the $1B in bonds posted by an adversary would be forfeited. The proposal aims to send the confiscated funds to the treasury by setting the “excess state receiver” address to the DAO’s treasury address. The trade-off is that the higher the resource ratio we want, the more expensive it is for both honest and dishonest parties to make claims in disputes.

Bonding pools as a way to allow people to participate in assertion posting

BoLD ships with trustless bonding pools that allow any group of participants to pool their funds together to challenge a dishonest proposer, and win. That is, any group of entities can pool funds into a simple contract that will post an assertion to Ethereum without needing to trust each other. Upon observing an invalid assertion, validators have a challenge period (~6.4 days) to pool funds in the contract and respond with a counterassertion. Making it easy to pool the funds to participate in the defense of Arbitrum trustlessly improves decentralization and the safety of BoLD.

Q: Does the bond requirement only mean that whales can validate Arbitrum One?

Validating Arbitrum One is free and accessible. By default, all Arbitrum One nodes are watchtower validators, meaning they can detect and report invalid assertions posted to Ethereum.

However, becoming an assertion proposer requires a bond, as without it, anyone could delay all Arbitrum-bridged assets by one week. That said, BoLD allows anyone to propose assertions and also challenge invalid assertions via pool contracts, helping keep proposers accountable for their actions.

Q: How does BoLD disincentivize malicious actors from attacking an Arbitrum chain?

Honest parties will always be refunded, while malicious actors will always stand to lose 100% of their bond. Malicious actors stand to lose everything at each challenge. The BoLD delay is bounded, and additional challenges would not increase the delay of a particular assertion.

Q: If there's a challenge, what happens to the confiscated funds from malicious actors for Arbitrum One?

Recall that BoLD enables any validator to put up a bond to propose assertions about the child chain state. These assertions about the child chain state are deterministic, so an honest party who posts a bond on the correct assertion will always win in disputes. In these scenarios, the honest party will eventually have their bonds reimbursed while the malicious actor will lose all of their funds.

In BoLD, all costs spent by malicious actors are confiscated and sent to the Arbitrum DAO treasury. A small reward, called the Defender's Bounty, of 1% will go to entities who put down challenge bonds in defense of Arbitrum One. For the remaining funds, the Arbitrum DAO will have full discretion over how to use those confiscated from a malicious actor. Applications include, but are not limited to:

• Using the confiscated funds to refund the parent chain gas costs to honest parties,
• Rewarding or reimbursing the honest parties with some, or all, of the confiscated funds over the 1% Defender's Bounty,
• Burning some, or all, of the confiscated funds, or
• Keeping some, or all, of the confiscated funds within the Arbitrum DAO treasury.

As always, an Arbitrum chain can choose how it wishes to structure and manage confiscated funds from dishonest parties.

Q: Why are honest parties not automatically rewarded with confiscated funds from a malicious actor?

It’s tempting to think that rewarding the honest proposer in a dispute can only make the protocol stronger, but this turns out not to be true, because an adversary can sometimes profit by placing the honest bonds themselves.

This situation creates perverse incentives that threaten BoLD's security. Here’s an example, from Ed Felten:

💡 Suppose the top-level assertion bond is $5M. A delay attack, where the attacker aims to cause a delay of at least one week at minimum cost, costs the attacker $5M. If we change the protocol to give the honest proposer 20% of the confiscated bond, then the attack only costs $4M, because the attacker can post both bonds ($10M total) and get back the honest $5M bond, plus a $1M reward. So, the protocol is weaker against delayed griefing. We can compensate by increasing the top-level assertion bond to $6.25M, so delay griefing still costs $5M, but that increases the cost, to an honest party, required to defend against other attacks. The intuition that giving larger rewards for honest actions can only strengthen the protocol, though natural, turns out to be incorrect. The reason is that large rewards create new strategic options for the attacker, which might enable them to reduce their costs.

That said, there’s no harm in paying the honest proposer a fair interest rate on their bond, so they don’t suffer for having helped the protocol by locking up their capital in a bond.

Therefore, the BoLD AIP proposes that honest parties be rewarded with 1% of the bonds confiscated from a dishonest party in the event of a challenge. This reward applies only to entities that deposit challenge bonds and participate in defending Arbitrum against a challenge. The exact amount rewarded to honest parties will be proportional to the amount the defender deposits into the protocol during a challenge, making bonding pool participants eligible.

Q: Why is ARB not the bonding token used for BoLD on Arbitrum One?

Although BoLD supports using an ERC-20 token, Ethereum, specifically WETH, was chosen over ARB for a few reasons:

1. Arbitrum One and Arbitrum Nova both inherit their security from Ethereum already. Arbitrum One and Nova rely on Ethereum for both data availability and as the referee for determining winners during fraud-proof disputes. Ethereum’s value is also relatively independent of Arbitrum, especially when compared to ARB.
2. Adversaries might be able to exploit the potential instability of ARB when trying to win challenges. Suppose an adversary deposits their bond in ARB and can create an impression that they have a nontrivial chance of winning the challenge. This impression might drive down the value of ARB, which would decrease the adversary's cost to create more bonds (i.e., more spam) during the challenge, which in turn could increase the adversary's chances of winning (which would drive ARB lower, making the attack cheaper still for the adversary, etc.).
3. Access to liquidity: Ethereum has greater liquidity than ARB. In the event of an attack on Arbitrum, access and ease of pooling funds may become crucial.
4. Fraud proofs are submitted to, and arbitrated on, the parent chain (Ethereum). The bonding of capital to make assertions is done so on the parent chain (Ethereum), since Ethereum is the arbitrator of disputes. If BoLD were to use ARB instead of ETH, a large amount of ARB must be pre-positioned on the parent chain, which is more difficult to do when compared to pre-positioning ETH on the parent chain (Ethereum).

An Arbitrum chain owner may choose to use any token they wish for bonding if they adopt and use BoLD permissionless validation.

Q: Can the required token for the validator be set to ARB, and can network ETH revenues get distributed for validator incentives for Arbitrum One?

Yes. The asset a validator uses to become a proposer in BoLD can be configured to any ERC-20 token, including ARB. For Arbitrum One, ETH is used as a bond for various reasons mentioned above. The Arbitrum DAO can change this asset type at any time via a governance proposal. Should such an economic incentive model exist, the source and denomination of funds used to incentivize validators will be at the discretion of the Arbitrum DAO. Again, though, we don't see ARB-based bonding as a good idea at present; see the last question.

Q: How are honest parties reimbursed for bonding their capital to help secure Arbitrum One?

The Arbitrum DAO reimburses “active” proposers with a fair interest rate, as a way of removing the disincentive to participate, by reimbursing honest parties who bond their capital and propose assertions for Arbitrum One. The interest rate should be denominated in ETH and should be equal to the annualized yield that Ethereum mainnet validators receive, which at the time of writing, is an APR between 3% to 4% (based on CoinDesk Indices Composite Ether Staking Rate (CESR) benchmark and Rated.Network). This interest is considered a reimbursement because this payment reimburses the honest party for the opportunity cost of locking up their capital and should not be perceived as a “reward”—for the same reasons why the protocol does not reward honest parties with the funds confiscated from a malicious actor). These reimbursement payments can be paid out upon an active proposer’s honest assertion being confirmed on Ethereum and will be calculated and handled offchain by the Arbitrum Foundation.

BoLD makes it permissionless for any validator to become a proposer and introduces a way to pay service fees to honest parties for locking up capital to do so. Validators are not considered as active proposers until they successfully propose an assertion with a bond. To become an active proposer for Arbitrum One post-BoLD, a validator must propose a child chain state assertion to Ethereum. If they do not have an active bond on the parent chain, they need to attach a bond to their assertion to post it successfully. Subsequent assertions posted by the same address will move the already-supplied bond to their latest proposed assertion. Meanwhile, if an entity, say Bob, has posted a successor assertion to one previously made by another entity, Alice, then Bob would be considered the current active proposer by the protocol. Alice will no longer be considered the active proposer by the protocol, and once her assertion is confirmed, she will receive a refund of her assertion bond. There can only be one “active” proposer at any point in time.

The topic of economic and incentive models for BoLD on Arbitrum One is valuable. It deserves the full focus and attention of the community via a separate proposal or discussion, decoupled from this proposal to bring BoLD to mainnet. Details regarding proposed economic or incentive models for BoLD will require ongoing research and development. However, deploying BoLD as-is represents a substantial improvement to Arbitrum's security, even without addressing economic-related concerns. The DAO may, through governance, choose to fund other parties or modify this reimbursement model at any time.

For Arbitrum chains, any economic model can be configured alongside BoLD if chain owners decide to adopt BoLD.

Q: For Arbitrum One proposers, is the service fee applied to the amount bonded? If that’s the case, the ETH would be locked and thus unable to be used to generate yield elsewhere. So, which assets get used to create this yield for the service fee? Would it involve some ETH from the Arbitrum bridge?

The proposed service fee should correlate to the annualized income that Ethereum mainnet validators receive over the same period. At the time of writing, the estimated annual income for Ethereum mainnet validators is about 3% to 4% of their bond (based on CoinDesk Indices Composite Ether Staking Rate (CESR) benchmark and Rated.Network).

The fee is applied to the total amount bonded over the duration of a proposer's activity. A validator must deposit ETH into the contracts on the parent chain to become a proposer. So those deposited funds will indeed be unable to be used for yield in other scenarios. The decision on the source of funds for the yield is entirely up to the Arbitrum DAO.

Q: For Arbitrum One, will the offchain computation costs get reimbursed? (i.e., the costs for a validator computing the hashes for a challenge)

Reimbursements will not be made for any offchain computation costs, as we view these as costs borne by all honest operators, alongside the maintenance and infrastructure costs that regularly arise from running a node.

Our testing has demonstrated that the cost of running a sub-challenge in BoLD, the most computationally-heavy step, on an AWS r5.4xlarge EC2 instance, costs around USD $2.50 (~$1/hour for one challenge with 2.5 hour duration) using on-demand prices for U.S. East (N. Virginia). Therefore, offchain compute costs are assumed to be negligible relative to the regular infra costs of operating a node.

Q: How will BoLD impact Arbitrum Nova?

Although this AIP proposes that both Arbitrum One and Nova upgrade to use BoLD, we 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.

This decision comes from two reasons:

1. Arbitrum Nova’s TVL is much lower than Arbitrum One’s TVL (~$46M vs. ~$17B at the time of writing, from L2Beat). This lower TVL means that the high bond sizes necessary to prevent spam and delay attacks would comprise a significant share of Nova’s TVL, which we believe introduces a centralization risk, as very few parties would have an incentive to secure Nova. A solution here would be to lower the bond sizes.
2. Lower bond sizes reduce the cost of delay griefing attacks (where malicious actors delay the chain’s progress) and thereby undermine the chain's security.

We believe enabling permissionless validation for Nova is not worth the capital requirement trade-offs, given the unique security model of AnyTrust chains.

Notably, since Arbitrum Nova's security already depends on at least one 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. This trust assumption requires all DAC members to run validators as well. If the 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 Nova in ~15 minutes, or the time it takes to reach parent chain finality. This finality is made possible by the DAC, which attests to and instantly confirms an assertion. Fast Withdrawals will be the subject of a future forum post and snapshot vote.

Q: When it comes to viewing the upfront assertion bond (to be a proposer) as the security budget for Arbitrum One, is it possible for an attacker to go above the security budget, and if so, what happens then?

The upfront capital to post assertions (onchain action) is 3,600 ETH, with subsequent sub-challenge assertions requiring 555/79 ETH (per level). This cost applies to both honest proposers and malicious entities. A malicious entity can post multiple invalid top-level assertions and open multiple challenges. The honest entity can defend against all of them in parallel, because BoLD ties bonds to the correct history rather than to the party that posted them.

Arbitrum state transitions are entirely deterministic. An honest party bonded to the correct state assertion will receive all their costs refunded, while a malicious entity stands to lose everything. Additionally, BoLD’s design ensures that any party bonded to the correct assertion resolves every challenge within the same bounded window, so extra challenges do not extend the delay.

If a malicious entity wanted to attack Arbitrum, they would need to deposit 3,600 ETH to propose an invalid state assertion.

Node Running Info

• Anyone can run an Arbitrum node (today and post-BoLD)
• The default mode is watchtower, which observes the chain. It will alert you if it detects something wrong on the chain, but it takes no action. It requires no funds and doesn't take any onchain action.
• Other "modes" that nodes can run are: stakeLatest, resolveNodes, makeNodes, and defensive. All of these modes require funds and will take onchain action.
  • Nodes running in this mode are considered validators because they validate what they see and take onchain action.
• A node running in watchtower mode is not a validator.
• Proposers are in a special role; they strictly run in makeNodes mode. This role means a proposer is someone running an Arbitrum node in makeNodes mode, also making them a validator.
• For more information about see Running a Node and Validation strategies.

Q: How do BoLD-based L3s' challenge periods operate, considering the worst-case scenario?

To recap, both Arbitrum’s current dispute protocol and BoLD require assertions to be posted to the parent chain and employ interactive proving, which involves a back-and-forth between two entities until a single step of disagreement is reached. That single disputed step then gets submitted to contracts on the parent chain, which will eventually declare a winner. For L2s such as Arbitrum One, BoLD must be deployed on a credibly neutral, censorship-resistant backend to ensure fair dispute resolution. Ethereum is therefore the ideal candidate for deploying the BoLD protocol on L2s.

But you might now be wondering: what about L3 Arbitrum chains that don't settle to Ethereum? Unlike L2s that settle to Ethereum, assertions on an L3's state need to be posted to an L2 either via (A) the L3 Sequencer or (B) the Delayed Inbox queue managed by the L2 sequencer on L2. If the parent chain (in this case, L2) is getting repeatedly censored or if the L2 sequencer is offline, every block-level assertion and/or sub-challenge assertion would need to wait 24 hours before they can bypass the sequencer (using the SequencerInbox's forceInclusion method). If this were to happen, challenge resolution would get 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!

To mitigate the risk of this issue manifesting on Arbitrum chains, Offchain Labs has included a feature called Delay Buffer (also called Censorship Timeout) in BoLD’s 1.0.0 release. The Delay Buffer feature aims to limit the negative effects of: prolonged parent chain censorship, prolonged sequencer censorship, and/or unexpected sequencer outages. This buffer is configurable by setting a time threshold that decrements when unexpected delays occur. Once that time threshold is reached, the force inclusion window is reduced, effectively allowing entities to make moves without the 24-hour delay per move.

Under reasonable parameterization, the sequencer could be offline/censoring for 24 hours twice, before the force inclusion window drops from 24 hours to a minimum inclusion time. The force inclusion window gradually (over weeks) replenishes to its original value over time as long as the sequencer is on "good behavior"—regularly sequencing messages without unexpected delays. We believe that the Delay Buffer feature provides stronger guarantees of censorship resistance for Arbitrum chains.

Recommended parameter defaults for L3 Arbitrum chains that wish to use BoLD are available in the BoLD configuration parameters table.

Q: What is the user flow for using the assertion bonding pool contract?

Warning

The autopooling feature is not available on Arbitrum Nitro yet.

Anyone can deploy an assertion bonding pool using AssertionStakingPoolCreator.sol as a means to crowdsource funds to put up a bond for an assertion. To defend Arbitrum using a bonding pool, an entity would first deploy this pool with the assertion they believe is correct and wish to put up a bond to challenge an adversary's assertion. Then, anyone can verify that the claim is correct by running the inputs through their node's State Transition Function (STF). If other parties agree that the assertion is correct, then they can deposit their funds into the contract. When enough funds are available, anyone can permissionlessly trigger the creation of the assertion onchain to initiate the challenge. Finally, once the dispute protocol confirms the honest parties' assertion, all involved entities can receive reimbursement for their funds and withdraw. The Arbitrum Nitro node validation software also features an optional "auto pooling" option that automates the entire workflow for assertion bonding pool deployment and depositing funds into the pool. If "auto pooling" is activated and the private key controlling the validator has enough funds, a trustless pool will get deployed alongside an assertion of the available funds. If a validator with the "auto pooling" feature enabled sees an assertion onchain that it agrees with and a bonding pool already exists for that assertion, the validator will automatically deposit funds into the bonding pool to "join" others backing that onchain assertion in a trustless manner.

Q: What type of hardware will be necessary to run a BoLD validator?

The minimum hardware requirements for running a BoLD validator are still being researched and finalized. The goal, however, is that regular consumer hardware (i.e., a laptop) can effectively secure an Arbitrum chain using BoLD in the average case, by any honest party.

Q: How do BoLD validators communicate with one another? Is it over a P2P network?

BoLD validators for Arbitrum chains communicate directly with smart contracts on the parent chain (Ethereum), meaning that opening challenges, submitting bisected history commitments, one-step proofs, and confirmations are all adjudicated on the Ethereum blockchain. There is no P2P between validators.

Q: For an L3 Arbitrum chain, secured using BoLD, that settles to Arbitrum One, does the one-step proof happen on the parent chain?

Yes, it happens on Arbitrum One.

Q: For Arbitrum One, does implementing BoLD reduce the scope or remove the need for the Arbitrum Security Council?

BoLD can limit the scope of Arbitrum One and Nova’s reliance on the Security Council as it takes Arbitrum chains one step closer to complete decentralization.