-
Notifications
You must be signed in to change notification settings - Fork 111
[consensus] Add consensus::aggregation
#974
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
Conversation
bcc3600
to
4321ffb
Compare
3e34e05
to
0bbdbea
Compare
83bc6d4
to
01039b6
Compare
I think this one will realllllly benefit from #1002 ❤️ (sorry I thought this would go out as a review comment lol) |
consensus/src/aggregation/mod.rs
Outdated
@@ -0,0 +1,1093 @@ | |||
//! Threshold signature aggregation for agreeing on externally-finalized hashes. |
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.
nit: Recover threshold signatures over an externally synchronized stream of digests.
I suppose the "aggregation" here is really what we'd call recovery (and it would be aggregation in a multi-signature case). 🤔
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.
...now second guessing the name aggregation
lol
consensus/src/aggregation/wire.rs
Outdated
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.
In other consensus crates, we combine types
and wire
. Curious if you feel it is better to separate (I've taken the position that anything in types
may be serialized somewhere and sent over the wire so delineation doesn't add anything).
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.
I think it's better to keep them separate. Just easier to see the direct types that you are expected to send over the wire or not
77f9b4c
to
29ba1c5
Compare
ecfa97e
to
a14e04d
Compare
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.
Very close! Will take it from here and merge 🫡
// Refresh the epoch | ||
debug!(current=self.epoch, new=epoch, "refresh epoch"); | ||
assert!(epoch >= self.epoch); | ||
self.epoch = epoch; |
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.
Unlike ordered-broadcast
, I suspect epoch
will be rigidly associated with a range of indices.
We "should" be ok gathering signatures from the current epoch on any historical data (and need to for liveness) but just calling out as a point of discussion.
Codecov ReportAttention: Patch coverage is
@@ Coverage Diff @@
## main #974 +/- ##
==========================================
- Coverage 91.39% 91.04% -0.36%
==========================================
Files 218 245 +27
Lines 59455 59775 +320
==========================================
+ Hits 54338 54420 +82
- Misses 5117 5355 +238
... and 188 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
Fixes #814
TODO
Future Work
Activity
emission for conflicts #1084ordered-broadcast
andaggregation
#1002