Polygon zkEVM Mainnet by Jordi Baylina

[Music] Hello everybody. I'm Jordina. I'm the technical league at Polygon ZKBM. So as many of you know uh ZKBM is the next chapter of Ethereum is scaling. Okay.

And why was ZKBM a big challenge? Well, in order to understand that, let me explain you a little bit how uh ZK roll up works. Okay, from the user perspective, imagine that you want to do a transaction on a roll up. Okay, so what you will do is you will connect with MetaMask like you connect to any other chain and you should be able to do anything that you can do in mainet, you will do it in the in the in the rollup in the Zika ABM. Okay.

So the first stage that you will do is you will send this transaction to a to a sequencer. In this case at the beginning is going to be a centralized sequencer like many of the like most of the rollups right now. This and uh this centralized sequencer it will give you already a trusted state. This state is final as far as you trust this centralized sequencer. Okay.

So this is the first stage. The second stage is at uh once in a while maybe uh I don't know 1 minute 2 minutes or 3 minutes uh the sequencer will send these transactions to layer one okay here is where the data availability will send once these transactions are in layer one and are sequenced then you will have a like what we call it a trusted state is a state that anybody can compute because you you have the transactions on chain so you can if these transactions are processed in a determinist istic way you know exactly what's the current state of the network and so they are final they cannot they are save it on chain they are final but this state we call that's an implicit state is a virtual state it's a state that anybody can compute but uh is not on chain okay and in the last step maybe once every half an hour or something like that it's going to be another transaction that will take all the all these transactions that are on chain and will generate a proof that uh that uh that these transactions are processed in a specific way and you will have the state on chain. It's at this point where you will will be able to withdraw the funds for example from the layer one. Okay. And uh the big trick here for the ZKBMS is this prover.

Okay. This prover actually what it needs to do it needs to create a a validity proof or a zero knowledge proof that okay that you are proving that if you go from a specific state route and you apply a set of transactions you go to this new state route but these transactions are standard Ethereum transactions. These transactions can be uh send funds can be uh deploy a smart contract can be execute something on the smart contract can be anything and they have exactly the same format the RLP. Okay. So building uh circuit here is the biggest challenge part in the case of the polygon CKBM we created an architecture an architecture that allows us to build that and it's a multi-layer architecture.

So we start we have the if you want the the basic thing is the the the polomials and the polomial identities. This is very much to understand you if instead of building a proof we were building electronics it would be like the transistors would be like the the basic pieces of this with these polomials we built a processor a zk processor okay but actually it's a state machine it's a processor it's something that can takes a program execute this program and and and have a specific state okay and we use and we created a also a a language for writing this kind of hardware. Okay. So, we built a processor and on top of this processor, this processor has his own assembly. So, we build the assembly and we built a program on top of this processor that um and that emulates Ethereum that actually this program is taking transactions as an input.

It ex and it process the transactions following exactly the same rules as Ethereum. Okay. And in order to do that, well, we had a lot of challenge to solve because this processor then needs to do 256 bits operations. It needs to do the EC recover no u well signature verifications. Uh you need to do catch.

You need to do many things. Okay. And this has been the huge work for the last two years. Okay. But there is a last challenge.

Okay. Okay, once we finished that 3 four months ago, the last challenge was about security. Okay, and this is what I want to talk very much about now. Uh, as you can imagine, there is a bunch of lines of code, new lines of code, new systems. So, it's a lot of things that can go wrong.

Okay. So this requires a huge uh review a huge shouting and a huge process for that. Okay. So for the last three months mainly what we have been running is running a lot of outits. We run two external audits and one internal audit.

more than 24 uh so more than um uh more than 26 individuals were working uh uh in in specific pieces of all the code. Uh we we run also an internal audit. We went really deep on that and uh we found many things when we even we found some even some optimizations and some improvements has been a huge work on that. Okay. Some of the things were were critical.

We had to define even a way to so the auditors need to learn what are those process to audit all this code. The truth is that auditing this was relative. Okay. I'm continuing here. I don't know do not leave yet.

