Blake 2B and Blake3 are slightly different algorithms. A while ago, I came up with the question of whether or not Siacoin should migrate to Blake3. This question was posted on Reddit.
This question has intrigued me, but what intrigued me more or less was the answer. It would need to be a hardfork, and although Blake3 is considered multiple times faster by others, there are debates in regards to HAIFA construction vs. traditional Merkle trees and so forth.
That said, a hardfork of Siacoin would likely be easy given the code is standardized, but according to devs on Reddit, a Blake3 upgrade is the wrong thing to be worried about. I do agree.
Is Blake a good choice?
However, I still had a curiosity in exploring Blake3. In one of my own projects, I have decided to let the founder integrate Blake3 as its core hashing mechanism.
That project is BitBadges (2nd version), and I think Blake3 would work as the hashing algo of choice for BitBadges. The whitepaper can be seen here. It is worth a read.
Another fact I found interesting, is that besides Siacoin, another Blake2b adaptor was Nano.
Nano utilizes Blake2b in regards to the digested seed hashing. In regards to Blake3 adaption, Nano and most of these other cryptos would likely need a hard fork over soft fork.
Interestingly enough about Blake3, is there have been many adaptations. This includes a PHP Hash Blake3 class, and Blake3 itself has a Rust and C implementation.
Blake3 is said to be a merkle tree on the inside, and the speed itself is substantially higher then Blake2b in regards to the
benchmark testConclusion
Blake3 is utilized more towards CPU multithreading, and likely if a cryptocurrency wants the benefit of hashing, but aren't too focused on multithreading or parallelization, then Blake2b is still a decent choice.
For me, as a person liking grid and verifiable forms of computing, I had the preference of Blake3. That said, it is nice that it was already available at the time starting development.