Skip to main content

ArbOS 20 Atlas

ArbOS 20 Atlas is shipped via Nitro v2.3.1, which is available on Docker hub with the image tag: offchainlabs/nitro-node:v2.3.1-26fad6f. This release of Nitro is a mandatory upgrade for Arbitrum One and Nova validators. For Arbitrum One and Nova, the ArbOS 20 upgrade requires a governance vote to activate.

Requirements:​

High-level description of ArbOS 20 changes​

ArbOS 20 is an upgrade to enable Arbitrum's support for L1 Ethereum's Dencun upgrade scheduled for March 2024. As a result, all of the ArbOS specific changes revolve around implementing the majority of the Cancun EIPs on Arbitrum:

  • Enable Arbitrum chains to batch and post transaction data in the form of Blobs to L1 Ethereum, to support EIP-4844. This includes updates to the Sequencer Inbox contract to support posting transactions in the form of blobs, updating Nitro's fraud prover to support proving additional hashes (KZG and SHA256 preimages), and updates to the core Nitro node software to handle parsing data from EIP-4844 blobs.
  • Addition of the TSTORE and TLOAD EVM opcodes introduced in EIP-1153 offering a cheaper option than storage for data that’s discarded at the end of a transaction.
  • Addition of the MCOPY EVM opcode introduced in EIP-5656 for cheaper memory copying.
  • Changes to the SELFDESTRUCT EVM opcode to reflect the behavior on L1 Ethereum, as outlined in EIP-6780.
  • Addition of a batch poster manager role that will have the ability to grant and revoke batch-posting affordances. This role is assigned to the operator of the sequencer to allow the batch poster manager perform key rotations for the batch posters. The DAO will continue to have the ability to revoke the seqauencer role, meaning there is no change to the current system's trust model since the DAO ca update the batch poster manager at any time (along with any batch posters).
  • Increasing the max block height that a batch can be posted, relative to the current block, to 64 bringing this in line with Ethereum's finality guarantees. The current value of 12 was set prior to the Ethereum merge and could mean that a small L1 reorg can cause an otherwise valid batch to revert.
  • Fix Sequencer Inbox bug: when posting a batch, the Sequencer provides the "newMessageCount” value as a parameter; if the Sequencer is malicious, it can provide the max uint256 value which in turn would make subsequent calls to forceInclusion revert with an overflow error. Atlas’s upgrade to the Sequencer inbox includes a change) in which forceInclusion does not modify the message count, fixing this bug. This bug had been disclosed to Arbitrum RaaS providers and to the Arbitrum DAO Security Council.

Special notes on ArbOS 20: Atlas support for EIP-4844​

  • Upgrading to the Atlas ArbOS release will require access to L1 Ethereum beacon chain endpoints to retrieve blob data. For nodes of a chain that come online 18 days after Atlas gets activated on their chain will need access to historical data to sync up to the latest state. If you are not operating your own Ethereum consensus client, please visit this page to view a list of beacon chain RPC providers where you can access blob data.
  • Applications on Arbitrum will not have to be modified or take any explicit action to get the benefits of using EIP-4844 (i.e. the whole chain opts-in with ArbOS 20 “Atlas”).
  • ArbOS 20 “Atlas” adds support for Arbitrum chains to send data in a blob storage format to data availability layers, like L1 Ethereum, that support the blob transaction type. This includes Arbitrum One and Arbitrum Nova. ArbOS 20 “Atlas” does not add support for Arbitrum chains to receive data in a blob storage format. This means that an L3 Orbit chain on top of an Arbitrum L2 will use calldata when posting L3 transaction data to the underlying L2. The L2 Arbitrum chain will then be able to post data to a L1 data availability layer like Ethereum using blobs.
  • There currently aren’t estimates on what the end-user gas savings of using blob data will be. This topic is something being actively worked on and monitored. Without Mainnet data, the estimates for blob gas prices will not be accurate enough to reliably predict the cost reductions that users will experience - and even with Mainnet data, the savings will vary by use case (i.e. no current way to predict the price impacts from all blob gas market participants yet). In general, however, the use of blobs will reduce the cost of using Arbitrum L2s. To learn more about what EIP-4844 will mean for L2 users, please checkout this blog post on Medium by Offchain Lab's Co-foudner and Chief Scientist Ed Felten.

Block explorers​

Below is a non-comprehensive list of explorers that support querying and viewing blob data on Ethereum that get posted by Arbitrum L2 chains.

Additional requirement for Arbitrum Orbit L2 chain operators: enabling blob batch posting​

This section maps to Step 4 in the guide on How to upgrade ArbOS on your Arbitrum Orbit L2 chain and contains additional instructions for Arbitrum Orbit L2 chain operators for ArbOS 20 Atlas. Specifically, the details below are meant to help Arbitrum Orbit L2 chain operators enable blob batch posting to L1 Ethereum following their successful upgrade to the ArbOS 20 Atlas release.

caution

Before proceeding, make sure you have successfully completed Steps 1 through 3 of the guide on How to upgrade ArbOS on your Orbit chain.

To enable the posting of transaction data in Blobs to L1 Ethereum, you must set node.batch-poster.post-4844-blobs=true on the batch poster.

Full list of ArbOS Atlas specific configuration options for Orbit chains​

FlagDescription
--node.batch-poster.post-4844-blobsBoolean. Default: false. Used to enable or disable the posting of transaction data using Blobs to L1 Ethereum. If using calldata is more expensive and if the parent chain supports EIP4844 blobs, the batch poster will use blobs when this flag is set to true. Can be true or false.
--node.batch-poster.ignore-blob-priceBoolean. Default: false. If the parent chain supports EIP4844 blobs and ignore-blob-price is set to true, the batch poster will use EIP4844 blobs even if using calldata is cheaper. Can be true or false.

The above configurations are also available in the Orbit command line options reference section and can be set using the command line or using the JSON node configuration below:

 "node": {
    ...
    "batch-poster": {
    ...
      "post-4844-blobs": true,
      "ignore-blob-price": false,
    ...
    },
  }