Pico Prism 2.0: Real-Time zk Proving at Scale

Transcript

Cool. Thank you very much for staying through. This is Alan from Brevis. I'm going to talk about our recent updates on our ZK engine called Pico. Specifically, we are going to be releasing the second version of Pico prison. It's going to be proving the real-time ZK at scale. We all know that blockchains are world computers, but it cannot run than a single server and it is extremely expensive. And the reason behind it is that we have this consensus issues. So, consensus today is built on simple recomputing. So, what I mean by that is that for example, here is the computation I want to prove.

Prove the validity of this computation and here's the Alice and Bob representing like two nodes or even more. Now, Alice wanted to do the computation and to show show the every node that this computation is correct. So, she spends some computation power and get a result and then now say, "Okay, this is the computation I've done. Here's the result and everyone should believe in it." But how come that Bob believes in it? How do they know that if it is real? They do this they do this kind of the so-called verification by recomputing. So, essentially, he spends the same amount of computing power and then do the same thing, right?

And then after that, he is kind of convinced that, "Okay, this is the correct uh he has verified this is the correct computation." So, essentially here, the consensus is achieved by the verification and the verification is achieved by recomputing. So, imagine that only if you have like only one node doing the swap, then it is fine because you're just doing this computation one time. But there are millions of nodes online so that you're going to be doing this exactly the same computation time after time up to like a million times if if not more. So, this is very wasteful.

And then what we propose for solving this kind of problem is the so-called verifiable computing, which is closely related to zero-knowledge proofs. So, instead of Alice doing the computation of the original computation, she will actually do the proofs besides the execution of the original program, which is now is the simple multiplication. So, here the proof is actually saying that, "Okay, I'm proving this program, which is the multiplication, and here's the input 142 and 121, and here is the result." He's packing all of these things into a zero-knowledge proof and then he can she can do the computation offline, off-chain, whatever whatever computing power she is using. Of course, this will

cost more than simply computing the original one. So, we have like more computing used, but I think it's like once she she sends this to the Bob >> [snorts] >> and the Bob do the verification, he's somehow convinced that this is the correct execution of the original original program. So, this is called a verifiable computing. The good thing about it is that Bob is only spending a very tiny amount of computing computational power here to do the verification. So, essentially, what happens here is that originally, the computation is is just equals the verification, but now we are decoupling the verification from the computation. So, essentially, we can do computing computing somewhere and then do the do the verification

somewhere else. And the good thing about it is that we just do the computing for one time and then verify it a million times. The thing is that the cost of the verification is just so small so so so small so small. There are many other benefits that we could bring. For example, the privacy and this one is also good is that originally, we only have this multiplication as a simple program, but the the program or the or the computing could be very complicated like like inference of a large language model.

So, this as you can imagine involves a multiple GPU machines to do like several seconds or like minutes of doing the inference. So, doing doing this recomputation is almost impossible. But now, with this but but now with this verifiable computing, we can just prove that this LLM with this specific input is having this output. And then what good it is about is about about the proof is that verifying the proof, no matter the what the original computation power computation workload is it is, they cost exactly same computation. So, it's still very tiny. It's it's like a constant thing there. So, that is to say that whatever computation thing we have

computation workload we have, we are paying the same amount of computation for verification on chain. So, this allows us to scale the the the the computation on chain almost infinitely. There's also something else like privacy benefits. For example, this is still that something that we want to prove, but then um Alice is saying that, "Okay, we are hiding hiding some part of the of the input. Say that we don't have this the 142. We have only 121 and the the proof is actually showing that there is some input [clears throat] that I multiplied with the 121 and here's the result." So, now things becomes totally different from the

