EVM

    Ethereum Virtual Machine
ZKP

    Zero-Knowledge Proof
DKG

    Distributed Key Generation
VSS

    Verifiable Secret Sharing
PVSS

    Publicly Verifiable Secret Sharing
zk-SNARK

    Zero-Knowledge Succinct Non-interactive Arguments of Knowledge
zk-SNARKs

    Zero-Knowledge Succinct Non-interactive Arguments of Knowledge
zk-STARKs

    Zero-Knowledge Succinct (Scalable) Transparent Arguments of Knowledge
R1CS

    Rank-1 Constraint-System
QAP

    Quadratic Arithmetic Program
VOC

    Verifiable Off-Chain Computation
EVM

    Ethereum Virtual Machine
NIZK

    Non-interactive Zero-Knowledge Proof
TID

    Threshold Information Disclosure
CP-ABE

    Ciphertext-Policy Attribute-Based Encryption
PoS

    Proof of Stake
MPC

    Multiparty Computation
DSL

    Domain-Specific Language

# Distributed Key Generation with Smart Contracts using zk-SNARKs

Michael Sober  0000-0002-9612-9022 Christian Doppler Laboratory for Blockchain
Technologies for the Internet of Things TU HamburgHamburgGermany
<EMAIL_ADDRESS>,  Max Kobelt  Christian Doppler Laboratory for
Blockchain Technologies for the Internet of Things TU HamburgHamburgGermany
<EMAIL_ADDRESS>,  Giulia Scaffino  0000-0001-5680-3003 Christian Doppler
Laboratory for Blockchain Technologies for the Internet of Things TU
WienViennaAustria<EMAIL_ADDRESS>,  Dominik Kaaser
0000-0002-2083-7145 TU HamburgHamburgGermany<EMAIL_ADDRESS>and
Stefan Schulte  0000-0001-6828-9945 Christian Doppler Laboratory for
Blockchain Technologies for the Internet of Things TU HamburgHamburgGermany
<EMAIL_ADDRESS>
(2023)

###### Abstract.

Distributed Key Generation (DKG) is an extensively researched topic as it is
fundamental to threshold cryptosystems. Emerging technologies such as
blockchains benefit massively from applying threshold cryptography in
consensus protocols, randomness beacons, and threshold signatures. However,
blockchains and smart contracts also enable further improvements of DKG
protocols by providing a decentralized computation and communication platform.

For that reason, we propose a DKG protocol that uses smart contracts to ensure
the correct execution of the protocol, allow dynamic participation, and
provide crypto-economic incentives to encourage honest behavior. The DKG
protocol uses a dispute and key derivation mechanism based on Zero-Knowledge
Succinct Non-interactive Arguments of Knowledge (zk-SNARKs) to reduce the
costs of applying smart contracts by moving the computations off-chain, where
the smart contract only verifies the correctness of the computation.

Distributed key generation, zero-knowledge proofs, smart contracts, blockchain

††journalyear: 2023††copyright: acmcopyright††conference: The 38th ACM/SIGAPP
Symposium on Applied Computing; March 27-31, 2023; Tallinn,
Estonia††booktitle: The 38th ACM/SIGAPP Symposium on Applied Computing (SAC
’23), March 27-31, 2023, Tallinn, Estonia††price: 15.00††doi:
10.1145/3555776.3577677††isbn: 978-1-4503-9517-5/23/03††ccs: Security and
privacy Cryptography††ccs: Computer systems organization Distributed
architectures

##  1\. Introduction

Threshold cryptography allows for the shared usage of cryptosystems with no
central authority (Desmedt, 1994). A threshold cryptosystem distributes trust
among all participants, while conventional cryptosystems often involve a
trusted third party. Fundamental to threshold cryptosystems is the ability to
generate distributed private keys by executing a DKG protocol. Such a protocol
allows a group of participants to generate a distributed private key where
each party only possesses a share of the private key while not having any
knowledge about the private key itself. DKG protocols have been subject to
ongoing research over the last two decades (see Section 2). Notably, the
latest spike of interest in blockchain technology paved the way for new
applications and improvements.

Blockchain technology is not only the underlying technology of
cryptocurrencies like Bitcoin (Nakamoto, 2008) but has also found applications
in various other fields (Mollah et al., 2020; Dai et al., 2019). A blockchain
is a tamper-resistant distributed ledger of transactions managed by a peer-to-
peer network of nodes. The second generation of blockchains, e.g., Ethereum
(Wood et al., 2014), allows the execution of so-called smart contracts, which
are deterministic programs stored on the blockchain. The decentralized nature
of blockchains makes them an excellent application for threshold
cryptosystems, e.g., for consensus, public randomness, or threshold signatures
using a DKG protocol (Kokoris Kogias et al., 2020).

DKG protocols are not only important for applications in the field of
blockchain technology but also the blockchain, especially smart contracts, can
help to improve DKG protocols (Schindler et al., 2019; Stengele et al., 2021).
Usually, in DKG protocols, misbehaving participants are excluded from the
protocol’s further execution and not held accountable for their actions. Thus,
trying to attack the protocol may seem beneficial as it does not entail
serious consequences. As we will discuss in the paper at hand, a smart
contract can augment a DKG protocol with crypto-economic incentives and the
possibility for dynamic participation such that participants are encouraged to
execute the protocol and behave honestly.

Further, external parties need to verify that a given public key was generated
according to the DKG protocol’s specification and belongs to a specific group
of participants that generated the key. While it is immediately apparent to
the participants, this verification process is more difficult for parties
external to the protocol. Therefore, we discuss the utilization of smart
contracts to ensure the correct execution of the DKG protocol and provide a
transparent view of the actions taken by each participant.

While the application of smart contracts introduces additional overhead, there
are mechanisms to keep it as low as possible. These include Verifiable Off-
Chain Computations with the help of Zero-Knowledge Proofs, where a smart
contract only needs to verify a short proof and does not need to perform all
calculations on the blockchain (Körbel et al., 2021).

Therefore, we propose a DKG protocol based on smart contracts. The smart
contract allows the participants to execute the different phases of the
protocol by facilitating the execution. The underlying blockchain constitutes
the communication channel, whereby no direct connection between the
participants is necessary. Further, the smart contract offers a lightweight
dispute mechanism by enabling VOC with zk-SNARKs. This mechanism allows for
the punishment of misbehavior such as slashing provided collateral, thus
making the participants accountable for their actions. Accordingly, we provide
the protocol’s specification and create a prototypical implementation for
Ethereum Virtual Machine (EVM)-based blockchains. Further, we evaluate the
costs of using the smart contract as well as the performance and memory usage
for generating the proofs.

The rest of this paper is structured as follows: in Section 2, we present some
background information and the underlying concepts. Then, we propose the
protocol in Section 3 and describe its implementation in Section 4. We
evaluate the protocol in Section 5 and discuss the related work in Section 6.
Finally, we conclude the paper in Section 7.

##  2\. Background

In this section, we present the concepts behind the proposed protocol. For
this, we briefly describe the most important aspects of Secret Sharing,
Distributed Key Generation, and Zero-Knowledge Proofs.

###  2.1. Secret Sharing

Secret Sharing was introduced by Shamir (Shamir, 1979) to divide a secret $S$
into $n$ pieces such that $k$ pieces or more are required to recover $S$.
Providing only $k-1$ parts, it is not possible to recover $S$ and does not
leak any information about $S$. Initially, a dealer picks a polynomial
$f(x)=c_{0}+c_{1}x+\dots+c_{k-1}x^{k-1}$ of degree $k-1$ in which $c_{0}=S$
and chooses the remaining coefficients $c_{1}\dots c_{k-1}$ randomly (Katz and
Lindell, 2020).

After that, a dealer evaluates $f(x_{i})$ with $x_{i}=1\dots n$ over a finite
field $\mathbb{F}_{p}$ and sends the points $(x_{i},f(x_{i}))$ to the
participants through a private channel. For $k$ distinct points, there is only
one polynomial that passes through all of these points. Therefore, it is
possible to use polynomial interpolation, e.g., Lagrange interpolation, to
reconstruct the polynomial. With the collaboration of $k$ shareholders, the
shareholders can reconstruct the polynomial and evaluate $f(0)$ to recover
$S$.

Shamir’s scheme has the disadvantage that the dealer is a trusted party that
can distribute incorrect shares. Further, shareholders can provide invalid
shares during the reconstruction of the secret. This issue led to the
emergence of Verifiable Secret Sharing (VSS) schemes. Ever since VSS first has
been mentioned by Chor et al. (Chor et al., 1985), many different VSS schemes
followed, e.g., (Feldman, 1987; Rabin and Ben-Or, 1989; Pedersen, 1991a;
Stadler, 1996; Schoenmakers, 1999), which exhibit distinct characteristics. In
the following discussion, we limit ourselves to non-interactive VSS schemes,
more specifically to Feldman’s VSS scheme, as no additional communication
between the dealer and the other participants is necessary.

In Feldman’s VSS scheme, only the dealer sends messages, while all
shareholders can verify if the received share is correct without sending any
messages. In addition to sending the shares to each participant, the dealer
broadcasts public commitments $c_{i}G$ for $0\leq i\leq k-1$ to the
coefficients of the random polynomial, where $G$ is a generator of a cyclic
group of elliptic curve points. Every shareholder has access to the public
polynomial $F(x)$ defined as

$F(x)=c_{0}G+c_{1}Gx+\dots+c_{k-1}Gx^{k-1}.$

A shareholder can use this public polynomial to verify that the received share
is correct by evaluating $f(x_{i})G=F(x_{i})$.

###  2.2. Distributed Key Generation

In threshold cryptography, there is no single party possessing all the
necessary information to encrypt, decrypt or sign a message. Instead, a
threshold cryptosystem requires that a certain subset of size at least $t$ out
of $n$ parties need to collaborate on these actions. Unfortunately, with VSS
schemes, there is still the problem that a dealer is a central authority that
knows the shared secret. A dealer can still act without collaborating with
other parties if it does not discard the secret, thus leading to some
centralization of trust.

DKG enables multiple parties to collectively generate a distributed private
key with no central point of trust. Each party only has a secret share of the
private key, but neither party knows the complete private key, which is also
never recovered. While many different DKG protocols already exist (Pedersen,
1991b; Abraham et al., 2021; Dehez-Clementi et al., 2021; Das et al., 2021;
Gennaro et al., 1999; Kate and Goldberg, 2009; Kate et al., 2012; Kokoris
Kogias et al., 2020), we limit ourselves to Pedersen’s DKG (Pedersen, 1991b)
as it has been widely used to create threshold cryptosystems. Further, it
forms the basis of our proposed protocol (see Section 3.5).

Pedersen’s DKG protocol allows a set of participants
$P=\\{P_{1},\dots,P_{n}\\}$ to generate a distributed private key where at
least $t$ participants need to collaborate to use the private key. For that,
every party $P_{i}$ executing the DKG protocol shares a signed secret
$s_{ij}=f_{i}(j)$ with all the other parties $P_{j}\in P\setminus P_{i}$ using
Feldman’s VSS scheme. Upon receiving an invalid share $s_{ij}$ from any other
participant, a participant can issue a complaint by publishing $s_{ij}$ and
the signature. More than $t$ complaints against a specific participant ensure
its disqualification, i.e., the exclusion from the protocol’s execution. A
participant $P_{j}$ can compute its share of the distributed private key by
calculating $s_{j}=\sum_{i=1}^{i=n}s_{ij}$. Finally, the participants can
compute the shared public key via the previously published commitments to the
random polynomials by calculating $H(x)=\sum_{i=1}^{i=n}F_{i}$ and evaluating
$H(0)$.

###  2.3. Zero-Knowledge Proofs

A ZKP allows a prover to convince a verifier that a statement is true without
revealing any information, i.e., the verifier has zero knowledge besides the
validity of the statement (Goldwasser et al., 1989). Many distinct blockchains
utilize ZKPs to enhance privacy or scalability (Hopwood et al., 2016; Bonneau
et al., 2020). Today the most popular ZKP systems comprise zk-SNARKs (Ben-
Sasson et al., 2014), Zero-Knowledge Succinct (Scalable) Transparent Arguments
of Knowledge (zk-STARKs) (Ben-Sasson et al., 2019), and Bulletproofs (Bünz et
al., 2018). With the help of these proof systems, it is possible to verify
computational integrity, i.e., whether the output of a program given some
public and private inputs is correct according to its specification without
re-executing the whole program to verify the given output. Instead, a verifier
only needs to verify a small proof (Kosba et al., 2020).

The verification complexity and proof size of zk-STARKs and Bulletproofs
depend on the computational complexity of the program, while for zk-SNARKs, it
is constant. A disadvantage is that zk-SNARKs depend on a trusted setup,
whereas this dependency is non-existent for zk-STARKs and Bulletproofs.
However, the short proof size and the constant verification complexity make
zk-SNARKs an excellent candidate for the application within smart contracts.
Therefore, in the following, we only focus on zk-SNARKs.

The first practical implementation of zk-SNARKs was the Pinocchio protocol
(Parno et al., 2013), followed by Groth16 (Groth, 2016), which uses pairing-
friendly elliptic curves to validate the proofs. For the protocol, a program
is transformed into an arithmetic circuit, then a Rank-1 Constraint-System
(R1CS), and finally encoded as a Quadratic Arithmetic Program (QAP). The
output of a program is correct if the respective solution to the QAP is also
valid. The succinctness and zero-knowledge aspect of such proofs come from
using random sampling and homomorphic encryption.

As discussed in Section 4.2, the proposed DKG protocol requires executing
elliptic curve operations within a circuit. Therefore, we need to clarify
possible limitations which affect our solution. The limiting factor to
implementing elliptic curve cryptography within a circuit is that a circuit
uses modular arithmetic over a finite field $\mathbb{F}_{r}$. Therefore, only
elliptic curves defined over $\mathbb{F}_{r}$ are usable within a circuit.
These curves can then enable the implementation of specific cryptographic
protocols (Bellés-Muñoz et al., 2021). Another possibility is to create a
cycle of elliptic curves where the proof is generated using another curve and
verify this proof in a circuit using $\mathbb{F}_{r}$.

##  3\. System

In this section, we propose a DKG protocol that uses smart contracts for
decentralized computation and communication in combination with zk-SNARKs to
reduce its costs. We start with a brief overview and continue with an
explanation of the communication model, cost model, smart contracts, and
dynamic participation. After that, we explain the design of the protocol and
provide an exact specification, including the different phases: Share
Distribution, Dispute, and Key Derivation.

The execution of the protocol starts with the Share Distribution phase. Each
participant generates a secret and distributes the shares among the other
participants using Feldman’s VSS and a smart contract. Afterward, the protocol
reaches the Dispute phase, during which the participants verify the received
shares and issue disputes against dealers who distributed invalid shares. The
accused dealer can generate a Zero-Knowledge Succinct Non-interactive
Arguments of Knowledge (zk-SNARK) to justify that the distributed share is
correct and the dispute is unjustified. Not resolving a dispute leads to
exclusion from the protocol and crypto-economic punishments. Finally, the
protocol reaches the Key Derivation phase, in which every participant uses the
correctly distributed shares to derive the shared public key. For submitting
the public key to the smart contract, any participant can generate a zk-SNARK
to prove that the derived public key is correct.

###  3.1. Communication Model

We assume a synchronous communication model in which all messages are
delivered within a fixed time bound $\Delta$ and consider the blockchain a
public broadcast channel where parties can send and receive messages.

