fix(devnet): Support op-reth v2.1.0 upgrade#162
Merged
Conversation
…2.1.0 In op-deployer v2.1.0+, DeployImplementations no longer populates the legacy opcmAddress field (always zero); the active contract is exposed as opcmV2Address. The apply pipeline also requires superchainConfigProxy to be supplied explicitly because OPContractsManagerV2 does not expose a superchainConfig() getter for on-chain resolution. Source opcmAddress from implementations.json's opcmV2Address and superchainConfigProxy from superchain.json before invoking op-deployer. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Reth v2.0.0 defaults --storage.v2 to true, but its v2 init path calls set_expected_block_start for AccountChangeSets/StorageChangeSets when genesis is non-zero. That mutates the in-memory expected_block_range to start at the genesis block while leaving the file on disk named at the fixed-range boundary. The next startup's check_consistency healer derives the path from the mutated range, fails to find the file, and panics on op-reth-seq launch. Force v1 init via --storage.v2=false (skipping the buggy code path), then run op-reth db migrate-v2 to upgrade to v2. The migration command builds static files via its own writer logic, producing correctly named segments. All existing dependents (rpc/seq2/rpc2 cp -r) pick up the migrated v2 layout automatically. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Reth v2.0.0 defaults --storage.v2 to true, but the v2 init path calls set_expected_block_start for AccountChangeSets/StorageChangeSets when genesis is non-zero. The mutated header range no longer matches the on-disk file name, so the next startup's check_consistency healer panics on op-reth-seq launch. Disable v2 by default in init and runtime entrypoints (reth-seq, reth-rpc) by passing --storage.v2=false unless RETH_STORAGE_V2=true is explicitly opted in. Drops the migrate-v2 step from init since the runtime now stays on v1. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Vui-Chee
approved these changes
Apr 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Resolves op-deployer v2.1.0+ upgrade onwards.
DeployImplementations no longer populates the legacy opcmAddress field (always zero); the active contract is exposed as opcmV2Address. The apply pipeline also requires superchainConfigProxy to be supplied explicitly because OPContractsManagerV2 does not expose a superchainConfig() getter for on-chain resolution.
Source opcmAddress from implementations.json's opcmV2Address and superchainConfigProxy from superchain.json before invoking op-deployer.
🤖 Generated with Claude Code