Add bold integration article

arbitrum-docs/launch-orbit-chain/bold-adoption-for-orbit-chains.mdx

@@ -0,0 +1,90 @@
+---
+title: 'BoLD for Orbit chains'
+description: ''
+user_story: 'As a developer or researcher of the Arbitrum product suite, I want to learn about BoLD, a next-generation dispute protocol that enables permissionless validation.'
+content_type: release announcement
+author: leeederek
+sme: leeederek
+target_audience: 'Developers who want to build on Arbitrum using popular programming languages, like Rust'
+sidebar_position: 1
+---
+
+:::info PUBLIC PREVIEW DOCUMENT
+
+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](https://discord.gg/arbitrum) 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                                             |
+| <a data-quicklook-from="arbitrum-one">Arbitrum One</a>     | Late Sept 2024                                              |
+| <a data-quicklook-from="arbitrum-nova">Arbitrum Nova</a>    | 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 <a data-quicklook-from="bold">Arbitrum BoLD</a> 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                           | Permissionless BoLD                              |
+|--------------------------------------------- |--------------------------------------------------|
+| Improved resistance to delay attacks         | Everything in permissioned BoLD                  |
+| Increased censorship resistance for `L3s`     | More expensive engineering overhead and infrastructure costs |
+| Use of any `ERC-20` as the bonding token    | 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)              |
+| Be on the latest iteration of Arbitrum technology, making future security and feature updates much easier to pick up | 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) |
+|                                             | 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 |
+|                                             | Risk of grieving attacks if the reward to defenders incentivizes self-challenges (by being too high), effectively lowering the cost of attack |
+
+
+### 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](https://medium.com/offchainlabs/solutions-to-delay-attacks-on-rollups-434f9d05a07a) 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](https://docs.arbitrum.io/how-arbitrum-works/bold/gentle-introduction#q-how-do-bold-based-l3s-challenge-periods-operate-considering-the-worst-case-scenario).
+
+#### 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](https://docs.arbitrum.io/how-arbitrum-works/bold/gentle-introduction#q-why-is-arb-not-the-bonding-token-used-in-bold-on-arbitrum-one) 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. 
+
+:::warning
+
+It is strongly recommended that existing and prospective Orbit chains upgrade to use Arbitrum BoLD but **not** enable permissionless validation.
+
+:::
+
+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](https://arxiv.org/abs/2404.10491). 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.
+
+#### 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 <a data-quicklook-from= "arbitrum-orbit">Arbitrum Orbit</a> chains deployed (or in active development) today, <a data-quicklook-from= "offchain-labs">Offchain Labs</a> 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](https://docs.google.com/forms/d/e/1FAIpQLSe5YWxFbJ8DgWcDNbIW2YYuTRmegtx2FHObym00_sOt0kq4wA/viewform) 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.

website/sidebars.js

@@ -354,6 +354,11 @@ const sidebars = {
           id: 'launch-orbit-chain/concepts/custom-gas-token-sdk',
           label: 'Custom gas token SDK',
         },
+        {
+          type: 'doc',
+          id: 'launch-orbit-chain/bold-adoption-for-orbit-chains',
+          label: 'BoLD for Orbit chains',
+        },
         {
           type: 'doc',
           id: 'launch-orbit-chain/concepts/public-preview-expectations',