You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This rpc will allow to quickly fetch the list of keys that have been changed/deleted between two different blocks, this is useful for chain analysis tools like an indexer and can then be used for processing.
The api would look like :
/// Returns a storage diff between given block and previous block#[method(name = "state_getStorageDiff", aliases = ["state_getStorageDiffAt"], blocking)]fnstorage_diff(&self,block:Hash,included_prefixes:Option<Vec<StorageKey>>,excluded_prefixes:Option<Vec<StorageKey>>,include_modified_child_tries:Option<bool>) -> RpcResult<(StorageCollection,Option<ChildStorageCollection>)>;
In our first implementation, we chose to read all the keys from the state and loop through the keys to generate the storage diff. Although this worked in our initial testing, when testing with the polkadot chain the performance is very slow (approx 1.5min) when blocks > 1million. We realised this is due to the fact that there is too many keys, iterating and processing each individual key to generate storage diff is too slow for our usecase.
In our latest implementation, we are adding the storage_diff generated during every block import to the backend DB. This ensures that we have the storage_diff for block (X,X-1) always ready without any extra processing. We do not observe any adverse effects on storage, but the rpc response time has improved considerably (1.5min -> 0.002858 secs)
The text was updated successfully, but these errors were encountered:
This rpc will allow to quickly fetch the list of keys that have been changed/deleted between two different blocks, this is useful for chain analysis tools like an indexer and can then be used for processing.
The api would look like :
Example :
curl -sS -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "state_getStorageDiff", "params": ["0xaa254e5ff33843f4abfb2527c7273239f395f7f7da10b6018646f4ae7257f913", "0xb2990969fd7771959f534d3d985603b5632fb6a3faf628d7ba79c564424de7ae"]}' http://localhost:9944/
Result :
Initial Implementation
paritytech/polkadot-sdk#1864
In our first implementation, we chose to read all the keys from the state and loop through the keys to generate the storage diff. Although this worked in our initial testing, when testing with the polkadot chain the performance is very slow (approx 1.5min) when blocks > 1million. We realised this is due to the fact that there is too many keys, iterating and processing each individual key to generate storage diff is too slow for our usecase.
Latest Implementation
traittech/polkadot-sdk#5
In our latest implementation, we are adding the storage_diff generated during every block import to the backend DB. This ensures that we have the storage_diff for block (X,X-1) always ready without any extra processing. We do not observe any adverse effects on storage, but the rpc response time has improved considerably (1.5min -> 0.002858 secs)
The text was updated successfully, but these errors were encountered: