> For the complete documentation index, see [llms.txt](https://cvnnt.gitbook.io/documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cvnnt.gitbook.io/documentation/algorithms-and-cryptography/dkg-frost.md).

# DKG FROST

{% hint style="info" %}
Note: This chapter is currently under development.
{% endhint %}

Covenant uses Collator node sMPC groups and DKG-based FROST algorithm to verify cross-chain messages.  

Collator sMPC group reaches consensus on data when their FROST threshold signature is successfully aggregated.

**FROST** (Flexible Round-Optimized Schnorr Threshold Signatures) is a cryptographic protocol that allows a group of *n* participants to generate a single Schnorr signature where a threshold of *t* participants must cooperate. It is designed to be efficient by minimizing network communication when no one misbehaves while still being secure against malicious actors. A successful outcome is a single, aggregate signature that is indistinguishable from a standard Schnorr signature.

**DKG** (Distributed Key Generation) is a cryptographic process in which multiple parties contribute to the calculation of a shared public and private key set. 

Covenant utilizes decentralized and trustless FROST protocol implementation by means DKG is performed without centralized dealer entity  and FROST is implemented without centralized coordinator in a decentralized and competitive manner, where each participant acts as a dealer and coordinator and aggregates a threshold signature.

Covenant system utilizes DKG as a basis for FROST as this algorithm does not rely on 3rd parties or on single power projecting authority. 

<figure><img src="https://content.gitbook.com/content/IrCs7se0X60UkwSdNUVw/blobs/OTaBNGSFEHWpNizhjRIQ/unknown.png" alt=""><figcaption><p>Covenant utilizes VSS (Verifiable Secret Sharing) using DKG (Distributed Key Generation) to eliminate any single power projecting entity. (<em>In the DKG scheme on this diagram only the shares distributed by participant P1 and P3 are shown, but all participants function similarly)</em>.</p></figcaption></figure>

### Covenant system DKG (no dealer) FROST (no coordinator) protocol flow

### FROST cryptographic dependencies

FROST protocol depends on:

* Prime-order Group
* Cryptographic hash function

Covenant utilizes FROST(secp256k1, SHA-256) ciphersuite.

### Preliminaries

Let $$\mathbb{G}$$ be a group of prime order $$q$$ in which the Decisional Diffie-Hellman problem is hard, and let $$g$$ be a generator of $$\mathbb{G}$$.&#x20;

#### sMPC group preliminaries:

sMPC group of participants is established before starting FROST protocol.&#x20;

sMPC group participant amount is $$n$$ Participants while Threshold Participants Amount $$t$$ is required to provide aggregated threshold signature.

Each sMPC group participant has a scalar unique identifier, `participant_id` $$i$$ ($$i\neq 0$$ ), assigned at the grouping stage, which FROST requires as one of pre-defined values.

Participant signing key $$sk\_i$$, which is a scalar value representing the $$i$$-th Shamir secret share of the group signing key $$s$$, which FROST requires as second pre-defined value along with $$i$$, is produced for each Participant via DKG protocol covered in this chapter.

### FROST general description

#### Shamir *t*-threshold secret sharing protocol

FROST on its basis relies on Shamir $$t$$-threshold secret sharing logic. For a Shamir $$t$$−threshold secret sharing protocol a polynomial $$f$$ of $$(t − 1)$$ degree is created, where the first coefficient is equal to the complete secret $$s$$ (private key), and all coefficients of remaining degree are picked randomly. Then, for each participant $$P\_i$$ the point on the polynomial $$f(i)$$ is calculated, and the result is communicated via a private secure channel to the participant $$P\_i$$. If t participants reveal their respective points, the polynomial $$P$$ can thus be found and calculating $$f(0)$$ will return the private secret. The protocol scheme is based on Lagrange interpolation, which allows to find the unique degree $$(t − 1)$$ polynomial given exactly $$t$$ points.

#### Additive Secret Sharing (non-interactive Shamir secret sharing)

While Shamir secret sharing and derived constructions require shares to be points on a secret polynomial $$f$$ where $$f(0) = s$$, an additive secret sharing scheme allows a set of $$\alpha$$ participants to jointly compute a shared secret $$s$$ by each participant $$P\_i$$ contributing a value $$s\_i$$ such that the resulting shared secret $$s$$ is the summation of each participant’s share:

$$s =\displaystyle\sum\_{i=1}^\alpha s\_i$$

Consequently, additive secret sharing can be performed non-interactively; each participant directly chooses their own $$s\_i$$. FROST protocol utilizes a non-interactive mechanism for participants to locally convert additive shares of the form $$s = \displaystyle\sum\_i s\_i$$ to polynomial (Shamir) form, as $$\dfrac{s\_i}{\lambda\_i}$$ are Shamir secret shares of the same $$s$$, where the $$\lambda\_i$$ are Lagrange coefficients. In FROST, participants use this technique during signing operations to non-interactively generate a nonce that is Shamir secret shared among all signing participants.

### **FROST protocol general flow overview**

FROST protocol generally consists of 3 steps:

**1.** Round 1. Commitment. Round one involves each participant generating nonces and their corresponding public commitments.

**2.** Round 2. Signature share generation

Participants broadcast the message to be signed and produce their signature shares.

**3.** Signature share aggregation

Each Participant competes to aggregate a valid threshold signature to be first to sign the transaction.

Covenant system utilizes a preprocess decentralized DKG step before FROST protocol processing to produce shared master key pair ($$\<msk, mpk>$$) and Participant signing keys $$sk\_i$$ for each Participant.

\
**Preprocess: DKG (Producing Shamir secret shares)**

**1.** Preprocess: DKG (distributed key generation)

FROST protocol requires sMPC group to be uniquely identified and have distributed master key pair ($$\<msk, mpk>$$) by means each Participant $$P\_i$$ should have two pre-defined values (input values): non-zero unique identifier $$i$$ and Participant signing key $$sk\_i$$, which is a scalar value representing the $$i$$-th Shamir secret share of the group signing (master) key $$s$$. Participants already have their $$i$$ produced on the grouping stage, so DKG is used to produce $$sk\_i$$ for each $$P\_i$$.&#x20;

DKG is a process of collectively generating distributed master public key $$mpk$$ and corresponding distributed secret key $$msk$$ collectively shared via Shamir secret share $$sk\_i$$ for each sMPC group participant $$P\_i$$.

VSS (Verifiable Secret Sharing) process is utilized during DKG by each participant to verifiably distribute data with every other participant.

DKG generally consists of three phases:

**a)** Sharing Phase: During the first phase, each participant in $$P\_i \in P$$ selects a randomly chosen secret $$s\_i$$ and subsequently uses Feldman’s VSS to share this secret among all parties. The verification procedure of Feldman’s protocol enables the parties to check that received shares are indeed valid.

