How are the storage tries structured?

[siladu]

https://github.com/ethereum/yellowpaper/blob/f41ec9a6785374c1d9b9e9a064e3ceae1413805a/Paper.tex#L253

A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values.

[siladu]

Answer from @ajsutton:

Each contract account has its own (potentially empty) storage: a new merkle trie. This represents the "inter-transactional state" and comes at a cost (in gas).
Some contracts have lots of storage.
Many smaller tries is a good model because you avoid paying the gas costs of hashing lots of small changes to one big trie. (Does besu's BONSAI mode change this?).
A merkle trie is a good choice because you're still able to identify it with a single hash.

If you store the accounts' storage tries by storageRoot rather than the more natural account address, i.e. Map<StorageRoot, StorageTrie> rather than Map<Account, StorageTrie> then this leads to de-duplication since two contract account with the same content will share the same storage root and therefore storage trie.