ZisK: Pushing the Limits of Real-Time Proving - Jordi Baylina

Transcript

[music] [music] >> Thank you very much for having me here. It's an amazing venue, by the way, and >> [snorts] >> amazing conference. So, let's start this. Before going a little bit deep in what we are doing in this, I would like to share with you how I see modern blockchains. I mean, how So, what why I tend to think about uh uh blockchains in the future, okay? So, blockchains um since the last years were separating

what's the data and what's the execution part. So, if we understand blockchains just as data, um we can just check. I mean, it's a ledger, it's a public ledger, it's a humanity ledger. If you want to see place where you can register the logs, I mean, you cannot go back as an as a ledger, so you just register those things, okay? And this itself this becomes like a true. You can understand a database that's increasing its data its data only.

And probably that's very much what you need. So, on these ledgers, I mean, if you take all these all these data, for example, in in in a normal in normal blockchain, these data used to be transactions. And we can do picture I mean, we can do pictures. We can do queries on these data, okay? So, these normal queries I mean, is we can uh and for example, from these queries, we can deduce the state. We can I mean, if we take all the all the Ethereum transactions, we process them deterministically from the beginning, and actually we could calculate I mean, what's the current what's the current balance of my account or what's the

whatever it's the we we know unique things of the state, okay? There were at the beginning of the blockchain so remember some some chain some I mean the old people some some of them one some of them called there was one that was called Factom something like that that was very much that just you just put data and then the way you read this data, the way that you interpret this data that's not it just needs to be like a consensus but it's like it's something that's already known and if we agree in how we read this data, we don't need we don't need much more than that.

Okay, so these queries we can actually compute the queries. The problem of a blockchain like that that like that is that everybody that connects to a blockchain and wants to know the data, they need to synchronize from the beginning and they need to interpret all this data. Currently with zero knowledge we can do those queries much easier. I mean we can do the query somebody maybe computes that's data but they can create a proof that the concrete um result of this query is correct. And not only that but I can do queries of a queries and queries of a queries of queries we have this recursion. I mean this tool of I mean you're doing a query of a state you prove the state and then you get to

create another proof that verifies the query of a query, okay? So if every time that there is a new block we just compute the new state and we can compute a query and we do have the this state, okay? So this is this idea of we can separate the idea of um >> [snorts] >> we call that dynamic consensus and static consensus. Static consensus is what Okay, we agree we don't doesn't change. It's something that's fixed. It's something that we are we we this is the way that we read this data, the way that we query this data. This agreement that we have that this data means this, okay?

And dynamic consensus would be like the the the mean is the data that in every block is happening, okay? So, we need the blockchain when we want to change this this consensus. Okay, so when there is something that something that changes, we need to reach a new consensus here. Okay? Now, Forex Well, we need blockchains for Forex because it's kind of a dynamic. There is a part that changes, so we need to somehow signal somewhere that this is a new the newest state. Okay? And moving forward to this concept, I mean we have transactions, but we can have other things. An example, for example, is linking this with a with identity. I mean, I can have transactions, but I can have attestations or information, other things that related, and we can read

this data in a in a in a specific way. Okay? And all this is possible thank you to this zero knowledge because we can prove these things. And when this uh and when we can generate these queries that are complex and we can generate them very fast, this model becomes more useful. Okay? And this is the the the things the vision that I'm I'm we are seeing on that. For example, another example is I mean, we we we are applying a little bit this this concept in in in is it in Ethereum Economic Zone. But the idea is when we have many rollups that interact one each other. Here we are talking only about rollups.

Um So, if we just put the transactions of all the rollups in this chain we can query I mean, we can deterministically um execute those transactions even if they touch different rollups. And of course, we don't will not have one state. We will have a one state per rollup. But the the uh the the result, the state of each rollup is going to be deterministic. Of course, maybe one transaction is going to touch one of these difference, but the only thing we need in order to do synchronous composability between rollups is just put the transactions there and read them.

