Binary Field RISC-V zkVMs

Transcript

[applause] >> And um I think Okay. Um I think the previous talk was very interesting and I have a few questions for for Srinath. Um In particular, I think there are um two interesting aspects to consider. First is the memory interaction because um I believe typically SP1 OpenVM RISC have um modular approach where you have tables that independently prove specialized computation or typically one table for each instruction and they

communicate with memory like bus arguments. While in this um like a many a many tons, sorry. A many tons. Um you have a monolithic approach. And this monolithic approach reduces the overhead of memory communication and in particular it enables twist because in like twist is not I mean like twist is not friendly to multiple tables because if you say like like the time stamp at which um each um like you need like the time stamp is implicitly the index at which

you address your table. So, it's not friendly to have multiple tables. You would prefer you you would rather need to do offline offline memory checking. But by having only one table in some sense you have to perform at each cycle every possible computation. If is it correct to say that? >> Yes, so you do Uh I think it's similar So, you do check uh >> bunch of constraints at every cycle and it's uniform circuit. Uh, but for pre-compiles, for example, if you're doing hash functions or even multiplications, I think they would be

done using a separate table. So, we might bring back some of the multi-table architecture, but it will be restricted only for these sys calls. >> Okay. And for Jolt, it's also only monolithic table. And instead of using the circuit to compute you delegate to look big like gigantic lookups. Is it correct? >> Okay. So, yeah, I think uh, Jolt is in some sense precursor to Magnetar.

Uh, and we have the same twist and shouts like architecture. Uh, I say the biggest difference between Magnetar and Jolt is that it swaps out the instruction execution part. Jolt currently uses a huge lookup table to do the that and do it over a prime field. Magnetar works over binary field and then it's swaps that out to just R1CS constraints. But, all the all the rest I would say is is basically the same is sort of the same philosophy, which yeah.

>> Do you have any intuition if you were to use Magnetar and to replace the PCS with like your new latest base PCS and you would remove the one hot nest check that it's necessary for hash base. Uh, so you would have in something between a mix between Jolt and Magnetar. Do you have any intuition how fast that would be? >> I think because you I think for binary fields uh, if you use large lookup tables, I think it's going to be much more expensive than doing it inside a constraint system because uh the reason that originally we devised this Lasso and Jolt uh around this one look up table was because in

uh large prime fields, uh these bitwise operations are very expensive. So, you turn them into look ups. Whereas in binary fields, you don't want to do that. If you try to do it, uh it's going to be more costly anyway. >> Interesting. Okay. And so, typically if you had to if you wanted to add the M is like the uh RISC-V 30 uh 34i, if you want to add the M to have multiplications and division, what you would do is you would have dedicated uh circuits or table to handle multiplication, and that would communicate with your main table, but that would not communicate with the memory and the registers.

Okay, makes sense. Okay. >> Yeah, I think the other way to your departure So uh that's it. Okay. >> Yeah, the other way >> Major departure, I think from this um large look up tables is also around uh recursion and scaling. I think um uh the existing or the the Jolt approach of uh scaling to really large executions, like for example, even billion cycles, is uh through uh streaming. For example, you can implement uh the sum check protocol uh in a streaming fashion. I think all the commitment schemes, both uh Dory and also Akita, I think are amenable to this type of uh scaling.

Whereas uh I think hash-based schemes have some limits, uh but recursion is also very cheap in the hash-based setting. So, uh better way to do scaling in the hash-based setting is through just recursion, do smaller chunks, and recurse. Whereas in Jolt, I think you can go to bigger uh chunks, uh but if your application already requires recursion, there may be some difficulties there or maybe some costs that I think are not maybe known yet. >> I see. And when it comes to adding this M you see like the M this M extension to 2S5 um because there is the possibility of using BitZ, which is if you is perfectly

suited for multiplications. The question I am wondering is would Flock or like which is in some sense the same as binary Spartan in some circuitry. Um would this be sufficient to make it to to make the multiplication division fast because if we can keep the same component to prove every every instruction, it's simpler than having to have specialized components for every type of instructions. So I'm what I'm wondering is that is for 2S5 proving would Flock or binary Spartan be be sufficient for multiplications or like do you have an intuition

