3

After reading through the BLS related issues in the substrate repo, it isn't quite clear to me what type of support is planned for the BLS signature scheme. It seems like the primary goal is to integrate it into BEEFY.

But could we also be seeing BLS supported in the MultiSignature enum? Will it be possible to use BLS public keys to control funds from the balances pallet? If we were to build a pallet today with future BLS support in mind, are there any recommendations on how to proceed?

In particular, it seems that the BLS public keys are not 32 bytes and they cannot be recovered from the signature in the way that ecdsa signatures can be. Hence, we would not be able to use AccountId32 for the AccountId associated type in the frame_system::Config trait and would instead need an enum type instead of AccountId32. That is at least one issue I see. Thus, I am guessing substrate may not directly support BLS in their MultiSignature type. So if we were to plan for eventual BLS support and develop a runtime with future compatibility, would it make sense to use an enum for the AccountId associated type and then eventually append a type that represents BLS public keys?

For my use case, I'd like to implement a rollup pallet to batch extrinsics that would use a storage map with u32 as the key and BLS public key type as the value. The payload for each subextrinsic would contain u32 values instead of public keys which would point to stored BLS public keys which would control their own funds. Operations would then be performed on the accounts' behalf once the aggregated signature is verified.

Improve this question

1 Answer 1

Reset to default
2

Afaik, there is never a good reason to use public key recovery in any signature scheme. It'd break batching in Schnorr. Also recovery makes soft derivation insecure in Schnorr. ECDSA should never be used in the first place.

BLS already makes soft derivation insecure, and recovery impossible. In cases, BLS makes sense for consensus, but BLS rarely if ever makes sense for accounts. If you want off-chain multisigs, then use two-round Schnorr ones we & others proved secure.

That said..

We'd envision folks doing BLS via https://github.com/paritytech/ark-substrate once we finalize the hostcalls added in https://github.com/paritytech/substrate/pull/13031 because this gives parachains maximum flexibility.

I've written https://github.com/w3f/ring-vrf/tree/master/nugget_bls to improve gossiping of BLS signatures, and https://github.com/w3f/apk-proofs/ can help in bridges using them.

Improve this answer
3
  • I was intending on using BLS signatures to implement roll ups as described here: vitalik.ca/general/2021/01/05/rollup.html. Why should BLS signatures not be used here? I haven't studied two-round Schnorr but it does not seem to fit my use case.
    – user2959071
    Commented Nov 2, 2023 at 15:22
  • Also, where does github.com/w3f/bls fit into all of this? This crate supports all of my needs and I've been using it meanwhile to test my pallet, but it is unclear how this crate and the ones you mentioned all fit together.
    – user2959071
    Commented Nov 2, 2023 at 16:06
  • It was a naive experiment of mine, which I now consider a mistake, and I wish it'd go away. We're unfortunately using it ourselves. <face palm>
    – Jeff Burdges
    Commented Nov 9, 2023 at 22:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.