[WIP] Describe implementation assumptions of Substrate regarding (child) storages

[lamafab]

Fixes #575 and #577 (#540 should be later completed here, too).

@tomaka I would appreciate if you could quickly double check this, especially my claim on how child storage keys are constructed and that get returns None if child_storage_root has never been called. Those are random guesses of mine :)

[tomaka]

I don't understand the purpose of this paragraph. You seem to be literally describing what a specification is.

[lamafab]

So we've been telling the implementers that the "main" storage is fully separated from the child storages and that this functionality can be implemented however they want. But with this new specification we're basically saying that those storages are really not that separate, meaning we kind of insist now that child storage entries are namespaced by a specific prefix and that the Storage API actually can access Child Storages. This paragraph is meant to imply that the Host implementation must simply deal with this "ugliness", but I guess I can clarify this further.

Regarding your other points.

Why is this not explained under ext_storage_get_version_1?
And why "for example"? We want a precise list, not examples?

I put everything into one section so it's clear how the underlying data is structured in the Substrate implementation. Those things must also be considered for read, append, next_key, etc, too. But I should replace the "for example" there with something more formal.

Similarly, why not explain this under ext_storage_clear_prefix?

As mentioned above, it's to keep things packed together; functions that modify data simply check whether the key starts with :child_storage:, but the clear_prefix function makes an exception by also checking whether the input is a substring of :child_storage:. If you think it's more appropriate to move that section to ext_storage_clear_prefix I can do so.

[tomaka]

So we've been telling the implementers that the "main" storage is fully separated from the child storages and that this functionality can be implemented however they want. But with this new specification we're basically saying that those storages are really not that separate, meaning we kind of insist now that child storage entries are namespaced by a specific prefix and that the Storage API actually can access Child Storages. This paragraph is meant to imply that the Host implementation must simply deal with this "ugliness", but I guess I can clarify this further.

I still don't understand. You told something to the implementers, and because you told them something you're writing the spec in a different way than you would have if you hadn't told them?

[tomaka]

Why is this not explained under ext_storage_get_version_1?
And why "for example"? We want a precise list, not examples?

[tomaka]

Similarly, why not explain this under ext_storage_clear_prefix?

[tomaka]

We shouldn't be linking issues in a specification?

[tomaka]

This spec isn't supposed to be an explanation of how Substrate works. It is Substrate that is supposed to conform to what this spec says. Linking to an issue saying that we want to remove the feature is IMO not only inappropriate (it places a judgement over how it works) but also doesn't remove the fact that child tries will continue to have to be supported and will forever be part of the Polkadot spec even if we remove its usage from Substrate.

[tomaka]

I don't think that this is accurate. As far as I understand, you can only call ext_storage_get_version_1 on :child_storage:default:some_child in order to get the root hash of the child trie, but you can't get the keys of the child trie.