like BitZ can give us 10 million um or say 10 million multiplication per second. The question is how good can we be with Flock or binary Spartan? >> Yeah, take this with a grain of salt because this is not implemented, not benchmarked. So I think if you write a a multiplication circuit over binary fields, I think probably like 10,000 constraints. I think um Yeah.

Yeah, yeah. I was taking a upper bound to just see where what's the max you could Yep. >> Uh for you 64 multiplication I think we start around like 4000 gates on variance or 2000. So I don't think it would be as good as busy but as long as you're not doing too many multiplications I think it's reasonable. Okay. >> Interesting. And do you have any intuition on for cuz for read read only arguments there are there are a bunch of them. You have a little bit star, you have offline memory checking, you have shoots, you

have like binary shoot and look up anyway. For read write memory setting read write memory arguments I think you only have twist or binary twist versus offline memory checking. In practice the the risk 5 VMs that use offline memory checking I believe SP1 and open VM 600 I don't know but anyway places the registers alongside memory and like in some sense register access is as costly as memory access.

And so that's the main that's the biggest the biggest advantage of twist as was mentioning memory locality. But what you lose is the ability to modify memory at each table. So it forces you to have monolithic table. And so the question yeah and and also one drawback of I believe twist is that it's friendly to small memories because you have to commit like in particular in in the manner setting if you have I don't know like 2 to the 32 size memory we'd have to commit to and I think I don't know like the the size of the chunks but if you take if

you commit to chunks of four bits, like um so typically you commit to two two 64s. Um and this No, I I don't know in practice, but I don't know. The more you The bigger your memory is, the big the the more field elements you have to commit for each access. And so, in practice, um in your benchmark, did you restrain yourself to small memories to make it work, or would it support larger memories? >> Oh, we can support larger memories. I think we even benchmarked uh millions of words.

Uh so, this uh could even uh support running an EVM inside. >> Okay. >> If you have like tens of megabytes of memory uh available to the guest, I think that could support >> Okay. >> Uh >> Okay. >> Yeah, I think I think the the cost of memory, I think uh is a small uh fraction of the overall proving. So, even if you support larger memories, I think the overall impact on end-to-end prover time is very small. Uh >> Okay.

So, if I summarize, we are getting close to 10 million cycle race five per second on CPU. Um Does anyone has intuition how it will translate to like if you do the same on GPU to prove EVM blocks? How good would would we be? I don't know. >> We have the Zisk folks in the room. >> Um >> So, we can The question is if we can do 10 million cycles on a CPU, like what's the what's the expected performance on the on the GPU?

>> How many How many How many steps? The problem is that here pre-compiles um changes a little bit of the rules, but uh So, currently, how many how many steps do we have? Let me calculate that. I give you numbers. >> Emil, you said that all the registers that access the the memory, but this is probably not true in the code. Like, there are some registers embedded on the main CPU tables.

>> Yeah, yeah. Okay, you mean You mean in the VM, you have code like the registers, you put some of them you put them in the main >> Yes, like when those that are very frequently accessed, like you embed them on the main tables, and so you reduce the the times to access. And this is not only RVM, like I'm pretty sure C C is doing the same, but uh >> So, in in in the VM, do you have a main CPU table, or it's like a no CPU architecture, like Open VM?

>> No, we have a main CPU. >> You have a main CPU in which you embed a few registers. >> Yeah. >> And you delegate the rest of the computation, I think. >> Yeah. >> It's just as a small detail it probably doesn't change the overall analysis, but just >> Yeah, yeah. >> You you could embed some registers like to avoid that. Uh >> Right. Um Yeah, if you get to 10 million RISC-V cycles per second on CPU, I think it's probably good enough for Ethereum use case. In particular, you can aggregate I mean, at this point the bottleneck will no longer be RISC-V cycles. It will be number of hashes you can prove per second. And recursion will be cuz I expect recursion practice. If you add uh

