Remove the `SynState` endpoint

[bobbinth]

Our current SynState endpoint does a bit too much, and I think we should be able to replace it with other existing endpoints. Specifically:

• SyncTransactions could be used to get all information about updates performed on a specific set of accounts.
• SyncNotes could be used to get information on all "incoming" notes for a specific set of accounts.
• SyncNullifiers could be used to get information about the status of the notes that a client produced.

The only thing that I think is missing is the ability to sync chain MMR. So, we may need to add an endpoint for this, but it should be pretty straight-forward.

One open question is whether getting rid of the SyncState endpoint will make things much more difficult on the client. cc @igamigo.

[igamigo]

One open question is whether getting rid of the SyncState endpoint will make things much more difficult on the client. cc @igamigo.

Not really, disregarding the fact that we would need an MMR delta endpoint (we are most of the way there already). The other thing is that this does add roundtrips to the node which is not great, but probably not bad either.
It might be a good idea to add block_to parameters to some of these endpoints if they don't have it, as the fact that data comes separately now makes it so the chain tip may change in the middle of the calls (data can also be easily discarded locally most of the time - except for MMR deltas - but I think it's better overall to have these as parameters).

[bobbinth]

The other thing is that this does add roundtrips to the node which is not great, but probably not bad either.

Agreed - though, with our current SyncState endpoint, we can't really bound the size of the response that well (we try to do it in terms of notes, but if there were lots of account updates at the same time, we may get in trouble). So, it is a sort of a trade off.

we would need an MMR delta endpoint

I think this could be a pretty simple endpoint. The request could look something like:

message SyncChainMmrRequest {
    BlockRange block_range = 1;
    repeated BlockNumber track_blocks = 2;
}

And the response could be:

message SyncChainMmrResponse {
    PaginationInfo pagination_info = 1;
    MmrDelta mmr_delta = 2;
    repeated BlockHeader block_headers = 3;
}

It might be a good idea to add block_to parameters to some of these endpoints if they don't have it,

AFAIK, all 3 endpoints I mentioned SyncTransactions, SyncNotes, and SyncNullifiers) take BlockRange as a part of the input and return PaginationInfo as a part of the output - so, I think we should be covered.

[Mirko-von-Leipzig]

I'm very much in favor of simpler and more limited endpoints. Round-trips for simpler results is a trade-off I'll make every day of the week. Simpler endpoints also makes caching, replication, scaling etc much easier to implement.

[igamigo]

I think this could be a pretty simple endpoint. The request could look something like:

message SyncChainMmrRequest {
    BlockRange block_range = 1;
    repeated BlockNumber track_blocks = 2;
}

Is track_blocks needed here? I guess it can make for a leaner response? But I don't think we have an equivalent in the current sync state endpoint.

I'm very much in favor of simpler and more limited endpoints. Round-trips for simpler results is a trade-off I'll make every day of the week. Simpler endpoints also makes caching, replication, scaling etc much easier to implement.

Yeah, I agree. Overall it's much simpler to manage simpler endpoints.

[bobbinth]

I think this could be a pretty simple endpoint. The request could look something like:
message SyncChainMmrRequest {
BlockRange block_range = 1;
repeated BlockNumber track_blocks = 2;
}

Is track_blocks needed here? I guess it can make for a leaner response? But I don't think we have an equivalent in the current sync state endpoint.

I was thinking that we'd send a list of blocks for which we want to get authentication paths - in case we get notes for these blocks via a side-channel - but maybe a different endpoint would be better for this? (e.g., something that gets an authentication path for a single block).

Also, looking at SyncNotes endpoint, seems like this already gives us authentication paths for the downloaded notes. So, maybe this would do the bulk of the work. And then, the only thing SyncChainMmr would need to do is bring back the delta to update the local MMR to the latest state but w/o any new authentication paths - right?