Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
Agglayer Educational Series - Session 2
Recorded: March 20, 2025 Duration: 1:09:38Space Recording
Short Summary
The discussion centers on the transformative impact of ZKVMs in the crypto space, highlighting their potential to revolutionize cryptography, enhance interoperability, and drive growth through innovative projects and partnerships.
Full Transcription
. The their educational series, session two, ZKVMs are eating crypto.
In July 2024, OX Park that cryptography is undergoing a generational transition from special
purpose cryptography to programmable cryptography.
This has implications not just for the Web3 world
that we exist in, but also for a lot of other technologies
and the world as a whole.
So we're here today to explore the main driver
of that change, ZKVMs.
Let's dive into it.
We are discussing ZKVMs today for three reasons.
One, ZKVMs are a powerful new technology.
They're also quite challenging to understand.
We'd like to take the opportunity to explain the technology
in as clear and simple a way as possible.
Second reason is that the people and resources
at Polygon have contributed enormously
to the development of ZKVs. Not only do we have
ZK luminaries such as Jordy and Bob and Threadbear who work here at Polygon, but Daniel Luberoff
here on the call and Angus and their team have developed a modular open source toolkit called
Plonky 3 which helps develop ZK VM systems. Essentially, Plunky 3 enables developers to capitalize
on this new shift in cryptography.
So we'll hear from Daniel and Angus today as well.
Last, we're going to have Brian Song,
our senior DevRel engineer,
describe how the Ag layer is using the ZKVMs
for interoperability purposes
and how we're able to leverage the new cryptography
to unlock a lot of really important aspects of interoperability.
For those who attended our last session, we talked a little bit about how the AgLayer
is using the unified bridge to replace previous settlement solutions that were maybe piecemeal or more old world.
And we can see AgLayer as approaching the ZKVM
from a similar perspective.
The previous sort of versions of cryptography
were a little bit more special purpose.
They were rigid, they were not flexible.
But now that we have these tools available to us
through ZKVMs, we have a much more flexible, minimal,
and powerful cryptography.
And so we're going to describe how the Ag layer is leveraging
that new technology to make interoperability more powerful
and accessible for the masses.
As always, our program is going to work at like very,
from a newb level, kind of left curve, less
technical.
And then we're going to talk to Daniel and Angus.
Angus described himself as the resident esoteric mathematician at Polankey 3.
So it's going to get a little bit nerdier.
And then we'll finish with the pessimistic-proof benchmarking, which is going to be very, very
technical.
But the hope is that we're sort of touching on the same themes throughout each sort of
tranche of the material.
And so if you can stick around for the first part,
I think everyone should be able to capture that.
And then if you start losing it a little bit in the middle,
that's okay.
And then the very bottom,
this is only for the real hardcore folks.
I know you're out there though,
because we heard a lot of really positive feedback
about Brian's sessions last time as well.
So overall, really, really excited for folks.
And the main sort of hope that we want to take from this
is that the whole educational series is meant to
under sort of articulate the concepts underlying
the Ag layer and because they relate
to these larger challenges and discussions
that are happening in the crypto world.
So we're going to tackle these conceptual themes in plain language, as well as diving deep into the meaningful technical discussions
and with code on screen tutorials and walkthroughs as well.
The first session was on settlement and interoperability. The session today is on ZKVMs.
We're going to have our final session on May 1st around interoperability and developer experience.
We're also hosting these protocol
and research study sessions.
If you're really, really deep into the technicals
and you really want to dive in deeper,
these are an excellent way to look at the white papers,
look at the sort of the critical technologies
and the really, really cutting edge stuff
on a deep, deep, meaningful way.
We had our first session around fast interoperability
and pre-confirmations featuring Spire.
And then next week, we're going to be
talking about folding schemes and proof aggregations
on Novanet.
All this information is on agglier.dev
or our social handles.
And so please check those out.
All right, so now we're going to jump into the
first part of the section which is just talking the introduction to ZKVM from a non-technical
perspective. We're going to assume you have a little bit of background in cryptography,
sorry in the crypto world, so we're going to talk a little bit about digital signatures, for example, but just this is going to be the less technical of the sessions.
So just a second ago, I described a generational shift in cryptography that's occurring and I want to drill down into that just a little bit. analogies to describe this shift. And here's the first one. The shift from special purpose
cryptography to programmable cryptography is really similar to the shift of the limited
programmability of Bitcoin to the more computationally flexible Ethereum or other next generation
cryptocurrency networks. Bitcoin was really monumental and revolutionary for transferring
one asset to another. But it doesn't do a whole lot more than that.
The next generation of cryptocurrency solutions
like Ethereum or Solana introduced a whole range
of possibilities with smart contract programming
where developers could build entire applications within it.
And so this is the shift that's happening
for cryptography more broadly as well,
as we talk about ZKVMs
and programmable cryptography.
We're going from the more simple,
kind of narrow special purpose cryptography
to the more flexible and much more powerful
programmable cryptography.
But a lot of people might say,
I thought crypto uses cryptography.
It's in the title as well.
And this leads us to our first sobering slide here.
This is from Wicked.
And the idea that a lot of people have around cryptography,
especially within crypto, and I was very similar until I dove
into the technicals a little bit more,
is that we use a lot of cryptography.
But actually, at its core, the most powerful L1, such as Bitcoin, Ethereum,
and Solana, mainly leverage two powerful cryptographic primitives like hashing and digital signatures, and they scale
them with peer-to-peer networks. Now, there's a lot of really exciting stuff that's been happening over the past couple
years with ZKVMs and ZKEVMs. We'll get into that as well. But we're just talking about at a really
basic level, the technology and the stuff that's happening for everyday users on these sort of
larger networks. These networks like Ethereum are just as much a testament to the power of social
networks of validators and core protocol developers coordinating software upgrades and propagating
blocks. For example, just one block when you submit a transaction, it's included into a
block on Ethereum. There's actually two things that a miner does as it gets passed around.
The first is just making sure that the account is not spending more or less than has been
submitted. But then the account also has a private key to digitally sign your transaction.
And if the block is correct, then it gets passed along.
And if a certain number of validators check these blocks,
we consider the consensus to be reached.
But the validators are still checking the math.
They're also checking the digital signatures.
We'll get into that in just a second.
But there's sort of a peer-to-peer quality
to the consensus around these networks.
It's less a little bit about sort of hardcore cryptography than about the hardcore cryptography
being paired with the social element of it.
So just to understand where we're coming from with this cryptography, we're going to dive
in just to a little bit with the cryptography that they do use, which is digital signatures.
I'm sure folks on this call are familiar
with digital signatures, but if you're not,
whenever you sign a transaction on a crypto network
through whatever wallet that you're using,
you actually are using a private key.
This is the thing that you're not supposed to share
with anyone and you're generating a digital signature.
The digital signature, just quite simply,
verifies the existence of a, or the public key,
the digital signature verifies the existence
of a private key through a public key
and does not reveal anything about the nature
of the private key.
So if we were to simplify what the digital signature
actually is, it's using
a mathematical process, which we'll just clarify here as what we're calling verify here. And
it's able to verify whether using this digital signature, the private key yes or no associated
with this public account with your Ethereum address was used to generate it. It's a snapshot of truth about a very narrow piece
of information.
Critically, it's just testing out
does Alice's private key, was Alice's private key
used to generate this public signature,
public digital signature.
And just to be clear, this kind of cryptography
is extremely, extremely powerful and revolutionary.
In fact, for decades, the US government actually classified this kind of cryptography is extremely, extremely powerful and revolutionary. In fact, for decades, the US government actually classified
this kind of encryption as a kind of weapon of war
that couldn't be handled by citizens.
But they're also limited from a functional perspective.
They're only proving the existence of this private key
without revealing anything about that private key.
They do it really well and they do it very quickly,
and they do it with relatively small amounts of data,
but it's quite limited.
Now, let's talk about how we're shifting
from this digital signature, which just only verifies
the existence of this private key
into the broader world of the zero knowledge virtual machines
that we're talking about.
So to verify that a block or a transaction in the network is correct, the miner or the
validator checks two things, right? They're going to check this digital signature here.
Is it correct? Is the account that is associated with the transaction? Does their account,
has their account generated this digital signature?
And this is the cryptography piece.
It's comprised, it's concise,
and it's proving one thing over and over again,
which is the specific private key created this signature.
But there's another thing that the that the miner or the
validator has to check. They have to check that the math here is correct. And this is where we
start to see the limitations of the cryptography and we start to rely on the sort of social element
of these networks. We start to sort of see that validators have to check the math themselves.
They're going to essentially run these transactions locally, double check that the math works out, and then pass along the transaction.
So this is actually the generational shift that's happening in cryptography right now.
We're moving away from these digital signatures and more towards the general purpose cryptography
of zero-knowledge virtual machines. Rather than just being limited to the digital signature
verifying that the account is correct,
we're actually moving towards these larger
kinds of digital signatures that are not only
going to verify if it's coming from the account,
but also if the value is correct of the entire transaction.
And so we can start to use these cryptographic systems that
verify an entire transaction or entire blocks of transactions.
And we start to see this extrapolation happening,
and it's really quite powerful.
Because rather than verifying just a single piece of data,
we can start to represent entire large blocks of data and verifying them a single piece of data, we can start to represent entire large blocks of data
and verifying them with single signatures.
And so we're not just proving
this individual digital signature,
we're proving this entire transaction
or sometimes even blocks of transactions
or maybe even programs outside of crypto networks.
We're able to prove that they are true
and that they actually happened
with a single digital signature. So I mentioned that I was going to use two analogies. I'm going to sort of try to use one
more just to sort of explain the shift that the generational shift in cryptography that's happening.
If we think of the digital signature as verifying a single snapshot of an image, in this case, the private key.
But we think of this as a photograph.
The ZKVM actually starts to string together
a number of these different photographs together.
So rather than just sort of verifying
one snapshot of information,
it's verifying a series of snapshots,
maybe a series of transactions, for example.
And so by stringing together all these different snapshots,
we're starting to get this movement
and we're starting to get the whole picture of a system.
And this is the expansion and the flexibility
that's coming with these ZKVM systems
as opposed to the more single use cryptography
that we've been seeing previously.
And when we talk about ZKVM's eating crypto,
this is what we mean.
Not only are they going to be sort of expanding
from the digital signature to verifying entire systems,
which they're able to do through ZKVM's
and through ZKVM's now,
but we're also seeing a lot of teams
that have built special customized circuits,
starting to adopt this more generalized ZKVM systems.
So on the left-hand side, we have these networks that for the number of years have spent a lot of really amazing countless hours building these very complicated custom circuits,
which essentially were very brittle and very not very flexible. They're now able to use this new framework of ZKVMs to create generalizable
programmability and really leverage that. We also have companies like Succinct, Risk Zero that are building entire sort of
ecosystems off of ZKVMs as well. And then we have really exciting initiatives like ETH Proofs, which just came out from the Ethereum foundation, which is using ZK VMs to essentially do this real-time block verification of Ethereum,
which opens up a lot of wonderful possibilities around scalability.
And so the last part about this is that like with AgLayer specifically, since we're talking
about interoperability, we're really excited for the promise of ZKVMs
for interoperability.
And again, a lot of the previous efforts
around interoperability, we're trying
to cobble together different smaller pieces of technology.
And as we'll explain today, Aglir
is using ZKVMs from a more holistic standpoint
to capture this new exciting technique of ZK VMs.
So that ends our intro to ZK VMs and now we're going to go a little bit deeper into the technical
implementations of ZK VMs. Specifically, we're going to talk about Plonky 3 with Daniel and Angus.
So if we can talk about sort of,
so we just talked about ZKVMs
from a really general conceptual standpoint.
Now we're gonna sort of talk about
a really exciting toolkit called Plonky 3,
which allow folks to build these ZKVMs.
So with that, I'll turn it over to Daniel.
Daniel is the inventor of Plonky 3 and he works at Polygon on the Polygon 0 team.
I'll bring you on here. And Daniel's going to just talk a little bit about Plonky 3 from the
perspective of ZKVMs and building those systems. Thanks, Guggen.
Next slide, please.
So, in the past, when we started working on ZK technology, there was a lot more use of
circuits, and these resemble hardware circuits.
They're not very flexible.
They're a bit difficult to use, and you had to take this thing that you wanted to prove
and somehow express it in fixed circuits.
And more recently, there's been this explosion
or shift towards ZKVMs,
and there are a lot of different ZKVMs,
some of them based on RISC-V, for example.
So anything that can be expressed as a RISC-V program
can then be proven pretty easily.
And you can even use existing programming languages
like Rust.
So there's this huge set of ZKVMs now.
I've listed only some of them.
And a lot of them recently are choosing
to build on top of Ponkey 3.
So for example, Valida, SP1, OpenVM, Pico,
and a few others, these are examples
of ZKVMs that are integrating with Plunky 3
and using that as the prover stack.
Next slide.
So why are all of these projects choosing to use Plunky 3?
There's a couple sort of obvious reasons.
One is that it's fully open source,
and it has pretty good performance.
So for example, on my MacBook Pro,
I can prove close to a couple million
per site in two hashes per second.
But there are also a few more subtle reasons
that we'll go into.
Next slide.
And first, just a very quick background.
So our team, Polygon0, we worked on Plonky 1, 2, and 3.
And we've also worked on a couple ZK-EVM projects, notably a Type 1 ZK-EVM.
So this was designed for proving the polygon chain,
as well as other EVM based chains like Ethereum.
Next slide.
And we've, so we've worked on a few ZK EVMs
and we've taken a lot of lessons from that
in terms of what works well, what doesn't work well,
and what's important at the prover framework layer.
What do we need there to really support ZKVMs as best we can?
And one lesson we learned is that it's important to keep the framework very flexible.
So in Plunky 2 and Starkey, we didn't do the best job at this.
There was these libraries were sort of designed around a specific set of cryptographic primitives,
such as the Fry based polynomial commitments and this field that we called the Goldilocks field and so forth.
And it was a little it was possible, but a little bit difficult to support other primitives.
For example, we wanted to support other hashes
like Ketchac for Ethereum compatibility.
And that got a little bit messy because it wasn't really
designed from the beginning to be flexible and accommodate
those different options.
Next slide.
The other lesson we learned was that it's really important
to support, to have a strategy for supporting multiple errors.
And an error is basically just a set of constraints
that define what a valid state transition would look like.
So in a traditional ZKVM where there's just one CPU,
there would be one error that says,
what does a valid transition from the previous CPU state
to the next CPU state, what does that look like?
But in modern ZKVMs, there's usually not only a CPU,
but also co-processors.
So this diagram is taken from Velida,
where you can see there's a CPU, but there's also
things like an ALU, which accelerates multiplication
and so forth and is more specialized for that.
So there's one error for the CPU, one for the ALU,
and a few others for other components
of this overall machine.
And there's a few challenges with supporting multiple errors
like this.
One challenge that comes up is just,
how do you even express it in a language like Rust?
This syntax here is imaginary.
We can't actually do this where we pass a list of types
as a generic.
So that's one kind of hurdle to think through.
How do we even express it if we're
trying to have one prover library?
Next slide.
So related to that, the other lesson
that we've drawn from this is that it's not really
practical to have one prover library that does it all.
And it's really better to provide building blocks
and let applications build their own little prover
library on top of that.
And another reason for this is just
that there's so many variations of starks.
So the basic vanilla stark protocol is pretty simple, but there's all kinds
of variations which modify the core protocol, or they might do things like distributed proving,
or for example, in an early version of SP1, there was this scheme where they would,
the sharding scheme where they would do part of the proving for the first shard, then pause in the middle,
save some data to disk, go on to the next shard,
and eventually come back to the first shard
and resume that proof and finish that proof.
So schemes like this are, there's
just too many variations for one library
to support all of these creative variations.
And it's better to kind of be
flexible and let people develop their own provers to do exactly what they need. Next slide.
So this is the sort of design paradigm of Ponkey 3 is that we're trying to be pretty unopinionated. We're not really trying to have one prover.
There is a end-to-end prover in Ponki 3 called Unistark,
but it's fairly basic, and we don't really
expect more mature projects to use it.
Rather, we provide building blocks
for things like various cryptographic permutives. And then from there, we try to just leave the door open to
innovation on the application layer.
So applications can innovate with, for example, different lookup arguments,
memory arguments, and so forth, and even all kinds of different distributed
proving or other sort of proving algorithms.
Next slide.
And also coming back to multiple errors, it's really important for efficiency to not,
in Plunky 2, we could do proofs that involved multiple errors, but basically each error would get its own stark proof more or less.
And the eventual proof size was proportional
to the number of errors.
So we couldn't really have too many coprocessors in a ZKVM,
or the proof would just be too big.
And in Plonky 3, we set about to change that.
So we combine things so that it looks a lot more like a single proof.
There's still some parts of it that are specific to one error or one coprocessor.
But for example, they all end up using a single Merkle tree and a single fry protocol.
Next slide.
The other benefit of building on Plunky 3
is that we have these building blocks
in the form of pre-existing errors.
So right now we have a few of them for different hashes,
like Ketchak and Blake.
But in the future, we hope to have a lot more of this,
these building blocks that ZKVMs or other applications can build on,
where if there's maybe a new ZKVM that
wants to add a precompiled to accelerate a certain hash,
they shouldn't have to do that themselves.
Or if they want to accelerate some big num math
or something like that, they shouldn't have to start over
and reinvent the wheel.
There should be this toolbox of these existing primitives
that they can draw from.
Next slide.
That's it for my part.
And now I'll hand it off to my teammate Angus.
OK, great. Thank you, Kugen, for having me and Brendan for that. So I guess my goal
over the next sort of 10 minutes or so is to try and answer the question, why is Plunky
3 so fast? What are the different things that we've been doing to try and make Plunky 3
as fast as possible? And I'd really recommend, if you find this interesting,
to go and look at our GitHub repository.
Because everything I'm going to say
is sort of publicly available.
It's all there.
I think our code is relatively well commented.
And there's, I think, some fun stuff in there
that I won't be able to get into about sort of tricks
that we use to make code run faster.
OK, could I, next slide?
So I think the first statement as to how do we
think about optimizing Plonky 3 is trying
to answer the question of where do we want Plonky 3 to sit.
And I very much think of Plonky 3
as sitting between this huge field of mathematics
and these ZK VMs, where we're not trying
to produce a ZK VM ourselves.
What we're trying to do is sort of coalesce all
of this mathematics into a useful set of sort of tools
and similar stuff that can be used by these ZK VMs, which
can then be used by the user.
And I think having a narrow scope in this sense
makes it much easier to optimize,
because you don't need to sort of worry about absolutely
everything. We just have to worry about absolutely everything.
We just have to worry about the set of things
that we want to produce.
OK, clear.
Next slide.
So fundamentally, what is in Plonky 3?
So at the basic level, Plonky 3 rests on these things
called field elements.
And if you haven't come across this math before,
it's not too complicated.
It basically looks like modular arithmetic.
So you fix some prime number p,
and everything in Plunky 3 can sort of be thought of
as some element between zero and p minus one.
This isn't always how it's stored,
the sort of various tricks,
but sort of this is how it should be interpreted
in some sense.
And then almost all the operations we do
are gonna be addition and multiplication in this field.
So I've written here what modular addition and modular multiplication look like.
If you haven't seen this before, don't worry about it too much.
But I think it's sort of important to realize that almost everything that we're doing in Punky 3 can be written in terms of these sort of pretty simple mathematical building blocks.
Next slide.
So given that, I think it sort of
is clear that one of the first questions that you should
be asking when you come across this is, well,
what prime numbers do you pick?
What field do we work in?
And so I think one of the lessons over the last three
or four years has been that if you want your ZKVM
or if you want your backends to be faster, you should be using smaller fields.
So initially, people were using quite large fields
like BN254.
Then Ponkey 2 started using Goldilocks.
And now in Ponkey 3, while we do support these larger fields,
we really recommend you use some of our 31-bit fields,
so sort of Mercy 31, Koala Bear, and Baby Bear.
And I'll talk specifically about those three fields
for most of this talk.
I probably won't mention the larger two fields too much.
But I think one question is, why are these smaller fields
better to use?
Next slide.
And so the answer is basically, they're faster.
So here, as I mentioned, everything in Ponkey 3
depends on these two operations of addition and multiplication.
And here I've sort of given you the rates of how quickly you can do these 1,000 operations of these
things. And so what you'll notice is that BN254 is much slower than Goldilocks. And Goldilocks
turns out to be a little bit faster than Koala and Baby Bear. And then, and then Mercy 31 is the
fastest. So I think it's reasonable to look at this graph
and think that I've slightly lied to you, because I said,
Goldilocks should be faster than Koala Bear and Baby Bear,
but these numbers clearly show.
Oh, sorry.
Goldilocks should be slower, but these numbers clearly
show the opposite.
And so I think one of the things to take away here
is that there's a couple of different things going on
in your CPU.
And so the reason that Goldilocks turns out to be fast
is that when you want to do additional multiplication
on a CPU, it turns out that often there
is a huge distinction between 32-bit and 64-bit integers.
However, there does turn out to be a distinction
if you want to do a lot of these operations.
And so could I have next slide?
So modern CPUs and GPUs support these things
called SIMD operations.
And what this means is that instead of adding two numbers together,
you can add two vectors of numbers together,
where you say pack eight different 32-bit elements into each vector,
and you get to do eight adds at the same time.
And so if you can make use of this, this is much faster.
And these operations are where these smaller fields really shine.
Because in Goldilocks, we can only
fit four Goldilocks elements into one of these 256-bit
vectors, whereas Koala bear, baby bear, mostly 31,
we can fit eight.
And so you can see that once you start taking advantage
of these SIMD instructions.
And so here I'm dealing everything with AVX2.
If you're on a Mac, it's neon, and so numbers
are a little bit different, but the same idea holds.
But you can really see here that all of a sudden,
these smaller fields get much, much faster.
So despite Goldilocks being slightly faster,
if you're doing one operation, once you
start being able to batch these things,
you find that these smaller fields are six times faster.
And so this is one of the places where
Plonky 3 gets really fast as you
start using these smaller fields.
Next slide.
The next thing that we do is we look around and find
various operations that get used multiple times
across the code base.
And the point of these is that while these
can be written in terms of addition and multiplication,
it's often faster to write custom code.
As you can see in this table,
looking at QualaBare,
I've just picked four operations and shown you how much you can
speed them up if you write custom circuits for them.
We have a dot product,
we have A times B plus C times D,
with a dot product, we have multiplication by three,
and then we have division by two.
For the first three of these,
you get somewhere around a 50% speed up, which is sort of good,
maybe not amazing, but certainly worth having.
For division by 2, you get this ridiculous speed up
about 80 times.
Partly, this is because the naive algorithm for the division
by 2 is truly, truly appalling.
It involves inverting numbers, and you don't want to do that.
But I think the key point here is that we have these methods
available so that if you're trying to build on top of Plonky 3
and you need to, say, compute a dot product,
you don't have to worry yourself about, well, how do I do this?
You can just call our inbuilt method,
and you can rely on us having written
the fastest possible implementation that we can come up with.
So I think this makes Plonky 3 much nicer to work with because on top of these fields,
we have all these methods and you don't need to do nearly as much work yourself.
When you want to build things on top of us, we have these methods for you and when you want to
use them, they will already be fast. You don't have to do nearly as much of these optimizations
yourself. Okay, next one. So of course, so far I've basically been talking about
simple operations involving addition, multiplication.
In order to build a ZKVM, you need a much larger toolkit.
And so this is sort of broadly what Ponki 3 is filled with
once you get outside of say the field crate.
So we support sort of fast hash functions,
Merkle tree commitments, fast Fourier transoms, extension fields, sort of all the various things that you might need in order to turn sort of these basic mathematical operations into a proper ZKVM.
And the idea is that all of these that appear in Pocky 3, we will have optimized them as fast as much as we can.
So I obviously am not going to have time to go through each of these examples and talk about how we've optimized it, but I thought as a nice case example, I could talk a little bit about
one of these. So I'm going to spend the rest of the time talking about how we got Poseidon 2 to
be much faster. So Poseidon 2 is this arithmetic hash function, and this turns out to be quite
important for recursive proofs, where you want to prove something and then prove that the proof was correct. Yeah, sorry.
Should have said next slide.
And so what it means to be arithmetic
is that it means that it can be written purely
in terms of additions and multiplications.
And if you remember back to the slide a while back,
where I showed timings, one thing
that you can notice is that addition is
much faster than multiplication.
And so when we go through and check,
well, where in Poseidon 2 is the most time being spent,
what you find is there are two operations.
And both basically correspond to these multiplications.
So the first one is, at some points in Poseidon 2,
you have to multiply your numbers
by some set of parameters.
And the other one is this Xbox, where you take an exponent.
I'm not going to get into too much detail on exactly what
these are or at least where they come from.
But I guess the key thing to note
is that we don't have complete choice over these parameters,
but you actually do have a reasonable amount of choice.
And so one of the things that we did in Ponki 3
is we went through and worked out, well,
how can we make the best choices?
How can we pick these parameters to make these operations
as fast as possible?
Next slide.
So I guess the key idea here is that if you already know,
if you have a constant you're trying to multiply by,
often, multiplying by constants can be very cheap.
For example, multiplying by 0 is very easy.
You don't do any multiplication.
You just return 0.
This is one of the beauties of 0.
Similarly, multiplication by small numbers is quite cheap. So 1, 2, 3, 4, you can sort of multiply
them basically by just doing addition or nothing at all in the case of 1. And finally, we sort of
did some mathematics actually. So there's, if you go through our code base, you'll find a couple of
theorems here or there proving that like we can multiply by plus or minus 2 to the powers of 2 quite quickly.
And I think this is sort of fun.
So if you're interested in why these are fast,
I would really recommend going through and looking
at the code base.
But I won't go into it too much here,
because I expect people don't want to math proof
in this sort of environment.
The other change that we made is thinking about how
we can do with this exponent.
So before Plonky 3 came about, I think the main 31-bit field that people were using was Baby Bear.
And this is mostly good, but this has sort of this annoying issue that the best exponent you can use for things like Poseidon 2 is this x goes to x to the 7.
And x to the 7 takes about four multiplications to compute.
And this 7 is coming from you need a number which is co-prime to the factorization of p minus 1.
So basically, if you look at this here,
you can see that if you look at prime minus 1 for baby bear,
this is divisible by 2, 3, and 5.
So the first number that doesn't divide this is going to be 7.
So based off this idea, what we did
was we implemented a new prime field called koala bear, which is broadly very similar and has almost the same properties, but has the benefit of we can use
it at this exponent is x goes to x cubed. And so this only takes now two operations instead of four.
All right, next slide. And so as a rough sketch, this is sort of showing you how much you can
actually improve these things, these tools, if you go through and do these sort of showing you how much you can actually improve these tools if you go through it
and do these sort of tricks.
So if we take sort of a naive approach that just does addition
and multiplication in the sort of naive way,
it's not that Poseidon is slow, per se.
It's still relatively quick.
But you can see that as we go in our current approach,
we've gotten sort of more than a 2x speed up
if you use Koala Bear and a little bit under a 2x speed up
if you want to use BabyBear.
There's also some hidden advantages of KoalaBear
in that for recursive proofs, your recursion actually
gets much smaller.
So next slide.
And so this really turns up if you
start looking at some end-to-end proofs.
And so these numbers are a little bit worse than the numbers
that Daniel posted.
This is because I timed them on a slightly worse laptop.
But I think the general idea comes through,
which is you can see that KoalaBear is proving
700,000 per second, two hatches a second.
And this is about double the speed of BabyBear
and a bit more than that compared to Mercy 31.
But nevertheless, these are all proving a huge number
of hatches per second.
So each is good of good to use
if it suits your purpose. Okay, great. Thank you very much.
Sorry about that. Thanks, Angus. Appreciate it. Okay. So how about that? Holy smokes. This is some
incredible tech and we're about to go even deeper into it.
I'm gonna bring Brian Song up.
He's a senior dev rel engineer here at Polygon,
part of the protocol and research dev rel team
to talk about now that you've seen
from the Plunky 3 team, the toolkit and the optimization
and just honestly, just the hardcore work
that's being done at a really low level. Brian is going to sort of talk through
some of the application effects and sort of application uses of Plunk3
specifically when it comes to interoperability, pessimistic proofs and
then benchmarking those with different ZKVMs. So over to you, Brian.
All right, thank you.
Yeah, so PlasmisApprove, essentially,
it's a application that is built on top of ZKVMs.
And it is specifically used in the context of AgLayer
in this case.
And you can think of PostMispr as the firewalls
between different chains,
because when there are a lot of chains
that are connected on AgLayer,
and then they are able to cross-chain
and communicate with one another seamlessly,
we wanna make sure the cross-chain communication itself
that is coming from one chain, you know, it's safe before we pass it on to the destination chain. So,
yeah, if there's like some chain where they're trying to send some money, like one ETH over
to another chain, you first want to make sure this chain does have indeed one ETH in this entire
chain balance sheet before passing it on to the destination chain. So yeah, so
what it really does here as you can see it guarantees that even if a
prover, even if the chain itself has an unsound prover like a ZK proof, their
ZK proof doesn't work for
their block proofs. At least we're able to make sure that the money that is coming out
is indeed acceptable before we pass it on to destination chain to prevent any further
harms. So in this way, the soundless issue cannot infect
the rest of the ecosystem.
Next slide, please.
So if you want a sort of a visual sort of a mapping
of how this will look like, just think of it as an airport.
Every cross-chain transfer on ACLR is screened and validated
before it gets into the act layer
from the source chain. Basically, you have to go through that layer of sort of a security check
and that's what pessimistic proof is. And once the security check passes, meaning the money actually
did come out from your chain and now the money is able to be claimed by the destination chain. So that
is sort of a security measurement that we're trying to establish. Next slide, please.
So that's pessimistic proof. And why are we using ZKVM to build this? Several, I guess,
benefits that Angus and Daniel has explained,
but mostly is regarding the traits
of trustless verifications.
It's pretty efficient to generate proofs and verify.
It comes with the ZKVM toolkits, such as the SB1
provides a lot of configurations for your proof generations.
And also, the verification itself is super simple.
You can do it on chain, off chain, regardless.
It all comes with the package.
And then consistency across environment.
So even if you're this Rust code,
it can be ran in different ZKVMs too.
So right now we're using SP1,
but this could be eventually designed
into a multi-prover scheme.
But that's more for a future discussion
where sort of thinking about what might be
the best solutions for this.
Because right now, ZKVMs, they all might look similar,
but as time goes by,
I'm sure they're gonna start to diverge quite further
from one another for different ways
of optimizing their constraints
and also different ways of applying their ZKVM
into different use cases.
Some might be modular,
some might be vertically very optimized.
So yeah, there's a lot of room to research
and then dig into, But yeah, that's for
the consistency part. And then of course, the CKPerve itself, meaning it's immutable execution
proof, and then also the security. Next slide, please. So how does pessimistic proof work? This
is a very ugly graph, but it's just a very simple diagram that showcase there's
three party place in this pessimistic curve.
So first, local chain has to prepare certificates.
Certificate it's basically a data or sort of a claim from the local chain or the layer
two, in this case, where they prepare say, hey, you know, these are all the money that are transferring
out and I'm claiming in from, you know, within this block building time period. And once I prepared a
certificate, I send it over to Aclair, and then Aclair will be populating inputs based on the
certificates for the pessimistic proof.
PP is pessimistic proof in this case. And then once it prepared all the input data,
then it will run the pessimistic proof Rust program. Remember, you know, this is pessimistic
proof program is written in Rust. And if you run that Rust program inside ZKVM, then yeah,
the ZKVM will be able to prove the correct execution
of that Rust code.
That's the logic.
But first, before we pass it into the ZKVM,
we first wanted to run it in our local environment,
in the native Rust environment,
just to make sure the pessimistic indeed runs correctly.
You don't want to run a program that is going to come up
with an error result inside of the KVM. It's a waste because you're proving a wrong execution.
There's no point of doing that.
So after you validate it that it's
going to run correctly inside your Rust program,
then you sense this pessimistic input to the Provers network.
In this case, we're actually the Provers network. In this case for Acclera,
we're using Provers network from SP1 from succinct labs
and we'll run the exact same code that we did in step four,
but inside ZK VMs.
And Provers network is much faster
to generate proofs than locally.
So that's why we are integrating with them.
And then after you get the proof,
the Provers network will provide a proof back to AccLayer,
and AccLayer will do a validation.
And if this passes, meaning pessimistic proof is accepted,
then the cross-chain transfer from this local chain
will be passed on to the next step,
which is waiting for other chains to settle on layer one,
et cetera.
Next slide, please.
So yeah, so that's the basic logics of Pessimistic Proof. And now we'll just quickly dive into the benchmarks
of Pessimistic Proof.
The list right now for this case, it's SP1, RISC0, and Pico.
And we're gonna add more ZKVMs along the way.
Right now we already are working on OpenVMs,
as well as Valida.
And expect to see more.
Next slide, please.
So this is the setup.
If you use Google Cloud before, you
should be able to find this instance, G2 standard 32.
It does require GPU, especially for SP1 and RISC0.
So just so you know, this benchmark
was conducted on CPU and GPU.
SP1 and RISC0 was done on GPU, whereas Pico is done on CPU
only.
So just expect a significant difference
in terms of performance.
We're gonna later add the CPU comparisons only
between SP1 and PQoT as well to do a more fair comparison.
But in this workshop,
we're just showing a general sort of data stats
of the benchmarking.
And yeah, it is recommended to at least have 16 core CPU.
32 is preferred because we have a lot of hashing
and there's a lot of input data that we're passing it
into the Ziggy VMs for generating pessimistic groups.
So, and then also the memory as well.
Higher the better.
Right now I'm running on 128.
I think the lowest I tried was 60 something. It was a little bit slow. But just so you know, this is a reference. If you wanted to bench
it yourself, these are some of the hardware setups that is required. Next slide, please.
And this is sort of a heat map of the entire execution itself.
This is a heat map of 20 bridge exits, basically 10 withdraw,
10 deposit transactions.
So there's 10 transactions from this local chain
that is bridging out the money, and there's 10 chain that is bridging out the money,
and there's 10 transactions that is bridging in the money.
So it's not a lot of bridging activities, but among this like 20 bridge events,
this is the flame chart that you can see, about 75% of the competition is mostly
the computation is mostly a catch-up operations.
So a lot of rooms can be,
there's a lot of things can be improved
based on this graph,
but I think the most that we need to optimize
is using the fastest catch-up as possible.
So this, our benchmark that we're gonna show
in the next slide is gonna be,
all of those ZKVMs has applied
the Ketchhap pre-compiles from their team.
So it's optimized in that way.
All right, next slide, please.
And this is sort of a rough chart, as you can see.
RISC0 also has different profiles
in terms of compressed, I forgot the name,
but it's like the compositions for the receives.
You can also do growth 16 as well,
which we'll add those data later.
But right now, as you can see on the left side
is the cycle counts and on the right side
is the time it took on my machine to generate pairs.
And then for the cycle count,
all the Plonky 3-base,
right now it's just Pico and SP1,
their cycle counts are about the same,
the red, yellow, green, orange,
all these are the Plonky 3-base CKVMs,
whereas on the RISC0,
where they have their own probing backend,
and also their own compilation, all that,
they have a way significant, way less cycle counts.
But if you look on the right, the performance wise,
SP1 core, which is sort of the default version
of RISC0 as well, the compressed and GROUP16
is more of a use case tailor, a less performant one,
whereas core is basically the most performance version
of SP1.
And then if you see the comparison,
it's a little bit small,
but the red one is always lower by a little bit
than the blue one,
which means SP1 core is still faster than RISC0.
And then you have the compressed and GROW16,
which in Aclair we use the most.
We use compressed, we also use the most. We use compressed.
We also use the plunkers,
which I don't have in this chart.
And then Pico seems like it's a lot slower
is because it's only running on CPU.
Later on, they're gonna support GPU version as well.
They're crazy on working on it.
Like they're shipping it real fast.
So really looking forward to their GPU version
and update this chart as well.
Yeah, next slide please.
Okay, so right now let's check out the code just quickly.
All righty, I'm gonna switch here.
This is like our code on screen section of it.
We have some questions coming in here, but if folks want to ask questions for either Daniel, Angus, or Brian, just while Brian's
getting this queued up, I'll put this QR code here. And yeah, go ahead, Brian.
Yeah, so this will be the repo. If you wanted to check it out, this is just type my name and
aclera pessimistic proof. You should be able to find it.
And inside here I basically have all the benchmarks.
Inside this pessimistic proof bench folder
and then inside create you should be able to see these are the pessimistic
proof folders from aclera repo. I kind of
stripped it off and we're using 0.2.1
if I remember correctly, version of the pessimistic proof.
And as you can see, we're slowly adding more pessimistic
proof with different ZKVMs.
Right now the working ones are the Pico, RISC0 and SP1.
Valida is adding on the progress, OpenVM as well.
Nexus does not work yet because they don't support
the standard library where we do use standard library
for pessimistic proof.
So we'll have to wait till they support.
Yeah, and if you scroll down,
you'll be able to see the table of content. We got, we got the benchmarks of ZKVM's and you will see how to benchmark and some of the benchmark
reports as well. It's not fully updated yet. I'm still working on finishing all the data.
And then if you want to learn more about pessimistic probe, here's all the explanations and how you can run it, etc.
So right now in this workshop,
we'll just try to run a simple benchmark on Sucsane SP1.
We're using their 4.1.3 version.
And first you want it to generate an EFL
of our pessimistic proof program.
of our pessimistic proof program.
And how you do it is,
so this is the repo that I'm in.
Basically you just clone it and then you get,
and then once you get in,
you wanna get into a pessimistic proof bench,
create PPSP1 and then PPSP1, yes.
PPSP1 and then PPSP1, yes.
Yeah, maybe not the best naming,
but yeah, I guess the worst done.
And then we need to, this cargo prove,
prove is basically their CLI.
So if you haven't installed SP1 CLI yet,
you just click on this guide
and then you'll be able to install following this link.
And once you install their CLI, and then we'll
just build the ELF.
So I already pre-built it before.
If it's your first time, it's probably
going to compile for a pretty long time.
But yeah, just let that flow.
But eventually, you'll get the ELF inside this ELF folder.
OK, I named something wrong, but it should be in here.
Oh, yeah, I think this is probably it.
Yeah, PPSP1, yes, that's the thing.
Okay, and then now that we have the ELF,
we will go, we'll just be running
the proof generation command from the PPSP1 folder.
So yeah, inside PPSP1 folder,
what we're gonna do is this is going to enable
the AVACS capability.
And then this is pretty much going to help you log
the proof generation process.
And then also is pretty much going to help you log the proof generation process. And then also, carcal run, basically, just run our program.
And then we'll be running the PPSP1 host.
There's this file called ppgen that is basically the proof itself.
All right, and then we just let it run.
It's gonna take a little time.
Meanwhile, we can take some questions.
Yeah, that sounds good.
Thanks so much, Brian.
And yeah, we are getting a couple of questions in.
There's a lot of material that was covered just between the three sections
so we might start from the and I'll get I'll bring Daniel and Angus back up on
here as well we might start from the most left curve and then go make curve
and then go right curve just just in terms of easy to hardest how about this
one for either Angus or Daniel?
This one is a very intro question.
So it's like, why would a project use Plunky 3
over building something of their own?
Meaning what is Plunky 3 provide out of the box
that's beneficial for builders?
Yeah, I can take that.
I would say partly it's about the cryptography. So if a project
is very comfortable building their own cryptography, like the polynomial commitment scheme and
that sort of thing, then that could be a good option. And there are certain advantages to
having a prover stack specifically for one ZKVM. That's what, for example, Risk Zero does,
or a couple other ZKVMs like Triton and so forth.
But on the other hand, some project
would prefer not to start from scratch,
not to build all those cryptographic primitives,
and to be able to leverage some of the performance work that has gone into Plunky 3.
Great, that makes sense. How about this one here, which is...
Why would ZKVMs, which are all using Plunky 3, such as Pico and SP1, for example, or I believe OpenVM also uses it.
Why would they have different benchmarking performances?
Like, where's the differences there?
Where are the differences there?
Excuse me.
Yeah, I think there's a few things.
So one thing we can, one way we can look at it is for each CPU cycle, how much data do
we end up committing and committing here means we have to basically hash it into a Merkle
tree. And for this, each ZKVM has its strengths and weaknesses. For example, this is something that Velida focused a lot on,
on trying to minimize this and designed a custom ISA
where it's a little bit different from RISC-V
or anything else.
And it's a bit, it's just meant to have
this very lightweight commitment.
And on the other hand, if we look at something like SP1,
they're committing a bit more data.
But on the other hand, they have this GPU prover,
which sort of makes up for it because they can do the hashing
more quickly now.
So yeah, I'd say there's a few dimensions to compare.
Some of them have this more compact witness
and less work to do.
Others sort of have more work to do,
but maybe they have an acceleration that helps
to do that work more quickly.
Yeah, that's awesome.
Just to add very briefly, I think
one other thing to remember is that Plonky 3 is very modular.
So if you're building on top of Plonky 3,
we let you use as much from Plonky 3 as you want, but it's sort of totally OK if you want to use some top of Plonky 3, we let you use as much from Plonky 3 as you want,
but it's totally OK if you want to use some parts of Plonky 3
and then write some things yourself.
And so some of this may also be a reflection
of the extra modular bits that they've written themselves.
Yeah.
And also, for example, OpenVM, they're not just using Plonky 3,
they're also using Halo 2 for recursion,
for different use cases and different ZKVM architecture,
you can plug and play with different approvers.
And eventually, you can reference some Plunky 3
and use a part of Plunky 3 as well.
So yeah, that's totally up to the design and the use cases.
Great.
I have a question for Angus,
which is, does the smaller field that you were mentioning
for koala bear and baby bear,
does that imply weaker security?
Oh yeah, that's a really good question.
So the straight answer is no.
And so this is, I guess, what I touched on briefly,
I think in one of the tool sets
as we apply extension fields.
In order to get a high security for smaller fields,
you need to pass to these mathematical objects called extension fields.
There is a little bit of a cost here.
Once you start getting into these things,
arithmetic gets a bit slower.
But it turns out that for most of the proof,
the trade-off here is still very positive.
If you do most of the proof in these small fields where arithmetic is very fast, and then towards the end of the proof, the trade off here is still very positive. If you do most of the proof in these small fields where arithmetic is very fast and then towards the end of the commitments, you start
having to deal with extension fields where the arithmetic is a little bit slower. But the key
statement is yeah, as long as you pass to a large enough extension field, there shouldn't be any
cost and security. Great. Dan, do you want to weigh in as well or are you good? No, I think that covers it.
Perfect. Amazing. Brian, looks like the benching is,
the bench run there is complete.
Do you want to just walk through that really quickly and then we'll
do one more question and then wrap it up.
Yeah. As you can see,
these are all of the processing process,
sort of like computation process before generating proofs.
It's going to generate an entire execution trace
of our present-missing proof program.
And then after that,
it's going to generate this execution report,
meaning what are some of the assembly in RISC-V
that we use the most?
And then you will be able to see these counters here.
And then this could be where you realize,
oh, we might just like Angus mentioned,
multiplication is much more expensive than addition.
Then can we reduce the use of multiplication
for addition and stuff?
That's how you can, but of course this is not like
from a front-end language perspective,
it's a little bit harder to optimize,
but it also depends on the library that you use.
That's why there's a lot of,
that's why there's like pre-compiles and patches,
so that you can substitute the existing sort of the commonly used Rust libraries.
And you kind of, you substitute it
with the customized version where it's more,
way more optimized as using less ZK expensive operations,
but it's using more ZK friendly operations.
So that's why, and in this case,
we're using catch-up patches from SP1 as a different the operations. So that's why, and in this case, we're
using Ketchhatch patches from SP1 as a custom version.
And then, yeah, the summary here, you will be able to see,
this is the amount of cycle that was required
to finish running it.
And then the time it took to generate the proof,
it's about 51 seconds.
But of course, as the bridge amount increases,
in normal use cases, let's say, if there's 300 or 500 bridge
exits coming out from one chain to other chains,
you'll be able to see some of the benchmark results here.
We're still up. We just need to add the risk zero,
then we'll add a graph.
But yeah, as you can see,
we have like a thousand bridge exits,
then it takes about 1,192 seconds to generate a curve, etc.
Yeah, you can stay a close watch to this repo,
then you'll be able to see the latest
and we're gonna keep on updating the data
as ZKVN upgrades themselves.
But yeah, that's it.
Thanks, Brian.
It's really awesome to see.
Okay, so it's really just cool.
I just think to sort of see it
both from a conceptual standpoint
but then also with the Plunky 3 team here, you all here,
I know you're part of the team,
and then the applications of these Plunky 3 enabled.
I know Risk Zero is not, but Pico and SB1.
It's really cool to see kind of the full pipeline
for ZKVMs.
I was wondering just to sort of finish off
what each of you all, maybe start with
Brian and then Angus and then Daniel, what you all can say either has been surprising
about the sort of the development of ZKVMs over the past 18, 24 months or something that
you're really looking forward to seeing people do, whether within crypto or beyond. So why
don't we start with you, Brian?
Yeah, I guess I come more from an application perspective.
I really started my ZK journey back in 2023,
end of 2023 when I was looking into Valida.
And it was one of the very first ZK VMs out there
with RISC0 and MyDen as well.
And now that as you can see,
Daniel listed a slide with like tens of, I don't know,
there's even more that he didn't add.
There's like a ton of Zika VMs, which is good,
but also now that we have a lot of Zika VMs,
what can we do with it, right?
Pestimacy provides one use cases,
but I feel like there has been quite some discussions
around verifiable AI, verifiable games.
SP1 has showed us the POC of how to build a verifiable game
on top of their SP1 Ziggy VM.
Just think of Ziggy VM as an engine, right?
You have to build a car on top of the engine.
Otherwise engine is just an engine, it's useless, right?
It doesn't run, it doesn't have a wheel.
It's only loud. So,
yeah, thinking about those use cases, what kind of car I can plug it into and what kind of road
that I can climb, it's pretty important. And I feel like for a verifiable AI, I feel like it's
pretty cool use cases. I don't think we should run AI entirely in ZKVM. It's just kind of
not viable. But you can run AI in a trusted environment or maybe not
trusted, but find some ways to leverage their security. But you can do coordination inside
ZKVMs. Of course, you can do it on blockchain, but inside ZKVM will make it much smoother
experience. So yeah, there's a lot of things that I feel that can be explored in ZKVM use cases.
So yeah, I'm more than interested to looking forward
to see what people can build on top of the ZKVMs
and of course, on top of these punk three-base ZKVMs.
Amazing.
How about you Angus?
Yeah, it's a good question.
So I mean, I think I sort of agree
with a lot of what Brian said.
Like I think it's certainly been, I think I sort of agree with a lot of what Brian said.
I think it's certainly been, I've been impressed how much faster these things have gotten,
particularly over the last sort of four or five years, or I guess maybe I should say
two or three years, that really gets you to a point where you can actually prove these
things.
Because I think if you go back sort of two or three years, we sort of had proving systems,
but they would take, you know, 30 seconds or a minute to prove something.
And at that point, you can't do too much with them, unfortunately. So I think that speed-up
seemed pretty exciting. On a much lower level, I think there have been some really interesting
developments on what does the right back end look like. So I think Plonky 3 has done an excellent
job on this easy-to-use and fast back backend. But there have also been some other ideas recently about, say, BNES is dealing with
fields of the smallest possible field of the field of two elements.
There's been lots of interesting thoughts about should you be univariate versus multivariate?
I guess these words mean something to you or they don't mean something to you, but it's
been great to keep up with the field, which has been moving really fast in the last year or so about different ideas of
how you can get these proofing systems faster. Very cool. How about you, Daniel? Yeah, in terms
of things I'm excited about, I would say maybe more sharing of code and resources. I think we're
already doing some of that,
but there's a lot more that can be done there going forward
where it used to be that everybody kind of started over
and re-implemented the same hashes and so forth.
And now we're trying to move towards a ecosystem
where there's this toolbox of primitives,
like pre-compiles and other resources
that different projects can draw from.
That's really cool.
I know Plugin 3 is leading the way with that,
both in terms of the open source nature,
as well as just encouraging other projects to build on it,
and just sort of seeing that whole ecosystem bloom
is really exciting as well.
Amazing.
Okay, I think that wraps it up for us. Thank you
all so, so much, Daniel, Angus and Brian for presenting. Thank you so much to everybody who
watched. We'll have our third and final installment May 1st and just keep an eye on socials and the
website for everything else. But until next time, we'll see you all then. Thank you so much. Take care. Смотрите на наш канал!