original scenario where we do the recomputation because now we don't have the input. There's no way to do the recomputation to do the verification, but now with the zero-knowledge proofs, we are able to do that. What does it bring? It brings us the privacy benefits. We don't have to show everything to the to the other nodes. We can hide something as a privacy thing so that even even if we hide something, they can still verify that this is true. Okay. So, so many benefits bring us to the conclusion or the prediction such that by the year of say 2035 or even 2030 to be more aggressive, 99% of the computation for blockchain applications is going to happen off-chain and verified by ZK proof.

However, there's a drawback because ZK is very complicated. So, I'm not sure like how many of you have handwritten some circuit ZK circuits before. Anyone? Yeah. It is very complicated. And here is just a very simple snapshot of of our engineers writing Halo 2 to prove a Fibonacci Fibonacci computation. Like two pages, hundreds of lines of code. Very complicated. You have to understand the Halo 2. You have to understand ZK knowledge zero-knowledge proofs and you have to write this code out. And it's also very hard to audit, right? I guess like many of you have already gone through this process before.

Basically, two solutions towards this kind of thing. First one is the ZK coprocessor. What is ZK coprocessor? It is essentially a set of handwritten circuit specifically for specific set of applications. For example, there's a zero-knowledge zero-knowledge machine learning, which is specified for machine learning applications. There's also data availability availability applications. So, DA thing. So, we can write a specific set of circuits for that. It is blazing fast, but it's limited generalization because every time you have a new application, you have to write a new set of set of circuits and it's very hard to audit every single time. It is tedious to develop.

Another solution is called the ZK VM. As you can tell from the from the from the name, it is a virtual machine. What we are essentially doing is to write a plain code, whatever code like Python, Rust, Go, or anything else. We compile it to say RISC-V, a specific set of like instruction set, and the by opcode by opcode, we translate it or compile it into a ZK circuit. So, it brings us a high flexibility because basically, anything that you write, you can directly compile it into a ZK circuit and then do the proof. And it is very easy to develop, but there has the performance overhead here.

So, yeah, there's many challenges here. I just to mention a few. Basically, every like currently, many of the ZK VM existing or ZK coprocessors are one-size-fits-all solution will be inherently limited. All right. So, that's why we proposed a Pico starting from last year. I think that last year at the same time like this year, exactly one year ago, we proposed the first version of Pico on CPU. It is very flexible and the future proof. It has has the modular architecture with interchangeable proving backends and customizable proving workflows.

It is it is very performant. It brings the modularity to a new level where we have the so-called both function level and application level coprocessors or precompiles. For functional functional level ZK coprocessor like precompiles, we have all kinds of cryptographic primitives or computations written in a specific chip or precompile chips. For application level ZK coprocessors, Pico is able to connect with any other handwritten ZK circuits like ZKML or ZK data availability. We have shown that it is possible where the Pico is working as the glue and coprocessor is working as a specific circuit that is very efficient

for specific applications. It is very developer-friendly, of course. You're just writing applications with the language that you are most familiar with. Yeah. So, Pico requires you zero ZK development experience. Right? So, now you just this is the same thing that you could be could be could be proved by Pico to generate a ZK proof. And now you only write like less than 20 lines of code in plain Rust. So, it brings a huge benefit for us that to develop.

Maybe not us, uh but also our AI agents. So, Pico democratizes the technologies. So, it is encapsulating all the complicated computations behind the scene so that you can just uh call it by some simple SDKs and then you get a ticket proof out of it. Here is a showcase of our our new application that is built upon upon Pico called Brevis Vera. Uh the motivation of that is that nowadays you can see that many images, videos are generated by AI. We cannot basically tell or even AI cannot basically tell which one is AI generated or not, right? So, um but it is possible that we using we use the ZK proofs to prove that which of the images or videos

are actually directly from the from the raw devices or have gone through uh some legal edits. Uh here is the some video that I can show you. In the age of AI, seeing is no longer believing. A photo used to mean proof. Now it means doubt. Using AI to detect AI is an arms race you never win. Don't ask if it looks real. Ask if it can prove where it came from. Introducing Brevis Vera, reality attested.

