-
Notifications
You must be signed in to change notification settings - Fork 5
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
Partial Signature Verification Aggregation #46
Conversation
sips/reduce_signatures_no_fork.md
Outdated
A partial signature message implies one RSA verification (in the message validation layer) and two BLS verifications (for `SignedPartialSignatureMessage` and `PartialSignatureMessage`). Notice that two signatures are used to verify that the sender is correct and one is used to verify if the (same) sender correctly signed the beacon partial signature. Therefore, we can, simply, ignore the first BLS signature since the RSA signature is already being checked. | ||
|
||
> [!NOTE] | ||
> Since we want a no-fork change, one must still BLS-sign twice to be compatible with the previous version. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is still a rogue key attack vector here ;-\
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is that? Can you give an example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't an attacker put a bad sig on the first BLS check simply?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it can. But let's say one malicious operator creates an invalid signature on the SignedPartialSignatureMessage
. What is the attack outcome in generating an inconsistent state?
Any projected gains from this? in terms of speed/ CPU/ etc? |
@alonmuroch |
This SIP attempts to reduce the current cost of signature verification. Specifically, it boosts the partial signature steps, in which a quorum is needed to trigger some action. To accomplish that, it proposes performing a single BLS verification on the reconstructed signatures only when a quorum is reached.
The SIP is based on discussion #38.