Next steps on the Polygon zkEVM / Jordi Baylina

Transcript

foreign [Music] polygon ckvm as you know we have been developing for the last year and a half I would say even two years from now on uh zkbm for me as a kbm is well it's a cable app type 2 where it works exactly the same that ethereum.cbm is ethereum virtual machine that means that you should be able to take any smart contract the way it is

and just throw it to the network and it should work aside forward you should not need any special tooling you don't shouldn't need any special compiler you should not need any special wallet or anything like that it's another ethereum like Network and this is what's a ckvm that's this compatibility is what makes uh the thing so cool that we can produce all the ecosystem all the tooling and all the all the developments that are happening in the ethereum space we launch at three weeks ago network is up and running and is the first of the kind uh the first of a kind in the in the space so what I'm gonna explain in this

presentation is mainly what are the next steps so what is going to be doing the the ckvm team inside polygon uh to for improving and doing the KVM actually to to scale and to make it better okay so let's start for some of things the first thing is that we want to be a type 2 roll up right now we are a type 3 roll up that means that we are ethereum equivalent uh on anything except that right now we need to implement uh some pre-compiled smart contracts that are not available right now these are the shadow 56 this is probably the most

urgent then it's Blake and paintings we are already working on that but that's uh the thing that we want to the main differences between ethereum but you know ethereum and uh zkbm okay then we want to remove that ZK Contours more on that a little bit later okay second thing is you want to improve the want to improve the the proverb okay so right now if we see the structure of the proverb that we have right now is a big proof where it has different state machines we have the main processor uh problem

pointer anyway so you have a processor we have a and some binary binary arithmetics application some auxiliary State machines with where you do most of the um heavy uh operations okay the problem that has what this is working well we know the proof right now takes about two minutes in a big CPU machine to compute about 10 million gas okay but the problem so if you want to improve that the big problem is that depending on the so the quantity of catch X that for example we can do in a proof is is a fixed number okay or the number of arithmetic operations is a fixed number so the idea is that we need

in when we actually when we are processing some transactions we need to count how many of these resources we call these zigga counters we are using so that if we are getting out of the limits we can stop the Proverbs say okay there is no space for the provers and then we just do an operation State transition so we can prove that in our system we can prove that transaction cannot be proven so that this allows us for example to have forced transactions in the system okay but this limit having this limitation something what happens is that you are not using a lot of the times you are not using other resources so there is a lot of so maybe in the in a batch we have a 2000 catch acts and

maybe you just use 1000 but you still have polynomials for two thousand so here there is a lot of um waste in resources so idea is instead of having a big monolithic proof that is to create using precaution that has to have a proof with many soup proofs so that is to create a proof for the main processor maybe a proof for the binary and a proper arithmetic and this proof of the binary the idea is that you can choose so you can you have like three different circuits one binary that's a small another it's a little bit bigger and another is a little bit bigger and then the poorer the recursion proof the one

that packs them all together uh can decide which circuits you want to use so this with this we can fine-tune very much how much thank you very much so depending on the transactions that you are processing you will use one circuit or or the other so we will waste less resources according to that the other thing so this is good for you know for when you have less resources but the other thing that's interesting is that if you if there are some transactions that requires for example a lot of binary operations the idea is that we can aggregate so we can instead of creating one single proof for binary operations we can have like many

proofs of binary aggregations and we can aggregate all them together okay so this allows us to have an infinite number of resources inside the the proof okay so the advantages of this is there are many the first is that this will allow us to remove if not all most of these uh zika Contours of you and this is the equivalent of the gas somehow is the limit the resources that you are consuming so we don't will not take to we will we don't have to do this accountability of these rigid resources and then this the all the the system is going to be much easier at at the ROM at the ROM level um and the other advantages there is a lot

of advantages is that right now one of the big limitations in the in the system is that uh the proverb requires a lot of memory requires right now we are using uh five terabyte of memory server with five terabyte which is a big server on there because the proof is too big because we are splitting if we are splitting the proof in in a smaller proof the memory requirements are going to be uh much smaller and this will reduce also the the cost of the of generating the proof the other thing is that because the proofs are going to be smallers then it would make sense to compute the full proof inside the GPU okay and this will also accelerate a lot the generation of the proof so this this model

this model of a variable degree composite proofs allows us to be more flexible and uh to improve the the the timings and the the the latency so how much long it takes to generate a proof especially when we go to the GPU okay next thing is in order to support these things we need to expand the people language the appeal is the language for that we use to build all the arithmetization of the the kbm so here we have some plans to extend the extend the appeal language I'm gonna give you some highlights of the things the first thing is to support

this variable degree whatever degree composite proofs so uh while we adapt the the the the the language so that teachers take machine we decide we we just say which is a so proof and initial proof we can we can specify different different sizes and then we can say that so that this superproof can be aggregatable uh on that so we can build pill and then the proving system should support automatically to generate the proof or the the composition of proof automatically from the from the P language okay so that's important next thing is the constructive language right now the writing pill uh the peel

