sp-state-machine: Read value from backend when writing the first time #6230
+90
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a first step into fixing #6020. The underlying problem for parachains is that when calling
storage_root
, values that are written, will need to be looked up in the trie. This is required to insert the value or to remove it. The problem is that this lookup instorage_root
increases the storage proof size, but storage reclaim for example can not track these lookups. This means that with storage reclaim it is possible to include more transactions than what the block should be allowed to include.This pull request reads a key from the backend the first time it is written. This results in taking into account what
storage_root
is doing at the end of a block. However, this may still skips reading one extranode
(depending on the trie structure). Skipping only onenode
is far less problematic than skipping the entire lookup. A future pull request will improve this further to take the entire operation ofstorage_root
into account.For chains that are not recording a storage proof, they will still do this extra backend read. However, this read will end up in the cache. At the end of the block the key will be read again as part of
storage_root
, but served from the cache. So, there is no downside of this.