add block hashes to the randomness used by hashmaps and friends in validation context

[alexggh]

#8606 paritytech/trie#221 replaced the usage of BTreeMap with HashMaps in validation context. The keys are already derived with a cryptographic hash function from user data, so users should not be able to manipulate it.

To be on safe side this PR also modifies the TrieCache, TrieRecorder and MemoryDB to use a hasher that on top of the default generated randomness also adds randomness generated from the hash of the relaychain and that of the parachain blocks, which is not something users can control or guess ahead of time.

[alexggh]

Will be removed once: paritytech/trie#224, gets merged and a crate release is done.

[burdges]

I first suggested this in #8606 (comment) but I honestly still have no idea how secure this is. Also how badly this breaks depends upon what computation happens, aka this seems not contract safe.

The simple attack is: 1st, do a bunch in a hashmap operations in a block. 2nd, search block hashes until you find one having considerable probing. At some point, I started looking up how the hash map handles landing early in the probe sequence, ala if probes ever trigger reallocation, but never pinned that down enough to figure out the attack difficultly. Anyways if you have a tight hash map and can land early in the probe sequence, then you can produce many probes on each read, which gives an attack.

I've no idea if there are worse attacks that exploit the weakness of hash brown vs say sip hasher, but that where not beiong. contract safe really emerges. Afaik nobody has ever proven really nice properties of sip hasher beyond hiding the key, so not sure what'd be better.

As for optimizing this, you could do hash(blockhash * hash-to-curve(blockhash)) for this randomness, so that every attack attempt required 25 us. It'd do nothing against parallellism though, so not worth the effort without the ECC host calls.

Anyways..

If we must BTreeMap then we could first take this appraoch because its easy, and not that bad, but also make an RFP for my other PerfectMap proposal, and hope that happens before anyone exploits this for griefing us.

PerfectMap amounts to the collator "proving" that it picked a "nearly perfect" seed. It just hard caps the probing like a cuckoo table does, but panic instead of rebuilding. Avoiding rebuilding should improve write performance. It's the hash map analog of the collator doing an O(n log n) sort on then verifying the sort in O(n) in the block.

[alexggh]

The simple attack is: 1st, do a bunch in a hashmap operations in a block. 2nd, search block hashes until you find one having considerable probing. At some point, I started looking up how the hash map handles landing early in the probe sequence, ala if probes ever trigger reallocation, but never pinned that down enough to figure out the attack difficultly. Anyways if you have a tight hash map and can land early in the probe sequence, then you can produce many probes on each read, which gives an attack.

Not sure, I understand this, the extra seed is derived from the relay chain parent blockhash and the hash of the current parachain block(which is also impacted by the transactions in it), so this is not something the user can control apriori or manipulate and it changes every block.

[paritytech-release-backport-bot]

Successfully created backport PR for stable2506:

• [stable2506] Backport #9127 #9181

[paritytech-release-backport-bot]

Created backport PR for stable:

• [stable] Backport #9127 #9236 with remaining conflicts!

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin backport-9127-to-stable
git worktree add --checkout .worktree/backport-9127-to-stable backport-9127-to-stable
cd .worktree/backport-9127-to-stable
git reset --hard HEAD^
git cherry-pick -x 7058819a45ed5b74cedd6d21698f1c2ac2445d6b
git push --force-with-lease

[paritytech-release-backport-bot]

Backport failed for unstable: couldn't find remote ref unstable.
Please ensure that this Github repo has a branch named unstable.

[paritytech-release-backport-bot]

Backport failed for stable2506, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin stable2506
git worktree add -d .worktree/backport-9127-to-stable2506 origin/stable2506
cd .worktree/backport-9127-to-stable2506
git switch --create backport-9127-to-stable2506
git cherry-pick -x 7058819a45ed5b74cedd6d21698f1c2ac2445d6b

[paritytech-release-backport-bot]

Successfully created backport PR for unstable2507:

• [unstable2507] Backport #9127 #9237