Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Add nonce to note hash. #1019

Closed
LeilaWang opened this issue Jul 11, 2023 · 2 comments · Fixed by #1084
Closed

Add nonce to note hash. #1019

LeilaWang opened this issue Jul 11, 2023 · 2 comments · Fixed by #1084
Assignees
Labels
T-feature-request Type: Adding a brand new feature (not to be confused with improving an existing feature).

Comments

@LeilaWang
Copy link
Collaborator

No description provided.

@iAmMichaelConnor
Copy link
Contributor

iAmMichaelConnor commented Jul 11, 2023

A nullifier is often hash(commitment, secret_key). Such a hash will only be unique if the commitment is unique. So how do we ensure commitments are unique? Some private notes might contain "randomness", but we cannot guarantee that such randomness is unique (indeed, there's nothing stopping a sender from using the same 'random' value twice!). So we need a 'nonce' - a piece of information which can guarantee all notes are unique.

A simple nonce would be:

nonce = hash(new_nullifiers[0], i)

Which would be calculated by the kernel circuit. Where new_nullifiers is an array of all nullifiers so-far created across the entire tx (not just the single function call currently being processed by the kernel circuit). And i is the index of the new commitment (into which this nonce will be injected) in the entire tx's new_commitments array.

Note: an account contract SHOULD always emit a hash of the 'tx request' as the 0th nullifier of the tx (@spalladino please can you confirm?), so there should always be a new_nullifiers[0].
Note: Given that there are plans to squash new commitments which get spent in later function calls, there's still a chance of collisions if we're not careful with how i is calculated. The computation of i should not adjust for the squashing of new commitments.

Example (in pseudocode, and with naming which doesn't quite match the actual code!)

Kernel:

// let i = kernel.start.new_commitments.length; // Maybe don't do this, because this length might have been reduced through squashing in previous kernel iterations.
let i = kernel.start.nonce_index; // Maybe track a nonce index, which doesn't get warped by squashing.
kernel.end.nonce_index = i + call.public_inputs.new_commitments.length();
let nonce;
let unique_commitment;
let siloed_commitments = [];
for j in 0..new_commitments.length() {
    nonce = pedersen({ kernel.end.new_nullifiers[0], i}, NONCE_GENERATOR_INDEX);
    unique_commitment = pedersen(new_commitments[j], nonce, NONCE_INJECTION_GENERATOR_INDEX);
    siloed_commitments[j] = pedersen(unique_commitment, contract_address, OUTER_COMMITMENT_GENERATOR_INDEX);
    ++i;
}

// Maybe some squashing of siloed_commitments happens, but the kernel.end.nonce_index is unaffected.

kernel.end.new_commitments = siloed_commitments;

@iAmMichaelConnor iAmMichaelConnor added the T-feature-request Type: Adding a brand new feature (not to be confused with improving an existing feature). label Jul 11, 2023
@spalladino
Copy link
Collaborator

spalladino commented Jul 11, 2023

Note: an account contract SHOULD always emit a hash of the 'tx request' as the 0th nullifier of the tx (@spalladino please can you confirm?), so there should always be a new_nullifiers[0].

This is actually handled by the initial kernel circuit, who manually injects that nullifier:

// Since it's the first iteration, we need to push the the tx hash nullifier into the `new_nullifiers` array
array_push(builder, public_inputs.end.new_nullifiers, private_inputs.tx_request.hash());

@LeilaWang LeilaWang mentioned this issue Jul 15, 2023
6 tasks
@github-project-automation github-project-automation bot moved this from Todo to Done in A3 Jul 19, 2023
@iAmMichaelConnor iAmMichaelConnor removed this from A3 Jul 26, 2023
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
T-feature-request Type: Adding a brand new feature (not to be confused with improving an existing feature).
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants