DAPPCON 2025: Zisk, zkProving in real time - Jordi Baylina

Transcript

[Applause] Well, hello. Um, want to talk today about uh ZISK. ZISK is a project that we have been developing inside uh Polygon and is very much what we call a ZK VM. I mean it's a ZK prover where you can build circuits using a high level uh language like Rust. I mean it's let's say a modern the modern way of writing uh Sika circuits and today here in this stage in Berlin I would like to do a really important announcement uh that just happened last Friday and is that ZISK we are spinning

off uh ZISK uh from Polygon. So we are becoming an independent and free project. We are a team of about a team of seven developers plus plus myself and we decided to keep this project uh uh outside uh polygon still committed of course to being open source. We believe that this is a really important project for the community and for the space and we are very committed to this project and to this technology and that's why we decided to spin off. The big motivation for this is in one side polygon wants to uh let's say wants to be focused more in the aggregation layer and in the in katana and other um uh products in the high level. Okay. And they want to be

free to choose uh any ZK technology that's uh available. I mean they don't want to be uh committed to a specific uh u zk and in the other side from the z perspective we don't want to build a product only for polygon I mean we want to build a product for anybody that can use it in the space so spinning off this makes a lot of sense so because we can start uh being in the space of the provers competing we are an open source I mean I like even the word competing but at least being in the space and and and working in the space for for for having a better uh ZK proving uh systems.

We as I mentioned before uh we are a set of uh eight persons uh mean we move out of polygon. We took all the I mean the intellectual property all the knowledge we have been developing this in the as polygon Hermes uh the polygon ZKVM we took all the knowledge on the no of the ZK we have been building for the last two years the last year is the specific disease but for the last two years the development of a new new proving system and uh this is the part that's uh u that's a spinning that's a spinning out okay and as I mentioned the our huge commitment to being open source project.

This project is uh going to be this it's going to be MIT slice Apach and it's going to we continue with that license um I would say probably forever I mean um on that here of course you can follow us these are some credentials I will mention later on but yeah this is a important moment for us we are very excited and uh for this project the team is very excited and very committed to this I think that here we and advance. We already did a lot of advances in in the space. The people that has been following us in the death proof uh channel or in they saw that uh we already contributing a lot uh to this uh to this space. Why proving in real time

is important as I mentioned the the main the most important and most differential thing of uh the ZISK is that we want to generate proofs as fast as possible. Until now the proofs were we are trying to minimize the cost but with zisk is not only about minimizing the cost but it's also or it's also about um minimizing the latency. It's really important to generate proof fast here is I don't care if we need to put two servers four servers um 20 GPUs whatever but the idea is to generate proofs in parallel so that we can generate these proofs real fast. Why is important this fast? Well, these are the main

applications. Of course, if uh one of those is in the roll-ups, normal roll-ups, they will uh verify they will normal they will have to prove uh that the state is valid and uh u and so that you want to do that uh fast. This is more clear for example in uh in the aggregation layers. uh if you want to communicate any chain um one to the other you need to commit um you need to commit to a state and you need to prove that that state is fast so that these fonts can be used in the other chain in this bridgeing this connection between chains so it's really important that these proofs are generated really fast okay and this was the signet from the first day with that in mind so how much we can push this technology so that we

can build this proof fast I will show you later in this presentation the numbers that we getting together. Okay, but the goal is to be able to generate Ethereum blocks in real time or even less. Okay, as faster as we can. And of course, this technology is also very important for let's say new generation consensus u algorithms. uh uh the bean chain Ethereum is one of these examples that the ZK uh is used in the consensus algorithm and this become a really important piece and for that it's also really important to generate these proofs really fast and pushing hard uh on this technology

some properties uh uh about uh ZISK um um this is um I mean as I mentioned this is designed from a scratch to run in a distributed The idea is that we try to paralyze as much as we can so that we can generate the proofs faster. There is one specific piece one small piece that's the execution itself that cannot be paralyzed and we try to demise that piece as much as we can. At this point this piece is u let's say 15 times faster than any other prover uh uh in the space and in the other side you we have like uh GPUs and everything is paralyzed so that we can always put more resources um to uh be able to build a

