Skip to content

feat: merge-train/fairies-v5#24223

Open
AztecBot wants to merge 8 commits into
v5-nextfrom
merge-train/fairies-v5
Open

feat: merge-train/fairies-v5#24223
AztecBot wants to merge 8 commits into
v5-nextfrom
merge-train/fairies-v5

Conversation

@AztecBot

@AztecBot AztecBot commented Jun 22, 2026

Copy link
Copy Markdown
Collaborator

BEGIN_COMMIT_OVERRIDE
feat: make node.getContract take an optional reference block (#24207)
feat(aztec-nr): wire constrained message delivery (#23866)
fix(pxe): respect slot boundaries in oracle (de)serialization (#24211)
feat: allow registration of raw shared secrets (#23708)
feat(e2e): constrained delivery and discovery with two PXEs (#24228)
refactor(stdlib)!: rename unsafe AztecAddress constructors to *Unsafe (#24230)
fix(txe): correct AVM oracle registry types for call and success_copy (#24203)
feat(aztec-nr): make handshake tagging secrets mode agnostic (#24241)
END_COMMIT_OVERRIDE

PXE needs the class id at the anchor block, but the node only exposed
the latest one. This forced PXE to reimplement the class id detection by
raw reads of the trees combined with delayed public mutable
interpretation of said data, which unnecessarily coupled PXE and the
registry contracts. With this PR we simply query the data from the node,
which will always be available if there's an upgrade, making the
original class a safe fallback.

The new `referenceBlock` argument is optional and defaults to
`'latest'`, with `address` kept as the first argument, so the change is
backwards compatible: existing single-argument `getContract(address)`
callers keep working unchanged, and only PXE's class-id resolution
passes an explicit anchor block.

Supersedes #24205, addressing the review feedback to make the new
argument optional.

Fixes #15170

---------

Co-authored-by: Nicolás Venturo <nicolas.venturo@gmail.com>
Fixes
[F-669](https://linear.app/aztec-labs/issue/F-669/aztec-nr-calculate-secret-and-index-helper-for-constrained-delivery)
Fixes
[F-670](https://linear.app/aztec-labs/issue/F-670/aztec-nr-send-constrained-msg-helper-that-emits-a-constrained)

## The change

- Adds constrained-delivery helpers that resolve or bootstrap the
app-siloed handshake secret, seed same-tx index reuse, validate index
`0` against the standard HandshakeRegistry, and constrain `index > 0`
through the previous chain nullifier.
- Wires constrained private message delivery to derive constrained log
tags from the resolved `(secret, index)` pair and emit the current
constrained-message nullifier.
- Keeps constrained logs from being squashed with note hashes so
recipient discovery can advance the per-secret index chain.
- Authorizes the standard HandshakeRegistry utility reads needed by the
flow.
- Adds TXE, snapshot, and e2e coverage for bootstrap, reuse, index
advancement, missing prior-nullifier failure, invalid API combinations,
and standard-registry constrained delivery.

Large portion of the diff is tests. 


[F-741](https://linear.app/aztec-labs/issue/F-741/getsharedsecrets-throws-no-public-key-during-recipient-discovery-for-a)
follow-up for the test skipped in
[fd07996](fd07996).

## Concurrency / batching constraint (worth a look)

Pinning the e2e tests surfaced a sequencing constraint in constrained
delivery that reviewers should sanity-check:

- **Parallel sends on one `(sender, recipient, secret)` chain collide.**
Each send is keyed on an incrementing index, so two sends fired as
separate parallel txs read the same index and one tx is rejected.
Distinct recipients are distinct chains and parallelize fine. Pinned as
`it.failing` (documents the limit; flips green if parallel sends ever
become supported).
- **Same-chain sends _can_ be batched into one tx**, but only onto an
already-committed handshake. A later send discharges its predecessor
check against a same-tx pending nullifier. Works both via a single
contract call (`emit_two_events`) and client-side `BatchCall`.
- **Batching onto a brand-new chain does not reuse, it re-handshakes.**
The reuse-vs-bootstrap decision in
`get_or_create_app_siloed_handshake_secret` is a utility call reading
_committed_ state, so a bootstrap earlier in the same tx is invisible
and the later send mints a fresh secret on a separate chain (next index
lands at 1, not 2). A new recipient therefore needs one landed tx to
establish the chain before sends can be batched onto it. This is why the
batched tests seed the handshake first.

All four behaviors are pinned in `e2e_constrained_delivery.test.ts`; the
rationale lives in the module doc and on
`get_or_create_app_siloed_handshake_secret`. Follow-up: allowing utility
functions to execute against combined committed + pending transaction
state is tracked in
[F-238](https://linear.app/aztec-labs/issue/F-238/allow-execution-of-utility-functions-touched-by-pending-transactions).

---------

Co-authored-by: AztecBot <tech@aztec-labs.com>
Co-authored-by: Nicolas Chamo <nicolas@chamo.com.ar>

@ludamad ludamad left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 Auto-approved

@AztecBot AztecBot added this pull request to the merge queue Jun 23, 2026
@AztecBot

Copy link
Copy Markdown
Collaborator Author

🤖 Auto-merge enabled after 4 hours of inactivity. This PR will be merged automatically once all checks pass.

@github-merge-queue github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Jun 23, 2026
@benesjan benesjan added this pull request to the merge queue Jun 23, 2026
@github-merge-queue github-merge-queue Bot removed this pull request from the merge queue due to a conflict with the base branch Jun 23, 2026
nchamo and others added 2 commits June 23, 2026 14:59
## Summary

Switches handshake-derived tagging secrets to be mode agnostic across
constrained and unconstrained delivery.

- Removes delivery mode specialization from handshake secrets and
registry handling
- Updates provided secret processing so PXE scans handshake secrets
across both on-chain tag domains
- Adds/updates Noir, PXE, and e2e coverage for mode-agnostic handshake
behavior. The meaningful tests of multiple mode scanning functionality
is contained in the TS.

---------

Co-authored-by: Nicolas Chamo <nicolas@chamo.com.ar>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants