Use hashbrown hashmap/hashset in validation context

[alexggh]

Discovered while profiling #6131 (comment) with the benchmark #8069 that when running in validation a big chunk of the time is spent inserting and retrieving data from the BTreeMap/BTreeSet.

By switching to hashbrown HashMap/HashSet in validation TrieCache and TrieRecorder and the memory-db paritytech/trie#221 read costs improve with around ~40% and write with about ~20%

[skunert]

Nice!

[athei]

Should be safe since the keys are already derived via a cryptographic hash function from user data.

[alexggh]

/cmd prdoc --audience node_dev --bump patch

[burdges]

If code runs in native, then HashMap uses secret system randomness, which makes it secure. We typically use BTreeMap instead of HashMap for user controlled keys inside the runtime because there is no system randomness, so adversaries could easily find hash collisions that cause slow probing.

A cryprtographic hash function only provides collision resistance at cryptographic sizes, but if you only have say 2^32 elements in the HashMap, then one can easily find thousands of blake2_128 collisions of that size, which then causes slowdows. If the adversary needs real accounts, then the elliptic curve scalar multiplications slows them down slightly, but does not prevent the attack, and if dust accounts suffice then they can avoid this by using a fast hash-to-curve.

cc @jakoblell

Alternative 1.

We could analyize this attach if the block hash were treated as "system" randomness for the HashMap. We do not have fiat shamir of course but then the blake2_128 gives us something: If we didn't have the blake2_128 then the adversary could compute the blockchain inside some contract and create dust accounts that collided. I think our blake2_128 means the adversary cannot run that improved attack without some auxiliary input external to the block, not allowed in our model.

If this works, then the adverary can only bruit force the whole block hash to pick a somewhat concentrated distribution, which likely reduces the size of attackable HashMaps, maybe or maaybe not enough.

Alternative 2.

As a "blockchain" solution, we could develop a cuckoo table say called PerfectMap, which mostly works like HashMap, except it always runs "perfectly" on the validator or else it panics.

At the collator, PerfectMap records its creation order and instantiates its hasher using local system randomness r, but all keys inserts and deletions get added to a replay log, which only runs on collators. Anytime an insertion fails PerfectMap simply resamples fresh system randomness r, enlarges itself if fuller than say 80%, and then replays the entire block creation process so far its replay log, possibly triggering even more restarts. PerfectMap::Drop logs the final size and final r in PerfectMap creation order in a perfectmap_log the PoV data.

At the validator, PerfectMap pulls the next size and r from perfectmap_log in the PoV data, allocates itself from this size, and instantiates its hasher using r. Any insertion failures simply panic, makign the block invalid. Any runtime code other than PerfectMap that reads the perfectmap_log could easily cause panics, so contracts must not have access to perfectmap_log.

A cuckoo table seems easier to analyize since they already have capped probing. Also they save some memory. You could cap the probing in a HashMap too, doing so costs some memory.