AIP: ArbOS 20 “Atlas” - Arbitrum Support for Dencun + Batch Poster Improvements

Constitutional

Abstract

This AIP proposes a number of improvements to Arbitrum chains, including the capability to leverage EIP 4844 to post batches of L2 transactions as Blobs on L1 Ethereum at a cheaper price. The proposal also includes support for most of the changes included in Ethereum's Dencun upgrade and 2 improvements to batch posting for Arbitrum One and Nova. The proposed ArbOS 20 “Atlas” upgrade will be ready for adoption by any Arbitrum Chain; this proposal concerns the Arbitrum One and Nova chains, as they are governed by the Arbitrum DAO. On a high level, an ArbOS upgrade can be seen as Arbitrum’s equivalent of a hard fork - more can be read about the subject over in Arbitrum ArbOs upgrades.

This AIP combines following two temperature checks: AIP: ArbOS Version 20 “Atlas” and AIP: Batch Poster Manager and Sequencer Inbox Finality Fix - both of which have passed.

Please note that ArbOS Version 20 “Atlas” is an upgrade that builds upon ArbOS version 11 which has been adopted by the ArbitrumDAO - this proposal increments the version number to 20 instead of 12 due to technical details that allow for better Orbit chain customizability.

Changes Included

1. Posting batches of transactions as blobs to L1 Ethereum (EIP-4844)

With ArbOS 20 “Atlas”, any Arbitrum chain that settles on L1 Ethereum will be able to post transactions as either calldata or “blob-data” - the latter of which is to be introduced in EIP-4844 as part of Ethereum’s Dencun upgrade.

Some notes on how this is implemented for Arbitrum:

• 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 Nova. ArbOS 20 “Atlas” does not add support for Arbitrum chains to receive data in a blob storage format. This means that any L3 Orbit chain settling to an L2 Arbitrum chain will post data to the underlying L2 Arbitrum chain as calldata. 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 yet. 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 generally reduce the cost of using Arbitrum L2s.

This AIP includes a number of upgrades that enable Arbitrum chains to utilize EIP-4844:

• Updated Sequencer Inbox contract with new methods allowing the Sequencer to post Arbitrum transactions in blob data.
• Updates to the OneStepProof (OSP) contract to support the new Nitro fraud prover (mentioned above), along with a small patch to the ChallengeManager contract to allow changing the OSP.
• Update to the Nitro fraud prover to support proving additional hashes, i.e., KZG and SHA256 preimages.
• Update to the core Nitro node software to handle parsing chain data from 4844 blobs.

Nitro core changes:

Current full code diff can be viewed via this link: https://github.com/OffchainLabs/nitro/compare/consensus-v11...finalize-arbos-20. Alternatively, the code diffs are attached below:

nitro.diff

fraud-prover.diff

PRs:

• https://github.com/OffchainLabs/nitro/pull/1814
• https://github.com/OffchainLabs/nitro/pull/2064
• https://github.com/OffchainLabs/nitro/pull/2092
• https://github.com/OffchainLabs/go-ethereum/pull/285
• https://github.com/OffchainLabs/nitro/pull/2108
• https://github.com/OffchainLabs/nitro/pull/1767
• https://github.com/OffchainLabs/nitro/pull/1865
• https://github.com/OffchainLabs/nitro/pull/2109
• https://github.com/OffchainLabs/nitro/pull/2112
• https://github.com/OffchainLabs/nitro/pull/2115
• https://github.com/OffchainLabs/nitro/pull/2111

Nitro smart contract changes:

Current Full Diff: https://github.com/OffchainLabs/nitro-contracts/compare/main...arbos-20-diff

PRs:

• https://github.com/OffchainLabs/nitro-contracts/pull/104
• https://github.com/OffchainLabs/nitro-contracts/pull/114
• https://github.com/OffchainLabs/nitro-contracts/pull/116
• https://github.com/OffchainLabs/nitro-contracts/pull/118
• https://github.com/OffchainLabs/nitro-contracts/pull/111
• https://github.com/OffchainLabs/nitro-contracts/pull/119
• https://github.com/OffchainLabs/nitro-contracts/pull/90

2. Enable partial support for Dencun Execution Layer

Ethereum’s Dencun upgrade is technically a combination of two upgrades: one to the Execution Layer and another to the Consensus Layer, named Cancun and Deneb, respectively. While the Consensus Layer upgrades are not applicable to Nitro (since Nitro is Arbitrum One and Arbitrum Nova’s execution engine), some of the Execution Layer changes are, including EIP-1153 as described above. The full Cancun network upgrade specification for Ethereum can be found here.

Nitro’s upgrade to ArbOS 20 adds support for three specific EIPs from Cancun, those being:

• Support the new transient storage EVM opcodes introduced in EIP-1153: TSTORE and TLOAD, offering a cheaper option than storage for data that’s discarded at the end of a transaction.
• Support the new MCOPY EVM opcode introduced in EIP-5656 for cheaper memory copying.
• Support the changes in functionality of theSELFDESTRUCT EVM opcode, as outlined in EIP-6780.

Since Nitro uses Geth at the Core, the above 3 EIPs were implemented by merging in a Cancun-supported version of Geth upstream. More specifically, Geth version 1.13.1 was merged into Nitro’s go-ethereum fork here:

https://github.com/OffchainLabs/go-ethereum/pull/284

With the above merged, the below PR is used to enable the Cancun fork in ArbOS 20.

https://github.com/OffchainLabs/go-ethereum/pull/285

3. Batch Poster Manager and Sequencer Inbox Finality Fix

Motivation

Batch Poster Manager:

Currently, both Arbitrum One and Arbitrum Nova, each have a single address that is granted the batch-poster role (this is currently the same as the Sequencer). The Sequencer posts batches frequently, and thus the batch-poster address must be controlled by a hot wallet. This means that if the batch poster’s keys were compromised, Sequencing could be unstable until the DAO took action.

This AIP proposes a system in which a “batch poster manager” role is granted to the operator of the Sequencer which has the ability to grant and revoke batch-posting affordances. This way, the batch poster manager could perform key rotations for the batch posters— routinely, and/or if a batch poster address is ever compromised — quickly and without the DAO needing to take coordinated action. Note that this proposal does not change the sequencer, but more so allow for easier key rotations on the batch poster.

Crucially, this would not represent a change on the current system’s trust model:

• In both the current and the new proposed system, the Sequencer is entrusted with managing the batch posting affordance; in the current system, for example, the entity behind Sequencer could technically grant batch posting to an additional entity by simply sharing it’s keys.
• In the new system, the DAO would still have the same ability to revoke the Sequencer role; i.e., the DAO could

... please visit link below to view full proposal

https://tally.xyz/gov/arbitrum/proposal/46905320292877192134536823079608810426433248493109520384601548724615383601450