system-config: remove batchInbox getter and setGasConfig - #922
Merged
Conversation
This was referenced Jul 8, 2026
Open
The batch inbox address is defined in the rollup configuration, and nothing in the OP Stack read it from the SystemConfig. Keeping the onchain copy meant OPCMv2's reinitialization could recompute it with the new-chain addressing scheme, which is what rotated it for every pre-OPCM chain during U19. `initialize` now clears the legacy slot instead of setting it. `setGasConfig` goes too. It could only write version-0 scalars and did not update the `basefeeScalar`/`blobbasefeeScalar` mirrors that OPCM reads, so calling it desynchronized `scalar` from those mirrors and the next upgrade silently reverted the change. Removing it makes the mirrors agree with `scalar` by construction. `overhead` is therefore immutable, which is fine because op-node ignores it after Ecotone. `startBlock` is unchanged — it is only written when unset, so reinitialization preserves it.
mds1
force-pushed
the
mds/remove-systemconfig-batch-inbox-start-block
branch
from
July 27, 2026 15:31
8572127 to
fbbe1d3
Compare
sebastianst
reviewed
Jul 28, 2026
sebastianst
left a comment
Member
There was a problem hiding this comment.
We usually keep historical information in the protocol specs, but I can see how this gets increasingly awkward, see comments. Wondering if we want instead switch to a description of the present state only and keep a separate Changelog section where we describe the diffs of each contract change.
…markers Per seb, the protocol specs keep historical information, so restore the `batchInbox` and `setGasConfig` sections with their TOC entries rather than deleting them, each marked `(-op-contracts/v8.0.0)` and noting removal in `SystemConfig` v4.0.0. Split the `initialize` batch inbox MUST into a versioned pair so the old behavior stays recorded next to the new one. The existing `(+v4.1.0)` markers were ambiguous between an op-contracts release and a contract semver. They mean the release: at `op-contracts/v4.1.0` the feature-flag and optional-ETHLockbox pause work is present while SystemConfig is at 3.7.0 and SuperchainConfig at 2.3.0, and no contract has ever been at 4.1.0. Make that explicit with the full `op-contracts/vX.Y.Z` identifier, normalize the existing markers in system-config.md and stage-1.md, and add a note to the Function Specification section saying which scheme is which. Also record what the monorepo PR actually changed about the overhead: `ConfigUpdate` type 1 now always carries a zero in the `overhead` entry, and the payload stays two words so its length is unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
6 tasks
maurelian
reviewed
Jul 29, 2026
maurelian
reviewed
Jul 29, 2026
maurelian
approved these changes
Jul 29, 2026
sebastianst
approved these changes
Jul 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
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.
Spec side of ethereum-optimism/optimism#21641, which removes
batchInbox()and the deprecatedsetGasConfigfrom the SystemConfig at op-contracts v8.0.0.Changes:
The
batchInboxandsetGasConfigsections stay as historical record rather than being deleted, each marked(-op-contracts/v8.0.0)and noting that it was removed inSystemConfigv4.0.0. Their TOC entries stay too.initialize's batch inbox MUST is split into a versioned pair:(-op-contracts/v8.0.0)sets the Batch Inbox address,(+op-contracts/v8.0.0)clears the legacy slot. Nothing in the OP Stack read that copy — derivation takes the batch inbox from the rollup config — and keeping it meant OPCMv2's reinitialization could recompute it with the new-chain addressing scheme, which is what rotated it for every pre-OPCM chain during U19.Version markers now spell out which scheme they mean.
(+op-contracts/vX.Y.Z)and(-op-contracts/vX.Y.Z)are op-contracts releases; a version written asSystemConfigvX.Y.Z is the contract's own semver. There is a one-line note to that effect at the top of the Function Specification section, and the existing markers insystem-config.mdandstage-1.mdare normalized to the full identifier.The existing
(+v4.1.0)markers were genuinely ambiguous, so to be explicit about why they are releases: atop-contracts/v4.1.0the feature-flag and optional-ETHLockboxpause behavior those markers describe is present, whileSystemConfigis at 3.7.0 andSuperchainConfigat 2.3.0. Neither contract has ever been at 4.1.0 —SuperchainConfigis still at 2.4.3 today — andsetFeatureEnabledis absent atop-contracts/v4.0.0.ConfigUpdatetype 1 records that as ofSystemConfigv4.0.0 theoverheadentry is always zero, and that the payload stays two words so its length is unchanged._setGasConfigEcotonehardcodes the zero because op-node ignores the overhead after Ecotone, but the event data has to stay 64 bytes.The post-Ecotone Overhead note says it is no longer writable, since
setGasConfigwas its only writer, and thatsetGasConfigEcotoneemits zero in its place. The variable and getter are kept, sooverhead()still works.The Batch Inbox address heading in
configurability.mdloses its staleSystemConfig.sol#L176permalink and says the value is defined in the rollup configuration and, as ofSystemConfigv4.0.0, is no longer stored onchain.Not doing here, per the review discussion: a separate per-contract Changelog section. The
(+v)/(-v)markers already carry this change now that they say which versioning scheme they use. Happy to open a follow-up issue for the Changelog idea if we want it.