Ethproofs Call #10: Binary fields

Transcript

Hello and welcome everyone to Eve proofs call number 10. This is a really special call uh on what might become the future of uh hashbased proof systems. Uh we're going to be focusing on binary fields which is a a big move away from the the prime fields that are are in production uh today. Um if you're new to the e-roof call uh community we uh have a corresponding telegram group. So that's EF proofs community. Uh and we also have a uh a QR code here if you'd like to join. Um Alex, would you minding yourself?

Uh we've had uh 12 EF proof calls uh so far. Uh a few B calls. Um and um yeah, we started in 2025 and the next EF proof call uh may be on Fiat Chamir. uh there's been a little bit of a development and the tentative date that we have here is October se 2nd. So famil is like one of the last few subtle things that we want to try and and and and get right uh to have really amazing security. So uh on fat shamir last year we had uh this paper how to prove false statements by ditri and lev and uh we're going to have a bit of alpha we're going to have a new paper uh by Jakamo uh with

another set of of edge cases to be to be careful of and I think this is a good u prompt basically have a bigger discussion on on on the okay now on the topic of today's call binary fields so yesterday uh we made made a big announcement on Twitter basically that the Eiff uh is moving away from Pedon and is going to be uh embracing traditional hash functions. And the way we can achieve that without losing performance is really to have these new breakthrough uh snark proof systems that are hash friendly or or or friendly to to to binary circuits and and boolean operations. And here are some of the top questions uh that I've

uh received um since since yesterday. And I guess I want to quickly go through them one by one. So the first question is is poseon broken? So to my knowledge as of today uh poseon is not broken. Uh it still has 128 bits of security. Um there there are multiple teams that have you know partial attacks that all nibble uh at the uh the security margins and we will have in October a um uh pedon crypto analysis workshop with 15 world experts. um they're going to be spending three days in a room and the the the one goal of this whole uh crypto analysis workshop is going to be to break and if

it survives this workshop I think there's going to be a tremendous signal for pose don in terms of its security if it breaks during the workshop I think that's also going to be a positive outcome because it might be a forcing function to start retiring and migrating away from pose don and uh having more unity and less fragmentation within within the space Um another question is what about uh multi-party computation and threshold signatures. So um once we have the the the snark functionality uh that we use for aggregation, we can reuse it for for threshold signatures.

So uh imagine having um a k out of n scheme. We just do it the most naively the most naive way possible where we have n parties each with n independent pup keys. um k independent signatures that get produced uh when a a message gets signed and these K signatures just get folded into the one proof that we have per block. So in some sense the approach that we're taking gives us threshold signatures and NPC for free and we can even do like super fancy um multi so it could be you know two out of three or like five out of seven or whatever programmable conditions you want to have.

Another question is what about the complexity of of snarks? Well, here the answer is is easy. This has been the answer that we've given for many years. Now it's end to end uh formal verification. Um another question was uh what about the performance on hardware wallets? Hardware wallets can only um process about 10,000 hashes per second. Well, um we still have work to do here, but we believe we can design a stateless signature scheme. Uh basically, uh something that we're calling lean sphinx, um and uh it will have a hardware wallet signing time of roughly uh 1 second. And then another question that we got is okay, you're moving away

from peron, but which hash function are you embracing? And the the the honest answer here is uh we we we don't know. If you haven't muted yourself, please please make sure to do so. Um, but yeah, if you're familiar with the e proofs calls, uh, we've already done one change away from pedon to two to pose one. Um, and if you had asked me, you know, two weeks ago, the top candidate would have been Blake 3. But now, every time that we improve the performance, we're kind of opening up the design space of of possible candidates that would uh have the performance that that that we want. So now, you know, we're starting to explore Blake 2s. Um, and the performance has

gotten so incredibly good in the last few days that, you know, even Shatu, you know, which is the slowest of all, you know, by roughly uh 2x relative to to Blake 3, you know, at least within a snark is is looking uh, you know, potentially very good. But again, we haven't made any decision as of yet. So um this whole uh area of binary field proof systems uh really kicked off with um the benignas paper in 2023 by uh Ben and and Jim and in in recent uh weeks uh we've had this this uh this flock paper by Benedict Ron and William that really

took it to the next level in terms of making it uh more much more applied with performance which is really competitive with with state-of-the-art uh systems. And nowadays we have this really incredible new tool called open auto research uh challenges. So one of them is snark.fast and it took the performance of of flock and improved it by three and a half times on a on a MacBook uh laptop uh getting us to 1.8 8 million compressions per second for Blig 3 which is absolutely amazing given that this computer is you it's an M3 so it's you know two and a half years old uh now now there's another very interesting

auto research challenge called zkolf uh they have also embraced binary fields so their challenges seven and eight are um regarding arithmetizations of shatu and blake 3 uh with with binary fields and they've both squeezed about 30% relative to flock. So the 1.8 million number here is actually a bit misleading. It should be closer to 2.3 million once we have these optimizations uh incorporated. And there's even more optimizations that are uh in the pipeline that are going to be announced uh later today that might get us closer to to 3 million hashes uh per second. So here's the agenda. Uh we have uh a very quick update from Jordi

and then we have uh a section on auto research. So we're going to be discussing zikk.go snarkf fast and there's a really exciting uh unveil and new challenge that is dropping uh today. So, Alex Hicks uh will be making a presentation on this very exciting uh new auto research challenge and then we have nine presentations on binary fields. Um you know going through flock benignas but all sorts of of other new and un some some unpublished ideas here that are going to take uh binary fields to to the next level. So without further ado, I would like to invite uh Jordi to the stage to give us a quick update on ZISK.

>> Can you hear me? >> Yep. >> Can you see Can you see the screen? Okay. >> Well, uh well just uh glad to announce that in in this we are continue working and we are ready to launch Z 1.1. We are going to launch it even either today or maybe Monday morning. And the main uh the main advantage I mean the main thing is about optimizations. I mean in the last uh in the last month we have been working a lot in a lot of optimizations and this is the current state. So with four 5090s uh keeping all the security parameters 128 bits uh probable security we are still using posed on posedon one but not posed on two so we we already step back

to posed on one and of course keeping the all everything on postquantum we are these are the numbers I mean we are uh the the 99% is below 10 10 seconds and the average the uh it's less than 6 seconds and this is just with four uh 5090s. This is a little bit the distribution that you can see. This is our uh it's like uh dress uh more than 7,000 blocks and this is the distribution that we are that we are getting uh what we did uh it's a lot of engineering here. Here I just highlighted uh some of the things that we did. First is we are using a new client is CSV one mainly is based on

EVM1. It's a C++ with some uh optimizations that are there. There is a lot of uh maps mopsis memory operations we are running in things that are moved from the CPU to the GPU. Uh a lot of GPU um uh re-engineering uh we converted some interpret of the what we call expressions to something that's compiled directly to the to the expressions in the GPU. We did a lot also a lot of u improvements in the limitations especially here is blade 2 and um I mean other uh that we save a lot of things here we also implemented all the risk five all the bit

manipulations this give us smaller smaller proofs with less uh compilations and we also added uh um I mean the new pre-ompile this is for the analysis or the jam test this also gave us a lot of bars a lot of boost here. Uh plus the we also did a faster BLS uh 381 and and and the BN 254 uh 64 premp compile. So this is very much a lot of the engineering that we've been working in the last uh I'm very excited very excited for what's going on on this binary fields and see how we can even improve that further with that.

>> Amazing. Congratulations Jordi. Um I would never have expected real-time proving with four GPUs. Uh this just means that we can increase the the guest limit by 4x. Um and one of the amazing outcomes from the last few weeks is that it seems like binary fields are actually faster uh significantly faster potentially for the glue logic than prime fields. So um yeah, very very bullish times. Um any questions for Jordi? If not, we're going to move to Matias.

Um who will discuss uh zk.golf. Jordi, do you want to show stop sharing your screen? >> I'm trying. It's just >> There we go. Uh, yes. Perfect. >> Does that work? >> Yes. Nice. >> Perfect. >> Uh, yeah. So, I guess sec golf kind of came out of um out of sort of a realization or a potential that developers essentially shouldn't be writing circuits anymore. they should be

writing sort of high level specifications and then asking um an LLM to come up with like an implementation and repeatedly optimize it. And we figured like the best possible demo we could do of this is is what's what CK Golf. So what what's CQ? So essentially in CK Golf we write some sort of a specification of a of a circuit essentially what should the circuit do? So it's just like a a program that computes whatever you you you want the circuit to do. So it's like sort of a traditional implementation of say ketchup and then everybody and their agents can compete to write the most optimized version of uh of the circuit and we can sort of trust these agents to do that

because they also need a proven lean that the circuit is complete. In other words, if the original program actually uh outputs something uh on some particular input or is satisfiable, then so is the circuit. And conversely, it's also sound. So if the circus is satisfiable, then it also satisfy the original program the specification. Um so for large fields, which is what we ran it for the longest, so we ran it on large fields with R1 CS, uh so motivated by G 16. Uh it's resulted in an extremely optimized uh circuits.

So what's new? Uh, of course the new thing is that now we also have uh subcircuits over binary fields. Uh, in specifically we are targeting what we call canonical R1Cs which is a version of of R1CS where everything is square and where uh the C matrix is an identity. So it's like a * set hard product B * set is you know set itself. Uh equivalently it means that like every every row is like some sort of uh that every every variable in in set is like written as some set of uh some sum of set eye elements times some other sum of set eye elements. Uh and there's exactly

one constraint on each uh each one of the entries and this was motivated by flock uh where it's also restricted to this uh so limited version of our cs. So in the first batch of challenges that we released we have uh added SH 6 compression and D3 compression as well as Kangaroo 12 uh uh permutation which is a rounded version of Ketchup permutation. Um we've seen like here the the numbers compared to to what Justin was showing here the numbers is in relation to the previous best circuit. So we have a uh 26 a 27% reduction and a 29% reduction

compared to the previous best known circuits at the moment. Uh although for for ketchup uh kangaroo 12 uh we still just have the the matching thing. It's it's because if you know how kangaroo 12 or like ketchup works internally it's uh it's very straightforward. So it's not so clear that there's there's great ways to optimize it. But the other ones have for instance module. Um so with that overview done um we're open for suggestions for the next binary circuit or other circuit that you would like to see on CK Golf. The hope is to release uh a circuit library of formally verified extremely optimized circuits for basically any type of primitive that

you you would want. Um so we would love to hear your suggestions. Um and I guess one other observation here is that there's been a lot of optimization uh in the in the large field case but it seems that on the binary fields uh there's much less space to optimize. Basically the the straightforward circuit is is is is relative is relatively closer to like the fully the the best possible optimized circuit would be my intuition. And with that I'm ready to take questions. Amazing.

Thank you, Matias. Go ahead. >> Can I can I ask a few questions? >> Yeah. >> Yeah, sure. So, first of all, um considering circuits to optimize, it seems like the natural target is uh integer addition considering it's probably the main the main circuit being actually optimized in chat and blake, right? uh and uh my personal my personal interest is integer multiplication. Uh I think uh I I I think this is probably a good a good thing to know.

>> Is it like a 64 bit 64-bit multiplication or are you >> Well, you you could do many things. You could do uh I I I would s suggest like 64bit um wrapping and and with carry like full 227 bits I guess and um and also the may maybe you you could also check 256 bits because there's actually an instruction in a VM that does that. So so it's probably good idea to check how hard or easy is it.

>> Yeah. Yeah. Yeah. So I mean there >> Okay. Yeah. And uh and and I also have a remark that one of the reasons why boolean circles probably have less space in optimization is because this model is actually well well studied. I guess uh a lot of people already spent a lot of time optimizing them. >> Okay. >> And and in particular these these hash functions are I mean uh also made so that they have efficient boolean circuits, right? >> Oh sorry another question. I think kangaroo about kangaroo I think uh you should compare um hashes that are have comparable capacity. So the pro the compression uh that is able to compress

similar amount of data but kanguru I think has larger width. So maybe you should compare with uh kisak 800 not kisak 1600. Yeah, it's it it's it's it's a bit of a it's a bit of a bad comparison because yeah, you're right like number of constraints per bits is not the same for each one of them. Yeah, I guess one one interesting thing here is uh these hash functions are like very optimized for for boolean circuits. It could also be interesting to consider like higher level um circuits that are not so easily optimized like for instance uh curve operations and stuff like this.

>> Well, then we need to multiply numbers first. We need to know how to multiply numbers. >> And once we have multiplication, maybe we can think of a whole ISA like like risk five. Um that would be very interesting. Thank you so much, Matias. Uh great initiative. >> I I had a question about Blake 3. Um I'm surprised it isn't better. May maybe I'm my mental model of the the cost model is wrong. Um so this is flock constraints, correct? So it's the restricted R1Cs.

>> Um >> are you finding that um that restriction um increases the number of constraints by a lot because so the the lake 2S uh which is basically a naive implementation. We didn't spend much time optimizing it in Sapling. Um was 21,000 and something R1CS. Um and Blake 3 is what is it 7 rounds instead of 10? I can't remember. Um so I'm I'm a bit confused unless it's that um flock restriction that is causing them the legend constraints.

>> I I think I think what uh what explains this is that we're kind of double counting. So in the in the R1CS in the usual R1CS you pay basically one cost unit for increasing the dimension and one cost unit for adding a constraint. So here you're you're you're paying both for increasing the dimension of K and you're also paying for each row. So as K grows by one the other the other thing grows by two. So, so, so this record you can you can broadly divide these these these numbers by by two to get I think what you mean by constraint.

>> Yeah, it's kind of a hold up left over from the generals challenges over over large fields. >> I see. Oh, okay. Thank you. I'll have to look at the concrete efficiency of flock to see whether that's worth it. Regarding the alternative hash functions, in the past there has been a lot of designs optimized for hardware and meaning that they also optimized sort of boolean operations not not exactly boolean multiplication but something different. There were like a lot of hash functions also with very small uh state like spongent and and others. So, and some of them even made it into standards like lightweight cryptography standards for example.

Would be maybe interesting to see them in the benchmark. >> Yep, I agree. >> And Moro makes an interesting comment in the chat that uh if you have lookup tables, it changes the cost model and we might see different types of automations. >> Yeah, >> thank you so much Matias. In the interest of time, we have to move on. Uh Sahil from snark.fast. fast. The floor is yours. >> Thanks. Thanks, Justin. I'm going to do this with Gotham, uh, since he's the architect. Um, so we're extremely excited about multiplayer auto research as a new way to solve some of these optimization problems uh across uh, you know, some of our uh, frontier research

um, cases. So, I'll tell you more about it towards the end, but maybe we can just show you how we set up snark.fast, fast where it is and of course uh excited about solving some of the other um you know cryptography problems. So Gotham, do you want to uh uh share your screen? >> Yeah, sure. I don't have much to share beyond what Justin presented, but um yeah. Okay, so we basically put together a snark.fest here. Um, this is essentially just like a the much stupider version of what ZK Golf is doing. We literally slap a timer around whatever the benchmark is in

>> [clears throat] >> uh, Flux repo. Much thanks to Ron and Tamir from the Succinct team for helping us verify that the code was correct. Uh, and you know, if you have a Mac, we have a benchmark here for Mac. You can click participate and paste something into your agent. We have a bunch of people here where your sort of agent is tracked. you can see how much, you know, people have improved things and everything links out to a PR where you can see what everyone's doing. The agents sort of submit these really detailed somewhat unparable notes about what they're doing. Um, and I guess we were supposed to hear supposed to be here to present that we had something for x86, but it's in the process of getting up right now. So, please uh go

to this page if you're interested and if you have an x86 machine, it will be up in like an hour or two. Thanks Gotham. So maybe I can add a couple of other explorations and then we'll open it up for questions. Uh we'd love any feedback. Uh I think one of the other dimensions we're thinking is um there's uh there's a lot of collaboration that can happen once uh agents submit their notes on what paths and what approaches they took. Uh and I think that is one of the interesting things that uh we're exploring. uh you we we're also doing some early experimentation with credit assignment which strategy contributed how much towards the the uh the frontier metric um and I think those are a few new

interesting things to kind of you know uh get more people to attack uh frontier research problems uh with uh and the new metric is how many what is your token spend uh for for making progress and what is the quality of improvements you can make So yeah, uh also kudos to a bunch of people we're working with uh Ezek Alex on some exciting problems um uh in the future. So please participate uh would love for to have you guys uh join our solver network as well. Um we're open to any questions.

>> One more thing I'd add is like uh Justin had this slide at the beginning where he's like uh you know now that we've got rid of Poseidon, can we also get rid of Blake? So there also may be a opportunity for adding even more sort of uh seeing how much of our cake we can eat basically. >> Why would we want to get rid of Blake? Sorry, I'm not saying motivation. >> Uh use Shhatu instead, right? >> Why? >> I'm I'm I'm just I'm just a messenger here. You saw his meme.

>> Okay. Okay. Yeah. Yeah. People like their government standards. Yeah, that's a whole discussion for possibly the next EF proof call. Um, but yeah, SH is just a little bit older and you know it has more adoption and you know if we want to build this a blockchain wide standard like you know and and have Bitcoin play along then uh that might be a strategic move. Uh but again no decisions have been made and Blake is is definitely awesome. >> Any questions? >> Let the man write your hash functions for you. Yes.

>> [laughter] [gasps] >> Okay. Uh, great. Um, I mean, there was a little bit of a hint here at, uh, you know, working with Alex and ZK security on something new. So, uh, great segue. I'd like to, uh, pass on the the floor to Alex Hicks. >> Yeah, thank you very much. Let me quickly share screen. Oh, I need to wait for the other one to stop sharing.

>> Uh, go, would you mind stopping the show? >> Yes, sir. >> All right. So, uh, this should work. So, yeah, as uh, as was hinted at uh, basically about a second ago, we have a new auto researching which is coming. You can find the website is already online. It's better. Uh this will host an auto research project that is going to target the proximity gap uh conjectures. Uh more specifically, we have a formalization in lean of the contents of the open problems in line decoding paper that Dan

Jakamo and um G have written. uh this is formalization of both the grand challenges there which is the coding theory part as well as the toy IOP which is uh which is also described there it's all built on top of arib so we reuse the ark formalism for the IAS uh which we used to construct the IOP we have a proof of soundness for the IOP which is there as well and uh very very soon uh you'll be able to then auto research trying to improve the number of provable bits for the toy IOP over uh the sex dick extension of Koala Bear with interle solment codes. Uh the bottleneck is currently my CPU compiling everything [laughter]

that will hopefully go away very soon. Uh and so we were hoping to get it launched in time and open for submission by this call. Uh you know most likely it will be probably a bit later tonight. Uh but you can all start warming up and uh it'll be very interesting. I think an important difference between this challenge and the ones is of course that people are going to submit proofs. The search base for proofs can be quite wide. We might see different techniques using different branches of mathematics. We've seen this so far on work in the conjectures of course uh you know kind of last year around last November there were several papers that all had different proof techniques. So it'll be very exciting as a kind of different challenge and uh I will also say we're starting with one challenge you know kind of hopefully today there'll be more

challenges coming we'll have the conjectures you know restated for binary fields and other things. So this is very much the start and uh it's certainly quite far away from the end. Uh and that's it. Good luck to everyone. >> Amazing. Uh we have a question from Gorg. Uh to what degree is this more than just a way to donate tokens? I'd be super interested to understand how diversity in models promotion techniques contribute to overall better result. Uh so my my um at least my impression from having partated in ZK Golf and Snow Golf Fast is that uh there's quite a big role still in kind of human expertise

and guiding uh obviously the optimization direction that your model goes in as well as finding of you new solutions. It's obvious that if you don't know what to look at, you're going to point claw to something and it's going to just find some module improvement on whatever the current leaderboard submission is. uh with snotfest I mean we kept seeing even like 7% improvements when we were past 1.5 million uh compressions per second which is pretty incredible. Um token diversity is kind of token counts and model diversity I think is actually hard to estimate because some people have a kind of coordinator model which they use and which the submission originates from but a lot of the work might be done by other models which are being orchestrated in

