Scaling Ethereum: Next Steps

Transcript

uh he comes all the way from catalunia he's going to talk about how about scaling ethereum uh please make him feel very very welcome put your hands together for Jordi [Music] Bina thank you very much it's a huge pleasure to be here in my city where I was born so well I'm going to explain here a little bit uh how we are in polygon we are um scaling how we are scaling ethereum uh my presentation will have like three parts the first uh um I'm going to give a nice light of the current state of the ethereum zbm and stay and explain it with the progress

then mainly I'm going to work about the polygon 2.0 that was announced uh uh last uh two weeks ago I think where we announcing it and uh then uh I'm going to explain um the the let's the shortterm uh shortterm and Midterm work that we are doing in the polygon ckvm more the technical details in what we are building uh there are questions I think this is the QR code uh the presentation is only 20 minutes and I think that five minutes is for for questions so I'm going to go a little bit fast so we have time for questions uh for questions at the end so let's start this is the current stage of the ethereum network of ethereum zkm uh we

decided not to go uh crazy uh I mean we we are not in a race with anybody uh of the TBL what we are doing mainly is we are on boarding uh a lot of projects uh we are working together with them uh we are increasing the transactions uh I would say in a healthy in a healthy way I mean no tokens no air drops no sings and no crazy things uh we are trying to do the things the right way there is I mean we are working a lot in fixing fine-tuning improving and this is the way that uh we like to work in in in in polygon but even that these are the the numbers still a lot of I mean it's a lot of things that are

happening currently in the in the in the zkm okay um okay let's talk a little bit about the polygon 2.0 I mean what at the end what we are trying to build at a polygon is is a long-term uh strategy but the strategy it's a strategy that's based very much in the in the ZK technology what we are trying to build at the end is um we can call it a constellation of rollups it's a space where you can have rollups here is we can have a rollups that can be um private rollups can be public rollups some of the rollups may have a calite sequencer other may have a decentralized sequencer with different parameters uh some of them may be like validum kind some of them are going to

have the data on chains where are going to be normal rollups and the idea is that all these rollups can there there going to be a kind of a composability between these rollups in order to have this so that from the user perspective at the end they see like as a single Network okay that's the the final idea for that we have a what we can we have a shared liquidity so it's going to be a single Bridge which all the all the phones are going to be there that means that it's going to be easy to transfer phones between one roll up and the other rollup one of the big difference and this is one of the differences between optimistic and ZK is that in ZK we have a instant um some final validity that means when you when you send the proof you know that this state is is valid so

that this is very important when you are transferring fonts between rollups and when you're moving between layer twos okay and the idea here is to have a a single here the idea is to have a um so each roll up may have like a single a proof that is proving the the chain but the idea is that the full ecosystem it's going to be a single proof it's going to be a single proof that's going to be decentralized that's going to aggregate all the rollups okay so the is with a single proof we can prove all the rollups that are in the in the uh polygon 2.0 okay and uh this roll up at this proof can be generated we are thinking in in in in in in terms of seconds maybe it's half a minute one minute or something like that so it's going to be like a clock every clock

that it's going to be a transfer between the rollups okay the coordination so that the generation of this proof is going to be coordinated with a specific consensus layer that's going to that's going to coordinate these that's going to coordinate this uh this roll up okay and the other thing that we announce is that uh in this in this network um uh it's going to be many so many networks with different parameters but one of those one of the thing one of the things that we are that we are we said that we are anoun set that we are proposing to do it's uh it's moving the current polygon POs to uh to a rollup this is a longterm probably this going to be the last I mean the last Network that's going to be uh uh in here here we need

first to build this uh uh constellation and have many rollups there but the idea is that the for the people that's building on POS they will have the the this addon this advantage that they will also be part of these uh polygon uh ecosystems this is very interesting because I mean you have for private rollups that they can communicate with public rollups private between private public between public I mean there is a lot of combinations a lot of interesting ideas for this uh uh for this uh different rollups okay um of course going to be some centralite sequencers but the idea is that also the it can be some decentralized sequencers sequencers for the people that don't know is just is

the actor the role of uh just getting transactions and ordering sorting they are not executing the transactions but they are okay we decide that these are the transactions that we are going to execute next these are the next one okay so it needs to be somebody that decides who is in the normal blockchain this is the minor and the minor is just changing in but in in the centralized sequencer there is a role that's uh that's saying that okay the idea is that uh the idea is to add a consensus layer here actually right now there is a centralized sequencer is also consensus layer we can call it a let's say a a dictatorship uh consensus is whatever the centralized sequencer says this is the consensus so it's very easy consensus probably the easiest uh the easiest one uh but the idea is to