Brevis Vera starts with a signed hardware backed capture. It then proves the edit path itself with zero-knowledge proofs. Now you or anyone can verify that what you are seeing is real. Brevis Vera We show you the proof. All right. This is the marketing material but what basically >> [laughter] >> happens behind the scene is that modern cameras and many smartphones have this so-called signature uh related to the thing that they generated at the moment of the capture.

So, if you take a take a photo of your smartphone smartphone and some of the smartphone like Pixel is having this a standard called C2PA. It has a signature that is actually proving that this image is directly from the device. Right? So, this is a thing. But second thing is that there some many many of the times we want to do some edits like just a cropping, doing rotations, changing the brightness, all these kind of things. Um Yeah, some of them may change the content of the of the of the image but we can still prove that we have just a written out a raster package out of it uh stating that all the things all the edits done by Rust applied to certain kind of image that is

generated by these smartphones or modern cameras are valid. Right? So, basically we have the ZK proof that okay, this image this input image has gone through a certain number of edits, legal edits and then this is the output image. This is one thing that we could prove. Second thing is that this input image is something directly from the device. By combining these two proofs together to get a one proof, we can after we verify it, we can know that okay, this is a this is a image and this image is not generated from air by AI but is generated from some devices.

Although it come gone through some some kind of edits but it's still something real instead of just something from the same air. Okay? What is fascinating about it from us is that um as I have mentioned that you you basically have have no idea you don't have to have any idea like what happens behind the scene but you just use it by calling some SDK. The other thing is that it's very AI friendly. We have made it try to we try to make it so AI native so that AI just reads the whole thing and then just just try to avoid wire everything into the Pico so that with just one week of work we just we just delivered the POC of Brevis Vera.

Right? So, building ZK apps has never been such easy. Okay? So, this is the application that we have built recently and we are trying to make it a serious production right now. There's also another series of series of application where we will try to prove prove that Ethereum mainnet blocks execution in real time. Uh I think it's about 5 to 6 months ago we will release the Pico Prism 1.0 to prove the Ethereum blocks with accessible and consumer grade hardware.

All the things I have just mentioned is done on some Oh, I think this is uh Whatever, this is something that is outdated but anyway. So, yeah. So, uh we have uh Yeah, anyway. So, um uh originally we are doing this kind of proving on the CPU but turns out that there are many uh computations that is very heavy and could be shifted to GPU. That's exactly what we did for the Prism Pico Prism 1.0. Uh we basically uh used 64 GPUs distributed on eight machines and each of machine is handing a part of the proof of the originals of block original blocks. For at the time at each of the

block has the gas limit of 45 million gas and then we divide them into seven sub blocks and for and distribute them into onto each machine. Each machine is handling one sub block and there are seven sub blocks here. After after computation we have seven proofs and then there's a machine there called aggregator that tries to combine all these seven sub sub proofs here into one. So, it is essentially divide and conquer thing using sub blocks and each blocks is divided into seven parallel thing and it can be can be proved in parallel.

Right? And here's the results. We are happy to announce at the time that we are able we are actually one of the first to do this kind of proving to approve that 99.6% of the Ethereum blocks is able to be proved under 12 seconds with 64 GPUs, right? And the 12 seconds is just the Ethereum Ethereum mainnet block generation time. And on average is actually even better is like less than 7 seconds. So, on average even within 7 seconds we are able to prove the Ethereum blocks.

This is not enough of course because 64 GPUs although it compares although it's nothing compared to current AI applications which uses like tens of thousands of GPUs but it's still something that individual or individuals cannot afford. It is not good for the decentralization. So, following the Ethereum Ethereum Foundation's criteria for doing this real-time proving we have just reduced the computation power required to do the real-time proving uh from 64 GPUs to 16 GPUs which is just a 16 25% of the original computation power that we want to use. And then the >> [clears throat]