proof in a constrain in a constrained uh timing. We are 128 bits for me this is really important. We sense seen in this space that for example there are some projects that are lowering this requirement to 100 bits and even lower uh in order to get performance. I think that we cannot accept that. Uh the standard in the industry even outside the block I mean in the world is at least 128 bits. Uh we can increase that but we cannot lower that. Okay. So we are stick to this 128 and we are going to be hard pushing for these 128 bits.

Zisk is also fully open source and when I say fullying open source that means that we are open source not only the code but also the GPU code. So everything the development that we are doing we are doing in an open way. We are a community project and uh we want to keep this uh open source. I believe that in the space there is no place for u companies or groups that are doing closed source uh uh in the space. So here we are fully committed to that and uh that's one of the core or core values that we are pushing here. Okay, this five is the only one in the space that's 64 bits. This is a I mean this a design it's a risk five 64 bits. Current compilers are 64 bits and this is good

for example if you want to uh create Bruce for example in Golang or in C that they have their own compiler and they compile it to a 64-bits architecture. So this is one of the reasons for using 64 bits. Also there is some optimizations and it's better um and it's better uh for from the optimal perspective to use 64 bits especially when you do memory copies and other things like that. And the other part that's important is that ZISK is uh I mean it's not um it's not just a ZKVM. I mean it's a full it's what's really it's really a full prover a full ZK prover that has one specific applications that's a ZKVM. Okay. That's a full stack for building uh for building uh for building proofs.

Um so the you can use it also for proving other things that are not a ZKVM or doing other kinds of ZKVM. Okay. Uh this is a full stack. Um um see that the proof man if you want to pro itself this is based with a P2. P2 is an evolution of the original pill from the polygon cvm. It's a well it's a much much more advanced and getting all the experience of PEL we just create this P2 with much better uh properties. We also have the recursor we have all the technology for aggregating uh proofs and and really fast and um compressing that in a single proof. The aggregation circuit right now

it takes only um 115 milliseconds which is really low. It's the lowest in the space and uh is also an important technology that's part of the full stack uh um of of this. If we look a little bit internally how this works. Um so the idea is that instead of having a big monolytic proof as we had for example in the first versions of the Zikibian here what we have is we we we call we have a lot of super proofs of if you want to call it we call it heirs okay a lot of um pieces so that u that some a lot of them are specialites and then we generate we

aggregate all these proofs all these proofs if you want all these airs to a single to a single proof this is specifically ization of of course we have the main processor. This is just take care of executing the the of verifying the the the main processor execution. But for example, we have uh some um other state machines some of them for example that are focused in doing arithmetic operations. Some of them are doing for catch others are doing for binary. There are some of them that's taking care of the memory uh the ROM. So we divide this and the idea is of this is that we can have many of each. For example, if we are running a program that requires a lot of binary probably instead of having one instance of binary uh proof, we may have two, three, four of them. So we can have as

many of that. So we have this idea of variable u variable proof or a proof that can be as big as uh you want. I mean we are not limited for a big hardcoded code. I mean we can add more suproof as we need. This is is translated in a way that we so if you want to create for example a bigger block um the result is that you may need to generate more of these uh stage so that they may need you may need to put more servers or more GPUs to generate those blocks but the time is going to remain constant. So no matter how big is the block uh that the time generation should not increase or at

least should not increase substantially. Okay. So that's one of the important ways of u u of seeing and that you see that this is a quite a modern architecture. Okay. As I mentioned before this is everything is based in a language for writing all the imitization. This is a P2. It's a very it's a very flexible and very competitive. This language allows us for example to audit the the arithmetization in a in a very compact in a very easy way. We saw that this is very we got all this experience from the ZVM and this give us a very good results. So a auditor teams they can focus in a relatively small uh number of lines to

