-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimization of Storage/Network through BLS Signature Aggregation #1085
Comments
Additional Reference Here: BLS Multi-Signatures With Public-Key Aggregation The following attack may be useful. |
This is something very important in order to reduce the size of the Multisignatures in general, |
@vang1ong7ang, it was a great pleasure to meet you. Thanks for opening this discussion and sending this nice reference. Let's move on over this topic and see the impacts on rebroadcasting. |
I agree with @vang1ong7ang. |
@anatoly-bogatyrev, integrate it into the dBFT consensus will not be problem for us. I investigated a little bit more and, for the dBFT, the Schnorr may be enough and since we are going to use them on the P2P CN payloads (which requires fast verification and propagation), I am thinking that Schnorr can be the first improvement for us to move right now. |
If we want to do it, we should not only consider consensus, but also consider the feasibility of using it for common multiple signature addresses. |
I agree with both ideas and two additional comments here.
|
@vncoelho Yes, about the implementation of BLS to consensus I just told about some fast draft for an experiment as a proof-of-concept, not full implementation.
But how can we know who signed the transaction during verification from all consensus nodes? |
I agree, as was discussed in a separate thread with NeoReaserach and Red4Sec, can be observed such scope as: Implementation as separate Syscalls to give the possibility to use aggregated signature verification from Smart contracts:
Implementation aggregated signatures verification to Neo protocol:
UPD: Also this can be integrated with crypto extensions in the VM ( https://medium.com/neo-smart-economy/behind-pr-149-a-bright-future-for-neovm-and-neo-3-3b779e8749c4 ) described by @igormcoelho and @vncoelho . |
It's time to vote. BLS or Schnorr. 👍 for BLS, and 👎 for Schnorr. |
It is still hard for me to vote in one, @erikzhang....aehauheauea I voted for both. But BLS have other good applications. |
Add some additional comments to BLS: The BLS aggregation signature scheme does not have a threshold feature. There are two solutions for adding threshold characteristics:
|
Hard for me to vote in one, too. Same idea with @vncoelho I agree that the schnorr may be enough now and maybe easier implement and BLS is so attractive. |
Last week, @fyrchik Evgeny Stratonikov prepared proof-of-concept implementation of BLS at the dBFT consensus golang lib. |
Great to hear, @anatoly-bogatyrev. From the P2P perspective, the block should support mix signatures. Then we can decide when it is worth to use BLS or singlesig. |
@vang1ong7ang, let's come back with this, in fact, this improvement can also enter as part of the effort for improving dBFT 2.0 to dBFT 3.0, since it will play an important piece on Block generation and information sharing during the Byzantine agreement. |
@anatoly-bogatyrev @fyrchik Seems BLS signature can also improve the transaction signature verification speed, Could you provide a performance comparison report between BLS signature and current signature algorithm after the BLS implementation completed? |
I believe signature checking can be made more fast by providing index of validators which have signed the block (may be just as a hint). It takes negligible amount of space (2-byte mask) and in this case it will also be easy to parallelize signature checking. |
I have benchmarked 3 implementations: current algorithm, ecdsa + info about used public keys, BLS.
Most of the time in BLS case is for an actual verification, not an aggregation of public keys. |
@fyrchik, what are the number of the second column? And what are the third, In our previous insights from the literature, we noticed that BLS would be slow on |
Guys, take a look at this, a good cryptographer here from Brazil, that also contributes in MONERO, sent me this idea: https://medium.com/cryptoadvance/ecdsa-is-not-that-bad-two-party-signing-without-schnorr-or-bls-1941806ec36f |
Any news about it? i think that it's a good feature |
I propose closing this one. It is an interesting feature that really makes signatures shorter, but:
So I'd say we don't need it now. If there are any other real useful applications for it (just size is not enough to justify), this can be reopened/discussed in future. |
@roman-khimov yes. let's close this outdated one and propose new ones if needed |
Summary
As it is comment here Link:
Actually BLS signature can be shorter than schnorr signature, but need more computing resources. But I think it is acceptable for consensus.
Do you have any solution you want to propose?
References are here:
BLS Wikipedia
Aggregate and Verifiably Encrypted Signatures from Bilinear Maps
DEMO implement based on PBC is here:
Where in software does this update applies to?
The text was updated successfully, but these errors were encountered: