Making Sub-12s ZKPs on Ethereum Possible With a New Builder–Prover Design

Transcript

Hello. Hi. Um my name's Neil Fan from Zcash. Sorry for the delay. Uh yeah, so in this talk I'll I'll show like from computation graphs to like uh production-level they can even notes. Like we did our uh like basically rewrite a lot of things like in the in the Zcash VM uh in the Zcash VM uh tech stack. So, the talk will be like uh three parts. The first is like uh we compare the difference between this like HAL, which stands for hardware abstraction layer approach versus our graph-based approach. Then the second is like we uh like our Zcash VM we named as like Vinash and right now is the the version number is 0.1.6.

We do some uh implementation of it on the different hardware such as like GPUs and also FPGAs. And then the third part is like how this like Zcash VM notion works. It should be like 1 2 3 instead of 1 1 1. Okay. Yeah, so let's first uh talk about uh like what is like HAL approach and then graph approach. So, HAL approach that we wrap around like each kernels like uh using like this like uh APIs and whenever you want to call this kernel, you just uh call the API and it will uh do the job for you. So, it's like which >> [clears throat] >> this like approach supports running the same proving uh structure like in

different hardware platforms. And the graph way is like sort of different. It encodes the whole process uh whole proving process as a graph and then you you do some like translation, you do some like coding regarding to this like graph. Uh yeah, and we can see like right now like the AI uh community you want to adopt the second part since it's like more fit to the like the GPU like uh architecture. But the Zcash uh community like we since like we start from Hello to Groth16, which is like pure like CPU uh execution and we usually just say like

um if you recall there is some like Zprize competition before where like people optimize the MSN, which stands for multi-linear multi multi-scalar multiplication and then like NTT like we optimize like using GPU or FPGA to optimize this like kernel since like in the whole process this kernels takes a lot of time. Uh but yeah, so that's like why like the normal like Zcash community like they start from the HAL since they they benchmark the process and saw like some parties like more time-consuming, so they want to optimize that part using some specialized hardware such as GPU and FPGA.

Uh yeah, so here is like a normal uh or like previous or like several Zcash VM like they how how the coding paradigm is like. So, you first um you like uh you do some um wrap around on the on the I mean on the internal core options such as like allocate your buffer or some other things. And then you build your like some some kernels such as like a commitment kernel or like the NTT kernels based on these like um internal calls. Then there will be like the third step will be like a a proof function which like a glue over all these like kernels together. So, that's like a

normal like typical Zcash VM a Zcash VM implementation paradigm is like. Uh yeah, if we want to use a picture to illustrate the process is like we have the say we have the like the uh the CPU which will first uh run this like build command. Then it will like a call the GPU to do a lot of things like such as like doing the commitment to evaluate the polynomial evaluate the constraints. There will be some like uh uh communication between the like the CPUs and the GPUs since like probably like you will use like the CPU to do the Fiat-Shamir hashing and all the other things. So, it's like this like stream line like each hardware will do their like corresponding job and then they

talk to each other. So, that's the HAL mode. And of course like we can saw some um disadvantages in this process. Uh it's like uh since there are like many kernels which will happen on the on the CPU and the GPU side, so it's very hard to optimize the kernels from this uh global perspective. And this like kernels they need to synchronize which with each other, which also takes some time. And and like more things like uh if you want to like start the kernel start some chip on GPU, it also takes some some time. So, which means like it's difficult to achieve some global optimization. And second Yeah, since second second is like we

treat things the HAL will treat the things like as a black box and there is some interactions such as like the Fiat-Shamir transformation and the IOP reduction, which remain like hidden from uh from the proving process. And the third one is like uh it's hard to uh translate or like rewrite the code like to some other platforms since like if you want to rewrite it to to like FPGA, then it takes really some time to do so. So, that's some like um uh disadvantages in the HAL approach. Uh and yeah, then let's move on to say like how the graph uh mode is like. So, to to like to warm this up, we usually to

implement uh the uh implement the the Zcash VM we have like three approaches. Like first is like direct implementation, which like you just directly implement the Zcash proving function in Rust in Python or in some other language such as like the the Glock or like the Hello to the the original Hello to me. And the second like there is some embedded like DSL into this like direct uh implementation. Yeah, so that's the the second layer. The so, it's like from shallow to deep. And the third one is like you design some like DSL such as like Carol or Noah like to encode the uh the like how the function should work,

how the So, but you need to compile it like into some other things to to make it work. Um yeah, so the HAL approach basically encodes the computation to be proved, but the graph mode will encode the whole proving process, which is like more comprehensive. Yeah, so here is like the uh we use a picture to illustrate uh the graph mode, which like the CPU will first compile this like whole proving process into a graph is into a like a deck. It's a pure data structure. And then like we run all these things on the on the GPUs. Like it will be like continuous like GPU execution, no CPU like round trips. So, like the GPU

doesn't need to talk to the CPU uh a lot of things, which means like we can achieve this like globalized uh optimization across like all kernels to make it like faster. And the the kernels they don't need to like synchronize with each other like to too frequently. Uh so, like in our design we have like three parts. The first is the circuit representation, which is like mainly used by the end user. We'll try to make it easier for the end user to to use it. And the second is IOP reduction. So, IOP reduction care about care about the correctness uh or the soundness of the uh of your Zcash VM.