verify because we have this uh language. But in pill 2 we added everything that we missed to add in the first versions. I mean we are uh generating the constants inside peel. We added all the let's say all the all the language for these multiple multiple uh state machines. Um so we have all the all the logic for connecting all these state machines in the same language and many other things that make this language um I mean it's a simple in some ways and at the same time more flexible uh on that okay what else um well as I mentioned uh the the the when you have all these um state

machines I mean you have the arithmetic state machines the main processor state machines so how it works Well, it works very much like a normal let's say hardware uh embedded machine. I mean we have a processor, we have a ROM, we have a uh RAM and we have arithmetic binary that you can you can understand those if you want to scope processors that are handling certain operations uh for doing that. Okay. And the core part is this what we call this this bus. Okay. This bus is what connects one state machine to the other. How this bus works? Well, the idea is that we are using one technology that's called uh log up.

Okay. And the idea is um have what we call it I mean this boss is that uh when there is one state machine that wants to assume for example the main state machine is not proving multiplications. Okay. So when it has to do on multiplication it adds something to the boss. Uh this addition what it does is say okay I'm assuming that this multiplication is proven in the right way. Okay. And in the other side in the arithmetic state machine what you are doing is subtracting from the so I'm proving so what was assumed in the main state machine no I'm improving that so I'm subtracting okay so everything that's any state machine is assuming u and there needs to be like another state

machine that's subtracting this is done in two stages so what you are adding and subtracting to the boss depends on a challenge because you do a commitment and then a challenge so you can modify okay and at the uh the sum of whatever is in the box needs to be zero. So everything that's assume it needs to be uh prove it and that means that everything that's added needs to be subtracted. So at the end the result is is is zero. Okay. And this is the technology that allows us to connect all these um um state machines. Okay. Um an example of that is for example um uh well uh this is the uh different the

arithmetic. Okay. So this assumes it adds to the bus and then the netic is subtracts. But um uh but this allows us for example uh oh no let me just go to the u um this this allows oh this is wrong but in the case for example in the arithmetic for example one thing one trick that allows us to do and this is an example is imagine that in the in the binary we have some operations that are quite usual in the in this when you are adding 0 plus 0 + 1 or 1 plus 2. This happens a lot of times in the program.

So one trick is instead of proving all these small operations, you can have all these frequent frequently operations in another streaming machine that they are hardcoded. So they are much cheaper to prove it and you can prove it by doing that. So the thing is that this they are substracting to the bus this part and you can select which one you want to uh substract. Okay. The same thing happens for example with the me with the meal line the memory. So when you are doing when the processor is doing a memory operation there is when the state machine that's substracting the memory. Okay. But this memory is very optimized because it's it handles alignment all the words of alignet uh alignet uh uh operations which is the normal operation that normal processors

do. Okay. But what happen when there is a non-align operation? Well, we have like another let's say intermediary machine that's kind of a meal line. So this processor it's it's assuming one memory operation an unaligned memory operation. This memor line somehow solve it substracts from the bus the memor line but at the same time it's adding two new memor lines. So two two new access to the memory and that are alignet and then are subtracted for the normal memory. Okay. So this allows us to combine uh uh the things uh with this uh with this bus.

Okay. The same happened for example for the for the processor. I mean the processor uh you can have what we can sometimes is the continuations for the inner continuations is that you have you can divide the the work in many chunks. So each one can be one proof but how you connect one with the next. Well the idea is very much the same. at the end of the processor we add to the bus the state of the current uh I mean of the of the of the processor and at the beginning of the boss we subtract that from the state so it's a way of connecting uh these things and the same thing happen with memory but instead of when we have memory instead of dividing that by uh the clock mean the execution time we can

divide by memory address so we can take all the operations in one range or in one state machine another operations of Another range is another state machine and the state uh between uh ranges is also added and subtracted to the bus. I mean it's it's not a time division but a address division but the idea is very much the same is using the bus for these internal uh continuations. Okay, these are the uh these are the numbers that we are right now. Um the if you see here um oh this is this slide is got it but anyway uh so mainly we have like four stages uh for generating the

