fix(l1): make the generic deployer refuse unusable rollup configuration - #25520
Merged
Merged
Conversation
…of the environment
iAmMichaelConnor
approved these changes
Sep 22, 2026
iAmMichaelConnor
marked this pull request as ready for review
September 22, 2026 16:57
iAmMichaelConnor
requested review from
just-mitch and
koenmtb1
as code owners
September 22, 2026 16:57
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.
Independent of the v6 upgrade PR (#25496)
This PR is not a dependency of, and does not depend on, the v6 upgrade PR #25496. Either can merge first, and neither needs a rebase on the other.
DeployRollupForUpgradeV6.s.sol,V6UpgradeSimulation.solandV6UpgradePayload.solimport onlysrc/contracts, the generatedHonkVerifier, and each other. None of them importsDeployRollupLib,RollupConfiguration,DeployRollupForUpgradeorDeployAztecL1Contracts, which are the only Solidity files this PR changes. The V6 script's one mention ofRollupConfigurationis a comment about version derivation, and this PR does not touch that function.forge scripton the V6 files directly. It does not userun_rollup_upgrade.sh,test_rollup_upgrade.shorstress_test_deploy.sh, which are the shell scripts this PR edits.src/changes, so the bytecode v6 deploys is identical with or without this PR.Problem
l1-contracts/script/deploy/is the env-driven deployer for tests, spartan/CLI and testnets (mainnet versions use the pinnedDeployRollupForUpgradeV<N>.s.solscripts, which hard-code and verify their configuration). The generic path forwarded whatever the environment supplied straight into theRollupconstructor, and the constructor accepts values that leave the deployed instance unusable or mis-bound. Several defaults were also fail-open: a missingREAL_VERIFIERbound aMockVerifier, and a missing genesis root silently became zero.Change
All in the deployer, its wrappers and its tests.
script/deploy/RollupConfiguration.solREAL_VERIFIERdefaults totrue; a stub verifier must be requested explicitly.VK_TREE_ROOT,PROTOCOL_CONTRACTS_HASHandGENESIS_ARCHIVE_ROOTmust be set and non-zero.NETWORK=mainnetrequires chain id 1 and chain id 1 requiresNETWORK=mainnet.script/deploy/DeployRollupLib.sol—validateRollupConfig, run beforenew Rollup:slot × epochfitsuint32(TimeLibmultiplies without widening);exitDelaySecondsnon-zero;lagInEpochsForRandao ≥ 1, validator-set lag not below it, and lag in seconds fitsuint32;uint96(SlashingProposerencodes payload amounts asuint96);rewardDistributornon-zero;stakingAsset == GSE.ASSET().Two values are deliberately not rejected because the node's test paths rely on them: a zero
targetCommitteeSize(ValidatorSelectionLibtreats it as "no committee"; the local network and e2e fixtures use it) and an epoch longer thanMAX_CHECKPOINTS_PER_EPOCH(e2e suites use 64 and 1000 to keep a run inside epoch 0).script/deploy/DeployRollupForUpgrade.s.sol—REGISTRY_ADDRESSmust have code on the target chain.scripts/run_rollup_upgrade.shno longer needs to overrideREAL_VERIFIER.scripts/test_rollup_upgrade.shandscripts/stress_test_deploy.shexport the three genesis roots, and the two script tests set them insetUp.The node's TypeScript deployer already passes
REAL_VERIFIERand all three genesis roots explicitly, and no in-tree, e2e or spartan configuration uses a value these checks reject.Tests
New
test/script/DeployConfigValidation.t.solexercises each check on values via small harnesses rather than throughvm.setEnv, because forge runs tests in parallel and the process environment is shared; itssetUpsets the same env values as the other script tests for the same reason. Locally:forge fmt --checkandforge lintare clean on the changed files apart from the pre-existingunsafe-cheatcodenotes forvm.setEnv. CI covers the rest of thel1-contractssuite and the e2e suite.Not in this PR: wiring an
EscapeHatchinto the generic upgrade script, which needs a configuration surface for the hatch parameters rather than a guard.Closes AztecProtocol/aztec-claude#840
Closes AztecProtocol/aztec-claude#845
Closes AztecProtocol/aztec-claude#1371
Closes AztecProtocol/aztec-claude#688
Closes AztecProtocol/aztec-claude#684
Closes AztecProtocol/aztec-claude#707
Closes AztecProtocol/aztec-claude#865
Closes AztecProtocol/aztec-claude#657
Closes AztecProtocol/aztec-claude#689
Closes AztecProtocol/aztec-claude#1003
Closes AztecProtocol/aztec-claude#1355
Refs AztecProtocol/aztec-claude#686
Refs AztecProtocol/aztec-claude#811
Refs AztecProtocol/aztec-claude#1145
The eight constructor-input findings are closed at the deployer layer on purpose: the constructors in
src/are unchanged because the mainnet pinned scripts assert these values themselves. If contract-level guards are wanted as well, change those lines toRefsbefore merging. #686 (zero committee) and #811 (epoch above the proof cap) are not closed here: both values are used by the node's own test paths, so any guard for them has to live in the pinned mainnet scripts, which already assert them.Created by claudebox · group:
slackbot· requested by Mike (@iAmMichaelConnor) · Slack thread