A Glance into the Future of Polygon zkEVM

Transcript

okay well I'm Jordan violina I'm the technical League at polygons ABM that's what it's explaining as you all know we launched at the polygon zkbm in uh one month and a half before um for many of you that are now zkbm mainly is uh layer 2 solution that it works exactly the same way that ethereum that means that you just connect urethra scan sorry your your your metamask to the chain and you can do exactly the same thing that you would do in ethereum like the creating a smart contract deploying

a smart contract using exactly the same tooling the same thing so that's the same that ethereum the only difference is that the price should be much cheaper and the number of transactions that support the evm is matches more so this is um uh for the last okay so this is a little bit what I'm gonna be talking at the beginning I'm going to explain a little bit what the current status of the IBM and then I'm going to talk a little bit about the near future and in the last minute I'm going to explain a little bit the long future at least why visualize the the the space of the Roll-Ups space the layer to roll up space

so let's start [Music] well right now the current status of the network is well so far so good it's working really hard it's working really good we had no uh no stops at all is working I would say uh perfect much better that we expected just for for you to know for example the the only things a lot of applications are have been deploying their application testing the deployment or even checking and producing uh most of the applications

I mean they have no issues they just take the smart contract that the deploy and they tell you okay that's working and that's fine and in general we don't have to talk with them that's the nice thing of the of the evm uh the only thing that probably the only a small thing that we are working is some something in the timestamps time stamps right now uh we are having some issues uh especially in the in the accuracy of the time of sun because we are doing batches to bigs and we are not next week we are going to fix that thing and we expect that some of the defy applications especially the ones that requires oracles that they will be up and running but this problem this small thing probably has been the biggest

issue that we had uh so far okay so everything is working uh okay and what's the question is what's what's going next actually is um we're having like two two years working really hard to put this in production and once we're in production we realized that we just started I mean that everything just starts uh starts now because now is when we really want to to to to to scale okay the first things that uh we want to I would say finish is uh there is a couple there is a couple of pre-compiled smart contracts that are not implemented yet uh these are uh chateau56 and um and uh paintings these

are the only two things that are not implemented to be a type 2 roll up so once we Implement that we'll do a type 2 right now uh this is why we are working really hard on these smart contracts and in the next upgrade this should be this should be fixed another thing is well it's more a small detail is just remove the ZK Contours and more on that more on that later okay well to remove this Contours actually we are changing a little bit the structure of the proof the proof the proof that we have right now is uh we say it as a monolithic proof it's a big proof it's a proof that you need a half terabyte machine

to compute it it has all the pieces in a single in a single in a single proof it's many state machines it's like many soup processors but all of them create a single create a single proof okay so what we want to do that is having using recursion to have a proof that's a composite proof that's uh it's a proof that's composite of many soup proofs so that means that this will allow us to have smaller proofs and what's best what's better is that so in this in this in this monolithic proof all the all the resources are the same

for example Ketch Acts was we have about 2 500 cash checks in the proof If we are using all of them that's okay but if we are using just 50 ketchups we are still paying the full the full proof itself so it's not very efficient on that with this uh with this system uh with with this kind of proof it allows you to have different sizes for example approved for 50 cash checks another for 100 another for 200 another for 400 and so on and then you choose depending on the proof that you choose which uh depending what you want to prove you choose this this different proof on here

okay this will allow us to do a more optimal more optimal things okay another thing that you can do with this is using recursion instead of having for example one binary um State machine you can have three different binary State machines and then aggregate them together so you can keep the sides of the sub proof uh small so all these uh well these are the advantages of you doing this is we don't waste sales in the Stark somehow we don't need to count the resources one of the things that we have right now is that we need to know if so you need to

prove that you cannot prove something so and how you how you do that well what actually is for example when you you before doing a catch up we keep accounting we keep an accounting of okay checks reminds remains uh not used and if we don't have enough cash checks then we just finish the proof but we finish in the right way and we put we said that there is not enough hedgehogs so maybe it is an operation transaction or whatever it is okay but these are forces us to keep an accountability of all the resources itself if we have this kind of proof because they are more extensible you can work with the limits and this allows you to scale as as much more so

