EEZ: Building Synchronous Ethereum with Real-Time ZK Proofs

Transcript

Hello everybody. I'm George Valina and the founder of uh ZISK and Easy. And today my presentation will have uh three parts. First I'm going to do a a review of what's the current state of uh proving Ethereum and the state of ZISK. Then I'm going to explain a more technical details in how we are building the proofs in easy. And finally we will go to other rollups and compare times and see the progress that we are doing in other chains in other rollups that are not explicitly Ethereum.

Let's go for the realtime proving where we are. Well, we are here. Okay. So this is uh with one GPU. You see the distribution there. you see that the average with just with one GPU is 8.5 uh seconds building it. Uh if we go to p99.9 so the the percent 99.9 we are above uh it's about 14 seconds but if you go to two GPUs the time uh goes to less than 5 seconds and the P99.9 is uh 8 seconds. So we can say that in today's day with just two GPUs we can uh prove uh nethe okay and if you go to four GPUs you see that the time

continues uh dropping on that this is and I want to because these numbers looks like okay that's you see but I want to remind here where we were uh one year ago in def connect and where we are right now to see a lot of the difference first of all so the last year so in in in in in in Bonosiritis we needed 2459 PS okay today we need two okay the average time was um 768 seconds right now is less than 5 seconds but Ethereum by that time had 45 million gas right now we are proving blocks of 60 million 60 million gas

by that time was discovered this Stark's conjecture that was not safety so we have to go to 128 fts probable security that means making much more queries in the fry protocol. So we absorb also that. So right now we are also in the in the in the proof. Okay. And the last thing and probably the most important part we were using uh by the time and until very recently we were using posedon by the time posed 2 or posedon we just read out of the arithmetic functions. Right now we are using Blake 3 and we are get all these uh improvement anyway. So you see the the I mean how much we advance in the last in

the last year in this one thing that for us is really important is security for us is security first. Okay. So we are the only protocol that's still 128 bits uh probable uh security. We are fully quantum resistant. The size of the proof is less than 256 uh kilobytes. Our system is fully open source including all the GPU code and everything. You can go to the GitHub repo and use it and download it in any Apache MIT license. Uh as I mentioned before we are not using any arithmetic hashes and currently we are working

really hard in the formal in the formal verification. This is the I would say this is the main priority that we are having in the team. Okay. Um having an end to end formal verification. This is an important effort. It requires a lot of the pieces starting from the cryptographic uh protocols but also includes all the recursion all the verifying all the different circuits and pre-ompiles that are there. the B what we call the bus and is when we aggregate these proofs in how they connect we need to formally verify how this connect is also the part of the transpolation um between risk 5 and and and that we need to formally verify to we

have a library we kind of kind of operating system with basic functions like CDSA or ketch at high level that we would want to formal verify to and all these we are doing in lim 4 and connecting all the pieces together. So at the end you will have a single proof maybe very long that is mathematically guarantee that when you have a a a zisk proof um the execution is uh correct according to the risk 5 um uh specification by the way we are using we're taking the seal one as the specification this is currently working in progress I believe that in uh few weeks months uh but quite early right

now we already have like a a minimal system more or less verify it end to end and just a matter of putting the pieces and we hope that we can have this very soon. We're also working very very much together with Ethereum Foundation in the specification in what we call the ZKBM standards. So the idea is that when we have a uh Ethereum client all of them they are using the same I mean the same way so that a a single Ethereum client can connect to any proving system. So it's a work in progress but we are working close together um and we are probably we are the the team that's most um um that's most compliant with the standards. I mean the standards is a

work in progress. We are discussing with them. Things are changing. we are learning together but this is um an important part that we are using to okay another thing that we have been doing um so uh right now so we are running the prover in in in seporia in sepoleia using the IP 8025 and and um like host we have been working together with them so the idea is that we are already um in sending to the peer-to-peer network uh this proof that the validators can validate without having to have an execution an execution client. All this is already running. Uh

and this is are the the timings. Uh important to mention that the first one is uh the block time mean the time since we see the first block until uh we we the proof is propagated. The other one is just the the the creation of the proof. Okay. I've been working a lot in in trying to align um I mean the clients so that uh we can start generate the proof as soon as as soon as possible. Okay. Another place where we have been doing a lot of work is in what we call the killer blocks or the or the idea is of these blocks are pathologically generated uh blocks that they try to explode the explode the prover. So in

