# Zero Coordination DKG
*Thank you Guanglei Deng from RockX and Nicolas Gailly from Protocol labs*

One of the great benefits of SSV is the ability to adopt advance key management schemes like Distribuited-Key-Generation(DKG).
DKG tranditionally requires some sort of manual coordination efforts to sync between the different participants, identify them and then use the results.

Recently SSV adopted an SSV-Improvement proposal ([SIP](https://github.com/bloxapp/SIPs/blob/main/sips/dkg.md)) for a generalized DKG protocol that lives within the SSV network, allowing anyone to chose any SSV node for a DKG committee.
Other DVT implementations like Obol went the manual route which presents significant limitations as it's heavily dependent on social coordination. This also opens up issues in key resharing/ voluntary exits.

The full SSV-DKG integration is lead by SSV and RockX following a [grant proposal](https://snapshot.org/#/mainnet.ssvnetwork.eth/proposal/0x6a21f05dad33c1bb872112c4a28226ad68ffe1b1a9e2fa881a7b288ce2fa122f) to implement the GG20 protocol.

## How Ditribuited-Key-Generation works?
Although [SIP-1](https://github.com/bloxapp/SIPs/blob/main/sips/dkg.md) treats the key generation protocol as a black box (meaning a variety of protocols can be adopted), most work by:

1. exchanging a series of messages between the participants in which each participant creates a local secret
2. The local secret from #1 is used to generate and share intermediary secrets to the others participans
3. Step 2 finishes when each participan has it's own locally generated secret and a set of intermediary secrets received by others
4. Each participan can now reconstruct its final share + the global public key associated with the distribuited private key
5. Most modern DKG algorithms add some verification which makes sure non of the participants cheated and all have valid signatures at the end or the whole protocol is aborted.

`The full private key is never constructed or combined in any of the participants`


## The coordination problem
The above requires some coordination, namely:
* how do the participants talk with eachother
* what encryption do they use to communicate and hide the secret shares
* how does the final result is received and used by the user

With SIP-1 we tried to solve all of those issues using the existing SSV infrastructure.

## Design goals
* Zero manual coordination
* Permissionless
* Contract friendly (for verification and validation)

With the above in mind we used the existing SSV registry contracts to establish for each operator an ethereum address for signing and a RSA2048 public encryption key (all already used within the existing SSV network).
With those 2 elements in place + an existing P2P network we could now solve the coordination problem

## SIP-1 Generalized DKG support in SSV
Each node in the SSV network will run a DKG service in it, listening to a sepcific pubsub topic, for DKG messages aimed to it.

**A new DKG session** starts off by an Init DKG message signed by anyone wanting to initiate that session.
Abuses can be prevented by aggressive peer scoring and rate limits. In the future SSV payment/ staking might increase those limits.
Private SSV nodes could configure specific whitelisted addresses than can generate DKG with high rate limits.

// Init is the first message in a DKG which initiates a DKG
type Init struct {
    // OperatorIDs are the operators selected for the DKG
    OperatorIDs []uint64
    // Threshold DKG threshold for signature reconstruction
    Threshold uint16
    // WithdrawalCredentials used when signing the deposit data
    WithdrawalCredentials []byte
    // Fork is eth2 fork version
    Fork [4]byte
}

**Distribuited key ceremony** starts right after the init message is sent, for the purposes of SIP-1 we treat it as a black box. It can vary in message structure, number of rounds and other technical elements. All distribuited key ceremonies end the same, every operator managed to calculate and populate the following struct:

type KeyGenOutput struct {
    Share           [*bls.SecretKey]
    OperatorPubKeys map[types.OperatorID]*bls.PublicKey
    ValidatorPK     [48]byte
}

SIP-1 enables identifiable blame for missbehaving parties which is crucial to reflect the initiator of the DKG what went wrong.

**Deposit data signature** follows right after the ceremony ends, in this phase each operator partially signs the calculated deposit data (using the withdrawal credentials from the init message).
Once a threshold of partial signatures are received, each operator can reconstruct a valid deposit data signature.

**DKG output is signed** using the operator's ethereum address (found in the operator registry contract)

    // Output is the last message in every DKG which marks a specific node's end of process
type Output struct {
    // RequestID for the DKG instance (not used for signing)
    RequestID [24]byte
    // EncryptedShare standard SSV encrypted shares
    EncryptedShare []byte
    // SharePubKey is the share's BLS pubkey
    SharePubKey []byte
    // ValidatorPubKey the resulting public key corresponding to the shared private key
    ValidatorPubKey [48]byte
    // DepositDataSignature reconstructed signature of DepositMessage according to eth2 spec
    DepositDataSignature [96]byte
}

type SignedOutput struct {
    Data *Output
    Signer uint64
    Signature [65]byte
}

**Broadcasting (of each node) its SignedOutput to the network**

## Verifcation

There are 2 types of verifications taking place during the entire DKG process:
1. Key generation verfication (VSS) - done internally by the DKG implementation
2. Output verification done by the user/ smart contract

If a party of 4 operators participated, 4 different signatures over the Output struct will be streamed to the entire SSV network.
A user will receive all of them, using his SSV node RPC, and will be able to verify:
1. The corret participants participated - Since each operator has a public encryption key there needs to be at least 1 non malicious operator to singal that out and the DKG won't happen/ there will be a missing SignedOutput message signed by the non malicuos party
2. The output paylod is valid and not changed - we can think of various trustless protocols that will want to verify that the result of the DKG is not tempered with. Since all output objects are signed it can easily be verified
3. The signed deposit data matches the validator public key
4. The correct withdrawal credentials were used

*The 1 thing which can't be verified is a malicious operator put an invalid encrypted share (his own share) in the output.
As long as 2/3 of the operators are honest (as the min requirement for SSV in general) that will not compromise the validator*

## Contract friendly verification
A contract can self verify the signed output object for each operator for:
1) Selected operators are valid
2) Withdrawal credentials
3) Shares are not tempered
4) validator public key
5) DKG was successful

This smart contract friendlyness is important to enable various DKG use cases without limits.