substrate
substrate copied to clipboard
paritytech
Key storage proof v2
This PR adds light client call as describe in https://github.com/paritytech/substrate/issues/10623 .
I only diverge from proposed spec at https://github.com/w3f/polkadot-spec/issues/590 by renaming required bytes hash = 1; in child trie description to required bytes name = 1; : so it is the same as the former storage_key but without prefixing.
Using child trie root hash sounds like a good idea but is not consistent with specifying a block number in the request.
When writing it I also did wonder if we should allow doing the query on multiple child trie (would be a bit of change in the format but pretty ok).
I also did remove the storage cache from the source (should have been removed already I think).
I also did remove the storage cache from the source (should have been removed already I think).
Yes, looks like some bad merge brought it back.
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.
Opened https://github.com/w3f/PPPs/pull/5
I've added a includeDescendants field for keys, for which the server must also include the list of all children of that key.
This is important in order to implement for example state_getKeys on a light client.
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.
Switched to "In Progress", as I will also integrate proposed changes from https://github.com/w3f/PPPs/pull/5 (prefix range query, restart and possibly ordering of keys).
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.