Consider a group of D nodes that together run the DKG. We assign a unique index i ∈ [0, 1, ..., D-1] to each node (according to the canonical ordering from the Protocol State).

<aside> 💡 We explicitly consider the case where some DKG participants are actively malicious, trying to undermine the DKG protocol. The DKG protocol is designed to handle this as long as the number of malicious participants is below a fixed threshold. Currently, we have fixed that threshold to a protocol constant t = floor((n-1)/2)

</aside>

Hence, we assume (axiom) that the following conditions are satisfied:

• Safety: the number of malicious DKG participants nodes is less or equal than t
• Liveness: there are at least t+1 honest participants

High-Level Design

• DKG requires two distinct channels of communication:

  1. (encrypted) direct 1-to-1 communication
  2. Smart contract: broadcast public 1-to-all other DKG members. This can be thought of as a whiteboard:
     • every member needs to be able to broadcast.
     • a member that can't broadcast (intentionally or because it is offline) is considered malicious, and the protocol is robust up to t malicious actors.
     • every member needs to be able to read broadcasted messages.
     • a honest member that can't read messages won't get the same info as other honest members that could read messages. At the end of the protocol we need at least t+1 honest participants to agree on the final results (otherwise, the upcoming threshold signature/random beacon halts). This is only possible if at least t+1 honest participants are able to read the broadcast messages.
     • Following the same argument above, we need at least t+1 honest participants to read every broadcast message consistently (2 participants must not get a different version of the same message).
     • The broadcast need to be authenticated (every receiver needs to be able to verify the origin of the message, since everyone is able to broadcast).
     • The broadcast channel must be unique per round of the protocol (i.e per epoch) to avoid replays. If we re-use the same channel, the uniqueness can be achieved by adding a different ID for each round

• There are three phases of message exchange (involving 1-to-1 communication as well as posting to and reading from the whiteboard). For details, see Distributed Key Generation API .

• After the three phases of message exchange, all nodes locally compute

  1. public keys shares for all participating DKG nodes (including themselves)
  2. a group public key
  3. their own private key share

  For D DKG nodes, we define the vector PublicKeys as

  • Each element is a public key (crypto.PublicKey)
  • PublicKeys holds D+1 elements:
    • PublicKeys[i] is the public keys share for DKG participant with index i ∈ [0, 1, ..., D-1]
    • PublicKeys[D] is the GroupPublicKey

• Each node saves its own DKG private key share to a secure location (local disk is fine).

• Each node now posts the PublicKeys it locally computed to the whiteboard.

  • The DKG protocol guarantees that the PublicKeys` vectors posted by all honest participants are identical.
  • However, other PublicKeys vectors might be posted by malicious participants.

  The DKG smart contract must now identify the PublicKeys vector which from the honest participants. We assume that honest participants are strictly larger than t. Therefore, the DKG smart contract can simply count which PublicKeys vector got posted at least t+1 times, which then has to be the one from the honest participants (this is guaranteed by the current value of t ). If such a vector exists, it is unique (with the current t value).

  If no PublicKeys vector has reached a count of t+1 then the DKG has failed and an error needs to be returned.

• DKG smart contract includes the single PublicKeys vector from the honest participants in the EpochCommitted system event (see Epoch Preparation Protocol)

The last step completes the DKG

Whiteboard Messaging

Broadcast messages are implemented in the DKG smart contract. The DKG protocol requires that, for a given phase, whiteboard messages are reliably and consistently delivered to all nodes. Messages may be received in any order within a phase.

A DKG node must be able to guarantee it has received all the messages of a phase to be able to determine that phase has ended. For each epoch, the epoch smart contract determines in advance the point at which each phase ends, defined in terms of a consensus view. These are emitted in the EpochSetup service event as DKGPhase1FinalView and so on.

The DKG contract does not differentiate between messages based on the DKG phase they are part of. (⚠️ This is a change from a previous specification ⚠️)

Each DKG instance is uniquely identified by a DKG ID, composed of the chain ID of the Flow instance it is running in and the epoch counter of the epoch for which the DKG is being computed (not the current epoch while the DKG is running!). All messages must include this ID to prevent replay attacks from other DKG instances.