Further, instead of establishing point-to-point connections between
participants, the participants use the public broadcast channel to exchange
direct messages. For that, the participants generate a public/private key pair
and disclose the public key to all other participants using the blockchain.
The participants use the public key and some unique round-specific information
to generate a shared key with its counterparts. This shared key is then used
as part of a symmetric key encryption procedure to encrypt communication over
the public channel.

###  3.2. Cost Model

Additionally, we assume that a public blockchain requires transaction fees to
be paid with the blockchain’s native currency. The transaction fees
incentivize miners to spend their computational resources to create new blocks
and execute transactions. Further, the transaction fees help to protect the
platform from misuse since wasting resources also entails considerable costs.

The transaction fees depend on the actual computation steps and required
storage space. As such, transactions which only transfer value between
different accounts incur lower transaction fees than transactions that trigger
the execution of a smart contract performing complex calculations or require a
lot of storage (Brandstätter et al., 2020). Especially, elliptic curve
operations are very cost intensive. Therefore, our DKG protocol uses zk-SNARKs
to move these computations off-chain.

###  3.3. Smart Contracts

Initially, the protocol requires a trusted setup ceremony, which is necessary
for using zk-SNARKs (see Section 2.3). This procedure generates the proving
and verification keys for the circuits of Alg. 1 and 2 (see Section 3.5) to
off-chain the computations for justification and key derivation. The execution
of the trusted setup generates a simulation trapdoor referred to as toxic
waste, which needs to be discarded because it would enable the generation of
fake proofs (Bowe et al., 2018). Therefore, it is recommended to use
Multiparty Computation (MPC) to distribute the trust among multiple parties
(Bowe et al., 2017). This approach ensures that as long as one honest party
discards its part of the secret, it prevents the possibility of recovering the
overall secret.

After executing the trusted setup ceremony, the smart contracts are deployed
on the blockchain. The protocol requires three different smart contracts: the
Justification, Key Derivation, and zkDKG contracts. The Justification and Key
Derivation contracts provide the same functionality as both contracts only
have to verify zk-SNARKs for the different circuits used during the Dispute
and Key Derivation phases of the protocol. They only differ with respect to
the inputs and verification keys. The zkDKG contract manages the whole
execution of the DKG protocol. The participants use it to distribute the
shares, issue disputes, justify their actions during disputes, and derive the
public key. As justification and key derivation are based on zk-SNARKs (see
Sections 3.5.2 and 3.5.3), the zkDKG contract interacts with the Justification
and Key Derivation contracts to verify the validity of the proofs.

Further, the zkDKG contract requires the configuration of different
parameters, including the addresses of the verification contracts, threshold,
time limits of the different phases, curve parameters, and others that might
be necessary to dynamically form the set of participants.

###  3.4. Dynamic Participation

Finally, after finishing the deployment of the smart contracts, different
parties can start the formation process to qualify as participants. In
contrast to conventional DKG protocols, which do not use a blockchain, several
options are available to dynamically form the set of participants, where we do
not want to limit ourselves to a specific one. Here, the zkDKG contract
defines and strictly enforces who is allowed to participate in the execution
of the protocol.

Among other things, one can imagine a permissioned setting in which the zkDKG
contract defines that only its owner can decide who is allowed to join. The
owner only has to provide a predefined list of the selected parties to the
smart contract. The zkDKG contract checks if the potential party is allowed to
join and only after successful authentication adds it to the current set of
participants. The problem here is that the owner represents a central
authority.

However, other permissionless mechanisms potentially allow everyone to join
without having a central authority. The zkDKG contract could implement a naive
mechanism to allow everyone to join until reaching a certain number of
participants as long as they deposit some tokens as collateral. However, this
approach is impractical in most cases since it does not provide any Sybil
resistance, which would allow anyone to register with multiple identities
(Douceur, 2002). In the worst case, a single party could register enough
identities to gain sole control and knowledge of the generated key.

An alternative solution is to let the potential participants stake tokens not
only as collateral but also to let the number of tokens decide who is allowed
to participate, as is done in systems based on Proof of Stake (PoS) (Kiayias
et al., 2017). Following this direction, the zkDKG contract specifies, e.g.,
that only the $n$ parties with the highest deposited stake may participate.
Should participants misbehave during the execution of the protocol, they might
get penalized by slashing their stake. This approach encourages participants
to behave honestly and improves Sybil resistance by encouraging the creation
of only one identity staking enough tokens. Another modification of this
approach would also allow regular token holders to delegate their tokens to
potential candidates to elect them as participants.

###  3.5. Protocol

After clarifying the necessary steps prior to the execution of the protocol,
we continue with its description and specification (see Protocol 1). For that,
we examine the Share Distribution, Dispute, and Key Derivation phases and
describe the different execution steps sequentially.

####  3.5.1. Share Distribution

A set of participants $P=\\{P_{1},\dots,P_{n}\\}$ generates a distributed
private key with threshold $t$ using a $zkDKG$ smart contract.

Protocol 1 Distributed Key Generation Protocol

  1. (1)

Share Distribution

    1. (a)

A participant $P_{i}\in P$ retrieves the threshold computed by the $zkDKG$
contract.

    2. (b)

$P_{i}$ generates a random polynomial $f_{i}(x)$ of degree $t-1$ and its
corresponding public polynomial $F_{i}(x)$ with coefficients
$C_{i}=\\{c^{i}_{0}G,...,c^{i}_{t-1}G\\}$.

    3. (c)

$P_{i}$ computes the set of shares $S_{i}=\\{f_{i}(j)\,|\,0<j<n,j\neq i\\}$
and encrypts each share $s_{ij}\in S_{i}$.

    4. (d)

$P_{i}$ calls the distribute function of the $zkDKG$ contract and provides
$C_{i}$ and $S_{i}$. The $zkDKG$ contract then verifies that:

      1. (i)

the distribution phase is ongoing,

      2. (ii)

$P_{i}$ has not already distributed $S_{i}$,

      3. (iii)

provided $|S_{i}|=|P\setminus P_{i}|$ shares,

      4. (iv)

$|C_{i}|=t-1$ coefficients

and otherwise reverts.

    5. (e)

The $zkDKG$ contract stores $c^{i}_{0}G$, $hash(C_{i})$, and $hash(S_{i})$ and
notifies $P$ that $P_{i}$ submitted a share.

    6. (f)

A participant $P_{j}\in P$ verifies the received share $s_{ij}$ by checking
that $F_{i}(j)=f_{i}(j)G=s_{ij}G$. If the share is invalid, $P_{j}$ continues
with Step 2 and otherwise with Step 3.

  2. (2)

Dispute (optional)

    1. (a)

$P_{j}$ calls the dispute function of the $zkDKG$ contract providing the index
$i$ of the disputee $P_{i}$ and $S_{i}$. The $zkDKG$ contract then verifies
that:

      1. (i)

the dispute phase is ongoing,

      2. (ii)

$P_{i}$ has not already been disputed,

      3. (iii)

$S_{i}$ matches the stored $hash(S_{i})$

and otherwise reverts.

    2. (b)

The $zkDKG$ contract notifies $P_{i}$ about the dispute including $i$, $j$,
$S_{i}$, and the time limit $\tau$ to justify.

    3. (c)

$P_{i}$ generates a zk-SNARK $\pi_{J}$ for the execution of Alg. 1 and uses
the justify function of the $zkDKG$ contract to submit $\pi_{J}$.

    4. (d)

The $zkDKG$ contract validates $\pi_{J}$ and if $\pi_{J}$ is valid resolves
the dispute. In case $\pi_{J}$ is invalid, the dispute remains unresolved.

  3. (3)

Key Derivation

    1. (a)

The $zkDKG$ contract verifies that the key derivation phase is ongoing.

    2. (b)

The $zkDKG$ contract checks for expired disputes and sets the coefficients of
excluded participants to zero.

    3. (c)

$P_{i}$ derives the public key $pk$ by calculating
$H(x)=\sum_{j=1}^{j=n}F_{j}$ and evaluating $H(0)$.

    4. (d)

