Comment on page
SSV DKG Client
The SSV-DKG tool is yet to be audited. Please refrain from using it on mainnet.
Distributed Key Generation is a cryptographic process that aims to solve the problem of coordinating
Nparties to cryptographically sign and verify signatures without relying on Trusted Third Parties. The process is demonstrated to be successful in computing a key pair in the presence of a number
Tattackers in a decentralized network. To do so, this algorithm generates a public key, and a secret key of which no single party knows, but has some share of. The involvement of many parties requires Distributed key generation to ensure secrecy in the presence of malicious contributions to the key calculation.
SSV DKG leverages drand's DKG protocol implementation, which traditionally relies on a peer-to-peer network for operator communication. The
ssv-dkgintroduces a communication layer centered around an Initiator figure to facilitate inter-operator communication, eliminating the reliance on a fully decentralized network. To mitigate potential centralization risks and malicious actors, the system employs a robust mechanism of signatures and signature verifications, as elaborated in the Security notes section.
ssv-dkgclient, stakers can initiate DKG ceremonies to generate new BLS key pairs for Ethereum validators and the key shares required for SSV network registration.
In order for the DKG protocol to execute successfully:
- all the chosen Operators must be running the
ssv-dkgtool as Operators
- separately, an Initiator (one of the Operators, or a separate entity), starts the DKG ceremony by running the
ssv-dkgtool with the
- the tool automatically exchange data between the interested parties, as outlined in the Architecture section, until the key shares are created
NOTE: Threshold is computed automatically using 3f+1 tolerance.
- 1.The Initiator creates an initiation (
init) message, signs it and sends it to all Operators
- 2.Upon receiving initiation message, the Operators check Initiator message signature and create their own DKG identity:
- new DKG secrets created
- if a new
initmessage with ID byte is received and at least 5 minutes have passed from the last
initmessage with the same ID, the DKG instance is recreated
Exchangesigned message containing the DKG identity is created
- Operator replies to
initmessage with the created
- 3.The Initiator collects all responses into one combined message and verifies signatures
- 4.The Initiator sends back the combined message to all Operators
- 5.Each Operator receives combined
exchangemessage and starts the DKG process, responding back to Initiator with a signed
- 6.The Initiator packs the deal bundles together and sends them back to all Operators
- 7.Operators process
dkgbundles and finish the DKG protocol of creating a shared key. After DKG process is finished each Operator has a share of the shared key which can be used for signing
- 8.Each Operator signs a deposit root, using its share of the shared key, then encrypts the share with the initial RSA key and sends it to the Initiator
- 9.Initiator receives all messages from Operators with signatures/encrypted shares and prepares the deposit data with a signature and save it as JSON file
- 10.Initiator prepares a payload for SSV contract
- 11.After the deposit is successful and SSV contract transaction is accepted, Operators can continue with their duties using their share of the distributes key
ssv-dkgcan handle multiple DKG instances, it saves up to
MaxInstances(1024) up to
MaxInstanceTime(5 minutes). If a new
ssv-dkgtries to clean instances older than
MaxInstanceTimefrom the list. If any of them are found, they are removed and the incoming is added, otherwise it responds with an error, saying that the maximum number of instances is already running.
It is important to briefly explain how the communication between DKG ceremony Initiator and Operators is secured:
- 1.Initiator is using RSA key (2048 bits) to sign
initmessage sent to Operators. Upon receiving the signature, Operators verify it using public key included in the
initmessage. If the signature is valid, Operators store this pub key for further verification of messages coming from the Initiator(s).
- 2.Operators are using RSA key (SSV Operator key - 2048 bits) to sign every message sent back to Initiator.
- 3.Initiator verifies every incoming message from any Operator using ID and Public Key provided by Operators' info file, then Initiator creates a combined message and signs it.
- 4.Operators verify each of the messages from other Operators participating in the ceremony and verifies Initiator's signature of the combined message.
- 5.During the DKG protocol execution, the BLS auth scheme is used - G2 for its signature space and G1 for its public keys