►
From YouTube: ZK Application Design Patterns | Devcon Bogotá
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/zk-application-design-patterns/
We build a brief mental model of zkSNARKs and give an overview of application design patterns and techniques for ZK-enabled apps. We discuss the overall landscape of proving environments and applications of each: the affordances of browser proving, mobile proving, server proving, GPU proving, etc. We'll go over the current state of the art and key benchmarks, and how improvements across the landscape can unlock new applications of both privacy and succinctness.
Speaker(s): Yi Sun, Lakshman Sankar
Skill level: Intermediate
Track: ZKPs: Privacy, Identity, Infrastructure, & More
Keywords: zero-knowledge,application
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
Application
design
patterns,
but
ye
and
I
got
together
and
started
talking.
We
realized
a
lot
of
what
we
really
wanted
to
talk
about
was
like
what
is
the
landscape
of
ZK
applications,
ZK
or
zkp
or
snark,
is
quickly
becoming
like
a
big
data-esque
buzzword
and
very
jargony.
It's
starting
to
mean
a
lot
of
different
things,
and
so
we
hoping
to
talk
to
sort
of
like
talk
through
some
of
the
different
application
classes,
we're
seeing
emerging
emerging
today
and
in
in
in
the
process
sort
of
like
plot.
A
What
we
think,
the
next
six
months
to
one
year
of
like
new
ideas
coming
out,
look
like
and
if
the
course
data
core
thesis
were
stated
in
a
single
statement.
It's
basically
maybe,
unsurprisingly,
to
many
people
who
work
and
say:
hey,
that's
succinctness
and
privacy
are
are
kind
of
like
the
two
sort
of
features
of
ZK
that
are
interesting
and
understanding
what
succinct
private,
succinct
apps
require
and
what
private
apps
require
like
independent
of
one.
Another
might
help
us
understand
how
like
these
two
applications
exist.
B
B
So
we
think
that
each
of
these
quadrants
is
useful
in
a
different
type
of
application,
so
in
the
top
left,
if
you
have
a
private
proof,
that's
not
succinct!
Well,
it's
going
to
be
hard
to
verify
it
on
chain,
but
you
can
still
use
it
in
some
off-chain
applications
in
the
bottom
left.
If
you
have
a
succinct
proof,
that's
not
private!
Well,
that's
perfect
for
on-chain
infrastructure
applications,
but
not
so
good.
B
If
you're
trying
to
hide
information
and
of
course
you
can
have
the
best
of
both
worlds
in
the
top
right
where
you
have
both
succinctness
and
privacy,
but
as
we'll
talk
about
a
bit
later
in
the
talk,
that's
extremely
challenging
to
do
so.
We
think
that
almost
all
applications
right
now
fit
into
one
of
the
left,
two
quadrants
so
just
to
talk
through
some
of
them.
B
B
There
are
a
lot
of
projects
surrounding
making
blockchains
more
scalable
or
giving
additional
capabilities
to
decentralized
applications
using
the
succinctness
property,
but
where
everything's
public
already,
so
we
don't
care
too
much
about
privacy
and
finally,
in
the
top
right,
there
are
a
very
small
number
of
applications
that
have
managed
to
both
achieve
succinctness
and
privacy
and
you're.
Probably
probably
everyone
is
familiar
with
those
shown.
Okay,
so
we're
now
going
to
give
an
overview
of
where
we
are
today
on
each
of
these
factors,
succinctness
and
privacy,
so
in
the
bottom
left
corner.
B
The
new
capability
that
succinct
proofs
give
us
is
that
only
one
party
needs
to
execute
the
transaction
and
generate
a
validity
proof
of
that
transaction.
Everyone
else
simply
needs
to
validate
that
proof.
So
this
removes
the
duplication,
but
just
incurs
a
very
high
overhead
on
the
prover
and
so
examples
about
applications
that
use
this
pattern
today
are
all
of
the
ZK
Roll-Ups,
as
well
as
the
sort
of
app
specific
Roll-Ups
like
dydx
or
Loop
ring.
So
another
capability
that
we
see
ZK,
succinct
proof
springing
is
cryptographic
interoperability.
B
So
while
each
of
these
Primitives
is
useful
for
a
different
thing,
they
are
designed
in
a
somewhat
single
purpose
way,
and
that
makes
it
very
difficult
to
aggregate
or
compose
these
things.
So
ZK
provides
an
interoperability
layer
that
turns
all
of
these
into
a
snark
proof
that
is
arbitrarily
composable
using
recursion,
and
while
that
snark
proof
adds
some
overhead,
it
makes
this
open
interoperability
possible.
Okay.
So
let's
talk
about
now,
what's
necessary
today
to
make
this
happen.
The
first
thing
is
that,
because
we're
only
asking
for
a
succinct
proof,
we
can
really
scale
the
prover.
B
In
particular.
We
can
first
not
prove
in
the
browser
we
can
prove
on
the
user's
bare
metal
CPU,
so
that
gives
us
a
really
high
5
to
10x
Improvement.
Secondly,
we
can
Outsource
the
prover
to
the
cloud,
so
we
can
send
the
user
can
send
a
request
for
a
snark
proof
of
something
that's
already
going
to
be
public
and
then
the
cloud-based
server
can
run
a
big
large
AWS
instance.
B
It
can
run
a
GPU,
it
can
run
an
fpga
or
eventually
an
Asic,
and
that
can
give
another
5
to
10x
speed
up
in
the
proving
time
and
finally,
I
wanted
to
talk
about
the
last
constraint
when
you
use
succinctness
on
chain-
and
this
is
a
pretty
heavy
one,
which
is
that
you
have
to
verify
all
of
your
zero
knowledge
proofs
on
chain,
and
in
this
case
the
gas
cost
of
verification
really
differs
from
the
CPU
cost.
It's
going
to
depend
on
the
proving
system.
B
You
used
the
choice
of
curve
for
that
proving
system
and
also
some
proving
system
specific
implementation
choices.
The
most
restrictive
of
these
is
the
choice
of
curve,
so
on
ethereum
there
are
pre-compiles
for
the
BN
254
elliptic
curve,
and
those
operations
are
much
cheaper.
Unfortunately,
other
curves
are
somewhat
prohibitive
to
do
directly
in
evm,
hence
the
need
for
a
pre-compile
in
the
first
place.
One
way
that
is
commonly
used
right
now
to
get
around
this,
for
example,
in
the
zkevm,
is
the
operation
known
as
aggregation.
B
The
strategy
here
is
that
if
you
want
to
use
a
snark,
a
very
big
one,
that's
not
natively
compatible
for
evm
verification.
You
first
generate
your
snark
a
and
then
you
produce
a
recursive
snark
B,
which
proves
the
claim
that
you
know
a
large
snark
a
that
proves
the
statement
you
claimed.
In
this
case
you
can
choose
B
to
come
from
a
different
proving
system
than
your
original
snark,
and
that
proving
system
could
be
very
cheap
to
verify
on
ethereum.
B
A
A
But
what
we're
seeing
is
that
they
seem
to
they
seem
to
Cluster
around
social
type
things.
This
doesn't
mean
that
this
is
all
it
is
in
the
future,
but
kind
of
want
to
talk
about
what
we're
seeing
today
and
so
in
thinking
about
this
quadrant
I
spend
a
lot
of
time.
Thinking
about
sort
of
this
spectrum,
there's
a
Spectra,
so,
let's
say
think
about
those
arrows
or
zero
knowledge
proofs
being
made.
The
computers
are
like
say,
like
an
end
user
computer
ethereum.
A
There
obviously
is
a
decentralized
state
machine
with
a
high-ish
block
or
a
low
low
ish
relative
to
congestion
block
gas
limit
those
those
bottom
two
icons
are
sort
of
how
proofs
are
being
consumed
and
the
top
two
icons
are
how
proofs
are
being
produced.
It
feels
like
there's
a
spectrum
of
applications
and
how
we
think
about
what
is
consumed.
Is
it
being
consumed
by
a
human?
Is
it
be
consumed
by
a
state
machine
or
a
decentralized
date,
machine,
it's
being
consumed
by
a
decentralized
state
machine
like
ethereum?
A
A
But
these
two
ends
of
the
spectrum
I
think
we
all
quite
understand
like
the
chain
side
of
applications
like
things
that
that
use
your
knowledge,
proofs
that
are,
that
requires
tend
to
benefit
from
being
very
composable,
creating
things
that
are
canonical.
On
the
other
hand,
if
we're
talking
about
like
humans
interpreting
proofs,
it
feels
like
it's.
The
applications
want
to
be
higher
velocity
or
can
benefit
from
being
higher
velocity,
because
you
don't
need
a
chain
verifying
every
proof.
Things
are
more
ephemeral.
Maybe
you
know
humans,
don't
necessarily
have
like
persistent
memory
themselves.
A
Another
mental
model,
I
think
about
is
zkps
on
the
on
the
Privacy.
Not
just
inside
is
like
vkp
sort
of
creating
a
new
content
type,
which
is
like
all
these
places
where
people
create
content
online
today,
what
if
they
now
were
enriched
with
the
zkp
of
some
sort?
It
kind
of
means
something
a
little
bit
different,
which
which
is
quite
cool,
so
I
didn't
really
talk
about
I
realized
I,
probably
should
have
had
a
slide
here.
Presenting
some
applications,
but
some
examples
are
like.
A
Actually
let
me
just
pull
back,
go
back
to
this
slide,
so
it's
done
before,
which
is
a
project
of
the
PSE
which
is
kind
of
group
group
membership
in
like
proving
private
group
membership.
So
you
can
prove
that
you
are
one
of
the
people
in
a
group,
and
so
you
can
use
this
to
do
like
private,
like
synonymous
message
board
or
something
like
this
things.
Like
CK
email,
like
proving
that
you
know
mail
servers,
it
turns
out
many
of
them
like
sign,
sign
the
email
body.
A
A
A
So
if
anyone
was
around
for
like
you
should
talk
earlier
today,
where,
where
he's
sort
of
been
developing,
this
new
deterministic
nullifier
scheme
that
came
from
realizing
that
we
just
couldn't
do
a
lot
of
things
with
private
key
in
in
in
a
client
device,
because
it
would,
we
would
need
to
pass
this
very
sensitive
piece
of
information
around
different
parts
of
application
memory,
and
so
we
have
to
think
of
new
kind
of
like
mechanisms
for
not
having
to
do
that.
Oh,
this
is
still
me.
A
Oh
cool,
all
right,
so
some
of
the
some
of
the
some
of
the
challenges
that
we
see
technical
technical
challenges
in
the
next
six
months.
So,
as
I
mentioned
earlier,
like
we
need
to
be
very
friendly,
unlike
for
privacy,
not
succinct
applications
and
in
research,
constraint,
environments
like
mobile
devices
like
like
web
browsers,
I
think
a
lot
of
like
a
lot
of
the
VK
space
is
assuming
that
most
VK
proofs
will
be
produced
on
like
very
large
servers
or
with
fpgas
or
gpus.
A
You
know
there's
some
like
debate
around
which
of
those
two
things
wins
of
course,
but
if
users
are
making
proofs
to
other
or
humans
are
making
you
proofs
to
other
humans,
we
perhaps
can't
quite
make
that
assumption.
So
we
spent
a
lot
of
time
thinking
about
performance
and
research
in
certain
environments.
A
I
so
specific,
like
you
know
the
specific
example
that
I
gave
earlier
earlier
with
ayush,
we
need
to
think
a
lot
about
non-private
key
nullifiers
like
non-private
key
uniqueness
of
identity,
because
we
don't
want
to
have
to
deal
with
private
key.
We
don't
want
to
have
to
create
like
an
environment
or
a
platform
or
anything
where
we
we
assume
private
key
is
passed
for
map
to
app,
and
then
we
also
spend
a
lot
of
time
thinking
about
representing
more
crypto
systems
where
identity
matters
in
snarks.
A
So
you
know
ethereum,
we
all
interact
with
ethereum.
That's
quite
obvious,
there's
a
lot
of
interesting
things.
You
can
say
about
ethereum
stuff,
but
there
are
other,
like
networks
in
the
world
where
you
know
cryptographic,
signatures
are
made
like
like
email,
mail
service
like
I
mentioned
earlier.
So
we're
constantly
looking
around
to
understand
where
new
networks
are
forming
and
how
to
like,
put
those
operations
inside
snarks.
B
So
in
that
sense,
what
what
I
view
the
challenge
ahead
as
really
optimizing,
the
performance
of
our
proving
systems
and
our
architectures,
so
One
Direction,
is
to
really
weaponize
this
operation
of
aggregation
and
recursion.
That
I
mentioned
earlier,
and
the
reason
here
is
that
if
you
want
a
very
rich
infrastructure
application,
you
need
a
proof
for
a
much
larger
circuit
than
is
even
possible
than
the
large
in
the
largest
circuits
today,
and
so
there
are
a
couple
ideas
here
that
are
only
beginning
to
be
exploited
by
projects
right
now.
B
One
is
to
maximize,
what's
called
a
prover
verifier
trade-off,
there's
a
fundamental
trade-off
between
the
proving
time
and
the
complexity
of
verifying
a
proof.
If
you
feed
in
more
compute.
You
can
get
an
easier
to
verify.
Proof
so
we
can
do
things
like
starting
with
a
very
fast
to
prove
system
and
then
wrapping
it
in
an
aggregation
layer
with
which
transforms
it
to
a
cheaper
to
verify
system.
B
A
lot
of
the
progress
in
ZK
has
been
driven
by
the
emergence
of
many
new
types
of
proof
systems
that
really
pushed
the
envelope
on
what
we
can
do
inside
a
ZK
circuit,
so
Justin
as
recently
as
2016,
really
the
most
viable
ZK
proof
system.
We
had
access
to
was
Groth
16,
but
since
then,
we've
added
many
capabilities
like
custom,
Gates,
lookup
arguments
and
we've
been
able
to
remove
some
aspects
of
The
Trusted
setup
in
newer
systems
like
Planck,
Halo
2
and
in
Starks
in
the
landscape.
B
A
This
is
probably
what
the
future
will
look
like
in
the
sense
that
so
so
that
the
left
side
is
the
kind
of
privacy
side
and
the
right
side
is
sort
of
the
succinct
proving
side
and
the
idea
being
that,
hopefully,
we
reduce
the
surface
area
of
the
private
to
public
ish
proof
to
something
quite
small.
That
could
then
be
recursively
included
in
a
larger
proof.
A
That
is
that
you
know
that
that
is
in
the
kind
of
like
succinct
but
not
private,
kind
of
like
technological
requirement,
land
and
then
that
is
interpreted
on
chain.
And
then
this
way
we
get
all
you
know
all
of
the
nice
benefits
the
Privacy
answering
thickness
and
on-chain
applications
with
pseudonymity
and
cool
stuff,
like
that,
yeah.
C
B
Yeah
so
succinct,
this
is
a
property
of
zero
knowledge
proofs
which
says
that
the
size
of
the
proof
can
be
asymptotically
smaller
than
the
size
of
the
computation
you're
able
to
do
so,
depending
on
the
proof
system.
Either
the
size
of
the
proof
could
be
constant
size
in
the
size
of
the
computation
or
it
could
be
logarithmic,
but
either
way.
The
point
is
that
you
can
verify
this
proof
in
much
less
compute
than
doing
the
actual
computation
itself.
A
Hey
and
perhaps
there's
another
distinct
slight
thing,
which
is
many
many
of
many
I
mean
most
of
these
proof
systems
do
have
constant
proof
sizes,
but
also
like
the
the
lower
the
lower
the
constant
proof
size,
the
better
for
something
that
is
interpreted
on
chain.
Obviously,
but
yeah
use
answer
is
better
than
mine
would
have
been.
I
was
just
gonna,
say,
small
Hey.
D
So
when
we
recursively
prove
stuff
so
over
here
sorry
when
we
recursively
prove
so
there
is
a
proof
and
then
you
are
proving
the
proof
right.
So
there
are
multiple
layers
of
Integrity
checks,
right
that
that
is
the
assurance
that
you
get
so,
and
these
circuits
are
super
complex
and
there
could
be
like
a
million
arithmeticians
in
in
there
right.
So
what
about
the
security
of
these
proofs?
D
B
Definitely
I
would
say
on
the
second
side.
Definitely
recursion
and
aggregation
make
it
substantially
more
difficult
to
verify
that
your
circuits
are
correct,
so
we
have
obviously
traditional
unit
testing.
We
have
randomized
fuzzing
and
we
have
some
emerging.
Formal
verification
approaches
for
ensuring
circuits
are
correct,
where
recursion
makes
these
more
complicated
is
that
you
may
need
to
encode
assumptions
slightly
external
to
your
circuit
itself,
to
check
things.
I'm
sure
locksman
has
some
views
on
how
that
affects
privacy
as
well.
A
Oh
I
mean
I,
like
I
I
think
this
is
actually
something
we
need
to
think
about
very
seriously.
It
feels
like
I
mean
if
any
of
you
are
familiar
with,
like
supply
chain
attacks
and
the
node.js
ecosystem.
It
feels
like
we
could
easily
that
that
is
like
I,
don't
want
to
get
too
pessimistic,
but
that
is
like
a
very
bad
worst
case
here,
because
it's
like
it's
very
hard
for
the
the
recursing
proof
to
make
strong
assumptions
around
the
soundness
of
like
proof
that
is
recursing
on
I.
A
Don't
have
any
optimistic
takes,
unfortunately,
but
I
think
it's
something
we
need
to
think
about.
There
are
lots
of
great
people
like
especially
in
the
Xerox
Park
ecosystem
kind
of
thinking,
a
lot
about
about
like
formal
verification
and
things
like
this,
and
maybe
like
yeah,
there's
formal
verification
of
the
dependency
graph
type.
Things
needs
to
needs
to
start
happening.
I
I,
don't.
C
B
I
think
of
the
different
proof
systems
most
of
the
ones
which
are
based
on
elliptic
curve.
Cryptography
are
not
going
to
be
Quantum
resistant,
since
they
will
require
at
least
a
discrete
log
assumption,
but
we
actually
do
already
know
proof
systems
which
are
quantum
resistant
like
Starks,
which
only
require
a
random
Oracle
hash
assumption.
E
What
do
you
mean
by
caulk
being
more
efficient
than
the
easiest
World
Cups,
so
it
from
all,
it
seems
to
me
that
you
can
actually
be
applied
to
like
local
arguments
in
circuits
or
in
the
Mercury
setting
where
you
want
to
have.
You
know:
zero
knowledge,
membership,
roofs,
because
that
the
there's
a
like
there's
a
linear
overhead.
When
maintaining
this
you
know
free
process
of
proofs.