Repository navigation
chore: port-to-v6 rolling port - #25587
Merged
Merged
Conversation
… scheduled change to the same value (#25586) Closes AztecProtocol/aztec-claude#2425 ## Problem `ScheduledValueChange::get_time_horizon` treats any pending scheduled change as a bound on how long the value read at the anchor block stays current, clamping the horizon to `timestamp_of_change - 1`. It does so even when the scheduled `post` equals `pre`, i.e. the change does not move the value. That state is produced by the documented cancellation mechanism (scheduling the current value) and by any idempotent setter such as `ContractInstanceRegistry::update` re-applying the class a contract already runs. Because the private kernel folds the registry entry's horizon into `expiration_timestamp` for every private call to that contract, a cancelled or idempotent update pins every caller's deadline to the phantom instant for a full delay period. As the anchor approaches it, the inclusion window shrinks to zero: at `anchor == timestamp_of_change - 1` the kernel emits `expiration_timestamp == anchor_block_timestamp`, which the rollup rejects for every later block. ## Fix In `get_time_horizon`, take the "no change ahead" branch (`anchor_block_timestamp + minimum_delay`) when `self.pre == self.post`. Such a change cannot alter the current value, so the earliest a different value can take effect is bounded by `minimum_delay`, exactly as when no change is pending. The method gains a `T: Eq` bound; its caller `compute_delayed_public_mutable_time_horizon` already requires `T: Eq`. The clamp for a genuine pending change (`pre != post`) is unchanged. Which of `pre` or `post` a read returns (`get_current_at`) is unchanged. ### Not covered A contract that has never been updated has the stored class id 0, which the kernel reads as "use the original class". Cancelling that contract's first update needs `update(original class)`, which stores `(0, original, toc)`. The two values mean the same class but are not equal, so the clamp still applies. This is safe (the horizon is too early, never too late). Covering it needs a kernel-level comparison that maps 0 to the original class id. ## Scope and cost - **Private kernel VKs change** for `private_kernel_init`, `private_kernel_inner` and their batched variants: +5 ACIR opcodes per private call. `private_kernel_reset_tail` is unchanged. - **Genesis does not move.** The protocol contracts compile to identical bytecode with and without the change. ## Tests (red → green) - `types`: `test_get_time_horizon_change_to_same_value_in_near_future` asserts the horizon is `anchor + minimum_delay` and checks the existing horizon invariants. Fails without the fix (returns `timestamp_of_change - 1`). - `private_kernel_lib` (`private_kernel_init`), driven through the real registry hint with a rebuilt public-data tree: - `expiration_timestamp_not_constrained_by_pending_contract_update_to_same_class`: a change to the class the contract already runs at `anchor + 1` yields `expiration_timestamp == anchor + DEFAULT_UPDATE_DELAY - 1`. Fails without the fix (emits `anchor`). - `expiration_timestamp_constrained_by_pending_contract_update`: control pinning that a genuine pending update at `anchor + 1` still collapses the deadline to `anchor`. The patch applies to `next` @ `551aa413aec` with no changes beyond a 3-line hunk offset. Full `types` / `private_kernel_lib` suites and `nargo fmt --check` passed on the same change against the private mirror of `next`; CI covers this branch. Labeled `port-to-v6`. --- *Created by [claudebox](https://claudebox.work/v2/sessions/9d033df6e2d9d301/jobs/3) · group: `slackbot` · requested by Mike (@iAmMichaelConnor) · [Slack thread](https://aztecfoundation.slack.com/archives/D0B2N7W1WJD/p1791128950488809?thread_ts=1791128950.488809&cid=D0B2N7W1WJD)* (cherry picked from commit d363a40)
AztecBot
added
ci-draft
iAmMichaelConnor
marked this pull request as ready for review
October 4, 2026 16:41
iAmMichaelConnor
requested review from
IlyasRidhuan,
LeilaWang,
iAmMichaelConnor,
iakovenkos and
ledwards2225
as code owners
October 4, 2026 16:41
iAmMichaelConnor
approved these changes
Oct 4, 2026
iAmMichaelConnor
enabled auto-merge (squash)
October 4, 2026 16:42
…orizon on a scheduled change to the same value The horizon change alters the private_kernel_init and private_kernel_inner circuits, so the VK tree root v6 builds moves to 0x1032cbb2f61a9c1151370ebc35c8ea20d1a726e3388eb94e84291c2b2fecb5d3. Labs patch 0001 pins testnet_compatibility.test.ts to it; the protocol contracts hash and genesis root are unchanged.
iAmMichaelConnor
approved these changes
Oct 4, 2026
1 task done
IlyasRidhuan
added a commit
that referenced
this pull request
Oct 5, 2026
Rolling integration PR for changes labelled `port-to-v6` on `next`. Each merged source PR is cherry-picked onto `cb/port-to-v6` as its own commit, keeping `(#N)` in the title. ## Ported - [x] [#25589](#25589) chore: blobs and docs (pick of the merge commit, `-m 1`, applied without conflicts, plus one `fix(port)` commit) - All eight files end up identical to `next` at 86d0021, as do the `blob` and `rollup-lib` crates and the whole `l1-contracts` directory. - It adds two labs patches, which keep their `next` numbering: - `0006-fix-blob-lib-bind-checkpoint-boundaries-into-the-blo.patch` (`yarn-project/blob-lib`, a test fixture path and the L1 publisher integration test) - `0007-docs-aztec-nr-private-log-fields-past-the-log-s-leng.patch` (a doc comment in `aztec-nr`'s `private_context.nr`) - Every file those two patches touch has the same pre-image blob on the `v6` labs pin `a0d73c0aed` as the patch expects. - The `fix(port)` commit updates labs patch `0001-test-pin-testnet-compatibility-to-the-v6-kernel-VK-t.patch` to the VK tree root `v6` builds with this change. ## Protocol impact - The blob commitments hash now binds checkpoint boundaries: each commitment is hashed with a one-byte flag that is `0x01` for a checkpoint's first blob and `0x00` otherwise. The change is made in three places that have to agree: - L1: `BlobLib.calculateBlobCommitmentsHash` - circuits: the `blob` crate (`blob_batching.nr`, the accumulator ABIs), consumed by the rollup circuits - node: `yarn-project/blob-lib`, through labs patch 0006 - This changes the rollup circuits, so the VK tree root that `v6` builds moves: - from `0x1032cbb2f61a9c1151370ebc35c8ea20d1a726e3388eb94e84291c2b2fecb5d3` (pinned on `v6` since #25587) - to `0x031139abb5b9f51ca0e55a6e2022d567029f50acc9428506f05c91ae27e7f75d` (taken from this PR's failing CI run on `b2cd9f3f`), which is what labs patch 0001 now pins - The testnet deployed from `v6` has root `0x2d89003cc2dc62b06f07d83d3635c66c63fc43668369d30e7ee516f908ee10e3`; `v6` has not matched it since #25575. The re-pin follows the decision recorded on #25549 (a breaking circuit change ported to `v6` re-pins testnet in the same PR). - The protocol contracts hash and the genesis root are unchanged; those two assertions passed on `b2cd9f3f`. - The L1 change takes effect only on a rollup deployed from this code. A node built from this branch computes the new hash, so it does not agree with a rollup deployed before it. ## Testing - CI3 on `b2cd9f3f` (before the re-pin): `testnet_compatibility.test.ts` › "has expected VK tree root" was the only failure in the fast run, which covers the `blob` and rollup circuit tests, the new `blobCommitmentsHash.t.sol` forge test and the labs `blob-lib` tests. - `./labs-patches/bootstrap.sh check`: the series (0001, 0006, 0007, 0010) applies cleanly to the labs pin `a0d73c0aed`. Patch 0001 was produced with `bootstrap.sh apply` / `export`. - No circuits or L1 contracts were built locally (no `nargo` and no pinned `solc` in the port environment); the re-pinned test runs on this PR's CI. --- *Created by [claudebox](https://claudebox.work/v2/sessions/134efca9a11ee14f/jobs/29) · group: `slackbot` · [Slack thread](https://aztecprotocol.slack.com/archives/C0AGN2WT3CP/p1790609320989739?thread_ts=1790609320.989739&cid=C0AGN2WT3CP)*
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.
Rolling integration PR for changes labelled
port-to-v6onnext. Each merged source PR is cherry-picked ontocb/port-to-v6as its own commit, keeping(#N)in the title.Ported
fix(port)commit)nextat d363a40, as do thetypesandprivate-kernel-libcrates.fix(port)commit updates labs patch0001-test-pin-testnet-compatibility-to-the-v6-kernel-VK-t.patchto the VK tree rootv6builds with this change.Protocol impact
ScheduledValueChange::get_time_horizonno longer clamps the horizon when the scheduled value equals the current one, so a cancelled or idempotent contract update no longer shortens callers'expiration_timestamp. A genuine pending change is clamped as before.private_kernel_initandprivate_kernel_innercircuits (and their batched variants), so the VK tree root thatv6builds moves:0x05b95d9ef57c61d1c6626545101db55ae2d1f98ecb618d1c220610c049ee522b(pinned onv6since chore: port-to-v6 rolling port #25575)0x1032cbb2f61a9c1151370ebc35c8ea20d1a726e3388eb94e84291c2b2fecb5d3(taken from this PR's failing CI run on0c629b6d), which is what labs patch 0001 now pinsv6has root0x2d89003cc2dc62b06f07d83d3635c66c63fc43668369d30e7ee516f908ee10e3;v6has not matched it since chore: port-to-v6 rolling port #25575. The re-pin follows the decision recorded on chore: port-to-v6 rolling port #25549 (a breaking kernel change ported tov6re-pins testnet in the same PR).0c629b6d.Testing
0c629b6d(before the re-pin):testnet_compatibility.test.ts› "has expected VK tree root" was the only failure in the fast run, which covers thetypesand kernel unit tests../labs-patches/bootstrap.sh check: the series (0001, 0010) applies cleanly to the labs pina0d73c0aed. Patch 0001 was produced withbootstrap.sh apply/export.nargoin the port environment); the re-pinned test runs on this PR's CI.Created by claudebox · group:
slackbot· Slack thread