Use XXH32 instead of sha256 for const hashing

[xermicus]

Would it be feasible to use FNV xxhash instead of sha256 for Key hashing, since we use only 32bits of the sha hash anyways? With FNV xxhash being a much simpler algorithm, it would allow us to use ink_metadata with stable rust without relying on RUSTC_BOOTSTRAP. Also what do you think @xgreenx ?

[xgreenx]

I thought about this solution(in the first implementation I used a custom hash function). The problem is that the chance of getting collision is higher, and it will make the implementation of the same storage key calculation for other languages harder because they need find implementation of this not popular function=) The same for documentation, we need to describe the usage of an unusual hashing algorithm.

But if other members of the ink! team like this idea, of course, go with it=)

[xermicus]

Thanks for your feedback! At first I shared your concerns about collisions, but as I thought a bit about it I came to a different conclusion. My guess was that reducing sha2 to 32 bits only has significant impact on its collision rate as well. And FNV1A is actually not that bad: According to this stack overflow answer, there are only ~4 collisions per ~200K hashes of UUIDS.

This left me wondering, how bad is FNV1A compared to 32bit SHA256? I quickly hacked together my own very small and totally unscientific experiment. If you run this multiple times, you'll observe that the SHA2 option does only slightly better than FNV1a. In fact, sometimes there are even more collisions for SHA2:

Testing for 200000 UUIDs with 32 runs...
FNV1A collisions: 137 (avg. 4.28125 per 200000 UUIDs)
SHA2_32 collisions: 155 (avg. 4.84375 per 200000 UUIDs)

Based on that it seems like we don't gain much in terms of collision resistance by using 32bit SHA2 instead of FNV1A. This only applies to hashing UUIDs though (behavior in our use case might be different!).

the usage of an unusual hashing algorithm

I don't think FNV is "unusual". To my knowledge it is a solid (in terms of speed vs collision resistance) and often used non cryptographic hash.

But if other members of the ink! team like this idea, of course, go with it=)

I'd be very happy to hear some more opinions on this one as well 😊

[ascjones]

I am in favour of this because it is a huge headache to require people who depend on ink std libs to run nightly or RUSTC_BOOTSTRAP=1.

The numbers and posts above seem to be encouraging. However I am not an expert on the suitability or not of hashing algorithms for unique key generation, so I would like somebody else here with more knowledge to approve this.

[xermicus]

As discussed internall, switched to xxhash32, since it is used already in substrate for non cryptographic hashes.

I used 0 as seed value, it is a valid seed and seems to be the common choice (xxh32sum utility and LZ4 compression use 0 as seed for example).

[HCastano]

@xermicus this should be XXHASH instead, eh?

[xermicus]

thanks! 🙈