# Zisk, zkProving in real time

- Channel: [Dappcon](https://streameth.org/dappcon)
- Date: 2025-06-18
- Duration: 23:46
- Watch: https://streameth.org/watch/6852e30c90bd41297bbae0fc

## Transcript

Well, hello, I want to talk today about Zisk. Zisk is a project that we have been developing inside Polygon, and it's very much what we call a ZKVM. I mean, it's a ZK prover where you can build circuits using a high-level language like Rust. I mean, it's, let's say, the modern way of writing ZK circuits. And today, here in this stage in Berlin, I would like to do a really important announcement that just happened last Friday, and it's that we are spinning off Zisk from Polygon. So we are becoming an independent and free project. We are a team of about, a team of seven developers, plus myself, and we decided to keep this project outside 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, let's say, wants to be focused more in the aggregation layer and in Katana and other products in the high-level, and they want to be free to choose any ZK technology that's available. I mean, they don't want to be committed to a specific ZK. And in the other side, from the Zisk 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, because we can start being in the space of the provers, competing, we are an open source, I mean, I don't like even the word competing, but at least being in the space and working in the space for having a better ZK-proving systems. We, as I mentioned before, we are a set of eight persons. I mean, we move out of Polygon. We took all the intellectual property, all the knowledge. We have been developing this as a Polygon harness, the Polygon ZKVM. We took all the knowledge, all the know-how of the ZK. We have been building for the last two years, the last year is specific to Zisk, but for the last two years, the development of a new proving system, and this is the part that's spinning out. Okay, and as I mentioned, our huge commitment to being an open source project, this project is going to be Zisk, it's going to be MIT, SLI, Apache, and it's going to continue with that license, I would say probably forever on that. Here, of course, you can follow us. This is some credentials I will mention later on, but yeah, this is an important moment for us. We are very excited, and for this project, the team is very excited and very committed to this. I think that here we can advance. We already did a lot of advances in the space, the people that have been following us in the proof channel, they saw that we are already contributing a lot to this space. Why proving in real time is important. As I mentioned, the most important and most differential thing of 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, it's not only about minimizing the cost, but it's also about 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, 20 GPUs, whatever, but the idea is to generate proofs in parallel so that we can generate these proofs real fast. Why is it important this fast? Well, these are the main applications. Of course, if one of those is in the roll-ups, normal roll-ups, they will verify, they will have to prove that the state is valid, so that you want to do that fast. This is more clear, for example, in degradation layers. If you want to communicate any change, one to the other, you need to commit to a state and you need to prove that that state is fast, so that these funds can be used in the other chain, in this breaching, in this connection between chains. So it's really important that these proofs are generated really fast. Zisk was designed from the first day with that in mind, how much we can push this technology so that we can build this proof fast. We'll show you later in the presentation the numbers that we are getting together. But the goal is to be able to generate Ethereum blocks in real time, or even less, as fast as we can. And, of course, this technology is also very important for, let's say, new generation consensus algorithms. The Beanchain Ethereum is one of these examples that the ZK is used in the consensus algorithm, and this has become a really important piece. And for that, it's also really important to generate these proofs really fast and push it hard on this technology. Some properties about Zisk. As I mentioned, Zisk is designed from scratch to run in a distributed way. The idea is that we try to parallelize as much as we can, so that we can generate the proofs faster. There is one specific piece, one small piece, the execution itself, that cannot be parallelized, and we try to minimize that piece as much as we can. At this point, this piece is, let's say, 15 times faster than any other prover in the space. And on the other side, you have GPUs and everything is parallelized so that we can always put more resources to be able to build the proof in a constrained timing. We are at 128 bits. For me, this is really important. We can see in this space that, for example, there are some projects that are lowering this requirement to 100 bits and even lower in order to get performance. I think that we cannot accept that. The standard in the industry, even outside the world, I mean, in the world, is at least 128 bits. We can increase that, but we cannot lower that. We are sticking to these 128, and we are going to be hard pushing for these 128 bits. Zisk is also fully open source, and when I say fully open source, that means that we are open source not only the code, but also the GPU code, so everything of the development that we are doing, we are doing in an open way. We are a community project, and we want to keep this open source. I believe that in this space, there is no place for companies or groups that are doing closed source in this space. So here, we are fully committed to that, and that's one of the core values that we are pushing here. RISC-V is the only one in the space that's 64 bits. This is a design, it's a RISC-V 64 bits. Current compilers are 64 bits, and this is good, for example, if you want to create proofs, for example, in Golang or in C-Sharp, 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 from the optimal perspective to use 64 bits, especially when you do memory copies and other things like that. The other part that's important is that RISC is not just a ZKVM. It's really a full ZK prover that has one specific application that's a ZKVM. But it's a full stack for building proofs. So this, you can use it also for proving other things that are not a ZKVM, or doing other kinds of ZKVM. This is a full stack, and see that the proof model, if you want to prove it itself, this is based with a PIL2. PIL2 is an evolution of the original PIL from the polygon ZKVM. It's much more advanced, and getting all the experience of PIL, we just create this PIL2 with much better properties. We also have the recursor. We have all the technology for aggregating proofs really fast, and compressing that in a single proof. An aggregation circuit right now, it takes only 150 milliseconds, which is really low. It's the lowest in space. This is also an important technology that's part of the full stack of ZISC. If we look a little bit internally, how this works, the idea is that instead of having a big, monolithic proof, as we have, for example, in the first versions of ZKVM, here what we have is, we have a lot of sub-proofs. If you want to call it, we call it AERS. A lot of pieces, a lot of them are specialized, and then we aggregate all these proofs, all these sub-proofs, if you want, all these AERS, to a single proof. This is specialization. Of course, we have the main processor. This is just the care of executing, of verifying the main processor execution. But, for example, we have some other state machines, some of them, for example, that are focused in doing arithmetic operations. Some of them are doing it for K-charts. Others are doing it for binary. There are some of them that's taking care of the memory, the ROM. So we divide this, and the idea 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 proof, we may have two, three, four of them. So we can have as many of that. So we have this idea of variable proof, or a proof that can be as big as you want. I mean, we are not limited for a big hard-coded code. I mean, we can add more sub-proofs as we need. This is translated in a way that we... So if you want to create, for example, a bigger block, the result is that you may need to generate more of these states. So 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, the time generation should not increase, or at least should not increase substantially. So that's one of the important ways of seeing that. You see that this is quite a modern architecture. As I mentioned before, everything is based in a language for writing all the arithmetization. This is a PIL-2. It's very flexible and very competitive. This language allows us, for example, to audit the arithmetization in a very compact, in a very easy way. We saw that this is very... I mean, we got all this experience from the KVM, and this gives us very good results. So the auditor teams, they can focus in a relatively small number of lines to refine, because we have this language. But in PIL-2, we added everything that we missed to add in the first version. I mean, we are generating the constants inside PIL. We added, let's say, all the language for these multiple state machines. So we have all the logic for connecting all these state machines in the same language, and many other things that make this language... I mean, it's simple in some ways, and at the same time, more flexible on that. What else? Well, as I mentioned, the disk, when you have all these 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-embedded machine. I mean, you have a processor, you have a ROM, we have a RAM, and we have arithmetic binary. You can understand those if you want to scope processors that are handling certain operations for doing that. And the core part is what we call this bus. 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 LogApp. And the idea is, half of what we call this bus, is that when there is one state machine that wants to assume, for example, the main state machine is not proving multiplications. So when it has to do a multiplication, it adds something to the bus. This addition, what it does is say, okay, I'm assuming that this multiplication is proven in the right way. And on the other side, in the arithmetic state machine, what you are doing is subtracting from the bus. I'm proving, so what was assumed in the main state machine, now I'm proving that, so I'm subtracting. So everything that any state machine is assuming, there needs to be another state machine that's subtracting. This is done in two stages, so what you are adding and subtracting to the bus depends on a challenge, because you do a commitment and then a challenge, so you can modify. And at the end, the sum of whatever is in the bus needs to be zero. So everything that's assumed needs to be proven, and that means that everything that's added needs to be subtracted, so at the end, the result is zero. And this is the technology that allows us to connect all these state machines. An example of that is, for example, well, this is the different ideas of arithmetic. So this assumes it adds to the bus, and then the arithmetic is subtracted. But this allows us, for example, oh no, let me just go to that. This allows, oh, this is wrong, but in the case, for example, in the arithmetic, for example, one trick that allows us to do, and this is an example, is imagine that in the binary, we have some operations that are quite usual in the thing. For example, you are adding zero plus zero, or zero plus one, or one plus two. 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 operations in another state machine that they are hard-coded, so they are much cheaper to do, and you can prove it by doing that. So the thing is that they are subtracting to the bus this part, and you can select which one you want to subtract. The same thing happens, for example, with the memalign. The memory, so when the processor is doing a memory operation, there is one state machine that's subtracting the memory. But this memory is very optimized because it handles alignment, all the words of alignment operations, which is the normal operation that normal processors do. But what happens when there is a non-aligned operation? Well, we have another intermediate state machine that's kind of a memalign. So this processor, it's assuming one memory operation, a non-aligned memory operation. This memalign, some host host, it subtracts from the bus the memalign, but at the same time, it's having two new memaligns, so two new accesses to the memory that are aligned and then are subtracted from the normal memory. So this allows us to combine the things with this bus. The same happens, for example, for the processor. I mean, the processor, you can have what we can, sometimes there's continuations or linear continuations. You can divide the work in many chunks, so each one can be one proof. But how do 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 processor, and at the beginning of the bus, we subtract that from the state. It's a way of connecting these things. And the same thing happens with memory. When we have memory, instead of dividing that by the clock, 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 operation of another range is another state machine. And the state between ranges is also added and subtracted to the bus. I mean, it's not a time division, but it's an address division. But the idea is very much the same. It's using the bus for these internal continuations. These are the numbers that we are right now. You see here... Oh, this slide is... Got it. But anyway. So mainly we have four stages for generating the bus. One is this execution part. This execution part, we are really, really fast right now. So we are able to execute 1.5 GHz. Probably 2 GHz with, let's say, overclocked and other better hardware. But that means that... I mean, if you want to prove an execution, you need to execute that. But if you are RISC-V, you need to emulate that. So this is a little bit the limitation. So the technique that we are using that's very much about transpiling. I mean, we are converting RISC-V instructions to Intel instructions. So this is... We have a very, very, very high efficiency on that. So that's why we are able to execute this part that needs to be... That cannot be parallelized. This part is really, really fast. And here we are good. I mean, this is... We are... This takes less than one second. I mean, this is like this. But anyway. The Windows computation. This is the part that probably we are working more. This is the one that we put less loss in the last week. But we are working hard. These six seconds probably can be around two, three seconds in the next version. But this is... We get the minimum trace of the first execution. And we are now creating... I mean, we are actually writing all the polynomials that we need to prove. I mean, all the evaluations of all the polynomials that we need to prove. All this part is already in parallel. And in general, it's a CPU work. And this is running in parallel. Then we have the... There it's building. And it's a proof itself. This is built in GPU. And this is highly, highly parallelizable. Okay? And this is, of course, in the GPU power. This is where the real power is. But this is highly parallelizable. And this is seven seconds. But it can even be lower than that. And there is a final... Let's put it in the slide. But it's a final one that's aggregating all this proof. Okay? The aggregation... Or aggregating... Currently, I think we're aggregating three to one. So, aggregating three proofs to a single one. This just takes about 15... 15... So, 115 milliseconds. Okay? So, if you have 1,000... Let's say 1,000 errors, aggregating these 1,000 errors... This is log n. This would take about one second and a half. One second, one second and a half. Two seconds. To aggregating that. So, when you add sum up all together, you see that we are in the numbers of real-time proving. I mean, I think that we are currently... With these six seconds, we are maybe at 16, 17 seconds. But when we get better with these six seconds, we'll probably be below the 12 seconds that is 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 what we're working. Optimizations. Finishing pre-compilers. Here, of course, there is some cleaning, documenting, auditing of formal verification. This is important that we are working on. And yeah, this is where we will need some help. I mean, this is... We are a small project, a small team. We are focused in creating that. But, I mean, auditing is expensive. Generating the GPU is expensive. But we hope that with the help of the community, we can improve and get better on that. Okay? Come follow us here. We are going to... This is a public announcement that we do with this spin-off. So, we are very excited and hope that in the future, we can be a reference in the Z-gate proving. And that's it. Thank you very much. Thank you, Jordi. So, we have a couple of questions. If anyone has, we have some time. You can ask and we'll have a mic pass around to you. So... Yeah. Nice talk. I had two questions. The first one is about... When you split memory into several pieces, how much is every coprocessor? Like, how much memory does the coprocessor represent? And do you split it per region? For example, you know, ROM, code, data? Or is it just a section of memory, like a fixed size? When we are talking about memory here, it's very much about data. The code is what we call the ROM. So, it's a different state machine. So, data or RAM, if you want. That is the input special memory that's for the input data. But what we call data is data. And what we divide is divide by address. And maybe we take from zero to one megabyte. Or from one megabyte to two megabytes. We can adjust the size of these state machines. I think that currently is 2 to the 18 or 2 to the 19. But this depends very much on the hardware. So, we can do bigger or smaller. I mean, all these state machines are highly adjustable. So, the idea, I mean, the optimal part here is try to do the state machines as big as possible that they fit inside the GPU. This is generally the optimal. I say 2 to the 18, maybe it's 2 to the 22. But it's like, it's depending on the configuration of the hardware. We can adjust this so that we optimize the time and the cost for that specific 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 prove individually each of the address. All the reads and writes. And because they are sequential, then you can prove it with a single register. And then you switch the memory address, you get a new register. That's the way you can prove in a state machine that's proving the full memory.