one tree compile for your hash, one tree compile to do extension extension field operations, your recursion will be I don't know half a million cycles. It will be 0.1 seconds. So it will be extremely fast. So I would say at this point and I mean recursion without the circuit recursion in VM like the nice the the pretty one. So at at this point I think we we may just we could have stopped optimizing for performance because 10 million is enough and just optimize for simplicity. And so what I like with I think I like I like mental a lot because it seems quite simple. Like you as you said it's only

like two essential and binary pattern. And your sum check for routing. Do you do you think you could remove the sum check for routing and keep the performance or >> Yeah, I tried quite hard because I don't like these special arguments. Just use existing stuff. But I think uh there is a big performance hit for not having those routings. So uh and turns out that protocol is actually simple. In some sense it's a a a type of um one hot based protocol. So it's I guess just another shout like protocol.

>> And did you have time to to try the implementation the new one hot test? Uh while you you you test the F X + 1 * F X equal did you have time to try it or >> Yeah, yeah. I think I looked at it. I think it could reduce the degree of one of the sum checks by one. I think four it becomes four to three. Uh and also I think reduces one of the evaluations or two of the evaluations in shout. I think it could reduce end to end times as well. But I don't right now how much >> Interesting.

>> Hello. Okay. So, I guess my view after working with Jolt for a while is that if you're designing a risk five CKB and or if you're designing any kind of fixed computation, right? The computation is going to be the same and you want to sort of optimize your protocol so that it matches the computation as much as possible. Uh, I don't know, like the metaphor I think of is like pouring water through a rock right? Or some some sort of thing where eventually it will sort of go to the most optimal configuration possible and there is essentially no cost to doing this

because it is a fixed computation. The risk five ISA is not going to change and the underlying principles I think are quite general. It's just that in each case of your fixed computation, that principle is going to be expressed in a number of different subjects that are connected together in a very tight manner and I think this is what Jolt does, this is what Magnetar does and it's probably the the most efficient way to to get to the the fastest proving.

>> And >> Yeah, maybe also about Magnetar one last optimization could be I don't know how impactful it would be, but to use a bigger field, let's say 192 bits extension field. I think the degree three tower over 64-bit field because this is what Lin VM uses currently like and the drawback is that the field operations are slower, but you get you can be in the list decoding regime and have I don't know, two 200 kilobytes or even less proofs. So, maybe considering end-to-end like proving un-recursion, um you would divide the proof size by three. Maybe it's something that is relevant to recursion.

>> Yeah, I [clears throat] think that's an interesting idea. I think it reduces proof length at the cost of some small increase in proof time, right? Maybe like a factor of two. >> Yeah. >> Uh and then I think it allows you to do recursion better and not lose soundness, etc. I think in the setting that we are in, because the there's no grand product argument or a grand sum argument, we have very minimal loss in soundness uh from even 128-bit uh field. Sorry? >> Yeah.

>> Yeah. But can Given uh current knowledge and proximity gaps, you're going to have to use a larger field. They're much too large. >> Uh for recursion? What do you mean? >> Uh so Okay, so for for recursion you want to have smaller proofs so the recursion will be faster. And then you want proximity gaps in the list decoding regime. And there the errors are much larger. So, uh 128-bit field won't suffice. >> Can you do 128-bit for the PLP and then 192 for the PC?

>> Yeah, so we did So, we did that in uh Plonk. So, we implemented recursion for Plonk. We did a um 128-bit field for all the sum checks, but then 256-bit field um within kind of the here protocol. Um So, it's much less than 2x proof overhead, but it's still annoying. I feel like it should be better. Um just maybe like 50% slower proof or something. Um yeah. >> Is there a reason you you didn't do 192 bits? Cuz that seems sufficient. >> Um so it's more It's like more easily compatible with a 128. Otherwise, you have like two different extensions of 64.

Um which is You you can do it. It's more annoying. Um yeah. I I feel like uh it's already pretty decent. I feel like there's more to squeeze out and the fact that it's kind of um non-continuous is annoying. I would want like something that's kind of smooth and uh whatever. I'm targeting 128. It feels like I pay only for that and not more. Right now it's sort of feels like uh the argument is um for lack of a better word kind of quantum. You have to kind of like make make these jumps kind of uh yeah.

>> And speaking of uh I was wondering is the the ages keep on the main branch or not yet? >> The main branch. >> Okay, nice. And you know if there is a paper >> Uh yeah, so the paper exists kind of fully. We sent it out to a few experts. Uh Rahul was here. We presented later today and I think this week it should be out. I've said that also 2 months ago, but this this uh this week uh for true. Yes. >> And about the ages keep uh which was if I understand correctly very complex to to find and to But is it the complexity for the prover or is it the complexity for the protocol and the verifier?

>> The com- the complexity is for the Rahul. Uh do you want comments? >> Uh both the prover and verifier get more complicated. >> Okay. >> It's not horrible. It's something that like an AI model can deal with and just implement for you. It's not like a human doesn't need to worry about the >> Yeah, but I mean Maybe it's hard to to to discover it, but once it has been discovered to understand why it's sound, is it something complicated or it's something that is human understandable?

>> It's something that's human understandable. Um yeah. It's just like yeah, it's more complicated than univariate skip, but there's a lot more like field theory you have to do, but it's it's like less than 10 pages plus a bunch of scripts that you just have to execute and see. Okay. You don't need to know any algebraic geometry to verify. You just need a field theory.

So, okay. Good to know. Okay. Cuz I assume that this could be applied to many others also. So, 10 million cycles maybe very soon. Okay. >> And have you checked how many hashes do you need to to do the verification and how fast can you prove those hashes? Like to have an estimation of how fast is the recursion? >> Also, the underlying proof system binary Spartan can do for example on Blake 3 almost close to a million hashes per second.

>> Okay. >> And I think the cost of verifying this proof is roughly the cost of hashing the proof. >> Yeah. >> It would be like 20 m I think linear is like 10,000 hashes, but I think we are in the coding region, but like the order of tens of thousands of hashes and that's it. >> Um yeah. And also maybe the reason for using a 256 bits is maybe because the hash is so fast on hardware. So, you prefer >> [clears throat] >> I still feel it's kind of like

quite good, probably good enough, but um we're the current thing in flux being kind of feel like too much for the 128 bits of security. Should be cheaper, I think. >> And so, you have you're you're hinting at ways to go from a 20 120 to 128. Is that, you know, with grinding? >> I think mostly standard things things things that other people are doing, I guess. Grinding, maybe bigger fields, so >> Mhm. >> Got it. >> Uh I don't know if if it's allowed to say, but any plans for JOLT to cuz there there there's always been this idea of JOLT binary fields. Isn't something that you started

working on or >> Um I guess in in my personal opinion, Magnetar is is JOLT for binary fields. So >> [laughter] >> Um so, in that sense, like, yeah. >> Okay. >> We should adopt it. >> Interesting. So, when I was chatting with Justin Thaler, he was saying that, "Okay, we can do JOLT for binary fields, but it's going to be slower than uh JOLT with lattices." And it looks like actually, you know, on on CPU if you only use a CPU, uh Magnetar is maybe an order of magnitude faster.

Um do you feel like JOLT with lattices will will catch up? Um >> Um yeah, I think it's it's very possible. Uh I I I'm not for sure, but there's the uh recent work um called Lapinus, which is basically you do a your PLP over binary fields, but then you're able to commit and open over a lattice uh base PCS. Uh and those techniques uh that paper has a number of limitations, like slow verification, uh but I think all those can be overcomeable, and uh we're looking at integrating that into Akita. And once

that's done, it can sort of just be like a lattice back end for Magnetar. >> And so in some sense, you would end up having even shorter proofs than hash-based schemes, but at the cost of slower verification. >> Um yeah, I I wouldn't say much slower. Like currently, if you saw the slides, like Jot with Akita, which is lattice-based, is faster than Magnetar. Um well, the difference is like 12 milliseconds versus 8 milliseconds. Uh but I think it's going to be very very comparable.

