BLS signatures implementation (from Chia)

Chia has started a full implementation of BLS signatures:

BLS (short for Boney-Lynn-Shacham) is a newer signature scheme based on elliptic curve pairings that has many attractive features. In particular for Grin, BLS signatures can be aggregated non-interactively, including with different messages. This would allow kernels aggregation, perhaps not in every single case (kernels can still be useful for scriptless scripts) but in the great majority of cases.

Note that Ethereum is also looking at BLS:

Also relevant, a common pitfall of BLS implementations:

5 Likes

This seems fantastic. Adding BLS to bitcoin would provide marginal benefit because of its limited txn aggregation. But aggregating kernels in Grin would be a huge win.

1 Like

So couldn’t be implemented on all kernels but is there an estimate for what percentage and what this would shrink down to? Only “simple” kernels? As far as I understand it signatures and kernel aggregation means essentially everything has been compressed ??? Sounds like more magic.

I’m guessing less than 10% of kernels would need to stay around, at least for some time. Probably much less. And yes, the rest would be fully aggregated, in each block and across blocks for fast sync.

1 Like

Marlins beard…

are the space savings as dramatic as aggregating signatures was to start…?. it sounds like it. In which case this is as revolutionary as the original cutting through?

Is this worth an additional test net pre main?

Probably not as good as cut-through, kernels aren’t that large. But we’d get closer to having a really skinny chain. I don’t think we should delay mainnet however, we can always hard fork it after: it’d be just another signature scheme to start. And that’s likely at least a year away, we need to do more research on the various implications. It’s a new implementation that needs to mature (possibly with our help).

2 Likes

Since BLS implies an increase in security assumptions beyond just elliptic curve discrete log, it may be best to implement it as a pure add-on. That is, tx in future may require a BLS kernel in addition to the current Schnorr kernel, allowing light clients to skip all the Schnorr kernels and verify only the aggregated BLS kernel, as a security/space&speed tradeoff.

1 Like

Interesting, so it could allow BLS only “superlight” clients and schnorr as a sort of fall back in case BLS is broken? And as BLS is pretty small addition it wouldn’t contribute too much bulk to schnorr-only clients space req?

Does that mean someday after sufficient testing a full switch to BLS could happen?

very clever Tromp!

Yes, yes, and not quite.

A full switch to BLS would perhaps only come when the scheme is proven to be just as secure as Schnorr, i.e. when breaking BLS implies breaking ECDLP.

1 Like

Yes, friend? You summoned me.

1 Like