Switch from SHA2 to BLAKE3

[dr-orlovsky]

BLAKE3 is 10+ faster (i.e. by an order of magnitude) than SHA2-256 encoding. It also supports streaming and will be used for working with consignments. It is also used in the new strict-type library which is our downstream dependency. It provides a native rust implementation written by the creators of the protocol, which is well-maintained.

I propose to start using BLAKE3 as a default hash functionin all layer 2+ projects. Of course, we can't change bitcoin part (layer 1), but that is not necessary. However, we can switch to BLAKE3 in RGB (together with other consensus changes), making validation faster.

The switch doesn't add new dependencies (blacke3 is already in the dependency tree due to strict-types) and is a highly-trivial. In fact, it reduces amount of code since the use of bitcoin_hashes involves a lot of boilerplate and creation of different hash types is much simpler and laconic with BLAKE3 APIs.

CC @fedsten @cryptoquick

[fedsten]

Do we know if SHA operations take a significant amount of the validation time? It doesn't look like SHA is used so extensively to actually have a big impact. If the advantage of migrating is not significant I'd rather stay with SHA2-256 as it remaining secure is an assumption that RGB needs to do anyway since it works on top of Bitcoin, while using another hash function adds another unnecessary assumption that also BLAKE3 will remain secure.

[dr-orlovsky]

I wouldn't say that either bitcoin or RGB relies on SHA/hashing for security. If a collision for a hash function would be found, it would not lead to loss of state, funds, double spending etc.

[fedsten]

On my (not fancy) machine to do 10,000 SHA256 computations takes only 3 milliseconds, so it doesn't seem to be a big impact on the overall validation time.
SHA is used in Bitcoin to compute the txid and merkle tree committed in the block header, so if the function is compromised a wide new range of attacks become possible. If the hash function of RGB is compromised it can become possible to forge new content for the same anchor, which is another vector of attack. Avoiding using multiple hash function when possible is therefore preferable to keep the attack surface smaller.

[cryptoquick]

This could add up if there are hundreds of tokens in a wallet, with hundreds of state transitions each, then there'd be hundreds of SHA validations. In this scenario, it'd be more than a million validations, which could be on the order of seconds. Also, the speed of a hash function's execution is dependent on the amount of data hashed; there's a difference between, say, hashing two 32 byte hashes, and hashing an entire contract, for example. Some contract data could be up to 16MB, from what I understand. Just things to keep in mind. I'm supportive of using Blake3, it's pretty well-trusted and relied upon, and I'd prefer to avoid legacy stuff while building new stuff if we can.

[fedsten]

The hash operations are done only when preparing or validating a consignment, not on all the wallet content. Also with current validation performances, if we have a consignment big enough that the hashing operations take more the 0.5 seconds probably the overall validation time is in the order of thousands of seconds (or even more), so I really fail to see how it can be worth to add security assumptions for this.

[dr-orlovsky]

I agree to keep bitcoin SHA256