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.