Migration notes
Aztec is in full-speed development. Literally every version breaks compatibility with the previous ones. This page attempts to target errors and difficulties you might encounter when upgrading, and how to resolve them.
TBD
[aztec.js] Removal of barrel export
aztec.js is now divided into granular exports, which improves loading performance in node.js and also makes the job of web bundlers easier:
-import { AztecAddress, Fr, getContractInstanceFromInstantiationParams, type Wallet } from '@aztec/aztec.js';
+import { AztecAddress } from '@aztec/aztec.js/addresses';
+import { getContractInstanceFromInstantiationParams } from '@aztec/aztec.js/contracts';
+import { Fr } from '@aztec/aztec.js/fields';
+import type { Wallet } from '@aztec/aztec.js/wallet';
Additionally, some general utilities reexported from foundation have been removed:
-export { toBigIntBE } from '@aztec/foundation/bigint-buffer';
-export { sha256, Grumpkin, Schnorr } from '@aztec/foundation/crypto';
-export { makeFetch } from '@aztec/foundation/json-rpc/client';
-export { retry, retryUntil } from '@aztec/foundation/retry';
-export { to2Fields, toBigInt } from '@aztec/foundation/serialize';
-export { sleep } from '@aztec/foundation/sleep';
-export { elapsed } from '@aztec/foundation/timer';
-export { type FieldsOf } from '@aztec/foundation/types';
-export { fileURLToPath } from '@aztec/foundation/url';
getSenders renamed to getAddressBook in wallet interface
An app could request "contacts" from the wallet, which don't necessarily have to be senders in the wallet's PXE. This method has been renamed to reflect that fact:
-wallet.getSenders();
+wallet.getAddressBook();
Removal of proveTx from Wallet interface
Exposing this method on the interface opened the door for certain types of attacks, were an app could route proven transactions through malicious nodes (that stored them for later decryption, or collected user IPs for example). It also made transactions difficult to track for the wallet, since they could be sent without their knowledge at any time. This change also affects ContractFunctionInteraction and DeployMethod, which no longer expose a prove() method.
msg_sender is now an Option<AztecAddress> type.
Because Aztec has native account abstraction, the very first function call of a tx has no msg_sender. (Recall, the first function call of an Aztec transaction is always a private function call).
Previously (before this change) we'd been silently setting this first msg_sender to be AztecAddress::from_field(-1);, and enforcing this value in the protocol's kernel circuits. Now we're passing explicitness to smart contract developers by wrapping msg_sender in an Option type. We'll explain the syntax shortly.
We've also added a new protocol feature. Previously (before this change) whenever a public function call was enqueued by a private function (a so-called private->public call), the called public function (and hence the whole world) would be able to see msg_sender. For some use cases, visibility of msg_sender is important, to ensure the caller executed certain checks in private-land. For #[only_self] public functions, visibility of msg_sender is unavoidable (the caller of an #[only_self] function must be the same contract address by definition). But for some use cases, a visible msg_sender is an unnecessary privacy leakage.
We therefore have added a feature where msg_sender can be optionally set to Option<AztecAddress>::none() for enqueued public function calls (aka private->public calls). We've been colloquially referring to this as "setting msg_sender to null".
Aztec.nr diffs
Note: we'll be doing another pass at this aztec.nr syntax in the near future.
Given the above, the syntax for accessing msg_sender in Aztec.nr is slightly different:
For most public and private functions, to adjust to this change, you can make this change to your code:
- let sender: AztecAddress = context.msg_sender();
+ let sender: AztecAddress = context.msg_sender().unwrap();
Recall that Option::unwrap() will throw if the Option is "none".
Indeed, most smart contract functions will require access to a proper contract address (instead of a "null" value), in order to do bookkeeping (allocation of state variables against user addresses), and so in such cases throwing is sensible behaviour.
If you want to output a useful error message when unwrapping fails, you can use Option::expect:
- let sender: AztecAddress = context.msg_sender();
+ let sender: AztecAddress = context.msg_sender().expect(f"Sender must not be none!");
For a minority of functions, a "null" msg_sender will be acceptable:
- A private entrypoint function.
- A public function which doesn't seek to do bookkeeping against
msg_sender.
Some apps might even want to assert that the msg_sender is "null" to force their users into strong privacy practices:
let sender: Option<AztecAddress> = context.msg_sender();
assert(sender.is_none());
Enqueueing public function calls
Auto-generated contract interfaces
When you use the #[aztec] macro, it will generate a noir contract interface for your contract, behind the scenes.
This provides pretty syntax when you come to call functions of that contract. E.g.:
Token::at(context.this_address())._increase_public_balance(to, amount).enqueue(&mut context);
In keeping with this new feature of being able to enqueue public function calls with a hidden msg_sender, there are some new methods that can be chained instead of .enqueue(...):
enqueue_incognito-- akin toenqueue, butmsg_senderis set "null".enqueue_view_incognito-- akin toenqueue_view, butmsg_senderis "null".set_as_teardown_incognito-- akin toset_as_teardown, butmsg_senderis "null".
The name "incognito" has been chosen to imply "msg_sender will not be visible to observers".
These new functions enable the calling contract to specify that it wants its address to not be visible to the called public function. This is worth re-iterating: it is the caller's choice. A smart contract developer who uses these functions must be sure that the target public function will accept a "null" msg_sender. It would not be good (for example) if the called public function did context.msg_sender().unwrap(), because then a public function that is called via enqueue_incognito would always fail! Hopefully smart contract developers will write sufficient tests to catch such problems during development!
Making lower-level public function calls from the private context
This is discouraged vs using the auto-generated contract interfaces described directly above.
If you do use any of these low-level methods of the PrivateContext in your contract:
call_public_functionstatic_call_public_functioncall_public_function_no_argsstatic_call_public_function_no_argscall_public_function_with_calldata_hashset_public_teardown_functionset_public_teardown_function_with_calldata_hash
... there is a new hide_msg_sender: bool parameter that you will need to specify.
Aztec.js diffs
Note: we'll be doing another pass at this aztec.js syntax in the near future.
When lining up a new tx, the FunctionCall struct has been extended to include a hide_msg_sender: bool field.
is_public & hide_msg_sender-- will make a public call withmsg_senderset to "null".is_public & !hide_msg_sender-- will make a public call with a visiblemsg_sender, as was the case before this new feature.!is_public & hide_msg_sender-- Incompatible flags.!is_public & !hide_msg_sender-- will make a private call with a visiblemsg_sender(noting that since it's a private function call, themsg_senderwill only be visible to the called private function, but not to the rest of the world).
[cli-wallet]
The deploy-account command now requires the address (or alias) of the account to deploy as an argument, not a parameter
+aztec-wallet deploy-account main
-aztec-wallet deploy-account -f main
This release includes a major architectural change to the system. The PXE JSON RPC Server has been removed, and PXE is now available only as a library to be used by wallets.
[Aztec node]
Network config. The node now pulls default configuration from the public repository AztecProtocol/networks after it applies the configuration it takes from the running environment and the configuration values baked into the source code. See associated Design document
[Aztec.js]
Removing Aztec cheatcodes
The Aztec cheatcodes class has been removed. Its functionality can be replaced by using the getNotes(...) function directly available on our TestWallet, along with the relevant functions available on the Aztec Node interface (note that the cheatcodes were generally just a thin wrapper around the Aztec Node interface).
CLI Wallet commands dropped from aztec command
The following commands used to be exposed by both the aztec and the aztec-wallet commands:
- import-test-accounts
- create-account
- deploy-account
- deploy
- send
- simulate
- profile
- bridge-fee-juice
- create-authwit
- authorize-action
- get-tx
- cancel-tx
- register-sender
- register-contract
These were dropped from aztec and now are exposed only by the cli-wallet command exposed by the @aztec/cli-wallet package.
PXE commands dropped from aztec command
The following commands were dropped from the aztec command:
add-contract: use can be replaced withregister-contracton ourcli-walletget-contract-data: debug-only and not considered important enough to need a replacementget-accounts: debug-only and can be replaced by loading aliases fromcli-walletget-account: debug-only and can be replaced by loading aliases fromcli-walletget-pxe-info: debug-only and not considered important enough to need a replacement
[Aztec.nr]
Introducing self in contracts
Aztec contracts now automatically inject a self parameter into every contract function, providing a unified interface for accessing the contract's address, storage, and execution context.
What is self?
self is an instance of ContractSelf<Context, Storage> that provides:
self.address- The contract's own addressself.storage- Access to your contract's storageself.context- The execution context (private, public, or utility)self.msg_sender()- Get the address of the callerself.emit(...)- Emit events
And soon to be implemented also:
self.call(...)- Make contract calls
How it works
The #[external(...)] macro automatically injects self into your function. When you write:
#[external("private")]
fn transfer(amount: u128, recipient: AztecAddress) {
let sender = self.msg_sender().unwrap();
self.storage.balances.at(sender).sub(amount);
self.storage.balances.at(recipient).add(amount);
}
The macro transforms it to initialize self with the context and storage before your code executes.
Migration guide
Before: Access context and storage as separate parameters
#[external("private")]
fn old_transfer(amount: u128, recipient: AztecAddress) {
let storage = Storage::init(context);
let sender = context.msg_sender().unwrap();
storage.balances.at(sender).sub(amount);
}
After: Use self to access everything
#[external("private")]
fn new_transfer(amount: u128, recipient: AztecAddress) {
let sender = self.msg_sender().unwrap();
self.storage.balances.at(sender).sub(amount);
}
Key changes
- Storage and context access:
Storage and context are no longer injected into the function as standalone variables and instead you need to access them via self:
- let balance = storage.balances.at(owner).read();
+ let balance = self.storage.balances.at(owner).read();
- context.push_nullifier(nullifier);
+ self.context.push_nullifier(nullifier);
Note that context is expected to be use only when needing to access a low-level API (like directly emitting a nullifier).
-
Getting caller address: Use
self.msg_sender()instead ofcontext.msg_sender()- let caller = context.msg_sender().unwrap();
+ let caller = self.msg_sender().unwrap(); -
Getting contract address: Use
self.addressinstead ofcontext.this_address()- let this_contract = context.this_address();
+ let this_contract = self.address; -
Emitting events:
In private functions:
- emit_event_in_private(event, context, recipient, delivery_mode);
+ self.emit(event, recipient, delivery_mode);In public functions:
- emit_event_in_public(event, context);
+ self.emit(event);
Example: Full contract migration
Before:
#[external("private")]
fn withdraw(amount: u128, recipient: AztecAddress) {
let storage = Storage::init(context);
let sender = context.msg_sender().unwrap();
let token = storage.donation_token.get_note().get_address();
// ... withdrawal logic
emit_event_in_private(Withdraw { withdrawer, amount }, context, withdrawer, MessageDelivery.UNCONSTRAINED_ONCHAIN);
}
After:
#[external("private")]
fn withdraw(amount: u128, recipient: AztecAddress) {
let sender = self.msg_sender().unwrap();
let token = self.storage.donation_token.get_note().get_address();
// ... withdrawal logic
self.emit(Withdraw { withdrawer, amount }, withdrawer, MessageDelivery.UNCONSTRAINED_ONCHAIN);
}
Renaming #[internal] as #[only_self]
We want for internal to mean the same as in Solidity where internal function can be called only from the same contract
and is also inlined (EVM JUMP opcode and not EVM CALL). The original implementation of our #[internal] macro also
results in the function being callable only from the same contract but it results in a different call (hence it doesn't
map to EVM JUMP). This is very confusing for people that know Solidity hence we are doing the rename. A true
#[internal] will be introduced in the future.
To migrate your contracts simply rename all the occurrences of #[internal] with #[only_self] and update the imports:
- use aztec::macros::functions::internal;
+ use aztec::macros::functions::only_self;
#[external("public")]
- #[internal]
+ #[only_self]
fn _deduct_public_balance(owner: AztecAddress, amount: u64) {
...
}
Replacing #[private], #[public], #[utility] with #[external(...)] macro
The original naming was not great in that it did not sufficiently communicate what the given macro did.
We decided to rename #[private] as #[external("private")], #[public] as #[external("public")], and #[utility] as #[external("utility")] to better communicate that these functions are externally callable and to specify their execution context. In this sense, external now means the exact same thing as in Solidity, i.e. a function that can be called from other contracts, and that can only be invoked via a contract call (i.e. the CALL opcode in the EVM, and a kernel call/AVM CALL opcode in Aztec).
You have to do the following changes in your contracts:
Update import:
- use aztec::macros::functions::private;
- use aztec::macros::functions::public;
- use aztec::macros::functions::utility;
+ use aztec::macros::functions::external;
Update attributes of your functions:
- #[private]
+ #[external("private")]
fn my_private_func() {
- #[public]
+ #[external("public")]
fn my_public_func() {
- #[utility]
+ #[external("utility")]
fn my_utility_func() {
Dropping remote mutable references to public context
PrivateContext generally needs to be passed as a mutable reference to functions because it does actually hold state
we're mutating. This is not the case for PublicContext, or UtilityContext - these are just marker objects that
indicate the current execution mode and make available the correct subset of the API. For this reason we have dropped
the mutable reference from the API.
If you've passed the context as an argument to custom functions you will need to do the following migration (example from our token contract):
#[contract_library_method]
fn _finalize_transfer_to_private(
from_and_completer: AztecAddress,
amount: u128,
partial_note: PartialUintNote,
- context: &mut PublicContext,
- storage: Storage<&mut PublicContext>,
+ context: PublicContext,
+ storage: Storage<PublicContext>,
) {
...
}
Authwit Test Helper now takes env
The add_private_authwit_from_call_interface test helper available in test::helpers::authwit now takes a TestEnvironment parameter, mirroring add_public_authwit_from_call_interface. This adds some unfortunate verbosity, but there are bigger plans to improve authwit usage in Noir tests in the near future.
add_private_authwit_from_call_interface(
+ env,
on_behalf_of,
caller,
call_interface,
);
Historical block renamed as anchor block
A historical block term has been used as a term that denotes the block against which a private part of a tx has been executed. This name is ambiguous and for this reason we've introduce "anchor block". This naming change resulted in quite a few changes and if you've access private context's or utility context's block header you will need to update your code:
- let header = context.get_block_header();
+ let header = context.get_anchor_block_header();
Removed ValueNote utils
The value_note::utils module has been removed because it was incorrect to have those in the value note package.
For the increment function you can easily just insert the note:
- use value_note::utils;
- utils::increment(storage.notes.at(owner), value, owner, sender);
+ let note = ValueNote::new(value, owner);
+ storage.notes.at(owner).insert(note).emit(&mut context, owner, MessageDelivery.CONSTRAINED_ONCHAIN);
PrivateMutable: replace / initialize_or_replace behaviour change
Motivation:
Updating a note used to require reading it first (via get_note, which nullifies and recreates it) and then calling replace — effectively proving a note twice. Now, replace accepts a callback that transforms the current note directly, and initialize_or_replace simply uses this updated replace internally. This reduces circuit cost while maintaining exactly one current note.
Key points:
replace(self, new_note)(old) →replace(self, f)(new), whereftakes the current note and returns a transformed note.initialize_or_replace(self, note)(old) →initialize_or_replace(self, f)(new), whereftakes anOptionwith the current none, ornoneif uninitialized.- Previous note is automatically nullified before the new note is inserted.
NoteEmission<Note>still requires.emit()or.discard().
Example Migration:
- let current_note = storage.my_var.get_note();
- let new_note = f(current_note);
- storage.my_var.replace(new_note);
+ storage.my_var.replace(|current_note| f(current_note));
- storage.my_var.initialize_or_replace(new_note);
+ storage.my_var.initialize_or_replace(|_| new_note);
This makes it easy and efficient to handle both initialization and current value mutation via initialize_or_replace, e.g. if implementing a note that simply counts how many times it has been read:
+ storage.my_var.initialize_or_replace(|opt_current: Option<Note>| opt_current.unwrap_or(0 /* initial value */) + 1);
- The callback can be a closure (inline) or a named function.
- Any previous assumptions that replace simply inserts a new_note directly must be updated.
Unified oracles into single get_utility_context oracle
The following oracles:
- get_contract_address,
- get_block_number,
- get_timestamp,
- get_chain_id,
- get_version
were replaced with a single get_utility_context oracle whose return value contains all the values returned from the removed oracles.
If you have used one of these removed oracles before, update the import, e.g.:
- aztec::oracle::execution::get_chain_id;
+ aztec::oracle::execution::get_utility_context
and get the value out of the returned utility context:
- let chain_id = get_chain_id();
+ let chain_id = get_utility_context().chain_id();
Note emission API changes
The note emission API has been significantly reworked to provide clearer semantics around message delivery guarantees. The key changes are:
encode_and_encrypt_notehas been removed in favor of callingemitdirectly withMessageDelivery.CONSTRAINED_ONCHAINencode_and_encrypt_note_unconstrainedhas been removed in favor of callingemitdirectly withMessageDelivery.UNCONSTRAINED_ONCHAINencode_and_encrypt_note_and_emit_as_offchain_messagehas been removed in favor of usingemitwithMessageDelivery.UNCONSTRAINED_OFFCHAIN- Note emission now takes a
delivery_modeparameter with the following values:CONSTRAINED_ONCHAIN: For onchain delivery with cryptographic guarantees that recipients can discover and decrypt messages. Uses constrained encryption but is slower to prove. Best for critical messages that contracts need to verify.UNCONSTRAINED_ONCHAIN: For onchain delivery without encryption constraints. Faster proving but trusts the sender. Good when the sender is incentivized to perform encryption correctly (e.g. they are buying something and will only get it if the recipient sees the note). No guarantees that recipients will be able to find or decrypt messages.UNCONSTRAINED_OFFCHAIN: For offchain delivery (e.g. cloud storage) without constraints. Lowest cost since no onchain storage needed. Requires custom infrastructure for delivery. No guarantees that messages will be delivered or that recipients will ever find them.
- The
contextobject no longer needs to be passed to these functions
Example migration:
First you need to update imports in your contract:
- aztec::messages::logs::note::encode_and_encrypt_note;
- aztec::messages::logs::note::encode_and_encrypt_note_unconstrained;
- aztec::messages::logs::note::encode_and_encrypt_note_and_emit_as_offchain_message;
+ aztec::messages::message_delivery::MessageDelivery;
Then update the emissions:
- storage.balances.at(from).sub(from, amount).emit(encode_and_encrypt_note(&mut context, from));
+ storage.balances.at(from).sub(from, amount).emit(&mut context, from, MessageDelivery.CONSTRAINED_ONCHAIN);
- storage.balances.at(from).add(from, change).emit(encode_and_encrypt_note_unconstrained(&mut context, from));
+ storage.balances.at(from).add(from, change).emit(&mut context, from, MessageDelivery.UNCONSTRAINED_ONCHAIN);
- storage.balances.at(owner).insert(note).emit(encode_and_encrypt_note_and_emit_as_offchain_message(&mut context, context.msg_sender());
+ storage.balances.at(owner).insert(note).emit(&mut context, context.msg_sender(), MessageDelivery.UNCONSTRAINED_OFFCHAIN);