Better child storage support

[xlc]

Improve decl_storage macro or create a new decl_child_storage macro to provide a proper support of child storage.

Currently child storage can only be used with raw key which requires some boilerplate code to use and easy to make mistake (e.g. pick a bad hasher). Those information also are not exposed on metadata which makes JS SDK implementation hard.

Usage of child storage should be similar to StorageMap / StorageValue for better developer experience.

Previous discussion: paritytech/polkadot#315 (comment)

[gui1117]

I can imagine this:

StorageName child($ChildString): map storage_type => storage_type;

This storage instead of inserting into top storage it will insert into the child trie with at the place $String.
$ChildString could default to ModuleName ++ " " ++ StorageName.
But I'm not sure about having a default one, like maybe some modules wants to put two storage into the same child trie and other modules wants to put every storage into a different child trie. Having no default seems better.

Also $ChildString could be hashed but I see no value of it, is there some ?

Does that fits all need ? also if someone doesn't want its stuff to be hashed in the childtrie (because it is already isolated from everything else) then we can introduce Identity Hasher.

[gui1117]

Also do we want those child trie to be created in genesis or do we want them to be created on first insert ?
I would say option 1

[kianenigma]

+1. It was mentioned in some previous conversations that would be good to, exactly as mentioned, allow syntax like:

StorageName child($ChildString): map storage_type => storage_type;

[cheme]

I had an experimental branch with full switch to child module.
Current state is 'does not work when running the node' so it will probably require implementing the switch optionally to spot the issues.
https://github.com/cheme/substrate/tree/child_module_storage , I guess it can help starting with this issue.

[shawntabrizi]

We still need this, but with the new FRAME v2 macros.

Could be a good project for a more advance hiring exercise.

[xlc]

no one love child storage