Merge branch 'master' into ethereum-vs-arbitrum

.github/workflows/main.yml

@@ -48,7 +48,9 @@ jobs:
           echo "format-check-result=$?" >> $GITHUB_OUTPUT
       
       - name: Output formatting error
-        if: steps.prettier-check.outputs.format-check-result == 1
+        if: |
+          steps.prettier-check.outputs.format-check-result == 1 &&
+          github.event.pull_request.head.repo.full_name == github.repository
         uses: actions/github-script@v6
         with:
           github-token: ${{ secrets.GITHUB_TOKEN }}

arbitrum-docs/for-devs/quickstart-solidity-hardhat.md

@@ -61,9 +61,10 @@ We'll install the rest of our dependencies as we go.
   - These transactions can be expensive when the network is under heavy load.
 - **Arbitrum**
   - Arbitrum is a suite of L2 scaling solutions for dApp developers.
-  - <a data-quicklook-from="arbitrum-one">Arbitrum One</a> is an L2 chain that implements the <a data-quicklook-from="arbitrum-rollup">
-      Arbitrum Rollup
-    </a> protocol.
+  - <a data-quicklook-from="arbitrum-one">Arbitrum One</a> is an L2 chain that implements the <a data-quicklook-from="arbitrum-rollup-protocol">
+      Arbitrum Rollup protocol
+    </a>
+    .
   - You can use Arbitrum One to build user-friendly dApps with high throughput, low latency, and low transaction costs while inheriting Ethereum's high security standards[^4].
 
 Let's review our vending machine's Javascript implementation, then convert it into a Solidity smart contract, then deploy it to Arbitrum One.
