Skip to content
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

Merged
merged 13 commits into from
Apr 14, 2020
Merged

DKG proof of concept implementation #2

merged 13 commits into from
Apr 14, 2020

Conversation

maqi
Copy link
Member

@maqi maqi commented Mar 23, 2020

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)

@maqi maqi changed the title DKG proof of concept implementation WIP DKG proof of concept implementation Mar 23, 2020
@maqi maqi changed the title WIP DKG proof of concept implementation DKG proof of concept implementation Apr 6, 2020
Yoga07
Yoga07 previously approved these changes Apr 13, 2020
Copy link
Contributor

@Yoga07 Yoga07 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! 👍

src/key_gen/mod.rs Outdated Show resolved Hide resolved
src/dev_utils/peer.rs Outdated Show resolved Hide resolved
@maqi maqi requested a review from madadam April 13, 2020 08:28
Copy link
Member

@dirvine dirvine left a 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

src/key_gen/tests.rs Outdated Show resolved Hide resolved
src/key_gen/tests.rs Outdated Show resolved Hide resolved
Cargo.toml Outdated Show resolved Hide resolved
Cargo.toml Outdated
bincode = "1.1.4"
failure = "~0.1.5"
lazy_static = "~1.2.0"
rand = "~0.4.2"
Copy link
Member

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.

Copy link

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.

Copy link
Member Author

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)

Copy link

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.

Cargo.toml Outdated Show resolved Hide resolved
Cargo.toml Outdated Show resolved Hide resolved
Copy link

@madadam madadam left a 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,

Cargo.toml Outdated Show resolved Hide resolved
Cargo.toml Outdated Show resolved Hide resolved
Cargo.toml Outdated Show resolved Hide resolved
Cargo.toml Outdated Show resolved Hide resolved
Cargo.toml Outdated Show resolved Hide resolved
}

// 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.
Copy link

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 Show resolved Hide resolved
/// 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.
Copy link

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?

Copy link

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

Copy link
Member Author

@maqi maqi Apr 14, 2020

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.

src/key_gen/message.rs Outdated Show resolved Hide resolved
src/key_gen/tests.rs Outdated Show resolved Hide resolved
@S-Coyle
Copy link
Member

S-Coyle commented Apr 14, 2020

@maqi A note on licensing of this repo - the license file says BSD-3, but the license blurb at the top of each of your source code files says GPL v3.

@dirvine can you confirm it's deliberate that this repo is BSD-3 only, and not MIT or BSD-3 as per the majority of our other repos.

@dirvine
Copy link
Member

dirvine commented Apr 14, 2020

You are right @S-Coyle it should be dual bsd-3/mit

Copy link
Member

@dirvine dirvine left a 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

@S-Coyle
Copy link
Member

S-Coyle commented Apr 14, 2020

@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

src/dev_utils/peer.rs Outdated Show resolved Hide resolved
/// 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);
Copy link

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.

Copy link
Member Author

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

dirvine
dirvine previously approved these changes Apr 14, 2020
// 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>(
Copy link

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?

Copy link
Member Author

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

madadam
madadam previously approved these changes Apr 14, 2020
Copy link

@madadam madadam left a 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants