This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:v3.8.0-rc.7-ef47e28
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.8.0-rc.7-ef47e28-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.
Note
This release should only be used by batch posters on L2 chains that submit blobs to L1 Sepolia for DA. These batch posters will need to upgrade to this release before Sepolia activates the fusaka hardfork on October 14th 2025. A new version of Nitro will be released more than 7 days before Mainnet Ethereum activates fusaka hardfork which is currently expected occur early December 2025.
Special Note about ArbOS 50 Support
Release v3.8.0-rc.7 is unrelated to ArbOS50. A future version of Nitro that supports ArbOS50 will eventually be mandatory if the DAO votes to adopt ArbOS50, but this will be addressed later.
Special Note For Database Schema
- Nitro 3.8.0 changes the database schema, so once a database has been run with 3.8.0, the database can no longer be opened with Nitro 3.7.x.
Special Notes about log index system changes to filtermaps from upstream go-ethereum
- 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.rpc.log-no-historycan be used to completely disable log indexing. - Nitro 3.7.0 pulled in go-ethereum 1.15.11 which includes a brand new log indexing system called
filtermapsthat 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=0to 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.
What's Changed
- Fix backward incompatible data-streaming protocol change by @pmikolajczyk41 in #3802
Full Changelog: v3.8.0-rc.6...v3.8.0-rc.7