@@ -173,11 +174,9 @@ Open `scripts/deploy.js` and replace its contents with the following:
 const hre = require('hardhat');
 
 async function main() {
-  const VendingMachineFactory = await hre.ethers.getContractFactory('VendingMachine');
-  const vendingMachine = await VendingMachineFactory.deploy();
-  await vendingMachine.deployed();
-
-  console.log(`Cupcake vending machine deployed to ${vendingMachine.address}`);
+  const vendingMachine = await hre.ethers.deployContract('VendingMachine');
+  await vendingMachine.waitForDeployment();
+  console.log(`Cupcake vending machine deployed to ${vendingMachine.target}`);
 }
 
 main().catch((error) => {

arbitrum-docs/for-devs/third-party-docs/PARSIQ/parsiq.md

@@ -0,0 +1,40 @@
+---
+title: 'Quickstart: PARSIQ (blockchain data API & SDK)'
+description: 'Learn how to use PARSIQ API and SDK to get Arbitrum data'
+author: Ivan-Ivanitskiy
+sme: Ivan-Ivanitskiy
+sidebar_label: 'PARSIQ'
+---
+
+**[<ins>PARSIQ</ins>](https://www.parsiq.net/)** is a reliable, fully customizable blockchain data indexer, helping developers to seamlessly access, process and utilize Web3 data - both raw and custom.
+
+PARSIQ API allows querying blockchain data such as transactions, token transfers, events, internal function calls, blocks, etc.
+
+PARSIQ SDK allows accumulating, processing, and storing this data according to the developer-specified logic, as well as building your own API endpoints.
+
+Check out **[<ins>this introduction video</ins>](https://www.youtube.com/watch?v=kQJYJGt62hc)**
+to get started.
+
+## PARSIQ Tsunami API
+
+PARSIQ Tsunami API is a highly efficient API to fetch raw Web3 data:
+
+- Events, calls, transactions (internal included), transfers, contracts, blocks - you name it. Possibility to use unlimited blockrange makes Tsunami a hard-to-beat solution for realiably getting large amounts of data from the blockchain. CSV Export is available.
+- Get decoded, human readable data right out of the box.
+- Need an up to date feeds of data streamed to you in real time? Give our low latency Real Time Streaming service a try.
+
+:::info Endpoints
+
+Please check out our [<ins>PARSIQ API Reference</ins>](https://docs.parsiq.net/reference/introduction) to see all the available endpoints.
+
+:::
+
+## PARSIQ SDK
+
+Some more complicated cases where custom data needs to be stored, accumulated, and calculated, cannot be covered by an API. In that cases, use PARSIQ SDK or go for a Custom Data Lake. They allow you to set up data bases and data processing logic to solve your specific use case.
+
+:::info SDK Documentation
+
+Please see [<ins>PARSIQ SDK documentation</ins>](https://docs.parsiq.net/reference/your-own-web3-api) for more details.
+
+:::

arbitrum-docs/launch-orbit-chain/concepts/chain-ownership.md

@@ -0,0 +1,49 @@
+---
+title: 'Orbit chain ownership'
+sidebar_label: 'Chain ownership'
+description: 'Overview of the technical architecture of chain ownership affordances on Orbit chains.'
+author: dzgoldman
+sme: dzgoldman
+target_audience: 'Developers deploying and maintaining Orbit chains.'
+sidebar_position: 0
+---
+
+A **chain owner** of an <a data-quicklook-from='arbitrum-orbit'>Orbit</a> chain is an entity that can carry out critical upgrades to the chain's core protocol; this includes upgrading protocol contracts, setting core system parameters, and adding & removing other chain owners.
+
+An Orbit chain's initial chain owner is set by the chain's creator when the chain is deployed.
+
+The chain-ownership architecture is designed to give Orbit chain creators flexibility in deciding how upgrades to their chain occur.
+
+import PublicPreviewBannerPartial from '../partials/_orbit-public-preview-banner-partial.md';
+
+<PublicPreviewBannerPartial />
+
+### Architecture
+
+Chain ownership affordance is handled via [**Upgrade Executor**](https://github.com/OffchainLabs/upgrade-executor) contracts.
+
+Each Orbit chain is deployed with two Upgrade Executors — one on the Orbit chain itself, and one on its <a data-quicklook-from='parent-chain'>parent chain.</a> At deployment, the chain's critical affordances are given to the Upgrade Executor contracts.
+
+Some examples:
+
+- The parent chain's core protocol contracts are upgradeable proxies that are controlled by a proxy admin; the proxy admin is owned by the Upgrade Executor on the parent chain.
+- The core Rollup contract's admin role is given to the Upgrade Executor on the parent chain.
+- The affordance to call setters on the ArbOwner procompile — which allows for setting system gas parameters and scheduling ArbOS upgrades (among other things) — is given to the Upgrade Executor on the Orbit chain.
+
+Calls to an Upgrade Executor can only be made by chain owners; e.g., entities granted the `EXECUTOR_ROLE` affordance on the Upgrade Executor. Upgrade executors also have the `ADMIN_ROLE` affordance granted to themselves, which lets chain owners add or remove chain owners.
+
+With this architecture, the Upgrade Executor represents a single source of truth for affordances over critical upgradability of the chain.
+
+### Upgrades
+
+Upgrades occur via a chain owner initiating a call to an Upgrade Executor, which in turns calls some chain-owned contract.
+
+Chain owners can either call [UpgradeExecutor.executeCall](https://github.com/OffchainLabs/upgrade-executor/blob/a8d3020c2771d164ebd323b1d99249049fe749f9/src/UpgradeExecutor.sol#L73), which will in turn call the target contract directly, or [UpgradeExecutor.execute](https://github.com/OffchainLabs/upgrade-executor/blob/a8d3020c2771d164ebd323b1d99249049fe749f9/src/UpgradeExecutor.sol#L57), which will delegate-call to an "action contract" and use its code to call the target contract.
+
+### Ownership flexibility
+
+A chain owner is simply an address; it is set by the Orbit chain's deployer and can represent any sort of governance scheme. I.e., it could be an EOA (as is set via the [Orbit Quickstart](../orbit-quickstart.md)), a Multisig, a governance token system, etc.
+
+The Arbitrum DAO governed chains, while not Orbit chains themselves, use a similar architecture and upgrade pattern as Orbit chains, with both a governance token and a Multisig (aka, the "Security Council") as chain owners. For more info and best practices on action contracts, see ["DAO Governance Action Contracts"](https://github.com/ArbitrumFoundation/governance/blob/main/src/gov-action-contracts/README.md).
+
+(_NOTE: The DAO Governed chains' Upgrade Executor contracts don't have the `.executeCall` method; only the `.execute` method_)

arbitrum-docs/launch-orbit-chain/how-tos/add-orbit-chain-to-bridge-ui.md

@@ -0,0 +1,30 @@
+---
+title: "How to add your testnet Orbit chain to Arbitrum's bridge"
+sidebar_label: "Add your testnet chain to Arbitrum's bridge"
+description: "Learn how to add your testnet Orbit chain to Arbitrum's bridge."
+author: ojurkowitz
+sidebar_position: 2
+---
+
+import PublicPreviewBannerPartial from '../partials/_orbit-public-preview-banner-partial.md';
+
+<PublicPreviewBannerPartial />
+
+This how-to will walk you through the process of adding your testnet Orbit chain to [Arbitrum's bridge](https://bridge.arbitrum.io/).
+
+## Prerequisites
+
+- A local Orbit testnet chain. See the [Orbit quickstart](/launch-orbit-chain/orbit-quickstart).
+- A browser-based Ethereum wallet (like [MetaMask](https://chrome.google.com/webstore/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn))
+
+## Procedure
+
+1. Navigate to https://bridge.arbitrum.io/.
+2. Connect to Arbitrum Goerli or Sepolia using your wallet. The bridge UI will automatically switch to the correct testnet view.
+   - If you're connected to mainnet, and don't want to switch networks manually in your wallet, then you can enable testnet mode in the bridge by clicking on your address in the top right corner -> Settings -> Turn on testnet mode.
+3. Go to Settings (on the bridge UI) and scroll down to "Add Testnet Orbit Chain":
+   ![Orbit Bridge](../assets/orbit_bridge.png)
+4. Copy and paste the JSON configuration from your generated `outputInfo.json` file.
+5. Click "Add Chain".
+
+Congratulations! Your chain should now appear in both the network dropdown in the top navigation pane, and as an option in the bridging UI directly.

arbitrum-docs/launch-orbit-chain/how-tos/customize-precompile.mdx

@@ -3,7 +3,8 @@ title: "How to customize your Orbit chain's precompiles"
 sidebar_label: "Customize your chain's precompiles"
 description: "Learn how (and when) to customize your Orbit chain's precompiles"
 author: jasonwan
-sidebar_position: 2
+sidebar_position: 4
+content-type: how-to
 ---
 
 import PublicPreviewBannerPartial from '../partials/_orbit-public-preview-banner-partial.md';
@@ -14,9 +15,7 @@ import PublicPreviewBannerPartial from '../partials/_orbit-public-preview-banner
 
 The guidance in this document will work only if you use `eth_call` to call the new precompiles. If you're calling from other contracts or adding non-view/pure methods, this approach will break block validation.
 
-To support these additional use-cases, stay tuned for instructions that walk you through the process of updating the Wasm module root.
-
-If you want to test modifying the State Transition System (STS) before this guidance is available, use the `--node.staker.dangerous.without-block-validator` config flag when you start your node.
+To support these additional use-cases, follow the instructions described in [How to customize your Orbit chain's behavior](/launch-orbit-chain/how-tos/customize-stf.mdx).
 
 :::
 
@@ -51,17 +50,11 @@ Then, open the corresponding Solidity interface file (`ArbSys.sol`) from the [pr
 function sayHi() external view returns(string memory);
 ```
 
-Next, build Nitro by following steps 3-7 of the instructions in [How to build Nitro locally](/node-running/how-tos/build-nitro-locally). Note that if you've already built the Docker image, you still need run the last step to rebuild.
-
-Run Nitro with the following command:
-
-```shell
-docker run --rm -it  -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @latestNitroNodeImage@ --parent-chain.connection.url=<YourParentChainUrl> --chain.id=<YourOrbitChainId> --http.api=net,web3,eth,debug --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=*
-```
+Next, follow the steps in [How to customize your Orbit chain's behavior](./customize-stf.mdx#step-3-run-the-node-without-fraud-proofs) to build a modified Arbitrum Nitro node docker image and run it.
 
 :::info
 
-Note that the instructions provided in [How to run a full node](/node-running/how-tos/running-a-full-node) **will not** work with your Orbit node. See [Command-line options (Orbit)](/launch-orbit-chain/reference/command-line-options) for Orbit-specific CLI flags.
+Note that the instructions provided in [How to run a full node](/node-running/how-tos/running-a-full-node.mdx) **will not** work with your Orbit node. See [Command-line options (Orbit)](/launch-orbit-chain/reference/command-line-options.md) for Orbit-specific CLI flags.
 
 :::
 
@@ -132,17 +125,11 @@ interface ArbHi {
 }
 ```
 
-Next, build Nitro by following the instructions in [How to build Nitro locally](/node-running/how-tos/build-nitro-locally). Note that if you've already built the Docker image, you still need run the last step to rebuild.
-
-Run Nitro with the following command:
-
-```shell
-docker run --rm -it  -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @latestNitroNodeImage@ --parent-chain.connection.url=<YourParentChainUrl> --chain.id=<YourOrbitChainId> --http.api=net,web3,eth,debug --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=*
-```
+Next, follow the steps in [How to customize your Orbit chain's behavior](./customize-stf.mdx#step-3-run-the-node-without-fraud-proofs) to build a modified Arbitrum Nitro node docker image and run it.
 
 :::info
 
-Note that the instructions provided in [How to run a full node](/node-running/how-tos/running-a-full-node) **will not** work with your Orbit node. See [Command-line options (Orbit)](/launch-orbit-chain/reference/command-line-options) for Orbit-specific CLI flags.
+Note that the instructions provided in [How to run a full node](/node-running/how-tos/running-a-full-node.mdx) **will not** work with your Orbit node. See [Command-line options (Orbit)](/launch-orbit-chain/reference/command-line-options.md) for Orbit-specific CLI flags.
 
 :::