State trie V1 to V0

[cheme]

@dimartiro , since the substrate repo got archived to switch to polkadot sdk, I couldn't reply to paritytech/substrate#11607 (comment) on the discussion. So I am opening this one here simply to reply (feel free to close/move it when you get this reply if not in the right place).

Substrate code allows going from v1 to v0 (I remember doing it by error in the past on testnet).
But clearly that is not something that should be done ever.

I think you are always assuming that we cannot go back from V1 to V0, is that correct?

I think we should assume it yes, there is no use in going back to V0.

What happen if we apply a runtime change that's start using V1 (for example in a fork) and then we discard that fork and have to re apply a previous runtime that is using V0?

In substrate, with the way fork work, changes are done in v1 (but changes are just a bunch of new trie nodes and a list of removed nodes by hash), then when we switch back to fork in v0, the changes are just discarded and we are back on a v0 state. (fork changes being kept in memory).

[dimartiro]

@cheme I didn't have the notifications for this discussion, thanks for reply! I already finish my V1 implementation in this PR

Now we are discussing about the benefits of translating Parity's trie crate in golang because our current state storage / trie implementation has some issues and is difficult to scale and mantain.

Do you have any concern with that? Thks

[cheme]

No real concern but a few warnings here:

• Parity trie crate got a lot more code than what is strictly needed for substrate, there was a plan to remove all ethereum related things. So there is some unneeded abstraction. Also some prefix key is only needed by rocksdb and not parity-db
• There is also an ongoing change to optimize parity-db usage (https://github.com/paritytech/trie/commits/arkpar/new-trie/ I think). Another pointer to ongoing changes: Multi tree column option paritytech/parity-db#232
• Generally the storage logic is not really part of the trie crate but more polkadot-sdk/substrate/client-db (all that is fork management and state prunning logic). So there may be a bit more work than just the trie crate.
• triedbmut: some function I find a bit awkward (partly due to rust lifetimes).

[dimartiro]

Thanks for your comments @cheme! It's really helpful for us to have all this context. The idea is to get some inspiration from trie crate + client-db and that will really help us to improve our current implementation.

I'll be taking a look into your links to have more context about the new changes and will be back here if I have more questions