some way so that's not very transparent. uh and then I think promoting techniques makes quite a big difference. I'm very hopeful that actually from this proximity prize order research that actually will probably generate a lot of maybe interesting lemas and proof techniques that we can then upstream into arib and certainly kind of make available to to everyone and maybe you know there's a obviously proximity prize has a human element to it. uh the prize is split 50/50 between kind of peer-reviewed publications as well as this auto research prize. And it would be very very cool if we could generate interesting content that then uh makes it back into kind of peer-reviewed papers and uh kind of informalized and communicated in in a nice way. Um so it should be interesting. Uh the other thing I would add is uh I think there's

quite a bit of interesting scope for finding uh negative results or impossibility results. I played around with this with ZK Golf where I was able to stop my model from going down stupid paths by instead having proof in lean that some optimization wouldn't work or generalize further than how it had been applied and uh and so kind of uh I want to think about how to encourage people to submit impossibility results as well and to kind of share these with other participants since that seems quite interesting. Uh and of course when you talk about an IP you might have you know attacks and upper bounds on security which you know this will uh this will definitely show up as a challenge as well on the website.

>> Yeah we've seen very high correlation between the submitter the human submitter and the type of submission on other auto research challenges like ecdsa.fvfail. Uh and one piece of alpha is that there's going to be an archive paper for the ecdsa.fail fail coming very very soon. Um and kind of distilling some of the learnings about auto research in general in addition to all of the quantum innovations uh that would brought to the to the table. Um congratulations Alex. I know you've worked extremely hard on this and uh yeah I guess it's coming either today, Friday, maybe over the weekend. Uh and that's kind of the second uh auto research challenge that is landing

because we're also going to have the x86 uh challenge for snark.fest. Um and one piece of alpha is that uh we're working on yet another auto research challenge which will be uh probably announced during the next proof uh call. Great. So now we're going to start the binary fields presentations and I'd like to give the floor uh to Ron and Benedict uh to talk about uh flock the recent breakthrough paper. >> Sounds great. Let me share the slides.

Uh can you see that? Can you hear me? >> Yes. >> Awesome. Cool. So uh cool. So thanks for having me. Uh let me talk about flop. I guess uh it was mentioned a little bit before as well. This is joint work with Benedict and and William um which we only published like two months ago. Um so the starting point at least uh for for my end for for this work was um I coming kind of from the theory side of proof system research and all the way back in 2020 I was uh looking at this question of like very quickly proving correctness of boolean computations and we published this paper together with NOGA on proving as fast as computing and we show that you know for general boolean circuits um which we

were interested in because they're like a very clean theoretical model we can prove kind of asically today's fastest computing, but this was hiding very large constants. And kind of recently with Benedict and Wigan, we were asking, you know, can we push this line of work into practice and actually get, you know, something that is completely efficient and you know what is kind of the the fastest you can prove over native uh native execution. Um so the setting we focused on with FL was the setting of sort of a batch computation. So we modeled the computation as an R1C instance essentially. you think of it as a booing circuit and you're proving many of these um and maybe on top of that you have some like minimal logic uh to connect uh like inputs and outputs and for me you

know this is like a a general setting of proving boolean circuits which I'm really interested in but a particular application for proving correctness of kind of standard hash functions like blake or sha and so on um so we we implemented this we sort of did a lot of uh very heavy usage of AI I for for the coding we rely on many um existing ideas which we combined I think in an interesting way and introduced uh quite a few new optimizations uh on top and I think we got results that at least I was kind of surprised by uh by which you can get the overhead for like single core proving over just native execution of the hash to be 250 sometimes uh even

uh less 200. This is on kind of consumer laptop from from last year. And maybe a headline number is for Blake 3 compressions using uh you know the 10 core computer you can improve over 600,000 uh compressions of the hash uh in a second. Um which kind of is pretty surprising. I think this is uh you know purely the the system itself is hashbased. Um these numbers were based on SHA 256 for security. Um it is with 100 bits of security. Uh yeah and we got sort of um I think nice speed ups over other systems. This is these are numbers back from June. I know that

hash caster has improved since um probably ben as well. I'm not I'm not sure but it was kind of like quite fast. Um and that's that was sort of what we did in in June and I feel feel like ever since kind of um there's a lot of energy around binary theories and you know this talk is further evidence of that and a lot of progress so let me mention a few some of which were already mentioned so zk.gov golf getting like smarter RMCS instances start out fast crazy speed ups using uh auto research we'll hear later I think about uh the GPU acceleration and also Gul will talk about this new uh his new work on on agitate geometry and Tamir Eugene will also say

more about x86 and kud what I wanted to uh mention is a new version of flock that we're sort of announcing today which um kind of uh the ne next I think significant step with flock which in which we were trying to like support um new functionality and get like other improvements. So first of all instead of just being able to prove a single hash now we can prove many different hashes or other types of logic all of these are connected using a machinery uh called the jagged PCS which we introduced with SQ1 hyper cube uh last year. We support kind of a more rich wiring which lets us like prove in general like circuits. Um this is via grand product GKR argument. We support now 128 bits of security and we do this

while actually um still working with 128 bit field except in the PCS um which kind of leads to better efficiency and all of this is still without incorporating the agit and the snark that fast improvements. So uh I'm going to show you numbers. These the numbers are only going to improve um and we know they're going to improve significantly. So in terms of like just raw throughput, if you use uh the new version of lock just to prove Blake 3 compressions, even though we have all of this new machinery to support uh wiring and extra tables and so on, the performance has uh improved for 100 bits of security. And this is largely because we could using the new architecture, we could leverage a better R1C um for for Blake 3. And

using 128 bits of security, we're getting um not quite as good throughput, but but quite good. I think there's room for improvement for with 128 bits as well. What I am most excited about is that because we're now able to prove circuits uh with FlockB 2, we can prove our our own verification circuit. And as a proof of concept of this, we implemented uh kind of a recursive hash chain again at 128 bits of security. So the idea is you want to prove a very very very large number of hashes and what you do is you break them into uh chunks. Each chunk is like two to the 18 blrees let's say um for each chunk you produce a flop proof but now you can combine these proofs in say a tree like manner and you know uh

orc and get eventually a single proof and what I think is really compelling are are the numbers. So each 2:1 compression we can do it 200 milliseconds again on the same uh M4 laptop. Um and the proof size is 250 kilobytes. Um just as a headline with 100 bits of security the recursion is 140 milliseconds and again this is without uh the AG skip which would improve things or the auto research. So just like uh briefly to say what our next step or just like open questions um some of them are engineering some of them are kind of more in the math side.

Um so if we're able to we know we can add the AG skip and that should like speed up uh things quite quite a bit. Snark that fast is kind of crazy improvements but we still need to see how we exactly digest them. Um and last and you know better proximity gaps for smarter proofs faster recursion and there even within the Johnson bound which some may think is a soft problem getting better errors could like greatly uh improve things. Second question um that I think um we're going to hear more talks about later on is even further enriching the functionality of of vlog doing uh some sort of either lean VM or full-fledged uh risk 5 uh ZKVM there challenge is handling integer

multiplication which I think that Le would also speak about and lastly I think um one remaining place which feels to me suboptimal in in the space is getting better lookup arguments so that I think is something we'd also love to resolve. Um yeah, the repository is online. There's a branch called version circuit which has kind of fluff v2 and happy to take questions. >> Wow, amazing. I had no idea about V2 and 2:1 recursion in 200 milliseconds. That is absolutely amazing. Congratulations guys. Um so one question is where can we look at the code? I think that's been answered.

Um any more questions feel free to just unmute raise your hand or ask in the chat. >> Uh what's the Oh, you you gave the proof size for 128 bits which was uh 255k. Is it any smaller if you go down or larger if you got how does it scale with the >> Oh, sorry. With the with bits with a bit of security only. >> Yeah. Um, I think we should be able to get to like, if I'm not mistaken, to 200 kilobytes with 100 bits of security. Um, I don't recommend going below. Are you asking about higher bits of security or >> um, so let's say, um, I want proven security

for postquantum. Um, uh, that is is it 128 bits of classical security gives you 255? I mean, so okay. So if you're worried about things like I'm not an expert on this. If you're worried about things like Grover search, then I don't think it's like >> No, I'm not worried about Grover. >> Yeah. Then I mean everything is is >> But I'm worried about Yeah, I am worried about proving things in the QROM to to make sure that >> Right. So I don't I don't know what's the state of the art here for me when I I I should not have even said bit of security. I just mean the maximal round by roundness here uh of the protocol.

>> Right. Okay. All right. I think I answer my question. Okay. So I I guess I have a question um like does going can can you go to intermediate uh size between 128 and 256? >> Yeah I mean especially like as you go to like um so the main thing that's most costly you know we have this big gap like say for recursion 140 milliseconds up to 200 for 128 bits of security. The main cause for this is that the correlated agreement uh error that we have from the 2025 paper by uh Ellie and and Urik and Swastik um kind of the numerator is not I mean the paper is amazing and it's fantastic result that

we heavily rely on but it feels that the constants there are not as good as maybe I would hope for them to be. Um, I think if you give me like 110 bits of security, then you could probably have the same speed as the as the 100 bits of security if that matters. Um, but like 120 is already kind of like past what we can just saw with grinding with such smart proofs and faster recursion. On the topic of proof size, I expect that proof sizes will significantly improve by next if proof call. Uh one piece of alpha is that Elon Yv has a

very significant uh proof size optimization that he's cooking. Uh and I also expect that the better codes uh will provide some partial results. Part of the reason why I have this confidence is because we've already started you know uh privately uh running the AIS on these on these statements and they're already finding uh you know new results uh at least internally. Uh so yeah very exciting times from a a proof size perspective. It is. It is. I It is. I had an amazing experience kind of proving stuff with um Claude and it used four different um areas of mathematics that I didn't know in enough depth to do this. Um yeah, it's fantastic.

>> Yeah. And uh get ready for Rahul's talk later on which will have some really hardcore algebraic geometry. Absolutely. Um >> Benedict, do you also have a presentation? No, no. We >> We thought it wouldn't be too distracting to switch though. >> Okay, cool. >> May I ask one more uh question if we have time? >> Uh so um you mentioned that you looked at the proofs um for miracle tree like construction uh and how to optimize that. But um did you have a chance to look at something that is more of a like a single chain of hash evaluations?

