search

paritytech / json-rpc-interface-spec

30 stars 3 forks source link

Add storage subscriptions on the peer-to-peer layer #10

Open tomaka opened 2 years ago

tomaka commented 2 years ago

I'm opening this issue here because this should lead to a new JSON-RPC function, but some changes to Substrate's networking would also be needed.

The idea is: instead of downloading storage items at each block, a light client can ask a full node to report when a certain list of storage items has been modified. This can maybe be done in the block announce, or maybe this can be done in a request-response way. Care should be taken to avoid race conditions between block announces and storage changes announces.

Note that when a full node says that a storage item has been modified, we should only treat this as a hint. The storage item still needs to be downloaded and verified with a Merkle proof, to make sure that it has actually changed.

In the same way, if a full node says that a storage item has not been modified, it's not an actual guarantee that it hasn't been modified. However if we're connected to multiple randomly-chosen peers, we can assume that at least one will properly report changes. Additionally we could consider periodically downloading the storage item anyway, in case all our peers are actually malicious.

All in all, however, this should always be used only as a hint, for example if it is acceptable to show an information that is outdated. If a user wants to be sure that a certain storage item has a certain value (e.g. the balance on their account), there is no other choice but to download the storage value and check the Merkle proof.

tomaka commented 2 years ago

This interacts with https://github.com/paritytech/json-rpc-interface-spec/issues/4

rphmeier commented 2 years ago

The storage item still needs to be downloaded and verified with a Merkle proof, to make sure that it has actually changed.

&

In the same way, if a full node says that a storage item has not been modified, it's not an actual guarantee that it hasn't been modified. However if we're connected to multiple randomly-chosen peers, we can assume that at least one will properly report changes.

Light clients can also randomly sample blocks to explicitly fetch the merkle proof & storage item every once in a while in order to check their peers aren't leaving out info. That way, you can figure out if a full node is leaving things out without fetching the storage item at every block. You can probably save like 75-90% of bandwidth that way, although you'd filter out lying peers a bit slower.