Just to capture some context (and @dev0x1 please correct me where I'm wrong), the issue is the following:
The direction that hash-to-scalar is going in the spec is to use either hash-to-field or expand-message. The issue is that blst does not seem to expose their hash-to-field api. Even if they did, they don't have the implementation we need, i.e., they use mod p, not mod r (something that i don't thing the blst people will be happy to fix).
They do expose an expand-message-xmd api that we could use though (in combination with blst_fr_from or blst_scalar_from_be_bytes that reduce mod r). That said, their implementation is not very memory efficient in contrast with the zkcrypto implementation. This is again something that will most likely not change (creating a lot of scalars isn't really one of blst targeted use case). It also does not support an xof.
So, the choices I can think of is:
we use the blst expand-message and accept the memory usage penalty.
we re-implement expand-message (and possible hash-to-curve to be consistent with the spec) to apply the optimizations used by the rust crate.
Unfortunetly, this is only an issue with blst (other libs i looked at don't face the same problem), so i don't think changing the spec to fit blst is the appropriate move either.
Just to capture some context (and @dev0x1 please correct me where I'm wrong), the issue is the following:
The direction that hash-to-scalar is going in the spec is to use either
hash-to-fieldorexpand-message. The issue is that blst does not seem to expose their hash-to-field api. Even if they did, they don't have the implementation we need, i.e., they use mod p, not mod r (something that i don't thing the blst people will be happy to fix).They do expose an expand-message-xmd api that we could use though (in combination with blst_fr_from or blst_scalar_from_be_bytes that reduce mod r). That said, their implementation is not very memory efficient in contrast with the zkcrypto implementation. This is again something that will most likely not change (creating a lot of scalars isn't really one of blst targeted use case). It also does not support an xof.
So, the choices I can think of is:
Unfortunetly, this is only an issue with blst (other libs i looked at don't face the same problem), so i don't think changing the spec to fit blst is the appropriate move either.