>> the whole architecture has been rewritten. Instead of doing this sub block thing uh divide and conquer thing what we did is that we have two machines each of them having eight GPUs and then we have a global scheduler. So, the global scheduler is essentially working as a task board uh which is indicating that which chunk or which task has not been done and these tasks could be fetched by each of the machine. And we have to we try to maximize the data locality such that if machine A has the corresponding proof then doing the recursion it is better happening on machine A as well and the same so as machine B. There's also some other optimization like up ahead of time computing compiling a compilation where

because originally the emulation is kind of interpreter based so it's very slow but now we are just a compiling it into native Rust and then do the do the execution on top of that so it's just becomes becomes super fast. So, with that we are maximizing the parallelism. There are also some other things. I think I'm kind of running out of time but I just want to mention some of the few. Um the CUDA code optimization because it turns out that we are able to greatly greatly increase the efficiency of the CUDA code by doing many kind of very small optimizations. For example, here doing the fry open thing we have this Montgomery batch inverse which requires

you to have like multiple reciprocal computation for individual values. But what we did here is that we do them first by multiplying every every single denominator to get a huge multiplication and then after that we use this product to recover the each of the reciprocals. So, in that way we are only just doing one reciprocal with multiple multiplications but the thing is that doing a multiplication is just a so much cheaper compared to the reciprocals. There's also a shift from the instruction set that we are supporting from 32-bit to 64-bit. It means more chips to us something more related but it means a fewer cycles. So, it's

basically a trade-off between the efficiency and the effectiveness. Um yeah, so a trade-off on efficiencies but we found a small a small sweet spot such that we can achieve the best efficiency on top of them. Uh we are also doing formal verification with another minds so this is on the way. So, this is the result. It's not only about like using 1/4 of the of the computation power to do the proving but it's also like compared to what we originally have which is gas limit of 45 million. Now we have 60 million, right?

Maybe next year we will have like a 120. But the thing is that the the workload is also kind of increasing. So, using the original 64 GPUs we will have the average running time proving time for Ethereum blocks nowadays for more than 8 seconds, but now we are just only having the uh 6.6 seconds. And what is more is that we are proving more than 99% of blocks under 12 seconds as well. So, in total, it would be more than 10x of acceleration compared to what we have uh uh using 64 GPUs.

All right. Finally, uh Pico uh Prism 2.0 will be able to prove arbitrarily large workloads because, as you can imagine, this uh this scheduler, global scheduler, and the worker architecture uh is could be uh could be embarrassingly parallelized. So, any kind of workloads could be distributed upon that. Um Pico Prism 2.0 is going to be open source, maybe next month or some sometime later, uh but it's pretty soon. Uh Pico itself is fully audited and ready to be used in production. So, finally, uh welcome to use Pico and build with us. Thank you.

>> [applause] >> Uh yeah, thank you. Um nice talk. Um Could you just clarify what a sub block is? Is that a Is that a chunk of RISC-V instructions, or what is that exactly? Oh, yeah. Uh the original Ethereum block is the whole block with uh tens of different transactions, right? And then the sub block, what I mean here is that we are we are dividing these transactions into uh some some smaller blocks and assigning this uh For example, originally, we have like a hundreds transactions. Uh we have maybe we can just uh pack 20 of them as one sub

block, which is is is essentially a part of the original whole block, and then send them to the one machine, and the rest of 10 uh to the other machine or something like that. We are capping them uh capping the gas limit to be 1/7 of the whole uh total gas gas limit, and then, yeah, do the parallelization there. So, do you you actually do that before um before it goes into the RISC-V? So, you're actually splitting the transactions at the kind of like Ethereum block level before you even go into the RISC-V. >> Yes. Yes. Yeah, exactly. We are actually doing that uh to to prepare the corresponding input. So, basically, we have eight inputs, seven for different sub blocks, and the one for aggregation.

But originally, directly proving the whole block would just require one input. Thank you. Yep. Thank you very much.