zkEVM next steps

Transcript

[Music] Hello everybody. Um, I'm Jordi Mina. I'm the technical lead at Polygon CKVM. And today I want to talk very much about Polygon 2.0. mainly what's the the plans for polygon for the upcoming month and I think it's very interesting because mainly what we are doing is uh scaling Ethereum uh going in the path in uh to scale Ethereum

so what's polygon 2.0 uh I like to think about polygon 2.0 zero as a constellation of rollups. So we have right now one rollup is the polygon ckm but here in this constellation of rollups we expect uh other other chains to be here. Here for example is going to be other public other public networks like maiden that we are constructing there. We are going to but at least we are going to propose to to to port or to to move uh polygon poss to a polygon so to a to a rollup. So the people that's building in Polygon POS will have not only the POS but we'll also have the security of Ethereum on top of that and it's going to be also some private

chains or semi-public chains. So any kind of chain no matter what's the but the properties they have and this will bring a constellation uh a constellation of uh a constellation of rollups. Okay. So um why constellation? Well, the b the main topic at the end here is to have many chains but that they interperate one each other that there is composibility between between one each other. So that you can communicate transfer information but not only transfer information also transfer value between one chain and the other and this should be so fast. We are thinking here that this composibility should be in the order of u seconds maybe one minute in the one

minute uh of very few seconds uh this compos this uh this composability and all this is because the zk technology and more explicitly I mean we are talking about the revolution of the zk but more explicitly there is one breakthrough that's actually what enables all this and is the the the recursion the well right now with stars is really easy to do recursion that means that it's easy to u pack to proofs in a single proof so you can build this kind of merkel so it's it's not mer trees but will be trees of proofs so with a single proof actually you are proving many proofs and this is the idea so it's going to be a single proof that

will proof all the all the chains so it will aggregate all the proofs of all the chains and this proof will act as a as a clock and every time that a proof is set there you know that the state of each chain is is valid is correct and you can do a transfer uh of information and and and and and value in between in between that. Okay. So this composibility is is uh is is is really important and important is uh so this um is what gives mainly the security. So all the chains will have the same proof because

this is what guarantees that uh the states evolves in the right way and there is no single chain that's cheating even if it's a private chain because at the end this is proven by this um this zero this um this this validity proof uh no trans so no wrong transactions no nothing nothing can be cheated everything is secured by the by the zk and by the circuit that's proving the zk That's mainly the rules the rules of Ethereum that are running in each in each in each chain.

One of the biggest concerns about the L2 is the the the the liquidity the the the the diversity like the sparse liquidity that the liquidity gets in many chains and this reduce the value of the whole ecosystem and this has been a concern uh for the community in the last uh in in the last years I would say with this system the idea is that we solve somehow that because it's going to be a single bridge. If you want a single place where all the value is going to is is going to be it's going to be a shared liquidity between all of them. So that when you are transferring from uh um when you are transferring from one chain to the other

the only thing that you are doing is just um updating the database updating where each of these phones is at the at this point. Okay. So this solves um the the shared liquidity uh this solves the the problem of the liquidity in in layer 2 in this in in in this uh constellation and this again this is possible because the zero knowledge because the proof the zigate proof that warranties that uh in the bridge I mean uh only the coin can be only in one chain or in the other.

Okay. And you cannot do like double spending and the the chains cannot cannot cheat. As I mentioned before, we are aggregating proofs. Okay. And uh you can imagine that's going to be different provers for each of the chains and at the end this uh proofs uh needs to be aggregated and then committed to the L1. All this process of decentralizing the chain is going to be run in a specific consensus layer. uh and uh it's going to be coordinated in this consensus layer between different actors between different provers. So anybody that wants to build a proof or want to collaborate to build this proof will be able uh to collaborate in this um in this uh

aggregation on this coordination chain uh for the proof. Okay. The other point that's um important here is that um it can be a diversity of uh rollups as I mentioned can be public or private but they can also have different consensus. Maybe there are some private chains that make sense that there is a centralized sequencer some public chains that are going to be decentralized with a fully decentralized sequencer. Some of some of the chains will um some of the chains will have u will will have data availability on L1. Some of them will become like valids validiums that will be that that's going to be just in the in the in so that the data is not going

