Merge branch 'master' into bold-orbit-integration

OffchainLabs · Nov 7, 2024 · 3765c22 · 3765c22
2 parents 8199a0d + 7b98628
commit 3765c22
Show file tree

Hide file tree

Showing 64 changed files with 301 additions and 303 deletions.
diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
@@ -0,0 +1,44 @@
+name: Check format
+run-name: Checking format
+
+on:
+  pull_request:
+    branches:
+      - master
+
+jobs:
+  install:
+    name: "Install"
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout files
+        uses: actions/checkout@v3
+
+      - name: Install node_modules
+        # This action does not work very well with subdirectories out of the box,
+        # but we can use this workaround to make it work.
+        # Note that this is highly dependent on the version of the action used
+        uses: OffchainLabs/actions/node-modules/install@35a1f8c3f3ad803e1fd9b81b94d063a4fc90a030
+        with:
+          install-command: cd website && yarn install --frozen-lockfile
+          cache-key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
+
+  check-formatting:
+    name: "Check Formatting"
+    runs-on: ubuntu-latest
+    needs: install
+    steps:
+      - name: Checkout files
+        uses: actions/checkout@v3
+
+      - name: Restore node_modules
+        # This action does not work very well with subdirectories out of the box,
+        # but we can use this workaround to make it work.
+        # Note that this is highly dependent on the version of the action used
+        uses: OffchainLabs/actions/node-modules/restore@35a1f8c3f3ad803e1fd9b81b94d063a4fc90a030
+        with:
+          cache-key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
+
+      - name: Check formatting with Prettier
+        working-directory: ./website
+        run: yarn format:check
diff --git a/arbitrum-docs/audit-reports.mdx b/arbitrum-docs/audit-reports.mdx
@@ -18,4 +18,4 @@
 | **Trail of Bits**       | 08/29/2024 | USDC Custom Gateway & ArbOS Timestamp Upgrade Action contract | [view](hosted-audit-reports/2024_08_29_trail_of_bits_security_audit_usdc_custom_gateway_and_arbos_upgrade_at_timestamp_action.pdf) |
 | **Trail of Bits**       | 08/29/2024 | Orbit & Governance Upgrade Actions Contracts v2.1             | [view](hosted-audit-reports/2024_08_29_trail_of_bits_security_audit_orbit_and_governance_upgrade_actions_v2.1.pdf)                 |
 | **Open Zeppelin**       | 09/05/2024 | Stylus Rust SDK                                               | [view](hosted-audit-reports/2024_09_05_open_zeppelin_security_audit_stylus_rust_sdk.pdf)                                           |
-| **Trail of Bits**       | 09/25/2024 | Timeboost Auction Contracts                                   | [view](hosted-audit-reports/2024_09_25_trail_of_bits_security_audit_timeboost_auction_contracts.pdf)                               |
+| **Trail of Bits**       | 09/25/2024 | Timeboost Auction Contracts                                   | [view](hosted-audit-reports/2024_09_25_trail_of_bits_security_audit_timeboost_auction_contracts.pdf)                               |
diff --git a/arbitrum-docs/bold/concepts/bold-technical-deep-dive.md b/arbitrum-docs/bold/concepts/bold-technical-deep-dive.md
@@ -10,10 +10,6 @@ sme: leeederek
 sidebar_position: 1
 ---
 
-import PublicPreviewBannerPartial from '../../how-arbitrum-works/bold/partials/_bold-public-preview-banner-partial.md';
-
-<PublicPreviewBannerPartial />
-
 ## Overview
 
 Arbitrum's current dispute protocol involves defending against challengers individually in a 1-vs-1 tournament setting. In contrast, BoLD enables an all-vs-all battle royale between Good and Evil, with a single winner always determined.
