Hyli: Benchmarking Noir

Transcript

Hey everyone. Um, happy to be here. Let me click this. Okay, that works. So, we're going to talk about benchmarking Noir. First of all, I'm very sad that I'm not wearing one of the lab coats from the Noir guys, but I'm wearing a one of the highly t-shirt that says zero know proof in French. So I just really want to make sure that this was captured on camera. So there we go. So um at high we have done a bunch of work. So I'm s blah blah blah co-founder of highly we've done a bunch of work benchmarking different options for client side proving and so we've done some work like very concrete work about benchmarking different options and especially nor so I give you a bit of context of what we do at highly uh going into more of the benchmarks the results the future blah

blah blah. So uh we're now one everything on highly is a proof. Uh we're hacking proof into the blockchain most of the time. And what we've done on highly is that we have designed an entire blockchain network to fit proofs. So we support major proving systems nor obviously otherwise it wouldn't be here with zero and SP1 and we aim at just supporting all of them. So very simple. This is Steve Balmer. Proofs proofs proofs proofs proofs proofs proofs. That's what we do. Um we've made some very like concrete design choices. There is no execution environment. So you don't run code on high. You just send a new state, send a proof and you're off to the races. We have very fast DA and some of the stuff that we have done with

Nora for example is that um we don't even have a concept of an identity. You just send a proof of who you are and you're good to go. So I'll let you look at more of this. We're not here to talk about highly. We're here to talk about uh Noir. Uh small plug, we just have released the test net so you can scan the QR code and use the nor good code. Do it really fast before the deaf team kills me. U because I'm not supposed to do this and um you can see that the wallet that we have built on highly uses noir. So it generates a zeon proof that you know your password and provisions a session key. So we're really happy about this one. It means that you can use uh the same wallet on your phone and directly on your computer.

Seamless, great experience. No, good. Thank you for building this. So, benchmarking noir. Why did we do this? Um the reason is if you want to prove something, there's always a bit of an overhead obviously. So most of the time and most of the research has been spent to make sure that it's very easy to prove and it's getting faster to prove on a server. Main use case being Ethereum blocks rollups etc etc. But there are some use cases where you cannot um prove on a server especially when it's privacy sensitive. So there's a great project called Zigg Passport. Uh Zigg Passport that allows you to

generate a zero knowledge proof of a particular statement of a piece of signed data on your passport. I want to prove to you that I'm over 18. I want to prove to you that I'm French. I want to prove to you that my first name starts with an S. But in order to generate a proof of this statement, I am not going to send my passport to the succinct proven network or to the boundless proven network. So I need to have a privacy preserving option to generate such a proof um without leaking everything. So that's where client side proving comes in. The proof is generated on the end user device directly. There are some other options there. The TCO team is leading the the the the march

for coarks. So it means you compute the proof of a multiple nodes on an NPC network. And I'm personally quite excited about TE proving. I think it's fine if we just put a pro ZKVM inside a TE and just call it a day. Uh but we really get to see more of these things happening. In the meantime, really bullish about client side proving. Um this was a slide from Nicholas Mlat, the aka the goat about um the trade-offs that you get between like fast proving and fully private. Um so it was a really good talk that he gave at Zuberlin a couple a couple days ago. So I stole his slide um shamelessly and you have some options you see like prove on the client

device fully private but it tends to be quite slow because you don't have access to like massive servers. So there's a whole range of options that you can use in order to compute a bit faster while um knowing of some of the privacy aspects. So the question is you want to benchmark great what are you going to benchmark on the question that we're asking ourselves um so if you take for example uh ZKVMs they tend to use these benchmarks Fibonacci uh or EVM blocks and it's pretty cool because it's a very very practical example for client side proving it's not necessarily very applicable so what we thought about doing is uh proving of what the hell

ECDSA signatures specifically on the SECP 256R1 curve. So uh the mission what is the best proof system for proving ECDSA signature verification on the SEC P25XR1 curve in a browser. This is very specific but it's an actual problem um that we want to solve. So this is what we run the benchmarks on. Uh why specifically this curve? because it's used mostly for all ID documents. So if you've been following there's ZK passport these guys have a mobile app for example that is great but what we're trying to do here is on a browser and the reason we want to do it on a browser