Okay, so you see the the whole portal full this this this can be. Of course this is more complex because we have also layer one and of course this state they can change. But as idea I think it's interesting to see to see this. Okay. And finally well I want to mention I don't want to go deep here but want to mention that this model also work with privacy. The difference here is that well the difference here is that this state is somehow encrypted and then you need to have a way to encrypt the crypt. Here there are some technologies but they are not available. I think the next next next talk is about obfuscation and something that is very promising but using obfuscation and so you can have

all this all this model but with privacy in mind. Okay. So Why and then let's talk a little bit about Zcash. Well Zcash is just a ZK VM. It's a ZK it's a ZK VM. It's just a well how you create this proof. I mean how do you do this queries? You do this queries means that you need to execute them and you get some data. You need to execute something deterministically and and then you need to generate a proof. Okay. So this is Zcash it very much helps a lot here. So Zcash is just a program that where you can write any program in Rust or in C or any normal language and you just

generate a zero knowledge proof of this of this computation. Okay. And it's open source. It's fast. It's secure. It's 128-bit security. It's quantum resistant. Uh The idea is to audit and to formally verify verify that and I mean it scales very well. I would say it's one of the top levels libraries in in in in in the current day. But probably the the main I mean the main [snorts] property of ZK is that it was designed with latency in mind. I mean, they they used to be able to generate these proofs as fast as we

can. Of course, also as cheap as we can and with as performance as we can, but the main priority was to do it fast. And in this presentation, I'm going to talk a lot about how So, all the things that we did in ZK to make this proof as fast as possible. Because when we want to have information, we want to know fast and we want to have this information fast. When you have a when a block is mined, we want to have a proof of that block as soon as as possible. We will see that for many applications, this is this is important. Of course, this has a lot of other applications, but all of them they have in common that you need to do them fast.

Also mention that um in ZK is uh I mean, it's not a new it is not a new project. Well, at least it's not a new team. It's a team that we have been working uh now about 5 years already in zero knowledge. Um Um I mean, we built Hermes, we built Polygon, ZKVM. We have been running. Uh we end of the few one of the few teams that they have been running uh uh ZK systems in productions for many times. So, and we have a lot I mean, we collect a lot of experience in the last years. Okay, so then ZK is the evolution I mean, is the the evolution of this team that's I mean, it's like the cutting edge technology uh

uh of the of the of all the learnings of the last uh those those years. Okay? ZK is um I mean, if you see check at the architecture of of of ZK, of course, ZK is a is a Rust uh is a RISC-V uh VM. Okay? But, this RISC-V VM is built on top of a uh of a uh generic ZK system. It's the the the proof man. And this is all all the limitation is written in in Pluto. It's a specific language for writing arithmetic. That allows us to make a so all the secure things. I mean all the arithmetic is compact in a very few um lines, of course, that can be easily audited and it's very very specific to

that. And on top of that, we have the recurser that's um a package. I mean, it's a framework that allows us to uh aggregate um proofs and to introduce just generate a proof of proof or a query for another query. This allows you to do it automatically and in a very easy way on top of on top of Zcash. Okay? Um if we go a little bit deep, how how what's the the core part of Zcash? So, the idea is that the idea of the main the the the the the important part of Zcash is that when you have an a huge query, I mean, you have a mission of program that's quite long, we have a way to divide the problem in many problems. Actually, it's a big proof and

we divide it in in sub proofs or in in in chunks of proofs, okay? And uh so, and then we we we can do those sub proofs like in parallel and then we aggregate those proofs in a big one. Actually, they are not regular proofs because all these proofs are built in parallel in the same transcript. This allows us to connect one each other, but this is what allows us to to to distribute it. Okay? And uh we have a we we we separate for so, we can, for example, have an execution and we can divide the execution in chunks, okay? But also, we we we separate that functionally functionally. I mean, we have a a specific um uh circuits that are for the RAM, others

