From 721a7f029574e947ca04f48c58af38de5367a4ff Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ga=C3=ABl=20Blanchemain?= Date: Tue, 25 Nov 2025 13:57:20 -0800 Subject: [PATCH 1/9] add stub for Arbos 51 upgrade notice --- .../arbos51-arbsepolia-upgrade-notice.mdx | 59 +++++++++++++++++++ sidebars.js | 5 ++ 2 files changed, 64 insertions(+) create mode 100644 docs/notices/arbos51-arbsepolia-upgrade-notice.mdx diff --git a/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx b/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx new file mode 100644 index 000000000..e1b0b6c44 --- /dev/null +++ b/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx @@ -0,0 +1,59 @@ +--- +title: 'Fusaka Compatibility Notice' +description: Upgrade notices for the transition to Fusaka +user_story: As an Arbitrum chain owner or node operator, I want to configure my chain/nodes to run on Fusaka-enabled parent. +content_type: notice +--- + +:::danger 🛑 IMPORTANT 🛑 + +Arbitrum chain operators must ensure that their nodes are properly configured before or shortly after the parent chain upgrades to Fusaka or the child chain upgrades to [ArbOS 50](docs/run-arbitrum-node/arbos-releases/arbos50.mdx). + +::: + +This document explains what you need to do if you operate a chain that settles on a Fusaka-enabled parent chain. This includes actions for Arbitrum Orbit chains as well as actions for Arbitrum One and Arbitrum Nova node operators. + +## What's included in Fusaka + +The Fusaka upgrade introduces several breaking changes. Review [EIP-7607](https://eips.ethereum.org/EIPS/eip-7607) for detailed information about the EIPs included in the Fusaka hard fork. + +## Important dates + +The following dates are relevant for Arbitrum chain operators. + +| Date | Network upgrade | Affected audience | +| ---------------------------------------- | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- | +| `Nov 20th 2025, 17:00:00 UTC` | Arbitrum Sepolia upgrade to [ArbOS 50](docs/run-arbitrum-node/arbos-releases/arbos50.mdx) | Node operators for Arbitrum Sepolia | +| `Jan 8th, 2026, 17:00:00 UTC (proposed)` | Arbitrum One/Nova upgrade to [ArbOS 50](docs/run-arbitrum-node/arbos-releases/arbos50.mdx) | Node operators for Arbitrum One/Nova | +| `Oct 14th 2025, 07:36:00 UTC` | Ethereum Sepolia Fusaka hard fork | Node operators for Arbitrum chains settling on Ethereum Sepolia (Orbit L2s, Arbitrum Sepolia) | +| `Dec 3rd 2025, 21:49:11 UTC` | Ethereum Mainnet Fusaka hard fork | Node operators for Arbitrum chains settling on Ethereum Mainnet (Orbit L2s, Arbitrum One/Nova) | + +## For node operators + +Outlined below are different types of Arbitrum chains, along with node software required for operators of chains in those configurations. + +| Layer | Data Availability | Fallback to blobs enabled? | Required Nitro node version | Configurations for the Ethereum Consensus Layer client | +| ------ | -------------------- | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | +| **L2** | **Rollup** | N/A | Update to [`3.9.0`](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.0) (ArbOS 50); [`3.8.0`](https://github.com/OffchainLabs/nitro/releases/tag/v3.8.0) or [`3.7.6`](https://github.com/OffchainLabs/nitro/releases/tag/v3.7.6) (ArbOS 40 or older) | Requires all [historical blob data](#how-to-ensure-your-node-has-access-to-all-historical-blob-data-and-blob-data-from-all-subnets) | +| **L2** | **AnyTrust / AltDA** | Enabled | Update to [`3.9.0`](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.0) (ArbOS 50); [`3.8.0`](https://github.com/OffchainLabs/nitro/releases/tag/v3.8.0) or [`3.7.6`](https://github.com/OffchainLabs/nitro/releases/tag/v3.7.6) (ArbOS 40 or older) | Requires all [historical blob data](#how-to-ensure-your-node-has-access-to-all-historical-blob-data-and-blob-data-from-all-subnets) | +| **L2** | **AnyTrust / AltDA** | Disabled | No nitro update required | Doesn't require historical blob data | +| **L3** | **Rollup** | N/A | No nitro update required | Doesn't require historical blob data | +| **L3** | **AnyTrust / AltDA** | Enabled or Disabled | No nitro update required | Doesn't require historical blob data | + +### How to ensure your node has access to all historical blob data and blob data from all subnets + +#### If you run a Nitro node and use an external L1 Ethereum beacon chain RPC: + +Confirm that your external L1 beacon chain RPC provider has configured their L1 beacon chain node to subscribe to all subnets before the Ethereum Fusaka hard fork and have all historical blob data to ensure your Nitro node can sync from periods beyond the blob retention period (or that your RPC provider has backfilled the blob data properly). + +#### If you run a Nitro node and operate your own L1 Ethereum beacon chain node: + +Ensure that your consensus layer client & Nitro node is configured as per the table below. + + + +import ClientFlagsTable from '../partials/_client-flags.mdx'; + + + +To read more about Fusaka PeerDAS changes and why Layer 2 network operators must connect to an Ethereum beacon chain node with historical blob data, see the [historical blobs docs](../run-arbitrum-node/beacon-nodes-historical-blobs.mdx). diff --git a/sidebars.js b/sidebars.js index 0261cb84e..d276747e5 100644 --- a/sidebars.js +++ b/sidebars.js @@ -1380,6 +1380,11 @@ const sidebars = { id: 'notices/fusaka-upgrade-notice', label: 'Upgrade for the Fusaka transition', }, + { + type: 'doc', + id: 'notices/arbos51-arbsepolia-upgrade-notice', + label: 'Upgrade for ArbOS 51 on ArbSepolia', + }, ], }; From fe14c9d12f8af968195fc2d4f2ad04c7e092a298 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ga=C3=ABl=20Blanchemain?= Date: Tue, 25 Nov 2025 14:22:46 -0800 Subject: [PATCH 2/9] fix admonition --- .../arbos51-arbsepolia-upgrade-notice.mdx | 60 ++++--------------- 1 file changed, 12 insertions(+), 48 deletions(-) diff --git a/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx b/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx index e1b0b6c44..29b74ee0d 100644 --- a/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx +++ b/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx @@ -1,59 +1,23 @@ --- -title: 'Fusaka Compatibility Notice' -description: Upgrade notices for the transition to Fusaka -user_story: As an Arbitrum chain owner or node operator, I want to configure my chain/nodes to run on Fusaka-enabled parent. +title: 'ArbOS 51 activation on ArbSepolia' +description: Upgrade notices for ArbOS 51 activation on ArbSepolia +user_story: As an Arbitrum chain owner or node operator, I want to configure my chain/nodes to run on ArbSepolia. content_type: notice --- -:::danger 🛑 IMPORTANT 🛑 +On Monday, December 1, 2025 at 17:00 UTC, ArbOS 51 will activate on the Arbitrum Sepolia chain. -Arbitrum chain operators must ensure that their nodes are properly configured before or shortly after the parent chain upgrades to Fusaka or the child chain upgrades to [ArbOS 50](docs/run-arbitrum-node/arbos-releases/arbos50.mdx). +:::warning Action required -::: - -This document explains what you need to do if you operate a chain that settles on a Fusaka-enabled parent chain. This includes actions for Arbitrum Orbit chains as well as actions for Arbitrum One and Arbitrum Nova node operators. - -## What's included in Fusaka - -The Fusaka upgrade introduces several breaking changes. Review [EIP-7607](https://eips.ethereum.org/EIPS/eip-7607) for detailed information about the EIPs included in the Fusaka hard fork. - -## Important dates - -The following dates are relevant for Arbitrum chain operators. - -| Date | Network upgrade | Affected audience | -| ---------------------------------------- | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- | -| `Nov 20th 2025, 17:00:00 UTC` | Arbitrum Sepolia upgrade to [ArbOS 50](docs/run-arbitrum-node/arbos-releases/arbos50.mdx) | Node operators for Arbitrum Sepolia | -| `Jan 8th, 2026, 17:00:00 UTC (proposed)` | Arbitrum One/Nova upgrade to [ArbOS 50](docs/run-arbitrum-node/arbos-releases/arbos50.mdx) | Node operators for Arbitrum One/Nova | -| `Oct 14th 2025, 07:36:00 UTC` | Ethereum Sepolia Fusaka hard fork | Node operators for Arbitrum chains settling on Ethereum Sepolia (Orbit L2s, Arbitrum Sepolia) | -| `Dec 3rd 2025, 21:49:11 UTC` | Ethereum Mainnet Fusaka hard fork | Node operators for Arbitrum chains settling on Ethereum Mainnet (Orbit L2s, Arbitrum One/Nova) | - -## For node operators +Arbitrum Sepolia node operators **must upgrade** to Nitro **`v3.9.3`** ahead of this activation to continue syncing the chain. -Outlined below are different types of Arbitrum chains, along with node software required for operators of chains in those configurations. +- **Docker image:** `offchainlabs/nitro-node:v3.9.0-cca645a` +- **Release notes:** https://github.com/OffchainLabs/nitro/releases/tag/consensus-v51 -| Layer | Data Availability | Fallback to blobs enabled? | Required Nitro node version | Configurations for the Ethereum Consensus Layer client | -| ------ | -------------------- | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | -| **L2** | **Rollup** | N/A | Update to [`3.9.0`](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.0) (ArbOS 50); [`3.8.0`](https://github.com/OffchainLabs/nitro/releases/tag/v3.8.0) or [`3.7.6`](https://github.com/OffchainLabs/nitro/releases/tag/v3.7.6) (ArbOS 40 or older) | Requires all [historical blob data](#how-to-ensure-your-node-has-access-to-all-historical-blob-data-and-blob-data-from-all-subnets) | -| **L2** | **AnyTrust / AltDA** | Enabled | Update to [`3.9.0`](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.0) (ArbOS 50); [`3.8.0`](https://github.com/OffchainLabs/nitro/releases/tag/v3.8.0) or [`3.7.6`](https://github.com/OffchainLabs/nitro/releases/tag/v3.7.6) (ArbOS 40 or older) | Requires all [historical blob data](#how-to-ensure-your-node-has-access-to-all-historical-blob-data-and-blob-data-from-all-subnets) | -| **L2** | **AnyTrust / AltDA** | Disabled | No nitro update required | Doesn't require historical blob data | -| **L3** | **Rollup** | N/A | No nitro update required | Doesn't require historical blob data | -| **L3** | **AnyTrust / AltDA** | Enabled or Disabled | No nitro update required | Doesn't require historical blob data | - -### How to ensure your node has access to all historical blob data and blob data from all subnets - -#### If you run a Nitro node and use an external L1 Ethereum beacon chain RPC: - -Confirm that your external L1 beacon chain RPC provider has configured their L1 beacon chain node to subscribe to all subnets before the Ethereum Fusaka hard fork and have all historical blob data to ensure your Nitro node can sync from periods beyond the blob retention period (or that your RPC provider has backfilled the blob data properly). - -#### If you run a Nitro node and operate your own L1 Ethereum beacon chain node: - -Ensure that your consensus layer client & Nitro node is configured as per the table below. - - +::: -import ClientFlagsTable from '../partials/_client-flags.mdx'; +### **Context** - +ArbOS 51 is a follow-up to [ArbOS 50](docs/run-arbitrum-node/arbos-releases/arbos50.mdx) and includes the activation for multidimensional-pricing instrumentation. ArbOS 50 was previously activated on Sepolia, but the Gas Target & Pricing Framework changes remained disabled pending a fix. ArbOS 51 now completes that work. -To read more about Fusaka PeerDAS changes and why Layer 2 network operators must connect to an Ethereum beacon chain node with historical blob data, see the [historical blobs docs](../run-arbitrum-node/beacon-nodes-historical-blobs.mdx). +Upstream governance items (ArbOS 50 + Gas Target & Pricing Framework) are being bundled into a single on-chain vote. Both components have passed Snapshot temperature checks, with the Tally vote expected to open on or around **December 4, 2025**. From 3ce62175b87b9ad7fffd4a0108347dc4ce963850 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ga=C3=ABl=20Blanchemain?= Date: Tue, 25 Nov 2025 14:42:40 -0800 Subject: [PATCH 3/9] add stub for Arbos 51 release --- .../arbos-releases/arbos51.mdx | 43 +++++++++++++++++++ sidebars.js | 5 +++ 2 files changed, 48 insertions(+) create mode 100644 docs/run-arbitrum-node/arbos-releases/arbos51.mdx diff --git a/docs/run-arbitrum-node/arbos-releases/arbos51.mdx b/docs/run-arbitrum-node/arbos-releases/arbos51.mdx new file mode 100644 index 000000000..4aa2333fa --- /dev/null +++ b/docs/run-arbitrum-node/arbos-releases/arbos51.mdx @@ -0,0 +1,43 @@ +--- +title: 'ArbOS 51' +sidebar_label: 'ArbOS 51' +sidebar_position: 2 +description: 'Learn about ArbOS 51 release, including Fusaka upgrade support, new EIPs, bug fixes, and upgrade requirements for Arbitrum chain owners and node operators.' +user_story: As an Arbitrum chain owner or node operator, I want to know what ArbOS 51 implements. +author: zk-Lumi +sme: zk-Lumi +content_type: release note +--- + +:::warning + +This is a stub/WIP article + +::: + +import { VanillaAdmonition } from '@site/src/components/VanillaAdmonition'; + + + +ArbOS 51 is still pre-release. This document may change. + + + +This page is intended for all Arbitrum node operators and Arbitrum chain owners chains. This page summarizes the changes brought by ArbOS 51, and what you should do to ensure a seamless upgrade. + + + +Before Ethereum Parent chain Sepolia and Mainnet upgrade to Fusaka: ensure that your Nitro node version is upgraded and consensus layer client is configured as per the [Fusaka upgrade notice](../../notices/fusaka-upgrade-notice.mdx). + + +The minimum Nitro version that supports ArbOS 51 is [Nitro v3.9.3](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.3), which is available on Docker Hub with the image tag `Noffchainlabs/nitro-node:v3.9.0-cca645a`. This release of Nitro is a mandatory upgrade for Arbitrum One and Nova node operators if adopted. For Arbitrum One and Nova, the ArbOS 51 upgrade will require a governance vote to activate. + +As a refresher, ArbOS upgrades get treated as Arbitrum's equivalent of a hard fork. To learn more, refer to the [Arbitrum ArbOS upgrades forum post](https://forum.arbitrum.foundation/t/arbitrum-arbos-upgrades/19695). Note that ArbOS 50 is an upgrade that builds upon [ArbOS 40 Callisto](./arbos40.mdx). + +### Requirements + +### High-level description of ArbOS 51 changes + +### Reference links for ArbOS 51 + +- [Guide for how to upgrade ArbOS on your Arbitrum chain](../../launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx) diff --git a/sidebars.js b/sidebars.js index d276747e5..03dacf948 100644 --- a/sidebars.js +++ b/sidebars.js @@ -613,6 +613,11 @@ const sidebars = { id: 'run-arbitrum-node/arbos-releases/overview', label: 'Overview', }, + { + type: 'doc', + id: 'run-arbitrum-node/arbos-releases/arbos51', + label: 'ArbOS 51', + }, { type: 'doc', id: 'run-arbitrum-node/arbos-releases/arbos50', From 54ce405f87455b0a9f38b3444e37538e4a8638b1 Mon Sep 17 00:00:00 2001 From: Daniel Lumi <149794418+zk-Lumi@users.noreply.github.com> Date: Wed, 26 Nov 2025 19:33:55 +0000 Subject: [PATCH 4/9] fix: change nitro versions and arbos version for upgrade --- .../common-configurations/13-arbos-upgrade.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx index f531d4b46..66b1689cd 100644 --- a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx +++ b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx @@ -16,7 +16,7 @@ The specific upgrade requirements for each ArbOS release are located under each #### Step 1: Update Nitro on nodes and validators -Refer to the [requirements for the targeted ArbOS release](/run-arbitrum-node/arbos-releases/01-overview.mdx) to identify the specific [Nitro release](https://github.com/OffchainLabs/nitro/releases/) that supports the ArbOS version that you're upgrading to. For example, if your upgrade targets ArbOS 50, you'd use Nitro `v3.9.0` (Docker image: `offchainlabs/nitro-node:v3.9.0-cca645a`) or higher. This is the version of the Nitro stack that needs to be running on each of your Arbitrum chain's nodes. A list of [all Nitro releases can be found on Github](https://github.com/OffchainLabs/nitro/releases). +Refer to the [requirements for the targeted ArbOS release](/run-arbitrum-node/arbos-releases/01-overview.mdx) to identify the specific [Nitro release](https://github.com/OffchainLabs/nitro/releases/) that supports the ArbOS version that you're upgrading to. For example, if your upgrade targets ArbOS 51, you'd use Nitro `v3.9.3` (Docker image: `offchainlabs/nitro-node:v3.9.0-cca645a`) or higher. This is the version of the Nitro stack that needs to be running on each of your Arbitrum chain's nodes. A list of [all Nitro releases can be found on Github](https://github.com/OffchainLabs/nitro/releases). Begin by upgrading your validator node(s) to the specified Nitro version, then update each remaining Arbitrum chain node to match this version. From 7b45e72df0de50231186cea99244ac6d85debf73 Mon Sep 17 00:00:00 2001 From: Daniel Lumi <149794418+zk-Lumi@users.noreply.github.com> Date: Wed, 26 Nov 2025 19:34:08 +0000 Subject: [PATCH 5/9] fix: change nitro versions and arbos version for upgrade --- .../13-arbos-upgrade.mdx | 14 +- .../arbos51-arbsepolia-upgrade-notice.mdx | 2 +- docs/notices/fusaka-upgrade-notice.mdx | 10 +- .../arbos-releases/01-overview.mdx | 2 +- .../arbos-releases/arbos50.mdx | 152 ------------------ .../arbos-releases/arbos51.mdx | 137 ++++++++++++++-- sidebars.js | 7 +- 7 files changed, 138 insertions(+), 186 deletions(-) delete mode 100644 docs/run-arbitrum-node/arbos-releases/arbos50.mdx diff --git a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx index 66b1689cd..f84626a4a 100644 --- a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx +++ b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx @@ -16,7 +16,7 @@ The specific upgrade requirements for each ArbOS release are located under each #### Step 1: Update Nitro on nodes and validators -Refer to the [requirements for the targeted ArbOS release](/run-arbitrum-node/arbos-releases/01-overview.mdx) to identify the specific [Nitro release](https://github.com/OffchainLabs/nitro/releases/) that supports the ArbOS version that you're upgrading to. For example, if your upgrade targets ArbOS 51, you'd use Nitro `v3.9.3` (Docker image: `offchainlabs/nitro-node:v3.9.0-cca645a`) or higher. This is the version of the Nitro stack that needs to be running on each of your Arbitrum chain's nodes. A list of [all Nitro releases can be found on Github](https://github.com/OffchainLabs/nitro/releases). +Refer to the [requirements for the targeted ArbOS release](/run-arbitrum-node/arbos-releases/01-overview.mdx) to identify the specific [Nitro release](https://github.com/OffchainLabs/nitro/releases/) that supports the ArbOS version that you're upgrading to. For example, if your upgrade targets ArbOS 51, you'd use Nitro `v3.9.0` (Docker image: `offchainlabs/nitro-node:v3.9.0-cca645a`) or higher. This is the version of the Nitro stack that needs to be running on each of your Arbitrum chain's nodes. A list of [all Nitro releases can be found on Github](https://github.com/OffchainLabs/nitro/releases). Begin by upgrading your validator node(s) to the specified Nitro version, then update each remaining Arbitrum chain node to match this version. @@ -26,7 +26,7 @@ Note that upgrading your node version _must occur_ before the deadline establish While every ArbOS upgrade will require an update to the WASM module root, not every ArbOS upgrade will require an upgrade to the chain's `nitro-contracts` version. -If necessary, as defined in the release notes for each ArbOS release ([example of ArbOS 50](/run-arbitrum-node/arbos-releases/arbos50.mdx)), you may need to deploy new versions of some (or all) of the Nitro contracts to the parent chain of your Arbitrum chain. These contracts include the rollup logic, bridging logic, fraud-proof contracts, and interfaces for interacting with Nitro precompiles. To verify the current version of your Nitro contracts, follow [these instructions](https://github.com/OffchainLabs/orbit-actions/blob/main/README.md#check-version-and-upgrade-path) while replacing the inbox contract address and network name with that of your Arbitrum chain. This information will allow you to find the correct upgrade path for your Nitro contracts. +If necessary, as defined in the release notes for each ArbOS release ([example of ArbOS 51](/run-arbitrum-node/arbos-releases/arbos51.mdx)), you may need to deploy new versions of some (or all) of the Nitro contracts to the parent chain of your Arbitrum chain. These contracts include the rollup logic, bridging logic, fraud-proof contracts, and interfaces for interacting with Nitro precompiles. To verify the current version of your Nitro contracts, follow [these instructions](https://github.com/OffchainLabs/orbit-actions/blob/main/README.md#check-version-and-upgrade-path) while replacing the inbox contract address and network name with that of your Arbitrum chain. This information will allow you to find the correct upgrade path for your Nitro contracts. To update the WASM module root and deploy your chain's Nitro contracts to the parent chain for the most recent ArbOS release, you will need the following inputs (obtained from the [requirements for the targeted ArbOS release](/run-arbitrum-node/arbos-releases/01-overview.mdx)): @@ -35,7 +35,7 @@ To update the WASM module root and deploy your chain's Nitro contracts to the pa Once you have the WASM module root and have identified the required `nitro-contracts` version for the target ArbOS release, if any, [please follow the instructions in this guide](https://github.com/OffchainLabs/orbit-actions?tab=readme-ov-file#nitro-contracts-upgrades) for specific actions based on the `nitro-contracts` version you are deploying. Note that each ArbOS release will require performing this step with a different WASM module root and may require a different version of `nitro-contracts`. The guide linked above will be kept updated with the instructions for each specific ArbOS release. -The `WASM module root` is a 32-byte hash created from the Merkelized Go replay binary and its dependencies. When ArbOS is upgraded, a new WASM module root is generated due to modifications in the State Transition Function (STF). This new WASM module root must be set in the rollup contract on the parent chain. For example, the WASM module root for ArbOS 50 Dia is `0x2c54f6e9e378ba320ed9c713a1d9f067a572b1437e4f1c40b1a915d3066c04f2`. +The `WASM module root` is a 32-byte hash created from the Merkelized Go replay binary and its dependencies. When ArbOS is upgraded, a new WASM module root is generated due to modifications in the State Transition Function (STF). This new WASM module root must be set in the rollup contract on the parent chain. For example, the WASM module root for ArbOS 51 Dia is `0x2c54f6e9e378ba320ed9c713a1d9f067a572b1437e4f1c40b1a915d3066c04f2`. To set the WASM module root manually (i.e., not using the above guide), use the `Rollup proxy` contract's [`setWasmModuleRoot`](https://github.com/OffchainLabs/nitro-contracts/blob/38a70a5e14f8b52478eb5db08e7551a82ced14fe/src/rollup/RollupAdminLogic.sol#L321) method. Note that the `upgrade executor` contract on the parent chain is the designated owner of the Rollup contract, so the **chain owner account** needs to initiate a call to the `upgrade executor` contract in order to perform the upgrade. This call should include the correct calldata for setting the new WASM module root. @@ -49,7 +49,7 @@ WASM module roots are backward compatible, so upgrading them before an ArbOS ver To schedule an ArbOS version upgrade for your Arbitrum chain, [follow this guide](https://github.com/OffchainLabs/orbit-actions/tree/main/scripts/foundry/arbos-upgrades/at-timestamp). In addition to the upgrade action contract address and the account address for the chain owner account, you will need the following inputs: -1. **`newVersion`**: Specify the ArbOS version you wish to upgrade to (e.g., `50`). +1. **`newVersion`**: Specify the ArbOS version you wish to upgrade to (e.g., `51`). 2. **`timestamp`**: Set the exact UNIX timestamp at which you want your Arbitrum chain (Orbit) to transition to the new ArbOS version. If you would prefer to do this manually, simply call the [`scheduleArbOSUpgrade`](https://github.com/OffchainLabs/nitro-precompile-interfaces/blob/fe4121240ca1ee2cbf07d67d0e6c38015d94e704/ArbOwner.sol#L116) function on the `ArbOwner` precompile of the Arbitrum chain(s) you're upgrading. Because this is an administrative action (similar to upgrading your Wasm module root), the **chain owner account** must call the target chain's `upgrade executor` contract with the appropriate calldata in order to invoke the `scheduleArbOSUpgrade` function of the ArbOwner precompile. This will schedule the ArbOS upgrade using the specified version and timestamp. @@ -64,14 +64,14 @@ To upgrade immediately (without scheduling), set the timestamp to `0`. You can obtain the current ArbOS version of your chain by calling `ArbSys.ArbOSVersion()`. Keep in mind that this function adds `55` to the current ArbOS version. For example, if your chain is running on ArbOS 10, calling this function will return `65`. -When scheduling the ArbOS upgrade through `ArbOwner.scheduleArbOSUpgrade` you must use the actual ArbOS version you're upgrading to. For example, if you're upgrading to ArbOS 50, you will pass `50` when calling this function. +When scheduling the ArbOS upgrade through `ArbOwner.scheduleArbOSUpgrade` you must use the actual ArbOS version you're upgrading to. For example, if you're upgrading to ArbOS 51, you will pass `51` when calling this function. #### Step 4: Enable ArbOS specific configurations or feature flags (not always required) -For some ArbOS upgrades, such as [ArbOS 50 Dia](/run-arbitrum-node/arbos-releases/arbos50.mdx), there may be additional requirements or steps that need to be satisfied to ensure your Arbitrum chain can use all of the new features and improvements made available in that particular ArbOS release. +For some ArbOS upgrades, such as [ArbOS 51 Dia](/run-arbitrum-node/arbos-releases/arbos51.mdx), there may be additional requirements or steps that need to be satisfied to ensure your Arbitrum chain can use all of the new features and improvements made available in that particular ArbOS release. -If there are additional requirements for the targeted ArbOS release you're attempting to upgrade to; the additional requirements will be listed on the reference pages for [the targeted ArbOS release](/run-arbitrum-node/arbos-releases/01-overview.mdx#list-of-available-arbos-releases). For example, the additional requirements for Arbitrum chains upgrading to ArbOS 50 can be found [here on the ArbOS 50 docs](/run-arbitrum-node/arbos-releases/arbos50.mdx). +If there are additional requirements for the targeted ArbOS release you're attempting to upgrade to; the additional requirements will be listed on the reference pages for [the targeted ArbOS release](/run-arbitrum-node/arbos-releases/01-overview.mdx#list-of-available-arbos-releases). For example, the additional requirements for Arbitrum chains upgrading to ArbOS 51 can be found [here on the ArbOS 51 docs](/run-arbitrum-node/arbos-releases/arbos51.mdx). Congratulations! You've upgraded your Arbitrum chain(s) to the specified ArbOS version. diff --git a/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx b/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx index 29b74ee0d..f16f88552 100644 --- a/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx +++ b/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx @@ -18,6 +18,6 @@ Arbitrum Sepolia node operators **must upgrade** to Nitro **`v3.9.3`** ahead of ### **Context** -ArbOS 51 is a follow-up to [ArbOS 50](docs/run-arbitrum-node/arbos-releases/arbos50.mdx) and includes the activation for multidimensional-pricing instrumentation. ArbOS 50 was previously activated on Sepolia, but the Gas Target & Pricing Framework changes remained disabled pending a fix. ArbOS 51 now completes that work. +ArbOS 51 is a follow-up to ArbOS 50 and includes the activation for multidimensional-pricing instrumentation. ArbOS 50 was previously activated on Sepolia, but the Gas Target & Pricing Framework changes remained disabled pending a fix. ArbOS 51 now completes that work. Upstream governance items (ArbOS 50 + Gas Target & Pricing Framework) are being bundled into a single on-chain vote. Both components have passed Snapshot temperature checks, with the Tally vote expected to open on or around **December 4, 2025**. diff --git a/docs/notices/fusaka-upgrade-notice.mdx b/docs/notices/fusaka-upgrade-notice.mdx index e1b0b6c44..8143c4cd9 100644 --- a/docs/notices/fusaka-upgrade-notice.mdx +++ b/docs/notices/fusaka-upgrade-notice.mdx @@ -7,7 +7,7 @@ content_type: notice :::danger 🛑 IMPORTANT 🛑 -Arbitrum chain operators must ensure that their nodes are properly configured before or shortly after the parent chain upgrades to Fusaka or the child chain upgrades to [ArbOS 50](docs/run-arbitrum-node/arbos-releases/arbos50.mdx). +Arbitrum chain operators must ensure that their nodes are properly configured before or shortly after the parent chain upgrades to Fusaka or the child chain upgrades to [ArbOS 51](docs/run-arbitrum-node/arbos-releases/arbos51.mdx). ::: @@ -23,8 +23,8 @@ The following dates are relevant for Arbitrum chain operators. | Date | Network upgrade | Affected audience | | ---------------------------------------- | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- | -| `Nov 20th 2025, 17:00:00 UTC` | Arbitrum Sepolia upgrade to [ArbOS 50](docs/run-arbitrum-node/arbos-releases/arbos50.mdx) | Node operators for Arbitrum Sepolia | -| `Jan 8th, 2026, 17:00:00 UTC (proposed)` | Arbitrum One/Nova upgrade to [ArbOS 50](docs/run-arbitrum-node/arbos-releases/arbos50.mdx) | Node operators for Arbitrum One/Nova | +| `Nov 20th 2025, 17:00:00 UTC` | Arbitrum Sepolia upgrade to [ArbOS 51](docs/run-arbitrum-node/arbos-releases/arbos51.mdx) | Node operators for Arbitrum Sepolia | +| `Jan 8th, 2026, 17:00:00 UTC (proposed)` | Arbitrum One/Nova upgrade to [ArbOS 51](docs/run-arbitrum-node/arbos-releases/arbos51.mdx) | Node operators for Arbitrum One/Nova | | `Oct 14th 2025, 07:36:00 UTC` | Ethereum Sepolia Fusaka hard fork | Node operators for Arbitrum chains settling on Ethereum Sepolia (Orbit L2s, Arbitrum Sepolia) | | `Dec 3rd 2025, 21:49:11 UTC` | Ethereum Mainnet Fusaka hard fork | Node operators for Arbitrum chains settling on Ethereum Mainnet (Orbit L2s, Arbitrum One/Nova) | @@ -34,8 +34,8 @@ Outlined below are different types of Arbitrum chains, along with node software | Layer | Data Availability | Fallback to blobs enabled? | Required Nitro node version | Configurations for the Ethereum Consensus Layer client | | ------ | -------------------- | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | -| **L2** | **Rollup** | N/A | Update to [`3.9.0`](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.0) (ArbOS 50); [`3.8.0`](https://github.com/OffchainLabs/nitro/releases/tag/v3.8.0) or [`3.7.6`](https://github.com/OffchainLabs/nitro/releases/tag/v3.7.6) (ArbOS 40 or older) | Requires all [historical blob data](#how-to-ensure-your-node-has-access-to-all-historical-blob-data-and-blob-data-from-all-subnets) | -| **L2** | **AnyTrust / AltDA** | Enabled | Update to [`3.9.0`](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.0) (ArbOS 50); [`3.8.0`](https://github.com/OffchainLabs/nitro/releases/tag/v3.8.0) or [`3.7.6`](https://github.com/OffchainLabs/nitro/releases/tag/v3.7.6) (ArbOS 40 or older) | Requires all [historical blob data](#how-to-ensure-your-node-has-access-to-all-historical-blob-data-and-blob-data-from-all-subnets) | +| **L2** | **Rollup** | N/A | Update to [`3.9.3`](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.3) (ArbOS 51); [`3.8.0`](https://github.com/OffchainLabs/nitro/releases/tag/v3.8.0) or [`3.7.6`](https://github.com/OffchainLabs/nitro/releases/tag/v3.7.6) (ArbOS 40 or older) | Requires all [historical blob data](#how-to-ensure-your-node-has-access-to-all-historical-blob-data-and-blob-data-from-all-subnets) | +| **L2** | **AnyTrust / AltDA** | Enabled | Update to [`3.9.3`](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.3) (ArbOS 51); [`3.8.0`](https://github.com/OffchainLabs/nitro/releases/tag/v3.8.0) or [`3.7.6`](https://github.com/OffchainLabs/nitro/releases/tag/v3.7.6) (ArbOS 40 or older) | Requires all [historical blob data](#how-to-ensure-your-node-has-access-to-all-historical-blob-data-and-blob-data-from-all-subnets) | | **L2** | **AnyTrust / AltDA** | Disabled | No nitro update required | Doesn't require historical blob data | | **L3** | **Rollup** | N/A | No nitro update required | Doesn't require historical blob data | | **L3** | **AnyTrust / AltDA** | Enabled or Disabled | No nitro update required | Doesn't require historical blob data | diff --git a/docs/run-arbitrum-node/arbos-releases/01-overview.mdx b/docs/run-arbitrum-node/arbos-releases/01-overview.mdx index 5d1dbc91a..46c762998 100644 --- a/docs/run-arbitrum-node/arbos-releases/01-overview.mdx +++ b/docs/run-arbitrum-node/arbos-releases/01-overview.mdx @@ -31,7 +31,7 @@ Visit [How Arbitrum works](/how-arbitrum-works/01-inside-arbitrum-nitro.mdx) to ## List of available ArbOS releases -- [Dia (ArbOS 50)](/run-arbitrum-node/arbos-releases/arbos50.mdx) +- [Dia (ArbOS 51)](/run-arbitrum-node/arbos-releases/arbos51.mdx) - [Callisto (ArbOS 40)](/run-arbitrum-node/arbos-releases/arbos40.mdx) - [Bianca (ArbOS 32)](/run-arbitrum-node/arbos-releases/arbos32.mdx) - [Atlas (ArbOS 20)](/run-arbitrum-node/arbos-releases/arbos20.mdx) diff --git a/docs/run-arbitrum-node/arbos-releases/arbos50.mdx b/docs/run-arbitrum-node/arbos-releases/arbos50.mdx deleted file mode 100644 index deb96184b..000000000 --- a/docs/run-arbitrum-node/arbos-releases/arbos50.mdx +++ /dev/null @@ -1,152 +0,0 @@ ---- -title: 'ArbOS 50 Dia' -sidebar_label: 'ArbOS 50 Dia' -sidebar_position: 2 -description: 'Learn about ArbOS 50 Dia release, including Fusaka upgrade support, new EIPs, bug fixes, and upgrade requirements for Arbitrum chain owners and node operators.' -user_story: As an Arbitrum chain owner or node operator, I want to know what ArbOS 50 implements. -author: zk-Lumi -sme: zk-Lumi -content_type: release note ---- - -import { VanillaAdmonition } from '@site/src/components/VanillaAdmonition'; - - - -ArbOS 50 Dia is still pre-release. This document may change. - - - -This page is intended for all Arbitrum node operators and Arbitrum chain owners chains. This page summarizes the changes brought by ArbOS 50 Dia, and what you should do to ensure a seamless upgrade. - - - -Before Ethereum Parent chain Sepolia and Mainnet upgrade to Fusaka: ensure that your Nitro node version is upgraded and consensus layer client is configured as per the [Fusaka upgrade notice](../../notices/fusaka-upgrade-notice.mdx). - - -The minimum Nitro version that supports ArbOS 50 "Dia" is [Nitro v3.9.0](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.0), which is available on Docker Hub with the image tag `Noffchainlabs/nitro-node:v3.9.0-cca645a`. This release of Nitro is a mandatory upgrade for Arbitrum One and Nova node operators if adopted. For Arbitrum One and Nova, the ArbOS 50 "Dia" upgrade will require a governance vote to activate. - -As a refresher, ArbOS upgrades get treated as Arbitrum's equivalent of a hard fork. To learn more, refer to the [Arbitrum ArbOS upgrades forum post](https://forum.arbitrum.foundation/t/arbitrum-arbos-upgrades/19695). Note that ArbOS 50 Dia is an upgrade that builds upon [ArbOS 40 Callisto](./arbos40.mdx). - -### Requirements - -- Having read and understood the [ArbOS Software Releases Overview page](./01-overview.mdx). -- Running [Nitro v3.9.0](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.0) or higher, which is available on Docker Hub with the image tag `offchainlabs/nitro-node:v3.9.0-cca645a`. - - Note that it's important to run Nitro v3.9.0 only against trusted databases. If you want to use an untrusted database, you can first remove the `wasm` directory if it exists (potentially inside the `nitro` folder). Otherwise, the database may have malicious, unvalidated code that can result in remote code execution. Avoiding unvalidated code is also mitigated by ensuring you run the Arbitrum Nitro node inside Docker. -- Running [nitro-contracts v3.1.0](https://github.com/OffchainLabs/nitro-contracts/releases/tag/v3.1.0) or higher - - If your chain isn't ready to activate BoLD, use [nitro-contracts v2.1.3](https://github.com/OffchainLabs/nitro-contracts/releases/tag/v2.1.3) instead; v3.0.0 or higher can't be used without activating BoLD. - - If you want to enable [Native Token Mint/Burn capabilities](#native-token-mint-and-burn) for your chain, you must use [nitro-contracts v3.1.1](https://github.com/OffchainLabs/nitro-contracts/releases/tag/v3.1.1) or higher. -- WASM module root: `0x2c54f6e9e378ba320ed9c713a1d9f067a572b1437e4f1c40b1a915d3066c04f2` -- If the Arbitrum chain posts blobs to a Fusaka-enabled parent chain, ensure that the consensus layer client is configured correctly as per the [Fusaka upgrade notice](../../notices/fusaka-upgrade-notice.mdx). - -### High-level description of ArbOS 50 changes - -ArbOS 50 Dia is an upgrade to support the relevant EVM changes that are a part of Ethereum's [Fusaka upgrade](https://ethereum.org/en/roadmap/fusaka/). Ethereum's mainnet upgrade to Fusaka is tentatively scheduled for [December 3, 2025 at epoch `411392`](https://notes.ethereum.org/@bbusa/fusaka-bpo-timeline). As a result, the majority of the ArbOS-specific changes revolve around implementing the relevant [Fusaka EIPs](https://eips.ethereum.org/EIPS/eip-7607) on Arbitrum Chains. - -Here's the list of all changes included in ArbOS 50 Dia: - -#### [EIP-7951: Precompile for secp256r1 curve support](https://eips.ethereum.org/EIPS/eip-7951) - -This EIP implements the same functionality and interface as [RIP-7212](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md), which was activated as part of [ArbOS 31 Bianca](https://forum.arbitrum.foundation/t/aip-arbos-31-bianca-activation-of-arbitrum-stylus-rip-7212-support-nova-fee-router-proposal/25904). The main difference here is to add a point-at-infinity check and to update the comparison step in the signature verification algorithm. Developers should expect the same behavior as the EIP being proposed on Ethereum after Fusaka is activated. - -#### [EIP-7825: Transaction gas limit cap](https://eips.ethereum.org/EIPS/eip-7825) - -This EIP introduces a gas cap for individual transactions. The goal is to ensure fairer access to block space and improve network stability. For Arbitrum One and Arbitrum Nova we're proposing a 32 million gas limit (Child chain execution gas, not including parent chain gas) per transaction, which is the same as the current block gas limit. This 32 million gas limit diverges from the EIP's proposed limit of 16 million gas per transaction for Ethereum parent chain. Orbit chains can customize this value according to their chains' needs. - -#### [EIP-7642: eth/69 - history expiry and simpler receipts](https://eips.ethereum.org/EIPS/eip-7642) - -This networking upgrade removes deprecated fields used prior to Ethereum's Proof of Stake (PoS) transition. We're including this EIP as part of Geth upstream. This is a networking change that impacts mainly parent chain nodes. As Arbitrum nodes don't have a P2P layer, we don't expect this to have any impact on Arbitrum node operators. - -#### [EIP-7939: Count leading zeros (CLZ) opcode](https://eips.ethereum.org/EIPS/eip-7939) - -This EIP adds a new CLZ (Count Leading Zeros) opcode to efficiently count the number of zero bits at the start of a 256-bit number. This is a fundamental mathematical operation used in many algorithms, especially for mathematical computations, data compression, and cryptographic operations. Currently, implementing this operation in Solidity requires complex and expensive code - this opcode makes it much cheaper and faster. - -#### [EIP-7823: Set upper bounds for ModExp](https://eips.ethereum.org/EIPS/eip-7823) - -This EIP introduces an 8192-bit (1024 byte) limit on each input to the ModExp cryptographic precompile. ModExp has been a source of consensus bugs due to unbounded inputs. By setting practical limits that cover real-world use cases (like RSA verification), this reduces the testing surface area and paves the way for future replacement with more efficient EVM code. - -#### [EIP-7883: ModExp gas cost increase](https://eips.ethereum.org/EIPS/eip-7883) - -This EIP increases the gas cost of the ModExp cryptographic precompile to address underpriced operations. It raises the minimum cost from 200 to 500 gas and doubles the costs for large inputs over 32 bytes. - -#### [EIP-7910: eth_config JSON-RPC method](https://eips.ethereum.org/EIPS/eip-7910) - -This EIP provides a new RPC method that allows the Arbitrum Nitro node to respond with key configuration variables, offering node operators the ability to gain greater confidence that their Nitro nodes are correctly configured and prepared for upcoming forks. In future Nitro releases, we expect to include additional fields specific to Arbitrum chains. This update is at the RPC level and may be enabled later than the ArbOS 50 Dia upgrade. - -#### [EIP-2537: Precompile for BLS12-381 curve operations](https://eips.ethereum.org/EIPS/eip-2537) - -As [disclosed previously](https://forum.arbitrum.foundation/t/disclosure-of-support-for-eip-2537-on-arbitrum-one-and-nova/29720), the precompiled contracts for performing various operations over the BLS12-381 elliptic curve, including BLS Signature verification, were added but not properly enabled in [ArbOS 40 Callisto](./arbos40.mdx) as originally expected. ArbOS 50 Dia will now enable `EIP-2537`. - -#### ArbOS block limit change: Effective block gas limit - -Since ArbOS 50 introduces a `MaxTxGasLimit`, the State Transition Function (STF) will be relaxed in ArbOS 50 to allow the final transaction in a block to use up to the `MaxTxGasLimit` even if it would cause the block to exceed `MaxBlockGasLimit`. This means that the "Effective Block Gas Limit" is really `MaxBlockGasLimit + MaxTxGasLimit`. In previous versions of ArbOS, the Sequencer would skip transactions if the transaction request's `GasLimit` minus the parent chain data posting gas exceeded the gas remaining in the block. - -The new algorithm is more efficient because the sequencer doesn't need to keep searching through the queue of transactions to find one that fits in the remaining block gas, and can continue to add transactions until the unused block gas is 0. - -This change doesn't affect the `GasTarget`, and therefore doesn't affect how much overall gas per second the chain will use - only how transactions using that gas could be divided between different blocks. - -#### A few bug fixes - -- ArbOS didn't get updated for parent chain calldata price increase - - This change standardizes the calculation of gas units for compressed Batch calldata across the codebase by replacing hard-coded values with a method call (tokenGasUnits). -- `EIP-7702` precompile delegation behavior divergence - - Previously, calls to precompiles could execute an INVALID opcode instead of succeeding with no execution. ArbOS 50 Dia will update code to align with `EIP-7702` spec to treat precompile code as empty during delegation. -- ARM and x86 divergence - - This change adds a map to store transaction hash along with its gas used to bypass transaction execution for a problematic transaction execution which diverged between ARM and x86 architectures. This was added in to hardcode one transaction that caused the divergence on Arbitrum Sepolia, as disclosed in the [security council emergency Action report](https://forum.arbitrum.foundation/t/security-council-emergency-action-10-13-2025/30093). - - The default WASM Stack Depth value in ArbOS is now set to 22,000, preventing new chains from encountering the same divergence issue. - -#### Raising the gas target, increasing the min L2 base fee, & improving the pricing algorithm - -As part of our strategy for scaling Arbitrum technology, the ArbOS 50 release includes a slight change to improve the pricing algorithm for Arbitrum One and Nova. This improvement is aimed at reducing the severity, frequency, and duration of high L2 gas prices during periods of elevated demand on the network. Concretely, the changes are to: - -- Replace the current single gas target and single adjustment window, with a new model that employs multiple (higher) gas targets, measured over multiple adjustment windows. -- Increase the default minimum L2 base fee from 0.01 gwei per gas to 0.02 gwei per gas. - -To read more about this change, see the [AIP for raising the gas target & improvements to the pricing algorithm](https://forum.arbitrum.foundation/t/aip-raise-the-gas-target-implement-improvements-to-the-pricing-algorithm/30182). - -#### A constraint-based pricing change: STF instrumentation to track multi-gas - -We've instrumented Arbitrum's State Transition Function (STF) to track gas usage across multiple resource types including computation, storage access, storage growth, and history growth, rather than only a single total based on opcodes. This work lays the foundation for dynamic, constraint-based pricing where gas fees can adjust based on the most constrained resource at the network level. The goal is to create more stable prices, improve responsiveness to spikes, and allow the network to safely increase throughput without overloading node hardware. In this release, none of the constraints are enabled, so there won't be any impact on current gas prices. This update simply adds the ability to measure and record per-resource usage, with actual pricing changes coming in a later version once constraints are configured, benchmarked and tested. - -To read more about this feature, see the [dynamic pricing explainer](https://blog.arbitrum.io/dynamic-pricing-explainer/). - -#### Native token mint and burn - -Native token mint and burn is a feature that allows Arbitrum chains to use interoperability-enabled token standards (e.g., LayerZero OFTs, xERC20s, native USDC) as native gas tokens on their chains. Currently, Arbitrum chains are designed to "lock and mint" native gas tokens on the chain's canonical Bridge. However, doing so means that these "locked and minted" native gas tokens can't interact with third-party cross-chain adapter contracts. This new feature lets an Arbitrum chain delegate minting and burning of its native gas token to a trusted bridge provider (e.g., LayerZero OFT). - -Native token mint and burn is included in ArbOS 50 Dia for the benefit of Arbitrum Orbit chains (reducing the need for forks) and to streamline development and testing into a single codebase. There are no plans to enable this feature on Arbitrum One or Arbitrum Nova, consequently this feature will be explicitly left disabled for Arbitrum One and Arbitrum Nova. - -To read more about this feature, see the [Native Token Mint/Burn enablement guide](https://arbitrum.notion.site/Enable-Native-Mint-Burn-for-your-chain-s-gas-token-22601a3f59f880be9b99d3d55f982a17). - - - -If you want to enable Native Token Mint/Burn capabilities for your chain, you must use [nitro-contracts v3.1.1](https://github.com/OffchainLabs/nitro-contracts/releases/tag/v3.1.1) or higher. - - - -### Fusaka EIPs that aren't proposed to be in ArbOS 50 Dia - -Support and implementation for the following EIPs aren't planned to be part of ArbOS 50 Dia: - -- [EIP-7594](https://eips.ethereum.org/EIPS/eip-7594), [EIP-7918](https://eips.ethereum.org/EIPS/eip-7918), and [EIP-7892](https://eips.ethereum.org/EIPS/eip-7892), since Arbitrum chains don't have blob data markets (though they do support posting blob data to a non-Arbitrum parent chain) -- [EIP-7917](https://eips.ethereum.org/EIPS/eip-7917), since Arbitrum chains don't have a beacon chain and therefore don't have a peer-to-peer layer like Ethereum does -- [EIP-7934](https://eips.ethereum.org/EIPS/eip-7934), this EIP is to help propagating blocks between nodes. Arbitrum doesn't do that - it sends messages (which are limited) and each node builds every block by itself -- [EIP-7907](https://eips.ethereum.org/EIPS/eip-7907), this EIP is no longer Scheduled For Inclusion (SFI) for Fusaka, as agreed upon by Client teams during [ACDE 216](https://ethereum-magicians.org/t/allcoredevs-execution-acde-216-july-17-2025/24770/2) on July 17, 2025. We're currently exploring alternative ways to increase the Smart Contract size limit that don't interfere with the ability for Arbitrum chains to support `EIP-7907` in the future. See this [forum post reply](https://forum.arbitrum.foundation/t/non-constitutional-proposal-to-direct-the-arbitrum-foundation-to-implement-an-extended-version-of-eip-7907-and-for-the-dao-to-ratify-its-deployment-on-arbitrum-one/29375/3) for more details about this. -- [EIP-7935](https://eips.ethereum.org/EIPS/eip-7935), since Arbitrum chains already have a default gas target of 28Mgas/s and we have separate, alternative plans for increasing the gas limit through other means, as mentioned in [Scaling Arbitrum everywhere](https://blog.arbitrum.io/scaling-arbitrum-everywhere/). - -### Special note about ArbOS 50 Dia for chains that haven't yet upgraded to use Arbitrum BoLD - -While ArbOS 50 Dia will be compatible with both `nitro-contracts 3.1.X` and `nitro-contracts 2.1.3`, only chains that have Arbitrum BoLD enabled can use `nitro-contracts 3.x`. This requirement means that if your chain hasn't yet upgraded to use BoLD, only use `nitro-contracts 2.1.3` for your ArbOS 50 Dia upgrade. - -### Reference links for ArbOS 50 Dia - -- [Guide for how to upgrade ArbOS on your Arbitrum chain](../../launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx) -- [README for how to upgrade your rollup contracts to support ArbOS 50 on your chain](https://github.com/OffchainLabs/orbit-actions?tab=readme-ov-file#nitro-contracts-upgrades) -- [Nitro v3.9.0](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.0) -- [nitro-contracts v3.1.1](https://github.com/OffchainLabs/nitro-contracts/releases/tag/v3.1.1) -- [nitro-contracts v2.1.3](https://github.com/OffchainLabs/nitro-contracts/releases/tag/v2.1.3) (only relevant for Arbitrum chains that don't have BoLD enabled yet) -- [AIP: ArbOS Version 50 Dia Forum Post](https://forum.arbitrum.foundation/t/constitutional-aip-arbos-version-50-dia/) -- [Temperature check vote on Snapshot for ArbOS 50 Dia](https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x33754da4006d0ef38666ec5d5e85fd0966a891a594ab9dc21f23beedea2d330b) -- [AIP: Raising the gas target & improvements to pricing algorithm Forum Post](https://forum.arbitrum.foundation/t/aip-raise-the-gas-target-implement-improvements-to-the-pricing-algorithm/30182) -- [Temperature check vote on Snapshot for Raising the gas target & improvements to pricing algorithm](https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x4a96a91d162975de0d402b83ca8b8a24e808ca357150120fc0d44ae0bf1cc4a5) -- Coming Soon - ArbOS 50 Audit Report, from Trail of Bits diff --git a/docs/run-arbitrum-node/arbos-releases/arbos51.mdx b/docs/run-arbitrum-node/arbos-releases/arbos51.mdx index 4aa2333fa..373856698 100644 --- a/docs/run-arbitrum-node/arbos-releases/arbos51.mdx +++ b/docs/run-arbitrum-node/arbos-releases/arbos51.mdx @@ -1,43 +1,152 @@ --- -title: 'ArbOS 51' -sidebar_label: 'ArbOS 51' +title: 'ArbOS 51 Dia' +sidebar_label: 'ArbOS 51 Dia' sidebar_position: 2 -description: 'Learn about ArbOS 51 release, including Fusaka upgrade support, new EIPs, bug fixes, and upgrade requirements for Arbitrum chain owners and node operators.' +description: 'Learn about ArbOS 51 Dia release, including Fusaka upgrade support, new EIPs, bug fixes, and upgrade requirements for Arbitrum chain owners and node operators.' user_story: As an Arbitrum chain owner or node operator, I want to know what ArbOS 51 implements. author: zk-Lumi sme: zk-Lumi content_type: release note --- -:::warning - -This is a stub/WIP article - -::: - import { VanillaAdmonition } from '@site/src/components/VanillaAdmonition'; -ArbOS 51 is still pre-release. This document may change. +ArbOS 51 Dia is still pre-release. This document may change. -This page is intended for all Arbitrum node operators and Arbitrum chain owners chains. This page summarizes the changes brought by ArbOS 51, and what you should do to ensure a seamless upgrade. +This page is intended for all Arbitrum node operators and Arbitrum chain owners chains. This page summarizes the changes brought by ArbOS 51 Dia, and what you should do to ensure a seamless upgrade. Before Ethereum Parent chain Sepolia and Mainnet upgrade to Fusaka: ensure that your Nitro node version is upgraded and consensus layer client is configured as per the [Fusaka upgrade notice](../../notices/fusaka-upgrade-notice.mdx). -The minimum Nitro version that supports ArbOS 51 is [Nitro v3.9.3](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.3), which is available on Docker Hub with the image tag `Noffchainlabs/nitro-node:v3.9.0-cca645a`. This release of Nitro is a mandatory upgrade for Arbitrum One and Nova node operators if adopted. For Arbitrum One and Nova, the ArbOS 51 upgrade will require a governance vote to activate. +The minimum Nitro version that supports ArbOS 51 "Dia" is [Nitro v3.9.3](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.3), which is available on Docker Hub with the image tag `Noffchainlabs/nitro-node:v3.9.0-cca645a`. This release of Nitro is a mandatory upgrade for Arbitrum One and Nova node operators if adopted. For Arbitrum One and Nova, the ArbOS 51 "Dia" upgrade will require a governance vote to activate. -As a refresher, ArbOS upgrades get treated as Arbitrum's equivalent of a hard fork. To learn more, refer to the [Arbitrum ArbOS upgrades forum post](https://forum.arbitrum.foundation/t/arbitrum-arbos-upgrades/19695). Note that ArbOS 50 is an upgrade that builds upon [ArbOS 40 Callisto](./arbos40.mdx). +As a refresher, ArbOS upgrades get treated as Arbitrum's equivalent of a hard fork. To learn more, refer to the [Arbitrum ArbOS upgrades forum post](https://forum.arbitrum.foundation/t/arbitrum-arbos-upgrades/19695). Note that ArbOS 51 Dia is an upgrade that builds upon [ArbOS 40 Callisto](./arbos40.mdx). ### Requirements +- Having read and understood the [ArbOS Software Releases Overview page](./01-overview.mdx). +- Running [Nitro v3.9.3](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.3) or higher, which is available on Docker Hub with the image tag `offchainlabs/nitro-node:v3.9.0-cca645a`. + - Note that it's important to run Nitro v3.9.3 only against trusted databases. If you want to use an untrusted database, you can first remove the `wasm` directory if it exists (potentially inside the `nitro` folder). Otherwise, the database may have malicious, unvalidated code that can result in remote code execution. Avoiding unvalidated code is also mitigated by ensuring you run the Arbitrum Nitro node inside Docker. +- Running [nitro-contracts v3.1.0](https://github.com/OffchainLabs/nitro-contracts/releases/tag/v3.1.0) or higher + - If your chain isn't ready to activate BoLD, use [nitro-contracts v2.1.3](https://github.com/OffchainLabs/nitro-contracts/releases/tag/v2.1.3) instead; v3.0.0 or higher can't be used without activating BoLD. + - If you want to enable [Native Token Mint/Burn capabilities](#native-token-mint-and-burn) for your chain, you must use [nitro-contracts v3.1.1](https://github.com/OffchainLabs/nitro-contracts/releases/tag/v3.1.1) or higher. +- WASM module root: `0x2c54f6e9e378ba320ed9c713a1d9f067a572b1437e4f1c40b1a915d3066c04f2` +- If the Arbitrum chain posts blobs to a Fusaka-enabled parent chain, ensure that the consensus layer client is configured correctly as per the [Fusaka upgrade notice](../../notices/fusaka-upgrade-notice.mdx). + ### High-level description of ArbOS 51 changes -### Reference links for ArbOS 51 +ArbOS 51 Dia is an upgrade to support the relevant EVM changes that are a part of Ethereum's [Fusaka upgrade](https://ethereum.org/en/roadmap/fusaka/). Ethereum's mainnet upgrade to Fusaka is tentatively scheduled for [December 3, 2025 at epoch `411392`](https://notes.ethereum.org/@bbusa/fusaka-bpo-timeline). As a result, the majority of the ArbOS-specific changes revolve around implementing the relevant [Fusaka EIPs](https://eips.ethereum.org/EIPS/eip-7607) on Arbitrum Chains. + +Here's the list of all changes included in ArbOS 51 Dia: + +#### [EIP-7951: Precompile for secp256r1 curve support](https://eips.ethereum.org/EIPS/eip-7951) + +This EIP implements the same functionality and interface as [RIP-7212](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md), which was activated as part of [ArbOS 31 Bianca](https://forum.arbitrum.foundation/t/aip-arbos-31-bianca-activation-of-arbitrum-stylus-rip-7212-support-nova-fee-router-proposal/25904). The main difference here is to add a point-at-infinity check and to update the comparison step in the signature verification algorithm. Developers should expect the same behavior as the EIP being proposed on Ethereum after Fusaka is activated. + +#### [EIP-7825: Transaction gas limit cap](https://eips.ethereum.org/EIPS/eip-7825) + +This EIP introduces a gas cap for individual transactions. The goal is to ensure fairer access to block space and improve network stability. For Arbitrum One and Arbitrum Nova we're proposing a 32 million gas limit (Child chain execution gas, not including parent chain gas) per transaction, which is the same as the current block gas limit. This 32 million gas limit diverges from the EIP's proposed limit of 16 million gas per transaction for Ethereum parent chain. Orbit chains can customize this value according to their chains' needs. + +#### [EIP-7642: eth/69 - history expiry and simpler receipts](https://eips.ethereum.org/EIPS/eip-7642) + +This networking upgrade removes deprecated fields used prior to Ethereum's Proof of Stake (PoS) transition. We're including this EIP as part of Geth upstream. This is a networking change that impacts mainly parent chain nodes. As Arbitrum nodes don't have a P2P layer, we don't expect this to have any impact on Arbitrum node operators. + +#### [EIP-7939: Count leading zeros (CLZ) opcode](https://eips.ethereum.org/EIPS/eip-7939) + +This EIP adds a new CLZ (Count Leading Zeros) opcode to efficiently count the number of zero bits at the start of a 256-bit number. This is a fundamental mathematical operation used in many algorithms, especially for mathematical computations, data compression, and cryptographic operations. Currently, implementing this operation in Solidity requires complex and expensive code - this opcode makes it much cheaper and faster. + +#### [EIP-7823: Set upper bounds for ModExp](https://eips.ethereum.org/EIPS/eip-7823) + +This EIP introduces an 8192-bit (1024 byte) limit on each input to the ModExp cryptographic precompile. ModExp has been a source of consensus bugs due to unbounded inputs. By setting practical limits that cover real-world use cases (like RSA verification), this reduces the testing surface area and paves the way for future replacement with more efficient EVM code. + +#### [EIP-7883: ModExp gas cost increase](https://eips.ethereum.org/EIPS/eip-7883) + +This EIP increases the gas cost of the ModExp cryptographic precompile to address underpriced operations. It raises the minimum cost from 200 to 500 gas and doubles the costs for large inputs over 32 bytes. + +#### [EIP-7910: eth_config JSON-RPC method](https://eips.ethereum.org/EIPS/eip-7910) + +This EIP provides a new RPC method that allows the Arbitrum Nitro node to respond with key configuration variables, offering node operators the ability to gain greater confidence that their Nitro nodes are correctly configured and prepared for upcoming forks. In future Nitro releases, we expect to include additional fields specific to Arbitrum chains. This update is at the RPC level and may be enabled later than the ArbOS 51 Dia upgrade. + +#### [EIP-2537: Precompile for BLS12-381 curve operations](https://eips.ethereum.org/EIPS/eip-2537) + +As [disclosed previously](https://forum.arbitrum.foundation/t/disclosure-of-support-for-eip-2537-on-arbitrum-one-and-nova/29720), the precompiled contracts for performing various operations over the BLS12-381 elliptic curve, including BLS Signature verification, were added but not properly enabled in [ArbOS 40 Callisto](./arbos40.mdx) as originally expected. ArbOS 51 Dia will now enable `EIP-2537`. + +#### ArbOS block limit change: Effective block gas limit + +Since ArbOS 51 introduces a `MaxTxGasLimit`, the State Transition Function (STF) will be relaxed in ArbOS 51 to allow the final transaction in a block to use up to the `MaxTxGasLimit` even if it would cause the block to exceed `MaxBlockGasLimit`. This means that the "Effective Block Gas Limit" is really `MaxBlockGasLimit + MaxTxGasLimit`. In previous versions of ArbOS, the Sequencer would skip transactions if the transaction request's `GasLimit` minus the parent chain data posting gas exceeded the gas remaining in the block. + +The new algorithm is more efficient because the sequencer doesn't need to keep searching through the queue of transactions to find one that fits in the remaining block gas, and can continue to add transactions until the unused block gas is 0. + +This change doesn't affect the `GasTarget`, and therefore doesn't affect how much overall gas per second the chain will use - only how transactions using that gas could be divided between different blocks. + +#### A few bug fixes + +- ArbOS didn't get updated for parent chain calldata price increase + - This change standardizes the calculation of gas units for compressed Batch calldata across the codebase by replacing hard-coded values with a method call (tokenGasUnits). +- `EIP-7702` precompile delegation behavior divergence + - Previously, calls to precompiles could execute an INVALID opcode instead of succeeding with no execution. ArbOS 51 Dia will update code to align with `EIP-7702` spec to treat precompile code as empty during delegation. +- ARM and x86 divergence + - This change adds a map to store transaction hash along with its gas used to bypass transaction execution for a problematic transaction execution which diverged between ARM and x86 architectures. This was added in to hardcode one transaction that caused the divergence on Arbitrum Sepolia, as disclosed in the [security council emergency Action report](https://forum.arbitrum.foundation/t/security-council-emergency-action-10-13-2025/30093). + - The default WASM Stack Depth value in ArbOS is now set to 22,000, preventing new chains from encountering the same divergence issue. + +#### Raising the gas target, increasing the min L2 base fee, & improving the pricing algorithm + +As part of our strategy for scaling Arbitrum technology, the ArbOS 51 release includes a slight change to improve the pricing algorithm for Arbitrum One and Nova. This improvement is aimed at reducing the severity, frequency, and duration of high L2 gas prices during periods of elevated demand on the network. Concretely, the changes are to: + +- Replace the current single gas target and single adjustment window, with a new model that employs multiple (higher) gas targets, measured over multiple adjustment windows. +- Increase the default minimum L2 base fee from 0.01 gwei per gas to 0.02 gwei per gas. + +To read more about this change, see the [AIP for raising the gas target & improvements to the pricing algorithm](https://forum.arbitrum.foundation/t/aip-raise-the-gas-target-implement-improvements-to-the-pricing-algorithm/30182). + +#### A constraint-based pricing change: STF instrumentation to track multi-gas + +We've instrumented Arbitrum's State Transition Function (STF) to track gas usage across multiple resource types including computation, storage access, storage growth, and history growth, rather than only a single total based on opcodes. This work lays the foundation for dynamic, constraint-based pricing where gas fees can adjust based on the most constrained resource at the network level. The goal is to create more stable prices, improve responsiveness to spikes, and allow the network to safely increase throughput without overloading node hardware. In this release, none of the constraints are enabled, so there won't be any impact on current gas prices. This update simply adds the ability to measure and record per-resource usage, with actual pricing changes coming in a later version once constraints are configured, benchmarked and tested. + +To read more about this feature, see the [dynamic pricing explainer](https://blog.arbitrum.io/dynamic-pricing-explainer/). + +#### Native token mint and burn + +Native token mint and burn is a feature that allows Arbitrum chains to use interoperability-enabled token standards (e.g., LayerZero OFTs, xERC20s, native USDC) as native gas tokens on their chains. Currently, Arbitrum chains are designed to "lock and mint" native gas tokens on the chain's canonical Bridge. However, doing so means that these "locked and minted" native gas tokens can't interact with third-party cross-chain adapter contracts. This new feature lets an Arbitrum chain delegate minting and burning of its native gas token to a trusted bridge provider (e.g., LayerZero OFT). + +Native token mint and burn is included in ArbOS 51 Dia for the benefit of Arbitrum Orbit chains (reducing the need for forks) and to streamline development and testing into a single codebase. There are no plans to enable this feature on Arbitrum One or Arbitrum Nova, consequently this feature will be explicitly left disabled for Arbitrum One and Arbitrum Nova. + +To read more about this feature, see the [Native Token Mint/Burn enablement guide](https://arbitrum.notion.site/Enable-Native-Mint-Burn-for-your-chain-s-gas-token-22601a3f59f880be9b99d3d55f982a17). + + + +If you want to enable Native Token Mint/Burn capabilities for your chain, you must use [nitro-contracts v3.1.1](https://github.com/OffchainLabs/nitro-contracts/releases/tag/v3.1.1) or higher. + + + +### Fusaka EIPs that aren't proposed to be in ArbOS 51 Dia + +Support and implementation for the following EIPs aren't planned to be part of ArbOS 51 Dia: + +- [EIP-7594](https://eips.ethereum.org/EIPS/eip-7594), [EIP-7918](https://eips.ethereum.org/EIPS/eip-7918), and [EIP-7892](https://eips.ethereum.org/EIPS/eip-7892), since Arbitrum chains don't have blob data markets (though they do support posting blob data to a non-Arbitrum parent chain) +- [EIP-7917](https://eips.ethereum.org/EIPS/eip-7917), since Arbitrum chains don't have a beacon chain and therefore don't have a peer-to-peer layer like Ethereum does +- [EIP-7934](https://eips.ethereum.org/EIPS/eip-7934), this EIP is to help propagating blocks between nodes. Arbitrum doesn't do that - it sends messages (which are limited) and each node builds every block by itself +- [EIP-7907](https://eips.ethereum.org/EIPS/eip-7907), this EIP is no longer Scheduled For Inclusion (SFI) for Fusaka, as agreed upon by Client teams during [ACDE 216](https://ethereum-magicians.org/t/allcoredevs-execution-acde-216-july-17-2025/24770/2) on July 17, 2025. We're currently exploring alternative ways to increase the Smart Contract size limit that don't interfere with the ability for Arbitrum chains to support `EIP-7907` in the future. See this [forum post reply](https://forum.arbitrum.foundation/t/non-constitutional-proposal-to-direct-the-arbitrum-foundation-to-implement-an-extended-version-of-eip-7907-and-for-the-dao-to-ratify-its-deployment-on-arbitrum-one/29375/3) for more details about this. +- [EIP-7935](https://eips.ethereum.org/EIPS/eip-7935), since Arbitrum chains already have a default gas target of 28Mgas/s and we have separate, alternative plans for increasing the gas limit through other means, as mentioned in [Scaling Arbitrum everywhere](https://blog.arbitrum.io/scaling-arbitrum-everywhere/). + +### Special note about ArbOS 51 Dia for chains that haven't yet upgraded to use Arbitrum BoLD + +While ArbOS 51 Dia will be compatible with both `nitro-contracts 3.1.X` and `nitro-contracts 2.1.3`, only chains that have Arbitrum BoLD enabled can use `nitro-contracts 3.x`. This requirement means that if your chain hasn't yet upgraded to use BoLD, only use `nitro-contracts 2.1.3` for your ArbOS 51 Dia upgrade. + +### Reference links for ArbOS 51 Dia - [Guide for how to upgrade ArbOS on your Arbitrum chain](../../launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx) +- [README for how to upgrade your rollup contracts to support ArbOS 51 on your chain](https://github.com/OffchainLabs/orbit-actions?tab=readme-ov-file#nitro-contracts-upgrades) +- [Nitro v3.9.3](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.3) +- [nitro-contracts v3.1.1](https://github.com/OffchainLabs/nitro-contracts/releases/tag/v3.1.1) +- [nitro-contracts v2.1.3](https://github.com/OffchainLabs/nitro-contracts/releases/tag/v2.1.3) (only relevant for Arbitrum chains that don't have BoLD enabled yet) +- [AIP: ArbOS Version 50 Dia Forum Post](https://forum.arbitrum.foundation/t/constitutional-aip-arbos-version-50-dia/) +- [Temperature check vote on Snapshot for ArbOS 50 Dia](https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x33754da4006d0ef38666ec5d5e85fd0966a891a594ab9dc21f23beedea2d330b) +- [AIP: ArbOS Version 51 Raising the gas target & improvements to pricing algorithm Forum Post](https://forum.arbitrum.foundation/t/aip-raise-the-gas-target-implement-improvements-to-the-pricing-algorithm/30182) +- [Temperature check vote on Snapshot for ArbOS 51 Raising the gas target & improvements to pricing algorithm](https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x4a96a91d162975de0d402b83ca8b8a24e808ca357150120fc0d44ae0bf1cc4a5) +- Coming Soon - ArbOS 50 & ArbOS 51 Audit Report, from Trail of Bits diff --git a/sidebars.js b/sidebars.js index 03dacf948..1e6e8588f 100644 --- a/sidebars.js +++ b/sidebars.js @@ -616,12 +616,7 @@ const sidebars = { { type: 'doc', id: 'run-arbitrum-node/arbos-releases/arbos51', - label: 'ArbOS 51', - }, - { - type: 'doc', - id: 'run-arbitrum-node/arbos-releases/arbos50', - label: 'Dia (ArbOS 50)', + label: 'Dia (ArbOS 51)', }, { type: 'doc', From 17f45773e7c9783d3c2e17834f88c51d1e033f0b Mon Sep 17 00:00:00 2001 From: Daniel Lumi <149794418+zk-Lumi@users.noreply.github.com> Date: Wed, 26 Nov 2025 19:35:24 +0000 Subject: [PATCH 6/9] fix: how to guide nitro version --- .../common-configurations/13-arbos-upgrade.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx index f84626a4a..db658d99f 100644 --- a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx +++ b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx @@ -16,7 +16,7 @@ The specific upgrade requirements for each ArbOS release are located under each #### Step 1: Update Nitro on nodes and validators -Refer to the [requirements for the targeted ArbOS release](/run-arbitrum-node/arbos-releases/01-overview.mdx) to identify the specific [Nitro release](https://github.com/OffchainLabs/nitro/releases/) that supports the ArbOS version that you're upgrading to. For example, if your upgrade targets ArbOS 51, you'd use Nitro `v3.9.0` (Docker image: `offchainlabs/nitro-node:v3.9.0-cca645a`) or higher. This is the version of the Nitro stack that needs to be running on each of your Arbitrum chain's nodes. A list of [all Nitro releases can be found on Github](https://github.com/OffchainLabs/nitro/releases). +Refer to the [requirements for the targeted ArbOS release](/run-arbitrum-node/arbos-releases/01-overview.mdx) to identify the specific [Nitro release](https://github.com/OffchainLabs/nitro/releases/) that supports the ArbOS version that you're upgrading to. For example, if your upgrade targets ArbOS 51, you'd use Nitro `v3.9.3` (Docker image: `offchainlabs/nitro-node:v3.9.0-cca645a`) or higher. This is the version of the Nitro stack that needs to be running on each of your Arbitrum chain's nodes. A list of [all Nitro releases can be found on Github](https://github.com/OffchainLabs/nitro/releases). Begin by upgrading your validator node(s) to the specified Nitro version, then update each remaining Arbitrum chain node to match this version. From 7a5667176ac6bb165bd73b469a826f70df3ca6b6 Mon Sep 17 00:00:00 2001 From: Daniel Lumi <149794418+zk-Lumi@users.noreply.github.com> Date: Wed, 26 Nov 2025 20:12:45 +0000 Subject: [PATCH 7/9] fix: update 3.9.0 docker images and wasm root --- .../common-configurations/13-arbos-upgrade.mdx | 4 ++-- docs/notices/arbos51-arbsepolia-upgrade-notice.mdx | 4 ++-- docs/run-arbitrum-node/arbos-releases/arbos51.mdx | 6 +++--- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx index db658d99f..67eaeab92 100644 --- a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx +++ b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx @@ -16,7 +16,7 @@ The specific upgrade requirements for each ArbOS release are located under each #### Step 1: Update Nitro on nodes and validators -Refer to the [requirements for the targeted ArbOS release](/run-arbitrum-node/arbos-releases/01-overview.mdx) to identify the specific [Nitro release](https://github.com/OffchainLabs/nitro/releases/) that supports the ArbOS version that you're upgrading to. For example, if your upgrade targets ArbOS 51, you'd use Nitro `v3.9.3` (Docker image: `offchainlabs/nitro-node:v3.9.0-cca645a`) or higher. This is the version of the Nitro stack that needs to be running on each of your Arbitrum chain's nodes. A list of [all Nitro releases can be found on Github](https://github.com/OffchainLabs/nitro/releases). +Refer to the [requirements for the targeted ArbOS release](/run-arbitrum-node/arbos-releases/01-overview.mdx) to identify the specific [Nitro release](https://github.com/OffchainLabs/nitro/releases/) that supports the ArbOS version that you're upgrading to. For example, if your upgrade targets ArbOS 51, you'd use Nitro `v3.9.3` (Docker image: `offchainlabs/nitro-node:v3.9.3-8bc5554`) or higher. This is the version of the Nitro stack that needs to be running on each of your Arbitrum chain's nodes. A list of [all Nitro releases can be found on Github](https://github.com/OffchainLabs/nitro/releases). Begin by upgrading your validator node(s) to the specified Nitro version, then update each remaining Arbitrum chain node to match this version. @@ -35,7 +35,7 @@ To update the WASM module root and deploy your chain's Nitro contracts to the pa Once you have the WASM module root and have identified the required `nitro-contracts` version for the target ArbOS release, if any, [please follow the instructions in this guide](https://github.com/OffchainLabs/orbit-actions?tab=readme-ov-file#nitro-contracts-upgrades) for specific actions based on the `nitro-contracts` version you are deploying. Note that each ArbOS release will require performing this step with a different WASM module root and may require a different version of `nitro-contracts`. The guide linked above will be kept updated with the instructions for each specific ArbOS release. -The `WASM module root` is a 32-byte hash created from the Merkelized Go replay binary and its dependencies. When ArbOS is upgraded, a new WASM module root is generated due to modifications in the State Transition Function (STF). This new WASM module root must be set in the rollup contract on the parent chain. For example, the WASM module root for ArbOS 51 Dia is `0x2c54f6e9e378ba320ed9c713a1d9f067a572b1437e4f1c40b1a915d3066c04f2`. +The `WASM module root` is a 32-byte hash created from the Merkelized Go replay binary and its dependencies. When ArbOS is upgraded, a new WASM module root is generated due to modifications in the State Transition Function (STF). This new WASM module root must be set in the rollup contract on the parent chain. For example, the WASM module root for ArbOS 51 Dia is `0x8a7513bf7bb3e3db04b0d982d0e973bcf57bf8b88aef7c6d03dba3a81a56a499`. To set the WASM module root manually (i.e., not using the above guide), use the `Rollup proxy` contract's [`setWasmModuleRoot`](https://github.com/OffchainLabs/nitro-contracts/blob/38a70a5e14f8b52478eb5db08e7551a82ced14fe/src/rollup/RollupAdminLogic.sol#L321) method. Note that the `upgrade executor` contract on the parent chain is the designated owner of the Rollup contract, so the **chain owner account** needs to initiate a call to the `upgrade executor` contract in order to perform the upgrade. This call should include the correct calldata for setting the new WASM module root. diff --git a/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx b/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx index f16f88552..912654ba3 100644 --- a/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx +++ b/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx @@ -11,8 +11,8 @@ On Monday, December 1, 2025 at 17:00 UTC, ArbOS 51 will activate on the Arbitrum Arbitrum Sepolia node operators **must upgrade** to Nitro **`v3.9.3`** ahead of this activation to continue syncing the chain. -- **Docker image:** `offchainlabs/nitro-node:v3.9.0-cca645a` -- **Release notes:** https://github.com/OffchainLabs/nitro/releases/tag/consensus-v51 +- **Docker image:** `offchainlabs/nitro-node:v3.9.3-8bc5554` +- **Release notes:** https://github.com/OffchainLabs/nitro/releases/tag/v3.9.3 ::: diff --git a/docs/run-arbitrum-node/arbos-releases/arbos51.mdx b/docs/run-arbitrum-node/arbos-releases/arbos51.mdx index 373856698..7d17633b0 100644 --- a/docs/run-arbitrum-node/arbos-releases/arbos51.mdx +++ b/docs/run-arbitrum-node/arbos-releases/arbos51.mdx @@ -24,19 +24,19 @@ This page is intended for all Arbitrum node operators and Arbitrum chain owners Before Ethereum Parent chain Sepolia and Mainnet upgrade to Fusaka: ensure that your Nitro node version is upgraded and consensus layer client is configured as per the [Fusaka upgrade notice](../../notices/fusaka-upgrade-notice.mdx). -The minimum Nitro version that supports ArbOS 51 "Dia" is [Nitro v3.9.3](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.3), which is available on Docker Hub with the image tag `Noffchainlabs/nitro-node:v3.9.0-cca645a`. This release of Nitro is a mandatory upgrade for Arbitrum One and Nova node operators if adopted. For Arbitrum One and Nova, the ArbOS 51 "Dia" upgrade will require a governance vote to activate. +The minimum Nitro version that supports ArbOS 51 "Dia" is [Nitro v3.9.3](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.3), which is available on Docker Hub with the image tag `Noffchainlabs/nitro-node:v3.9.3-8bc5554`. This release of Nitro is a mandatory upgrade for Arbitrum One and Nova node operators if adopted. For Arbitrum One and Nova, the ArbOS 51 "Dia" upgrade will require a governance vote to activate. As a refresher, ArbOS upgrades get treated as Arbitrum's equivalent of a hard fork. To learn more, refer to the [Arbitrum ArbOS upgrades forum post](https://forum.arbitrum.foundation/t/arbitrum-arbos-upgrades/19695). Note that ArbOS 51 Dia is an upgrade that builds upon [ArbOS 40 Callisto](./arbos40.mdx). ### Requirements - Having read and understood the [ArbOS Software Releases Overview page](./01-overview.mdx). -- Running [Nitro v3.9.3](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.3) or higher, which is available on Docker Hub with the image tag `offchainlabs/nitro-node:v3.9.0-cca645a`. +- Running [Nitro v3.9.3](https://github.com/OffchainLabs/nitro/releases/tag/v3.9.3) or higher, which is available on Docker Hub with the image tag `offchainlabs/nitro-node:v3.9.3-8bc5554`. - Note that it's important to run Nitro v3.9.3 only against trusted databases. If you want to use an untrusted database, you can first remove the `wasm` directory if it exists (potentially inside the `nitro` folder). Otherwise, the database may have malicious, unvalidated code that can result in remote code execution. Avoiding unvalidated code is also mitigated by ensuring you run the Arbitrum Nitro node inside Docker. - Running [nitro-contracts v3.1.0](https://github.com/OffchainLabs/nitro-contracts/releases/tag/v3.1.0) or higher - If your chain isn't ready to activate BoLD, use [nitro-contracts v2.1.3](https://github.com/OffchainLabs/nitro-contracts/releases/tag/v2.1.3) instead; v3.0.0 or higher can't be used without activating BoLD. - If you want to enable [Native Token Mint/Burn capabilities](#native-token-mint-and-burn) for your chain, you must use [nitro-contracts v3.1.1](https://github.com/OffchainLabs/nitro-contracts/releases/tag/v3.1.1) or higher. -- WASM module root: `0x2c54f6e9e378ba320ed9c713a1d9f067a572b1437e4f1c40b1a915d3066c04f2` +- WASM module root: `0x8a7513bf7bb3e3db04b0d982d0e973bcf57bf8b88aef7c6d03dba3a81a56a499` - If the Arbitrum chain posts blobs to a Fusaka-enabled parent chain, ensure that the consensus layer client is configured correctly as per the [Fusaka upgrade notice](../../notices/fusaka-upgrade-notice.mdx). ### High-level description of ArbOS 51 changes From 767407d987e8dfed9b0c4fda1c4415a56842ba1d Mon Sep 17 00:00:00 2001 From: Daniel Lumi <149794418+zk-Lumi@users.noreply.github.com> Date: Wed, 26 Nov 2025 20:44:15 +0000 Subject: [PATCH 8/9] update: arbos50 notice text --- docs/notices/arbos51-arbsepolia-upgrade-notice.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx b/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx index 912654ba3..bd51d461e 100644 --- a/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx +++ b/docs/notices/arbos51-arbsepolia-upgrade-notice.mdx @@ -18,6 +18,6 @@ Arbitrum Sepolia node operators **must upgrade** to Nitro **`v3.9.3`** ahead of ### **Context** -ArbOS 51 is a follow-up to ArbOS 50 and includes the activation for multidimensional-pricing instrumentation. ArbOS 50 was previously activated on Sepolia, but the Gas Target & Pricing Framework changes remained disabled pending a fix. ArbOS 51 now completes that work. +ArbOS 51 is a follow-up to ArbOS 50 that fixes issues with the Pricing Framework. ArbOS 50 was previously activated on Sepolia, but the Gas Target & Pricing Framework changes remained disabled pending this fix. ArbOS 51 now completes that work. Upstream governance items (ArbOS 50 + Gas Target & Pricing Framework) are being bundled into a single on-chain vote. Both components have passed Snapshot temperature checks, with the Tally vote expected to open on or around **December 4, 2025**. From 4a65d405f54a40814a7402ec9939fa0f43279f01 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ga=C3=ABl=20Blanchemain?= Date: Wed, 26 Nov 2025 12:48:58 -0800 Subject: [PATCH 9/9] config: add redirect from arbos50 to arbos51 --- vercel.json | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/vercel.json b/vercel.json index ad693a20f..e3e9f72b5 100644 --- a/vercel.json +++ b/vercel.json @@ -426,6 +426,11 @@ "destination": "/how-arbitrum-works/inside-arbitrum-nitro", "permanent": false }, + { + "source": "/(docs/run-arbitrum-node/arbos-releases/arbos50/?)", + "destination": "/(docs/run-arbitrum-node/arbos-releases/arbos51/?)", + "permanent": false + }, { "source": "/(docs/run-arbitrum-node/sequencer/run-feed-relay/?)", "destination": "/(docs/run-arbitrum-node/run-feed-relay/?)",