the sense that you either you cannot proof uh some block or uh the proof takes very very very long. This is there is a full repo in Ethereum with a lot of these um uh killer blocks. We're running all of them and it gives us also a good a good idea of where we are here. There is some um in the especially in the in the KCG in the BLS here we have some optimizations that we still can tweak tweak a bit. Show me >> that we can we can tweak a bit and uh uh but besides that that we still have margin to to that we still have margin to improve. We have um the rest are very much um

in general are of codes that are very cheap and that you just execute a lot of them. So are very cheap in gas terms. So uh the margin so what you can do inside the proof is very low. So very much we are in that limit where you cannot uh go much uh farther. Okay. So this is the the optimizations and the good news is that we are also running all these blocks in in 200 million gas uh with a new uh I mean with a new block uh size that we're having all of them are running and with relatively few GPUs uh you can we can get a guarantee that we are able to generate always all the all the blocks. Okay. Another important uh piece that we have been working a lot is

a zisketh one. This one is a full client is a stateless client. But the idea of this client is uh to show other clients how we are optimizing that client in order to run in zisk. I mean how we call the pre-ompiles and all the tricks and all the things that we are uh doing the this one is about between one and a half and twice and two times more uh cheaper uh uh than ref okay it's written in uh C++ is use is using is using underneath AVM1 actually there is two versions but very much one and um well it's um um it it it it has the full GL glamsterdam I

mean it's fully glam glamster van compatible um I mean right now this is the one that we are running in sepoleia um we created this ref extension so that we can uh we can get the we can have access to the block as soon as possible and if there is a fork we can cancel the proof and start the the next block we're passing all the Ethereum test um for the last forks but we're passing all the Ethereum test this is the one that we are running all these 200 million proven killers on top of that EAP 8020 and um we'll also u check at a lot of the uh a lot of the sness so they are trying to keep this client as safe as possible

running some internal audits in there again this is fully open source you can uh check uh uh in there okay let's go to the next the next page and it's like this is a little bit changing gears here But this is how we are building easy proofs. Okay. So if we see what's easy, easy is very much is a synchronous composibility. So the idea is of easy is that you may have uh well one L2 and L1 another L2. And the idea is that you can uh in a single transaction you are calling um smart contracts that are in a different chain L1 either L1 or neither L2. Okay.

So you can have nested calls, you can have reverts. So the idea is that we can split all the executions with um small pieces with different um execution pieces that are uh executed in different chains. Okay. And in easy for example these different chains they can even be proven with this different proving systems and and they may they may have different state transition functions. Actually we define in easy we define what we call is actiondriven state transition function. So it's a state transition function not of a transaction but it's a state transition function of this um small piece of a transaction of mean if you are doing a call if you're in this state and you're doing a call then the this uh chain is going to this

uh uh new state okay and this um action-driven function this is the one that in easy u any chain can define their own one okay how define them well they create um uh if they are using easy uh if they are using zisk as a as a ZK prover they are creating a circuit that actually is verifying this uh mean this this transition I mean this call or this return I mean this piece of execution that happens inside a inside a transaction. Okay. Another concept that I want to introduce and this is something uh I mean in in Z we have a a system that allows us to connect very well different proofs so that we can uh

split the computation of the proof in different I mean in different proof and then aggregate them together. Okay. But how do we um how do how do we connect them together? Well, we are using what's called a cryptographic accumulator. Okay. A cryptographic accumulator is very much like a hash but uh but it's a hash of a set. So the idea is that uh to this set um so if you have a set of elements you can add elements to this set or you can remove elements with this set and no matter if you are adding elements to this set um uh no matter which order you are adding them you are going to get exactly the same the same hash.

You can use elliptic course but we want to be quantum resistance. So we are using a technique that's very much adding hashes but this is not safe because if you are to hash uh we have this birthday attack but the trick at the end is um well having bigger hashes so that uh and limiting the number of times that you can uh that you can add them. So then adding uh adding I mean getting a hash uh big one of this big hash and adding we can add and remove. Okay. And this is what allows us for example um um it's like this idea of a boss. Okay. So we can have a proof that's adding things uh to this accumulator and other proofs that are removing things in the accumulator.