bus one is this execution part this execution pass we are really really fast right now so we are able to execute uh 1.5 GHz probably 2 GHz with uh let's say overclock another better hardware but that means that uh I mean if you want to prove an execution you need to execute that okay but if you have risk five you need to emulate that so this is a will be the limitation. So the technique that we are using that's very much about transpiling I mean we're converting risk five instructions to Intel instructions. Okay. So this is uh we have a very very very high efficiency on on that. Okay. So that's why we are able to execute this part that needs to be that cannot be paralyzed. This part is really really uh fast. Okay. And here we are good. I mean this is we are this takes less than

one second. I mean the see this this is why this moved but anyway uh the Windows comp the Windows computation this is the part that probably we are working more this is the one that we put less love uh in the last weeks but we are working hard this 6 seconds probably can be at around 2 3 seconds uh in the next version but this is okay we get the minimal trace of the first execution and we are now uh creating I mean we are actually writing all the polomials that we need to prove I mean all the evaluations of all the polomials that we need to prove all this port is already in parallel. Okay. And generally it's a CPU work and this is running in parallel. Then we have the the the air is building and it's a proof itself.

This is a built-in GPU and this is highly uh highly parallel. Okay. And this is of course you need GPU power. This where the real power is but this is highly parallel and this is 7 seconds but it can even be lower than that. And there is a final that's gooded in the slide but it's a final one that's aggregating all this proof. Okay. aggregation uh or aggregating currently I think we're aggregating 3 to one so aggregating three proof to a single one this just takes about 15 uh 15 so 150 uh milliseconds okay so if you have if we have 1,00 let's say 1,000 airs aggregating this 1,00 airs this is lock this will take about 1 second and a half

one second 1 second and a half two seconds to aating that so when you add zoom up all together you see that we are in the numbers of uh real time proving. I mean I think that we could we are currently with the 6 seconds we are maybe at 16 17 seconds but when we uh get better with these six seconds we probably be below the 12 seconds that's the real time and we probably can get even lower because there is still a lot of optimizations that are working. So I mentioned this is the this is the what we're working optimizations finishing pre-o compiles here of course there is some cleaning uh documenting auditing and formal verification this is important that we are working on and yeah this is the this is where we will

need some help I mean this is the we are as a small project a small team we are focused in creating that but I mean auditing is expensive generating the GPUs is expensive but we hope that with the help of the community we can improve and get better uh on that. Okay, come follow us uh here. We're going to this is a public announcement that we do with this spin-off. So, we are very excited and hope that uh uh in the future we can be a reference in the in the in the Zape proving. And that's it. Thank you very much.

[Applause] Thank you, Georgie. So, we have a couple of uh questions if anyone has. we have some time you can ask and we'll have a mic pass around to you. So yeah um nice talk I had uh two questions. The first one is about like when you split the memory into several pieces um how much is every co-processor like how much memory does a co-processor represent and do you split it per region? uh for example you know ROM code data or is it just uh a section of uh of memory like a

fixed size when we are talking about memory here is very much about uh data the the code is what we call the ROM so it's a different state uh uh machine so data or RAM if you want okay there is the input special memory that's for the input data but what we call the data is that and what we divide is divide by address okay and maybe we take from zero to 1 megabyte or from megabyte to 2 megabytes. We can uh adjust this the size of these uh state machines. I think that currently is two to the 18 or two to the 19. But this depends very much on the hardware. So we can do bigger or smaller. Uh I mean all these state machines can are highly adjustable. So the idea I mean the optimal part here is

try to do the state machines as bigger as possible that they fits inside the GPU. This in general is the optimal. I say 2 to8 maybe it's 2 to 22 but it's like it's a depending on the configuration of the hardware we can adjust this so that we optimize the time and the cost for that specific state machine but it's a region on the memory the memory we divide it by regions because the way to prove memory is that you sort the memory. So you sort the memory and then you proof individually each of the each of the address all the reads and writes and because they are sequential then you can prove it like with a single register. Okay. And then you switch the memory address you get in the register. That's the way you can proof in a state machine.