@@ -38,10 +34,10 @@ The current implementation of BoLD involves both on-chain and off-chain componen
 - **Arbitrum rollup contracts:** The set of smart contracts on Ethereum L1 that serve as both the data availability layer for Arbitrum and for confirming the rollup's state assertions after a challenge period has passed for each assertion made.
 - **Assertions:** A claim posted to the Arbitrum rollup contracts on Ethereum L1 about the Arbitrum L2 execution state. Each claim consumes messages from the Arbitrum rollup inbox contract. Each assertion can be confirmed after a period of 6.4 days, and anyone can challenge it during that period. A BoLD challenge will add an additional upper bound of 6.4 days to confirm an assertion. If an assertion is challenged near the end of 6.4 days, an additional 6.4 days will be needed to complete the challenge. Gaining the right to post assertions requires placing a large, one-time bond, which can get taken away in the case of losing a challenge to a competing assertion. Opening challenges requires posting smaller "challenge bonds".
 - **Validating bridge:** The smart contract that leverages Ethereum's security and censorship-resistance to unlock bridged assets from L2 back to L1. Assets can be unlocked after an assertion has been posted and confirmed.
-- **Fraud proofs:** Proofs that prove or disprove that an invalid state transition has taken place. These proofs are generated by challenge participants and are submitted to a chain's parent chain. For example, Arbitrum Rollups that settle onto Ethereum will have their proofs submitted to Ethereum and verified via a smart contract. In this case, these proofs allow Ethereum to be the final arbiter of disagreements over assertions in the rollup contracts, which cannot be falsified by any parties as there is only a single, correct result of executing a `WASM` instruction on a pre-state. 
-- **Challenge protocol:** A set of rules through which a disagreement on an assertion is resolved using Ethereum as the final arbiter. Ethereum's VM can verify one-step proofs of deterministic computation that will confirm a challenge winner in Arbitrum's rollup contracts once the challenge period has elapsed. 
+- **Fraud proofs:** Proofs that prove or disprove that an invalid state transition has taken place. These proofs are generated by challenge participants and are submitted to a chain's parent chain. For example, Arbitrum Rollups that settle onto Ethereum will have their proofs submitted to Ethereum and verified via a smart contract. In this case, these proofs allow Ethereum to be the final arbiter of disagreements over assertions in the rollup contracts, which cannot be falsified by any parties as there is only a single, correct result of executing a `WASM` instruction on a pre-state.
+- **Challenge protocol:** A set of rules through which a disagreement on an assertion is resolved using Ethereum as the final arbiter. Ethereum's VM can verify one-step proofs of deterministic computation that will confirm a challenge winner in Arbitrum's rollup contracts once the challenge period has elapsed.
 - **Bonding of funds:** Creating an assertion in the rollup contracts requires the submitter to join the validator set by putting up a large bond in the form of `WETH`. Subsequent assertions posted by the same party do not require more bonds. Instead, the protocol always considers validators to be bonded to their latest posted assertion. The bonded funds are taken away if another competing assertion is confirmed. When an assertion is confirmed, the associated bonded funds can be withdrawn.
