As of today, we already parallelize the merkelization of accounts. That is, we divide the account trie updates in 16, separating them by the first nibble. This includes storages, but as their path starts with the account, that means that smart contracts with many storage updates will have all of them sequentially.
We may take even more advantage of this idea by parallelizing the storage updates in 16 threads as well. One way we can do this is to divide the storage updates in 16 parts, by using not the first nibble of the full path, but the first nibble of the storage slot part of the path. With this, big contracts like commonly used stablecoins and dexes may have faster updates too.
As of today, we already parallelize the merkelization of accounts. That is, we divide the account trie updates in 16, separating them by the first nibble. This includes storages, but as their path starts with the account, that means that smart contracts with many storage updates will have all of them sequentially.
We may take even more advantage of this idea by parallelizing the storage updates in 16 threads as well. One way we can do this is to divide the storage updates in 16 parts, by using not the first nibble of the full path, but the first nibble of the storage slot part of the path. With this, big contracts like commonly used stablecoins and dexes may have faster updates too.