Okay. And the idea is that then we can aggregate them together. So the idea is that we are just adding or I mean we are adding or subtracting I mean all these all these accumulator and at the end this accumulator needs to be zero. Okay. So for example in the in the idea of uh in the idea of easy uh we have uh three big different types of proof. We got proofs that very much verify uh blobs. We have proof that uh verifies these uh state transitions functions and we can have a proof that actually computing the hash that's happening in L1. Okay. So it's an example for example uh uh the the one that's um proving a blob well

it's it it adds to this but in this case subtract to the to the to this uh accumulator is it subtracts the blob that's doing okay but if we go to the hash actually we see that we add this blob uh this blob commion so when we are saying that we are processing this this blob and we adding that into the hash we are adding that to the same accumulator so that means that at the end whatever is in one assume it in one proof is verify it in the in the next proof and we can connect uh the different proofs all together. Okay. Um the cool thing of this is that um and this is uh super interesting is that um okay in easy anybody can define new state transition

functions and we don't even know what transition functions uh people will use it. Okay. Okay. So, how I do a proof of something that I don't know yet? Okay. Well, the idea is we have this adapter of a straight attention function that's verifying any um any circuit with the verification key as a parameter. Of course, the circuit needs to follow certain rules. And is this circuit the one that's computing that the one that's computing the accumulator and it's adding to the accumulator? So I can so I can define with this way um uh new uh chains can define their own uh state transition function circuit and we can join them together in the in the in

the easy in the easy proofs. Okay. Um just as a reminder on easy, it's important to um remind that um the hard part of easy is that well you need to construct this um we need to compose this this these uh transactions very much taking transactions simulating or executing extracting these small pieces and at the same time uh proving all that the fact that we are dividing is with different proofs so that you can change the data. This allows us to generate the proof as we are composing and at the end we just care about the

last um delay that currently is less than 3 seconds and probably less uh uh uh at the end. So if all this needs to happen in a block of 12 seconds, okay, you have like maybe 8 seconds, 9 seconds to build the block and then wait like only 3 seconds just to finish the the the the proof building. Okay. And my third part well I just want to talk about uh different chains and see how we perform here. Yesterday we published it. This is uh proving optimism. So we are proving optimism in real time. Okay. So that means that since uh there is some blobs that are uh included in L1 until we have the proof

available in average is less than uh 11 seconds with just four uh GPUs. Okay, how we are doing? Well, we are using very much the same technique of this accumulator of building things. In the case of uh uh uh in the case of optimism as blobs as blocks are generated, we are already proving them actually we are packing all these proofs in groups of uh five blocks and we generate a proof that proves execution on that part. Okay. And um while we are generating this we already are aggregating them. So we are advancing as we go. Okay. And finally when the when the blob is included in the chain actually well we process all

the blob we process I mean we connect all these change we do the final aggregation and then we can uh we have uh this proof and this is very much using this technique of the of the cryptographic um accumulator. Okay. Uh just to mention that uh we are using four GPUs mainly for minimizing the time that the blob and the that that the blob when the blob is published in L1 uh until we want to have the proof available. But all these GPUs are very empty. I mean they are I think proving a blob is proving a block it takes something like 07 seconds in a block that takes 2 seconds. So GPUs are quite empty during all the time and just in

the last minute we are putting four GPUs for the last uh for the last minute thing there is and even that there is a lot of margin for optimizing we are losing sometimes I mean connecting to the RPCs preparing the the the witness and actually building the the building the proof aggregating the final the final proof and then building a snark I mean building this is uh this building uh a proof that can be validated uh on chain. You see that this is not this is the important part because it's just less than two seconds we can generate the the last uh the last wrapper. Okay.

And finally I want to talk with uh to another project. This is the aggregation layer from polygon. The their circuit mainly they have like two different circuits. one that's just uh uh proving a multi or proving a multi plus another uh so another zk proof in this case it's an sp1 proof so uh we are proving from inside this aggregation layer we are proving the sp1 we are using different prime fields but we have all the all the circuits to prove different different proving systems and uh yeah I mean the generating this aggregation layer proofs it's it's I mean it's taking uh 7.4 uh 7.4 seconds I mean um