So yeah so this is the this has been running these teams has been running for for for for many things. We found many things we had to learn how we had to learn how to do these audits. We created a full process for doing these audits out actually these auditors created different process different ways to testing and I can tell you that these are uh the best auditors that we can get during this time. Okay. after well these auditors you can just to see the magnitude of this I mean these are the different pieces that the ZKBM has the bill is this like this hardware language where is this processor is definite we have a storage which is like another processor explicitly for working with uh the sparse merry here for the storage how you do the storage so it's like a full topic in there we have the ROM this is the program that's running on top of the processor that needs to be audited and check We have the smart contracts of course we have smart contracts as the roll up that needs to be audited and check it too and we have all the cryptography side here we are using very much starks and flunk in the last stage so and all this process needs to be audited and check it that's the right way okay besides that uh once we finish this audits we are finishing the last one so probably in one two weeks we will start the back bounty program here I invite you and any of the developers ers that are interested in ZKBMS uh just to uh invite you to to to to take a look to review.

There are some incentive to do that. We have a lot of material and documentation uh to learn that. So if you are interested on that we will run this bug bounty program on that. Okay but and with all this the question is are we ready to launch the mainet? Okay because I mean there is a lot of things on the stake.

Okay so let's do a kind of a risk analysis. Okay so when we have this DKBM it's like we need to say okay what can go wrong and how critical is that? Okay. So in order for that we um we split the things that can go go wrong in four different things. Okay.

One thing is something is wrong in the smart contracts and then the last three things is something goes wrongs in the prover. Okay. Um if we focus in the smart contracts this is like I mean this is a known technology. So we run two audits of the smart contract. We check on that.

We didn't find any measure things in there but I mean we went deep on that and and this is a known technology somehow. Okay. Um so this would be critical if something is wrong in the smart contract but here we have a high confidence that the smart contracts are going to be okay. Again zero warranty it's impossible but it's it's it's we have good confidence on that. from the audits.

Here we have three things that can go wrong. What we what we talk about correctness. Correctness means that you are probing something that the prover that you send a transaction and the result of this of the transaction is actually that uh you steal funds or that you your your balance account just gets much higher for example. This would be a correctness problem. This is really critical uh on this so that you are executing the the op codes and you are doing what you're supposed to do.

Okay, for this besides running the audits and the back bounty here we have a lot of confidence because our system is passing all the Ethereum tests. That means that we are we are getting all the we are so we are we have all the uh the the test suite from Ethereum. We are taking all the all the relevant all the relevant tests which is more than 13,000 tests and we are passing all of them. Okay, this is what give us the warranty that uh you know that the correctness of the proof is going to be okay. Again uh not 100% uh sure.

Okay, but this um you know this uh tests and this audits give us enough confidence uh to launch mainet. Okay. Uh the last two things is one is sonness. Soness is is is more tricky is I would say that this is much easier that a sonness back is in the prover. A sonness is when you can a sonness in the prover means that with the same state and with the same transactions you can compute two different states.

Okay, this would be a sness this would be a typical example of sonness program. Okay, in this case um we are um putting a a mitigation here that the mitigation is um we are going to be at the beginning we are going to be the only prover uh that can uh proc that can process that actually this is so this is not really true. We are going to be the the the only prover as far as we are building proofs. If we uh accumulate a delay of more than five days then anybody will be able to run the prover. Okay.

But because we are the the main prover uh we will not prove something wrong. Okay. So this pro pro programs are these bugs are mitigated as far as you trust this as far as you trust us. So as far as you trust the the prover. So this is not the best because actually you should not even trust us.

But at least we know that this in this in the beginning of the at the beginning of the when we are starting this uh we have the warranty the users have the warranty that the the prover is going to act correctly and even after we remove as a trusted prover the smart contract also contains a kind of a mechanism that is if you prove if you sign to proof that goes to different state then the smart contract will also halt and then of course there will be some some something wrong and we have to to update okay and The last thing that can go wrong is a little bit more specific for the prover is that imagine that you have a transaction that you cannot prove. So that you cannot generate the proof. This is a state and then what would happen here is that the rollup would just stop. You cannot generate proof. So the roll up would stop.

For this uh the mitigation is quite easy. uh what we do is just uh uh well if in a week nobody is generating a proof then the system will hold and we will be able to update uh to update the system. Okay. So this is our explain a little bit. This is the mitigations.

These are the trailing bills. Some of them I already explained it. Okay. We have centralized sequencer. We have a trust approver.