to be in in in L1. So echane will be kind of autonomous but they will be they will guarantee the security because they will be ABMs and they will guarantee that the that what they are executing is is is valid um and correct. I like to here to put an example of the to see the powerful of of of this and and imagine a private chain that's kind of even can be even private where there are some internal transactions but at some point wants to interact uh with some public chain maybe by sending some funds or by doing some exchange to some some exchanges to some um um to some decks or um I mean just two private chains that they are coordinating and they are

sending information uh through through these rollups or public to private I mean this this all the all the possibilities between public and private chains that with this shared with this shared systems and with this composibility in 30 seconds I think this is uh an important step to for for for scaling and for for scaling for scaling Ethereum so and all this is uh the idea is that internally and this is a little bit more internal but the idea is that we are building a single um a single stack we call it a single zk stack where it's going to be a of course going to run on top of polygon but it's going to it's going to be a a single prover uh a single prover with a single let's say

EBM um system that gives the security with a single client a single bridge so that they have a single full stack where everything is is is is coordinated and so everything is is is integrated yeah so this is a little bit the summary of the polygon uh 2.0 zero this is what we are going to build uh I mean a lot of news will happen in the upcoming month because we're working really hard on that but right now I would like to give a give update of the current state of the I mean what of the polygon CKVM you know right now as you know uh polygon CKVM is the I mean this the only EVM uh EBM um equivalent uh rollup that's running right now in in in mainet we

launched that on uh on on March. Uh we are on boarding a lot of applications. We don't care very much about the about the drops DVLs. We care about developers that the applications that that they have a low friction between them so that the the developers should feel that they are developing uh they are deploying the things like in Ethereum. The only thing that they should be cheaper and faster but uh they should not notice any difference. They should not use any specific u tooling any no specific compilers no specific debuggers no specific um tool to tools uh for that we are scaling Ethereum you

should you should deploy as if you as as if you are part of uh of Ethereum okay and this is we're working really hard in the team in fine-tuning things finding edge cases and putting everything together and I think that we are getting to a point uh to a point of stability that were I would say that the the the applications quite comfortable in in in deploying them so that they don't see any difference and uh uh in deploying in one chain or the other so what are the next uh things well there is one thing that's uh we are working really hard and we have been working I mean we have been working really hard in improving the performance of the prover but we're also right now working very much uh in

working the performance of uh the remaining pieces I would say is the client the sequencer the database because at the end of the day if you want to scale it's not enough with uh scaling the prover you need to scale uh all the pieces if you want to execute thousands of transactions per second you need a database that supports thousands of transactions per second you need a uh RPCs that support thousands of transactions per second you need uh I mean you need to synchronize uh fast enough to support all these transactions so working in all these pieces is uh is is really important and we are this is one of the core uh uh one of the most important pieces that we are focused on.

The next one is we're also improving the provers uh the prover as I as I told you we want to generate these proofs really fast right now uh improving uh proving a u 10 million gas uh batch uh it takes about a minute in a big computer. Okay, this is good. I think this is for a for ABM for a single for a single uh zkm is good but we want to improve also that uh very much and for that one of the things is we are working with uh batcups this is variable degree uh composite proofs the idea here is that what we have is that right now what we have is a kind of a monolithic proof it's a proof is uh uh

in a single proof we can do many things we have many resources for example in the single proof we can do like something like two 2,500 kax We can do arithmetic operations. We can do binary operations. We have certain amount of RAM. Uh I mean we we have different uh resources and this is fixed and this is limited. Okay. So we cannot in this proof we cannot uh put more than that but if we put put less than that we are uh wasting part of this proof. So the idea is we we have a new mechanism where uh using this idea of recursion where we can instead of having like a big monolyic pro proof we can have like super proof that they are computed in

parallel and we can scale a lot. Uh that means for example if we are not using uh a lot of arithmetic um operations we can have a smaller proof so we can go faster but not only not only that um if um for example we have a lot of binary uh operations what we can do is we can aggregate we can have many proof of binary applications we can aggregate all of them and we can aggregate as many as you as we want and then um composite this proof uh in a single proof that have everything together. So this give us a lot of this give us a lot of um um this give us a lot of u performance um uh and uh we believe that this we we can

speed up I don't know 3x 4x 5x uh the speed of generating proof and the capacity that this proof uh will contain. Okay. So this is one one topic of research well topic of actually working hard for for that. Uh the other thing that uh we are working is in the P2 actually as you know we were using a language for writing all the imitization in in for writing the imitization for the CKVM. This has been given us a very very very good results. this idea of allowing us to um separate the different layers, the immization layer, the the the ROM layer, the cryptographic layer in different teams, I mean different pieces with different teams is what