>> I see. Okay. Interesting. Any plans to include BZG? >> Um yeah, so I guess uh BZG is in some sense, like if if you have to just stick to hashes, then exponentiation is probably the best you can do. But if you can include lattice techniques, I think there may be something better that you could do. >> Mhm. Interesting.

What are the open problems that you feel are are remaining with Magnetar? Like What are the things that, you know, you're hoping we can potentially solve you know, in the next few days three days? >> Yeah, I think although I wouldn't call these open problems because I think we know how to solve them. Like M extension, uh formal verification, uh recursion. I think all these are known how to do. Just doing them, I think uh So, I don't see any uh roadblocks to reaching parity with other ZK VMs while retaining the same security and It doesn't

>> So, do you feel like this is the end of the road, you know, where >> [laughter] >> I think I guess we could always look for more performance. Uh but as was told earlier, maybe this is already good enough uh >> You know, if you unlock like a hundreds of megabytes of performance and new application was it unlock and you know, I have this vision of like computing as fast as computing um which was the title of a theory paper. It didn't really mean it practically, but if we can get something that's, you know, I just think it will enable new application that are hard to imagine right now. I don't think there is a really a limit to what we can hope for.

>> So, what one open problem for binary fields that I see is that we only get a 2x uh performance improvement when we use metal as opposed to the 10x if we use, you know, Nvidia GPUs. Um so, maybe this is a question for Jean-Luc, but do you expect we can somehow talk to Apple to get them to expose uh you know, similar acceleration instructions in in that >> [clears throat] >> I mean, I think it's Yeah, I think it depends. I'll talk a little bit this afternoon. I think the binary field instructions are a happy accident {slash} confluence of a lot of different reasons why we want careless multiplication not just for

um proving. So, I think what we need to find is like what's a uh like a uh a set of fundamental building blocks that will not only support our workloads, but also other like maybe non-proving workloads and that's where we can find the intersection of those, that's where you get the best performance. So, um it really depends on like and and then hardware timelines are are long. So, where we see ourselves in like 2 to 3 years is really important in terms of determining what instructions are going to be useful.

>> And And if I understand correctly, the the story with this instruction is that the hardware supported, you know, the acceleration going years back, maybe, you know, the the 3090 or something. Um and I'm just wondering is there potentially more potential to to unlock untapped performance by exposing even more precompiles or instructions? >> Yeah, it depends on what the instructions are. >> Okay. >> And >> Right.

>> Yeah. >> [laughter] >> There's a lot of Yeah. I'll say that Yeah, it really depends. And the main blocker is like long-term support. So, once you once you unblock an instruction, um part of like the CUDA guarantee is that like you write a program in like 2013 using instruction, in 2026, it should still work. >> Okay. >> And so, it it kind of adds a long-term support requirement. And that's it's it's almost more of the logistics are are the constraint there.

>> Yeah. And if the only thing we care about is short-term support for a specific version of a GPU, is that something is that a design space or is that completely locked off? >> Yeah, I think that's that's it's more difficult to do. >> difficult. Yeah, okay. Got it. >> Sure. So, so semi-related question. So, I think both from what you you told me in the past and what I observed is that the charismatic application on consumer GPUs is great, but not as good as on servers. Um is that going to be continued to be that way or if you can comment on that?

>> Yeah, I don't know if I can comment on that. But But I think it is true. Um you can think about the workloads that typically run on consumer GPUs, and they don't look the same as data center GPUs. So, that will continue to be the case. There may be some like Yeah. There may be some in the future that Yeah. Yeah. I I um I'll talk about this afternoon. Yeah. Yeah. But But um Yeah, there's a I think there's a good way to intuit what is what that performance is tied to. Yeah.

>> And And you're you're the first person from Nvidia that I ever interact with. And I'm I'm wondering what is the process for the cryptographers in this room to talk to the Nvidia folks so that we can figure out what are the correct instructions that potentially we could expose in the future? >> Yeah, I um I'm I'm happy to chat with anyone. Um I think the more people who have the same thing that they kind of want the better. Um because it more of a demonstrated need. And um uh I'll give a brief shout this afternoon, but but we have a uh on the product side, we have a library that some folks are building with kind of cryp- low-level cryptographic

