Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
tomaka opened this issue Mar 9, 2022 · 2 comments
Open

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

tomaka opened this issue Mar 9, 2022 · 2 comments

Comments

@tomaka
Copy link
Contributor

tomaka commented Mar 9, 2022

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
Copy link
Contributor Author

tomaka commented Mar 9, 2022

This interacts with #4

@rphmeier
Copy link

rphmeier commented Mar 9, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants