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
you