Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
zkEVM: The final Testnet before Mainnet
Recorded: Jan. 11, 2023 Duration: 1:06:49Space Recording
Full Transcription
. Hello?
Hey, Grace. Yeah, we can hear you.
Hey, everyone. We're just starting a couple of minutes early so everybody can get settled in.
Let's just give it a few minutes before we begin.
Awesome. Thank you.
I think Jordi is yet to join, right?
Jordi should be joining us any second now.
David is here.
Yep. I think I've made David a speaker. Yep. All good.
Perfect. I see Jordi has joined. Jordi, I'm just sending you speaker request.
And then we'll still just give it a few more minutes, let some more people join.
Everybody settle in. Thank you. Hello, can you hear me?
Yes, Jordi, I can hear you.
Perfect.
We're just waiting for a few more people to join and we'll get started soon.
Awesome. Thank you. Shall we get started?
Yep, go ahead.
Wonderful.
Hello, everyone.
It's really great to be here.
I am very happy and excited about doing this, not only this one, this Twitter space,
but also the series of Twitter spaces that we'll be carrying out throughout our journey into mainnet.
I am Grace, and I am the CKVM product delivery lead.
lead. I am very happy to have the opportunity to have here David Schwartz and Jordi Bailina
as our speakers. Hello. Hello, Grace. Hey, everyone. Hello. Hi. So it's good to get started
with this particular Twitter space. We've been looking to have the opportunity to not only have the proper space to discuss,
for example, in this particular one, the test net
and what expectations we should have around that.
I think David is going to talk to us about that,
but also offer some clarity around our design decisions
for the CKABM, confirming what is valid and what is not
and why are we making
certain choices. And more importantly, we're here to connect with you, with our community.
And we hope that we can get lots of questions from you. There are very few times where we can
gather all together and answer these questions, and we hope that this is the great opportunity we can all take to do that.
So with that in mind, let's get started with David.
David, are you ready?
Sure.
Great.
Please, let's discuss here with our community so that they can also prepare some questions
since they have. Give us an overview of what has led us to what we have today as CKBM and Testnet.
I think you have a great history that you can share with us.
And more importantly, how do we get to this public and permissionless Testnet?
Sure.
Well, the Testnet has been a very long road, has been very exciting part since we
announced the project in July 2021. Later, we joined hands with Polygon around August,
more or less. And we have been working super hard because the main important milestone in the CKVM always has been the CK Prover.
And Jordi can talk more about this later.
But the Prover is the core and the engine of the whole system.
So it has been a long path until we were solving challenges and many technical decisions, many, let's
say, barriers to just overcome.
And at this stage, we are at the public testnet, which is kind of the preliminary scenario
to the mainnet.
And about public testnet, I have to say that it has been designed around
the engine around the CK prover and this means that the main objective of this
initial testnet has been to just verify and validate the model basically the
prover is the element that creates this validity proofs where we just verify the correct
execution of the user transactions and in the case of the evm you know you need to support
arbitrary user code in this transaction so any application that actually is currently running on
ethereum needs to be accepted and executed.
So this is where the complexity comes,
that you need to be prepared for any kind of user transaction.
And the prover is kind of the element that we wanted to test better.
So the testnet today is a second version.
The initial version of the testnet was intended to just connect the prover and see how everything is running,
how everything goes.
And this second version has been
including an improvement in performance
in terms of the proof recursion.
So again, the idea of the testnet
has been to prove this concept and to mature the solution
around the prover because the network client also needs to be supporting this effort of
EBM equivalence that we can discuss later.
But the design of our CKBM was intended to provide this seamless experience,
this no friction for users to deploy existing smart contracts.
And the prover needs to support these arbitrary user transactions with complete proofs.
So once we are able to connect all these elements and put this testnet out, we are sure that the whole engineering process is, let's say, complete and that we have absolutely we have some bugs, we have some challenges, specifically around performance today.
But the whole project is considered to be feasible, it's considered to be practical.
And we can discuss later more about this path. But today we are super excited to see that
the first testnet we had around 15,000 proofs, validity proofs for different batches with user
transactions. In the second testnet we have even user load, and we have been managing to create like 50,
55,000 proves already. So that's a lot of activity. And we have the model for the CK
provers to run in parallel, to scale horizontally. So we can just, you know, have the whole
infrastructure ready, and we have the model in terms of cost ready
to just deploy Minux.
So this is the overall story in short.
But we are super excited today
about how this testnet is running
and the results and the learnings
about this first and second testnet.
That is wonderful
David
I mean
this is a
this is something
important that
that our listeners
should know as well
it's a
we have
achieved great
you know
great progress
we have achieved
our goals
but there's also
a lot of challenges
that come along
with that right
so it's important
for our listeners
to know
also what are the challenges
in what has been so far our first testnet and now our second testnet.
Yeah, absolutely.
Can you tell us a little bit about that?
Absolutely.
So the first testnet was the initial release of the connection of the prover and the client.
The idea was to, you know, collect all possible information about how the prover was running.
Because the prover, when I say that the network or the CKVM was built around the prover,
it means that we want to make sure that anything that's,
let's say, executed in the network client can be proven.
So if you think about how CKVMs, let's say,
cover this ABM equivalence, we today are,
according to the model of Vitalik of the CKVMs, we are a type 3 CKVM.
This means that we are not supporting the 100% of the, let's say, pre-compiled smart contracts.
This is something we have already shared, and there's some pending smart contracts, sorry, pre-compiled smart contracts to implement.
some pending smart contracts, sorry,
pre-compiled smart contracts to implement.
But still, we need to offer, let's say,
the whole opcode support
and some pre-compiled smart contracts that are supported too.
So anything we offer in terms of opcodes to the user
needs to be proven.
So we are using in the client
the same execution environment that we are using in the client the same execution environment
that we just run in the prover.
And this is something we wanted to test.
And this is a very important step,
because from this design, we are
sure that everything that the user can execute
will be proven.
And this is where we simplify a lot of potential issues.
This is what the main, let's say, achievement that we wanted to test and to see running.
And this was happening in the first testnet.
In the second one, we have enabled some improvements in the SIGKey-Prover regarding the capacity in gas
of each of the batches,
because initially we had like 4 million gas per batch,
and now we have around 10 million.
And also we have reduced the proof time
because initially it was like 10 minutes,
now it's around five minutes.
And these improvements come also with the recursion deployed because we are able to just aggregate proofs because the main concept of the CK proofs around CKVN is that we are just creating user, you know, batches need to be passed into the process of the CK proof or validity proofs
to just validate the execution.
And the model ends with a proof in layer one
that's just verified by a smart contract on Ethereum.
So the cost model splits in several steps.
So we have the cost of the client, which is very low,
but there we have a cost which is relevant in the prover.
The proof generation is something costly,
although we have very good numbers here to share
because we are in a unitary cost in terms of proofs
is under a cent of a dollar.
So that's very low cost.
But there's another cost that's the
the cost in layer one proof and with the recursion we are able to verify a lot of batches
and aggregate them in a single layer one proof so this is also a very interesting step for the
scalability because we don't need to create a layer one proof every time we have a new batch, but we can do this two layer processing of the proofs so we can scale more horizontally in terms of servers and we have a lower cost.
So this was a big step forward in the second testnet that's already running super well.
Also, we are testing some improvements
in the bridge with layer one.
And what's pending for the next versions of the testnet,
which is kind of a great of the sequencing part.
So we want to provide better TPS, better throughput
because today we are around four or five TPS, better throughput, because today we are around four or five TPS
and we want to grow more for the main launch
because it's, for us,
currently the bottleneck is not in the proving size,
in the proving side,
where we can scale horizontally more servers.
But in the, let's say, sequencer,
because the first version of the CKVM
will have a centralized sequencer
and we need to be able to provide better TPS
so the network can be faster in terms of throughput.
That's quite a work that has been done so far.
And I feel like the challenges have been able to overcome in so many different ways. Geordi, but we have an amazing group of advanced developers and researchers that are really behind the whole implementation of this technology, but also the challenges, right?
And I think that that has proven a good amount of dedication from this team.
Now, if we take the opportunity to get Geordi to speak at this point.
Hi, Geordi. Hello, Grace. speak at this point. Hi, Jordi.
Hello, Grace.
How are you feeling?
Well, very good.
So just to let everyone know, Jordi is a little bit under the weather,
but even though he's not feeling 100%, he has agreed to do this event with us.
Thank you so much, Jordi.
I hope we don't make you do too much effort there.
But it's important to have you.
I mean, you have a whole number of fans that are listening to you right now.
And we'd love for you to start with explaining
a little bit about the design decisions
that we have made with CKEVM,
what has led you to make maybe some compromises or
even create some
great enhancements and performance
with the design?
Well, a lot of
engineering decisions.
Probably the most important one is
understanding that this project is
feasible. And what I mean, this project means
in a CK-EVM, in an EVM-compatible, in a non-code-compatible ZK roll-up.
This was something that two years ago nobody would believe that this would be possible maybe in the next years.
possible maybe in the next years.
together here, it's important to say
here, together with people from the Field Foundation,
especially Barry White Hat, we were
working together. We just
were running to the
major
problems,
talking about the memory, talking about
CDSA, so talking about different the stack, talking about different piecesSA, so talking about different, the stack, talking about different
pieces. How long ago was that? This was 2000, I don't want to be right, but this was one year and a half,
almost two years ago. So it was just after the launch of Hermes I. So just,
but this was
an intense
it was quite a
work, a parallel
a common work
in both sides
just trying to solve
these main problems
and at some point we just realized
okay, this looks like
it's possible
of course
that doesn't mean that the work is
done. Just the opposite.
The work just started
the challenges were
not really all of them solved.
You know, just
we needed much more.
And here is where
we started
to design
the ZKVM,
not from a scratch, but from this in mind.
And here is where, at the beginning of the project,
is where we took the main, I would say, engineering designs.
The first was, the project is huge and complex, so the first was dividing the project
in these abstraction layers. We have an abstraction layer of arimmitization. We built PIL. PIL
is a language for specifying this arimmitization, this polynomial identity language, and this has
been very crucial for the evolution of the project.
Then build this architecture,
this processor architecture that we are building.
Actually, what we are doing
is building a processor
that's running a ROM code.
It's a special processor
with a special assembly.
And this assembly is actually
interpreting Ethereum. Building this stack with these different pieces a special assembly and this assembly is actually interpreting uh ethereum okay this building this
stack with these different pieces of uh abstraction this is what allows us to first to build the
system in parallel here we can we could grow the the team uh uh quite in in in parallel. Here was also very important
at that point we were
merged
with Polygon.
From the financial perspective,
being able to hire a bigger
team, this was really, really, really
important.
But this design and the fact that we could
work in parallel is what
allows us to run quite fast
and build a system that's split in these different layers
that has been in parallel,
that they connect one, each other quite well
with very teeny interfaces in that.
This has also been proven that has been very important
also, for example, for auditing.
Even auditors, they can split the work in different teams,
different people just checking different parts.
And this is what has been able to create this project, which is huge.
If you could in a number of lines,
if you want, or a number of new things
that are in this project,
to do it just in one year,
one year and a half, if you want.
And this problem was the biggest, the biggest, the biggest.
Yeah, this was the problem.
Yeah, something that problem would take,
I don't know, five, six, seven years in normal circumstances.
We could do that in one year and a half.
And this is the big thing.
And this was because of these decisions that we took at the beginning of the project.
Of course, after the project ran and started becoming challenges, you see, okay, Ketchak, okay, we need to do a lot of Ketchak.
How can we do Ketchak faster?
And then here it's okay, we found out a way to create Ketchak much faster.
Another important point, another important breakpoint
in the creation of the project was the influence of Xero
and the other teams in Polygon.
From Zero, we just import all these small field,
Goldilocks ideas, all the hash functions for the Goldilocks,
and all the technology for doing fast recursion.
Recursion has said it's very important,
just not with a single proof to verify a block or to verify a batch,
but to verify a segment of a network.
We can't hear what we are aggregating batches.
And a lot of the knowledge and the technology you hear,
it's important by the zero people. people also the the structure of the stark
uh how we build the starch in the right way the optimal way here may then also help a lot and also
for the identification part so building all these sustain machines for different pieces
sustain machines for different pieces.
At the end, we were three projects that were doing similar things.
We were building an ABM, a ZKBM, at least, somehow.
So we were sharing the same challenges, somehow.
And the fact that we were working together in an open environment
and in a collaborative environment, this has been so great because we learned a lot.
We learned a lot from each other.
And a lot of things that were difficult for us,
maybe the minor people already solved or zero people solved
and the other way around.
So this has been a very, very productive year,
in fact, of solving, you know, small details.
How you do a CDSA in a fast way,
how you do arithmetic,
arithmetic 256 bits, arithmetic in an optimal way.
A lot of the details that we have been,
like solving, improving during the month,
doing new versions.
The methodology that we were using, this is quite common in cryptography.
It's just me and my closest team were building this in JavaScript.
Sometimes this is not in Python, in our case.
In JavaScript, this is just a prototype
but this allows you to
advance fast and go fast
and have really fast
prototypes. And then we have
a real engineering team behind
that's just writing all this code
in C++
in the right
way. But they don't have
the work
of understanding the protocols.
They are just copying the protocols
that come from JavaScript.
This is very much, for example,
how Ethereum was built.
The first version of Ethereum, for example,
was rated.
It was not in JavaScript.
It was in Python.
But the methodology was very much the same
because Python is very fast to write things,
to have prototypes, everything works, everything match.
You can generate the test vectors there.
You can validate that everything what you're doing is right
and you can start running the first test.
Then you put them together on the C++.
Going to C++ and not going to rust this is
because maybe somebody is asking that uh yeah so technical people i would say that the right
decision from the technical perspective probably was to go to rust but it was not a technical
decision it was not a technical decision alone. It was a
business decision here. So finding RAS
people, well first RAS people
is much more expensive.
They have much more rotation
in the projects. In general
it's much more difficult
to keep RAS people
in the teams
and C++ we can
take advantage of other industries
that there is
a lot of
excellent developers in
C++. Also besides that
there is also some other advantages
especially when you go to some things
about acceleration
you want to work with
GPUs or you want to work with
maybe clustering environments
and so on, C++ is still a little bit more
but it's still more mature than Rust.
This was a hard decision
but I think it was, here David,
you can maybe talk a little bit about that
but I think this was the right decision
at that point.
So... It certainly made you faster. It went faster, faster, cheaper. Yeah, it allows us to find
excellent resources, the resources that we had available in our hands where it came from C++.
So, yeah, it's like,
it's this kind of decision that says,
okay, you know that Rust has a lot of advantages.
I still appreciate a lot of the Rust.
I do not discharge to maybe to convert
the parts of the project
or having different versions in Rust.
Actually, I know that there is people in the community that's writing some of the of the project or having a different versions in rust actually i know that there is
people in the community that's writing some of the pieces that we wrote writing them in trust but from
going to market perspective just having a project in mind and converting that to a to a project
that's uh useful that anybody can use and you know going to main mainnet going to C++ I think
that was the right decision
it seems to me like we had
a few of the ingredients that have
really propelled
the progress of the project
and I think that like you mentioned
about the resources that we have found
within Polygon researchers
and the knowledge that the have found within Polygon researchers and
the knowledge that the Polygon co-founders and their vision have been able to create around CK
and CK technology as a whole, right? Yeah. So here, of course, when you need to do that,
you need to, you start along somehow, okay? So you start writing, maybe you have somebody at your side, but since you are a small team,
but if you want to build this kind of system, you need a team.
You cannot do that alone.
You need a, it's not a small team.
You need an important team.
I don't like to work with big teams, with huge teams.
I think that they are not very efficient in general, but here we needed
the smallest as possible team, but the high quality and it cannot be a one, two, three
persons teams. At least you need this at least 10, 15, 20 persons. Actually, I think David
could write me if I'm wrong, but I think that currently we are like 25 developers
in Polygonermis right now.
Yes.
This is, I mean, this is, it's a small team,
but it's a huge team, you know,
which is managing, doing 25 persons,
doing a single project is, well, it's an important thing.
So to build this team, to build this team actually, well, hiring the persons,
putting these people to work together, building this team is not an easy job.
I was really lucky to have access to really talk with,
actually what mainly the main strategy was to go directly
to the people that I've been working before in my own life.
That's a good strategy.
Knowing exactly people that you have the warranty,
that they are high quality.
So here we could build a kind of a dream team.
At least it's a dream for me to build with these people.
All the people that's around me, it's much more smarter.
It's much smarter than me.
Maybe some of them
come from other industries, so
they need to do a huge effort
just to understand some of the pieces.
We also had
the opportunity
to have people
that come from the industry
that has been
working for us
and mixing these things
has been really for us and mixing these things has been really, really, really, really amazing.
For me, it's a huge surprise
how well these things have been working
and the results are there somehow.
It's a dream come true with a dream team.
I would like to add, Chris,
I would like to add that. Please say for me, in terms of design decisions, the most important
decision was to be so crazy to aim for a sick AVM.
That was AVM equivalent in the first place.
So as you said before, this was supposed to not be feasible or be something
like targeting 10 years. And this craziness from Jordi was kind of, let's say, the trigger
for this project to happen. And we are super proud and happy that this happened. And then
no story short, it was a constant, let's say, battle to overcome obstacles.
And Jordan described some of them.
But we are still on that because the project is just starting, basically.
We are getting to the starting line because it's not about only being fast and quick to market.
This is why we made some decisions on the team, the languages, and all of it.
But also, we need to improve a lot because this was a scalability project in the first place.
And we need to not only prove that this is feasible, that this is practical,
but also we need to scale and scale a lot. So this is not over. It's just a step in the way.
We have been burning stages
for a couple of years.
And this second testnet
is what we expect
the final one before mainnet.
But this testnet
will get a lot of improvements
and changes during
the next weeks.
And the mainnet still will be a fast release.
We have the audit working in progress.
The audit will also bring a lot of feedback,
which is very important and required
because we are very concerned about security.
But at the same time, we have a long backlog of improvements
and features to include.
Also, in collaboration with other Polygon teams, where we are sharing a lot of ideas,
not only internally in Polygon, because you see all the source code is available in our repositories, and we have been making use of other teams' work, but we are also sharing all our work with other teams, which
is how we feel proud to work.
And we think that this is also an important contribution for the community.
And Jordi can explain more about the tooling, but we were also providing new concepts and
ideas for CK scalability and CK, let's say, in general.
for CK scalability and CK, let's say, in general.
And we have new tooling to the space
complementing the original circumsolution that Jordi built.
And we are now able to combine different technologies
like Stark and Snark
in the same way that we are doing in our CK Prover.
And this is opening also a lot of, let's say,
space for innovation in other teams.
And we are also not only excited, but also a lot of, let's say, space for innovation in other teams.
And we are also not only excited, but also very proud of this contribution.
And we expect that the testnet is, let's say, the final step for Mainnet.
But Mainnet needs to be, as I said, it's only the starting point,
because this project is a long run project and we need to do kind of a marathon here.
And we expect that the objective of scaling Ethereum,
which was in the first place why we are here,
is just actually implemented during 2023.
That's for sure.
That's what we'll make sure we will do.
Absolutely.
Thank you so much, David, for sharing that.
I still have some points that I would love for us to discuss, and you touched upon it, David, with the audit.
Maybe we can get a little bit more perspective about the audit from Jordi.
And obviously, this is very important for us
because this is something that needs to be completed
before we go on mainnet, right?
Yeah, actually this is the main piece that's-
The main piece.
The main piece is missing.
So right now we could deploy mainnet today,
just whatever is in testnet,
we just deploy mainnet and we have mainnet,
but this needs to be out of it.
This needs to be taken
seriously and as you can imagine
this project is huge and
there's a lot of pieces that can go
wrong and this needs to be audited
the right way
we hired two
teams to do the audit
they are doing both
teams a very good job
so far especially proud of the team from Spervitz.
These are a lot of people that they work or that have been working for the last years in the Thinium Foundation.
They are really going really deep in all the code of the ROM, all the administration, all the different
pieces, the phone, I would say, many things.
Some of them really important, which is a good signal that they are going deep on that.
But, you know, this takes time. it's not something that you do in a
in a week you know this we need maybe one extra month at least to to to finish this this
audits in parallel we're also running an internal internal audits and at some point we will open also a bug bounty program for the community.
Tell us a little bit about the internal audit as well, which is quite important.
Well, internal audit really is the people that's working,
but maybe at this point it's okay.
Work is like that.
Of course, there is a lot of improvements to do,
but instead of working in the improvements, point is, okay, work is like that. Of course, there is a lot of improvements to do, but
instead of working in the improvements, they just spend the time maybe analyzing, reading
and understanding what his colleague has done. But the instructions is to work as an external
audit. It's internal because we work in the same company but besides
that they they are doing a professional audit and this is also very good internally for you know for
sharing knowledge this is you know when you're managing these projects you need to
you need to take care that you don't have a single point of failures so that you have uh backup
people you know and this is for the internal organization this is also
very helpful but
the important is that
somebody else that's not
the main guy that built a specific
piece
it's reviewing
as deep as possible
for his own even if they maybe
writing some tooling around or doing
some tests or whatever just to make sure and to guarantee, to certify that this code is not in the right way.
Similar?
Yeah.
Similar?
Yeah, same way that the external audit are working, but with our own resources.
are working but with our own resources.
But it's important to note that we have had then several eyes looking into this,
not only two independent firms, but also the team is doing that internal audit.
So we're very much focusing on ensuring that this is at the right level of security
so that we can actually launch Mainnet.
We are doing as much as we can.
Exactly.
But what I'm trying to say is also that it's the first time, essentially, that we have audited a CKVM system.
So for the auditors themselves, this has been a discovery process.
themselves this is uh this has been a discovery process and they even have to uh come up with
their own tools and develop tools to to be able to do the proper audit on this is that the case
exactly yeah it's the case and this audit will will will set the the standards or will set a
lot of the standards of how these systems must work, must be audited.
They are doing, as I told you, they are doing an incredible work,
an incredible job.
It's super interesting the methodologies that they are using
just to analyze different pieces of that.
So this is very important.
It's really a very important piece on the system.
So, yes, we just need to get now the final result of the audit
and then ready to go.
So is that what's holding us for mainnet?
Is that the only thing holding us?
Or is there anything else?
This is the main thing, I would say. Of course, we are
factoring this
sequencer, as David
says, it's just a matter of
doing a better sequencer, just that
it goes much faster. Right now
there is still, the way we are doing
is, it's a little bit
slow, but, you know, just
changing some things.
This will just scale much faster
there is we have an integration with ether scan right now that's running in there
here we are working with something we have not announced here data we are working also
for the last proof right now we we have the Golo 16,
but we are working right now
in implementing Flonk.
What is that? Tell us a little bit about that.
This is a paper
from Aztec people
from Mariela and Zach.
It's an amazing team.
I would say that.
There's somebody from Aztek listening,
actually.
If they do,
they are,
I would say this is,
if not the most,
it's one of the projects
that's adding more
value to the
community
in zero knowledge.
Plonk was invented by them.
Plonk Up was invented by them.
Flonk, which is an optimization of Plonk,
is invented by them.
And from the research perspective,
they are killing.
Actually, it's what everyone is using.
It's their work and so on.
So one of the last papers I wrote is a paper called Flon,
which is interesting because as Flon doesn't require trust to set up
and we have some implementations, we already have some implementations
that we are very close to merge in the SNARK JS, that the verification is even lower than GROSS 16.
So we are now building the proving part,
but the proving part, we believe that we can,
it's gonna be maybe a little bit slower than GROSS 16,
but I don't think it's gonna be more a little bit slower than gross 16,
but I don't think it's gonna be more than two, three X, more than gross 16 in times.
This is a quite a small proof
because this is just the aggregation pools.
It's like the last proof where you aggregate many.
So here it's, we are talking about a few seconds,
but this is divided by all the batches that is aggregated.
So timings here are not, unless they are crazy, but this is divided by all the boxes that is segregated.
So timings here are not, unless they are crazy,
they should not be a big issue.
We're working very hard on that part.
And let's see if we can include that in the first version.
This will allow us to not have to do this trusted setup,
which Gros 16 requires.
And again, the cost, the gas cost of the verifier,
it's similar, but it's lower.
I think it's like 10K or 15K cheaper than verifying Gros 16.
So if this if everything matches which
it's matching, this is
the other thing that we are
working. I mean, this is not a requirement
because we can always start with
the gross 16 and run a
small
ceremony for the gross 16
and maybe we can update
it later. But if we can
go from the first day with this vlog,
that would be great.
This also needs to be out in, you know,
there is some work to do in that vlog.
But we are also working hard on that direction.
Awesome. Thank you. Thank you, Jordi.
I have like one more question and then I would love to open that to our listeners to see if they have questions, and that's what we're here for, right, to answer those questions.
So just before that, David, we discussed we currently are at a Type 3 CKABM, and the idea is to become a type 2
give us a little bit
background to that
Vitalik defines some kind of taxonomy
for CK-EVMs in order to
provide some clarity into some
messy arguments
between teams and so
so we are
targeting the EVM equival This, let's say, concept in Vitalik's
words means that we are type 2 in some way, targeting to this type 2, where we are compatible
with EVM, fully compatible with EVM. But at this stage, as I said before, there's some
pre-compilement concepts that are not very common in terms of usage
to be implemented, although we have this in the backlog to be implemented very soon after
the main launch.
So this is what's pending, basically, because we have already ABM equivalents for all the
upcodes of Ethereum for some pre-compiles too we have the same gas model and this is what
makes us let's say transparent for users and i would say i would invite everyone here to
to test the testnet to provide some feedback because we have a lot of projects that have
already deployed their d apps smart contracts and they have been testing. And our testnet has a format, which is not very common today,
but what we understand is a testnet, which is open, permissionless,
and self-service.
Everybody can just access and to just deposit some GoEarly Ether
and start testing there.
And any feedback is welcome and appreciated.
For now, we have a lot of, let's say, projects that deployed
that they are testing both in the first version
and the second one.
And the feedback is very, very good, very exciting
because they are just very autonomous.
They don't need us for anything.
They just deploy smart contracts and they work.
And you can see the proofs running
in the layer one smart contracts.
And if you want to audit the proofs,
you are free to do it
because they are open source since July last year.
And yeah, this is basically,
in our site, what's pending is
these three pre-compliant smart contracts,
basically Blake 2, Pairdings, and Shadow 256.
And from our site, it's going to be implemented very soon.
So we are virtually type 2,
although it's true that today we are not complete,
but the user feedback is very good,
and nobody is just missing anything for now.
So, but somebody is just missing anything for now.
So, but somebody can just miss the, for example, you cannot use pairings. This means that you cannot do a roll-up inside a roll-up, or you cannot play a CK application that uses these pairings.
But in general, most of the apps just run, and they run transparently.
So that's the current status of the testnet
have you come across any of uh of the partners that i have deployed on testnet have you received
any type of feedback you would like to share here sure sure the feedback is uh is very positive they
they just just uh they feel everything runs fine uh the only concern they have is about TPS,
which I just explained before.
This testnet was not designed to be super fast initially,
and we are doing this now.
Before mainnet, we have this sequencer refactor pending.
But in our site, it was most about testing that the prover is functional, complete,
and it's just not getting stuck, that it's very stable and so on.
So we have a model for the prover to be multi-instance.
We are just using, let's say, stateless servers for putting more provers as we need them, depending on the load of the network.
And this is going super well.
So performance is, let's say, in the proving side,
is just flexible.
And performance in the sequencing side
is what we are just improving now.
So this was basically the main feedback from the users.
Great.
And the strategy was to focus on the prover at first and then to start slowly addressing the performance issues with the sequency, right?
Exactly. Because the performance is the main objective of this project.
And we know we have a long run here.
But first thing, we wanted to that the the solution is kind of feasible
and practical and from here start accelerating
so if we have somebody that is going to go into our test net for the first time
what should be their expectations what should they expect at this point i mean
expect at this point i mean the course yeah yeah but the cool the cool thing of the system is that
you know they should not see many things special because and this is the cool thing because you
know creating a smart contract deploying smart contracts it's exactly the same that uh doing
that in Ethereum.
But you just connect MetaMask instead of connecting to the Ethereum,
to the mainnet or to the Agoril, you just connect to the CKBM testnet,
and everything else should be exactly the same.
And this thing that's very simple is the magic of everything.
So you don't need a special compiler.
You can still use Harhat.
You can still use Truffle.
You can still use the same Solidity compiler, Viper.
Whatever you are using, whatever application you are using,
it should take as is and run in the ZKVM.
And this is that so, you know, you know sometimes is you don't need to
do many things you know a new user should not do should not install any sdk should not install any
special things it should run smoothly and this is the i think this is the biggest advantage of the model that we follow.
An opcode compatible means that.
It's a model where you don't need to rebuild.
You can use the same tooling.
You can use the same thing.
You are just deploying one thing or the other. And this magic, this simplicity from the user is what I think makes the ZKVM stronger.
So that's what is to expect as well.
So no difference.
It's almost like deploying exactly in Ethereum.
A normal developer should not notice absolutely any difference running in one network or the other.
Excellent.
So now the expectations are set.
Anything that they could experience
that may not be according to plan?
Well, we're running the audits.
You know, audits so far,
so far they are going okay.
They are finding interesting things,
but nothing
you know, bugs that can be
fixed easily
it's interesting to see
also that all the bugs
that the auditors
found so far are
errors which are the ones that are more
the ones that we expect to have more
the mainnet is going to be a special mechanism
for protecting against this kind of errors.
So, yeah, we need to see.
Maybe there is some surprise.
I do not expect at this point, but you never know.
That's why it's better just to be cautious
and just wait until everything is said
and you feel comfortable.
Wonderful.
David, were you going to add something to that?
No, no.
I just explained that.
You never know.
We need to go step by step.
We are doing our best to achieve our plans
and security is kind of the open topic here
and you never know where these results of the audit will come.
But still we think that it's good that we get some feedback.
It's good that we get, let's say, bugs
or let's say, issues from the audits
because the sooner we find them, the better.
And here also the second challenge is not only build this,
but also getting
the the best maturity as possible and very soon that's the second objective
that's excellent so let's just quickly recap and i think it will be a great time to open it
to for any listeners that would like to ask some questions. But before that, just a little recap.
I mean, we have really gone, you know, in different directions
that are pretty much giving us a complete picture of where we are today as testnet
and how we're positioning for mainnet tomorrow.
So we have a prover, an engine that is working.
10 amps is completely out.
It's open.
It's permissionless.
It's absolutely public. amps is completely out. It's open. It's permissionless. It's absolutely public.
There is no restriction.
You don't have to apply for anything.
It's not conditional.
So it's something that is quite valued.
It's functional.
You can test it.
We are encouraging you to give us your feedback
and give us your experience
and how you are going through TestNet
because it's something that will help us moving forward.
We have great metrics,
having generated already more than 70K proofs.
So that's something to talk about
and the experience that the team is holding
alongside of generating this wonderful metrics.
The EVM equivalence, you know, going for a type 2 and continue to improve in getting closer to that EVM compatibility that it's desired from this team.
We're ready for MedNet. and the audit is a big factor,
and I feel like the fact that this audit process,
which is the first project, CKVM project that has been audited fully,
including every single component of the CKVM,
for me it's also an honor to be part of this team because we are setting standards there and we're allowing for this technology to evolve even stronger.
So those are kind of like some of the points that I wanted to emphasize and summarize from our conversation.
And if we have any questions, we'd love to listen to anyone out there.
Let's see.
This is the first time I'm doing the question thing,
so I need to make sure that I do this right.
Let's see.
We have somebody here from the community.
It's very slow, isn't it?
It's not connecting well.
I guess you are now a speaker.
Bullshit? Is that a uh are you there
okay i think we are then going for somebody else there's a few requests here
let's get you in.
It's just going really slow.
Awesome.
Hello.
Can you guys hear me?
Let's see.
Yes, there you are.
Let's unmute you.
Awesome.
Thanks for having me up here. The last hour was super insightful to kind of get a perspective on what you guys are doing.
Sorry, can you get closer to the mic?
Yeah, can you hear me better now?
Perfect, yes.
Awesome, okay. Yeah, thanks again for having me up here. The last hour was super insightful for just learning about what your team has been working on.
My question was, I'm curious, is there a lot of intersection between your team and the Polygon Nightfall and Polygon Zero teams as well?
I know there's a lot of ZK solutions that are coming out from Polygon, and this one, from my understanding, focuses a lot more on efficiency through roll-ups. But I was curious, is there a larger general ZK vision where a lot of the teams intersect?
Or is each of your teams siloed?
That was something that was really interesting for me.
Yes.
Yes, great question.
Thanks for that. I think this has been explained several times, but the mission of the team is to complete a different approach to scalability because there's slight differences in the approach.
basically to implement this CK roll-up.
That's, let's say, according to the concept of CK roll-up,
the data availability is on J.
We have this CK EVM equivalent proofs,
and we have this approach to scalability
according to a specific model.
So we are getting close to mainland now,
but one year ago, this was kind of incognito in some way.
It was difficult to know.
There's the Xero team.
They are building another approach of CKVM.
They are more focused on the performance.
They are focused on the, let's say, also an equivalence,
but they have also improving and getting ideas.
We're sharing a lot of knowledge,
and they are basically doing a different approach.
But there's also the Miden team.
The Miden team is doing, let's say, a CKBM.
It's not EBM equivalent.
It's a different VM, more in the way like a Stagmet, for example.
And this is a custom VM that's more intended to support specific applications that can
be just leaning or leveraging on a specific
language or a specific compiler. So we have a variety of solutions in terms of CK
and this is the moment where the projects are just building and trying to ship. This 2023,
a lot of things will happen and this is where this is the year where we will get, let's say, more specificity
on the public, let's say, strategy for these solutions. But up to now, we are collaborating
internally, sharing a lot of knowledge, and we are just contributing each other team. But
the strategies are separate because Polygon was doing this bet on the diversity and approaches
because the objective for Polygon was to get these solutions out there and functional
and in this open source model.
So at this stage, this is where we are.
And I expect that during this year, we'll be able to provide, let's say, more details about how these
projects fit together as we are more close to these final steps of shipment.
Gotcha. Yeah, that makes a lot of sense. Thank you.
Thank you, David. That's wonderful. Thank you for the question. We have another speaker.
Hello, hello hello everyone
hello
I think I work at Polygon so I
can ask some more questions
actually
it was very serious
I'll ask you
maybe easy questions
maybe David and Jordi around like, how do you see this year,
especially with a lot of like, I've been speaking to a lot of like, people who have been through
multiple cycles, multiple bear cycles. And what do you think this year, will be, I mean, apart from the ZK, of course, like ZK core
infrastructure will be built.
But in general, like, what do you think in terms of, like, apps or maybe some verticals
that you think would be more interesting than others?
Or you think ZK will be, will maybe open up completely new things?
It's the year of the scalability.
Yeah.
And that means that from the apps perspective,
you know, there are,
currently in the space,
there are so many apps,
so many apps that are not feasible
because the technology doesn't scale.
And there are amazing apps
you know
things you know tooling for DAOs
voting things
about insurance
future markets you know
if you see you have a lot of apps
that they are amazing
they are incredible
they can really change this is the real
promises these apps that have been building for the last years,
mostly since Ethereum started, a lot of apps,
that they require that Ethereum scales.
And in this year, we'll see how Ethereum scales.
Here is two pieces.
One is the ZKADM.
This is one piece.
The other piece I don't want to forget to mention
is the data availability.
Here the EIP 4844 and so on.
It's really important.
When these two things go together,
we will see real scaling on Ethereum.
And I expect this is going to be an explosion
for all the
dApps that
they are not
feasible, they are not practical
right now, and they will be practical
this year.
Yeah, thank you.
Thank you so much.
So I think we have one more
question and we will unfortunately have to close this session.
Who wants to ask the last question?
Go for it.
Okay, JM, JM.
Do you have a question for us? yes i do actually okay so my question is quite is quite
simple right so um in a world where we have definitely we have a whole lot of um evms and
roll-ups and the likes existing right now right what do you think is going to be the ultimate
selling point because right now after
the launch and everything right is where the community stands that the evms will survive
that's this roll-up that will survive what do you think you guys have that would win the zk race
the roll-up race what do you think you guys have differently? Do you understand? That's a wonderful question. David is so ready to say that.
Well, no, there's a lot of super exciting projects and very good teams out there.
We think our project is very special because we combine some things.
First thing, we are a layer two. Layer two benefits a lot from the security
of Ethereum. It's native. It's, let's say, decentralized because we rely on that. Second
topic is that we are not only layer two, but we are a CK roll-up. And CK roll-up have a lot of
benefits in terms of user finality. And I can tell you our finality will be excellent,
meaning excellent in order of minutes.
So this is where the users will have this confirmation
of the network, this state is final,
and then a lot of applications will be benefiting
from this finality.
And the last one is that we are combining these two
and also we are EVM equivalent.
This means user transparency, as we have been discussing before.
So this is for us the combination that we think is the best one.
And in addition to that, we are source code available.
Everything on our ideas are there.
So you need to also see which is the trust model because in the
CK rollups you have
the complexity of the prover.
It is cryptographic protocols.
There's some things that you need to
in some way trust.
But if the source code
is available, you could audit
yourself. That's a good benefit.
Or you can trust the audits that we
will publish once they are
just finished. But we think
we combine both this
let's say benefit for layer 2
this security model
and you don't need to trust anything
and the usability that we
can provide with EVM equivalents.
Lovely, lovely. Okay, good to know.
Thank you very much. thank you uh thank you everyone
excellent so thank you everyone for uh for joining us it has been a pleasure having you here
and obviously having the time to interact with you and also getting you to hear from the co-founders
themselves, David and Jordi.
Thank you so much, guys.
You're amazing. You kill it.
As usual.
Thank you, Grace. It has been a pleasure.
Thanks, everyone.
Have a good evening.