capabilities. So, like NTT, hashing, Merkle trees, big integer, some other stuff that they're working on. And so, the best path would be if there's enough interest to try to push support through that kind of library so that you guys can all build on top of it. >> So, I do a formal verification on the when I do formal verification on say RISC-V, I take the say RISC-V specification, I do formal verification on the things that run on GPUs. What kind of specification can I use as say it's for an Nvidia immediate things?

>> I think you I it really depends on on what you want trust. If you don't want trust anything, it's really tough because the if you you go from like CUDA to PTX like a portable assembly and then you compile down into SAS or some other, you know, really low-level device specific um ISA and that >> PTX is uh candidate >> Yes. >> So if you know, there is uh an author >> Yeah, you can you can >> author data you like author data author data is it the adjective? Yeah, we some specification formal spec with a stamp of Nvidia that will help me a lot.

>> [laughter] >> PTX I believe does have a spec. Um >> Yeah, okay. >> But you're not the the problem is you don't have you don't have access to the compiler that goes from PTX to to your GP you bytecode. And so you can prove that the PTX is correct, but you can't prove that the transformation into the actual kernel that is running is correct. It's really difficult because you know, not only it there's a compilation step, but there can also be like runtime patching and like there's a bunch of stuff happening below the surface that would be hard to verify.

>> Yeah, I understand any trust boundary. We know that there's actually total complexity, but yeah, PTX is a candidate. So like I'll keep looking at it. >> Exactly, yeah. >> So so one reason that something like Tile IR would be interesting is one because obviously it exists in MLIR dialect and there's ongoing efforts to verify MLIR and infrastructure for this, but the other one is that obviously Tile IR could also be used by Intel and AMD and other vendors and then we would actually have at least shared semantics that different >> Yeah, yeah, as long as you're >> if you're comfortable with that with kind of not formalizing what happens afterwards, then yeah.

>> Yeah, so it's more you it's a good starting point at least cuz it can be shared and reused and then whatever happens below we deal with later. >> Exactly, yeah, yeah. >> Is there any kind of >> Is there any kind of formal verification possible for like the runtime of an algorithm? Uh some some sort of bound that you can have. >> Like the runtime behavior? >> Yeah. >> Yeah, like a bound on how long this is going to run for. >> Oh, like a runtime bound. Um I think Uh I I think it would be difficult.

Maybe for maybe for a subset >> could we model like you know, some abstract machine and >> Yeah, yeah. >> do bounds on that. >> Yeah, yeah. I I think like for a some subset of instructions you could do that, but sometimes there are like I mean, it's already a variable cycle, but like sometimes you have instructions where you really don't know how how long it's going to take, you know. >> Uh just a question for the risk five ZKVM in this room that are not binary. I think there is lambda VM and Zisk. I think in Zisk you switched to Blake three, if I understand correctly, recently.

Um so you get the like the benefit of standard hash security. Is there any plan or any uh research on switching I guess you are at using Goldilocks from Goldilocks to binary fields or is it something that you do not consider in the short term? >> Version 2.0, I mean, we want to uh consolidate current version. That's just using Goldilocks. It's not using prime binary fields at all. But we are internally researching and and if we see good results, of course, we will go whatever uh whatever good better results.

But we are we are studying it, but we are not implementing it for production yet because we need to believe first that this is going to go in the right way. Which looks very good, but we need to check. >> All right. And number VM? >> Can you repeat me the question? >> Which field are you using currently? Baby bear or Goldilocks? >> Goldilocks. >> Sorry, Goldilocks. Okay. And Do you have any plans of switching to binary fields in the short term or not?

>> Uh yeah, we have a a couple of forks on the road that could happen. One is that we have a a protocol to do some cross proofs. So we we will use both the stark protocol and the binary protocol and do use each to the fastest to apply each protocol to to the place where they are faster and then mix the the outputs. Uh if there is now a protocol that does everything together, maybe that makes less sense. I don't know.

