# Architecture

Mishti Network has distributed keys, generated by Distributed Key Generation (DKG). It is curve-agnostic. Currently, it supports three curves:

**Secp256k1 **for miscellaneous operations such as key derivation

**BabyJubJub** for efficiently provable encryption to Mishti Network

**BLS **for internal use cases involving asynchronous threshold signatures

Mishti network's core cryptographic primitive is the elliptic curve (EC) point multiplication by its distributed secret. When a user provides an EC point, Mishti checks whether the user is allowed to get the answer for this point, and if so Mishti responses with the answer. This point x scalar multiplication is decentralized in the following manner:

#### DKG

Standard DKG where node `i`

learns an additive share `f_i`

of some secret polynomial `f`

, along with `f(i)`

. `f(0)`

is the private key of the network. The threshold `t`

of `n`

nodes who can collective act on behalf of the network is determined by the degree of polynomial `f`

.

#### Multiplication

If user requests to learn some point `P$`

multiplied by the private key `f(0)`

, one simply sends `P`

to `t`

nodes who all return `f(i) * P`

and a DLEQ proof of correct multiplication.

I.e., each node sends `S = f(i) * P`

and a DLEQ proof that both:

its response

`S = f(i) * P`

its public key

`K_i = f(i) * G`

are for the same `f(i)`

.

*Note: these nodes behave identically as how they would in the centralized case, except instead of multiplying their private key by **P** they multiply their private key share, **f(i)**, by **P**.*

After receiving the multiplications and verifying their DLEQ proofs (see the Verify section), the user computes `f(0) * P`

with Lagrange interpolation:

where `l`

is a publicly known function for giving each node Lagrange coefficients.

*Note: **l(i)** is the "Lagrange* *basis at 0" for node **i*

#### Verification

To ensure nodes can be held accountable for giving an invalid result of `f(i) * P`

a discrete-log equality proof is used to check their results are all right. Otherwise, a malicious node could untraceably cause the netowrk to give incorrect results. With this accountability, nodes are incentivized to give the right result since if they are known to be unreliable, users will not use them and they would not collect any fees from users.

To verify the proofs, the relayer verifies the DLEQ proof and also checks public outputs. To check its public outputs The user must check that the two points in the proof are the node's actual response and actual public key `K_i`

.

Last updated