-
Notifications
You must be signed in to change notification settings - Fork 234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The _public_ kernel circuit should inject a nonce into new note hashes #1386
Closed
Tracked by
#2783
Labels
T-fix
Type: fix this. Not quite a bug.
Comments
iAmMichaelConnor
pushed a commit
that referenced
this issue
Aug 3, 2023
# Description The way nonces work now, there can be inconsistencies in nonce assignment in the simulator vs the private kernel. Furthermore, you cannot know during function execution what the full set of commitments will be for the whole TX as some new commitments may be nullified and squashed. But we still want the ability to determine nonces and therefore uniqueNoteHashes from L1 calldata alone. I am sure I am not explaining all of the issues well enough, but it was determined that the current nonce paradigm will not work and therefore we must rework it. Rework nonces so that siloing by contract address happens first and uniqueness comes later. For now, nonces are injeced by the private ordering circuit (vs suggestion which was base rollup circuit). Pending notes and their reads have no nonces when processed in kernel. The public kernel (and therefore all commitments created in public functions) does not use nonces. Here was Mike's proposal for the rework: ![image](https://github.com/AztecProtocol/aztec-packages/assets/47112877/7b20c886-1e92-452c-a886-c3da5ed64e17) Why not just use leaf index as nonce? ![image](https://github.com/AztecProtocol/aztec-packages/assets/47112877/e6337107-ac93-4a3b-b83c-27213cb5133d) ## Followup tasks * #1029 * #1194 * #1329 * #1407 * #1408 * #1409 * #1410 * Future enhancement: The root rollup circuit could insert all messages at the very beginning of the root rollup circuit, so that txs within the rollup can refer to that state root and read L1>L2 messages immediately. * #1383 * #1386 * We should implement subscription / polling methods for Aztec logs * We should maybe write rpc functions which allow calldata to be subscribed-to, keyed by tx_hash. * If a dapp wants to write a note from a public function, a lot of honus will be on a dapp developer to retain preimage information, query the blockchain, and derive the nonce. We should provide some examples to demonstrate this pattern.
AztecBot
pushed a commit
to AztecProtocol/docs
that referenced
this issue
Aug 3, 2023
# Description The way nonces work now, there can be inconsistencies in nonce assignment in the simulator vs the private kernel. Furthermore, you cannot know during function execution what the full set of commitments will be for the whole TX as some new commitments may be nullified and squashed. But we still want the ability to determine nonces and therefore uniqueNoteHashes from L1 calldata alone. I am sure I am not explaining all of the issues well enough, but it was determined that the current nonce paradigm will not work and therefore we must rework it. Rework nonces so that siloing by contract address happens first and uniqueness comes later. For now, nonces are injeced by the private ordering circuit (vs suggestion which was base rollup circuit). Pending notes and their reads have no nonces when processed in kernel. The public kernel (and therefore all commitments created in public functions) does not use nonces. Here was Mike's proposal for the rework: ![image](https://github.com/AztecProtocol/aztec-packages/assets/47112877/7b20c886-1e92-452c-a886-c3da5ed64e17) Why not just use leaf index as nonce? ![image](https://github.com/AztecProtocol/aztec-packages/assets/47112877/e6337107-ac93-4a3b-b83c-27213cb5133d) ## Followup tasks * AztecProtocol/aztec-packages#1029 * AztecProtocol/aztec-packages#1194 * AztecProtocol/aztec-packages#1329 * AztecProtocol/aztec-packages#1407 * AztecProtocol/aztec-packages#1408 * AztecProtocol/aztec-packages#1409 * AztecProtocol/aztec-packages#1410 * Future enhancement: The root rollup circuit could insert all messages at the very beginning of the root rollup circuit, so that txs within the rollup can refer to that state root and read L1>L2 messages immediately. * AztecProtocol/aztec-packages#1383 * AztecProtocol/aztec-packages#1386 * We should implement subscription / polling methods for Aztec logs * We should maybe write rpc functions which allow calldata to be subscribed-to, keyed by tx_hash. * If a dapp wants to write a note from a public function, a lot of honus will be on a dapp developer to retain preimage information, query the blockchain, and derive the nonce. We should provide some examples to demonstrate this pattern.
I believe this is blocked by #1420 |
also referenced in #4891 |
I still think it needs to be tackled, and I reckon your team (Jan) is now perfectly placed to tackle it (whereas it'd be a big context-switch for david) :) |
This was referenced Jun 20, 2024
This was referenced Jul 3, 2024
Merged
superstar0402
added a commit
to superstar0402/aztec-nr
that referenced
this issue
Aug 16, 2024
# Description The way nonces work now, there can be inconsistencies in nonce assignment in the simulator vs the private kernel. Furthermore, you cannot know during function execution what the full set of commitments will be for the whole TX as some new commitments may be nullified and squashed. But we still want the ability to determine nonces and therefore uniqueNoteHashes from L1 calldata alone. I am sure I am not explaining all of the issues well enough, but it was determined that the current nonce paradigm will not work and therefore we must rework it. Rework nonces so that siloing by contract address happens first and uniqueness comes later. For now, nonces are injeced by the private ordering circuit (vs suggestion which was base rollup circuit). Pending notes and their reads have no nonces when processed in kernel. The public kernel (and therefore all commitments created in public functions) does not use nonces. Here was Mike's proposal for the rework: ![image](https://github.com/AztecProtocol/aztec-packages/assets/47112877/7b20c886-1e92-452c-a886-c3da5ed64e17) Why not just use leaf index as nonce? ![image](https://github.com/AztecProtocol/aztec-packages/assets/47112877/e6337107-ac93-4a3b-b83c-27213cb5133d) ## Followup tasks * AztecProtocol/aztec-packages#1029 * AztecProtocol/aztec-packages#1194 * AztecProtocol/aztec-packages#1329 * AztecProtocol/aztec-packages#1407 * AztecProtocol/aztec-packages#1408 * AztecProtocol/aztec-packages#1409 * AztecProtocol/aztec-packages#1410 * Future enhancement: The root rollup circuit could insert all messages at the very beginning of the root rollup circuit, so that txs within the rollup can refer to that state root and read L1>L2 messages immediately. * AztecProtocol/aztec-packages#1383 * AztecProtocol/aztec-packages#1386 * We should implement subscription / polling methods for Aztec logs * We should maybe write rpc functions which allow calldata to be subscribed-to, keyed by tx_hash. * If a dapp wants to write a note from a public function, a lot of honus will be on a dapp developer to retain preimage information, query the blockchain, and derive the nonce. We should provide some examples to demonstrate this pattern.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We're not-yet injecting nonces into commitments which have been created by public functions.
@dbanks12 is currently working on doing this for private functions.
When a public function wants to insert a new note hash into the utxo tree, the public kernel circuit should inject a nonce (in the same way as is done for private functions).
inner_note_hash
with somepreimage
.tx_hash
of the tx.tx_hash
, by subscribing to an event or polling. (This is a separate TODO!!!)tx_hash
is seen, the accompanying L1 calldata for this tx will include:unique_siloed_note_hashes
tx_hash
,logs
, and already-known preimage data, the dapp can learn thenonce
of this commitment:Brute-forcing doesn't seem too terrible. If you already know the
tx_hash
, you'll only be trialling as many commitments as can be created by a single tx.The text was updated successfully, but these errors were encountered: