Do we have either of these features implemented yet, and/or is there a plan to do so? The nonce rework (recently finished) will make these features pretty important.
nonce = hash(first_nullifier, noteIndexInTx)where
first_nullifieris the tx-hash and
noteIndexInTxis the index of the
noteHashin the TX’s
- Note: this array omits “transient” noteHashes that were nullified/squashed in the same TX. “Transient” notes are not assigned a nonce.
noteHash: direct hash of a note preimage
innerNoteHash: a noteHash siloed by storage slot
siloedNoteHash: an innerNoteHash siloed by contract address
uniqueSiloedNoteHash: a siloedNoteHash hashed with nonce
NoteProcessor: client-side component that listens for new L2 blocks and attempts to decrypt TX logs that target the current user. Loads any successfully decrypted notes into client’s DB.
NonNativeToken contract as an example.
I create a commitment/noteHash in public that I later want to claim in private. I know the note preimage (amount, secretHash), so I can compute the noteHash easily. But today all that ends up in L1 calldata for my note is the final uniqueSiloedNoteHash. The nonce used to make this noteHash (created in a public function) unique can only be known by the Sequencer/Prover since they will execute the public section of the transaction. If at some later time I want to claim my funds in private, I’ll need to know the uniqueSiloedNoteHash for my note in order to nullify it.
Well I could record the tx-hash alongside the secret and then when I want to claim in private I can find the TX’s L1 calldata, but I still won’t know which final noteHash (unique / hashed with nonce) corresponds to my note. So, the public function could emit an unencrypted log that includes the my noteHash (non-unique) such that I can determine the nonce assigned to my noteHash along with the uniqueSiloedNoteHash. I can subscribe to unencrypted logs (for that contract) that include my noteHash and can then use that information to claim/redeem the note privately when I need to nullify the uniqueSiloedNoteHash.
These challenges can also be relevant to noteHashes/commitments created in private functions (see
claim functions). Basically if a note is not encrypted in calldata for decryption by the receiver, it will not be successfully decrypted by the receiver’s note-processor and therefore will not end up in their DB. So, the note creator will need to communicate the commitment nonce to the receiver (which, in the ZkTokenContract example, can be communicated alongside the “secret”/note-preimage).
More info on nonce rework in this PR.
“We originally did this in Aztec Connect, but then we encountered problems when trying to chain transactions (i.e. squash nullifiers and commitments between multiple txs in the same rollup). If I want to create tx1 and tx2 in the same rollup block, and tx2 spends a note which came from tx1, then I need to know the nonce for the note in order to nullify it. I don’t want to wait for the sequencer to tell me the leafIndex before I can start generating a proof for tx2. So we can’t use the leafIndex, because I don’t know it, because I don’t know where the sequencer will sequence my tx1 in the block. Also, tx1 might get put in one rollup block, and tx2 might not get included until some later rollup block, in which case the nullifier for the note has to be a proper nullifier (with some kind of nonce - not a half-baked transient nullifier), because it could end up in the nullifier tree forever.” - @Mike