Releases: OffchainLabs/nitro
Arbitrum Nitro v3.8.0-rc.7
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
Arbitrum Nitro v3.8.0-rc.6
This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:v3.8.0-rc.6-949e616
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.6-949e616-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.
Special Note about ArbOS 50 Support
Release v3.8.0-rc.6 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.
Configuration Changes
- The parameter
--node.data-availability.rpc-aggregator.max-store-chunk-body-sizehas been removed
What's Changed
Updated batch poster to support cell proofs which is required after Fusaka hard fork, change database schema, and other assorted updates.
User-facing Improvements
- Enable blob cell proofs for fusaka: #3788
- Remove Double Account Creation in BoLD Challenge Tests: #3746
- Remove pre sylus validation: #3785
- Update arbdb schema version to 2: #3759
Internal Highlights
- Add DA proof support to daprovider interface: #3600
- Refactor consensus-execution sync to push sync data: #3538
- Respect context cancellation during reconnect wait: #3751
- Support multi-dimensional resource constraints: #3755
- Close response body on non-200 Beacon REST responses to prevent connection leaks: #3756
- DataPoster: Verify external-signer transaction is signed by the expected address: #3731
- Hardening: fix CloseExec race, secure chunk-size tests, enforce gci: #3747
- IP address string conversion in connection limiter: #3762
- DAS: Fix last-chunk size validation when totalSize is a multiple of chunkSize: #3732
- DAS: make trie iterators robust to stray files: #3739
- DAS: Import data streaming changes: #3770
- Fix gas calculation precision: #3777
- Change MaxArbosVersionSupported to 40: #3800
Full Changelog: v3.8.0-rc.5...v3.8.0-rc.6
Arbitrum Nitro v3.8.0-rc.5
This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:v3.8.0-rc.5-6c74ee2
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.5-6c74ee2-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.
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.rpc.log-no-history 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.
What's changed
Final touches on ArbOS50 support, continue adding multi-dimensional gas support, minor fixes throughout codebase.
User facing changes
- Remove deprecated AnyTrust db storage service: #3701
Internal highlights
- Fix some tests: #3657
- stylus target: infer support of previous sse versions from more advanced ones: #3649
- Wire cranelift flag through compileNative in testcompile: #3634
- Reduce error message to trace: #3660
- Instrument multi-gas in emitLog HostIO: #3646
- Fix data race in LocalFileStorageService pruning goroutine: #3659
- Use the t.TempDir() for L1 data directory in tests: #3671
- Overhaul GitHub actions and workflows to add a merge queue: #3655
- fix(fuzz): validate --fuzzcache-path against fuzzcachepath, not binpath: #3656
- Fix DAS server http.Server.Addr and add graceful shutdown timeout: #3673
- Data stream improvements: #3661
- Revert change to the server address: #3677
- Fail the can_proceed job instead of skipping it: #3676
- arbos: Instrument multi-gas in create HostIO: #3672
- Cancel heavy jobs in progress when git.ref is updated: #3674
- fix: correct safe-wait delta calculation in edge tracker and transact: #3633
- Do not run CI workflow on push event (redundant with merge queue): #3679
- arbos: Instrument multi-gas in doCall HostIO: #3663
- Fix underflow inside the gas charging hook: #3688
- fix sendroot generation for genesis generator: #3686
- fix: enable ReadHeaderTimeout config and add tests: #3683
- Remove the quadrupling of MaxPerBlockGasLimit: #3692
- fix: expected hash in parent-chain linkage error: #3628
- Detailed batch post report: #3696
- Move funding common accounts to genesis block for L1: #3682
- arbos: Fixup log messages in attributeWasmComputation: #3709
- chore: remove no-op OS-specific prerequisites block in check-build.sh: #3675
- fix: missing reassignment of rivals when recording creation times in block snapshot: #3619
- update CI/CD infrastructure: standardize actions and upgrade linting tools: #3702
- fix(events): use stable subscription ids and remove by id: #3563
- System tests should use BOLD contracts by default: #3690
- Fix timer leaks in transaction streamer retry logic: #3717
- arbos: Instrument multi-gas in setTrieSlots HostIO: #3713
- fix: correct error message formatting in blockchain and genesis generator: #3722
- Interpolate the RUN_URL in Slack notification: #3723
- fix: use Counter for nonceFailureCache overflow metric: #3648
- Close HTTP response body to prevent connection leaks in REST URL list fetcher: #3715
- Fix secondary beacon URL parsing in BlobClient: #3721
- fix(solimpl): correct UpperChild zero-check to use UpperChildId: #3703
- Add multi-dimensional gas metrics: #3726
- Instrument multi-gas in precompiles: #3729
- Enable CodeCov analysis: #3714
- Refactor caller context creation and remove redundant argument: #3733
- Merge go-ethereum v1.16.4: #3734
- timeboost: replace time.After in loop with cancellable timer to prevent leaks: #3728
- feat(nitro-val): implement ValidationNodeConfig.Validate with logging and persistent checks: #3735
- remove: delete unused HashPlusInt function from arbos/util: #3730
- Use also head_ref for limiting CI concurrency: #3741
- Add support for consensus-v50-rc.5 to Dockerfile: #3744
Full Changelog: v3.8.0-rc.4...v3.8.0-rc.5
Arbitrum Nitro Consensus v50 Release Candidate 5
This release signifies a WASM fraud proof consensus version, and is not a good version to run a node on
WAVM Module Root: 0xb90895a56a59c0267c2004a0e103ad725bd98d5a05c3262806ab4ccb3f997558
This is a release candidate of a consensus release for ArbOS 50, including support for Fusaka.
Full Changelog: consensus-v40...consensus-v50-rc.5
Arbitrum Nitro v3.7.4
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.4-9244576
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.4-9244576-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.rpc.log-no-history 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. As above, there will likely be elevated CPU usage for some time while it creates new indexes. 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
- stylus target: infer support of previous SSE versions from more advanced ones: #3658
- Fix some tests: #3665
Full Changelog: v3.7.3...v3.7.4-rc.2
v3.7.4-rc.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.4-rc.2-9244576
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.4-rc.2-9244576-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.rpc.log-no-history 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. As above, there will likely be elevated CPU usage for some time while it creates new indexes. 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
- stylus target: infer support of previous SSE versions from more advanced ones: #3658
- Fix some tests: #3665
Full Changelog: v3.7.3...v3.7.4-rc.2
Arbitrum Nitro v3.8.0-rc.4
This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:v3.8.0-rc.4-4d9a400
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.4-4d9a400-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.
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.rpc.log-no-history 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
- Fix consensus bug introduced in
v3.8.0-rc.3
What's Changed
- Make sure to retry fast confirmation on failure: #3640
- fix: recreate-missing-state-from panic: #3464
- Add FloorGasAdditionalTokens to floor-gas computation: #3642
- Fix redefining of staker related metrics: #3592
- Fix api.go to use new callcode/delegatecall/staticcall signatures: #3635
- Instrument multi-gas in account HostIOs: #3645
- Use RLock instead of Lock in CollectMachineHashes: #3632
- Extract SerializedChainConfig from json directly: #3636
- Remove unnecessary alias imports: #3637
- Fix goroutine loop variable capture in sequencer shutdown forwarding: #3623
- fix: Docker and tool version checks for accurate reporting: #3643
- Account for multi-gas in transaction intrinsic gas: #3639
- batch_posting report: fix addition of batchExtraGas: #3654
Full Changelog: v3.8.0-rc.3...v3.8.0-rc.4
Arbitrum Nitro v3.8.0-rc.3
This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node:v3.8.0-rc.3-22f4bff
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.3-22f4bff-validator which has the extra script /usr/local/bin/split-val-entry.sh as the entrypoint.
Special Note
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.
Configuration Changes
--node.bold.strategyhas been removed, use--node.staker.strategyinstead
User facing changes
- Important! If you have previously used the
ArbOwner.setMaxTxGasLimitto set the max transaction and block gas limits for your chain, you should add calls toArbOwner.setMaxTxGasLimitandArbOwner.SetMaxBlockGasLimitto your upgrade action to arbos 50. (When it's time.) - After the arbos 50 upgrade, there is a new
ArbOwner.setParentGasFloorPerTokenwhich can be used to set the parent chain's blob base fee per token (4 bytes) of calldata. 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
- Makes Nitro configurable to handle the parent chain implementing EIP-7623
What's Changed
- Add extra logs to debug missing onchain controller in #3561
- chore: Add require-exhaustive-init linter to structs (1/n) in #3575
- fix: Correctly count struct fields in the structinit linter in #3579
- Fix PublishedMachine tests to handle cases when latest release is behind latest ArbOS in #3581
- Multigas: Instrument GasChargingHook with multi-gas in #3576
- Run execution-spec-tests in nightly CI in #3577
- Fix: Return proper error on non-200 in RestfulDasClient.ExpirationPolicy in #3585
- Move output dir setup to constructor; make Start launch-only in #3578
- Small fixes related to DA in #3591
- fix: Make structinit linter work cross packages in #3586
- Test Genesis assertion on nitro init in #3570
- Update Rust to 1.88.0 in #3553
- CustomDA core Arbitrator & WASM infra in #3548
- Remove redundant Background context initialization in poster_test in #3595
- Include msg.SetCodeAuthorizations field when constructing arbitrum.TransactionArgs in #3598
- Fail instead of panic when building second node if first node was not built with L1 in #3601
- Turn bold into a sub-package of nitro in #3599
- Unify DAS interfaces in #3593
- Add to chain_info: feed-signed in #3583
- Update the implementation of EIP-7825 in #3589
- Fix l1 pricing state field order in #3602
- Multigas: Add multi gas to transaction receipt and remove collector in #3594
- bugfix: genesis validation without l1 reader in #3607
- Extract streaming protocol (sender) in #3603
- Named initializer linter in #3604
- Linters cleanup in #3609
- Hide multi-gas behind feature flag in #3613
- Fix race in DAS chunk assembly by adding per-batch locking in #3588
- Arbos50 block gaslimit in #3606
- bold/e2e: fix Anvil startup race causing RPC hangs in end-to-end tests in #3612
- Ignore the go.work and go.work.sum files in #3620
- Recursively fetch submodules in CI in #3621
- Hotfix: remove hardcoded value in TestMultigasStylus_GetBytes32 in #3614
- Fix ProduceBlockAdvanced handling of txs that don't need sequencing hooks in #3627
- Extract streaming protocol (receiver) in #3625
- [config] Handle node.staker.strategy and node.bold.strategy appropriately in #3582
- Gas floor in #3618
- Multigas: Fix api.go to use new
evm.Createsignature in #3630 - Add suppoort for Consensus V50 (rc.4) to Docker in #3638
Full Changelog: v3.8.0-rc.2...v3.8.0-rc.3
v3.7.3
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.3-e421729
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.3-e421729-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.rpc.log-no-history 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
- Make sure to retry fast confirmation on failure: #3641
Full Changelog: v3.7.2...v3.7.3
Arbitrum Nitro v3.7.3-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:v3.7.3-rc.1-e421729
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.3-rc.1-e421729-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*
Make sure to retry fast confirmation on failure: #3641
Full Changelog: v3.7.2...v3.7.3-rc.1