is very linear language you just uh you need to put all the identities one after the other okay and what happens is in some complex State machines for example that in medical State machines we end up like doing a secondary program that's writing pill it's like a kind of a script JavaScript script that generates spill so it's just uh so and then this is hard to to audit because you need this secondary program and and that's the one that generated build so the idea is to integrate instead of having a separate script that has to integrate that in pill so we have a programmatic so we you will be able uh to Define constraints in in a loop or in with conditions so this will allows us to to

do more complex uh pills General one of the learnings is that uh when you are working with a starex um it's much it's more optimal if you go to wider to wider so to many many polynomials so wider we call wider proofs and and and uh shorter degree so a small polynomials many polynomials the smaller polynomials uh in general you get better performance mainly because you have much less copy constraints uh in general okay but when you hold when you work with many polynomials that means that the number of constraints um are gets more complex and then it's more necessary this this programmatic

way of writing uh these these circuits okay another thing is the well conditional constraints a lot of this is more for a reliability thing but sometimes there is a lot of constraints that only applies to certain lines okay so that they used to use this this structure which is much more readable than the one that's in the in the old way um we also allow to Define challenges so if you see if if you if you check how the proof Islam uh mainly it's many steps so you commit to some polynomials you send a challenge then you commit to other

polynomials you send a challenge Mark and and there are different stages okay uh right now in pill uh the idea is that you just Define the first stage and the others are automatic when you are using block apps or when you are using permutation checks so you have access in the pill only to the first stage here we are extending pills so that you can Define your own challenges and you can Define uh polynomials in different stages so this allows us this will allow to generate other other uh other schemas for uh proving different things things like equivalent like block ups but different schemas that uh they would not need to be required to be implemented until in this case for

example this is an example how uh there's an example how a lookup will be implemented using this actually in Korean pill you don't need that because you just use the in directive and it's much shorter but if you want to implement a different schema then it should be this should be possible okay um oh this is not constant here is the constant constant Generations uh right now when you are writing a polynomial language a polynomial uh schema actually you need to do like three things one is generating the constants the computer polynomials generating the pill which is the constraints and then it's generating actually is generating the the witness

or Computing the the trace when you are Computing the proof so you need a program to compute the trace um the idea is to put this this step of generating constants inside peel so instead of having a separate uh program uh you can put it inside PL this has a couple of advantages the first is it's much more readable and when you when you want to audit some of the circuit you just need to go to pill and that's it but the second thing is that a lot of the constraints are cyclic and when you have cyclics when you detect cyclics then you can do some tricks to improve the performance of the approvers so having in the definition language makes all makes a lot of sense okay also in pill right now you can

access only to the current Row one to the next row to do the references because mean what you're doing is just a steady machine but here we will allow to access to maybe many rows uh in front and many rows uh uh before okay so you can have access and this is much more flexible and much more readable and that of course if you are accessing too many values you will need to do more openings for for each polynomial but this is very convenient in in some cases okay and finally uh we also have a special notation for rain checks uh actually we are doing rain checks with a normal uh blue cap but if you if you can Define that in the in the circuit and

you know that's a rain check there are other constructions you can use other constructions that are more efficient and a lot of the lookups that we're using are for just rain checks so we can optimize also a lot here in the in the rain checks okay so this is very much one of the line of works is this uh pill the other important work in the ckvm context is about compression okay so right now uh the Roll Up is just sending the transactions in Rao in the in the in the blockchain but the days to compress this data that availability is going to be one of the bottlenecks uh in the list in the short run so that there is to instead of putting the transaction is pushing a compressed version of the transaction okay this is perfectly

possible the thing is defining what's the best compression okay for compression well in general if you see how compression Works in general a compressed file is just a set of commands and parameters and this each command is just writing part of the file good example for example of these comments is for example right if you want to write just some uncompressed data you just okay just print this or just open this and put this this in the file you can for example do a write just reuse part that just go back in some something that you write before and just write this again many many times okay but you can when you want to compress transactions you can do some special compression for example give you an

example is for example for the values the values uh in general values are typed by humans and humans the significant digits used to be quite small in general so you are sending one meter or three ethers you are not sending 1.54567348 ethers okay so you can compress you can use techniques to compress decimal values uh very well and this will allow us to reduce a lot okay but okay this is but what else can you compress the big important part is that in a roll-up you can remove the signatures of the data compression the idea is to substitute that is to substitute the signators by a proof

that so you are proving that you have or the person that generates a proof have the signatures that thinks that so you can replace all the signatures with a single proof that Aggregates all the signal tools that you are validating this proof is can be it's if it's a plonk is less than one kilobyte okay and a signatory is 64 bytes so if you have like 16 signators it's more worthy to more than 16 signatures is more worthy to just put this put this proof instead of a single a single signature okay and but if you see how a transaction is on but there is one thing

that's more interesting and the idea is that for compression if you want to compress the information one thing that you can do is use and here you can use the state so you can use the current state to access the state to do some compression but you can also have a system to access all the other all transactions for example if you want if you are saying in an address and a film address is very difficult to compress by itself because it's just some 20 bytes and they are quite random okay but if you can do a reference you say Okay use the address that's in so use these data that was in uh in this transaction that was three blocks ago