substitute this idea to substitute this decision that's taking the decentral sequencer with uh an a layer one that's deciding about these uh these transactions but they are not executing and that's why it's scale so they are just deciding about about blobs they're saying okay this data this data this data and this this data when you process this data you get the a new state okay and you proof this Neo State okay um all this is going to be built in a in a with a polygon stack so they is to have a this from the software perspective but they there to have a single so having a a right now we are working in plony 3 plony 3 is a right now we are working plony 2 that's made very much based on the Goldilocks at least say yes plony 3

is it goes to even a smaller prime number and uh it's 32 bits this fits very good in gpus and vectorization things and it's a specific team that's working in in the having a a single Pro Prov system that's uh uh important we have a um um the the ZK the so what the the ckvm it's going to be ckvm and mid we have a CL the client so it's a team that's working with a single client the bridge staking Hub and and and andum okay but this is this stock it's a single stock so instead of having like many stacks Thea is to try to have a single stack uh with all the with the

best functionalities of each of each game okay okay so here is a bit idea of the polygon 2.0 so now I'm going to talk a little bit about the the what we are doing in the polygon zbm so as you know we launch it on on on on March uh well a lot of work have been happening from there a lot of would say uh adjusting fixing things uh getting the things uh better and um but the the the planning we are going to do I can announce now that we are going to do U the first let's say the first consensus or the first um the first first upgrade of the smart contracts uh very soon is

what we call it the 4K D5 uh here we are going to add mainly the the push the push zero up code that in there uh and a couple of uh minor uh minor fixes uh one of those is required to enable the force transactions a back that we need to fix uh in there okay uh The Next Step uh that's going to be this is going to be probably happening September October 45 here we are going to be Pro a type two uh roll up at least we are going to implement painings we already have a pings implemented internally uh we are going to add Shadow 56 and the the the the the exponentiation precompiled smart

contract with this I mean maybe there are some very arotic smart contracts that would still still pending but we can consider that we are mainly uh type two if we have this uh compil because this with this 99 % of applications is what they are they are using and we are going to launch that September October okay another thing that we are working and this is very interesting this is more it's a better Pro right now the pro is a monolitic proof where you have uh well you prove uh I mean if you see the zbm we are proving these these these transactions but here we have a uh we have some stain machines that do arithmetic operations some of them that do cat but they do a fixed number of

kcks okay this is the idea of the of the counters and and here the problem of this structure uh is that you don't use it uh you don't use it very efficiently because maybe there are some transactions that maybe you are using just half of the KCK that you have in the proof okay or sometimes you need more kcks and then you cannot build the proof okay and and then maybe it's a no operation transaction okay so this has a little problem of the flexibility so the idea here is to build the proof that each of the state machines can have different sizes and not only that even you can aggregate uh many of them for example if you have a lot of binary operations you can take a lot of the binary operations you can recursively you generate this recursive proof and at

the end you just join all the proof together here there is an interesting paper that we did in polygon in the research team in the polygon that's how to communicate between different degree uh uh parts of the proof and uh we are extensively using in this new AR in this new in this new architecture this is one of of the topics that we're working a lot okay so these are very much the the advantages of the B cops we're also working in the pill 2 as you know we build pill to build all the arithmetization for the polygon zkm we are currently working with the pill 2 this is a more um I mean it's a a an extension of this language uh this I'm not going to go deep because we don't

have much time but here is um of course we have a bad clop support that that's the the language was going to be it's going to be a constructive language right now pill is just a list of constraints and here you will be able to have like loops and and and conditions uh very much like whole circum works that you can build these constraints in a programmatic way like if it like a macro okay so you can have right now we have a we are using it but we have sometimes we have a external Javascript program that's generating pill so the idea is to have this to to have that we are trying to avoid these um auxiliary programs and uh keep everything in in pill so that's very easy to audit and to to see what hold there inate digestion is it looks like

okay more constru challes we have also uh challenges in Bill one we have some let's say um um high level uh high level um uh operations for have an instruction for doing block ops or for doing permutation checks or copy constraints the idea of this pill two is that uh these um high level uh constructions are built themselves in pill so it's the system is going to be more low level but it's going to be a library where you can do blups but if there is a new protocol for example for for for I mean for doing better rain checks or for checking some stock some we things the idea is that we

we will be able to build that uh on that and then you you will be able to have libraries where you have all these uh where you have all these um um prot protols embedded embedded embedded embedded in there fixed columns right now we have external programs to put all the constants of all these fixed uh the constant values of the fix columns we have a full programmatic way to include it here in the in the pill this will be is going to be very helpful especially for auditing and so you have everything in the same place maybe there is still some polinomial very specific that requires something outside but uh here because it's programmatic you can you can you you can you can generate it with this okay you can access right now in