are for arithmetic operations, for binary operations, for catch-ups, for hashes. So, we have a very specialized uh uh circuits that you can do bunch of operations of a single kind, okay? And then we join them together in what we call a kind of a bus, okay? So, the idea is that all these circuits they connect one each other. I mean, they from one circuit builder, they can send like message. Actually, they are not really message. They are things that are assumed in one side that you prove uh uh in the other side. So, you have only one circuit, for example, in the main machine that you are assuming that one multiplication is correct, and then you have another circuit that actually is proving multiplications so that and you have this bus that says, "Okay, the

multiplication that you assume that was correct here, actually you are proving that's correct in this other circuit." And this all these SC machines they connect through this through this bus, and at the end we just check that everything is is is is is proven. Okay? Well, this allows us to do uh different different This bus allows us to do different techniques. Um going to jump this a little bit, but uh yeah, this is the the core of the of the bus, okay? But, let's go to the different techniques that we are using in order to make it fast uh with low latency. That's very much the goal.

So, the main goal of this uh project in the last 2 years that I have we have been working currently okay? So, when we have a um a proof, I mean, we would generate a proof. Well, actually, we we we have an execution, okay? Probably, in this execution sometimes we have to uh prepare uh that execution. For example, if we want to prove an Ethereum block, well, first there is a preparation. I mean, maybe we want to extract from an Ethereum client, we want to extract all the stateless uh uh witness. I mean, it's also all you need to all you need to do to prove uh a block in a stateless manner, okay? So, this would be like a

pre pre process, okay? We have the execution itself. I mean, if you want to prove an execution, actually we need to execute. We cannot prove an execution without executing it, okay? So, that's one of the basis is executing it, okay? And uh this execution in the case of ZK is in RISC-V. So, the first one of the first problems that we have is that okay, um one of the bottom the first bottleneck is like okay, if it's RISC-V, I need to execute code in in RISC-V. And I will not be able to prove faster that the time it takes to prove.

Currently, the system is monothread. There are techniques for doing multithread, but the idea is monothread, so this give us a limitation. So, the first thing is how we can uh execute RISC-V code uh fast, okay? Once we have this code um executed, well, the idea is that we divide this work. So, we have a kind of a quantum plan. The idea is we we do a strategy, okay? We're going to do so many mains, so many binaries, so we are doing a plan of how many proofs to prove we're going to build, okay? And then we in parallel we build all those proofs, okay? These proofs are has in general two parts. One is the what we call the witness computation. This is a part that's if

you want is a part that's done in the CPU and another part that's on the GPU. That's the more cryptographic, mainly entities and and mercurization. For a STARK, that's very much what we're using. And once we have all those proofs, well, there is a final stage that we need to aggregate them. So, we need to join them. So, we take two proofs and we convert them in a single proof. It's a then it's a recursive circuit that it's a proof that's proving two proofs. So, we we start with two proofs, we have one, and we just do kind of a tree, and we have a final proof. And a lot of times is this is a STARK, if you want to prove it on chain, we may have a last state that it converts it to a STARK. I mean, we just it's a proof it's a it's

normal Plonk or a normal Groth16 proof that actually is proving a stark, okay? So, at the end we have a a proof that concentrates everything here, okay? So, what can we do here, okay? Well, one of the techniques that we are doing is for example, well, in the in the first two stages, the first thing is okay, we can do all these preparation, we go to the Ethereum block and so on, and then start execution, or we can do it a little bit more smart. So, the idea is that we can do those things in in in a pipeline way. So, we we are preparing and while we are preparing uh the proof, we are already start executing that proof, okay? So, this pipelining the inputs. This is one thing

for example that if we are planning to do a latency, we we we can do it we can use this technique, okay? And here we have like a good reduction uh for for I mean, for proving blocks in in real time, this is an important Well, this is one of the things that you can you can do. Another thing that another technique that we can do is Well, RISC-V I mean, RISC-V Well, using execution, we have a when you're executing one of those things in in a in a serial way, you have like a lot of pieces of the code that are quite repetitive, okay? So, for example, we call it pre-compiles. For example, here we can have hashes or we can have a