and in uh in the transaction number 10 and it's in the position whatever this can compress this can be compressed as that compression very much and you can have access and this the the access to the all the transactions to the raw data of the previous transactions of the history of the Roll Up This has Advantage not only for accessing addresses which are very much compressed they have also the access for example if you are accessing to the hash values of nfts or you are redeploying smart contracts that have very similar parts that you want to recycle or you are accessing some miracle tree where the hashes are are the same so you are reusing you are

using many users are using the same Mercury this is for example for the claim system so this allows us to this allows us to to uh compress the data very much we did some estimations we expect that we can have a compression ratio of 5x this is a little bit pessimistic but so I think we can do it a little bit better but this is the numbers that we are targeting okay and if we add that if if we add that to the eip4844 that will give us a 10x in the costs in the cost that means that

it would we expect that by the end of the year we can be a 50x scalability factor by the end of the year when you compose the both Links of course working in this eip4844 is a priority uh um we have a special people that's dedicated to to that from now on and this is very important for for for for scaling for your information this is the Prototype charting but then charting so when sharding happens we expect that at least it's going to be an extra zero here in that availability okay so this is a little bit the roadmap for for this okay of course having this when you are

scaling is not only about generating the proof it's also you need uh to process these transactions and you need to have all that uh all the tooling around so the the sequencer the synchronizer the database so all the system itself needs to scale so here is a lot of work also in improving the the the pieces to process uh that I expect that the biggest bottleneck after that availability is more or less solved with uh bank sharding is going to be the the well this um this um you know the transactions in ethereum are quite sequential that depends one in the other okay so having

a way to parallelize these transactions there are some ideas and there is some people that's working in that direction but this is probably going to be the next bottleneck after that availability happen okay uh one thing that actually we are working but we are not working and one of the cool things of uh zkbm uh something that's of code compatible and things is that you have things for free I mean we have the EAP so we have that uh that uh we have a account abstraction for free you know account obstruction does not require anything in L2 so you can take all the construction smart contracts deploy it in the ckbm the same you don't even need to recompile them

you just throw them and you have this uh counter-structions uh for free okay this is so this is one well this is a ckvm it's it's it's ethereum okay so if ethereum is improving the ckvm is going to be improving is the ethereum ecosystem works well we're just gonna get uh the benefits we will we will have the benefits of the ethereum itself and we will keep the full compatibility just a couple of notes for these uh EIP there are some optimizations knowing that this is happening there is a couple of optimizations that you need to take in account it's like one is that the the sequencer if it's a centralized sequencer it becomes it becomes very

much as uh the the the the sequencer becomes very much like a minor okay so you need to have some API for the CIP that you need to to implement but we will Implement and the other thing is also in the it comes in the more in the for the for the compression okay if you want to remove the signatures of uh of an account abstraction you need to take in account that in the design protocol so we are taking accounts that we can also remove the signatures from the account obstruction uh um user operation for transactions that are happening here but besides that I mean this is just optimizations and everything should be in place on that

there is a full topic this is something well we are start working on that is the decentralizing the sequencer just giving you some ideas here is to you can understand the sequencer as a consensus so you can't replace a sequencer as a with a consensus uh layer right now A centralized sequencer is is a kind of a dictatorship uh consensus it's whatever the sequencer is is the consensus okay so it's a consensus there but you can replace this with an another consensus layer there is a temporary consensus because a sequencer only makes sense um until the transactions are in the layer one but

during this time the H2 change the consensus parameters in the in the three dilemma so that there is that in general you want a consensus that have a high finality with maybe sacrificing sacrificing a little bit of the central rotation and security uh somehow and this is the the ideas to adjust and having some consensus in there so not in our team but in polygon there is other teams that are working in that direction and this is important also to to to mention okay uh of course there is a topic of security security is uh it's uh itself I mean it's the main topic uh it's a priority in polygons so we are still doing Outreach it's uh back bounties reality things uh everything the new

code and this is something important that we we are strongly committed to this so it's a Non-Stop uh work okay and last thing that I want to mention is that we are thinking also in start um increasing the trailing Wheels like there is going to train Wheels very going to trailing Wheels very soon uh training wheels the type 2 according to vitalik favorites very tattoo very soon that means in this stage what it means that what it will means is that uh if the if the system works okay we uh so the central lights so nobody will be able to lock or of course uh steal the funds okay so the system is going to be

decentralized if everything works well if uh invalid proof is detected or in some situations but needs to be proved in the smart contract then the system may become May Halt and then that can be upgradable okay for this we need to enable Force transactions we hope to do that very soon we need to remove the security well this is the enforcement sessions are already programmed it's just a matter of hitting a button but we want to everyone in two three weeks I hope we can remove that and then we have about remove the security Council uh that's removing the skill switch that's another thing and the last thing is increasing from 10 days to 30 days they upgrade uh the upgrade uh time lock

this is a little bit the planning for this for the end of the year uh we are very well we are very optimistic as always this is not a commitment when you are doing these deployments you can find things but uh more or less I think that this is where the timing is good I think it's good to give times and to for the people to know what's uh internal timings that we are working on so that's very much uh thank you very much for listening [Applause] [Music]