**b)** Dispute Phase: During the dispute phase, each party that received one or more invalid shares in the previous phase uses a non-interactive proof technique to convince other parties about the fact that the issuer violated the protocol.

**c)** Key Derivation Phase: At the beginning of the phase, a set of qualified parties $$Q \subseteq P$$ is formed. A party $$P\_i$$ is part of $$Q$$ if and only if it:

1. &#x20;broadcasted the required information during the sharing phase and
2. &#x20;no party broadcasted a valid dispute against $$P\_i$$ during the dispute phase.

In other words, the set $$Q$$ contains all parties which correctly shared their secret and should thus contribute to form the distributed master key pair $$⟨msk,mpk⟩$$.&#x20;

For $$\forall$$ party $$P\_i \in Q$$ the values $$h^{s\_i}$$, related to the randomly chosen secrets $$s\_i$$, are either revealed or recovered and used to derive the master public key $$mpk$$. Using Lagrange interpolation, $$msk$$ can be optionally computed after pooling the shares from $$t$$ parties.&#x20;

During the DKG process $$n$$ VSS processes run in parallel where in every process another Participant is the dealer. Each dealer picks a random secret to share, and the overall secret is the sum of all random secrets. The public value or public key is the product of each individual public key. Finally each participant knows their part of the secret, and a share of every other secret, but no participant has the whole combined secret. DKG works on a round basis, and in Pedersen’s implementation, one round is needed in absence of faults to establish the shared public-private keypair.