chore: rework nonces (#1210)

[dbanks12]

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:

Why not just use leaf index as nonce?

Followup tasks

• getCommitment should be able to work with pending commitments #1029
• Update old TransparentNote in Noir #1194
• Kernel and ordering circuit should require that 0th nullifier be nonzero #1329
• Kernel should not forward read_request_membership_witnesses via public inputs #1407
• Rename commitment to noteHash everywhere #1408
• Rename "transient/non-transient/pending" notes #1409
• Add tests to ensure failure if an oracle maliciously returns note_header.nonce = 0 for a pre-existing note #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.
• Do merkle membership checks when consuming L1->L2 messages #1383
• The _public_ kernel circuit should inject a nonce into new note hashes #1386
• Log subscriptions #1420
• 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.

Checklist:

• I have reviewed my diff in github, line by line.
• Every change is related to the PR description.
• I have linked this pull request to the issue(s) that it resolves.
• There are no unexpected formatting changes, superfluous debug logs, or commented-out code.
• The branch has been merged or rebased against the head of its merge target.
• I'm happy for the PR to be merged at the reviewer's next convenience.

[iAmMichaelConnor]

Just planting a flag that I've begun reviewing this, to save duplicated efforts from anyone else :)

[iAmMichaelConnor]

Thanks for this! It's clear you've been very meticulous and methodical, which is fantastic for such a fiddly part of the protocol. Only a few minor change requests. Most of my comments can be addressed in later PRs, or are asking questions.