Distributed Key Generation (DKG)

The Distributed Key Generation (DKG) protocol is a fundamental component of various applications that prioritize data privacy and security. It ensures the secure generation of asymmetric cryptographic keys in a distributed manner, preventing any single entity from having complete access to sensitive key information. Some of the applications that can benefit from DKG include:

1. Private Voting: DKG can be employed to create secure voting systems where individual votes remain confidential, preventing unauthorized access or manipulation.

2. Private Funding: Applications dealing with financial transactions and investments can use DKG to secure sensitive financial data.

3. Social Recovery: DKG can aid in securely recovering lost or forgotten passwords or keys without compromising user data privacy.

Demo (EVM):

Public Folder

Architecture

Desired Properties:

The DKG protocol implementation requires three critical properties:

• Homomorphism: The ability to perform operations over ciphertexts, allowing value commitments from multiple participants to be combined into batched values.
• Verifiability: Verification of the correctness of the encryption process, ensuring that a given value was encrypted accurately to a specific ciphertext.
• Robustness: The system should withstand the failure of up to N−T validators, who may either fail to provide a decryption share or provide an invalid decryption share.

Workflow and Actors:

1. Chairperson: The Chairperson is the one who create commitee, defines parameters, including T (the number of committee members) and N (the minimum required active committee members to run the protocol).
2. Committee Member: Dedicated members who serve the community by participating in the DKG mechanism. They contribute random sources for key generation and are essential for decryption processes. In a Threshold DKG scheme, trust relies on T out of N committee members.
3. Requester: An individual or entity seeking to use the DKG protocol to secure their data. Requesters can request the public key generated by the council for data encryption.

Contracts

• Committee: The Committee smart contract allows the creation of DKG committee, which consists of a list of member (identified with their Mina public key) and a threshold config for the committee. These data are stored in on-chain through the roots of merkle trees defined as in the following diagram.

• DKG: The DKG smart contract allows the creation of public keys, which is achieved after a 2-round contribution ceremony from all members in the committee. These public keys can then be requested to use in the Threshold Homomorphic Encryption module of other contract/zkApp. And in order to response to this request, T out of N (committee's threshold) members from the committee need to contribute their calculation to produce the final result. No information about the secret parts are exposed to the on-chain environment througout this process.

• Request: The Request contract allow a Requestor contract to request usage of a key generated by the DKG contract for their specific use cases, to track the request status, and to fetch the final result of the request. Initially, any requestor is able to create a request, additional whitelist or fee charging scheme are for the future work.

Contributions

Besides the architecture design based on specified requirements, we introduce some additional contributions to the development of zkApps:

• A multi-action reducer:

  • Enabling a smart contract to process multiple types of Action with the dispatch-reduce pattern.
  • Every action is dispatched
  • All pending actions are reduced into a merkle tree to ensure they are recored on-chain.
  • One can choose to execute a [set of] action with the similar type in any order they want [with recursive proof].

• Different supporting libraries: @auxo-dev/auxo-libs

  • Dynamic Array data type for Field, Scalar, Group, etc.
  • CustomScalar data type for efficient representation in Field[].
  • Bit255 data type for representing 255-bit string in encryption module.
  • IPFSHash data type.

Future Work

1. Business Model: Implementing a payment system where requesters pay for the usage of keys generated through the DKG protocol. This can enable sustainability and incentivize participation.

2. Automation: Exploring automation possibilities, i.e. Chainlink Automationg, to streamline and enhance the efficiency of the DKG protocol. This could include automating key generation processes and interactions with the smart contract.

In summary, Distributed Key Generation (DKG) serves as a critical component in enhancing privacy and security in various applications. Its core properties of homomorphism, verifiability, and robustness ensure the secure generation and use of cryptographic keys, enabling applications such as private voting, private funding, and social recovery to thrive while preserving user data and decision confidentiality. As DKG continues to evolve, future work can focus on establishing sustainable business models and further automating the protocol to improve its efficiency and usability.