Salt StorageMap keys

[PhilippGackstatter]

What should be done?

Useres can currently use StorageMaps in accounts to authenticate many key-value pairs in a single storage slot. The keys of the Smt underlying the StorageMap are taken directly from user input. This means users or an attacker could insert many key-value pairs that end up in the same subtree. However, a uniform distribution of keys across an Smt is important for storage optimizations, so it would be desirable for us to ensure keys are uniformly distributed and not entirely user-controlled.

How should it be done?

To that end, we can add a salt to the user keys, like the account ID. So in essence, the actual key in an Smt should be the hash of the tuple (KEY || [account_id_prefix, account_id_suffix, 0, 0]) or something similar.

When is this task done?

When user input can no longer affect the distribution of keys in a StorageMap.

Additional context

No response

[bobbinth]

One additional consideration: by looking at the salted keys it would not be possible to reconstruct the original key values. This may be fine in some cases, but may be problematic in others. For example, if we have some kind of a "storage explorer" which lets people visualize the contents of the storage, then such storage explorer would not be able to show the original keys and this may be confusing to users.