all these counters which is a little bit the difference between um the layer one and the layer twos we can read out of these Discounters okay and also the other interesting thing is because these two proofs are smaller by itself this can this would allow to run these proofs for example in GPU on fpgs uh right now the problem is that these proofs they're running us in a CPU with this big machine and this doesn't I mean 500 terabytes 500 gigabytes doesn't fit in a GPU but 10 improves of 64 gigabytes they fit in the GPU so this we believe that with this we

will reduce a lot the cost and accelerate a lot and the proof generation with this new version okay to do that you know for generating this proof for the ckbm we build a language that we call pill as polynomial identity language and this has been very useful for writing order in meditation on the zkvm currently we are working with a new version with an extension of build we call it pill 2 and well here I'm going to do a little a little bit of summary of the of the of these new new things that will allow us to build the npr2 okay well the first thing is that we will support in peel two this uh this uh

but crops this variable degree composite proofs inside the pill the peel right now you put all the identities all the all the constraints it is just one of one line after the other and with this new pill tool it's going to be a more constructive language so you will be able to build all these constraints like in a programmatic in a programmatic in a programmable in a programmable way okay um while this goes okay so you can you can have uh variables you can have loops files for each uh functions and um you know everything related to that

and this will allow us to build much much much more complex circuits in a more programmable or more programmable way okay functions for example to do some components you can have some functions libraries and itself okay here we are one thing that's very typical in the Starks that's the boundary constraints right now we don't have boundary constraints actually we do it manually with a single things but here we we uh we allow us to to build uh about boundary constraints on the system uh the other thing that we are doing now is that we allow to put so to Define we Define these stages right now we have

like one single stage and we have a high level language for example for uh blue Caps or for um for um permutation checks the idea now is that we will be able to Define polynomials at different stages and we will Define also challenges at different stages so this will allow us to build new constructions uh new constructions that for example the the permutation check is not going to be something that's specific from the language you will build a construct a permutation check with your own language or a plug-up or any other fancy or difficult constructions that you can have there so somehow peel is

going to be a lower level language but pill is going to be written in pill so pill somehow okay so we simplify the language improve but we make it more complex we can do more complex things okay another thing is right now or all the fixed columns are all the fixed columns right now are just constant columns okay here we distinguish with repetitive fixed columns and generic columns okay and another thing is that all the constant Generations are we are will be included also in PL so for auditing you will not have to go to a special program that you use to generate the language

okay you have everything here in pill okay another thing is right now uh Imperial you can access only to the current row and to the next row here we add in the language to access to different parts of the row so of course this will require openings in different places but this allows you to be more uh to create more readable or if you want to uh work with a Stark that works with different rows at the same time you have everything in the in the language okay I prefer those for rain checks well actually a rain check is going to be a function for itself so we put it everything here on that okay

and another important thing is okay from the language when you're building a circuit of course you need to build the you need to build mainly two things one is this identities the identity system this the set of constraints but you need to build also the witness generation for building the winning generation you need a lot of information that goes from that goes that talks from peel okay so we have we add here a way to communicate from pill to the witness generation for helpers they're there so they can go together from one side to the other okay some building functions lookups are at the end are going to be functions permutation checks are going to be

functions so proof permutation checks oh yeah because we have this multiple variable degree different variable degrees to proof we have a full system to communicate between the between the uh the different state machines okay matching and so on okay okay this is mainly I mean this isn't important because I think that this is going to generate a be a good way to generate uh approving systems uh with uh with polynomial based systems okay one of the topics that we are working very much right now is data compression right now as you know the one of the biggest limitations is that availability so we work very much with the

compression and data compression just to go a little bit fast here is uh well when you have data you you if you see how the data is compressed and generally you see the data and it's a common with parameters okay for example in one common can be put just raw data don't compress anything or write something reuse some part of the data or for example if you have a value that have a lot of zeros you can have some standard techniques for compression but this is not the most important thing the most important thing is well there is one thing that for example is easy to compress well it's relatively easy to compress one thing is for example removing the signatures and the idea here is substitute a set of signatures that will be in a blob with uh proof

