-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Alter BEEFY primitives to prepare for potential BLS integration #10466
Conversation
primitives/beefy/src/commitment.rs
Outdated
let mut signatures_compact: Vec<Signature> = vec![]; | ||
let mut signatures_compact: Vec<&'a TSignature> = vec![]; | ||
|
||
let mut bits: Vec<u8> = |
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 we populate this and signatures_compact
in one iteration?
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, but actually I think I'd rather use iterators for both:
let mut bits = signatures.iter().map(|x| if x.is_some() { 1 } else { 0 }).collect();
let mut signatures_compact = signatures.iter().filter_map(|x| x).collect();
wdyt?
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.
yeah better 👍🏻
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.
Not my thing, but the changes make sense to me.
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.
Thanks!
…tytech#10466) * Generalize signature. * Fix tests. * Introduce VersionedFinalityProof. * cargo +nightly fmt --all * Rework packing a tad.
…tytech#10466) * Generalize signature. * Fix tests. * Introduce VersionedFinalityProof. * cargo +nightly fmt --all * Rework packing a tad.
@andresilva, @acatangiu: The current structure results in BEEFY messages of around 80K for 1K validators vs if we just keep one aggregated BLS signature it would 32K + 48Bytes + 1000/8 = 32172 that is about 2.5 time bulkier messages for no obvious advantage. I suggest to have a vector of ECDSA signatures and a single aggregated BLS signature field in the BEEFY message instead of having a vector of (ECDSA, single BLS) signatures. |
Agreed! I believe the ideal end result is to have single aggregated signature, resulting in slim messages. |
So aggregation before gossip unfortunately is not possible with unorganized gossip that we have: w3f/bls#51 |
…tytech#10466) * Generalize signature. * Fix tests. * Introduce VersionedFinalityProof. * cargo +nightly fmt --all * Rework packing a tad.
This PR makes
SignedCommitment
contain a generic parameterSignature
(instead of harcodedecsda
signature), so that in the future it can be used as:SignedCommitment<BlockNumber, ecsda::Signature>
orSignedCommitment<BlockNumber, (ecdsa::Signature, (bls::Signature, ecsda::Signature))>
).Also I've renamed
VersionedCommitment
toVersionedFinalityProof
. Currently BEEFY finality proof is simply theSignedCommitment
with sufficient number of valid signatures, but in the future it will include not only theecdsa
Signatures, but also an aggregated BLS signature.Related: paritytech/grandpa-bridge-gadget#2
CC @drskalman @andresilva