allow us to go fast in the in the going to market uh uh uh idea and but this also for example for auditing has been very very useful because for example we were able to have different teams with different skills to out different pieces of the of the of the system. Okay. And one of the pieces is the the arithmetization. We need to uh I mean we are tagging I mean we we are we are working really hard on this new language because first because we need it for the bat cops. We need the language to to to use in the batcops but we are using also this update to do many other things like uh programming for example putting the constants uh putting the all the constants in the same language. right

now were different uh scripts that I mean they were separated files so we can put them together in the same file and also uh it's another important thing is that this this is going to be a language that's going to be more programmatic I mean we can we can for example have four whiles so uh instead of having right now for example what we have is we have like separated scripts that generate spill okay so they instead of having these things we can do the same thing in in pill so this will will allow us to to to to to uh to just have the single pill for the definition of the of the of the of the verifier. Okay. Um well, a lot of advantages and you will hear a lot about this in in in the in the next in the

next in the next weeks. Okay. What else? This is from the functionality perspective what we are working really hard right now is data compression. As you know the the biggest limitation on the well the biggest limitation right now in the rollup apps is not the prover I mean the prover is scales as much as you want. I mean if you have more load in the network you just spin up more proverbs. If you if the if the if the load of the network lows you just stop provers and you can scale as much as you can. Uh the the biggest problem or the biggest part of the price of an L2 transactions goes to the to the to the data availability. So in order to improve the data the data availability

there is like two things okay one is the one that's working the three foundation very much is the EIP4844 and uh thank sharding and all this this will for EIP 4844 for example will increase about 10x the capacity of the data availability in L1. So this is uh good news and this will happen really soon. We are working really hard uh to implement and well to use this this CIP. But the other thing is that a compression. I mean if you can put a transaction that takes uh 100 bytes and you can put it in uh 10 bytes then you get a a winning of of uh of 5x or 10x.

So how um how you compress a transaction? While compression you can understand I mean as as a set of as a set of as a set of comments uh where you can uh I mean you for example you have one command that's just put this information as a route transaction but you can have different compression one thing for example that you can do is compress the value instead of using um I mean 16 digits of the value maybe you can use a kind of a floating point kind so we have a mantisa an exponent and this for example you can compress this thing. So you can have a command that says okay compress this value but the important part of the transactions so what are the parts that are that gives

you more uh compre that that that are more difficult to compress. Well the first thing is uh signatures I mean the signatures is not necessary uh to in to include the signatures in the data availability. Instead what we can do is include a proof that if you have 100 transactions you can include a proof that these signatures exist. Okay. So and this um this can be compressed a lot. So uh if you have 100 transactions you can maybe you have something I mean you can get a compression. So this this data availability so this the data availability of the of the signatures can be reduced to a constant size per batch and this is really really low and this is one of the things that can

compress a lot. The other thing that's difficult is to compress is the addresses. I mean one address is is have a very uh high entropy in general. It's kind of it's a random number comes from a hash. Okay. So probably the first time that you are using uh an address you will have to uh publish the full address. But the idea here is that uh you you have a state a state of the of the transactions and the addresses that you have used before. So in the data compression instead of uh referring to um a given address you can refer to an index to some sort of database uh of the address that you have been using on.

Okay. So and when you put all together uh this is uh this is our very conservative uh numbers uh we can you can get a 5x um you can get a 5x uh compression actually in the last uh I mean the last results this is more a six 7x the 5x but 5x is a an optim I mean it's a conservative a conservative measure here this is depends very much on the kind of transactions and so on what means that that when you are that when you are putting on top when you joining this data avail this uh this data compression together with EIP4844 we can get easily a 50x um uh scalability and this will happen in the

in the upcoming month the days that when the 4844 uh we should be able to process 50x uh what we have right now that's already two three ethereums more or less what we have at this point so this is the plans this is what we are working hard and yeah, thank you very much. And I'm here open for questions. Have plenty of time. Any question?

Uh you mentioned in your talk that uh Polygon POS was going to become a rollup. Is that uh because they announced it was a valid? Is that an officially new position or is that we announce validium but I can tell you that uh the idea is that when D sharding is ready we will put the data on chain and this is what I would love to happen okay great thanks thank you for oh hello thank you for your talk Jordi um I'm just wondering like you spent a lot of time thinking about how to scale you must have some dreams or kind of ambitions for like what's the coolest use case that you're

