refactor: remove aztec dependency from aztec_sublib#22033
Conversation
| /// | ||
| /// @dev Whenever a contract function or Noir test is run, the `aztec_utl_assertCompatibleOracleVersion` oracle is | ||
| /// called and if the oracle version is incompatible an error is thrown. | ||
| pub global ORACLE_VERSION: Field = 21; |
There was a problem hiding this comment.
how does this ORACLE_VERSION relate to the one in aztec.nr? are they supposed to be in sync so the same PXE picks both up indistinctly?
There was a problem hiding this comment.
That's to be discussed but currently the version 21 is here because the code of the protocol contract was "following" the changes in the real Aztec.nr. So figuring the versioning out is for another PR.
But this is indeed very problematic because the contracts are to go for an audit at which point we will not want to modify this.
The only feasible approach is to stick to backwards compatibility from now on and modify the pxe oracle check to check that AZTEC_NR_ORACLE_VERSION > 21 && AZTEC_NR_ORACLE_VERSION <= PXE_ORACLE_VERSION.
WDYT?
There was a problem hiding this comment.
I don't understand the issue here - sublib is on version 21 no?
There was a problem hiding this comment.
Yes, the question is what to do with this with future changes in the real Aztec.nr
There was a problem hiding this comment.
🤔
I think I've been thinking of this with the wrong perspective. My concern was that with aztecsublib and aztecnr now properly parting ways, we would end up with two different sets of oracles so we would need two different versions and PXE would need to be aware of that.
But that was the wrong frame: the oracle version is determined by PXE's interface, and the different nr libs just need to declare which one they were built for. Then it's up to PXE to detect compatibility or lack there of.
When Aztec.nr gets future changes leveraging newer oracle versions, it will just state its target version and aztecsublib will stay at 21. Then it's our job to make sure we don't ship PXE's where both libs are properly supported.
So this is not different from the more general issue of oracle semver we've been discussing.
| type = "lib" | ||
|
|
||
| [dependencies] | ||
| aztec = { path = "../../../../aztec-nr/aztec" } |
There was a problem hiding this comment.
it's so nice to see this line go 😍
|
/claudebox point this pr at merge-train/fairies and rebase the branch on it |
|
ClaudeBox: point this pr at merge-train/fairies and rebase the branch on it ... workflow run |
Copy the version oracle into aztec_sublib directly so it no longer depends on the aztec (aztecnr) crate. This makes aztec_sublib fully independent, allowing it to be audited and versioned on its own timeline. Resolves F-466 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
benesjan
force-pushed
the
jan/extract-version-oracle-for-sublib
branch
from
f5bc24b to
0b15229
Compare
benesjan
changed the base branch from
graphite-base/22033
to
merge-train/fairies
benesjan
added
ci-squash-and-merge
backport-to-v4-next
and removed
ci-squash-and-merge
labels
Reverting [bad decision of mine](#21533 (comment)) from a while ago. ## Summary - Copies the version oracle into `aztec_sublib` so it no longer depends on the `aztec` (aztecnr) crate - Removes the `aztec` dependency from `aztec_sublib/Nargo.toml` - Makes `aztec_sublib` fully independent, allowing it to be audited and versioned separately from aztecnr Resolves https://linear.app/aztec-labs/issue/F-466/extract-oracles-mod-specifically-for-aztec-sublib ## Test plan - [x] `nargo check --package fee_juice_contract` compiles successfully - [x] No remaining `aztec::` imports in aztec_sublib 🤖 Generated with [Claude Code](https://claude.com/claude-code)
|
✅ Successfully backported to backport-to-v4-next-staging #22091. |
4 participants
Reverting bad decision of mine from a while ago.
Summary
aztec_sublibso it no longer depends on theaztec(aztecnr) crateaztecdependency fromaztec_sublib/Nargo.tomlaztec_sublibfully independent, allowing it to be audited and versioned separately from aztecnrResolves https://linear.app/aztec-labs/issue/F-466/extract-oracles-mod-specifically-for-aztec-sublib
Test plan
nargo check --package fee_juice_contractcompiles successfullyaztec::imports in aztec_sublib🤖 Generated with Claude Code