signature signature verification. So, things that are very concrete and very parallel. Well, one of the things that we can do is okay, so instead of executing everything in the RISC-V execution, the idea is that we can have a native execution done in in in in in Intel that's just um doing this um it's like a kind of helping the RISC-V execution. So, the idea is okay, you are pre-computing all these uh I don't know, these uh EC recovers or these hashes or these uh paintings things, okay? And when the the risk five is having to

execute that, it will give him the result already. I mean, it will pre-process. It will help them because then at the end this is going to be maybe proven in another pre-compile. So, the risk five does not need to execute there. So, they they they can hint them. They can send hints and and so, overall, then the execution can goes faster. Okay? Another thing to do I mean, if you see here, you see that most of the work in a proving system can be parallelized. We can build this thing in parallel. But, there is this execution part that's harder [snorts] to parallelize. So, the idea is that we want to um start parallelizing as soon as possible.

So, we want to have an execution and we we need to split this execution in multiple executions so that we can start using multi-process as soon as as soon as possible. So, one of the techniques that we are using while first, this execution one of the things that we are doing is we are transpiling this execution to uh so, we we convert the risk five assembly to Intel assembly. The code that we're executing is actually the same. So, and this can I mean, this transpilation this allows us to execute risk five in around 2 GHz, which is very close to the uh clock speeds of Intel uh by there, okay? So, it's a very optimal code, okay? But, we want to parallelize we want to parallelize that. How we

parallelize? Well, the idea is we execute that normally, okay? But, what we are doing is um we are storing I mean, the idea is that every time that we are doing a read of a memory, we are just um creating a lock. Every time that we do a read, we are storing this lock. So, the idea is that then we can execute all these chunks again, but in the set of having memory, you have this lock. So, when you need to to read something from the memory, you get this lock. Writing to memory, I don't care about the memory. I don't have memory. Okay, I already did it the first time. Okay? So, this allows us to do a first pass, a first execution of the code, creating this lock. And from there, I can

have different chunks, and I can run in multiple processes, and running it in in in in in in parallel. Okay? And from there, I can do the witness computation and the and the global. So, this allows me so in executing, even when I execute the first chunk, I can already start computing the witness computation of that chunk. Even while I'm executing the first time, I'm already uh starting to uh compute the proofs for this uh given chunk uh uh in parallel. Okay?

So, so from here, we go in parallel. Okay? But, this is this works in the single machine. Okay? But, the idea is that we can do the idea in multiple servers. So, because we want to to build that fast, so we want to parallel not in one single server, but in many servers. So, the strategy here is that this execution we are not doing once and then distributing to the servers. We are executing the same thing in all the servers. So, all the servers, they know what they're going to do. And then the parallel part, each server they already know in a deterministic way. They don't even need to have to communicate which

are in this strategy, which which piece they are going to they are going to uh uh have to execute. And the first server is going to do maybe the first uh chunk, the second chunk, and maybe this first chunk of the binaries, and whatever. And this is a deterministic uh uh distribution. So, without communications, all the servers can be done in in parallel. Okay? So, we can have This is uh one of our clusters that we have in in Girona. So, we can have like many machines working together.

All of them they are I mean doing the execution, but each one is doing each each of the each of the each of the of the pieces. Okay? And maybe one of those or one of those is they are finally aggregating all of them. Actually, the aggregation the technique for aggregation, they don't need to follow a specific pattern on the tree. They can You can aggregate to prove no matter the first comes first aggregate, and you can use different servers. So, the aggregation is really fast. Actually, the aggregation circuit is very optimized. It takes less than I think it's about 80 85 milliseconds one single aggregation and can be done in parallel. So, aggregation is very very optimized in the case of in the case of Zcash. Okay?

