Polygon zkEVM mainnet with Jordi Baylina
Ethereum Denver·Mon, Oct 9, 2023, 12:00 AM
Speaker
Join Jordi Baylina, a highly regarded contributor within the Ethereum community as he discusses the functionality of the zkEVM, the security compromises, the performance and the learnings on the audits. At the time of this talk, Jordi is working on the implementation of the first complete zkEVM proving system. Presenter: Jordi Baylina Technical Lead, Polygon zkEVM https://twitter.com/jbaylina
Transcript
hello everybody I'm Jordan violina I'm the technical League at polygon ckbm so as many of you now ZK ABM is the next chapter of ethereum is scaling and why was the kbm a big challenge well in order to understand that let me explain you a little bit how 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 mainnet you will do it in the in the in the roll up in the CK ABM okay so the first stage that you will do is you will send this transaction to a sequencer in this case at the beginning it's going to be a centralized sequencer like many of the like most of the roll ups right now this and uh decentralized sequencer it will give you already a trusted State this state is final as far as you trust the centralized sequencer okay so this is the first stage the second stage is that once in a while maybe uh I don't know one minute two minutes or three minutes uh the sequencer will send these transactions to layer one okay here is where the data availability will send once this transactions are in layer one another sequence then you will have uh like what we call it a trusted State it's a state that anybody can compute because you you have the transactions on chain so you can if these transactions are processed in a deterministic way you know exactly what's the current state of the network and so they are final they cannot they are saved on chain they are final but this is a state we call that's an implicit State it's a virtual State it's a state that anybody can compute but uh is not Unchained okay and in the last step maybe once every half an hour or something like that it's gonna be another transaction that will take all the all these transactions that are on chain and will generate the 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 the the big trick here for the ckvms is this proverb okay this Brewer actually what it needs to do it needs to create a a validity proof for 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 fonts can be deploy a smart contract can be execute something on the smart contract can be anything and they have exactly the same format the RRP okay so building a circuit here is the biggest challenge part in the case of the polygons in KVM 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 polynomials and the polynomial 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 polynomials we built a processor a ZK processor okay but actually it's a state machine it's a processor it's something that they can take subprogram execute this program and and have a specific state okay and we use and we created the uh also 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 with the assembly and we built the program on top of this processor that uh and that emulates ethereum that actually this program is taking transactions as an input it's and it processes the transactions following exactly the same rules as ethereum okay and in order to do well we had a lot of challenge to solve because this processor then needs to do 256 bits operations it needs to do the easy recover no uh well a signature verifications uh you need to do catch acts 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 once we finish that three 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 review a huge shouty thing and I could include a huge process for that okay so for the last three months mainly what we have been running is running a lot of Outreach we run two external Audits and one internal Audi more than 24 uh so more than um uh more than 26 individuals were working uh in in specific pieces of all the code we run also on internal audit we won't really deep on that and uh we found many things when we if 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 auditor this code the truth is that auditing this was relative okay I'm continuing here don't do not leave yet so yeah so this is the this has been running these teams has been running for for for for for many things we found many things we had to learn how we had to learn how to do these Outreach we created a full process for doing this Outreach out to actually this 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 this Auditors you can just to see the magnitude of this I mean this is all the different pieces that the zkvm has the pill is this like this Hardware language where is this processor is defined we have a storage which is like another processor explicitly for working with uh the sparse Mercury 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 it we have the smart contracts of course we have Smart contracts as a roll up that needs to be audited and check it too and we have all the cryptography side here we are using very much the starex and flunk in the last stage so and all this process needs to be audited and check it that's the right way besides that uh once we finish this outage 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 that are interested in zkbms uh just to invite you to to to to to take a look to review there are some incentives to do that we have a lot of material and documentation uh to learn that so if you are interested on that we'll run this back Bounty program on that okay but and then with all these the question is are we ready to launch the main net 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 ckvm 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 wrong inform different things okay one thing is something is wrong in the smart contracts and the last three things if something goes wrongs in the program okay um if we focus in the smart contracts this is like I mean this is a known technology so we run two hours 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 Outreach 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 Brewer that you send a transaction and the result of this of the transaction is actually that uh you're still fun so 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 up 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're we're getting all the uh we are so we are we have all the uh that at the test Suite from ethereum we are taking all the all the relevant other 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 gonna be okay again uh um not 100 uh sure okay but this um you know this uh tests and these Outreach give us enough confidence uh to launch mainnet okay uh the last two things is one is soundness soundness is is more tricky is I would say that this is much easier is when you can as soon as in approvert means that with the same state and with the same transactions you can compute two different states okay this would be a soleness this would be a typical example of summoner's program okay in this case uh we are putting 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 process that can process that actually this is so this is not really true we are going to be the the only Brewer as far as we are building proofs if we accumulate a delay of more than five days then anybody will be able to run the proverb okay but because we are the the main Brewer uh we will not prove something wrong okay so this soundness programs are dishonest bugs are mitigated as far as you trust this as far as you trust us so as far as you trust the the proverb 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 uh when we're starting this uh we have the warranty the users have the warranty that the the broker is Gonna Act correctly and even after we remove as a trusted proverb the smart contract also contains a kind of a mechanism that is if you proof 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 something wrong and we have to do update okay and the last thing that can go wrong is a little bit more specific for the program 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 will happen here is that the roll up would just stop but you cannotch and create proof so the lab 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 the to update the system okay these are the trailing bills some of them I already explained it okay we have centralized sequencer who have a trust approver we have this soundness back detection by the smart contracts um we have this protection again against this on probable transaction and even on top of that we will add temporary uh at least while we are in beta we will also uh escape hatch gear switch it's going to be a security Council that in at any moment will be able to just push a bottom and hold the system so that we can upgrade this this uh this is going to be running 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'll be in training wheels too okay at the beginning we're going to be training wheels one because this this this last one okay so I would say yes we are ready for mainnet it's a mainnet better 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 I think it's important that the users that's using this network understand uh the risk we won't hear we want to be very transparent we are going to publish all the Outreach all those 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 one billion dollars in the in the network and and then we have 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 mine event so thank you and I'm gonna 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 why flunk yeah the third process behind that selection yeah uh yeah the flunky is I mean so our main blueberry is a stark and it's a set of uh uh um you know um recursive star X on top of that and it's in the last just in the last state that we're verifying a stark with a circuit with a snark here you could choose grow 16 here you could choose uh plonk or you could choose flunk flunk is a new it's a variant of flunk that has the advantage that the verification cost is uh modernized the same that grows 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 grow 16. uh and it's uh the same.plunk it does it doesn't require a true syrup actually but it takes the the it's it requires the universal processora but this is already run but doesn't require a specific process set up so it has the same advantage of long but it's much cheaper to verify the inconvenience 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 now read so the one of the updates that we are filling finishing right now is the flung protocol itself and the implementation of the flank protocol but this is one of the new things that we're adding that I think is interesting uh 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 for moving away from a trust approver to uh 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 or the escape hatch this is the the most centralized part that we have I expect that once maybe I don't know one two months of running uh the system I mean we don't find any big thing we plan to remove on that we will continue doing our reads and you know this back Bounty and we'll see how confident we are but we need to remove that very soon and regarding the trusted proverb idea is to start lowering down this this uh this time so that you will start with five days and then we go four five three to one and actually at at some point we just remove them which we just try to to uh well to let the market just anybody just can generate the proof and start this program 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 program in the shadow and if there is something wrong we can always um generate the right proof and uh how the system so uh even for that I think that this is something that's some mechanisms that we will spin up really soon I don't know if I need to sell you a time I'm thinking about a few months but again we need to just plan and and just before finishing I want also to maybe give you a little bit uh so what's the future after after the launch uh we want to work very much uh with the aip4844 uh roll ups the main limitation of roll ups the bottleneck of Roll-Ups uh R and will be the data availability so though even in the ZK the approver is not the limitation anymore the cost of the of the impact of the proving cost in the transactions is not an issue anymore it's it's really uh cheap on that so we need to focus in the data availability and data compression uh we want to also improve a lot the sequence because the sequencer I mean if you want to scale 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 it's a little bit the near future for this the KVM but still a lot of work to do and and of course we want to finish so the the we have some pre-compiled smart contracts that are not implemented yet like paintings and chateau56 and Blake mainly and we will add that those uh in the next version of the roll up in few months Provo so this is a little bit the short-term roadmap for the zkbm uh for the zigabian project so guys if there is no questions thank you very much and uh let's give a try to the Tesla [Music]
Automatic transcript — names and jargon may be misspelled.