I suppose ext_sr25519_verify permits the signature to run native, nice. I see at least three variants here:

We could pass a running hash function state through this boundary, possibly a 203 byte merlin::Transcript or possibly something else. This gives the cleanest looking code because you avoid artificial serialization. There is however a small cost to running the hash function in WASM when hashing anything large.

We could simply add a context parameter to ext_sr25519_verify so that at least adding context avoids artificial serialization, but..

Ideally, we should select some fast hash function for hashing large things anyways, probably blake2b or blake2x if we have chacha elsewhere, or maybe kangaroo12 if we want keccek everywhere. We now become free to do merlin::Transcript hashing inside WASM safe in the knowledge that we could later improve performance by adding a native call for our fast hash function.

On the other hand, alternative implementations suffer from passing a running hash function across the boundary. If they want to provide this call then they would be required to handle the precise internal state of running hash function. If this is a concern, ext_sr25519_verify could just take a 32 byte hash output and maybe a context string.

As an aside, if we had unlimited time then STROBE itself provides a perfect interface for being called across boundaries because it's literally one method that does all your normal symmetric crypto operations. In fact, merlin uses STROBE on a Keccek variant, so this remains an option for later, but I donno if STROBE's Keccek variant is the best choice for hashing large amounts of data. I'll note a full STROBE implementation has a slightly more complex internal state than a merlin::Transcript.

In any case, artificial serialization can always be avoided by hashing data and maybe context inside WASM and calling this ext_sr25519_verify on the 32 byte output. I'm probably making a mountain out of a mole hill here.

The usage expects AsRef for sr25519::Signature. You can either change the usage to e.g. Encode::encode it instead, or rework the Signature type itself, either introducing an appropriate AsRef in schnorrkel or just using an alternative type and converting between them as needed in sr25519.rs.

It's fine to treat errors in deserializing a signature as signature verification errors, so sr25519::Signature could wrap just a [u8; 64].. and signatures only get checked once.

It's less ideal treat public key deserialization errors as signature verification errors because they can represent a failure elsewhere.. and sometimes you verify with the same key repeatedly.

Just to continue that aside: You could alternatively provide only the permutation like keccak in native, except then you'd be calling across the boundary too much. And it'd break optimizations for at least some chacha implementations. You can normally call STROBE's operate only a couple times for whatever your goal is.

(Buying myself a beer after removing the need to keep those hashes maintained.)

while it is still open, we could also add/further discuss a new sign() to accept Rng (or anything representing entropy) as a parameter before this is even merged at the first place. Needs to be first implemented in the underlying library.

• And remove the dependency as git = ... and replace the published version in crates.io