feat(auth_registry): demote to non-protocol contract via two-pass build#23106
Open
feat(auth_registry): demote to non-protocol contract via two-pass build#23106
Conversation
Cuts the apparent build cycle ("every consumer needs the address; the
address depends on the artifact") with a new
`noir-projects/aztec-nr/auth_registry_address/` crate sitting downstream
of `auth_registry_contract` but upstream of every consumer. The cut
works because auth_registry only calls the private-path authwit helpers
and the public-path wrappers (which inline the address) get tree-shaken
out of its bytecode. The cycle-guard CI script enforces both halves of
that invariant.
Splits `noir-projects/noir-contracts/bootstrap.sh build` into
phase 1 (compile auth_registry) -> stamp (TS script writes lib.nr +
lib.lock.json + TS twin from the artifact) -> phase 2 (compile
everything else); a source-content-hash freshness gate fronts every
partial build and exits with the regen instruction on drift.
Drops `auth_registry_contract` from `protocol_contracts.json`,
`CANONICAL_AUTH_REGISTRY_ADDRESS` from `constants.nr`, the matching
CPP/PIL whitelist entries, and the `AuthRegistry` slot in
`generate_data.ts`. Slot 1 in the protocol-contracts roster stays
vacant (`AztecAddress::zero()`); `MAX_PROTOCOL_CONTRACTS` stays at 11.
dbanks12
changed the title
dbanks12
changed the title
dbanks12
changed the title
Reverts the protocol-contracts roster removal, the bootstrap.sh phase split, and the cascade of TS-side rewrites that depended on them. The build-pipeline ordering (noir-projects builds before yarn-project) means a stamp script that depends on @aztec/foundation/@aztec/stdlib cannot run during noir-projects bootstrap; that's a structural change to make in a follow-up alongside the actual demotion. Keeps the structural Noir-side cut: the new `noir-projects/aztec-nr/auth_registry_address/` crate (alias for the slot-1 magic address while auth_registry remains a protocol contract), 4 Noir consumer migrations to import from it, the cycle-guard CI script, and the stamp-script + tests as utilities for the follow-up.
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
1 participant
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
noir-projects/aztec-nr/auth_registry_address/as the dependency-cut crate every consumer of the auth_registry address imports from. Today it aliases the magic slot-1 protocol-contract address; the follow-up demotion PR overwrites it with the artifact-derived address viayarn-project/protocol-contracts/src/scripts/derive_auth_registry.ts.aztec-nr/aztec/src/authwit/auth.nr,aztec-nr/aztec/src/test/helpers/authwit.nr,aztec_sublib/src/authwit/auth.nr,avm_test_contract/src/main.nr) and theirNargo.tomldeps to use the new crate.auth_registry_contractitself MUST NOT depend on the new crate; the structural + bytecode-level cycle guard atnoir-projects/scripts/auth_registry_cycle_guard.shpins that invariant.derive_auth_registry.ts(Noir + TS twin renderer +lib.lock.jsonwriter withsrcContentHashfor the freshness gate) and a unit test for its determinism. Not yet wired into bootstrap — calling it fromnoir-projects/requires@aztec/foundation/@aztec/stdlibto already be built, which violates the existingbarretenberg → noir → l1-contracts → yarn-projectbuild order. That wiring is the follow-up.Why scoped down from the original design
Final design lives at https://gist.github.com/dbanks12/149a8f296e8c141a8d19ff20c5ea9f45 (Category C: tree-shaken-leaf two-pass build). The first attempt (commit
d983ec7, reverted in91c7205) implemented the full design: split bootstrap.sh into phase1 → stamp → phase2, droppedauth_registry_contractfromprotocol_contracts.json+ theCANONICAL_AUTH_REGISTRY_ADDRESSconstant, and migrated every TS-side consumer.CI failed (https://github.com/AztecProtocol/aztec-packages/actions/runs/25572154854/job/75070294420) because
bootstrap.sh's new stamp step shells out toyarn generate:auth-registry-addressfrom insidenoir-projects/— but yarn-project hasn't been built yet at that point. The clean fix is to either (a) move stamp logic into a dependency-free Noir-projects-side script or (b) restructure the build pipeline so a minimal@aztec/foundation+@aztec/stdlibslice builds beforenoir-projects/. Both are bigger changes than what fits in this PR; this PR sets up the dependency-cut crate so the follow-up can land cleanly.Test plan
yarn-project/protocol-contracts/src/auth-registry/derive_auth_registry.test.ts).noir-projects/scripts/auth_registry_cycle_guard.sh) — structural + bytecode invariant.e2e_authwit*and every consumer is bytecode-identical to base modulo the import path.Risks
auth_registry_addressparticipates in every consumer'scache_content_hash(viaaztec-nr/), so a comment-only edit to that crate'slib.nrtriggers a wider rebuild than before. Expected once stamping is wired up; flagging now.aztec-nr/authwit.