And it's important to see that the interactions uh between the servers and if you want the what would be a coordinator are absolutely minimal. Because I mean you have the input you get the input of course you need to broadcast the input to all of them. All of them execute. Each one already knows what they have to execute. There is a couple of There is a couple of interactions a couple of back and forth. Um because I mean this this I said to you these proofs are built in parallel. So, there is they need to have a single point is a single challenge that needs to be broadcast. And then the aggregation part. So, we have a lot of proofs at the end. A lot of proof at the end. And then all this needs to be aggregated at the end. But, the the

important part here is that the the bandwidth between the coordinator and the server is very low. And this allows us for example, so Zcash is very good if you want to build this proof in a decentralized way. I mean you can have three servers in Asia and another in Europe and another in America. Uh and the latencies will affect minimally in the proof generation. And this is because you don't really need a cluster to build a proof. You need a set of computers coordinated, but minimally coordinated from the network. Okay, so this is one of the important properties of of this.

Okay? And of course, at the end we have a this PlonkWrapper, which is optional, but if you want to prove this on chain, then this is well, we have this piece already done. Currently, it's it takes less than 2 seconds, and there are some margin here to to improve. Proving that on chain is about 150k. It's Plonk, so it's not costly. You don't need a trusted setup. Well, you need a universal trusted setup, but it's already there, so you don't need to worry about building a ceremony and so on. And it goes relatively fast, and it's 100% available. As I I told you before, it's everything is open source.

Okay? And on top of that, we have also the recursion. This is where we're working hard currently on documenting and making it more available, but everything is written already. So, the idea is that you can have two independent proofs or three independent proofs. For example, you have a proof of two blocks or three blocks, and you can aggregate them in a single block. And this is it's a different concept. It's one thing is like inner aggregation. So, if we have a building a single proof, that's a split it in there. But once you have a the proof, you can take another proof and and aggregate them. Okay? So, you can have two real proofs, and then technique is very similar, but you aggregate real proofs, and you can aggregate them using the using the the the the recursion. Okay? Some

benchmarks. Well, you can you can check it in F proof. For example, there we have some clusters running. Uh, but uh I mean, what's clear is that proving blocks in real time is is is is is a fact, actually. These are the numbers. Uh, 97 96%. This is with uh uh I think this is uh uh Girona cluster is 16 GPUs. In Sevilla we have 24 GPUs. This can go lower especially for the clients. Clients are getting better and there is some margin to improve uh with the clients. But what's clear is that they can they we we are talking about in the order of few seconds to generate a proof. Actually

for for easy for Ethereum economic zone, there is one time that's really important. I mean it's like So, if you are building we have this composer, this bundle. I mean we are taking transactions of different chains and we we need to build a kind of a a bundle with all these transactions that do all these cross-chain communication. Well, the idea is that while you are building this, you can already start building this proof and the idea is this time. I mean so since you finish the bundle until you get you get the proof available, how long this takes, okay?

And this is very and this is it's a below uh below uh three below three seconds currently and there is margin. And this is what allow us to actually to make easy easy possible this low latency. You see you can you you need to you can only build those proofs when you already have a block and you have only 12 seconds to do all this. So that's why you need this low latency and this becomes uh super important. Okay? Last thing uh uh well, we are current state of ZK's I mean it's uh everything is I would say it's finished.

We are currently doing some clean up uh of the code. We expect to have a version 1.0 um the first week in the next next weeks. Um it's going to be probably it's going to be a 1.0 beta because of course here there is a lot of security and things that needs to be run. And also we are working hard on the formal verification. But currently um if you are a user you would not notice anything from what would be like the final version for for at least for six for for the recursor here there is some work that we are still working but if you are just doing normal proof I fully recommend to test it it's really easy we simplify it a lot all the

installing and all the user experience for that okay and that's very much what I wanted to explain today thank you >> [music]