thinking of like would you mind sharing the use cases for scaling? Well, the use cases for all of what you do. I mean I think that all the all the I think what I'm thinking this is very much the the way I'm thinking is all the all the even all the transactions all everything that the humans do they hold some sort of value. uh even when we talk one each other on when uh of course there are some of these transactions that holds higher value some of these transactions that holds lower value okay so for me it's uh that this value is uh committed is used in the blockchains this gives a lot of fairness a lot of transparency and and and this helps a

lot but it's not only about only about humans here is there is a full topic for example where can grow is the the transactions between bots or between uh I mean intelligent b robots or the you know the the the the uh internet of things can I mean the the things can interact with each other so it is a lot of a lot of uh uh uh interactions a lot of operations of of course at the end it's a matter of uh uh what's the it's a offer it's an economic thing it's a uh what's the price what's the offer and measure this long tale of transactions that can happen is probably difficult to measure but what's clear is that the there is a there is a lot of

demand and I believe this is very much like when internet I mean when at the beginning of internet is what's the limit of the bandwidth that the routters have I mean you just can grow the bandwidth and it will be filleted uh uh somehow this is the the way I'm thinking and uh probably here we are thinking in transactions that are more money related with the money I mean defy and these This is probably because they they are first you see the value clearly that there you can measure very easily but there is a lot of other transactions. I mean for example uh voting systems on the governance for governance systems for decision taking for I mean for for for scroll or even for communications uh

I mean when you are when you say something in Twitter it would be good you to prove for example that you you said something like that. So there is a bunch of uh applications a lot of transactions that if uh you have this um u you manage this um um common good I mean where you can make these transactions in a very cheap uh manner. There is plenty of uh space and plenty of uh applications that can run on on that. We need this to be uh I mean the low cost, low cost and of course uh secure scale. I mean all the all what we are building right now uh technology is

not ready yet and we are we are growing and we are we are uh improving uh this technology to reach these stages and this is somehow where where we are going to. Hi can you hear me? Yeah perfect. Uh quick question. You mentioned that the proving time is currently around 1 minute. Where do you think the proving time could potentially be in two years, three years, five years? I think I can more than four five years. I think that the proving time with this just with these bad cops in the I mean in the few months I think we can be um in the the order of seconds. Uh thinking about 20 30 seconds is

definitively valid. The other thing is that with this bad cop with these bad uh bad cops right now um right now we're doing 10 million gas uh we could do it 1 million gas and and that would be great for most of the applications. Why we are doing 10 million gas? Because we are not uh because we are processing uh because we are process so we want to fit at least one transaction inside. We don't want to split. There is some techniques to split the transaction like in different batches and you you can do the things but if you thinking in a batch you want to have at least the minimum batch so that you can fit a transaction and 10 million gas is I mean doing a transaction of more than 10 million gas is is I would say it's not practical uh

in general. So that's what the million gas but uh with these bad cops it's perfectly possible to do uh batches of uh maybe 1 million gas or uh uh 500k gas. So and then these transactions can be generated much faster. I mean you maybe you can generate a proof with I mean I mean maybe with five 10 seconds uh uh on that and maybe there are u uh rollups that uh uh wants this kind of uh finality. Okay. So this is perfectly possible. Another thing is for example the the aggregation you know when you have different proof and you want to aggregate more or less aggregating two proofs um after I mean after genetic it's more or less about 1 second the order is 1 second. So this gives you the

the order of magnitude of we have right now it's a lot of development that's uh happening. I mean there are new cryptographic systems that are are being investigating. I know for example Ethereum foundation is is investigating a lot all these nova with uh aggregation syncs. We need to see if this is better or not if it works or not but it's uh it could be really revolutionary. Another thing is the hardware hardware acceleration is um here we have a little bit disappointment in working in hardware acceleration because we see that the CPUs are really fast and also here the kind of proving system we are using is a little bit memory intensive and for hardware acceleration is not doesn't work well but there are other proving systems and there are other

innovations and I don't have a crystal ball but is this is uh this is going really really fast and thinking in proofs in few seconds is perfectly uh I would I would bet that this will happen and not even five years I would say even less. Yep. So thank you very much. This is all any any question you you you can reach me. [Music]