Endpoint(s) to update the client's partial MMR

[hackaugusto]

When a client comes back online, it needs to fetch data from the rollup to update its local state. One of the data structures that has to be update is the client's partial MMR (used to maintain authentication proofs for notes of various blocks).

Tasks

Preview Give feedback

1. Add request/response messages to the store and rpc
2. Add endpoint to query the update for a given block range to the store and rpc
3. Add MMR support to the store's db

[bobbinth]

How are you thinking about the RPC endpoint for this? I'm assuming we'd need to take a list of block numbers as an input (maybe something else as well?), and then return some kind of "mmr delta" which can be applied to a locally-stored partial MMR.

[hackaugusto]

list of block numbers as an input (maybe something else as well?)

I'm thinking the client would send only it's last seen block_number, and the node would send the changes from block_number .. latest.

[bobbinth]

I'm thinking the client would send only it's last seen block_number, and the node would send the changes from block_number .. latest.

Say the client is currently at block 1000 and the chain is at block 2000. Let's also say that the client has notes which it can consume at blocks 1200 and 1500 (for now, I'm assuming that info about these notes comes from a separate endpoint). At the end of the sync, the partial MMR we want to end up with would be with peaks up to block 2000, and then extra nodes so that we can build authentication paths to leaves at positions 1200 and 1500.

Would we have another endpoint to retrieve these authentication paths?

[hackaugusto]

Would we have another endpoint to retrieve these authentication paths?

It should be the same endpoint you mentioned previously

(for now, I'm assuming that info about these notes comes from a separate endpoint)

Or am I missing something?

[bobbinth]

It should be the same endpoint you mentioned previously

Let's think through that endpoint as well because I think how that endpoint works may have implications for this endpoint.

One thing to consider is that there are two separate Merkle authentication paths needed to prove that a note is in the MMR:

1. Path from the block header's note_root to the note node. This path is stable - e.g., once a note is added to the block it never changes. My current thinking is that for these we'll store fully-materialized (but compressed) paths in the database.
2. Path from a relevant MMR peak to the block header. This path is not stable - it changes together with the MMR peaks.

Originally, I was thinking that the user would get the first path from get_notes endpoint, and the second path would come from either this endpoint or something else. But maybe there are other options?

[hackaugusto]

superseeded by #43