that you hold these signatures okay and the cool thing here is that you don't even need to prove that on chain you can put this proof uh with the same blob and then recursively check this signature there so we can remove the all the signatures in there so there's a huge win in the compression the other part that's important is for example the addresses or sometimes the hashes it's a lot of this this data is very difficult to compress because an ethereum address is kind of a random so it's difficult to compress so here the technique that we're using is that we keep a kind of a state of all the transactions that has been made in the last in the last blocks

and then you can access to this address by reference so the first time that you use an address you will have to put the full address but then you will have a then to access an address you will have a single reference okay well I'm gonna jump a little bit this okay this one just to go fast we have we'll have like two kind of roll ups one for processing data the other four processing transactions and it's gonna be two pipeline it uh Roll-Ups uh itself okay here is uh in compression and this well these numbers from the last weeks these are very optimistical not they are very these are pessimistical numbers actually we are going to do it a little bit

better than that but uh we expect that data compression will give us a 5x in in cost okay that when you add that to the eip4844 that's 10x on top of that we expect that the the cost that availability cost once the eip4844 is going to be like 50x cheaper uh in the roll up so expect here the thing is that expect that in less than in half a year one year and most uh the costs for the ltus is going to be much much cheaper than what we have right now that we are currently we are something like 10 like 90 percent cheaper that L1 already

okay other other points of work is other points to work is the uh no no performance of course the scalability is very much about that uh processing transactions sequencing the transactions synchronizing the node and this uh you know having better database better cache it's a full work here in the in the note itself just one detail here is the the for account abstraction the cool thing of being a ZK AVM is that we get that for free I mean uh because uh you just need an evm to run the erc4337 so the system without designing itself we already have uh we have we will have

a construction fully compatible the 4337 we just need to deploy the 437 smart contract and then allow bundles to to send transactions there the centralized sequencer this is probably the the hardest topic but it's important to decentralize the sequencer in polygon we are working in that direction security of course is a Non-Stop thing keeping investing in security is a thing continue to do aerating all the new versions it's important to work in the security training wheels well we should remove very very easy very soon the the force

transactions there I mean this is going to be maybe in one two weeks we will enable that but then it's we want to be in a trailing wheels too as soon as possible this requires removing the the security Council and extending the the extending the upgradability to 30 days okay so this is a little bit the roadmap that we have for this for these years the idea is to deploy all these new versions with this data compression by the end of the year where we will see the 4844 when it comes but as always is not a commitment but

this is a plan that we have uh that we have right now on the table and just to to finish uh oh that's it oh yeah here is just to finish here it's a little bit more in the long run this is how I see the uh the L2 space so that there is to have a of course you have a lot of uh Altus uh chains that can be different chains they should have maybe a but they have a common liquidity a common liquidity pool maybe this liquidity pool will connect with other uh Roll-Ups and with other liquidity pools in other chains okay and the idea is that all these change

they can have uh they can have a proof aggregation so this can be a set of actors that can generate the proof in a coordinated manner in a consensus layer to generate a single proof and at the end in ethereum you have a single proof where you have the proof of all the chains itself okay of course this change they can be with centralized sequencer with the centralized sequencer there's probably going to be some stacking Hub where they can stake in in the different consensus that goes in here so these are the things the pieces and but the idea is that you can have a full ecosystem of of uh of chains with compass compost ability between chains uh because there

is going to be one single proof for for all the ecosystem you can generate a proof maybe every 30 seconds and this will be like a clock and then the composibility you can you can call from one rollout to the other and the other to the one this is this is the the nice thing of the case that you can have this uh small timings between uh interrollup communication because you don't need to wait for this uh fraud proofs for this space so this is a little bit the future that we are expecting and this is in the long run and this is a little bit the whole we're planning and polygon to move forward okay so this is very much my talk and

thank you very much [Applause]