Not going to be saying much new here, but just going to summarise my understanding and position on any potential BLS signature research.
First, I think we need to split off consideration of the Pink Paper for the time being and set it to one side. It is definitely of value and of it does indeed outlines exciting possibilities, but it’s still an unreviewed proposal based on a theoretical foundation (e.g. a Grin or Grin-like chain that already incorporates BLS) that doesn’t currently exist. I’d see it as an potential example of something that might be enabled by Grin+BLS, but designing or planning to it right now is putting the cart several miles before the horse.
That foundation is what we’d be looking to establish via any BLS research we’d be undertaking at this time. As has been said before (but I’ll outline for the purpose of my point,) the immediate implications of changing the underlying cryptography to a pairing-friendly curve and incorporating BLS are:
-
The ability for a secure single-trip (A->B) transaction creation that doesn’t leak private keys. (This is actually possible today if participants are willing to expose their keys to the other party). The main advantage BLS gives over Schnorr is that no exchange of nonces is required among all parties before the partial sigs can be created, enabling the A to include a partial sig in the transaction sent to B. That’s really about it. edit: (Not without further research on how to construct this, see thread below)
- Being a step closer to kernel aggregation, (but not all the way there)
That, in my mind, is it for the time being. Incorporating BLS will not magically give us ‘non-interactive transactions’, (though it may facilitate future schemes that can try to emulate them,). It could remove some friction from the transaction creation process, a not-insignificant benefit.
However, the main downsides of trying to bung this into Grin as it stands are many (and have all been stated before):
- Having to maintain 2 separate crypto implementations
- BLS requires the use of pairing-based cryptography, which is immature as a field of study and very immature in terms of usable implementations, which means massive risk for anyone relying on them for secure applications. It would be highly irresponsible of us to suddenly expose all of the value locked up in Grin in this manner.
- Having to reconcile pairing-based outputs with secp256k1 outputs (the whole foundation of MW is summing outputs together, and you can’t meaningfully sum elements across 2 separate fields) I can’t even begin to imagine how we’d deal with that.
On balance, I don’t see the immediate benefits (slightly easier transactions, slightly slimmer kernel set and only nebulous possibilities of future benefits) being worth this pain and risk exposure for all Grin users.
If I were to start a Grin+BLS research project right now, what I would be doing is forking Grin and replacing the underlying crypto primitives with the most mature paring-based curve implementation available. (This in itself would be a very time-consuming and resource intensive project, don’t forget all of the work that’s gone into implementing the MW primitives on top of libsecp256k1.) Then I would be replacing the current transaction-building protocol with a single-trip A->B protocol based on BLS.
I would not even attempt to think about how to incorporate all of this into Grin at the outset, and would be exclusively focused on a new testing chain that only uses bleeding-edge and largely untested and unhardened paring-based crypto. I would thus call it ‘Grinsecure’, because nobody would have any idea whether it’s supposed to be more secure or less secure than Grin, which would accurately reflect reality.
This would be entirely, 100% a ‘Grin Labs’ (n.b. this doesn’t actually exist) research project intended to explore pairing-based crypto, the possibilities enabled by BLS signatures, and not in any way intended for use as a new currency or ‘Grin 2’. As I said, trying to bung untested-crypto into Grin for some small and less-then-tangible benefits would be grossly negligent toward anyone who’s put any value at all into Grin.
Perhaps would-be fork authors should take note: instead of forking Grin and changing the economics, try forking Grin and changing the underlying cryptography in this manner, then you’d be adding something of great value from a research perspective that the community could get behind (even though you’d be putting users at great risk if you ever tried to launch an actual currency).
But for now, what I’ve just described is as far as I’d be willing to advocate for exploring BLS currently. Whether this is worth it given our limited resources is hard to say. If we were a corporation with an Advanced Research department, it would be a no-brainer, in our situation, it’s not such a slam-dunk.