You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/docs-developers/docs/foundational-topics/pxe/execution_hooks.md
+11-2Lines changed: 11 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -82,14 +82,23 @@ For an unconstrained self-send (the recipient is one of the wallet's own account
82
82
83
83
### In Noir tests
84
84
85
-
When testing in Noir, leaving the strategy unset makes `TestEnvironment` fall back to the bare PXE default. Set a strategy when creating the environment to exercise a specific one; it affects message delivery in private executions:
85
+
When testing in Noir, leaving the strategy unset makes `TestEnvironment` fall back to the bare PXE default. Set a strategy
86
+
when creating the environment to exercise a specific one; it affects message delivery in private executions that use the
87
+
default wallet strategy hook. Use `with_default_tag_secret_strategy` to configure the strategy for a specific delivery
Use `with_default_tag_secret_strategy_all_modes` only when the same strategy should apply to both constrained and
100
+
unconstrained delivery. Contract-fixed delivery derivations bypass this default strategy.
101
+
93
102
### In production
94
103
95
104
Pass a `resolveTaggingSecretStrategy` hook when [creating the PXE](#configuring-hooks). It receives a `TaggingSecretStrategyRequest` with the executing contract's address and the message's sender, recipient, and delivery mode (`'constrained'` or `'unconstrained'`), so a wallet can apply per-application or per-recipient policies, or surface the decision to the user, instead of returning a fixed value.
`TestEnvironmentOptions::with_tagging_secret_strategy` is now `with_default_tag_secret_strategy_all_modes` for tests
15
+
that want the same default wallet strategy for both onchain delivery modes. The new naming reflects that these helpers
16
+
configure the TXE default wallet strategy hook; contract-fixed delivery derivations bypass that default.
17
+
18
+
For mode-specific defaults and hook semantics, see the
19
+
[`resolveTaggingSecretStrategy` test helper docs](../foundational-topics/pxe/execution_hooks.md#resolvetaggingsecretstrategy).
20
+
21
+
### [Aztec.nr] L1-to-L2 message consumption takes the secret as an array
22
+
23
+
`PrivateContext::consume_l1_to_l2_message` and `PublicContext::consume_l1_to_l2_message` now take the message secret as an arbitrary-length array `[Field; N]` instead of a single `Field`, so a consumer can derive its secret hash from more than one field. The helpers `compute_secret_hash` and `compute_l1_to_l2_message_nullifier` are likewise now generic over the secret length. A single-field secret behaves exactly as before (the hashes are unchanged for `N = 1`) — just wrap it in an array.
+ let secret_hash = compute_secret_hash([secret]);
35
+
```
36
+
37
+
**Impact**: Contracts that consume L1-to-L2 messages, or that call `compute_secret_hash` / `compute_l1_to_l2_message_nullifier`, must wrap their single-field secret in an array. Already-deployed contracts are unaffected: their unchanged bytecode keeps working, as PXE serves the previous L1-to-L2 membership-witness oracle through a compatibility adaptor.
38
+
39
+
### [Aztec.js]`computeL1ToL2MessageNullifier` replaced by `computeFeeJuiceMessageNullifier`
40
+
41
+
The `@aztec/stdlib` helper `computeL1ToL2MessageNullifier(contract, messageHash, secret)`, which returned the siloed message nullifier, has been removed. Its replacement `computeFeeJuiceMessageNullifier(messageHash, secret)` returns the **unsiloed** nullifier — siloing now happens at the point where the nullifier is looked up. `getL1ToL2MessageWitness` accordingly takes an optional `{ contractAddress, nullifier }` (unsiloed) and silos internally. `computeSecretHash` is unchanged, and `getNonNullifiedL1ToL2MessageWitness` keeps the same signature.
**Impact**: Only affects code calling these low-level messaging helpers directly - most integrations use `getNonNullifiedL1ToL2MessageWitness`, which is unchanged.
53
+
12
54
### [Aztec.js] Account signing keys are no longer derived from the privacy secret
13
55
14
56
Schnorr account signing keys used to be derived from the account's privacy secret (via the now-removed `deriveSigningKey`), which meant the ownership key could be reconstructed from a value the PXE holds. The relationship is now reversed: the signing key is the root, and the privacy secret is derived from it with `deriveSecretKeyFromSigningKey` (exported from `@aztec/accounts/utils`).
0 commit comments