[Consensus] Foundation for DKG and Threshold Signatures

[Olshansk]

Objective

Prepare the consensus module for Distributed Key Generation (DKG) and Threshold SIgnatures (TS) implementation in the future.

Though neither of these mechanisms is going to be fully implemented in the near future, it could potentially require major design changes and decisions when the time comes. The objective of this issue is to determine what low-hanging fruit exists that can be implemented today that could have a lower impact in the future when the codebase is more mature.

Origin Document

See Issue #109 - BLS Signature Aggregation as background on why DKG and TS are not being implemented today.

State of the Industry

This is meant to be a starting list of pointers but not an exhaustive set of research references.

hot-stuff/libhotstuff

The Github Library used to benchmark the original whitepaper did not use a TS library since one was not available at the time of writing. See the following comment found here:

Frost DKG - Zcash Foundation

The Zcash Foundation is moving to an algorithm called FROST DKG which has a good introductory article by Coinbase written here.

Practical Threshold Signatures - DFINITY

The original HotStuff whitepaper references Victor Shoup's paper on Practical Threshold Signatures.

Victor Shoup and other leading cryptographers, such as Jens Groth, in the space currently work at DFINITY so similar is likely to be found there too. Example.

HotPOKT - Pocket

Our team at Pocket has spoken with the team at meter.io which also implemented a variation of Hotstuff in Go.

One of the big learning points here is that DKG and TS in the context of linear complexity consensus algorithms is difficult because of the time it takes to distribute keys, aggregate signatures, rotate keys, etc, while trying to maintain sub-second or single-digit second consensus mechanism.

This is applicable to most smart contract L1 chains where immediate (i.e. short block times) finality is necessary. However, like other PoS chains implementing BFT consensus, instant (i.e. not deterministic) finality does not necessarily need to imply immediate (i.e. quick) finality.

Since Pocket Network's utility (i.e. quick relays) are optimistic in their poorf lifecycle and do not require short block times, this creates an opportunity to leverage longer block times in exchange for much larger validator networks (potentially more > 100,000 validators) with increased security (DKG + TS).

The following diagram is only presented for demonstration purposes as a high-level idea and not for technical pruposes:

Note to the curious reader: If you're reading this and want to get hyped, imagine the impact on interoperability if Pocket can serve as a foundational layer with a high-validator count and a high level of security given that it is already responsible for providing access to other blockchains.

Goals / Deliverables

• Decide & design to what extent the codebase should be updated today (versus in the future) to support TS and DKG
• If appropriate, implement key rotation used by validators during consensus. As shown in the diagram above, this can be done as part of the HotPOKT consensus flow.
• Add unit Tests where appropriate
• Documentation: Documentation (text and/or diagram) of the Test's functionality, source code structure, and implementation.
• Follow up work: Github issues and/or milestones + TODOs for future work needed for exhaustive Byzantine behaviour testing.

Non-goals

• Full implementation of either DKG or TS

Creator: @Olshansk
Co-Owners: ???

[DragonDmoney]

I love the early initiative and foresight. I think it is likely that POKT is turned into some type of bridge in the future, and laying out the groundwork for that whilst the codespace is new and malleable will certainly help in the long run.

Note: if you want to learn more about TH signatures in bridges, I would recommend looking at Chainflip