Idea: use Blake2s instead of SHA256 for subtree hashing and message hashing (have to implement Blake2s in Solidity and port Kobi's circuit implementation to the latest version of circom)

[weijiekoh]

To use SHA256 or Blake2s might be a good idea for message hashing as the user will save a lot of gas (since they have to hash 8 values).

To use Blake2s is even better because it'll use fewer constraints than SHA256. We'll have to write a Solidity/EVM version though.

[kobigurk]

Will Blake2b work for this case? It allows 1024 bit inputs and also available on the EVM.

Porting the Blake2s to Blake2b isn't too hard.

[weijiekoh]

I was wondering if Blake2s has enough security even though it's cheaper.

There's https://github.com/axic/blake2-solidity which implements Blake2b but perhaps it can be modified to Blake2s. The Blake2 precompile is just the F compression function anyway.

I was also thinking about the possibility of writing Blake2b/s in Huff, to save even more gas...

[kobigurk]

Yeah, the main difference is that it works on 512-bit inputs, not that it has less security. You're right that the precompile is only the compression function, though I'd expected that implementing Blake2b using it would still be cheaper than Blake2s. Maybe not :)

[weijiekoh]

I was also thinking about the possibility of writing Blake2b/s in Huff, to save even more gas...

https://github.com/AztecProtocol/AZTEC/blob/5754a9087535ffc9201656c98b0b24c4bd26a265/packages/weierstrudel/huff_modules/blake2b.huff

Aztec already implemented Blake2b in Huff. Nice! (Though they don't use the F precompile)

[ctrlc03]

we now fully use poseidon hashing for messages, and the accqueue structure for signups was removed, as well as the one for messages is removed in favour of an hash chain using only poseidon #1625. Closing due to those changes