BoLD for Orbit chains
This document is currently in public preview and may change significantly as feedback is captured from readers like you. Click the Request an update button at the top of this document or join the Arbitrum Discord to share your feedback.
Launch details and key dates
- Status: Alpha - continued testing and evaluation of performance of BoLD with Stylus
| Chain | Release timelines |
|---|---|
| Sepolia | Mid August 2024 |
| Arbitrum One | Late Sept 2024 |
| Arbitrum Nova | Late Sept 2024 |
tldr;
Arbitrum BoLD is an upgrade to the existing dispute protocol used by Arbitrum chains that enables permissionless validation and other security benefits. Similar to other new features for the Arbitrum technology stack, BoLD will be made available for mainnet adoption by Orbit chains when they are ready. Specifically for Arbitrum BoLD, an upgrade will involve a Nitro node software version bump and the deployment and consumption of new smart contracts on the parent chain.
Adopting Arbitrum BoLD brings new security benefits to Orbit chains that are independent of whether or not validation is permissionless. These new security benefits include improved resistance to delay attacks and increased censorship resistance for L3s. Because of these new security benefits, we strongly recommend teams to upgrade their Orbit chains to use Arbitrum BoLD (for the security benefits) but keep validation permissioned. Below is a quick breakdown of the impacts of permissioned BoLD vs. permissionless BoLD on your Orbit chain:
Permissioned BoLD
| Benefits | Limitations |
|---|---|
| Improved resistance to delay attacks | |
| Increased censorship resistance for L3s | |
Use of any ERC-20 as the bonding token | |
| Be on the latest iteration of Arbitrum technology, making future security & feature updates much easier to pick up | |
| Less engineering overhead and infrastructure costs | |
Permissionless BoLD
| Benefits | Limitations |
|---|---|
| Improved resistance to delay attacks | More expensive engineering overhead and infrastructure costs |
| Increased censorship resistance for L3s | Risk of resource exhaustion attacks (challenges required computing and financial resources to participate in, and an attacker could have significantly more resources than the defenders) |
Use of any ERC-20 as the bonding token | Risk of repeated delays due to cheap challenges (each challenge takes time to resolve and so if the cost of a challenge is cheap, then an attacker can open challenges and prevent the progress of the chain at an inexpensive price) |
| Be on the latest iteration of Arbitrum technology, making future security & feature updates much easier to pick up | Risk of liquidity concerns and price impacts if a low-liquidity (relative) ERC-20 token is used as the bonding token and a challenge occurs |
| Less engineering overhead and infrastructure costs | Risk of grieving attacks if the reward to defenders incentivizes self-challenges (by being too high), effectively lowering the cost of attack |
| More trust in the system's integrity and fairness | |
| Creates a more open ecosystem for third-party developers and users | |
Benefits of adopting Arbitrum BoLD
Arbitrum BoLD enables an Arbitrum chain to be permissionlessly validated thanks to several key improvements to the existing dispute protocol. These key improvements benefit an Arbitrum Orbit chain even if validation is kept permissioned on a BoLD-enabled Orbit chain.
Below are some benefits for an Orbit chain that come with adopting Arbitrum BoLD - regardless of whether validation is kept permissioned or not:
Improved resistance to delay attacks
Disputes on a BoLD-enabled chain are resolved in a round-robin style format where disputes can be concurrently resolved. This is an evolution from the current dispute protocol, where challenges are resolved one-by-one. This evolution means that an upper time bound can be placed on all disputes such that a malicious actor cannot delay the chain indefinitely like they can today. Even when validation is kept permissioned, this upper time bound is critical to mitigating the risk of delay attacks by parties on the validator allowlist for an Orbit chain.
Increased censorship resistance for L3 Orbit chains
Today, the force inclusion window is a fixed 24 hours. This force inclusion window exists to enable both users and validators to force-include their transactions and assertions on the parent chain, with a 24-hour delay, if the sequencer is offline or censoring transactions. Arbitrum BoLD's release will come with the Censorship Timeout feature that will automatically reduce the force inclusion time window if the parent chain or sequencer is maliciously censoring user transactions/assertions or the sequencer goes offline. This massively benefits Orbit L3 chains (that settle to a BoLD-enabled parent chain) as it ensures the chain can advance with minimal UX degradation during periods of censorship. You can read more about how this feature works in the gentle introduction to BoLD.
Use of your project's native token as the bonding asset to secure the chain
Arbitrum BoLD enables the chain owner to use any ERC-20 token on the parent chain as the bond for validators to participate in securing the network. By default, this token will be WETH for Arbitrum One and we recommend teams consult this section in our documentation to understand why WETH was selected for Arbitrum One (and not ARB).
Being on the latest version of Arbitrum technology
Adopting Arbitrum BoLD for your Orbit chain will require upgrading the Nitro node software and deploying a new set of contracts on your parent chain. While not specifically related to Arbitrum BoLD, it is always strongly recommended that Orbit chain owners upgrade and keep their chain on the latest stable releases of both Nitro node software and the relevant on-chain contracts. This is critical to ensure your Orbit chain benefits from the latest security improvements and features that the Offchain Labs team is constantly churning out.
Caveats that come with adopting Arbitrum BoLD for permissionless validation
Arbitrum BoLD's implementation and specification have been thoroughly tested and audited. The upgrade to Arbitrum BoLD is not the subject of this section, but rather the caveats and nuances that come with whether to enable permissionless validation.
It is strongly recommended that existing and prospective Orbit chains upgrade to use Arbitrum BoLD but keep validation permissioned.
Enabling permissionless validation means that any entity can spin up a validator and open challenges to dispute invalid claims made by other validators on the network. This opens up an Orbit chain to the risk of spam and attacks by unknown and malicious entities. To mitigate this risk for Arbitrum One, a considerable amount of research and testing has been done to optimize the trade-offs between deterring attacks and managing the costs of defending Arbitrum for honest parties. This research includes carefully calculating all relevant bond sizes, challenge period durations, and relevant plans for operating the infrastructure. More information on this research can be found in the BoLD whitepaper. Below are a few examples of various risks that an Orbit chain will hold should they pursue permissionless BoLD:
Risk of resource exhaustion attacks
Where malicious entities can acquire and utilize more resources than honest parties can put together during a challenge. Such an attack can take many forms and includes both on-chain and off-chain computational/infra costs. For example, a well-coordinated attack on an Orbit chain could overwhelm honest parties if the malicious actors can spend more gas and computational power and acquire more of the bonding asset than the defenders can. This risk can be mitigated by a combination of high bond sizes, use of a price-independent bonding asset, use of a bonding asset with high liquidity, strong economic guarantees that attackers will lose most of their resources, sufficiently long challenge periods, and robust infrastructure operations and resources that can respond and scale up when necessary. More information on resource exhaustion attacks and how Arbitrum BoLD's design accounts for this risk can be found in Section 6.1.4 of the BoLD whitepaper.
Risks to liveness or delays of the chain
If the bond sizes are set too low, making challenges relatively cheap to open compared to the benefits of delaying the chain. Remember that challenges, while time-bound, still take time to complete. This means that each challenge adds a fixed amount of time to confirm assertions. If the bond sizes are carefully calculated and chosen, confirmations of an Orbit chain's state may be completed on time if the cost to open a challenge is low. Delaying the confirmation of assertions for a chain could negatively impact the chain in many ways that an attacker could benefit from (e.g., profiting from price volatility and price impacts on the Orbit chain's token may make delaying the chain worthwhile for an attacker).
Due to the uniquely different tokenomics, sizes, and varying types of Arbitrum Orbit chains deployed (or in active development) today, Offchain Labs does not provide a "one-size-fits-all" recommendation for how best to safely set up and enable permissionless validation for Orbit chains. Instead, we recommend teams adopt Arbitrum BoLD but keep validation permissioned.
If your team would like to have permissionless validation for your Orbit chain, please reach out to us via this form so that we can schedule some time to understand your needs better.
How to adopt Arbitrum BoLD
As mentioned earlier, the upgrade to the dispute protocol involves both a Nitro node software upgrade and the deployment/upgrade of new smart contracts on your Orbit's parent chain.
More details on deploying Arbitrum BoLD for your Orbit chain will be added here when they are available.