# Efficient and cryptoeconomically driven DKG as a smart contract (Devcon4)

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2019-10-09
- Duration: 07:19
- Topics: blockchain, smart contracts, distributed ledger, Science & Technology
- Watch: https://streameth.org/watch/yt-OOk7fsoDoLk
- YouTube: https://www.youtube.com/watch?v=OOk7fsoDoLk

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/4/efficient-and-cryptoeconomically-driven-dkg-as-a-smart-contract

In the absence of a trusted party, Distributed Key Generation (DKG) protocols are essential for the initial setup of any type of threshold cryptosystem. The protocol results with each of the participants holding a valid key share. We use Ethereum as a decentralized trusted platform to run a DKG protocol for BLS signatures. We use precompiled contracts that were initially designed for fast (within the block gas limit) zkSNARKs verification to overcome the computational complexity of the protocol. We rely on a previously proven DKG protocol, but our version is specifically designed to be implemented as a smart contract over Ethereum. We prove the security of our DKG protocol in the random oracle model and other common cryptographic assumptions. To conclude the system, we give an efficient smart contract for signature verification. Our smart contract consumes reasonable gas and scales nicely (in terms of the number of participants). Only a dispute between two of the participants will invoke elliptic curve arithmetics or paring computations. Ethereum is used for three reasons: As a medium for (synchronous) communication, as a mediating authority in case of conflicts, and as a cryptoeconomic incentivization layer over the plain DKG protocol.

Speaker(s): David Yakira, Ido Grayevsky, Avi Asayag, Ido Zilberberg
Skill level: Intermediate
Track: Security
Keywords: gas, gwei, scaling, incentives

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 4 was held in Prague, Czech Republic on Oct 30 - Nov 2, 2018.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

okay so hi everybody my name is David I'm from orbs which is a company based in Israel and I will talk today about dkg distributed key generation so a choreographic primitive that we use in orbs is their full signatures in which so in a circle threshold the signature scheme you have and participants and any large enough subset should be able to produce a valid signature but a small subset of the participants should not be able to produce a valid signature and this is quite similar to a multi signature but not just quite right because we have a 1:1 signature so as you can probably understand if you want to have such a chromatic such a scheme you need the participants keys to be related mathematically so the participants cannot just generate their keys locally and expect them to somehow work together so option a that the way to address this is to use a trusted dealer that would distribute the keys to the participants but of course in a decentralized environment that would not be desired right you don't want a single entity to know everything so what you can do is you can use a distributed key generation protocol which would indeed you know reduce the need of a trusted dealer but it would introduce some challenges so first of all a lot of communication right all the participants are going to have to communicate with all the participants so this is expensive and then computationally it's going to be hard on participants they're going to have to run many computations to validate that everything is correct and then there's still this trust assumption where we're trusting that the majority of the participants are following the protocol correctly and if this assumption breaks then the protocol breaks so we're going to use the theorem in order to kind of justify or relax this is not this is something in red that's the main purpose of using a theorem so how is it going to work basically it's going to be a smart contract right adapt that does the dkg and the participants are going to start by enrolling to the smart contract they're going to send a deposit and then they're formally a part of this dkg and after this is over they the actual dkg can start the first communication they're going to communicate by sending transactions to the smart contract which would basically be data that they're trying to distribute between one another and this could be public information available for everybody or private information that is destined to a specific participant and then they just encrypt their data after the communication is over they the participants are going to execute local computations and then if everything is fine and basically the dkg is over okay and everybody every participant has their keys in' and it's good to go over if there's a problem then any participant that detects a problem with another participant state that they can basically complain they can file a complaint to the smart contract which would then re-execute the reported computation and would find whoever is faulty and would slash that participant okay so what we were able to do is we're able to find valid complaints for every way that a participant can divert from the instructions from the original instructions of the protocol and what this means is that if you're a participant and you care about the deposit that you put you would have to follow the protocol instructions correctly or else you're going to be complaining against and slashed okay so this is exactly what we wanted which is great but let me just finish up by giving you a taste as to how we actually solve the technical problems because the dick ages is very computation and communication and expensive as I said before so first so our general approach is to do as much as we can off chain so what does that mean so in terms of communication except for a 32 byte commitment that the participants have to include in their and transaction basically all the communication can be done off chain secondly in terms of of the interactive of the dispute mechanism so if any participant files a complaint this really expensive computation has to be done on chain to verify who was correct and who was faulty and this is very expensive this cannot be done ovary theorem so we use it we use an interactive protocol between the participant who is complaining and the participant is being complained against okay in the spirit of troubie so this is really great because this what it bring what it what it lets us it lets us arrive to a situation where there's only one on chain operation has to be done in order to find out who is faulty but this is still too expensive to run over here because this is typically going to be an elliptic curve operation okay so the way to address this is to use one of the precompiled contracts that actually do elliptic curve operations and this will allow us to be two to not to pass the gas limit so what we were able to do is to we were able to take the dkg the original dkg protocol and restricted to only use the curves and the operations that are backed by these alee by these precompiled contracts even though these pre-compiled contracts were originally introduced to e theorem just 2zk snarks so we were able to using for completely different use case and we're using them for this dkg and then for pls threshold signatures to be done over a theorem so this is pretty cool that we were able to do this we proved that our variant of the dkg is safe and it works and so all these things together were actually able to were actually able to make the dkg run efficiently over e theorem with a very large number of participants so there is a prototype implementation that you can find in our github it's a it's a proof of concept it's not production already or anything and there is a paper coming which you can also check out and I encourage you to comment asking a question if you have yeah thank you very much