Trigger note discovery process (via oracle call) #9372
Assignees
Labels
C-aztec.nr
Component: Aztec smart contract framework
C-pxe
Component: PXE (Private eXecution Envrionment)
team-fairies
Nico's team
Comments
nventuro
added
C-aztec.nr
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 <nicolas.venturo@gmail.com>
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 <nicolas.venturo@gmail.com>
|
Completed in #9623 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We want to be able to initiate the process described in #9380 from inside aztec-nr. When this will be triggered is still up for debate since it depends on things such as how fast syncing is, and how fast syncing at an already-synched state is. If note discovery is indeed quite speedy, then we may want to perform it any time we're about to read notes. Alternatively, we can have it in the unconstrained
view_notes, which is called by the unconstrained getters apps presumably use to e.g. display information on UIs and therefore call frequently.While this process will be triggered by aztec-nr, initially the implementation will reside in PXE. We'll therefore trigger the process by calling a temporary oracle that returns nothing but updates the PXE note database - we expect to eventually move things off from the PXE side of thigs into aztec-nr, until we get to the point where the oracle is fully removed.
The text was updated successfully, but these errors were encountered: