►
From YouTube: Penumbra: Building a Private DEX with ZKPs and Threshold Cryptography by Henry de Valence
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 Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/penumbra-building-a-private-dex-with-zkps-and-threshold-cryptography/
ZKPs allow transactions to prove their state transition was valid, without revealing anything about what it was. But this isn't enough, because useful applications require shared state, which ZKPs can't provide. In this talk, we'll describe how to break this barrier by combining ZKPs with flow encryption, a new threshold crypto primitive, to allow private interaction with public shared state, and how Penumbra uses this technique to build a private DEX.
Speaker(s): Henry de Valence
Skill level: Intermediate
Track: ZKPs: Privacy, Identity, Infrastructure, & More
Keywords: ZKP,threshold crypto,DEX
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 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
All
right
all
right,
that's
just
my
personal
opinion,
though,
but
I
think
zkps
are
actually
the
the
nice
thing
that
nobody
expected
coming
from
cryptocurrencies,
but
they
still
happened
so
next
up
we
have
Henry
de
valence,
the
founder
of
penumbra
and
he's
going
to
to
be
talking
about
their
experience
of
building
a
privacy.
Oh
they
just
disappeared
in
front
of
my
eyes,
because
the
talk
is
starting
now,
but
Henry's
building
privacy
preserving
decks
using
zkp.
So
please
put
chance
together
for
Henry
all.
B
Right,
yeah
well
great,
to
see
everyone,
so
I'm
gonna
be
giving
a
talk
about
how
to
build
a
private
decks.
However,
just
as
a
kind
of
a
pre-warning,
if
you're
really
interested
in
all
of
the
sort
of
details
of
ZK
proofs
that
actually
won't
be
covered
in
the
talk,
and
the
reason
is
that
I
think
part
of
the
problem
with
deploying
zkps
for
privacy
rather
than
just
for
scalability.
Is
that
there's
some
interesting
and
fundamental
challenges
in
the
state
model?
B
So
that's
actually
sort
of
the
whole
summary
of
the
talk
so
to
get
started
for
context,
so
I'm
working
on
a
project
called
penumbra?
What
that
is,
is
a
private
proof
of
stake.
L1
inside
of
that
L1,
we
have
an
interchange,
shielded
pool,
so
you
can
take
any
IBC
compatible
asset
moving
into
this
chain
and
that's
the
Privacy
boundary.
B
The
the
thought
is
that
every
Market
is
also
a
marketing
information.
When
we
talk
about
price
Discovery,
for
instance,
you
can
think
of
that
as
being
a
kind
of
decentralized
computational
process
that,
as
a
side
effect,
produces
some
information
about
prices.
But
that
means
that
information
leaks
are
value
leaks.
When
people
talk
about
Mev
and
have
these
you
know
dashboards
of
here's,
how
much
value
is
extracted
from
people
who
are
trying
to
do
trading?
Really
that's
just
the
sort
of
first
order
symptom
of
this
problem.
B
It's
not
even
if
you
fixed
Mev
in
some
way,
you
still
have
the
problem
that
you're
you're
leaking
information
about
what
trades
are
doing.
What
trades?
Your
account
has
done.
Your
entire
history
of
your
whole
trading
strategy.
All
of
that
information
is
valuable
too.
It's
just
harder
to
make
a
dashboard
of
it.
So
the
the
thought
here
is
that
privacy
is
a
really
interesting
thing
for
trading,
because
trading
is
a
context
where
having
privacy
allows
you
to
unlock
greater
Capital
efficiency
and,
as
somebody
who's
really
interested
in
privacy.
B
This
is
a
really
interesting
and
exciting
opportunity,
because
it
means
that
there's
the
potential
to
build
a
private
product
that
can
actually
out
compete
the
non-private
ones,
because
it's
private,
so
we
we
get
out
of
this
mode
of
like
oh
well,
we'll
you
know
have
people
accept
all
these
trade-offs
to
use
the
private
thing.
No
we're
going
to
build
something!
That's
that's
better
because
it's
private,
so
right,
I,
said
I
was
going
to
talk
about
the
challenges
and
the
first
challenge,
which
is
the
most
fundamental,
is
actually
the
state
model.
B
So
if
we
consider
a
transparent
chain
like
ethereum,
the
the
Paradigm
of
that
state
is
global.
Mutable
State,
there's
like
one
big
ethereum
state
and
every
transaction
is
applied
sequentially
and
it
can
do
whatever
mutation
to
that
state
and
as
it's
doing
that
mutation
effectively,
it's
taking
like
a
global,
lock
over
the
whole
state
doing
some
changes.
Then
you
do
the
next
transaction
and
so
on.
But
in
order
to
have
a
shielded
chain
where
the
user
state
is
not
public
information,
we
have
to
change
the
state
model
to
a
model
of
immutable
composable
State.
B
This
is
actually
kind
of
like.
Historically
speaking,
this
is
sort
of
rewinding
to
a
Bitcoin
style
sort
of
utxo
model,
but
I
think
utxo
is
a
little
bit
of
a
loaded
like
baggage
Laden
term.
So
I
prefer
just
having
this
idea
of
a
state
fragment
and
instead
of
having
one
big,
Global
State
we're
going
to
have
a
tree
of
State
fragments
which
are
immutable
and
each
transaction
is
going
to
consume
some
State
fragments
produce
some
new
ones
and
put
those
you
know
append
those
into
this
tree.
B
The
reason
that
we
want
to
do
this
is
that
that
way,
we
can
make
the
state
transitions
private
and
the
move
to
do
that.
Is
you
replace
all
of
those
State
fragments
with
cryptographic,
commitments
to
States
and
then
in
your
transaction,
rather
than
explicitly
declaring
the
plaintext
values
of
those
State
fragments?
You
can
just
have
a
ZK
proof
that
the
state
transition
was
valid,
and
here
are
the
commitments
to
the
new
states
that
I
produced
okay.
So
this
is
all
cool
and
that's
why
everybody's
like
using
like
private
blockchains
all
the
time?
B
B
That
represents
the
state
transition,
but
what
we've
actually
done
is
we've
moved
all
of
the
execution
off
chain,
along
with
moving
all
the
user
data
off
chain
right,
but
now
we
don't
really
have
any
way
to
access
any
shared
State,
because,
when
somebody's
submitting
their
transaction
effectively,
every
transaction
is
is
its
own
little
micro
Roll-Up,
and
what
I
would
claim
is
that
the
key
problem
here
is
is
one
of
early
versus
late
binding.
So
what
we
have
in
this
sort
of
ZK
model
is
early
binding.
B
Every
transaction
has
to
have
this
fully
sealed
complete
State
transition,
but
that's
not
actually
what
we
generally
want
right.
If
you
make
a
trade
on
uniswap
you're,
not
going
to
sign
over
here's
the
exact
State
of
the
Union
reserves
of
this
contract,
here's
the
exact
outputs
that
I'll
get,
because
the
only
way
that
you
could
do
that
is
by
sort
of
having
the
entire
world
stop.
While
you,
you
know,
submit
your
transaction
right.
B
With
their
own
State
and
passing
messages
back
and
forth
to
each
other,
so
what
would
that
look
like
in
the
context
of
trying
to
build
a
privacy
preserving
chain?
Well,
we
could
try
to
think
of
this
kind
of
actor
model
for
chains
where
a
transaction
rather
than
synchronously,
doing
a
contract
call
where
it
locks
some
state
does
some
execution
and
then
finishes
and
releases
the
look.
B
In
some
cases
you
know
you
could
combine
all
of
those
messages
into
one
right
like
you
could
do
a
batch
swap
which
I'll
get
to
later
on
in
the
talk,
but
also,
you
could
imagine,
say,
like
an
auction
protocol
that
orders
these
messages
by
the
the
bid
amount
and
the
key
thing
is
that
you're
not
doing
any
execution
at
a
higher
time
resolution
than
is
actually
provided
by
the
underlying
consensus
right.
When
people
talk
about
transaction
ordering.
B
B
That
represents
the
eventual
result
of
the
computation
that
I'm
going
to
be
doing,
but
I
can
do
all
of
the
all
of
the
computation.
That
is
only
touching
a
particular
user.
State
can
happen
off
chain
privately
in
ZK.
So
the
really
interesting
thing
about
this
model
is
that
it
actually
simultaneously
unlocks
both
scalability
and
privacy,
because
all
of
the
data
that
doesn't
need
to
be
having
any
shared
execution
is
happening.
B
That
execution
is
is
happening
on
each
individual,
user's
client
and
the
on-chain
data
is
limited
to
the
minimum
shared
computation
and
it's
executing
in
a
batch.
So
you
can
potentially
have
a
much
more
efficient
implementation
so
to
see
kind
of
how
this
works
in
a
in
a
diagram
which
I
think
it
might
be
a
little
bit
more
clear,
we're
going
to
start
off
with
our
first.
B
What
it's
going
to
record
as
the
output
of
that
initial
transaction
is
actually
a
privately
minted
state
nft,
which
commits
to
the
Future
that
this
computation
is
supposed
to
be
representing.
So
now
this
user
has
this
in
this
diagram.
This
is
the
the
Diamond.
Is
this
nft
that
records
the
kind
of
intermediate
state
of
their
per
user
computation
after
they
send
that
all
out
to
the
chain,
it's
included
in
a
block?
B
The
chain
is
going
to
send
a
message
back
by
publishing
data
to
the
the
chain
or
the
contract's,
going
to
send
a
message
back
by
publishing
the
data
to
the
chain,
and
we
take
that
message
from
the
contract.
Combine
it
with
our
intermediate
execution
state
we're
going
to
burn
that
state
and
inside
of
this
ZK
proof.
We
can
now
prove
that
we've,
you
know,
modeled
the
correct
future
with
the
correct.
You
know
same
input,
values
that
we
had
committed
to
in
the
first
transaction,
and
now
we
can
privately
mint
some
outputs.
B
So
this
is
this
sort
of
big
picture
diagram
of
how
this
sort
of
async
ZK
execution
can
work
in
principle
and
we'll
get
to
a
concrete
example
of
how
that
works
out
for
the
case
of
doing
batch
swaps,
but
before
that,
I
just
want
to
get
into
this
second
challenge,
which
is
once
you
have
an
idea
of
okay.
We
have
maybe
a
workable
State
model,
but
what
is
the
Privacy
model
right
and
the
the
claim
here
is
that
basically,
every
useful
blockchain
revolves
around
public
shared
State.
B
Or
you
know
what
the
volume
is
and
all
of
the
the
sort
of
big
breakout
successes
of
of
useful
contracts
have
the
contracts
public
shared
State,
acting
as
this
kind
of
universal
counterparty.
So
you
don't
need
to
go
and
find
some
some
person
to
interact
with
you
can
just
interact
with
the
chain.
So
we
need
to
have
public
shared
state,
but
you
know
maybe
we
want
it
to
be
private.
So
what?
What
does
that
mean
exactly
right?
This
question?
The
question
is
like:
how
do
you
allow
private
interaction
with
public
shared
State?
B
We
want
to
have
some
kind
of
notion
where
the
individual
users
transactions
have
privacy,
but
all
of
the
aggregate
state
of
the
chain.
Like
you
know,
all
of
the
aggregate
Market
data
is
public,
but
the
individual
users
trades
are
not
so
here's
two
basic
strategies
of
how
you
could
have
a
private
interaction
with
public
State.
One
is
splitting
flows
and
the
other
is
batching
flows
when
I
say
flow.
The
reason
I
use
that
word
is
that
I
think
of
you
know
value
being
in
in
different
sort
of
pieces
of
the
chain.
B
So,
looking
at
these
two
in
turn
for
splitting
flows,
the
idea
is
that
we're
going
to
start
off
with
some
users
value
that
you
know
this.
Maybe
this
is
an
amount
that
they
want
to
trade.
They
can
split
that
into
randomized
sub
amounts
and
then
reveal
each
of
those
sub
amounts
in
distinct
transactions
and
then
reunify
them
later.
So
this
method
only
works.
B
If
you
have
a
shielded
base
layer,
if
you
have
a
transparent
based
layer,
then
this
like
is
trivially
broken
because
you
just
like
look
at
what
the
account
was
and
then
you
can
see
what
it
did,
but
if
everything
else
is
private
and
you're,
only
revealing
like
here
is
a
specific
amount
that
I'm
sending
to
this
part
of
the
system
like
this
is
a
a
public
delegation
amount
to
some
validator.
This
is
like
an
amount
in
in
one
sort
of
randomized
sub
trade.
B
This
might
be
okay
and
it's
a
it's
a
fairly
practical
and
simple
thing.
However,
it's
it's
not
really
ideal.
So
the
other
strategy,
which
is
more
interesting
and
more
cool,
is
this
idea
of
batching
flows.
So
if
we
know
that
we're
already
going
to
be
processing
the
contract
state
in
batches,
it
would
be
nice
to
have
a
way
to
batch
up
flows.
B
You
know,
as
long
as
the
the
batch
size
is
is
big
enough
as
an
example.
If
you're
trying
to
have
you
know
a
a
delegated
proof
of
stake
system,
you
could
make
it
so
that
oh,
the
validator
weights
will
change.
You
know
in
each
Epoch
and
we'll
just
sum
up
all
of
the
the
delegations
or
undelegations
in
each
Epoch
and
only
reveal
the
net
change.
B
So
these
are
sort
of
the
the
two
pieces.
Let's
see
how
this
kind
of
works
out
as
a
as
a
concrete
worked
example,
which
is
doing
sealed
input
batch
swaps
on
penumbra,
so
looking
first
at
the
private
State
part
right.
Remember
that
we
have
this
model
where
we
explicitly
segment
away
the
per
user
private
state
from
the
shared
public
state,
we're
going
to
start
off
with
okay,
here's
the
the
private
input
for
this
trade
that
a
user
wants
to
make
they're
going
to
encrypt.
That
input
include
that
in
their
transaction.
B
The
rest
of
the
transaction
right
is
is
totally
shielded
because
we
have
this
shielded
base
layer,
so
there's
no
Public
Accounts
or
any
other
metadata
in
the
the
transaction.
And
what,
though,
meant
in
that?
Swap
transaction
is
a
swap
nft,
where
the
the
asset
ID
of
that
nft
is
a
snark
friendly
hash
of
their
input.
Trade
amounts
the
trading
pair
their.
You
know
the
address
that
they're
going
to
Mint
the
funds
to
some
prepaid
fees
and
as
this
transaction
that
they
submitted
is
included
in
a
block.
B
Trade
amounts.
Now,
if
you're
on,
say
like
a
thinly
traded
pair.
Maybe
you
end
up
in
a
badge
size
of
one,
but
in
that
case
you
can
use
this
sort
of
randomized
splitting
technique
that
I
mentioned
earlier
to
make
effectively
a
kind
of
like
randomized
t-wop
of
your
trade,
so
zooming
out
of
the
the
private
State
part
to
how
this
works
on
the
public
State
Side.
B
We
have
all
of
these
all
of
these
swap
transactions
that
have
been
included
in
the
the
block.
We
have
the
Dex
engine
group,
all
of
those
inputs
by
pair.
We
do
this
batching
and
decryption.
But
now,
at
this
point
we
we
don't
just
have
you
know
a
single
swap.
We
don't
just
have
a
single
Swap
transaction
on
a
single
pair.
B
We
have
a
complete
picture
of
here's
all
the
trading
intent
for
the
entire
chain
in
this
block,
and
we
also
know
that
we
only
have
to
run
the
Dex
engine
once
per
block
because
we're
in
this
batched
computation
model.
So
that
means
that
we
can
actually
be.
You
know
considerably
more
sophisticated
in
how
we
resolve
these
trades.
B
We
can
load
up
the
entire
liquidity
graph
of
all
of
the
assets
on
the
Chain
sort
of
put
the
trade
intent
into
the
correct
spots
on
that
graph
and
then
compute
some
optimal
resolution
of
all
of
these
trades
simultaneously.
So
you
can
do
some
kind
of
global
resolution
of
the
trading
intent
do
optimal
Arbitrage,
and
this
is
computationally
tractable
to
do
just
like
in
consensus,
because
you
know
that
you're
only
doing
this
once
per
block.
B
So
you
you
end
up
in
a
model
where,
rather
than
sort
of
having
to
call
each
contract,
you
know
potentially,
like
thousands
of
times
a
block.
You
just
know
that
the
chain
is
going
to
step
in
discrete
time
from
one
set
of
consistent
prices
to
a
new
set
of
consistent
prices.
You
can
handle
all
of
the
newly
added
or
removed
liquidity,
also
in
a
batched
way
right.
So
you
first
add
all
of
the
newly
created
liquidity.
Then
you
resolve
all
of
the
trading
tent.
B
Then
you
are
up
all
the
prices
to
be
consistent
with
each
other.
Then
you
close,
all
the
you
know,
closed
positions,
and
this
also
lets
you
as
a
side
effect,
have
like
single
block,
jit
liquidity
with
the
kind
of
like
batch
semantics.
So
there's
a
lot
of
really
interesting
pieces
of
Market
design
that
get
unlocked
by
this
model.
B
So
that's
basically
the
content
of
the
talk.
If
you
want
to
play
with
this,
we
have
some
weekly
test.
Nets
that
you
can.
You
know,
play
around
with
here's
a
bunch
of
links
so
far,
the
the
big
last
sort
of
piece
to
build
is
the
the
actual
Dex
engine,
but
we
have
a
toy
amm
that
you
can
do
these
shielded
swaps
against
on
our
test
net.
So
that's
a
talk.
If
anybody
has
any
questions
happy
to
get
into
it,.
D
E
B
Yeah
so
it's
possible,
for
instance,
that
someone
could
submit
a
transaction
that
say
you
know
they
submit
a
trade
for
a
trading
pair
that
doesn't
have
any
liquidity
on
it
right.
So
one
of
the
outcomes
of
the
the
batch
swap
is
that
the
the
trade
can
fail,
and
in
that
case,
rather
than
having
people
privately
meant
their
Pro
rata
share
of
the
outputs.
They
privately
meant
their
Pro
rata
share
of
the
inputs
they
get
their
their
funds
back
yeah.
B
So
the
whole
batch
goes
goes
at
once
so,
like
technically
I
guess
you
could
have
some
kind
of
griefing
attack
where
someone
is
like
continually
locking
up
capital
in
trying
to
like
dot,
prevent
other
people
from
Trading
by
submitting
a
giant
whale
trade,
but
like
they
can't
actually
do
that
without
running
the
risk
that,
like
someone,
will
provide
liquidity
at
a
bad
price.
So
I
think
it's
probably
not
a
big
deal.