Add notes to DB via oracle call #9370
Assignees
Labels
Comments
nventuro
added
C-pxe
Closed
Thunkar
added a commit
that referenced
this issue
Nov 7, 2024
Closes: #9371 #9370 #9372 Blindly moves the logic in `note_processor.ts` to the `simulator_oracle`, so retrieved logs can be processed and injected in PXE's db. This approach has several problems: - We have to trigger a process from an oracle, but the thing itself requires a simulator to call `compute_note_hash_and_nullifier`. This either implies moving lot of stuff into `client_execution_context` (namely, the key store), or a chicken and egg problem with `simulator_oracle` (we need a simulator in the oracle that is provided to a simulator). Right now a very ugly solution is adopted, instantiating a new simulator in place. - ~~Are deferred notes even necessary now?~~ No, will be removed in #9575 - Is there an alternative to passing the the `dataStartIndexForTx` all the way from the node to compute the note index? (this is not too bad IMO) - Can the logic in the processor be simplified? - Is there a better place to put this code that still allows us to initiate the process from `aztec.nr`? --------- Co-authored-by: Nicolás Venturo <[email protected]>
AztecBot
pushed a commit
to AztecProtocol/aztec-nr
that referenced
this issue
Nov 8, 2024
Closes: AztecProtocol/aztec-packages#9371 AztecProtocol/aztec-packages#9370 AztecProtocol/aztec-packages#9372 Blindly moves the logic in `note_processor.ts` to the `simulator_oracle`, so retrieved logs can be processed and injected in PXE's db. This approach has several problems: - We have to trigger a process from an oracle, but the thing itself requires a simulator to call `compute_note_hash_and_nullifier`. This either implies moving lot of stuff into `client_execution_context` (namely, the key store), or a chicken and egg problem with `simulator_oracle` (we need a simulator in the oracle that is provided to a simulator). Right now a very ugly solution is adopted, instantiating a new simulator in place. - ~~Are deferred notes even necessary now?~~ No, will be removed in AztecProtocol/aztec-packages#9575 - Is there an alternative to passing the the `dataStartIndexForTx` all the way from the node to compute the note index? (this is not too bad IMO) - Can the logic in the processor be simplified? - Is there a better place to put this code that still allows us to initiate the process from `aztec.nr`? --------- Co-authored-by: Nicolás Venturo <[email protected]>
AztecBot
pushed a commit
to AztecProtocol/aztec-nr
that referenced
this issue
Nov 15, 2024
Closes: AztecProtocol/aztec-packages#9370 Closes AztecProtocol/aztec-packages#9575 Closes AztecProtocol/aztec-packages#9786 Replaces the note processor with the tagging approach, supporting a sliding window of indexes and partial notes --------- Co-authored-by: Nicolás Venturo <[email protected]> Co-authored-by: Santiago Palladino <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Notes are currently added to the database when discovered by the note processor as it performs trial decryption of all logs and eventually calls
compute_note_hash_and_nullifier. This will be replaced in favor of an approach in which some process finds out about a new note and asks PXE to store it, which needs to validate existence etc.Note that this is not the same as
notify_note_created, which only adds notes to a temporary cache to assist during witness generation.Since this will eventually become an oracle call, it'd be good to have all of the infrastructure in place and call this as if we were doing it from aztec.nr, so that the ts -> noir migration is painless. The call would behave fairly similar to the current flow (check for existence in the note tree etc), except it will receive note contents plus note hash and nullifier, instead of having to call
compute_note_hash_and_nullifier.The text was updated successfully, but these errors were encountered: