The BLS-Distributed Key Generation is a mechanism where nodes communicate with each other to generate BLS keys and use the same to achieve consensus on events/data. For communication among nodes there needs to be layer that facilitates the transport of messages. Quic-p2p was our choice for this transport layer which would now make users of this crate have no hassle in running a DKG session.

The current coverage report only shows a test coverage of 50%.

We may need more tests to cover changing membership, but with simple net setup and not requiring qp2p.

as a note, the previous tests using members doesn't contribute to the test coverage.

For reference, we could have a look at https://github.com/dan-da/brb/blob/master/src/net.rs.
With some usage/tests are in: https://github.com/dan-da/brb_dt_orswot/blob/master/tests/brb_orswot_net.rs
for a fake network testing.

Is your feature request related to a problem? Please describe.
When working with BLS keys it's necessary to keep track of the secret share index. BLS signatures need the index of the secret share that signed them when they are combined to form the final aggregate secret key.

Describe the solution you'd like
I'd like the Outcome struct to include our index as I don't want to keep the key generator around after I've finished creating the key.

Describe alternatives you've considered
Alternatives are querying the key generator for the index, but as I mentioned, once I have an outcome, I want to throwaway the key generator.

merged into the aes crate

The aesni crate has been merged into the aes crate. The new repository
location is at:

<https://github.com/RustCrypto/block-ciphers/tree/master/aes>

AES-NI is now autodetected at runtime on i686/x86-64 platforms.
If AES-NI is not present, the aes crate will fallback to a constant-time
portable software implementation.

To prevent this fallback (and have absence of AES-NI result in an illegal
instruction crash instead), continue to pass the same RUSTFLAGS which were
previously required for the aesni crate to compile:

RUSTFLAGS=-Ctarget-feature=+aes,+ssse3

See advisory page for additional details.

failure is officially deprecated/unmaintained

The failure crate is officially end-of-life: it has been marked as deprecated
by the former maintainer, who has announced that there will be no updates or
maintenance work on it going forward.

The following are some suggested actively developed alternatives to switch to:

• anyhow
• eyre
• fehler
• snafu
• thiserror

See advisory page for additional details.

Typo pending_messags > pending_messages occurs 10 times in src/key_gen/mod.rs

First instance is
https://github.com/maidsafe/BLS-DKG/blob/988d9f0c3362d57cfd5bc807a1aad37252e03eb6/src/key_gen/mod.rs#L319

crate has been renamed to block-cipher

This crate has been renamed from block-cipher-trait to block-cipher.

The new repository location is at:

<https://github.com/RustCrypto/traits/tree/master/block-cipher>

See advisory page for additional details.

A happy path test case is needed to test that the DKG mechanism works properly when we pair it up with Quic-p2p. This will allows us to configure any transport layer(quic-p2p) parameters before letting this out in the wild :)

Following are the pending test related suggestions from the PoC PR #2 that shall be addressed asap:

1, Comment on tests.rs lines 213 to 235
Ideal for making this test more robust: iterate over all THRESHOLD + 1 - sized subsets of sig_shares
and check that they produce valid signatures and also that the signatures

2, #2 (comment)
We should also test that combining less that THRESHOLD + 1 shares is not enough.

3, #2 (comment)
Same here: we should test that this work with any THRESHOLD + 1 sized subset of dec_shares and that it doesn't work if we have less that THRESHOLD + 1 shares.

Do we have decentralized example of bls-dkg?

merged into the aes crate

The aes-soft crate has been merged into the aes crate. The new repository
location is at:

<https://github.com/RustCrypto/block-ciphers/tree/master/aes>

AES-NI is now autodetected at runtime on i686/x86-64 platforms.
If AES-NI is not present, the aes crate will fallback to a constant-time
portable software implementation.

To force the use of a constant-time portable implementation on these platforms,
even if AES-NI is available, use the new force-soft feature of the aes
crate to disable autodetection.

See advisory page for additional details.

Hello Maidsafe Team !
Thanks you for providing this complex implementation for BLS_DKG in rust.

I need some guidance...
Currently this library works with BLS12 381 curve....
But I want to understand, is it feasible to do changes by replacing BLSTTC or BLST crate with BN254 (aka alt_bn128) one..

So that we can perform BLS signature on BN curve...???

Reference : BLS Signature on BN Curve

net2 crate has been deprecated; use socket2 instead

The net2 crate has been deprecated
and users are encouraged to considered socket2 instead.

See advisory page for additional details.

Is it possible to start with one set of members and then at some point about the list of members but still keep the same collective public/secret key.

For example, one scenario might be to start with the initial set of member S1. Then use that to encrypt some data. At a later point then some members might leave the group and some other might join. However, since the data where encrypted with the S1 set of members, it would make sense to use the same key to decrypt the original data even though the members have changed.

Hi Team !!
Thanks you bls-dkg to provide such a complex implemetation in rust.

I would like to request if it is possible to convert public key and signature into G1 and G2 format.
So that I can verify dkg-bls signature in the ethereum smart contract.

Currently I tried to input those PK and SIG in python ECC library
Line 40 , 51

but it produces G1 and G2 of length 115 but this smart contract Line 38 verifyBLSTest()

accepts G1 G2 value of length 77.

In short do any way to get G1 G2 values in for required length ??

A test case must be written to check the behavior of the DKG mechanism at scenarios where nodes get randomly dropped in an ongoing session. Nodes getting dropped/delays in reaching back are real-world problems in the network that we would need to account for before we have the crate being employed.

spin is no longer actively maintained

The author of the spin crate does not have time or interest to maintain it.

Consider the following alternatives (both of which support no_std):

• conquer-once
• lock_api (a subproject of parking_lot)
  • spinning_top spinlock crate built on lock_api

See advisory page for additional details.

what's reason to remove quic? https://github.com/maidsafe/bls_dkg/pull/58/commits

Currently, a peer that has been concensused complained will be removed directly.
To follow up the paper more closely, those being complained peers shall be allowed to prove themselves within the Justification phase (currently being skipped and TODO comments put).

To provide this feature, there are two points need to be considered:
1, For those being complained due to invalid contribution, shall we allow a new value to be provided, or only encryption keys (to decrypt the recorded encrypted contribute).
2, For those being complained due to non-contribution. How do we let them provides proposal & acknowledgment and let us know about it and have all members catch up with this.

It is possible that this Justification phase turned out to be not necessary. And in this case, the whole encryption key stuff could be removed from the code block (a simplification gain)

The property KeyGen.parts (code below) is misleading and may benefit from being renamed proposal_states since the type being used is ProposalState.

https://github.com/maidsafe/BLS-DKG/blob/988d9f0c3362d57cfd5bc807a1aad37252e03eb6/src/key_gen/mod.rs#L306-L307

There's a struct Part (code below) which seems like KeyGen.parts would be, but it's not, it's a set of ProposalState

https://github.com/maidsafe/BLS-DKG/blob/988d9f0c3362d57cfd5bc807a1aad37252e03eb6/src/key_gen/mod.rs#L73-L84

KeyGen.parts is used in generate_keys (code below) to get a variable called part which is a ProposalState and not a Part. That's very confusing to me!

https://github.com/maidsafe/BLS-DKG/blob/988d9f0c3362d57cfd5bc807a1aad37252e03eb6/src/key_gen/mod.rs#L876-L880

It's especially confusing since Part and ProposalState both have the property commitment so could easily be using the wrong commitment without knowing it. Is it worth changing those properties to Part.our_commitment and ProposalState.proposed_commitment so they cannot be accidentally used interchangeably?

arr! macro erases lifetimes

Affected versions of this crate allowed unsoundly extending
lifetimes using arr! macro. This may result in a variety of
memory corruption scenarios, most likely use-after-free.

See advisory page for additional details.

Currently it requires:

type Signature: Clone + Eq + Ord + Hash + Serialize + DeserializeOwned + Debug;

Consider removing the Ord and Hash bounds if they are not necessary. Those bounds prevent using e.g. ed25519_dalek::Signature as the signature (requires wrapper).

Currently it doesn't seem to complete at all. Alternatively, it should return an error in that case.

directories is unmaintained, use directoriess-next instead

The directories crate is not maintained any more;
use directories-next instead.

See advisory page for additional details.

Following are the pending API related suggestions from the PoC PR #2 that shall be addressed asap:

1, #2 (comment)
return type of generate_key, more explicit error or just an option

2, #2 (comment)
have one API function for finalize_contribute and finalize_complaint

crate has been renamed to qp2p

This crate has been renamed from quic-p2p to qp2p.

The new repository location is:

<https://github.com/maidsafe/qp2p>

See advisory page for additional details.