yeah so so this is the idea of the chain and this is the well this is the the improvement that we get I mean currently in in in polygon it's taking about 200 seconds to generate this proof uh and in this we are doing uh exactly the same with just one GPU and 7.4 four seconds. So, it's mainly uh very few and probably there is still some things to optimize. And yeah, that's very much my presentation. Anybody interested in this or I want to hear about any chain that uh wants to zk proof uh their L2, we are in here in the in we have a we have a a booth here.

So, happy to hear from your from your chain. Thank you. >> Yes. Yes. Great. Thank you so much, Jordi. We have I was just about the question. We have a lot of them. Let's have a What happens if one rollup goes offline or fails while another rollup is waiting for its response? Can the system still work safely? >> Yes. I mean, this is um Yeah. Yeah. Yeah. I mean, the one of the important things of the of easy is that security is the cop. I mean one roll up cannot affect in any way another roll up and this is the main design uh things if a

first we need to understand what means that a roll up fa fail I mean if roll up fail maybe maybe means that the sequencer does not generate that that means that probably it's going to not going to be uh that the composer will not be able to generate any transaction that touches that roll app but yeah that's fine other roll apps will continue working >> okay next how does e said, "Oh, sorry. Zika proofs takes time to generate. Generating this proof also introduces latency problems. How do you solve that?"

>> Well, this is the main this is the main um this is the main uh I mean the main idea of the main motivation of Zisk I mean we are trying to minimize this uh latency. Okay. So um right right now for example proving ethereum block this latency can be one two seconds uh finally okay and we are reducing I mean one of the motivations for us is reducing of course it always is going to be some latency because I mean in order to prove some to prove some execution you need to execute it first and then finish the proof so it's going to be always some latency but the idea is to reduce that as much uh as we can in the order of uh seconds or few seconds or

even less. I mean in the oral of subsecond probably is is possible. Important part here is aggregation. I mean the aggregation is um we are able to aggregate in in in 200 milliseconds. We got a little bit penalty going to blade. We were at 80 millconds. Now we are at 200 millconds. That's still very very very fast uh aggregation. I mean just in one GPU aggregating something in less than 200 milliseconds is uh I mean it's like the last delay. Uh uh so this is a little bit the limit that the end you need to aggregate something. Okay.

So that's but below a second we should be there. >> Great. Why why have you replaced Posidon 2 with Blake 3? Is Poseidon 2 safe? SP1 is still using it. >> Yes. Um I mean Poseidon is is safe. I mean we there has not been any way of breaking Poseidon but recently has been some discoveries and uh in Poseidon that let's say cryptographers don't like it and it's like okay it's not broken but it may so there are some suspicious that uh things that should not be possible are possible. So when there was an

announcement from uh EF uh that they want to read out of uh this arithmetic uh hashes and that was the main motivation for switching to Blake. >> Okay. >> But say I mean just to be clear I mean the all the all the current systems that are using poson there is no way of uh it's not known way of breaking uh poson at least as far as as as we know. >> Great. How does E set allow two different rollups to communicate with each other instantly without waiting for Ethereum to confirm every transaction?

>> Well, that idea is when you have two rollups at the end is the Ethereum is the one that's settled. Okay. So, uh one roll up one is talking with another needs to commit um that the roll app is doing a call and the other is receiving. Okay. And the settlement layer is Ethereum. So actually this um communication doesn't happen until uh you uh settle in in Ethereum. Other thing is that okay they may agree and they include uh some transactions that they are going to be included in the next block. I mean but there's a private agreement between them I mean open to that but from the easy perspective the state is um settled when uh a transaction in L1 is is done and then we

warranty that the two states of two rollups that that are calling one each other are um uh uh I mean that updated at the same time anatomically. >> Amazing. One last question be for long time. Since EAD uses Ethereum blobs to exchange information, what happens if the data becomes unavailable or Ethereum experiences heavy network congestion? >> I mean the idea of the idea of the blobs is that the data is is I mean it's data availability. So that's the mechanism that Ethereum provides about this data availability. These blobs are um available. there is a lot of people that's uh collecting them. Um I think

they are there for 15 days. I'm not 100% sure but they that you'll have so everybody has 15 days to collect those blobs and those blobs are going to be uh should be available means be at least somebody that uh collects them. If you have some uh stake in the I mean skin if you if you have some interest in in in in that and you you can always collect. >> Thank you so much. People have even more questions but I think time is up. Um you will still be around.