Note: might be best to add this feature via #1230 ruleset switch so there it fails to compile under pre-Istanbul rules

Please also include the blake2s hashing function.

We shouldn't have to make it so configurable. It should look more like:

blake2b(msg: Bytes) -> bytes32[2]
blake2s(msg: Bytes) -> bytes32

I think it's 9 rounds for blake2b and 7 rounds for blake2s. Then the message should be recursively hashed 4 32-byte chunks at a time until it's done. Not sure what h and t0/t1 are, probably KDF features (make them empty)

Please also include the blake2s hashing function.

coming up to speed on this -- how to calculate blake2s? is it somehow derivable from blake2b_f (which, just to make sure we're on the same page, can be calculated by calling the precompile at 0x09)?

Please also include the blake2s hashing function.

coming up to speed on this -- how to calculate blake2s? is it somehow derivable from blake2b_f (which, just to make sure we're on the same page, can be calculated by calling the precompile at 0x09)?

The precompile at 0x09 is a large portion of what the blake2 series of hash functions use internally to compute hashes. There are several hash functions in this class, most notably blake2b and blake2s, which require a small amount of preprocessing and assume a few parameters for the call into 0x09.

Once that call is completed, the resulting hash would either be 256 bits (blake2b) or 512 bits (blake2s) to be returned from the function

Most of the time people would want to use just blake2b, but blake2s is also useful. Being able to call the internal function directly through the precompile is a rarer use case.

As a historical note, the precompile at 0x09 works with an internal method of the blake2 series of hash functions because that's what Zcash's PoW algorithm uses, and when it was created people wanted to bridge to Zcash more cheaply