And then there is a high-performance competition, which like we just want to achieve like as fast as possible uh for for for this kernel. Um yeah, so previously I would say like the the PL or Sercom PL PL2 like then they separate the circuit representation from the IOP reduction and like high-performance competition. But in our approach like we separate like all three things like. So, like each part will just uh care about their like jobs like don't need to like interact too much with other.

Uh yeah. So, here is the result like we uh our things built on Zcash. Uh the latest version of Zcash is I remember it's like 0.1.6. Uh we implement um so, the comparison right now is like done on like 1590 GPU card and we achieve pre so, I I I mean like uh last week is like 6%, but right now we are improving it like almost like 10% for now. And the the code is also on Zcash VM on its proof. Um yeah, but like we are switching from um I guess like from Rust to Go, so like we are still catching up with the block, so it uh so, the the the screenshot I take is like uh 8 days ago and we are uh

catching up with the latest block. After that we can do the proving. Yeah, so here is the result uh compared with uh Zcash. And as I just mentioned like the uh the encoding of the whole Zcash encoding of the whole proving process will allow us like to translate the the pure data structure into other into other I mean um into other hardware platforms well. So, we do we also do it on on FPGAs. Uh the FPGA like right now is a very preliminary result. We just um uh like HALs like friend less uh synthesized the C++ codes. Yeah, we

didn't do any optimization on it yet and it's showing uh almost the same performance per watt as GPU. So like for the for the metrics for for for the hardware there are like two metrics. The first is performance per dollar, which means like how much you pay for your hardware. The second is performance per watt, which means like how what's the energy efficiency of the thing. And I I believe by optimizing the FPGA or not, then we can get some probably like slightly better performance in terms of like performance per watt compared against the GPU. So right now the FPGA just around around 100 MHz and normally it runs like around 300 MHz.

So still some something like we can do. And yeah, since like SciMix we started a hardware company like we do a lot of hardware acceleration and one of the goal for SciMix is to design some specialized ASIC chips for for for the K. But yeah, we are just going to not very sure if the market is big enough to digest the chip. But we still believe that if we ignore the upfront cost, the ASIC will still be the perfect be be the ideal hardware to run it. Since an ASIC like the we can basically uh de decompose the module like into like uh many smaller ones and this like in inter module communication will be

treated as like uh first class on chip flow, which will make things like which much efficient than doing on FPGA or like GPU. Uh yeah, so there are like so many like things like we can customize if we if the market is big enough and we think like big enough to pay the upfront cost for tapeout for chip tapeout. Uh yeah, so here is our summary on the hardwares. Like like I I I believe like 3 years ago we write a blog post to say what's our take on GPU versus FPGA versus ASICs. We still think uh it's almost the same as before, but

right now the the K algorithms they converge a lot. There we So when we wrote the blog like 3 years ago like there are so many the K algorithms uh in the space, but they right now they converge a lot. Like the GPU still remains the production performance pass. Like if you like it's still the main's um power main proving power for for the K workload. And the FPGA FPGA still uh we we we use it as a prototype for for the ASICs. Uh it represents some like architecture design, but it's not the endpoint. And and and one one more non-technical thing about the FPGAs like it's not very easy to acquire the FPGA chips.

So which means like uh yeah, you also need to pay a lot like compared against the GPU. And we use FPGA learnings like to quantify as a quantitative guidance to the ASIC design. If there is still like needs demand in the market to come up with ASICs and like we are very happy to do so. Uh yeah, so this is like how the the K EVM node should like and it's supposed to be a demo, but we I don't have time to show it up. So it's Uh so like I guess like the audience right now is like very familiar with the K EVM nodes, which like instead of re-execute the blocks, you just need to have some like provers uh to generate proofs for the for the block then you just verify the block

instead of like re-executing the block. Um yeah, but there is like still some questions like we need to think about. The first one is like uh what's the provers will fit in the in the general like uh Ethereum uh roles. Uh will it be like some separate role or like it will be probably like the relayers should be the one to do the to do the proof since the relayers can see the blocks and it will just choose probably like the most um uh the blocks has the most gas to do the proving.

Uh and then we need to design some like incentivizing rules to mobilize to motivate the provers to generate a proof. If it's just uh the provers and to do the proof for each block and uh what they are going to get from the block since they are and like without a proof the gas um the gas per block is limited, but with a with a prover the gas limit can be like hugely increased. And so what's the what's like the the cost the provers should take like from from like boosting the boosting the gas limit.

Yeah, so that's something like I guess the Ethereum Foundation should think about. Uh yeah, so if you are interested in like here is our good good code repository. We open source the codes uh several days ago. And we also write like three posts like the of the graph modes and the like our our take on different hardware plus like what's will be the the K EVM uh economics uh will be like in the in the trilogy posts. Yeah. Okay.

Thank you. >> [applause] >> Thank you, Leo. We don't really have time for questions, but maybe people can join you in the what time the auditorium. Thank you, guys.