>> Yeah. Um so at two levels so um at the flock v1 already we had uh support for so the basic system was just proving a bunch of hashes unrelated but we also supported proving them in the chain with essentially maybe 1% overhead essentially within noise um but that's like it was somewhat tailored to the chain situation in flock v2 we have we have more flexibility you can write down sort of a circuit um involving these hashes if you like write down kind of a a circuit and treat it in a generic way that introduces a little bit of overhead but but not too bad. And in particular, what I described with the recursion thing is just like proving a ton of hashes. So you can think of each leaf in

the recursion as just proving an individual hash chain and then the recursion is combining them. >> Amazing. Thank you. >> Sure. Wow, Ron, I'm I'm really speechless. I'm I don't know how you guys move so fast. Uh I guess AI plays a big role, but >> Absolutely. Absolutely. >> Crazy times. Okay. Uh next up, let me just have a quick look at the calendar. We have uh Jim, who will talk about uh Benas.

Yep. One sec. Okay. Uh, you can see Binas. >> Cool. Um, okay. So, a lot of people on this call have probably heard of Binas, but as a recap, there's a as of the end of last year, we basically rewrote the system uh as a new way to assemble the components with somewhat different goals from the original one. So, this is Binas 64, which is the currently maintained and developed version of Binas. Uh, and the goal of it is fast client side proofing for zero knowledge proofs. uh which has

a lot in common with but also is somewhat at odds with like massive like infinitely scalable uh high performance building VMs. Um it's supposed to be efficient for proving classical symmetric cryptography. That's one of the big things that binary fields can deliver. And then aside from that the goals are uh to have a simple secure platform with good developer experience to build these types of privacy preserving client side applications. So some examples uh the very first one we built that was driving development is zk login which is uh or a copy of it that's the name of a paper that does zero knowledge proofs of RSA signed JSON web

tokens. Um, another example is the type of hashbased signature aggregation that uh the lean Ethereum uh project is is planning on. And another recent application or demo is BIP 32 bitcoin address derivation which is a collaboration I did with project 11 that is sort of a a potential solution to the bitcoin post migration problem. So these are the types of applications that we want this library to support.

Uh the computation model is not boolean circuits but it's very close. It's circuits over 64-bit words and the computation model allows for a pretty rich set of gates that you would naturally find in instruction set architectures and such. So bitwise and/or exor bit shifts uh both 64-bit and 32-bit variance integer comparisons uh select um and then there's a special ghash multiplication instruction and a specially accelerated integer multiplication instruction which is uh not listed in this. And then the computation model can have non-deterministic hints. So these are

computations that are not that you must constrain yourself but will derive some values uh from some other values. So this is a circuit model not a VM. Circuits don't have branching um and they don't have writable memory but despite that it's still a very powerful model and very simple to build a protocol around and use and is fairly low overhead. Oops. Okay. So, the new thing that has been in progress for uh you know the last two months or so is a multi-chip architecture and this is somewhat

prompted by or in large part prompted by the numbers that Flock was able to get. Um the biggest or one of the biggest causes for the flock binia 64 performance gap is the expensive wiring check that you incur when you have a monolithic circuit. Um that was actually the dominant step in in proving time. Um and it also made verification very slow because the verifier needs to know this entire wiring circuit and do it. Um so Binia 64 now supports a multi-chip circuit architecture where you can write uh subchipss with data parallel subcircuits which is something you see in uh I think failank originally but uh

flock jolt etc. And then we have a primary single instance circuit which takes in the statement and sort of dispatches these chip calls and the chip calls can be arranged as a a cyclic graph of calls. Um this almost completely eliminates the wiring overhead for proving and verifying. Um and so uh there's one caveat. It's the feature is almost complete except that it does not yet constrain uh that any of the chips are talking to each other. But I think that's a fairly small um thing that shouldn't affect the [clears throat] proving numbers that uh you'll see in a minute. So that's coming very soon. Uh cure chip benchmarks. I

hate benchmarking competitor code bases because I don't really know what's going on, but um on the AWS Graviton instance that I've done all my benchmarking on, the numbers deviate pretty significantly from what you see in the paper. So I wanted to put this for comparison. Um these are three hasher uh benchmarks. The proving time is worse than flock um by something like 20 to 30% in most cases. I think catch's fairly competitive. Uh witness gen has some some issues that could be improved on.

Um but the the proving performance has gotten a lot closer than what was shown in the flock paper. This is based on the flock main branch codebase. So if there's more improvements that are new then uh this doesn't incorporate that. Oh and then uh one thing I wanted to add is that we have a a library for uh SECP256 K1 point edition which is just to demonstrate that there's an int multiplication accelerated protocol in binius 64 that can that's really powerful for the types of things you might actually want to prove in a zero knowledge proof.

Um as a case study of the multi-chip architecture we implemented XMSS signature aggregation. So the statement is something like you have n signers signing a single message. Their hashbased signatures are the witness data. And then the architecture is you have a tiny glue circuit that dispatches chip calls to the XMSSS verifier which dispatches chip calls to the core the hashing core and can basically do uh something like 500 XMSS verifications in a second based on uh Blake 3 and otherwise the um a specification for this that is in the Ethereum leanb uh

codebase. Um, and then the last thing is the binas library is developed to be fairly modular but also opinionated but there's a lot of uh batteries included. So there's lookups, there's a zk wrapper proof. It actually you know you can run proofs to be either zk or nonzk and recursion is very close but not done before this call. Um and when I say we, this is uh the list of people who have been contributing recently. Um many thanks to Thomas for a ton of really good uh work here and uh Wilson, Latif, Paul, and Project 11 for uh working with me on the BIP 32 thing.

>> Amazing. Uh thank you so much, Jim. Uh Benedict asks, "How does a sepsk one scaler more compare to a hash function invocation?" Eglake. let's see. Let me go back to the benchmarks. Uh so we could do uh 16,000 around 16,000 EC point ads per second and Blake was getting something around uh to the 17 128,000 per second. Uh yeah, something like that. So they're slower by a factor of eightish.

>> That's a that's a scaling addition. A uh wait no a point addition between two points. >> A point addition. Okay. >> Point edition. >> Scal yeah point edition. So scala mole is even >> faster >> like >> wait >> no the gap is bigger like it's like uh if I prove let's say proving one hash function versus proving one scalable >> oh sorry >> 800 times faster. I can prove 800 hashes while I can prove one >> scalar right >> depend depending what >> scale algorithm algorithm use. Yeah >> the also the library um has a fairly

sophisticated way of doing sep stuff. So it does the endomorphism trick and also it does uh strauss for multiscaler multiplication. So for things like BIP 32, you can um it's not just sort of 256 point additions to do a few uh scalar moles. >> Um Jim, a quick question for me. So within the EF we kind of have lean VMBB with Emil. We have Tomas spending a lot of time uh helping with uh with vignia 64 and there's like all sorts of other

kind of parallel efforts. Do you see an opportunity to have some sort of uh equivalent of plunky 3 maybe plunky 3B or some other name uh for for binary fields? >> Yeah, I mean that's really what I hope could become. So I mean to comment on I don't necessarily think that the binius 64 circuit model is going to be the best for you know building a risk 5 VM or something. Uh you get efficiency from doing the boolean circuit with massive data parallelism. the 64-bit model is meant for circuits, but I think there's a lot of high quality code in the binas codebase like a portable

multi- uh multiarchchitecture field library and um it would be possible to build you know more and more sophisticated binary field protocols using some of the the components that are in there. So if people are interested in uh helping drive binas into that direction uh talk to me. >> Maybe I can also mention that in flap we borrowed some of the binius code and really appreciate both both the code also the research papers. So >> oh sorry one thing I did want to mention also I'll drop a link but uh there's a binius.xyz website but also binius.xyz.pdf PDF is a fairly complete protocol specification which I think is really

important for cryptography protocols to actually say what they're doing. Um, >> absolutely. Uh, repeat that URL. >> binas.xyz.pdf. >> Um, it's fairly up to date. It still needs the multi-chip architecture stuff, but uh, yeah. Amazing. Thank you so much, Jim, both for, you know, your original ideas in 2023 and, you know, persevering all the way up to to now and, uh, you know, so much potential for for BU 64, uh, potentially as a library. Uh, next up, we have, uh,

threef uh, who will talk about binary Spartan Let's see. And I believe the paper has been submitted to e-rint several days ago, but uh they seem to be on holiday at errint. >> Sorry, I'm facing some issue with uh sharing. Let me I may have to rejoin because it I had to change settings.

>> No worries. See you soon. Uh in the meantime, let's move along uh with Rahul uh who will talk about fast binary zero check using some fancy algebraic geometry. >> Hello everyone. Uh let's see. Let me just share. Uh here we go. Okay. Sorry. Uh spoilers. Um okay. Right. So I'll be talking about a new sort of uh gadget uh called ag skip which is uh the point of this is to optimize the round skipping in binary sum checks. So let me start with the sort of overview of what the problem binary sum check round skipping is

trying to solve. So this is a sort of technical optimization to the sum check protocol. uh when you input data in a small field and uh the problem here is that the sum check protocol it needs to work in a very big field to achieve soundness the sort of challenges you draw in every round they have to come from like a very big set and you need to use this thing that a polinomial doesn't have too many roots and so on and so forth um so very roughly um this is not like 100% accurate but you can think of it in this way that uh the first round of sum check uh basically it takes about order of data work over the field in which your input data is uh however the later rounds basically they take 2 n * o of data work over the bigger field that you

need for soundness. So if you compute this out what you can say is that round sort of two to whatever end up being extremely expensive compared to your first round. So the trick people normally use is that you want to find a way to increase the work that you do in round one to sort of skip these like very expensive two to whatever rounds. And uh in 2013 basically uh Mir uh found a sort of abstract formalism for how sumch works that uh the way you can do this round skipping is you can find a certain kind of error correcting code uh over your big field um with message length to the power the number of rounds and uh if this error correcting code has the right properties uh this lets you

