Arbitrum Nitro Consensus v50 Release Candidate 4

This release signifies a WASM fraud proof consensus version, and is not a good version to run a node on

WAVM Module Root: 0x393be710f252e8217d66fe179739eba1ed471f0d5a847b5905c30926d853241a

This is a release candidate of a consensus release for ArbOS 50, including support for Fusaka.

Full Changelog: consensus-v40...consensus-v50-rc.4

Arbitrum Nitro v3.7.2

This release has bug fixes and improvements, but it is not a required upgrade.

This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:v3.7.2-42be4fe
This Docker image specifies default flags in its entrypoint which should be replicated if you're overriding the entrypoint: /usr/local/bin/nitro --validation.wasm.allowed-wasm-module-roots /home/user/nitro-legacy/machines,/home/user/target/machines

If you're running a validator without a split validation server (this will be true of most validators), you should instead use the image offchainlabs/nitro-node:v3.7.2-42be4fe-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.

Special Note 1

Nitro 3.7.0 pulls in go-ethereum 1.15.6 which changed log index from bloombits to filtermap. This means that on startup there will be elevated CPU usage for 50+ hours while new FilterMaps are generated for log indexing. If log queries are not used, the parameter --execution.tx-indexer.enable=false can be used to completely disable log indexing.

Special Note 2

Nitro 3.7.0 pulls in go-ethereum 1.15.11 which includes a brand new log indexing system called filtermaps that has resulted in an increase in log indexing latency due to Nitro’s current reliance on HashDB (instead of PathDB). In some cases, this can delay log queries from being served anywhere between 5 seconds to 2 minutes on Arbitrum One during long tail unindexing. We’ve observed that this happens roughly once per day based on Arbitrum One mainnet traffic levels. Teams who need to serve log queries with consistent latency (e.g. eth_getLogs, eth_getFilterLogs, eth_getFilterChanges) can use the configuration parameter --execution.rpc.log-history=0 to keep all log history, which will only slightly increase database growth. Teams running their own log indexer may be unaffected. At some point, a future release Nitro is expected to fix the issue of log index pruning being able to block log queries.

What's Changed

Added support to verify custom chain genesis, and add consensus v41 to Docker image.

User-facing improvements

• backport adding consensus v41 to Dockerfile: #3556
• Backport test Genesis assertion on nitro init to 3.7.x: in #3596

Full Changelog: v3.7.1...v3.7.2-rc.1

Arbitrum Nitro v3.7.2-rc.1

This release has bug fixes and improvements, but it is not a required upgrade.

This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:TBD
This Docker image specifies default flags in its entrypoint which should be replicated if you're overriding the entrypoint: /usr/local/bin/nitro --validation.wasm.allowed-wasm-module-roots /home/user/nitro-legacy/machines,/home/user/target/machines

If you're running a validator without a split validation server (this will be true of most validators), you should instead use the image offchainlabs/nitro-node:TBD-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.

Special Note 1

Nitro 3.7.0 pulls in go-ethereum 1.15.6 which changed log index from bloombits to filtermap. This means that on startup there will be elevated CPU usage for 50+ hours while new FilterMaps are generated for log indexing. If log queries are not used, the parameter --execution.tx-indexer.enable=false can be used to completely disable log indexing.

Special Note 2

Nitro 3.7.0 pulls in go-ethereum 1.15.11 which includes a brand new log indexing system called filtermaps that has resulted in an increase in log indexing latency due to Nitro’s current reliance on HashDB (instead of PathDB). In some cases, this can delay log queries from being served anywhere between 5 seconds to 2 minutes on Arbitrum One during long tail unindexing. We’ve observed that this happens roughly once per day based on Arbitrum One mainnet traffic levels. Teams who need to serve log queries with consistent latency (e.g. eth_getLogs, eth_getFilterLogs, eth_getFilterChanges) can use the configuration parameter --execution.rpc.log-history=0 to keep all log history, which will only slightly increase database growth. Teams running their own log indexer may be unaffected. At some point, a future release Nitro is expected to fix the issue of log index pruning being able to block log queries.

What's Changed

Added support to verify custom chain genesis, and add consensus v41 to Docker image.

User-facing improvements

• backport adding consensus v41 to Dockerfile: #3556
• Backport test Genesis assertion on nitro init to 3.7.x: in #3596

Full Changelog: v3.7.1...v3.7.2-rc.1

Arbitrum Nitro v3.8.0-rc.2

Note

v3.8.0-rc.2 should not be used

Special Note 1

Nitro 3.7.0 pulled in go-ethereum 1.15.6 which changed log index from bloombits to filtermap. This means that database previously running pre-Nitro 3.7.0 on startup there will be elevated CPU usage for 50+ hours while new FilterMaps are generated for log indexing. If log queries are not used, the parameter --execution.tx-indexer.enable=false can be used to completely disable log indexing.

Special Note 2

