foreign
[Music]
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 uh 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
um 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 what we think the next six months
to one year of like new ideas coming out
look like
um and if the course data core thesis
were stated in a single statement it's
basically
um 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
so as Alexa mentioned we really think of
ZK as this Matrix where your proof can
be either succinct or not succinct and
your proof can either be private or not
private
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 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 on
the on the top left
we have uh more social type explorations
of what you can do when you can hide
information about what groups you belong
to and what statements you want to make
with partial revelation of information
on the top left there are in the bottom
left 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 if we ask for a
succinctness but not privacy the general
theme is that zkps are used to scale
trustless off-chain compute and the
theoretical principle behind this is
that if you run code on ethereum today
every ethereum full node has to rerun
that code to validate that the execution
of your transaction was correct so
that's about 100K at times overhead and
it has very high duplication
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 uh succinct proof
springing is cryptographic
interoperability so one thing that ZK
allows you to do is to take anything
from the grab bag of crypto
cryptographic Primitives on the left and
allow you to wrap it in a uniform format
namely a ZK snark
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 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 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 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
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 in this way you can
sort of transmute a very large snark
from an arbitrary proving system to an
on-chain verifiable snark from something
that's compatible with ethereum
the only caveat here is that you of
course incur the overhead over this
recursive proof cool thank you
um yeah now I'll talk about the the
other kind of interesting cluster we're
seeing in the top left which is uh
application classes that seem to require
privacy or pseudonymity of some sort but
don't necessarily require six sickness
um this is kind of like a more nascent
uh ecosystem of things
um
many of them don't require chains and so
uh I think relative to maybe a lot of
the things that you talked about they're
perhaps less familiar to the average
ethereum conference attendee
um but what we're seeing is that they
seem to they seem to Cluster around
social type things
um 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
um 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
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
uh 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
um it's being consumed by a
decentralized state machine like
ethereum
hence like on-chain verification uh you
need things to be considerably more
succinct this being interpreted by a
human maybe you don't maybe it can be
like a much larger piece of information
that is like human interpretable or has
like some kind of like interesting
graphical representation
and so in thinking about this spectrum
and again this is this is not including
a lot of things in the middle so things
in the middle might be things like uh
like being consumed by like an app chain
or a layer two or a a lower congestion
layer one or a short-lived chain or
something like that
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 uh you don't need a
chain verifying every proof uh things
are more ephemeral maybe you know humans
don't necessarily have like persistent
memory themselves right like we see a
lot of things on Twitter and sort of
like form a vague understanding of
what's going on
um another mental model I think about is
um zkps on the on the Privacy not just
inside is uh like vkp sort of creating a
new content type which is like all these
places where people create content
online today
um 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
um so I didn't really talk about I
realized I probably should have had a
slide here presenting some applications
but
um some examples are uh like
um actually let me just pull back go
back to this slide
so it's done before which is a project
of the PSE uh which is kind of group uh
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 uh synonymous message
board or something like this
um things like CK email like proving
that
you know mail servers it turns out many
of them uh like sign uh sign the email
body so uh you can you can do a zero
knowledge proof that you received an
email with certain Properties or
something like that which is kind of
cool and and do things like it's not
obvious that that's your knowledge proof
in either these cases needs to be
interpreted by a chain
um and so the requirements in this
quadrant are quite a bit different um
than and then the the quantity e was
talking about and that like verification
complexity doesn't matter as much
verification complexity matters its
thickness because
um or matters when you're verifying on
chain because you don't want the chain
to have to spend a lot of gas to verify
your proof but if a human's verifying it
like whatever right like uh it can be
done somewhere else uh like off chain
and or like you know it can use like
some
like even consumer Hardware is more
powerful than a chain
um proving complexity tends to matter a
lot more because we are operating
usually on a consumer device for proving
so consumer device proving friendliness
as well um this is something we think
about a lot is how do we make things
work in a web browser how do we make
things work in a mobile device
another piece is you know like given
that we care about privacy in the
Squadron is respect for sensitive user
information so if anyone was around for
um like you should talk earlier today uh
where where he's sort of been developing
this new deterministic nullifier scheme
um that came from realizing that we just
couldn't do a lot of things with private
key uh in in uh in a client device
because it would we would need to pass
this very sensitive piece of information
around different parts of application
memory
um and so we have to think of new kind
of like mechanisms for not having to do
that oh this is still me oh cool
all right so some of the some of the
some of the challenges
um that we see uh technical technical
challenges in the next six months um so
as I mentioned earlier like we need to
be very friendly unlike for privacy not
succinct uh applications and in research
constraint environments like mobile
devices like like uh
web browsers I think a lot of like
um 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 you know there's some like debate
around which of those two things wins of
course
um but if users are making proofs to
other or humans are making you proofs to
other humans uh we perhaps can't quite
make that assumption so we spent a lot
of time thinking about performance and
research in certain environments
um I
so specific like you know the specific
example that I gave earlier earlier with
ayush uh we need to think a lot about
um non-private key nullifiers like
non-private key uniqueness of identity
um 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
um
representing more crypto systems where
identity matters
um in snarks 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 uh you know cryptographic
signatures are made like like email mail
service like I mentioned earlier so
um we're constantly looking around to
understand where new networks are
forming and how to like put those
operations inside snarks so lock swans
talk a bit about some of the challenges
ahead for privacy and a lot of that was
dominated by finding new ways to improve
the user experience and find
applications I think on the sickness
side uh the split is the other way where
what you want to build is somewhat more
clear but you need to have good enough
performance to actually build it 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
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
um so we can do things like starting
with a very fast to prove uh system and
then wrapping it in an aggregation layer
with which transforms it to a cheaper to
verify system one form of that is
already in use with basic aggregation
but we can push it much further using
multiple aggregation layers
and the things here to really optimize
are non-native arithmetic and elliptic
curve operations for these snark-based
systems and a second direction is that
even if we really optimize aggregation
it's likely that the most interesting
operation statements to make are going
to require multiple circuits to prove
and so in this schema you divide up a
large computation with into multiple
pieces and then you verify each piece in
a snark and then you verify those snarks
recursively
so with the ZK VM and other ZK roll-up
VMS we're seeing the beginnings of
building virtual machines in this way
and I think that VMS for transaction
execution are just the beginning of this
trend in a separate Direction in the
last five years 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
um in the landscape today there are
actually a number of New Primitives
emerging which may be equally or more
exciting so systems like Nova allow for
much more efficient accumulation some
check based systems like gkr or
hyperplunk allow for fast and faster but
larger proofs which could get then be
recursively aggregated in other proof
systems that we already control very
well
and finally there's the potential for
much more efficient lookups and new
systems such as caulk and so each of
these represent a pretty big shift in
the way that we can design ZK circuits
and what type of programs we can express
efficiently in them and so it'll be
exciting to see how fast these can come
to production and what new applications
they can enable oh yeah
um and so so finally
um and to talk a little bit about where
we see kind of these two things
converging in the third quadrant
um this is probably what the future will
look like in the sense that so so that
the left side is the kind of uh 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 uh that is that you know that that
is in the kind of like succinct but not
private uh kind of like um 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
um yeah that's it sorry maybe a silly
question for the audience but um can you
explain a bit more like what actually
sing means like what's that probably
um you know in the Layman Layman
layman's terms yeah
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
hey and perhaps there's another distinct
slight thing which is
um 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 uh something that is
interpreted on chain obviously
um but yeah use answer is better than
mine would have been I was just gonna
say small
Hey so uh 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 uh there are multiple layers of uh
Integrity checks right that that is the
assurance that you get so uh and these
circuits are super complex and there
could be like a million arithmeticians
in in there right so what about the
security of uh these proofs because if
you have a single bug in a circuit right
that is gonna Traverse down to like this
very small proof that you will post on
chain so what are your thoughts about
that how is the security landscape
around verifying CK systems glad to hear
that yeah 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 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
um
I 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 uh 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 know hello uh what
measures can we take uh to make our
proofs Quantum resistance for the long
term
so 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
um so if you want something to be really
standing the test of time you probably
want to use one of those Quantum
resistant systems
um I just wanted to add to the 16
minutes part there's a difference
between space succinctness and time
succinctness
um and usually six things will mean like
both
um a question on calc
um what do you mean by caulk being more
efficient than um 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
yeah definitely like I would say we're
being a bit sloppy with the use of
succinctness here in most of the systems
that are deployed today you get both uh
verifier and size success uh with
regards to call I'm more trying to
gesture towards the idea that there are
people working on enabling lookup
arguments to be more efficient and that
that would really transform uh how we
write these circuits I totally agree
that they're not caulk is not like today
going to enable much more efficient
lookups
while the music is coming I guess we're
coming to an end
uh thank you so much speaker of Applause
to lakshman and Yi