skip add rounds. Um so right it needs to satisfy certain unusual properties that maybe you don't ask for normally in the theory of error correcting codes but uh it turns out that there's a standard choice you can make that you can use read solomon codes and they satisfy all these properties and putting these two things together you get something that's normally called trick or univariat skip. Okay so that's the problem that we're trying to solve. Uh we're trying to do this technical optimization to sum check. We reduce it abstractly down to finding a particular kind of air correcting code. uh let's talk about the kind of error correcting code that we need.

So here are the here's the property that the code needs to have. So basically it's something called multiplicativity with a little with a few bells and whistles. So what is multiplicativity? Multiplicativity means that we have an error correcting code C. There exists a product code that will denote C star such that uh well if you have two messages of C then you can sort of multiply them together to get a message of C star satisfying a few properties. Uh so if you encode the two things of C and you take a pointwise product uh that is basically the encoded message of C star. So this is sort of the important like the core thing of multiplicativity.

Um and the other part is that when you take this product on the message side, not on the code word side, uh the prefix of that is basically the pointwise product of your messages. So putting these two things together, this is the thing that lets you do like nonlinear sum checks. Uh the next thing you need is that C star has extremely large minimum distance. Um and this is basically for the first round uh challenge soundness. And the last thing you need is that this is sort of where the optimization comes from that if you start with two C messages in your base field f_sub_2.

Then when you look at their product um that product the entries of that are in some small field f2 to the k for some small k. Uh so we are going to achieve k equals 1 uh the which is where most of the improvement comes from. Uh read solomon codes give you k equals n. And uh this is where the optimization comes. So your first round can be over f_sub_2 to the k instead of f_sub_2 to the 128. So if you look at how the work uh works in sum check basically the thing you want to minimize is uh this field k uh multiplied by the dimension of c star minus the dimension of c and however small you can make this number uh that's how efficient your code skipping ends up being your your round skipping ends up being. uh there's a sort of second

optimization but this this value k times this difference of dimensions is sort of the main thing that you want to optimize. Okay so basically like the the point of this work is we find a code that makes this much smaller than the read solomon value. Okay so we find this code using algebraic geometry and there's a particular construction called a differential goa codes. Um so how does this construction work? Well, the first thing we're going to do is we're going to choose a system of polomial equations in d variables that has greater than or equal to 2 to the n solutions over f_sub_2. And the solution needs to basically be one-dimensional in some technical sense. The system of

equations. Uh so then uh you can bring in the algebraic geometry input. So if you satisfy a lot of technical properties, if X satisfies enough technical properties, then what you can do is you can take X and you can produce two vector spaces of rational functions L1 and L2. Uh and you think of these as functions on the solution set of X and these two vector spaces of rational functions are going to satisfy some properties and these properties are sort of going to line up with the properties of the code that we're trying to satisfy. So first property if you have two functions rational functions in L1 then their product is inside L2 and the second two properties are basically interpolation properties um where if you take a function in L1 it

can be interpolated from the evaluations at 2 to the nu at the 2 to the n f2 points uh f2 solutions of this uh system of equations x and uh if you take something in L2 it can be interpolated from these evaluations and basically a bunch of derivatives that you add on top of these evaluations. These are just rational functions. Polomial divided by polomial. So you can take derivatives and uh just like you can interpret univari polinomials from evaluations and derivatives, you can evaluate these rational functions from evaluations and derivatives. So the algebraic geometry input is basically it checks all the technical conditions and it gives you this input.

Um so how do we get the code from these two vector spaces? Uh so C is basically going to be an interpolation code. Your message is the evaluations at these points. Encoding is interpolate and then you can evaluate at the big field solutions. CR is similarly an interpolation. And in this way this product map is you basically you take your two messages, interpolate them, evaluate the derivatives to get the C star input data and then you can multiply those derivatives using the product rule. So these are all very simple things and if you do the cost accounting here uh basically your cost comes from optimizing dim of C star.

Okay. So uh the explicit construction was done by AI. Uh we'll focus on skipping six rounds. So 2 to the N is 64. Um the next algebraic geometry input is that the dimension of C star is determined by a by a invariant of X called it genus. So the goal is you want to find the lowest genus X with 64 solutions. compute the explicit L1 and L2 using the algebraic geometry inputs and do the interpolation maps. Um so the old the last generation of models can do this in a weekend. I really want to emphasize that this was a project that was seriously unlocked by AI. This would not have been practical to do without LLM. Um so uh this would have been a monthslong computation requiring experts in this very like specific field of algebraic geometry um which none of us

are. And uh the key point here is that you have the complicated math construction but um because everything is worked on to explicit matrices and polomials at the end um and the properties of the code are very combinatorial once you've constructed everything uh you can check that your code is valid by scripts and elementary math you can completely forget about the algebraic geometry once the construction is done. So you have easy verification and this is very important for anything you generate with AI. So how well does the construction work? Well, basically this optimization goal is about 158 versus about 380 for uh um for Reed Solomon. Uh even better. Um you work over F2 instead of F64. The arithmetic

is much more hardware friendly and overall you get basically a 2x speed up to the zero check part of the flock protocol which I think is the main bottleneck. Um >> uh what is the genus of the result? >> Uh the genus it's 95. What? >> 95. Yeah. >> Yeah. Sorry. Is that crazy? Yeah. This is why you need the AI to do all the computations for you because it's very >> Well, okay. Okay.

>> Yeah. Yeah. So, this is this this Yeah. So, I think this is like a >> No, it's more like it's more like surprising that that there are this such special curve of genus 95. >> Yeah. It's amazing right because of >> yeah it's it's a small point thing like the the linear factor uh asmtoically is much worse but apparently 64 is small enough that you can beat that linear factor >> um and you can yeah you can do this with a genus 95 curve. >> So can you find similar curves also for higher higher characteristic fields or is this specific to uh characteristic characteristic 2?

>> Uh it seems like a general sort of like special thing. Um there's a website many points you can look at uh many points.com where people have been trying to track records of uh um uh sort of low genus curves with lots of points. Um [snorts] and uh yeah uh so you can see there that there there's a result that says that like asmtoically as your genus gets very high the number of points is some linear scaling of what you have. It's upper bounded by that. But uh if you look at that site, you can see that for like it takes a long time for that asmtotic to kick in.

>> Mhm. >> So yeah, this is an entire field of like math that people have been working on very hard and uh it's yeah, um it's it's very nice that they did all that work already because uh that's what the AI was able to take advantage of to uh find a find a new curve with 64 F2 points. Yeah. >> [snorts] >> Bro, >> have you submitted a paper on errint for this? >> No, this is not submitted yet. Um, so for embarrassing reasons, um, basically I I wrote a draft and uh it was not readable to people in coding theory. So I think uh Ron and Tamir uh have a version that's fixed up that should be there next week. Um hopefully we'll see

what happens. >> Amazing. Just then regarding your question, I think uh one thing that's as I understand of F2 that's nice is we're anyway implementing like for over read Solomon we anyway implemented the the FFT using a matrix multiplication. So essentially just lookups and with the AG code it just becomes a different lookup that's in fact even more efficient because exactly of what Ru has here on the slide. I think once you get over larger fields, it's not clear to me that sort of the same uh matrix multiplication like then maybe you pay for this quadratic cost like this doesn't actually have a faster encoding

algorithm but we don't care. Yeah, I think larger field you probably do not care that much about that. Like you can use normal univer skip which already has optimal properties of your field is at least like what uh basically two to the power size you want to skip. >> Yeah. You don't pay much of a cost of your input datas in a bigger field. This is the binary is sort of where the benefit is biggest because like the the soundness field is so much bigger than the bass field.

Thank you so much Rahul. This is uh fascinating. Uh we have many questions in the chat but in the interest of time let's move forward. Anyone who has questions, if you go to the agenda on uh the ERI community call, there's a a link to Rahul's Telegram handle. So, you can just DM him with all your ideas and hopefully that will lead to fruitful collaborations. Um Sinaf, do you want to try again? It's better this time. Okay.

All right. Can you guys see my screen? >> Yes, perfect. Thank you. >> All right. So, I'm going to be talking about this binary Spartan. It's uh it's it's not a new proof system. It's just a Spartan over binary fields. Uh it provides transparent proofs. Proofs are poly loarithmic plausibly postquantum. There's a short note about this work. Uh it's supposed it's supposed to it was submitted last week. it so it could be public anytime. Just a quick recap on Spartan. Spartan is a proof system from 2019. It's a snark for R1 CS. Uh it's generic over a multilinear polomial commitment scheme and in prior works it has been

instantiated over different uh commitment schemes like group based lat based also hashbased. It also works for both types of fields prime fields and binary fields. The proof system itself is lean and fast because it only commits to the witness runs two checks and produces a proof of the witness polinomial at exactly one point. So one question that I had was uh what happens if you just uh do an implementation of this uh scheme over binary fields. So here is one slide that depicts the performance of such a system. On the left there is throughput on various uh standard hash functions. On the right uh we depict latency of a proving a single

hash function. As you can see just uh just doing a implementation of known techniques we can already get uh pass 200,000 hashes per second for shto 56 and cross 400,000 hashes per second for bleak 3. Even on the latency you can see that uh it's significantly faster than many other schemes. In fact, it's the fastest scheme in the the client side proving benchmark of uh ATM foundation. So what did we actually build? So here is a a single slide that depicts uh uh the the scheme that was implemented. Uh so we have the Spartan protocol and we instantiate this with the liarto polomial commitment scheme and then we

implement six optimizations and all of these optimizations are widely used in the literature and also in many implementations. In fact five of these six were developed in the context of prime fields and four out of six were developed in the context of elliptic curve snarks and nearly all of these uh optimizations are present in modern Spartan implementations. For example, uh Spartan and Jolt implements five out of those six optimizations and Oh, three and a half. We might be losing

you. Um, let's try turning off your video. So this sorry uh we can't hear you. Uh we're losing you. Um let's see if it gets better within the next few seconds. If not, we can move forward to an Andrea.

Cool. Yeah, let's just move forward. Uh, Andrea, are you ready? >> Uh, yeah. If we don't want to wait for for him to reset, I can I can jump in. >> Let's see if he's back. Um, yeah, let's just go ahead. >> Yeah, sure. So, I'll be speaking about both Liherita and Bolt. So, it's been it's going to be two two presentations in a row for me. Um, let me just uh share the right screen.

You should see this, right? >> Yep. Perfect. >> Okay. Is there a wait presentation? Yeah. Okay. Wait. Sorry. Um, okay. Okay. So this is my joint work uh with Kilarma from uh 2024 2025 actually. Um so I'm going to talk a little bit about this scheme. So we are going to look how leerto was developed what's the core idea um what we uh published first how we used binary fields um back then and also since we had like a lot of questions um what is like comparison

with we what's the relation what's the difference I'll just try to cover some stuff that I know if anybody knows anything else um feel free to jump in or uh or send the more resources. Um, so I think the the audience here is like good enough. So we don't need to go through what is like a multilinear PCS. But um the idea of Lurito was to build um a state-of-the-art multilinear PCS that was quite agnostic. So it was not depending on uh any linear code. It was not depending on a finite field. Um so it was like quite generic.

okay so I think the the the main main idea of how Lehi works is uh that it's literally you can imagine it as delegating leero verifier and having this like recursive protocol um having like doing it enough time uh before the instance becomes too small then we can just send it. So uh how liero in general works. So we have some data matrix uh we pick like some linear code and we commit to the columns of these matrices.

uh like we commit to rows of this matrix we are for example marker tree and uh some hash function we like and then verify send some randomness and for the multilinear uh polinomial commission schemes uh this randomness is not just any randomness it's come uh we are forming this like eq vector and then we are essentially doing a matrix vector product with this so um what really happens in this protocol is that verifier then uh queries um given like the the security we care about queries some of the rows of this committed matrix and then it checks a bunch of inner products. So um leerto and its

core you can just imagine this as a variant of code switch where essentially what you do is instead of sending m to the verifier and then verifier is like doing this inner products we are delegating this to the prover in a new realm. So prover then instead of sending M it commits to M. Um and here is the nice property. It can pick any dimension how it wants to commit to the new message like this uh new like folding whatever dimension. It can pick different code different whatever it commits to it. And then we run one recursive instance to check this uh now

lio or like another recursive instance of Lehi. And then um there is also like a bunch of these sub checks that we have to prove and we can batch them all together. It works very nicely. The one expensive check would be to delegate proving hashes or uh it was before before flock but essentially you can leave verifier doing um a few more like a few very fast hashes um and then delegate the inner products. So then um if you want to make liarto succinct is happening sorry for this if you want

to make liarita succinct you need um somewhat structured code so our implementation and what we were target I think back then was like um read solomon codes and over binary fields but that doesn't matter for this part so using any like generic linear code. Um the verifier would be linear. Um there is like a structure to exploit which is given the EQ vector which is a tensor product of this like um like vectors of like len 2. If the row of the generator matrix of code you use can also be written as a tensor product of these

small vectors, you can actually compute um the this product in logarithmic work. And if you think about what is the last step of the checking this uh sun check, it's actually like evaluating polomial like polomials in a random point. So the hard part for the verifier is to evaluate this row um treated as like a it's lowderee extension in a random point. Uh when this row is structured actually verifier can do that in the in uh in logarithmic time. uh if you want to uh for example use some other code you can also imagine having like another

snark where you just delegate this like again linear work to the prover where I don't know if you want to use ra code or some other code you can also have a specialized snark doing this for the verifier so the protocol itself is very uh very uh modular um you can do this for like both of our like additive and multiplicative fields for reach element. And yes, what we first did uh I'm super sorry about this. What we first did um uh in our like implementation that is now like ancient in terms of uh what are the speeds and what are people doing with the AI and

all the optimizations. We were anyway even then uh very bullish on doing these things over binary fields and we were trying to just demonstrate that we don't need all these GPUs and that we can have like a very efficient snarks running on CPUs client side um and consumer hardware. So the whole point and why are we here now is that we have this like CPU instructions that are very efficient to handling multiplication in binary fields and additions as we know is just sore. So as I maybe mentioned lurico is again coming as a very flexible protocol. So each recursive step you can

pick a different dimension for folding. Uh if you're always using the same code, it can still be like different rate and you can also just be creative and pick different code as you're recursing um through dimensions. And then um what do we know from like uh relation and what happened with like um uh with weird? So like original weird paper if we understand it correctly it was way more like [snorts] algebraic in nature. It was um type of a code switch but it was using it was like curated to just use the the prime field rate Solomon and then literally if

somebody's here uh maybe I forgot but literally like a few days before we published the paper and implementation there was also a PR made um in V repository starting to mention interle uh interled codes. So at this point I don't know um but in like when I spoke to Jako seems that we are now like conversed to having like essentially the same protocol. Um but I think that these two things were developed from like a very different ideas and it was just interesting to think about which perspectives we took. Um, so yes, again, if I said something wrong here, uh, feel

free to, uh, feel free to stop me and point to other stuff, but I think that, um, there was like, I I think two days before we published or something like that, the the the PR uh, starting to mention interlomman codes in V repository. And yes also as this uh this uh code this call is like very oriented towards flock um I'm very happy to say that uh the the current implementation uses alleherita that we have um for for flock system. So yes let me know if you have any questions and then I can jump on the other presentation.

Andrea, we uh very tight on time. Uh so my suggestion would be to just go ahead with the next presentation. >> Okay. Uh yes, sure. Um this is on the other paper we had uh called Bolt. So my share screen is now not working right, but it was just working. Uh sorry about this. Um let me just try to reset everything. Sorry. I know we are tight. Um share.

Uh yes, now it should work, I think. Okay. And sorry for this presentation mode in Google Chrome is not the best. I thought it's better. Uh yes, it's not working. Okay. So, this is a work I had with Kobe and Ron who I think are both here. Um so I just said we were having this work um called Liharto which is multilinear PCS and Bolt is another multilinear PCS which was trying to optimize this further. So again we all know what is the multilinear PCS here and I'll try to make this presentation faster. So what we saw with the years was that read Solomon codes were very

efficient, very nice to handle. They have this beautiful structures that we can exploit to have succinct verification, very efficient um code switch etc etc. So uh the only kind of drawback of read Solomon is their like end login. So we were trying to see is there like something we can do to exploit some other codes um that are faster and not sacrifice everything else around it by much. Um the most obvious thing that uh suffers is proof size as we can see with like breakdown and other schemes. But also something very not trivial when we want to implement this in practice are this um evaluation proofs. So how do we code switch or how

we even prove the statements about this different codes. So literally the goal was can we make something like um faster significantly faster than just pure read salmon but not just sacrifice every everything other. So we have this thing called sketch codes. Uh so it's like a very uh very like a easy thing to imagine. So if you can imagine having like some very sparse matrix which if you want to encode with this matrix it will take a linear time or something that is uh in complexity of number of non-zero of um of this matrix um or its weight however you call it. So

essentially what we do is we use this systematic code where we first encode the big message that we have with this sparse matrix and it takes something um let's say like purely linear time and then whatever is left to amplify the distance of the code you can apply any other code you want. This can be some other linear code or as you will see practically we then on this smaller thing used reads element. So the the idea of this work was to try to make something as practical as possible and not like think that much about the bigo notation so to say. And the intuition here is very easy. It says if something

uh if the me like initial message is of highway we are good. If not then uh encoding this with like one matrix and then amplifying it with the other um with the other code will give us some okayish distance. So um what are these sparse matrices? So we have uh something called LDPC uh codes or like low density parity check codes which are codes which parity check matrices are dense uh are sparse sorry. So what you can actually do here is you can use this um parity check matrices as an encoding step in the first time uh which might be

unintuitive at first glance and they have like a very nice property which is that there are no lowweight uh messages in the kernel of these matrices. So this literally gives us the property that is nice for distance. If your message is um good enough um like have a high weight the you're already good. If it's too low then uh encoding or like multiplying it with this parity check matrix will be non zero. So then the other code will take care of the distance. So what we practically did we had this uh eight factor compression uh and then we used one half rate solomon code. So you can

imagine that on a big instances you're doing eight times smaller n login operation with rate 1/2 and the first thing is linear. So why are binary fields very important here is that when you start thinking about how these LDPC codes look they are sparse um and you can do like a lot of like things in parallel with like SIMD and uh put things very nicely into cache and use all the CPU instructions. So if you don't have all of this like nicely implemented, it's not that obvious that this is like a significant implementation. So I think that uh Kobe did the most amazing work here where we

actually uh did like a far stretch to show that this is actually practical and that you can do a very nice and efficient implementation of encoding with this LDPC code in the first step. Um and for the best kind of parameters we also used 32-bit binary field. You can have this over other fields even just binary field um with like some pure additions. Uh so these are some benchmarks for like a few months ago from the paper uh we published. By now I think people would really be able to even more optimize on that. Uh but this is just uh how it was now. So uh on like

a M4 max uh we were literally able to get 2 to the 30 commitment time over 32-bit field in just like a little bit above 1 second with 2 megabyte proofs. And we are very very optimistic that this can be pushed even further with more uh with more smart tricks in optimizing around cache and uh and CID and all other CPU instructions. Um so this gives like uh around four times uh improvement over read Solomon implementation also over binary fields we had then and one thing that people will mention like will see is that in the pure unique decoding radius um the

proofs are still quite like large. Um so either there is like uh some potential way to recurse this or there are like other things that we didn't yet have time to explore. Uh these codes come with some very nice properties that uh should not be uh part of this presentation but uh you are um either ask me questions or look in our paper. But also one of the very interesting open questions is that there are now this new papers showing that we have proximity gaps up to capacity for LDPC codes. So if we can figure out the parameters and how to do this, what is the regime, we can actually

significantly lower the proof sizes and be like very close to pure Solomon um code maybe but uh like sufficiently uh sufficiently uh faster proof uh proving time. Um they also come with like a very nice uh evaluation proofs. Um but yeah this is for for some other time in the longer term. Um that's that's it for me. >> Amazing. Thank you so much Andrea and yeah very interesting design space to to look at alternative codes.