Nitro 3.7.0 pulled in go-ethereum 1.15.11 which includes a brand new log indexing system called filtermaps that has resulted in an increase in log indexing latency due to Nitro’s current reliance on HashDB (instead of PathDB). In some cases, this can delay log queries from being served anywhere between 5 seconds to 2 minutes on Arbitrum One during long tail unindexing. We’ve observed that this happens roughly once per day based on Arbitrum One mainnet traffic levels. Teams who need to serve log queries with consistent latency (e.g. eth_getLogs, eth_getFilterLogs, eth_getFilterChanges) can use the configuration parameter --execution.rpc.log-history=0 to keep all log history, which will only slightly increase database growth. Teams running their own log indexer may be unaffected. At some point, a future release of Nitro is expected to fix the issue of log index pruning being able to block log queries.

User facing changes

• Important! If you have previously used the ArbOwner.setMaxTxGasLimit to set the max transaction and block gas limits for your chain, you should add calls to ArbOwner.setMaxTxGasLimit and ArbOwner.SetMaxBlockGasLimit to your upgrade action to arbos 50. (When it's time.)
• After the arbos 50 upgrade, there is a new ArbOwner.setL1CalldataPrice which can be used to set the parent chain's blob base fee per byte of caldata. This is for allowing the state transition function to adjust for the parent chain having enabled EIP-7623: Increase calldata cost

Highlights

• Nitro is ready for Fusaka
• Arbitrum One node operators need to upgrade to v3.8.0 before mainnet upgrades to Fusaka
• Arbitrum One and Arbitrum Nova will both upgrade to ArbOS 50 as described in the AIP

What's Changed

• Store single-gas in multi-gas collector in #3552
• fix: correct error aggregation for multi-target compile results in #3532
• fix: prevent HTTP response body leaks in restful DAS client in #3558
• Custom GH action for unified installing Rust in #3559
• Instrument multi-gas in StylusPrograms (just for getBytes32) in #3539
• fix: correct rightshift linter documentation in #3562
• Update gammazero dependency in #3565
• Update go version to 1.24.x across github workflows in #3567
• Merge v1.16.3 in #3568
• Multigas: support geth multigas api changes in #3569
• chore(ci): update GitHub Actions to latest versions in #3573
• Update EIP-7910 implementation in #3571
• Add suppoort for Consensus V50 (rc.3) to Docker in #3574

Full Changelog: v3.8.0-rc.1...v3.8.0-rc.2

Arbitrum Nitro Consensus v50 Release Candidate 3

This release signifies a WASM fraud proof consensus version, and is not a good version to run a node on

WAVM Module Root: 0x385fa2524d86d4ebc340988224f8686b3f485c7c9f7bc1015a64c85a9c76a6b0

This is a release candidate of a consensus release for ArbOS 50, including support for Fusaka.

Full Changelog: consensus-v40...consensus-v50-rc.3

Arbitrum Nitro v3.8.0-rc.1

Note

v3.8.0-rc.2 should not be used

User facing changes

• Important! If you have previously used the ArbOwner.setMaxTxGasLimit to set the max transaction and block gas limits for your chain, you should add calls to ArbOwner.setMaxTxGasLimit and ArbOwner.SetMaxBlockGasLimit to your upgrade action to arbos 50. (When it's time.)
• After the arbos 50 upgrade, there is a new ArbOwner.setL1CalldataPrice which can be used to set the parent chain's blob base fee per byte of caldata. This is for allowing the state transition function to adjust for the parent chain having enabled EIP-7623: Increase calldata cost

Highlights

• Nitro is ready for Fusaka
• Arbitrum One node operators need to upgrade to v3.8.0 before mainnet upgrades to Fusaka
• Arbitrum One and Arbitrum Nova will both upgrade to ArbOS 50 as described in the AIP

What's Changed

• Fix error handling and add comprehensive tests in #3510
• Add 10 minutes to bold tests in #3514
• Optimize sender address derivation in #3518
• Don't log error if unable to return expired nonce cache failure in0 in #3486
• Add multi-dimensional gas collector in #3453
• Refactor move multigascollector to arbos in #3524
• Add debug flag to enable deep copy of backlog msgs in #3519
• Update geth post merge of v1.16.0 in #3523
• Update geth post merge of v1.16.1 in #3528
• Use the parent chain for BlobFeePerByte instead of an RPC call in #3531
• Fix acquiring redis lock in batch poster in #3511
• Account multi-gas in StartTxHook in #3533
• Add GetNativeTokenManagementFrom precompile to ArbOwnerPublic in #3534
• Allow same prevTimestamp in eth_simulateV1 in #3535
• Return False When Checking if Deposit Tx Type Has Poster Costs in #3536
• Update geth post merge of v1.16.2 in #3537
• Improve CPU performance when processing blocks in #3541
• Fix eip 2537 in nitro enable it as part of arbos 50 dia in #3492
• Fix that arbos didnt get updated for l1 calldata price in #3470
• Support passing multi gas by value in #3543
• Skip block size cap for arbitrum chains in #3544
• Record only specific targets needed for stylus in #3416
• Remove rust nightly dependency in #3546
• Implement EIP-7825 in #3545
• Enable arbos 50 in #3547
• Treat precompile code as empty during delegation after arbos 50 in #3549
• Enable ArbOS 50 in system tests in #3550
• Prover: remove unnecessary wasm exports in #3554
• Move the MaxTxGas limit enforcement in #3557
• Add support for consensus v50 to Docker in #3551

Full Changelog: v3.7.1...v3.8.0-rc.1

Arbitrum Nitro Consensus v50 Release Candidate 2

This release signifies a WASM fraud proof consensus version, and is not a good version to run a node on

WAVM Module Root: 0xc1ea4d6d2791bf5bdf6de3c2166ce4aab8fe16ca4ad5c226e8ae31a8b77f1a08

This is a release candidate of a consensus release for ArbOS 50, including support for Fusaka.

Full Changelog: consensus-v40...consensus-v50-rc.2

Arbitrum Nitro Consensus v50 Release Candidate 1

This release signifies a WASM fraud proof consensus version, and is not a good version to run a node on

WAVM Module Root: 0x8fd725477d8ef58183a1a943c375a8495a22cd2d7d701ac917fe20d69993e88e

This is a release candidate of a consensus release for ArbOS 50, including support for Fusaka.

Full Changelog: consensus-v40...consensus-v50-rc.1

Arbitrum Nitro v3.7.1

This release has several bug fixes and improvements, but it is not a required upgrade.

This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:v3.7.1-926f1ab
This Docker image specifies default flags in its entrypoint which should be replicated if you're overriding the entrypoint: /usr/local/bin/nitro --validation.wasm.allowed-wasm-module-roots /home/user/nitro-legacy/machines,/home/user/target/machines

If you're running a validator without a split validation server (this will be true of most validators), you should instead use the image offchainlabs/nitro-node:v3.7.1-926f1ab-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.

Special Note 1

Nitro 3.7.0 pulls in go-ethereum 1.15.6 which changed log index from bloombits to filtermap. This means that on startup there will be elevated CPU usage for 50+ hours while new FilterMaps are generated for log indexing. If log queries are not used, the parameter --execution.tx-indexer.enable=false can be used to completely disable log indexing.

Special Note 2

Nitro 3.7.0 pulls in go-ethereum 1.15.11 which includes a brand new log indexing system called filtermaps that has resulted in an increase in log indexing latency due to Nitro’s current reliance on HashDB (instead of PathDB). In some cases, this can delay log queries from being served anywhere between 5 seconds to 2 minutes on Arbitrum One during long tail unindexing. We’ve observed that this happens roughly once per day based on Arbitrum One mainnet traffic levels. Teams who need to serve log queries with consistent latency (e.g. eth_getLogs, eth_getFilterLogs, eth_getFilterChanges) can use the configuration parameter --execution.rpc.log-history=0 to keep all log history, which will only slightly increase database growth. Teams running their own log indexer may be unaffected. At some point, a future release Nitro is expected to fix the issue of log index pruning being able to block log queries.

What's Changed

Fixed performance regression in v3.7.0

User-facing improvements

• Improve CPU performance when processing blocks: #3542

Full Changelog: v3.7.0...v3.7.1

Arbitrum Nitro v3.7.1-rc.1

This release has several bug fixes and improvements, but it is not a required upgrade.

This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:v3.7.1-rc.1-926f1ab
This Docker image specifies default flags in its entrypoint which should be replicated if you're overriding the entrypoint: /usr/local/bin/nitro --validation.wasm.allowed-wasm-module-roots /home/user/nitro-legacy/machines,/home/user/target/machines

If you're running a validator without a split validation server (this will be true of most validators), you should instead use the image offchainlabs/nitro-node:v3.7.1-rc.1-926f1ab-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.

Special Note 1

Nitro 3.7.0 pulls in go-ethereum 1.15.6 which changed log index from bloombits to filtermap. This means that on startup there will be elevated CPU usage for 50+ hours while new FilterMaps are generated for log indexing. If log queries are not used, the parameter --execution.tx-indexer.enable=false can be used to completely disable log indexing.

Special Note 2

Nitro 3.7.0 pulls in go-ethereum 1.15.11 which includes a brand new log indexing system called filtermaps that has resulted in an increase in log indexing latency due to Nitro’s current reliance on HashDB (instead of PathDB). In some cases, this can delay log queries from being served anywhere between 5 seconds to 2 minutes on Arbitrum One during long tail unindexing. We’ve observed that this happens roughly once per day based on Arbitrum One mainnet traffic levels.

Teams who need to serve log queries with consisten latency (e.g. eth_getLogs, eth_getFilterLogs, eth_getFilterChanges) can use the configuration parameter --execution.rpc.log-history=0 to keep all log history, which will only slightly increase database growth. Teams running their own log indexer may be unaffected.

Future releases of Nitro are expected to fix the issue of log index pruning being able to block log queries.

What's Changed

• Improve CPU performance when processing blocks: #3542

Full Changelog: v3.7.0...v3.7.1-rc.1