ArbOS 11
ArbOS 11 is shipped via Nitro v2.2.0, which is available on Docker hub with the image tag: offchainlabs/nitro-node:v2.2.0-f7dc9de
. This release of Nitro is a mandatory upgrade for Arbitrum One and Nova validators. For Arbitrum One and Nova, the ArbOS 11 upgrade requires a governance vote to activate.
Formal release notes can be found here.
Requirements:
- Nitro v2.2.0 or higher
- nitro-contracts v1.1.0 or higher
- Wasm module root:
0x6b94a7fc388fd8ef3def759297828dc311761e88d8179c7ee8d3887dc554f3c3
High-level description of ArbOS 11 changes
- Addition of all EVM changes made on L1 Ethereum as part of the Shanghai upgrade. This includes:
- Improvements and fixes for retryable tickets to ensure that the fee calculation to redeem retryable tickets will take into account both the infrastructure fee and the network fee. The infrastructure fee is the minimum L2 base fee only, while the network fee collects L2 congestion charges. This is important for AnyTrust chains like Arbitrum Nova because members of the Data Availability Committee (DAC) gets paid a percentage of the infrastructure fee but not the network fee. Previously, the calculations to determine the fee for redeeming retryable tickets did not consider the infrastructure fee.
- Fixes an issue where the
ArbOwnerPublic
precompile returned the incorrect list of chain owners. This does not change the parties who are able to perform chain owner actions. As intended, only the Arbitrum DAO is able to take chain owner actions for Arbitrum One and Nova. - Resolves an issue where the
arbBlockHash
method would take up all the gas when reverting. The previous incorrect behavior meant that if a transaction callsarbBlockHash
with an out-of-range block number, then the transaction would consume all the gas when reverting. - Addition of the
L1RewardReceipient
andL1RewardRate
precompile methods to view L1 pricing parameters and make it easier to view the current chain configuration. - Fix the
ArbOwner
precompile to disallow emitting logs inSTATICCALL
contexts, bringing this in line with how the EVM is expected to behave asSTATICCALL
invocations should never be able to emit logs. The previous incorrect behavior would mean that a log was emitted when a chain owner made aSTATICCALL
on theArbOwner
precompile.