is because a browser is very very limited in terms of the resources that it has. So we want to see what's the best option that you can have so that you don't even need to download an app you can just use it everywhere. Um so the three criteria that we benchmarked against are proving speed, how fast does it take to generate the proof, memory requirements to give you an idea um was in a browser on Chrome uses up to 4 GB of RAM. On Safari uh it's one gigabyte for example.

So it's very very um limited um and ease of use. So, we wanted a tool that was easy easy to use. Um, lucky for us, we have a good friend called Vlad. This is him. Uh, as he said, the only Brook dude in crypto that helped us build this benchmark. So, give him a follow. Um, check out his GitHub. Um, and so the the benchmarks that we run, uh, we did it with SP1, Rezero, Noir with the two different backends, Halo 2, and Cairo with Stew. I actually typed Halo 2 logo and I was surprised to find the Halo 2 logo um because there's none out there on on Google.

Uh we thought this was going to be easy in and out 20-minute adventure. This took way longer than expected because some of these things is just not documented or or it's just overall very very difficult to use. Um so disclaimers on the results. First of all, we've done this work five months ago and we have not updated them. So, please take this with a grain of salt. Uh, second, it's a single data point that was done by a single team. Please don't get mad. It's a single data point that was done by a single team. Please do not get mad again. Uh, if you do not see the shiny double baby bear job curve on plum plum arm icicle with GPU acceleration, we're sorry, but we did not find it. And we

should have included Lgerro, but when we did the benchmark 5 months ago, it just wasn't there. So, you're just going to see the benchmark done on all of this. So, that's it. All the disclaimers done. Uh, what's the result? The result is, as you should expect, noir good and Noir came out on top by a very, very, very large margin. So, if we go from bottom to top, Cairo, we didn't manage to make it work uh concretely. Halo 2 didn't work either. We didn't manage to make it work. Ris zero and SP1, great options for ZKVMs, but it was just too heavy to run in a browser, so it didn't work. Um, Cir, the proving key was too heavy, so

it didn't work for what we tried to do. Um, so we didn't use this. And then we ended up with No, so it was really pretty fast. We got it to two seconds on an M1 MacBook and about six seconds on uh an Android. And this is like bear in mind we are not running any type of optimization here. This was run-of-the-mill type of um Vlad is a cryptographer but like he doesn't have all the context for all these things. So this was if you wanted to use this right now what's the best option that we would recommend and we just recommend Noir and this is the version for no and Bitenberg at the top.

Um so nor is good um but honestly it could be faster. Uh so please Aztec team just make just make it faster. But yes uh no is good and that will be that will be the conclusion. Thank you. [Applause] Any questions? Thank you for the talk. Um curious what what motivated the benchmark to begin with at the first place? Was it for prioritizing for example like which

tech stack to support? Was it from user demand? Yeah, we'd love to hear more. Um it really was to prioritize which one to work with. Um we currently support RZero uh SP1 and noir and we support both ZKVMs because they're great and they work quite well but we really wanted to have a good option for client side proving because in terms of the applications that we want to build on highly we want to have both applications that can be offloaded to proven networks and benefit from great stuff with GPU acceleration etc etc but maybe like 5% of the app must be completely private and so we need to have a great option for this so this is why um we've supported more and we wanted to be able to make um recommendations to builder as to concretely what should I use because

we could support absolutely everything um but we'd rather um support what works. So that's that's how we ended up doing the benchmark and that's how we we chose Noir. Yeah. I wanted to ask about I mean there's a distinction between noir and Aztec noir right? I mean Aztec is a rollup. Are you considering verifying the rollup circuits in highly and have you thought about because you have all these extra kernel circuits and sorry yeah so verifying the AIC circuit and you're saying

okay that's that's a question yeah we we can verify that uh we haven't prioritized it but it's something that we can do. be super nor overall. So this would mean that we just include another uh contract with the yeah just verifying a state. Yeah, doable. Cool. Thank you very much folks. [Applause]