Pro it looks very solid. So >> Is it like the field switching from level? >> Um I should check it out, but it's kind of novel. So I don't think so. But it might be that is not extremely efficient, but we need to test it. So we we have like these more experimental forks. We will see how they work. Uh Um in the worst case, we keep moving with some normal stark recursion with uh uh late with probably with weir.

That's our best approach right now. >> And And right now you use Poseidon? >> Um yes, right now we are are using Poseidon, but the plan is to to switch to Blake, of course. Uh, it's it's just easier for us to to compare against other VMs with Poseidon since everyone is using Poseidon, so uh I'm we're mostly using Poseidon as a benchmark metric and not as the end game.

>> All right. Okay. >> And And I I think Charlie wants to say something. >> Well, I would like to give you a little bit the current state of the art of the numbers that you asked there. So I mean, we currently we are uh we are currently uh proving an Ethereum block block in average in 4.8 seconds with two GPUs. This is the last numbers from yesterday, which is really good okay?

Of these, I mean, if you if you have to prove a block just with RISC-V without any precompiles, this is I mean, we need to check, but this roughly like uh 3-4 billion steps of RISC-V. Okay? So, currently the number of uh steps is 75 millions only. That means that uh most of the steps are solved in the precompiles. And precompiles are only like uh around 30-40% let's put 50% of the actual area, I mean, the actual cost of the of the prover okay?

So uh if we just try to do some some some math here, so if we are doing doing 75 million steps, um uh but only 50% of them, so it's like 5 5 seconds in just one GPU, okay? So, this would be uh uh more or less an average of uh about 15 about 15 MHz, okay? But, you probably need to multiply that by two because during this timing, so 50% of the time is doing aggregation, okay? So, if we don't count aggregation, which is important, but if you don't count aggregation, this would be about uh uh uh about uh So, it would be about uh uh

30 million 30 uh 30 MHz, okay? And if we remove the 50% of the precompiles that I mean we are proving that are included that are including here, that would be around 60 70, okay? Also, the proofs that we are building here, so currently the proofs is relatively uh small, so we have a lot of uh let's say uh waste area that we are not using. So, if we discount that, so probably we could reach I mean this is a little bit a high uh upper, but maybe would be about 100 MHz, which would be one order of magnitude of that 10 MHz uh of just using just a single uh GPU uh with the system that presents,

okay? So, 100 MHz uh 100 MHz in uh in a 50 in a 5090, that would be probably where we would be. Again, without recursion and just doing uh risk five. This is the Of course, this is without using any binary fields, but this is a little bit the state of the art or more or less where we are uh currently. This includes execution. It executes like everything in the block okay?

More or less. Just give you a rough idea of what's the current state of the art of uh proving uh capacity. >> Interesting. >> That there is also a bit of overhead when linking uh multiple recursion segments. >> Yes, this has increased a lot, especially when we are using Blake. I mean, the Blake circuit so the trick for not using Poseidon and using Blake a little bit the trick is of course Blake is much faster. So all the So proving in Blake is faster. Okay, the problem is the recursion part. So when we when we pay the penalty is in the recursion.

Uh the recursion circuit is much more complex, but at the same time building the proof is faster because we are using Blake itself. Okay? And the other trick in order to keep more or less the numbers is to do the the sub proofs. I mean, the try to do the proofs a little bigger, so as big as we can so that we can reduce the recursion. Okay? And because the initial step mainly when most of the work is much faster because it's just proving I mean, proving everything is Blake. I mean, the first step of you don't need to So you need to verify that, but the the first computation of the proof is relatively fast.

This has increased a lot. So the proving time is much faster. So we have more time for recursion. Okay? So putting all together um surprisingly we are better that I that using Poseidon. I mean, surprisingly because uh for us is a surprise. Okay? So it's like I I I was thinking, okay, we are going to be like 10 times uh slower or order of magnitude slower and we are and and not only that uh the nice thing is that um thing is that we we were in a point with Poseidon that like 50% of the proof was uh compute hashing Poseidon.