pill you you just access the current row at the next row here we have a system where you can access the previous Row the next row or even two previews three previews and all that in a programmatic way um and here is this pill also okay you have the pill this is the constraints but a lot of times on you when you build a proof you need what we call the weakness computation okay and then you need to give some hints you need to give some information that you need to transfer to the wind know to the person that to the to the window generation so here we're adding the concept of uh hints also to to build the to to pass to the witness so you can have uh libraries in the witness generation that uh trades specific U sting Machines of theic libraries of the

pill that they they work together and they generate okay you can have a a a pill for blups and then you have like a library for the windows computations that just fill the weakness of the polinomial computation okay but you need to you need to you need to pass information which polinomial is which when you are defining okay so this is I mean this is very technical but this is very important because this will give a lot of improvement in this in the generation of this proof okay the other part more more uh more that we're working is very much in data compression the idea is that right now we are putting the full transaction with the signature all together on chain okay this is I mean this is we are doing zero compression at this with the corrent version the idea is that we can compress

this okay give you here some hints well this is a little bit how compression does at the end you can understand a compression file as a set of commands that's like printing information so you can have for example a r right that's something you want to put some information that's not compressed okay uh but here you things that you can do is for example you can one of the things that you can do is for example removing the signature removing the signatures the idea is to substitute all the signatures of the transactions with a proof that you that there is one single uh with a proof that all these these signatures exist okay the problem is well the problem or the difficulty or the challenge here is that the uh uh you want to put include this proof this aggregated signature if you want in the

data availability and then we you want to prove that in the in in the proof uh in the prover okay that means that in the prover you need to have paintings for example because you want this to be short in One S because data availability you don't want a big St here you want to save in this for but at the same time you want to uh you want to be able to prove but because right now we already have paintings is this is perfectly possible so we can aggregate that put it in a elliptic core kind proof and then uh verify in a another proof that Aggregates other proofs reference to all that another thing that uh takes a lot of data is addresses I mean when you have a lot of addresses are random numbers the idea is of course the first time that you are

using an address you will have to pay I mean you will have to put the exact address okay but once you reuse this address the idea is that instead of briting the having this address you just can put an index to these to to previous address okay so you need to keep in state of previous addresses but you can perfectly do that and here you save a lot of information okay okay here you have batches the batches you create blobs and the blobs well is more the technical deta and then you aggregate the blobs and and and finally you just have a single proof that aggregate everything okay uh here the just with data compression we expect a 5x uh Improvement in capacity just with the same data availability we

can compress the the the information uh 5x okay and uh the other thing is that with thep 4844 that we expect this to happen by the end of this year beginning next year in the the foundation this will give another 10 another 10x on top of that so when you join together we expect to have a capacity of 50x uh uh by the beginning of the next year okay of course to scale uh to scale the the the system is not enough on the Prov uh on the pr part you need to this is like a car you have a car and um you have a a uh so you have a car and and and you you build an engine but it's not enough to build a good engine you need

to build a good Wheels you need to have a bu a bu a good um shape and you need to build everything on the car okay so need we are working also in the synchronizer in the the the database sequencer and all this part just a few mention that one of the cool things of being a z kbm is that we get for example the work from the ethereum space for free for example the the IP 437 thec 437 for the contraction uh I mean we didn't plan it to have a contstruction in the ZN but we already having for free because we are evm if ethereum have it we have it we just we just need to deploy the smart contracts without compiling in in the polygon km we're working the centralized

sequencer as I mentioned before security uh I would say that the think that I'm more focus is in the in the force transactions this is the the the thing that we want to enable as soon as possible uh uh but here is uh well a lot of of course it's always a work in progress in there okay and uh yeah there's a little bit of R map and yeah that's very much uh I think I have two minutes for for [Applause] questions oh just remove

um the the well the question that I read is what's the the cause of the Vari why the transactions are uh the price of the transactions are uh different uh uh depending what's and here very much is the the the biggest the biggest bottleneck is the data availability data availability you need to pay the data availability here there are different strategies uh one of the things that we are going to implement now uh in the in the next 4kd is that uh we are going to play with the effective gas price so the idea is that uh the user will set up a gas price limit uh but then the sequencer will be able to to to uh just charge a percentage of that okay and with this we will adjust the different

the difference between so we are going to charge at the end the real cost not the uh not the not the actual cost okay right now it's a little bit uh messy because it depends many things but with this uh new Fork ID this is one of the things that we expect that's going to be better and especially for thei transactions we expect a a reduction in the in the in the price so transactions that are very I would say um uh um Computing intensive and they have low low uh low data like defi transactions they are going to benefit very much on on on this okay I think I'm running out of time but uh I'm here about I'm here

outside avable if any of these questions want to ask me directly I'm happy to answer to you so don't want to be out of time so thank you very [Applause] much