Any participant generates a zk-SNARK $\pi_{R}$ for the execution of Alg. 2 and
uses the derive function of the $zkDKG$ contract to submit $pk$ and $\pi_{R}$.

    5. (e)

The $zkDKG$ contract verifies $\pi_{R}$, notifies $P$ about the successful
submission, and stores $pk$. If $\pi_{R}$ is invalid the zkDKG contract
reverts.

    6. (f)

The $zkDKG$ contract slashes disqualified participants.

After determining the participants, the actual execution of the protocol
starts with the Share Distribution phase (see Step 1 of Protocol 1) in which
every participant acts as a dealer in one of $n$ parallel executions of
Feldman’s VSS. For that, a participant $P_{i}$ has to retrieve the targeted
threshold $t$ from the zkDKG contract. The next step is to generate the random
polynomial $f_{i}(x)$ of degree $t-1$ and commit to the polynomial’s
coefficients to create its public counterpart $F_{i}(x)$ with coefficients
$C_{i}=\\{c^{i}_{0}G,...,c^{i}_{t-1}G\\}$. After that, a participant generates
its shares $S_{i}$ by computing $f_{i}(j)$ for every other participant
$P_{j}\in P\setminus P_{i}$. Each share $s_{ij}\in S_{i}$ gets encrypted using
a symmetric encryption scheme (e.g., the One-Time-Pad (Schindler et al.,
2019)). For that, a participant retrieves the public keys of the other
participants from the zkDKG contract to compute a shared key with each
participant using the Diffie-Hellman key exchange. Additionally, to ensure
that each shared key is unique, as it is necessary for the One-Time-Pad, we
concatenate it with $c^{i}_{0}G$ and take its hash as the shared key.

Following, a participant only has to broadcast its key shares $S_{i}$ and the
coefficients $C_{i}$ using the blockchain. For that, the zkDKG contract offers
a distributeShares function which is only callable for registered participants
during the Share Distribution phase of the protocol. The zkDKG contract also
ensures that the participants can only submit the right number of shares and
commitments. After these checks, the zkDKG contract stores $c^{i}_{0}G$ and
only the hashes of $S_{i}$ and $C_{i}$ to save storage costs. Further, the
zkDKG contract either notifies the participants, or the participants have to
poll the zkDKG contract to check the current status. After that, a receiving
participant $P_{j}$ can query the blockchain to get their share $s_{ij}\in
S_{i}$, decrypt it, and verify that $F_{i}(j)=f_{i}(j)G=s_{ij}G$. The Share
Distribution phase ends after reaching the timeout or if all participants
distributed their shares.

####  3.5.2. Dispute

After the distribution of the shares, the zkDKG contract reaches the Dispute
phase (see Step 2 of Protocol 1) of the protocol. If a participant receives an
invalid share, it can issue a dispute against the dealer, which then has to
justify by proving the correctness of the distributed share. A participant
issues disputes by calling the zkDKG contract’s dispute function and providing
the index of the dealer and the shares. The zkDKG contract verifies that it
reached the Dispute phase, checks if the hash of the provided shares matches
the stored hash and that no dispute concerning this dealer is ongoing.
Afterward, the zkDKG contract notifies the dealer or respectively the dealer
has to check if there are any ongoing disputes to resolve within a certain
time limit. This time limit is extended with every dispute to provide the
dealer enough time to justify.

This approach requires an additional interaction as the disputer first issues
a dispute, and the respective dealer then has to justify its actions. By
having the disputer generate a zk-SNARK and proving that the share is invalid,
it is possible to avoid additional interactions with the dealer. However, the
smart contract then needs to verify the inputs by the dealer during the Share
Distribution phase to ensure that the receiver can generate a zk-SNARK which
is only possible with correct input values. Therefore, it is better to leave
it to the dealer, who has the incentive to provide correct inputs, because
otherwise, the dealer cannot generate a valid zk-SNARK. This decreases the
costs since there is no need for the smart contract to verify the inputs.

The dealer continues with the generation of the zk-SNARK for Alg. 1 to prove
the correctness of the disputed share. For that, the dealer has to provide its
commitments $c$, secret key $sk$, public key $pk$, the public key of the
disputer $pk_{d}$, index $i$, encrypted share $s_{enc}$, and the hash of the
public parameters $h$. The costs of verifying the zk-SNARK increase with the
number of public input parameters. Therefore, we declare all public parameters
as private and only pass $h$ to verify them within the circuit by comparing
the hashes. Further, the dealer has to provide the commitments as uncompressed
points as decompressing is too complex within the circuit.

The program (see Alg. 1) for the justification of a disputed share starts by
checking whether the dealer knows the secret key to the provided public key.
After that, the program needs to verify that the dealer provided the correct
public input parameters. For that, it hashes the commitments and subsequently
hashes the result again with the remaining public input parameters. The hash
is then compared with the hash provided by the dealer and only if both hashes
match, it is possible to continue with the computation. Since the input
parameters are correct, the program can derive the shared key from $sk$,
$pk_{d}$, and $c$, to get the decrypted share $s_{dec}$. Finally, it checks if
the public polynomial evaluates to $s_{dec}G$ and returns the result.

After computing the proof, the dealer calls the justify function of the zkDKG
contract providing the previously computed proof. Initially, the zkDKG
contract checks if there is a dispute to resolve. After that, the zkDKG
contract computes the hash of the public input parameters and calls the
Justification contract. The zkDKG contract reverts if the proof is invalid,
and otherwise, it deletes the dispute and excludes the disputer for the
unjustified dispute.

Algorithm 1 Compute the justification that a distributed share is correct and
was wrongly disputed

1:function justify($c$, $sk$, $pk$, $pk_{d}$, $i$, $s_{enc}$, $h$)

2: $assert(mult(sk,G)==pk)$

3: $h_{c}\leftarrow hash(compress(c))$

4: $h_{c}\leftarrow hash(h_{c},pk,pk_{d},i,s_{enc})$

5: $assert(h==h_{c})$

6: $s_{dec}\leftarrow s_{enc}-sharedKey(sk,pk_{d},c)$

7: $actual\leftarrow mult(s_{dec},G)$

8: $expected\leftarrow evalPubPoly(i,c)$

9: return $actual==expected$

10:end function

11:function sharedkey(sk, pk, c)

12: $k\leftarrow scalarMult(sk,pk)$

13: return $hash(k,c[0])$

14:end function

15:function evalpubpoly(i, c)

16: $result\leftarrow Infinity$

17: for $k\leftarrow 1$ to $len(c)$ do

18: $result\leftarrow mult(result,i)$