Okay? So this limit uh was difficult to break. Uh changing to Blake I mean, we remove I mean, this is just one order of magnitude Blake is one order of magnitude faster. So mainly we remove this bottleneck on the prover. So readjusting uh the things So we have margin. Uh Now Now have margin because we break this bottleneck. Now we have other bottlenecks and adjusting these bottlenecks we can get better. Okay, so we break one of the big stoppers that we had. Okay. This experience of the last month this is I mean we are quite surprised of this way. But the reality is that well, okay, we unlock something and we

are doing huge improvements. I mean the last two versions we are getting to I mean one year ago we were in four GP four GPUs and now we are in two GPUs with these numbers and that's because we are I mean adjusting the rules has changed with like so we have adjusting the size of the circuits the recursion circuit. I mean we are readjusting everything to optimize and to have the level optimization that we had with Poseidon with Poseidon 2. >> Interesting.

And when you say 4.8 seconds I guess this is the median of the average block I assume. >> Yeah, this is the current this is the current Ethereum. >> I'm just if like the in terms of prover clear what's currently the if I had to construct the the worst block for Zcash what would it be? Would it be I don't know some even precompiled so is there some I assume typically if you were to build a risk-averse Zcash VM with um with an assumed uh multiplication like uh 256 multiplications is likely not good for unless you use bit Z.

Uh like in this what's currently the the biggest >> Yeah, let's see because for example we say oh multiplication is expensive. Well, depends. I mean if you are doing for example if you are doing two times two uh you don't have to prove the full multiplication. We have to work with we call precomputed, precomputed multiplication. So, for a small number, for normal, which by the way are the ones that are most used most, it's it's just a look up. Okay, so that's it's really really really cheap. So, when you say multiplication, it depends. Of course, if you are doing elliptic curve, so elliptic curve multiplication, then that's uh more expensive. But it's a circuit that's quite optimized and and has been quite

proven currently. So, uh doing that in binary fields, well, I want to see if this is faster even applying all these uh tricks there that currently. I mean, this is what we need to see. It's difficult to compare because uh I mean, we've been working in Goldilocks for the last uh 4 5 years uh in our team. Okay, so we have everything very very very very optimized. And binary fields, it's it's something that's relatively new. I mean, they I know that being used, they were doing some work, but it's not so it's not optimized. I mean, >> [laughter] >> let's see. Uh so, we have So, it's very difficult to compare

uh currently. Okay, so we have a refer good reference, but this is something that's new and we need to see where this uh optimization I mean, how long they can be. But it's difficult to I mean, it looks really interesting. It looks really good, but uh until the experience is that we don't you don't have all the pieces there, it's difficult to really do uh comparison uh one to one to the other. >> Mhm. And answering that, um is uh Magnet open source? >> Yeah, it's not yet open source. Uh it's it's fully built.

The missing things are an extension, recursion, zero knowledge. Some of these are missing. We will uh implement those and get it >> Okay. And so, what was the ETA for >> Uh no ETA. >> Yeah, I no ETA yet, but I think uh probably soon. >> Soon. >> Oh, yeah. >> Even if the regression SDK is not ready, I think it it would be valuable for everyone to to be able to learn how you made it so fast. >> Yes. Yes. Yeah, I think um um there is a I guess some um because I was building a lot of these underlying components from a long time, like almost 10 years. Uh I think it's uh supercharged by AI assistance, but

it's not like you just ask AI to build, it will build. It's not going to happen, right? Like it's not one shot or so on. It's a lot of iteration. Uh and people who have built these kind of systems before have much more advantage or just white coding. Like it's significantly different. Uh Uh So, it's a lot of iteration. Get it built, but high maintain quality. I think quality is one of the biggest important things. Uh Uh so, this code base that uh we have built, I think it maintains high quality both for maintenance and also we want this code to be um uh modified by humans. So, it's not uh something it's uh

>> Awesome. I think we can all smell the food. Um so, uh thank you so much Emil, and let's go for lunch. >> Okay. >> [applause]