>> We are very uh much in a rush. So let's move ahead with Lev who will try to uh resolve one of the big outstanding issues with uh binary fields. Well, okay. I I was told that presentation should be quite short and it is also non-technical. I'm sorry about that because I I I did not understand that it can be technical. Okay. Anyway, I will share my screen. Uh so just few words. So basically my opinion is what computers should be able to multiply numbers. Uh I know it's a bit controversial. So I will try to justify this opinion. Um so first of all

characteristic two protocols are excellent at boolean circles but arithmetic operations are uh especially begin multiplication is slow and currently has notable amount of arithmetic uh like as as it stands right now in signature validation and bnup codes and it will not instantly go away and moreover just like there are contracts that use a recover they will not instantly go away even if you transition layer one to fully postquantum something that only uses hash signatures. And moreover, future protocols might need to multiply numbers too. Uh like lic based protocols for

example do need to multiply numbers in like even quite quite like moderately sized integers. Anyway, multiplying numbers is important. That's that's my thesis. Okay. Uh so uh there is field switch protocol. Um there is an unfortunate collision with link switch. Uh but basically the idea is essentially the same. You commit to data over one field and simulate opening over another field. Uh important is we want to lift the characteristic. So we commit to the data over a specific choice that I made is um commitments are

over f_sub_2 to the^ 127 and um we interpreted them as elements of fp where p is 2 to the^ 127 minus one which is prime um and um so basically we want to evaluate a polomial over this fp uh in in a point multilinear polinomial and we want to simulate simulate this process and it turns out it is cheaper than doing arbitrary multiplication because uh when you are evaluating a polomial uh you are basically multiplying many elements by the same number like you you pick the right half of the polomial multiply all the

elements by the same number then you fold then you repeat the process right and so um lookup based computation and the exponent and suddenly becomes much better. So this is the observation. So okay I have one slide about theoretical performance. Here's the link. Uh I can also copy it in chat and it is in the group. Uh so there is like description of the protocol. It's not published in e print yet but like at some point it will be. Um so commitment costs if you want to transfer n elements you need to commit to n divided by half more full 127 bit elements. So for

example if you want to transmit 64bit numbers which is reasonable choice uh you will pay like roughly double the commitment costs. Uh you will also need to commit to some lookup star tables but they're small and look up costs are indexed by limbs of the committed data. So basically all your committed data is split into limbs of some reasonable size. I don't know in current implementation it's 16 but it could be larger. Um and uh basically you you need to do a lup star uh indexed by the strings.

Okay. Uh so I have a fully vibe coded implementation. uh uh verifiers are kind of sort of like uh like I I I I read them and they were obtained by like sort of working AI through it, but they're still still far far from being like written by me. Um proofer is not written by me at all. You can find it by this link. Marana proves fields which just remember to move the move move the uh dash uh between S and W. Uh so currently on my machine which is x86 32 core uh it does measly 3 million per second uh

which which is pro full 127 uh bit elements which is I think it's too small but um uh there is like a significant room for optimization left. Uh so that's it. Um if you have any questions like like this performance is probably already enough to justify it like for usage for like beginner arithmetic if you need to do something with 256 bit numbers or whatever. Uh but uh but I think this probably can be improved a lot.

>> Wait 3 million what? 3 million what? Sorry I >> uh 127 bit F. So basically this is like full full argument including commitment r switch and like all all the rest which um like commits to uh well it's comm it commits to one mill formulated >> if I want to do 64-bit multiplications. Uh is it 3 million 64-bit multiplications or I I I think it will be 1 1.5 because uh wait first of all it will be a bit cheaper because I'm transferring full if you want to do 100 uh like native field 127 bit uh

multiplications for some reason you would uh have 1.5 million of those per second with the current implementation. I think it's too slow. Uh but um yeah, it's probably not that optimal. At least theoretical count seems to suggest it probably should be faster send message. Okay, it's not Yeah. Okay. And generally biggest bottleneck that I observe is uh is uh lookups and for the fact that that you are going into exponent at all. So I think very useful thing to do would be

trying to benchmark it against uh trying to benchmark it against like let's say naive flock circuits and checking check checking whether maybe you could avoid uh may maybe you could avoid going into exponent and seeing this element they're not witnessed so they're not committed but they're still in the IOP. Thank you so much Lev um for sharing these ideas and I know that Benedict is also kind of shared with us privately that he's looking into this design space. So the two of you should maybe chat even more. Um next up we have Emil who will talk about uh lean VMBB the

binary version of LINVM. >> Thanks. Hello everyone. Um can you see my screen? >> Yes. Okay. So, um, lin VM is this minimal ZK virtual machine whose goal is basically stacking Ethereum. So, aggregate hashb signature postquantum availability recursion etc etc. It's a minimal virtual machine. It's by Kro and it was previously using collab and poson and I'm going to speak about the transition to binary fields. So as a quick reminder

um there was only so there was this read only memory two registers frame pointer and program counter a very limited number of instructions and so the field was collab extens extension five and posidon one and the security was approximately 124 bits and um thanks to the recent breakthroughs in binary fields we've been able to move it to binary fields. keeping essentially the same virtual machine in the sense that there are still two registers still read in memory still a very limited number of instructions but the field is no longer

collabor it's either um a large 192 bits extension field for the memory values [clears throat] let's say and the rest is in the 64 bits binary field The hash function is Blake currently blake to s but it doesn't matter because in some sense the key point is that we can basically use uh standard hashes and deciding which standard hashes we're going to use. It's still an open question and the security is four bits better than previously at like a standard list level one security.

In terms of performance, um it's essentially uh close to the like [snorts] because it's very recent, so less than two months. Um and performance is progressing quite fast. So hopefully we will be able to get the last 2x that we need to target above a,000 xmss per second and um below let's say 250 millconds for two tone recussion and um in ter in terms of hash proving we are below the flock 700k blade 3 per second because we use blade 2s and more importantly because we use a

bigger extension field to be uh in the list decoding regime to get small proof and easy 128 bit security. Even though uh given like the the new flock 2 version, we might we may have again improvement on this. In terms of proof size using a big 182 bits extension, we can get the same um small proofs as the previous version of LINVM. uh so I think between 200 and 300 kilobytes and hopefully with the proximity gaps conjecture when they will get solved we will be able to have sub 100 kilobyte proof size for hashbased um snarks which

is amazing quick technical details so as I said we don't use ghash um because like the list decoding regime is quite good to use to to to have small proofs and to trivially have 120 bit security. So we use a degree three to extension over a 64 bits field. Um and uh the key idea is that there is this we fix a multiplicative generator g of the 64 bits field and all the uh arithmetic of the VM is in the exponent meaning the memory addresses the program counters etc. It's not 0 1 2 3 4 5. It's 1 G G square G cube etc. So

it's kind of a trick. Uh and the idea is that using this you you get a cheap way to express um memory shifts and offsets you transfer uh addition to multiplication which you can do very easily and so you get uh roughly the same speed as before using um collabor. So as I said the hash black 2S is currently proven by flock uh ring switching from the one bit field to the 64-bit field because we commit in the 64-bit field with we're aa liarto um permutation is handled by GK product and for the lookup we currently use um a

nice idea essentially offline memory checking in the exponent it's nothing new it was described by I think the original newspaper And there is a nice um business blog post that basically explains that if you have a some kind of memory bus that you can implement with CR product easily, you can build on top of it a lookup argument that has the advantage of avoiding to commit twice. Meaning you avoid the because if typically there are some lookups where you need to commit once samples of some randomness and recommit and in the end when you open you have to provide mer openings for all these

commitments and so you pay a bit in terms of proof size. So I like this and also like this lookup is very simple so it's kind of nice even though it's definitely not optimal and maybe we can find some better lookups later. As a conclusion, promising benchmarks uh obviously need a lot of cleaning. Uh we need to choose a hash function but that's not for today and to double the performance and we are going to be good. That's it for me. Thanks. >> Amazing. Thank you Emil. Um Emil has been working extremely hard to uh derisk binary fields for us. Um and uh yeah, the performance is is definitely good

enough that uh we we had a lot of conviction in uh in moving in that direction and there's all sorts of improvements that are going to be incorporated in the weeks and months uh to come. Any questions for Emil? If not, let's move on because we're very very tight on time. Thank you so much, Emil again. Uh, next up we have Tamir and Eugene who will talk about a binary version of SP1.

>> Okay, now I'm not muted. Uh, can everyone see my screen? >> Nice. Um, okay. Oh, now it's doing auto slideshow for some reason. Sorry. Okay. Um, yeah. So, one of the main um motivations for flock other than uh really originating from this work of proving as fastups computing um and others. One of the motivations for me was to really use classical hash functions uh in a ZKVM.

And I will try to phrase this as like what I think ZKVMs in the future should look like um and how we're going to incorporate all this in like the next So a lot of this is uh work in progress. Um, so I'm going to be a little bit more philosophical in the first half and then Eugene actually will tell us a bit more concrete results. So okay um so I I informally I want to kind of divide the progress of in ZKVMs in the last few years to like four generations um or the fourth generation is not here yet. So the first generation was just being able to like create easy

proofs from code like at the time it was revolutionary uh with risk zero um as the first one um and then SP1 and then others uh [sighs] but in the beginning it was you know mostly CPU based uh not really like not really cost efficient and then uh the second the first adopters were kind not latency sensitive customers but people who had very complicated code bases and wanted to be able to prove something. So this is something like bridges like Celestia famously and un rollups.

The third kind of gen three I would say is like the latency focus which is the last year's kind of real-time proving effort really brought um new paradigms in how execution and proving are being overlaid and we kind of see this like convergence of many VMs to like a similar um design here [snorts] and the question is what what do we require from the VM of the future and I think um a few zerorata that I I would like to have is and and some others would like to have too is is formal verification you know with AI should be possible using traditional hashes only increases our security assumptions uh 128 bits of security some people are

already there uh others are in progress and better performance in general now what does that mean like what do I need from the proof system so uh hashbms they they all kind of converge to something they're all very different Actually when you look under the hood but but when you look from far enough they're they're very similar in the in what they require from a proof system they require uh multiple tables because we realize that specializing circuits brings much less overhead on things like zero check. So we need multiple tables with low overhead and the ability to write specific circuits and maybe also include pigma files and