19: $result\leftarrow add(c[len(c)-1-k]$

20: end for

21: return $result$

22:end function

####  3.5.3. Key Derivation

After reaching the time limit and allowing all participants to verify their
received shares and file a dispute, the final Key Derivation phase (see Step 3
of Protocol 1) of the protocol begins. A participant computes its overall
share of the distributed private key by summing up the shares received from
qualified participants, i.e., participants with no unresolved disputes. The
derivation of the public key is very cost-intensive using a smart contract.
Therefore, any participant can generate a zk-SNARK for Alg. 2 to derive the
public key off-chain and only submit the public key with the proof to the
zkDKG contract. A participant can derive the public key by computing
$pk=\sum_{j=1}^{j=n}c_{0}^{j}G$. However, generating a proof of this
computation also requires the hash of the public input parameters, i.e., the
first public coefficients, to verify that a participant uses the correct input
parameters.

After generating the proof, a participant calls the derive function of the
zkDKG contract providing the public key and the proof. The zkDKG contract
checks if it is in the Key Derivation phase and if participants have any
unresolved disputes. If a participant has unresolved disputes, it is excluded
by setting its first public coefficient to 0, i.e., the point at infinity.
Further, the zkDKG contract aborts the execution of the protocol if the number
of excluded participants exceeds the limit specified during deployment. In the
worst case, the number of participants and the threshold are equal, meaning
that a single failure is enough to make the distributed private key unusable.
This case requires a restart of the protocol with an updated set of
participants, i.e., misbehaving participants get replaced and lose their
collateral.

After that, the zkDKG contract computes the hash of all the stored first
coefficients and the submitted public key. Here also, only providing the hash
of the public inputs reduces the verification costs. Then, the zkDKG contract
calls the Key Derivation contract, providing the previously computed hash and
the public key. The zkDKG contract stores the public key if the proof is valid
and otherwise reverts. Another possibility is to let the zkDKG contract
optimistically accept the public key and introduce another dispute round after
the submission. This approach reduces the costs of submitting the public key
and the necessary resources since the generation and verification of the proof
are only required if the submitted public key is invalid. However, another
dispute round introduces further complexity.

Finally, the zkDKG contract allows multiple runs such that only a single
deployment is necessary to reduce the overall costs. It is up to the creator
of the zkDKG contract to specify when to execute a reset.

Algorithm 2 Derive the distributed public key

1:function derive($coef$, $h$)

2: $h_{c}\leftarrow hash(compress(coef))$

3: $assert(h==h_{c})$

4: $pk\leftarrow Infinity$

5: for $k\leftarrow 1$ to $len(coef)$ do

6: $pk\leftarrow mult(pk,coef[i])$

7: end for

8: return $pk$

9:end function

##  4\. Implementation

In this section, we describe the implementation of the client software and the
smart contracts available as open-source software on
GitHub111https://github.com/soberm/zkDKG.

###  4.1. Smart Contracts

We implemented the smart contracts in Solidity for the Ethereum smart contract
and decentralized application platform as it is today the most popular smart
contract platform with a wide range of tools and support (Belotti et al.,
2019). Further, Ethereum offers precompiled contracts for elliptic curve
addition, scalar multiplication, and pairing checks on the alt_bn128 curve,
which is necessary to verify the zk-SNARKs. Since the implemented prototype
works for Ethereum, it also supports other Ethereum-based blockchains out of
the box. However, the solution can also be implemented for other blockchains
as long as these platforms provide the necessary smart contract capabilities
and verification of zk-SNARKs.

We decided to implement the naive registration mechanism, which has already
been discussed in Section 3.4, as it is sufficient for the first prototypical
implementation and allowed us to focus on the more important parts of the
protocol. The zkDKG contract only allows participants to join until reaching a
certain number and requires them to provide collateral. The participants can
withdraw their placed collateral from the zkDKG contract after the execution
of the protocol if they behaved honestly.

The used threshold depends on the number of registered participants $n$. The
zkDKG contract computes $\lceil(n+1)/2\rceil$, specifying that the
reconstruction of the distributed private key requires more than half of the
registered participants. Further, we define that at least
$\lceil(2n+1)/3\rceil$ need to successfully share their secrets to enable the
submission of the public key to ensure that the system continues to work if
participants misbehave. These are usually the minimum requirements considering
the related work (see Section 6).

The zkDKG contract has to store the distributed shares and commitments of the
participants. Storage space on the blockchain is one of the biggest cost
factors. Therefore, the zkDKG contract keeps the storage as low as possible.
For that, the zkDKG contract only stores the first coefficients of each
participant directly in the smart contract’s storage while leaving the shares
and commitments as part of the calldata and only storing the Keccak256 hash,
which is considerably cheaper. Unfortunately, Ethereum does not provide a
cost-efficient implementation of arithmetization-oriented hash functions such
as MiMC (Albrecht et al., 2016), Poseidon (Grassi et al., 2021), or Rescue-
Prime (Szepieniec et al., 2020), which would make computing the hash inside a
circuit more efficient. The zkDKG contract emits an event to notify all
participants about the recent distribution from a specific participant.

The Justification and Key Derivation contracts required no manual
implementation. For these functionalities, the ZoKrates toolbox (see Section
4.2) provides the possibility to generate the verification contracts for the
respective circuits. These generated contracts use the precompiled contracts
provided by Ethereum to ensure the cost-efficient verification of the proofs.

###  4.2. Client

In addition to the smart contracts, we also provide a prototypical
implementation of the client software written in the Go programming language.
The client software is the off-chain component that uses the zkDKG contract to
generate the distributed private key. For generating the zk-SNARKs, we use the
ZoKrates (Eberhardt and Tai, 2018) toolbox, which enables zk-SNARKs on
Ethereum. ZoKrates offers a Domain-Specific Language (DSL) to create off-chain
programs and compile them to arithmetic circuits. After that, a client can use
ZoKrates to compute the witness for a specific circuit and generate a proof of
computation using the selected proving scheme. We selected Groth16 as the
proofs only consist of three elliptic curve points, which makes the
verification on the blockchain cheaper.

We used the DSL provided by ZoKrates to implement Alg. 1 and 2. The standard
library of ZoKrates already provides the implementation of elliptic curve
operations over the Baby Jubjub curve (Bellés-Muñoz et al., 2021). Hence, our
prototype uses this curve for elliptic curve cryptography. However, the
protocol supports any other curve as long as its base field matches the scalar
field of the curve used for the zk-SNARKs.

The client software uses Go language bindings for Ethereum smart contracts to
avoid boilerplate code and directly interact with the smart contracts through
their interfaces. Unfortunately, ZoKrates does not provide Go bindings.
Therefore, the client uses Docker to spin up new containers using the ZoKrates
Docker image and execute the respective commands to compute the witness and
generate the proofs for Alg. 1 and 2 within a container. The client retrieves
the result from the container to submit the proof to the zkDKG contract when
executing the justify or derive functions.

##  5\. Evaluation

After describing the implementation of the protocol, we use this section to
evaluate the protocol concerning costs, performance, and memory. The results
give insight into the overhead introduced by smart contracts and the necessary
resources needed to generate the proofs for justification and key derivation.

We execute the protocol ten times each before doubling the number of
participants until we reach 256 participants resulting in 70 protocol runs.
During the executions, we measure the gas consumption, proof generation time,
and memory usage. We perform the experiments on an Amazon EC2 instance
equipped with an Intel(R) Xeon(R) Platinum 8259CL running Ubuntu 22.04 using
eight cores with a clock speed of 2.50GHz. The machine has access to 32GB DDR4
RAM with a frequency of 3200MHz and an SSD with a throughput of 128 MB/s max.
Further, we spin up a local blockchain instance using Hardhat network 2.11.1
to deploy and run the smart contracts.

###  5.1. Costs

48163264128256$200$$400$$600$$800$$1{,}000$# of ParticipantsGas Consumption in
kGassharedisputejustifyderive

Figure 1. Gas consumption of the different phases

The execution of smart contracts on the Ethereum platform requires gas to
protect the platform by preventing the unnecessary consumption of resources.
Further, it serves as a reward for miners and incentivizes them to provide
their resources. However, this is not only an inherent characteristic of the
Ethereum platform but also of other smart contract platforms that need to
compensate miners. Therefore, we examine the costs incurred by the protocol
through executing smart contracts. We specifically look at the gas consumption
of the share, dispute, justify and derive functions.

The results (see Fig. 1) show that the share and dispute functions consume the
least amount of gas. The gas consumption of the share function averages 117
kGas for 4 participants reaching 505 kGas for 256 participants. These costs
are relatively low since the shares and commitments are part of the calldata,
while the zkDKG contract only stores the respective hash values. The dispute
function consumes even less gas since only the number of shares impacts its
gas consumption. Here we get 137 kGas for 4 participants and 269 kGas for 256
participants. However, the gas consumption of both functions increases
linearly with the number of participants that execute the protocol.

Further, we can see that the gas consumption of the justify function is
constant at 343 kGas respecting the number of participants. The reason is that
the justify function only expects the zk-SNARK consisting of three elliptic
curve points as input. The zkDKG contract does not execute any operations
based on the number of participants and removes the dispute upon successful
proof verification. However, the gas consumption increases slightly if
multiple disputes are stored since the smart contract needs to loop over all
inputs to find the respective index.

On the contrary, executing the derive function consumes more gas with an
increasing number of participants since the zkDKG contract needs to compute
the hash of all first coefficients to verify the zk-SNARK. The results show
that executing the derive function consumes 290 kGas for 4 participants up to
932 kGas for 256 participants. The number of expired disputed also increases
the gas consumption since the smart contract has to exclude the nodes before
deriving the public key. However, since disputes are an exception the impact
on gas consumption is low.

###  5.2. Performance

Not only do the smart contracts introduce additional overhead but also the
generation of zk-SNARKs for executing the justify and derive functions.
Although this approach saves costs when executing the smart contracts, all
participants have to use more of their local resources to generate the proofs.
An interesting aspect here is how much time a participant spends on generating
these proofs with an increasing number of participants.

The results of the executed experiments (see Fig. 2) show that proof
generation time for justification and key derivation linearly depends on the
number of participants. The proof generation time for key derivation gets
higher and grows faster than for justification. The difference is that the
former directly depends on the number of participants, while the latter
depends on the threshold. The generation of the proofs with 4 participants
takes 17 and 6 seconds, respectively. However, it already takes 292 and 451
seconds with 256 participants.

The proof generation time is usually not a large concern since blockchains are
not suitable for time-critical applications. However, configuring the timeouts
of the zkDKG contract requires attention to ensure that each participant has
enough time to generate the proofs, which is particularly important for
justification. Further, there is also a lot of optimization potential to
reduce the proof generation time by using arithmetization-oriented hash
functions and enabling multi-threading for ZoKrates.

481632641282568163264128256512# of ParticipantsProof Generation Time in
Secondsjustifyderive

Figure 2. Time to generate the proofs

###  5.3. Memory

Additionally, we investigate memory consumption during proof generation.
Memory consumption is usually a bigger concern than proof generation time
since memory consumption tends to be very high, considering that certain
computations (e.g., keccak256) are not very efficient with zk-SNARKs. Here, we
also examine how the number of participants influences memory consumption.

The measurements of memory consumption (see Fig. 3) show that it also
increases linearly with the number of participants. The memory consumption
behaves the same as the proof generation time. The generation of the proof for
justification consumes 1.39 GB for 4 participants up to 21.2 GB for 256
participants. For key derivation, we get a memory consumption of 452 MB for 4
participants and 27.7 GB for 256 participants. Therefore, we get a higher
entry barrier for the participants since they need the resources to ensure
they can generate the proofs. However, there is also potential to optimize
memory consumption by using arithmetization-oriented hash functions.

4816326412825651210242048409681921638432768# of ParticipantsMemory in
MBjustifyderive

Figure 3. Memory usage during proof generation

##  6\. Related Work

DKG protocols have always received a lot of attention in research, as they
constitute the primary building block of threshold cryptosystems. Although
blockchain technology already benefits from the application of threshold
cryptography, only a few works, to the best of our knowledge, explore the
application of smart contracts to enhance the protocols themselves.

In 1991, Pedersen (Pedersen, 1991b) introduced the first DKG protocol, which
allows multiple participants to generate a shared secret, where each party
only possesses a share of the secret and has no further information about the
shared secret. Every participant acts as a dealer in one of $n$ parallel
executions of Feldman’s VSS scheme (see Section 2). In later work, Gennaro et
al. (Gennaro et al., 1999) propose the Joint-Feldman DKG protocol, which
builds upon Pedersen’s DKG protocol but also ensures the uniform distribution
of the shared secret. Pedersen’s DKG protocol provides the foundation for our
proposed protocol. While it does not guarantee uniform randomness of the
shared secret, it remains secure, and only specific use cases require this
property (Gennaro et al., 2002, 2003).

Kate and Goldberg (Kate and Goldberg, 2009) propose the first DKG protocol,
which works in an asynchronous network setting. For that, the authors define
an asynchronous VSS scheme adopting a hybrid model for a network with
$n>3t+2f+1$ nodes, where an adversary may control $t$ nodes, and $f$ nodes can
fail. The VSS protocol includes a sharing and reconstruction protocol and a
recovery mechanism. The work shows that asynchronous DKG protocols require a
Byzantine agreement scheme. Therefore, the authors use a leader-based
agreement protocol in combination with the previously specified VSS scheme to
create a DKG protocol. In subsequent work, Kate et al. (Kate et al., 2012)
provide another protocol version to guarantee uniform randomness of the shared
secret. Further, they provide an implementation of the protocol and analyze
its performance.

In (Kokoris Kogias et al., 2020), the authors present another asynchronous DKG
protocol. However, the protocol enables the generation of a shared secret with
a dual $(f,2f+1)$ threshold with $f$ faulty participants. The authors
introduce an asynchronous high-threshold VSS scheme that separates the
reconstruction and recovery thresholds using an asymmetric bivariate
polynomial. This VSS scheme forms the basis for a weak DKG protocol which
eventually leads to a common key. By adding another mechanism to produce
common randomness and implementing an agreement protocol, the authors were
able to create the final asynchronous DKG protocol. Following a different
approach, Abraham et al. (Abraham et al., 2021) present a more efficient
solution improving on the results presented in (Kokoris Kogias et al., 2020).
Further, a work by Das et al. (Das et al., 2021) also promises improvements
while providing compatibility with current threshold cryptosystems.

Schindler et al. (Schindler et al., 2019) present a DKG protocol that uses
Ethereum as its communication and verification platform. The protocol is based
on the Joint-Feldman DKG protocol (Gennaro et al., 1999) and incorporates
further improvements from (Neji et al., 2016) to address biasing attacks. The
application of blockchain technology allows for the dynamic selection of
participants and the augmentation of the protocol with crypto-economic
incentives. Similar to our protocol (see Section 3.5), it uses Feldman’s VSS
to create and distribute the shares through the blockchain. However, there are
some differences regarding the management of disputes. The authors describe a
dispute mechanism where shareholders have to publish an invalid share and the
key to decrypt the share. A disputer has to provide a Non-interactive Zero-
Knowledge Proof (NIZK) to show the equality of two discrete logarithms to
ensure the correctness of the published key. After that, a smart contract can
then decrypt and verify the share. In our protocol, we stick to the notion
that a dealer needs to prove that it behaved correctly instead of letting the
shareholder prove that the dealer violated the protocol. Further, our protocol
requires that the dealer submits a zk-SNARK to prove that it behaved
correctly, which reduces the on-chain computations to a bare minimum. Despite
these differences, the approach by Schindler et al. comes closest to the work
at hand.

In (Stengele et al., 2021), the authors present a smart contract for Threshold
Information Disclosure (TID) based upon the work in (Schindler et al., 2019).
This approach allows users to disclose certain pieces of information
simultaneously such that all or no users disclose their information. The main
building block of the TID mechanism is a DKG protocol that allows for the
scheduled reconstruction of the private key. The authors extended and
simplified the DKG protocol by Schindler et al. (Schindler et al., 2019) to
generate a threshold ElGamal key pair for encryption and decryption,
ultimately making it more gas-efficient for the TID use case. After $t$ or
more participants have contributed to restoring the private key, any
participant can submit it to the smart contract. The smart contract enables
the disclosure of the information to the public by providing the information
and the submitted private key. While the authors were able to optimize the DKG
protocol, it is only applicable to specific use cases.

The authors of (Dehez-Clementi et al., 2021) propose a blockchain-based DKG
protocol that ensures privacy and traceability. The protocol utilizes a
blockchain, e.g., Bitcoin, with a pegged sidechain to improve scalability.
Here, the main blockchain only acts as the coordinator and enables the
anonymization of participants through a coin mixing service. The participants
lock their coins on the main blockchain, generate the shares using the
protocol from (Gennaro et al., 2003) and execute the sharing phase on the
pegged sidechain. Participants can also issue dispute claims on the sidechain
in case another participant violates the rules of the protocol. Finally, the
participants can unlock their coins after successfully executing the protocol.
While this solution provides better scalability through the pegged sidechain,
it also introduces additional complexity.

Zhang et al. (Zhang et al., 2022) present a publicly verifiable DKG protocol
that uses Ethereum for trustless computation and communication. The authors
explore the application of Ciphertext-Policy Attribute-Based Encryption (CP-
ABE) instead of Publicly Verifiable Secret Sharing (PVSS) to lower the
communication and computation overhead. Similar to PVSS, CP-ABE also enables
the participants to create a shared publicly verifiable secret. The protocol
only needs a single round as the smart contracts directly verify the proofs,
thus removing the dispute phase. Unfortunately, the protocol incurs very high
verification costs.

While our solution also entails a cost, time, and memory overhead, it is more
cost-efficient than the current solutions based on blockchain technology since
we move the expensive computations off-chain. Further, the availability of
additional precompiled contracts to enable complex cryptographic operations
besides the verification of the proof does not restrict our solution since
there is no need for the smart contract to execute these complex calculations
on the blockchain.

##  7\. Conclusion

Threshold cryptography is an essential building block for creating threshold
cryptosystems used by various applications, especially in the blockchain
field. In this work, we showed that blockchains also open new possibilities
which help to advance threshold cryptosystems by offering a platform for
decentralized computation and communication.

For this, we introduced a DKG generation protocol that uses the potential of
integrating blockchain technology into the protocol. Smart contracts enable
the dynamic participation of participants, augment the protocol with crypto-
economic incentives to establish accountability, ensure the correct execution
of the protocol and provide a public broadcast channel through the blockchain.
The protocol enables participants to use zk-SNARKs for justification and key
derivation to execute heavy computations off-chain to save gas costs. We
implemented the proposed protocol for the Ethereum smart contract platform and
evaluated it regarding costs, performance, and memory to demonstrate its
applicability.

In future work, we want to examine if there is potential to reduce the
overhead of using smart contracts even further and integrate improvements from
other protocols.

## Acknowledgment

The financial support from the Austrian Federal Ministry for Digital and
Economic Affairs, the National Foundation for Research, Technology, and
Development, and the Christian Doppler Research Association is gratefully
acknowledged.

## References

  * (1)
  * Abraham et al. (2021) Ittai Abraham, Philipp Jovanovic, Mary Maller, Sarah Meiklejohn, Gilad Stern, and Alin Tomescu. 2021.  Reaching consensus for asynchronous distributed key generation. In _2021 ACM Symposium on Principles of Distributed Computing_. ACM, 363–373.
  * Albrecht et al. (2016) Martin Albrecht, Lorenzo Grassi, Christian Rechberger, Arnab Roy, and Tyge Tiessen. 2016.  MiMC: Efficient encryption and cryptographic hashing with minimal multiplicative complexity. In _International Conference on the Theory and Application of Cryptology and Information Security_. Springer, 191–219.
  * Bellés-Muñoz et al. (2021) Marta Bellés-Muñoz, Barry Whitehat, Jordi Baylina, Vanesa Daza, and Jose Luis Muñoz-Tapia. 2021.  Twisted Edwards elliptic curves for zero-knowledge circuits.  _Mathematics_ 9, 23 (2021), 3022.
  * Belotti et al. (2019) Marianna Belotti, Nikola Božić, Guy Pujolle, and Stefano Secci. 2019.  A vademecum on blockchain technologies: When, which, and how.  _IEEE Communications Surveys & Tutorials_ 21, 4 (2019), 3796–3838.
  * Ben-Sasson et al. (2019) Eli Ben-Sasson, Iddo Bentov, Yinon Horesh, and Michael Riabzev. 2019.  Scalable zero knowledge with no trusted setup. In _39th Annual International Cryptology Conference_. Springer, 701–732.
  * Ben-Sasson et al. (2014) Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer, and Madars Virza. 2014.  Succinct $\\{$Non-Interactive$\\}$ zero knowledge for a von neumann architecture. In _23rd USENIX Security Symposium_. USENIX Association, 781–796.
  * Bonneau et al. (2020) Joseph Bonneau, Izaak Meckler, Vanishree Rao, and Evan Shapiro. 2020.  Mina: Decentralized Cryptocurrency at Scale.  https://minaprotocol.com/wp-content/uploads/technicalWhitepaper.pdf Accessed: 2022-06-24.
  * Bowe et al. (2018) Sean Bowe, Ariel Gabizon, and Matthew D Green. 2018.  A multi-party protocol for constructing the public parameters of the Pinocchio zk-SNARK. In _International Conference on Financial Cryptography and Data Security_. Springer, 64–77.
  * Bowe et al. (2017) Sean Bowe, Ariel Gabizon, and Ian Miers. 2017.  Scalable multi-party computation for zk-SNARK parameters in the random beacon model.  _Cryptology ePrint Archive_ (2017).
  * Brandstätter et al. (2020) Tamara Brandstätter, Stefan Schulte, Jürgen Cito, and Michael Borkowski. 2020.  Characterizing Efficiency Optimizations in Solidity Smart Contracts. In _2020 IEEE International Conference on Blockchain (Blockchain)_. 281–290.
  * Bünz et al. (2018) Benedikt Bünz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter Wuille, and Greg Maxwell. 2018.  Bulletproofs: Short proofs for confidential transactions and more. In _2018 IEEE Symposium on Security and Privacy_. IEEE, 315–334.
  * Chor et al. (1985) Benny Chor, Shafi Goldwasser, Silvio Micali, and Baruch Awerbuch. 1985.  Verifiable secret sharing and achieving simultaneity in the presence of faults. In _26th Annual Symposium on Foundations of Computer Science_. IEEE, 383–395.
  * Dai et al. (2019) Hong-Ning Dai, Zibin Zheng, and Yan Zhang. 2019.  Blockchain for Internet of Things: A survey.  _IEEE Internet of Things_ 6, 5 (2019), 8076–8094.
  * Das et al. (2021) Sourav Das, Thomas Yurek, Zhuolun Xiang, Andrew Miller, Lefteris Kokoris-Kogias, and Ling Ren. 2021\.  Practical asynchronous distributed key generation.  _Cryptology ePrint Archive_ (2021).
  * Dehez-Clementi et al. (2021) Marina Dehez-Clementi, Jérôme Lacan, Jean-Christophe Deneuville, Hassan Asghar, and Dali Kaafar. 2021.  A Blockchain-enabled Anonymous-yet-Traceable Distributed Key Generation. In _2021 IEEE International Conference on Blockchain_. IEEE, 257–265.
  * Desmedt (1994) Yvo G Desmedt. 1994\.  Threshold cryptography.  _European Transactions on Telecommunications_ 5, 4 (1994), 449–458.
  * Douceur (2002) John R Douceur. 2002\.  The sybil attack. In _International workshop on peer-to-peer systems_. Springer, 251–260.
  * Eberhardt and Tai (2018) Jacob Eberhardt and Stefan Tai. 2018.  Zokrates-scalable privacy-preserving off-chain computations. In _2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData)_. IEEE, 1084–1091.
  * Feldman (1987) Paul Feldman. 1987\.  A practical scheme for non-interactive verifiable secret sharing. In _28th Annual Symposium on Foundations of Computer Science_. IEEE, 427–438.
  * Gennaro et al. (1999) Rosario Gennaro, Stanisław Jarecki, Hugo Krawczyk, and Tal Rabin. 1999.  Secure distributed key generation for discrete-log based cryptosystems. In _International Conference on the Theory and Applications of Cryptographic Techniques_. Springer, 295–310.
  * Gennaro et al. (2002) Rosario Gennaro, Stanislaw Jarecki, Hugo Krawczyk, and Tal Rabin. 2002.  Revisiting the distributed key generation for discrete-log based Cryptosystems.  _RSA Security’03_ (2002).
  * Gennaro et al. (2003) Rosario Gennaro, Stanislaw Jarecki, Hugo Krawczyk, and Tal Rabin. 2003.  Secure applications of Pedersen’s distributed key generation protocol. In _Cryptographers’ Track at the RSA Conference_. Springer, 373–390.
  * Goldwasser et al. (1989) Shafi Goldwasser, Silvio Micali, and Charles Rackoff. 1989\.  The knowledge complexity of interactive proof systems.  _SIAM J. Comput._ 18, 1 (1989), 186–208.
  * Grassi et al. (2021) Lorenzo Grassi, Dmitry Khovratovich, Christian Rechberger, Arnab Roy, and Markus Schofnegger. 2021\.  Poseidon: A New Hash Function for Zero-Knowledge Proof Systems. In _30th USENIX Security Symposium_. USENIX Association, 519–535.
  * Groth (2016) Jens Groth. 2016\.  On the size of pairing-based non-interactive arguments. In _Annual International Conference on the Theory and Applications of Cryptographic Techniques_. Springer, 305–326.
  * Hopwood et al. (2016) Daira Hopwood, Sean Bowe, Taylor Hornby, and Nathan Wilcox. 2016\.  Zcash Protocol Specication.  https://raw.githubusercontent.com/zcash/zips/master/protocol/protocol.pdf Accessed: 2022-06-24.
  * Kate and Goldberg (2009) Aniket Kate and Ian Goldberg. 2009.  Distributed key generation for the internet. In _2009 29th IEEE International Conference on Distributed Computing Systems_. IEEE, 119–128.
  * Kate et al. (2012) Aniket Kate, Yizhou Huang, and Ian Goldberg. 2012\.  Distributed key generation in the wild.  _Cryptology ePrint Archive_ (2012).
  * Katz and Lindell (2020) Jonathan Katz and Yehuda Lindell. 2020.  _Introduction to modern cryptography_.  CRC press.
  * Kiayias et al. (2017) Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov. 2017.  Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol. In _Annual International Cryptology Conference_. Springer, 357–388.
  * Kokoris Kogias et al. (2020) Eleftherios Kokoris Kogias, Dahlia Malkhi, and Alexander Spiegelman. 2020.  Asynchronous Distributed Key Generation for Computationally-Secure Randomness, Consensus, and Threshold Signatures. In _2020 ACM SIGSAC Conference on Computer and Communications Security_. ACM, 1751–1767.
  * Körbel et al. (2021) Benjamin Körbel, Marten Sigwart, Philip Frauenthaler, Michael Sober, and Stefan Schulte. 2021\.  Blockchain-based result verification for computation offloading. In _International Conference on Service-Oriented Computing_. Springer, 99–115.
  * Kosba et al. (2020) Ahmed Kosba, Dimitrios Papadopoulos, Charalampos Papamanthou, and Dawn Song. 2020.  $\\{$MIRAGE$\\}$: Succinct Arguments for Randomized Algorithms with Applications to Universal $\\{$zk-SNARKs$\\}$. In _29th USENIX Security Symposium (USENIX Security 20)_. 2129–2146.
  * Mollah et al. (2020) Muhammad Baqer Mollah, Jun Zhao, Dusit Niyato, Kwok-Yan Lam, Xin Zhang, Amer MYM Ghias, Leong Hai Koh, and Lei Yang. 2020\.  Blockchain for future smart grid: A comprehensive survey.  _IEEE Internet of Things_ 8, 1 (2020), 18–43.
  * Nakamoto (2008) Satoshi Nakamoto. 2008\.  Bitcoin: A peer-to-peer electronic cash system.  http://www.bitcoin.org/bitcoin.pdf Accessed 2022-07-02.
  * Neji et al. (2016) Wafa Neji, Kaouther Blibech, and Narjes Ben Rajeb. 2016\.  Distributed key generation protocol with a new complaint management strategy.  _Security and Communication Networks_ 9, 17 (2016), 4585–4595.
  * Parno et al. (2013) Bryan Parno, Jon Howell, Craig Gentry, and Mariana Raykova. 2013\.  Pinocchio: Nearly practical verifiable computation. In _2013 IEEE Symposium on Security and Privacy_. IEEE, 238–252.
  * Pedersen (1991a) Torben Pryds Pedersen. 1991a.  Non-interactive and information-theoretic secure verifiable secret sharing. In _Annual International Cryptology Conference_. Springer, 129–140.
  * Pedersen (1991b) Torben Pryds Pedersen. 1991b.  A threshold cryptosystem without a trusted party. In _Workshop on the Theory and Application of of Cryptographic Techniques_. Springer, 522–526.
  * Rabin and Ben-Or (1989) Tal Rabin and Michael Ben-Or. 1989.  Verifiable secret sharing and multiparty protocols with honest majority. In _Twenty-first Annual ACM Symposium on Theory of Computing_. ACM, 73–85.
  * Schindler et al. (2019) Philipp Schindler, Aljosha Judmayer, Nicholas Stifter, and Edgar Weippl. 2019.  Ethdkg: Distributed key generation with ethereum smart contracts.  _Cryptology ePrint Archive_ (2019).
  * Schoenmakers (1999) Berry Schoenmakers. 1999\.  A simple publicly verifiable secret sharing scheme and its application to electronic voting. In _Annual International Cryptology Conference_. Springer, 148–164.
  * Shamir (1979) Adi Shamir. 1979\.  How to share a secret.  _Commun. ACM_ 22, 11 (1979), 612–613.
  * Stadler (1996) Markus Stadler. 1996\.  Publicly verifiable secret sharing. In _International Conference on the Theory and Applications of Cryptographic Techniques_. Springer, 190–199.
  * Stengele et al. (2021) Oliver Stengele, Markus Raiber, Jörn Müller-Quade, and Hannes Hartenstein. 2021.  ETHTID: Deployable threshold information disclosure on Ethereum. In _2021 Third International Conference on Blockchain Computing and Applications_. IEEE, 127–134.
  * Szepieniec et al. (2020) Alan Szepieniec, Tomer Ashur, and Siemen Dhooghe. 2020\.  Rescue-prime: a standard specification (SoK).  _Cryptology ePrint Archive_ (2020).
  * Wood et al. (2014) Gavin Wood et al. 2014\.  Ethereum: A secure decentralised generalised transaction ledger.  _Ethereum project yellow paper_ 151, 2014 (2014), 1–32.
  * Zhang et al. (2022) Liang Zhang, Feiyang Qiu, Feng Hao, and Haibin Kan. 2022\.  1-Round Distributed Key Generation With Efficient Reconstruction Using Decentralized CP-ABE.  _IEEE Transactions on Information Forensics and Security_ 17 (2022), 894–907.

  *[DKG]: Distributed Key Generation
  *[zk-SNARKs]: Zero-Knowledge Succinct Non-interactive Arguments of Knowledge
  *[VOC]: Verifiable Off-Chain Computation
  *[EVM]: Ethereum Virtual Machine
  *[VSS]: Verifiable Secret Sharing
  *[ZKP]: Zero-Knowledge Proof
  *[ZKPs]: Zero-Knowledge Proof
  *[zk-STARKs]: Zero-Knowledge Succinct (Scalable) Transparent Arguments of Knowledge
  *[R1CS]: Rank-1 Constraint-System
  *[QAP]: Quadratic Arithmetic Program
  *[zk-SNARK]: Zero-Knowledge Succinct Non-interactive Arguments of Knowledge
  *[MPC]: Multiparty Computation
  *[PoS]: Proof of Stake
  *[DSL]: Domain-Specific Language
  *[NIZK]: Non-interactive Zero-Knowledge Proof
  *[TID]: Threshold Information Disclosure
  *[CP-ABE]: Ciphertext-Policy Attribute-Based Encryption
  *[PVSS]: Publicly Verifiable Secret Sharing