We have this soundness back detection by the smart contracts. Um we have this protection against this unprobable transaction. And even on top of that we will add temporary uh at least while we are in beta we will add also a a scape hatch gear switch. It's going to be a a security console that in at any moment we'll be able to just push a button and hold the system so that we can upgrade this this uh this is going to be run for independent people from polygon and it's going to be just temporarily uh the thing if we remove this this last one then we will be in according to Vitalik's classification we will be in training wheels two okay at the beginning going we're going to be training wheels one because this this this last Okay. So, I would say yes, we are ready for mainet.

It's a mainet beta. Okay. And here is we're very excited for that and I think it's an important it's an important milestone for the for the for the community. But again, uh it's a beta. Uh I think it's important that the users that's using this network understand uh the risk.

We want here want to be very transparent. We are going to publish all the audits. All this all the code is available. You can check on that. I would ask you to give a try to try this network.

But don't go crazy. I mean don't do don't put $1 billion in the in the network and and then we have some some some issue here. Okay. But I wanted to explain that uh we we will launch if everything goes okay on uh March 27. And yeah, just uh uh very excited for this main event.

So thank you and I will going to take questions right now. Yeah, we have six minutes. So I've been much faster. If there is no questions. Yeah, there is questions.

Okay, that's great. Why why select flunk, right? Why what why flunk? Yeah. Why was flunk the thought process behind that selection?

Yeah. Uh yeah, the flunk is I mean so our main prover is a stark and it's a set of um um um you know um um recursive starks on top of that and it's in the last just in the last state that we're verifying a stark with circuit with snark. Here you could choose grow 16. Here you could choose uh plon or you could choose flunk. Flunk is a new is a variant of plunk that has the advantage that the verification cost is uh more or less the same that gross 16.

So it's very cheap uh verifying a proof on chain. It costs I think it's about 235,000 gas units which this is really low. It's like gross 16. uh and it's uh the same that plunk it does it doesn't require uh tr setup actually well it takes the the it's it requires the universal tr setup but this is already run but doesn't require a specific tr setup so it has the same advantage of plong but it's much cheaper to verify the incompanion here is that the proving time is a little bit it's actually it's much longer but because this is the last stage of the prover this is it doesn't take that much okay and I think it takes something like about one minute and if you are doing that every 30 minutes for example it's more than enough uh time we're improving that that side but this is a it's quite new we are running right now an audit so the one of the audits that we are finishing right now is the flong protocol itself and the implementation of the flong protocol but this is one of the new things that we are adding that I think is interesting uh for for for for these systems If there is Oh yeah. Okay.

Thank you. Um I had a question about the um trusted prover stage of it. over what period of time ballpark would you say would be like the future from moving away from a trust approver to a trustless uh let's see um here we need to define exactly but the idea is we want to remove uh as as fast as we can the the kill switch the well the scape hatch this is the c the most centralized part that we have I expect that once maybe I don't one two months of running uh the system and if we don't find any big thing uh we plan to remove uh on that we we will continue doing audits and you know this bug bounty and we'll see how confident we are but we need to remove that very soon and regarding the trusted prover the idea is to start lowering down this this this u this time so that we start with five days and then we go four five three to one and Actually at at some point we just remove and we we just try to to uh well to let the market just anybody just can generate a proof and start this uh prover market start spinning up. Um I think this will be very very soon uh because we have the other protection. So we have we can be like running a prover in in the shadow and if there is something wrong we can always um generate the right proof and uh hold the system.

So uh even for that I think that this is something that's some mechanism that we will spin up really soon. I don't know if I need to sell you a time. thinking about few months but again we need to just plan and and and and that just before finishing I want also to maybe give you uh a little bit uh so what's the future after uh after the launch uh we want to work very much uh with the AIP4844 uh rollups the main limitation of rollups the bottleneck of rollups uh are and will be the data availability So the even in the ZK the prover is not the limitation anymore. The cost of the of the implic the impact of the proving cost in the transactions is not an issue anymore. It's is really uh cheap on that.

So we need to focus in the data availability data compression. Uh we want to also improve a lot the the sequence because the sequencer I mean if you want to scale you you you want to increase uh at least one order of magnitude in the sequencer. And of course we also want to start working in the decentralized uh sequencer. This a little bit uh near future for this KVM but still a lot of work to do and and of course we want to finish so the the we have some pre-ompiled smart contracts that are not implemented yet like pings and chat 56 and Blake mainly and we will add that those uh in the next version of the roll up in few months probably. So this is a little bit the shortterm road map for the ZKBM uh for the ZKBM project.

So guys if there is no questions thank you very much and uh let's give a try to the test net. [Music]