-
Notifications
You must be signed in to change notification settings - Fork 17
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
DKG proof of concept implementation #2
Conversation
- Fixes inconsistencies and typos. - Aligns with original paper. - Clarifies abbreviations and similar.
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.
LGTM! 👍
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.
Some small changes, mainly not use seeded rng and defo not maidsafe_utils
Cargo.toml
Outdated
bincode = "1.1.4" | ||
failure = "~0.1.5" | ||
lazy_static = "~1.2.0" | ||
rand = "~0.4.2" |
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.
Also use latest rand please.
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.
My suggestion would be to use the same version of rand that threshold_crypto uses. Then we wouldn't need the RngAdapter
wrapper leading to somehow simpler code. The last published version of threshold_crypto (0.3.2) uses rand v0.6.5.
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.
but the latest rand is at 0.7.3, and seems threshold_crypto depends on a bit old rand_core version.
So I'd suggest keep the RngAdapter, so that the latest rand can be used within this crate (avoid a potential adapter outside this crate)
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.
OK, I don't mind that. It's also worth keeping an eye on the threshold_crypto crate because it seems they already use rand 0.7.3 in master. So likely the next published version will have it too.
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.
Some comments mostly about style, naming, consistency and documentation. Not much about the logic itself which I would have to spend more time on. Maybe a followup PR can expand the test suite (possibly using property testing too) to give us more confidence in the correctness of the algorithm,
src/key_gen/mod.rs
Outdated
} | ||
|
||
// TODO: so far this function has to be called externally to indicates a completion of the | ||
// contribution phase. May need to be further verified whether there is a better approach. |
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.
It's not clear to me when this function should be called. Maybe add more detailed explanation?
src/key_gen/mod.rs
Outdated
/// d, call `finalize_complaining_phase` to complete the complaining phase. (This separate call may need to | ||
/// depend on a separate timer & checker against the key generator's current status) | ||
/// e, repeat step c when there is incoming `DkgMessage`. | ||
/// f, call `generate` to get the public-key set and secret-key share, if the procedure finalized. |
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.
if the procedure finalized.
How do I know it's finalized?
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.
call
generate
The function is called generate_keys
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 do I know it's finalized?
have to wait for a fixed interval or keeps polling.
This is same as to when the finalize_complaining_phase shall be called.
You are right @S-Coyle it should be dual bsd-3/mit |
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 sure why my comments don't show at time so adding new review here
@maqi given the above, perhaps you can update the license files as part of this PR to match that of all our duel BSD/MIT repos, and of course update the license blurb at the top of each source code file |
/// Returns the new secret key share and the public key set. | ||
pub fn generate_keys(&self) -> Result<(BTreeSet<S::PublicId>, Outcome), Error> { | ||
if self.phase != Phase::Finalization { | ||
return Err(Error::Unknown); |
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.
Should we maybe have more specific error for this? Something like OutcomeNotReady
. Or alternatively, change the return type to Option
as there seems to be only two possibilities: either the outcome is available or it is not.
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.
right, will consider whether it will be a more explicit error or an option to be more suitable, within the next PR
// contribution phase. That is, the owner of the key_gen instance has to wait for a fixed | ||
// interval, say an expected timer of 5 minutes, to allow the messages to be exchanged. | ||
// May need to be further verified whether there is a better approach. | ||
pub fn finalize_contributing_phase<R: RngCore>( |
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 wonder if it would be possible to reduce the API surface a bit by merging the finalize_contributing_phase
and finalize_complaining_phase
into one function which automatically detects what to do based on the current phase. Would that make sense?
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.
good idea, will give a try within the next PR
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.
Left two suggestions which don't necessarily need to be addressed in this PR. Approving already.
This PR is trying to provide a POC implemenation of a DKG protocol, following the one as suggested at
https://github.com/dashpay/dips/blob/master/dip-0006/bls_m-of-n_threshold_scheme_and_dkg.md#distributed-key-generation-dkg-protocol
This is the attempt trying to address the routing issue of have 50% threshold in BLS set (maidsafe/sn_routing#2045)