BLS12-381 host functions

[s0me0ne-unkn0wn]

Rendered

CC @drskalman @davxy

[burdges]

We should avoid doing the hostcalls for specific signature schemes like this anymore.

Instead, we should do four hostcalls for the underlying slow operations, namely scalar multiplications, multi-scalar multiplications, Miller loops, and final exponentiations. There are no real standards for BLS signatures, so this allows us to support whatever form someone deploys, and also support most snark verifiers, all with only 4 host calls per curve.

We'd expose these through the forked sp-ark-[curve] crates, so then your regular rust code would work in the runtime but accelerated. We discuss the dsign rational in https://hackmd.io/@rgbPIkIdTwSICPuAq67Jbw/rkipBanIn

We'd eventually add quite a few curves this way:

Very standard curves:
ark_ed25519_dalek -- 2 hostcalls, ark_ristretto_dalek reuses ed25519
ark_secp256k1 -- 2 hostcalls

Several pairing friendly curves:
ark_bls12_381, ark_bls12_377, ark_bw6_767, ark_bw6_761, ark_bn254 -- 4 hostcalls each

Some jubjub curves for those, maybe some sister curves later.
ark_ed_on_bls12_381_bandersnatch, babyjubjub -- 2 hostcalls each

Two cycle curves: secq256k1, ark_grumpkin -- 2 hostcalls each

Also maybe some NIST curves: ark-secp256r1 -- 2 hostcalls, requested

Additional work RFPs: https://hackmd.io/@rgbPIkIdTwSICPuAq67Jbw/r1dRCb86C

[davxy]

While I strongly agree with the idea of introducing ark-related host calls for computationally heavy operations (essentially using ark-extensions), this RFC focuses on generating and using secrets from the keystore. That cannot be done within the runtime, so dedicated calls are required.

The ark-extensions work is mostly about optimizing verification operations, which involve only public keys and do not require keystore access.

We could consider introducing a generic call with a parameter to select the scheme, but in any case, this follows the same format used by the other schemes.

Also, I am not entirely sure we need dedicated calls for the ECDSA-BLS hybrid scheme. I suppose the runtime could simply call into the host twice, once for each scheme, and then combine the results?

[s0me0ne-unkn0wn]

@burdges I cannot say I understand what you're talking about as I'm not familiar with the problem space at all, I'm just specifying interfaces here, but I do understand what "4 hostcalls each" means ;) That's 4 allocations of output buffers on the runtime side, 4 times applying marshaling strategies to every argument (they are not no-op unless the arguments are primitives), and 4 times copying over the buffers here and there. If we can generalize the whole thing, disassemble it into Lego pieces, and create chained solutions out of those pieces, that's great news, but that should be done on the host side anyway to avoid FFI overheads.

@davxy as for the ECDSA-BLS, I saw @drskalman implemented the ECDSA-BLS key generation as a host function, and I did the same for the other interfaces. Again, if it can be decomposed into pieces, then the question is: how critical is the performance of this stuff, and does the performance boost justify increased interface complexity? If something is called once per block, it's probably okay to do two separate calls for it; if it's called often, it makes sense to keep it together at the host side.

[burdges]

Alright, you cannot sign anything from block runtime, but this gets used by offchain workers? We've some mechanism that restricts such signing host calls to offchain workers?

[bkchr]

We've some mechanism that restricts such signing host calls to offchain workers?

We don't have anything that restricts this. However, calling this while building a block would lead to indeterminism, so this isn't done.

[burdges]

It's restricted to only the relay chain runtime then?

[bkchr]

It's restricted to only the relay chain runtime then?

Parachains could also use this off chain. But maybe I misunderstood you?

[burdges]

I simply meant that parachains cannot invoke this in their PVF.

Anyways my original comment was entirely about the verification, not about signing per se. There are many reasons not to expose secrets to off-chain workers, if avoidable, so no objections here.