Endpoint for note syncing

[bobbinth]

As described in 0xPolygonMiden/miden-client#405 (comment), it may be beneficial to have an endpoint which works similar to the SyncState but is limited only to retrieving note data.

The endpoint could be called NoteSync and could look as follows:

Parameters

• block_num: uint32 – send notes created starting at this block.
• note_tags: [uint32] – send notes matching these tags.

Returns

• chain_tip: uint32 – number of the latest block in the chain.
• block_header: BlockHeader – block header of the block with the first note matching the specified criteria.
• mmr_delta: MmrDelta – data needed to update the partial MMR from request.block_num + 1 to response.block_header.block_num.
• notes: [NoteSyncRecord] – a list of all notes together with the Merkle paths from response.block_header.note_root.

One open question is how exactly we should handle the mmr_delta here (or if there is a better way to send this info to the client).

[Mirko-von-Leipzig]

I'm trying to understand how this gets used. Am I understanding correctly that the response only returns the delta up to the first matching block?

And that chain_tip is only there to suggest to the user that he ought to call the method again with request.block_num = response.block_header.block_num until he catches the notes he is interested in?

[Mirko-von-Leipzig]

One open question is how exactly we should handle the mmr_delta here (or if there is a better way to send this info to the client).

Does this also apply to the state sync endpoint? If not, what makes the two queries different aside from less data?

[bobbinth]

I'm trying to understand how this gets used. Am I understanding correctly that the response only returns the delta up to the first matching block?

Correct.

And that chain_tip is only there to suggest to the user that he ought to call the method again with request.block_num = response.block_header.block_num until he catches the notes he is interested in?

Also correct. The motivation for this is to provide a sort of "context-independent pagination". We can improve on this by streaming responses as discussed in #174. Also, I think we should impose a limit on the span of time covered by a response (e.g., 1 epoch). This way, no response will cover more than 1 epoch which could simplify dealing with this on the database level in the future.

Does this also apply to the state sync endpoint? If not, what makes the two queries different aside from less data?

Yes - the main (only?) difference is that state sync also deals with accounts and nullifiers, but note sync is purely for syncing notes.

[bobbinth]

Closed by #424.