-- **Honest validator:** An entity that knows the correct state of the Arbitrum L2 chain and who may want to participate in creating assertions, confirming assertions, and/or challenging invalid assertions if they exist. More specifically, this entity must run an Arbitrum full node in `MakeNodes`, `Defensive`, `StakeLatest`, or `ResolveNodes` mode as described in the [How to run a validator](https://docs.arbitrum.io/run-arbitrum-node/more-types/run-validator-node).  Note that there must always be an active proposer to advance the chain and who will need to run a validator in `MakeNodes` mode.
+- **Honest validator:** An entity that knows the correct state of the Arbitrum L2 chain and who may want to participate in creating assertions, confirming assertions, and/or challenging invalid assertions if they exist. More specifically, this entity must run an Arbitrum full node in `MakeNodes`, `Defensive`, `StakeLatest`, or `ResolveNodes` mode as described in the [How to run a validator](https://docs.arbitrum.io/run-arbitrum-node/more-types/run-validator-node). Note that there must always be an active proposer to advance the chain and who will need to run a validator in `MakeNodes` mode.
 - **Challenge period:** Window of time ([~6.4 days on Arbitrum One](https://docs.arbitrum.io/build-decentralized-apps/reference/chain-params)) over which an assertion can be challenged, after which the assertion can be confirmed. This is configurable by the DAO.
 - **Edge:** Edges are 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. Edges are the fundamental unit in a challenge.
 - **Timers:** Each unrivaled edge (that is, an edge without another competing edge) will have a timer that _ticks up_. Time in the protocol is measured using L1 blocks and block numbers are used. An edge's timer stops ticking when a rival edge is created on-chain. Most importantly, timers are used to confirm assertions when an unrivaled edge's timer, and associated assertion, reaches the specified challenge period. See the section on [Timers](./bold-technical-deep-dive.md#timers) for more details.
@@ -109,8 +105,7 @@ To address this, there is a [contract](https://github.com/OffchainLabs/bold/blob
 
 Anyone can deploy an assertion bonding pool using the `AssertionStakingPoolCreator.sol` contract as a means to crowdsource funds for bonding funds to an assertion. To defend Arbitrum using one of these pools, an entity would first deploy this pool with the assertion they believe is correct and wish to bond on to challenge an adversary's assertion. Then, anyone can verify that the claimed assertion is correct by running the inputs through their node's State Transition Function (`STF`). If other parties agree that the assertion is correct, they can deposit their funds into the contract. When enough funds have been deposited, anyone can trigger the creation of the assertion on-chain to start the challenge in a trustless manner. Finally, once the dispute protocol confirms the honest parties' assertion, all involved entities will get their funds reimbursed and can withdraw.
 
-Note that with bonding pools, there is no minimum `WETH` requirement and once the entire bond amount is raised (either 3600, 555, or 79 ETH for Arbitrum One), then the assertion can be posted by anyone trustlessly. Additionally, there is an optional feature in the Nitro node validator software that enables both the automatic deployment of a bonding pool contract and depositing of funds to challenge an observed invalid assertion. 
-
+Note that with bonding pools, there is no minimum `WETH` requirement and once the entire bond amount is raised (either 3600, 555, or 79 ETH for Arbitrum One), then the assertion can be posted by anyone trustlessly. Additionally, there is an optional feature in the Nitro node validator software that enables both the automatic deployment of a bonding pool contract and depositing of funds to challenge an observed invalid assertion.
 
 <a data-quicklook-from="trustless">Trustless</a> bonding pools can also be created to open challenges
 and make moves on challenges without sacrificing decentralization.
@@ -203,8 +198,11 @@ To create a challenge, there must be a fork in the Arbitrum assertion chain smar
 
 <a data-quicklook-from="challenge">Challenge</a> bonds are named as such because they are bonds required
 for opening challenges. The mechanism of how challenge bond economics are decided is contained in the
-[Economics of Disputes](../../how-arbitrum-works/bold/bold-economics-of-disputes.md), which also explains the cost profile and spam prevention in BoLD. In short, the
-actual cost of a bond encompasses many costs associated with participating in the dispute game. More information on the bond sizes and how they were calculated can be found in the [Economics of Disputes](../../how-arbitrum-works/bold/bold-economics-of-disputes.md) document mentioned above.
+[Economics of Disputes](../../how-arbitrum-works/bold/bold-economics-of-disputes.md), which also explains
+the cost profile and spam prevention in BoLD. In short, the actual cost of a bond encompasses many costs
+associated with participating in the dispute game. More information on the bond sizes and how they were
+calculated can be found in the [Economics of Disputes](../../how-arbitrum-works/bold/bold-economics-of-disputes.md)
+document mentioned above.
 
 Each subchallenge that is created requires depositing a challenge bond. For Arbitrum One, the first unrivaled edge’s bond is kept in the challenge manager contract on Ethereum, while any subsequent rival bonds are kept in an excess bond receiver address. Once a challenge is complete, all bonds for an honest party are automatically refunded in-protocol while all confiscated bonds are sent to the ArbitrumDAO treasury. It is important to not offer the majority of the bonds confiscated from dishonest parties to honest parties to avoid perverse incentives, such as grieving attacks in self-challenges or to discourage needless competition between honest parties.
 
@@ -216,14 +214,13 @@ The reimbursement of assertion bonds and challenge bonds for honest parties will
 
 For BoLD to be deployed on an Arbitrum chain, an upgrade admin action needs to be taken using an `UpgradeExecutor` pattern. This is a smart contract that executes actions as the Rollup owner. At the upgrade, the `RollupCore.sol` contract will be updated to a new BoLD one, and additional contracts needed for BoLD challenges, such as an `EdgeChallengeManager.sol`, will also be deployed to the parent chain.
 
-Next, assertions will then be posted to the new Rollup contract. During the upgrade period, there could have been a very large number of blocks posted in Arbitrum batches. For this purpose, BoLD assertions support the concept of an **overflow**, allowing us to efficiently handle this situation. 
+Next, assertions will then be posted to the new Rollup contract. During the upgrade period, there could have been a very large number of blocks posted in Arbitrum batches. For this purpose, BoLD assertions support the concept of an **overflow**, allowing us to efficiently handle this situation.
 
 :::caution Withdrawals leading up to a BoLD upgrade
 
-The confirmation timing on any withdrawal that is in-flight when the BoLD upgrade is activated will be delayed until the first BoLD assertion is confirmed. This means that for any Arbitrum chain that upgrades to use BoLD, including Arbitrum One and Arbitrum Nova, all pending withdrawals to L1 Ethereum that were initiated _before_ the upgrade will be delayed by 1 challenge period, plus the time between the withdrawal was initiated and the time that the BOLD upgrade takes place. This is because the upgrade effectively "resets" the challenge period for that are not yet finalized. 
+The confirmation timing on any withdrawal that is in-flight when the BoLD upgrade is activated will be delayed until the first BoLD assertion is confirmed. This means that for any Arbitrum chain that upgrades to use BoLD, including Arbitrum One and Arbitrum Nova, all pending withdrawals to L1 Ethereum that were initiated _before_ the upgrade will be delayed by 1 challenge period, plus the time between the withdrawal was initiated and the time that the BOLD upgrade takes place. This is because the upgrade effectively "resets" the challenge period for that are not yet finalized.
 
 For example, if the upgrade happened at time _t_, then a withdrawal initiated at a time _t-2_ days will need to wait an additional _6.4_ days for their withdrawal to be finalized, totaling 8.4 days of maximum delay. Withdrawals that finalize before the upgrade takes place at time _t_ will be unaffected. In other words, the maximum delay a withdrawal will experience leading up to the upgrade is 12.8 days (two challenge periods).
 :::
 
-
 The upgrade pattern for an existing Arbitrum Rollup to a BoLD-enabled one is tested extensively and run as part of each of our pull requests in the BoLD repository [upgrade workflow on GitHub](https://github.com/OffchainLabs/bold/blob/c4e068b568ff662f49ed191c5c3188ea7b6138b2/.github/workflows/go.yml#L209).
diff --git a/arbitrum-docs/build-decentralized-apps/nodeinterface/01-overview.mdx b/arbitrum-docs/build-decentralized-apps/nodeinterface/01-overview.mdx
@@ -7,10 +7,6 @@ content_type: concept
 
 <!-- todo: remove this doc, redirect to existing ref doc -->
 
-import PublicPreviewBannerPartial from '../../partials/_public-preview-banner-partial.mdx';
-
-<PublicPreviewBannerPartial />
-
 The Arbitrum Nitro software includes a special `NodeInterface` contract available at address `0xc8` that is only accessible via RPCs (it's not actually deployed on-chain, and thus can't be called by smart contracts). The way it works is that the node uses Geth's [`InterceptRPCMessage`](https://github.com/OffchainLabs/go-ethereum/blob/@goEthereumCommit@/internal/ethapi/api.go#L1034) hook to detect messages sent to the address `0xc8`, and swaps out the message it's handling before deriving a transaction from it.
 
 The [reference page](/build-decentralized-apps/nodeinterface/02-reference.mdx) contains information about all methods available in the NodeInterface.
diff --git a/...ntralized-apps/token-bridging/bridge-tokens-programmatically/01-get-started.mdx b/...ntralized-apps/token-bridging/bridge-tokens-programmatically/01-get-started.mdx
@@ -5,10 +5,6 @@ user_story: As a developer, I want to understand how to bridge tokens between Et
 content_type: overview
 ---
 
-import PublicPreviewBannerPartial from '../../../partials/_public-preview-banner-partial.mdx';
-
-<PublicPreviewBannerPartial />
-
 Token bridging is a fundamental aspect of any Layer 2 (L2) protocol. It allows projects to quickly integrate with the Arbitrum ecosystem by leveraging their existing Layer 1 (L1) tokens.
 
 This section offers a series of how-tos showcasing the different methods available for making your token bridgeable.

diff --git a/...en-bridging/bridge-tokens-programmatically/02-how-to-bridge-tokens-standard.mdx b/...en-bridging/bridge-tokens-programmatically/02-how-to-bridge-tokens-standard.mdx
@@ -5,10 +5,6 @@ user_story: As a developer, I want to understand how to bridge tokens between Et
 content_type: how-to
 ---
 
-import PublicPreviewBannerPartial from '../../../partials/_public-preview-banner-partial.mdx';
-
-<PublicPreviewBannerPartial />
-
 In this how-to you’ll learn how to bridge your own token between Ethereum (Layer 1 or L1) and Arbitrum (Layer 2 or L2), using [Arbitrum’s standard ERC20 gateway](/build-decentralized-apps/token-bridging/03-token-bridge-erc20.md#default-standard-bridging). For alternative ways of bridging tokens, don’t forget to check out this [overview](/build-decentralized-apps/token-bridging/bridge-tokens-programmatically/01-get-started.mdx).
 
 Familiarity with [Arbitrum’s token bridge system](/build-decentralized-apps/token-bridging/01-overview.md), smart contracts, and blockchain development is expected. If you’re new to blockchain development, consider reviewing our [Quickstart: Build a dApp with Arbitrum (Solidity, Hardhat)](/build-decentralized-apps/01-quickstart-solidity-hardhat.md) before proceeding. We will use [Arbitrum’s SDK](https://github.com/OffchainLabs/arbitrum-sdk) throughout this how-to, although no prior knowledge is required.

diff --git a/...dging/bridge-tokens-programmatically/03-how-to-bridge-tokens-generic-custom.mdx b/...dging/bridge-tokens-programmatically/03-how-to-bridge-tokens-generic-custom.mdx
@@ -5,10 +5,6 @@ user_story: As a developer, I want to understand how to bridge tokens between Et
 content_type: how-to
 ---
 
-import PublicPreviewBannerPartial from '../../../partials/_public-preview-banner-partial.mdx';
-
-<PublicPreviewBannerPartial />
-
 In this how-to you’ll learn how to bridge your own token between Ethereum (Layer 1 or L1) and Arbitrum (Layer 2 or L2), using [Arbitrum’s generic-custom gateway](/build-decentralized-apps/token-bridging/03-token-bridge-erc20.md#the-arbitrum-generic-custom-gateway). For alternative ways of bridging tokens, don’t forget to check out this [overview](/build-decentralized-apps/token-bridging/bridge-tokens-programmatically/01-get-started.mdx).
 
 Familiarity with [Arbitrum’s token bridge system](/build-decentralized-apps/token-bridging/01-overview.md), smart contracts, and blockchain development is expected. If you’re new to blockchain development, consider reviewing our [Quickstart: Build a dApp with Arbitrum (Solidity, Hardhat)](/build-decentralized-apps/01-quickstart-solidity-hardhat.md) before proceeding. We will use [Arbitrum’s SDK](https://github.com/OffchainLabs/arbitrum-sdk) throughout this how-to, although no prior knowledge is required.