we need some way to communicate between the circuits. Okay. Uh I think a lot of people here know that but and then another thing we need is recursion. We need an efficient way to enable parallelism and also handle long execution traces. And until now we really recursion performance relied on using uh hash friendly uh zk friendly hash functions and like Justin phrase it now we we will use um hash friendly snarks instead um namely I think binary field snark is a good candidate here and finally for a zkm where your proving is usually done in server side you want uh hardware friendliness so you know

originally plonky or you know originally the small the small field um quest was was kind of motivated by this and this is to enable real-time proving on modest GPU clusters and you know as we heard today like you know numbers of GPUs growing lower and lower and but GPUs are still you know the compute throughput machines of of today. Um so then the question is uh what does the fourth generation SP1 would look like and what do we adopt? So I think flock v2 is actually a good candidate. Uh and that's kind of what the message I wanted to give in this first part of the slides and why uh multiple tables like I'm kind of repeating something that Ron already

said. So uh multiple tables using the jacket PCS seems to be pretty efficient. uh the communication we right now we have a grand grand product argument I think one uh very overlooked um advantages of binary field arithmetization is that there's no range checks so that's that's very nice so we actually I think we can do all of SP1 without we don't need multiplicities we can just use a grand product argument um and maybe better things like from the likes of the works of of Benedict's uh group in the future.

Recursion as we can see can verify its own circuit. Now the key question is like is it hardware friendly? Notoriously this is the problem with binary fields. Um but recently we we have been rescued. So I want I I'll pass it on to Eugene to explain more um how flock looks like on on GPUs. And Eugene maybe you can share your screen because it'll be easier. I pass whatever. >> Can you just Yeah. Can you just do it because it's like the Um Yeah. So, next slide. So, yeah.

Thanks for passing it along to me. Also, sorry for making everyone listen to my coffee grinding at the very beginning. Um but yeah, so basically I'll be really quick. So binary fields the conventional wisdom or at least that's what we felt internally was that binary field arithmetic is slow and the GPU um GPU is not doesn't really have built-in support for binary fields like CPUs do. They typically CPUs for example have very fast uh 8bit binary field uh support.

however recently next uh slide as of May third as of May CUDA 13.3 has support for a uh carless multiply and add instruction. So basically it's uh possible to efficiently implement the gash field on GPU. you can get a 128 bit binary field um using this new PTX instruction. So yeah, so basically this uh so it's a 64 to and 64 * 64 it's 128 bit carryless multiplication. So you also need carrot suba. Um so between that so yeah next

slide between this instruction and carrot suba we implemented a GPU prover for flock. We didn't use ag skip yet. Um but yeah, so roughly early benchmarks in uh is around 7 million Blake 3 compressions per second including as far as I can tell witness generation and proving um this is on a 5090. Uh yeah and then uh the other optimization but that we that I want to mention here is that on GPU

you're sort of um more memory limited. So trading compute for doing more compute and doing fewer memory passes memory traffic uh helps. So we did this look ahead optimization. So you could do multiple rounds of some check messages by one pass over the data. Um and then if you want you could try it yourself. We merged it into flock main. Uh you can see that you can get proofs that verify with the flock verifier. So um yeah. So you can just take the main branch of flock and then run the uh

uh unit test uh to do two it's a two to the 19 hashes here or two to the sorry 2 to the 20 hashes the test that I have here and it'll print you the um uh proving time. Okay, that's that's all I have. Amazing. Thank you. We got so lucky on on so many fronts. All the stars are aligning and Nvidia has uh exposed this new instruction. Um and this is a great segue to our final talk uh which is going to be about uh GPU acceleration of

binary fields as well. >> Just wait a second. I need to turn off all the browser. Oh. I think I have a problem with sharing slide eyes.

>> Uh if you send them to me, I can I can use >> Okay. Okay. Thank you. >> Okay. Oh, sorry. I sent the message. >> Nice. Perfect. Just a second. Share. Boom. Okay. Good. >> Okay. Yeah, my presentation is going to be very short. So, yeah, we achieved four 4.1 million hash per second on singular artist 5090. But unlike the the sash team does, we did through the compile approach. So unlike the existing

approaches we using uh we write some we write our protocol in Python and so there's no product code in the Python code and then if you look at the all these layers we starting from the prover layer which you describe your protocol in Python and here we have a two layers one is fractured which is a uh protocol for f written in Python for you based on George and George stands for Python for G GK which allow you to uh easy to write your GK snar uh by layering. So you can layering uh IOP and you end up with a

creating a new snap basically and through the uh from the Python you trace your Python code and you get the IR which is uh stab ratio and then with from the stab ratio we're going to compile it and we basically modify the there's something called uh X-ray which is X-ray linear algebra we added um some opico on top And then we make it to uh aware of the field aware semantics so that it can be lowered to CPU binary so that uh from a one compiler if you write one compiler then you can support basically many arbitrary hardware. So

basically this code run on CPU and and because I was so rushed so I was also trying to support matter too but I was so rushed I couldn't make it but yeah it basically run the same code but from metar 2. Could you go to the next slide? So then uh my the main message about this presentation is going to be yeah uh for the five weeks maybe the number is gonna be not that late l latest. So I look up the the entire approaches made by the snap vest and over the entire 2,166

submissions only the 226 uh the patches actually move the performance. And then if you look uh if you just pick the only the uh patches that actually move the performance more than 2% it's going to be just a 90 patches and out of entire 90 patches then if you see the categorize all the changes then only the 15 c changes are actually does nothing for the prover code and this pro code I mentioned in the earlier page is about uh fracture and George. So if you write uh some your protocol the most of optimization is

already done by compiler side only the four out of 15 uh four out of 19 is really the change you need to make on your pro side and also if you look at the frontier code um because maybe this is written by AI there are a lot of repetition there are a lot of inefficient B I can find for example like if you see the uh this corner for dedicate corner for zero check. If you see the some of the uh CR super multiplication implement in zero but not in ENT not in entity if I remember correctly and if you have a uh hardware you want to support more and more basically you need to repeat your code

also you can find this uh in the second axis handbu generators you can you can also see something like generator that generates the hardware dedicate code which is not portable. But if you look at all this approach from the perspective of compiler then most of these code generation is can be done by the compiler side and then or yeah so that you can share every technique just by using the compiler side and then on top you have a church which can be appliable for every scheme and then on top you have a flock church and it is dedicated to your uh uh your proving

scheme. So basically with that the uh we can change our mindset. For example like the compiler the one that who um implement the compiler owns the how to compute and the other is going to be uh in charge of what compute. Could you go to the next slide? And also if I see the how the throughput is computed then I we can start it from the how the time is measured. time is basically the com sum of fixed cost plus the C time H and the the F is stands for fixed computation. You can imagine like this is the the time taken for every run

because you need to sample something which is a sequential you need to stop your kind of pause your hair computation in the middle or it could be uh the time for the device and whole synchronization or something like that and H is uh the number of comp compression hashes and C is going to be a marginal cost of each hash and the throughput is computed like h over F + C * H. And if you go H to the infinity, the ceiling is going to be N1 / C. And as you can see, the fifth cost is going to be of uh impactful when the B side is small. But once you have a batching your computation, then the

fixed cost is going to be amortized. And then the if you have and over the batch sizes you get the ceiling of one over C. And the and yeah so and if and I think the the the setting that the snest is using is almost we hit the most of the ceiling part. So the question is like so as I mentioned earlier F is going to be amortized over the best size. The question is like how do we um increase the the the how uh how do we uh reduce the cost that that takes for like if you see like simply thinking

that how do you remove how do you reduce the the cost taken for the computation for each element or for given the the bite or given the data would you go to the next slide so I my belief there's not much left inside a counter optimization. So if you see the the the performance in this way. So the the the yaxis is going to be attainable performance and which can be computed uh using a minimum between compute peak and intensity times bandwidth. And the computer pick is going to be uh theoretical the maximum performance you can achieve given your data. And

intensity is going to be like the operation per each bite. For example, like if you use carafa, you're going to use a three multiplication and the bite for this operation is going to be 64 by 64 bytes times three kind of. So, and then if you fix the one device, the bandwidth is going to be fixed. So, so it's going to be yeah bytes per second. And if you run a profile using NCU then you can see where you can see where you are and you typically it sits on the left side of this slope. So, so if you are in the left side of the

which means on a slope then you which means you uh the contation is memory bound or bandwidth bound and if your computation sits on the the the horizontal line which means you are cont because if you if you analyze if you profile your computation is normally in in in case of a flux Ed in case of fluctu the computation is sitting on the slope of the memory bandwidth and then the typical way to make your point to the left upper side is basically the technique called fusion or tiling or recmputation. You need to reuse this bites. Fusion allow you to reuse your bite or reduce the the bites you need to

transfer from host to device or tiling. Also the way to compute the data from the cache or share memory or recomputation is like basically the recomputee from the the data on your already on your memory. And the typical way to the uh achieve so much high performance in AI area is yeah given bandwidth you need you reduce the number of bite to send which means you use a uh small sized data which means like FB4 F8 like under one bite in in that sense if you look at the way you uh compute in the the GPU side then I

think the the the research side to pick up the binary field for the next generation proving scheme is the right choice I think. Could you go to the next slide? And so as I mentioned earlier, so throughput is going to be seed by the one over C and to uh so to uh to reduce the Oh. Oh, you you you went too far. >> Yeah, sorry. You're right. We really do need to wrap up very very soon. Sorry.

>> Ah, I see. I see. I see. I see see. Okay. So, yeah, all the details are written in the blog. So, please scan the QR code and see the detail. And if you have any question, please DM to me or chat with me. I happy to chat. >> Awesome. Thank you so much uh Ryan for this completely new direction that doesn't involve uh writing CUDA makes use of of compilers. Super convenient, super portable. We've had a marathon on the of an e- proof call. Thank you so much to the 80 people who've made it uh two and a quarter hours in and I'll see you uh at the next call. Thanks everyone. Bye guys.

>> Bye. >> See you. >> Bye. Thank you.