Threshold crypto is attracting a lot of attention currently from a practical perspective:

For all these use cases, ideally we need large set of participants: the larger the size is the more trust we can have in the system. However, doing a DKG (the setup phase) over a large set of participants is unpractical (because of $O(n^2)$ complexity)

In a permission-less environment participants are associated with weights, and the idea is to randomly sample participants such that the totality of the selected nodes have a weight superior to a given threshold

Doing weighted DKG is extremely impracticable as we usually "emulate" as many nodes as one's weight, which comes back to the scalability issue.

Note: Ferveo from Anoma is maybe the first DKG that tackles this nicely. It is still open questions for us whether it is practicable and the trade offs they are making.

Ideally we want DKGs to be compatible with schemes that are already existing on other blockchains so interopability is given. The natural use case for DKGs is threshold signature: if the signature is compatible with well known schemes then the network can act as a participant easily in these other blockchains

Many more criterias defined in the Holy Grail DKG page.

Current definitions in the Holy Grail DKG - in collaboration with ConsensusLab as well.

Status: Final stages of reviewing - done

Collaboration with Aniket Kate.

It's about making a better DKG that fits the holy grail DKG properties as much as possible.

Milestones Q1’22

Implementing a full DKG in a SNARK. There are multiple steps

See tracking document

Milestone Q1’22: