This release is available as a Docker Image on Docker Hub at offchainlabs/nitro-node: v3.7.6-c0fe95e
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.6-c0fe95e-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
Automatically handle beacon RPC changes before Fusaka and after Fusaka hard fork.
This PR also introduces a --parent-chain.blob-client.dangerous.skip-blob-proof-verification flag which allows skipping the verification of blob proofs returned from the beacon client. This allows the node to be robust when connecting to a beacon node client like Teku which doesn't provide blob proofs after the fusaka fork AND doesn't support the new blobs endpoint.
User-facing Changes
- Attempt both blob_sidecars and blobs beacon api endpoints and add skip KZG flag: #3836
Full Changelog: v3.7.5...v3.7.6