 Hey everybody, so the next talk is going to start in a bit. It's going to be a tale, a snark's tale, a story of building snark solutions on the mainnet by Savvy, a core that from the graph. But before we get ready, does anyone have any interesting snark tale? Or is the, do people actually use ZKPs here in any user way? Or is one person? That's nice. Could you tell us your snark tale? What is your first time? You know, just sit back, close your eyes and tell us about the first time you ever use a snark. Oh, he doesn't have a microphone, but I'm going to run there. Well, to send the transaction on the MENA network, which is a ZK layer one. Nice, that was a nice and not push at all shill of MENA. But yeah, appreciate it. Thank you for sharing. So yeah, finally, please welcome on stage Savvy from the graph. All right, thank you. Yeah, so I'm a cryptographer at Semiotic Labs and this is a joint work with Jackson Blasensky from Edge and Node. Like I said, we're core developers from the graph and basically we're just kind of going to walk through one of our stories of trying to, you know, build solutions using snarks and then actually running them on Ethereum mainnet. So first, I think everybody here has at least heard of a snark. So let's just kind of quick recap of the main character of our story. This is the, you know, the expanded acronym of snarks. It's not an interactive argument of knowledge. In particular, what we care about is the sickness property of these snarks. So it's kind of like that computation, compressing the scalability solution for Ethereum, those properties. One notable omission from our snark here is we don't have the ZK piece. And so in our solutions, we don't necessarily care too much about the ZK, the privacy piece, which is really this scalability piece that we're after. Then also, as I'm laying out the acronym snark, I noticed something that one of my co-workers, 10-year-old daughters noticed and she said, shouldn't it be called a snack? And she's not wrong. So. All right, so our story. Every story has a challenge, a reason for it to exist. And this is our challenge. Let's, you can't really see the bottom line there, but that's all right. So basically what we're trying to do is we are trying to use a snark to resolve like one million independent payment channels within the graph protocol. So the graph protocol, the way that they ensure indexers get paid is they have an entity called the gateway. And every time the indexer provides a result from a query, they get paid some amount. And so then the gateway issues them a receipt that's been signed by the gateway. And then it says, what's the value of your transaction, right? So the nice thing about the payment channel that the graph uses is that you can basically instantiate up to a million independent kind of payment channels, right? And these are all asynchronous. So the gateway can just be firing away receipts as the indexer is serving queries. And so the indexer ends up with a bundle of, say a million different receipts. And their total amount that they're owed is kind of the sum of the total value over all of those receipts. And so for the indexer to be able to prove that they're owed, the total amount that they're owed, they need to somehow prove that all one million of these receipts have valid signatures, that none of these receipts have been repeated, and that the total value adds up to the total value that they claim that they're owned. And so one way they could do this right is they just take that bundle of a million receipts, throw that on chain, and then run some BL signature verification on all one million receipts. But that's a little costly. So we want a better solution. And so the solution seems like really well suited for a snark, right? Basically we want to take this computation of a million different signature verifications, throw it into a snark that can say yes, all one million of these are valid, total value adds up to the claim total value, all IDs are unique, and then you get out just one nice little succinct proof with some claimed total value amount. That goes on to chain, and you run your snark verifier algorithm on chain, and the indexer gets paid. And so let's look a little closer at this problem and why it's interesting. This table here that we're generating, right? This bundle of receipts, we've got a million different receipts. And so whenever we talk about snarks, there's always this talk of like, okay, what circuits are used to verify your computation and all that type of stuff. So basically our circuit needs to take in, actively needs to prove one million different signature verifications. So initially we're thinking about using BLS signatures. You can maybe say that a BLS signature can be proved with the circuit of size say two to the eight. If you wanted to prove all one million of those transactions with this size two to the eight circuit, you could just take the two to the eight circuit, copy and paste it, and then you have some huge size two to the 28 circuit that you're gonna be using in your snark to verify and to prove and verify. And so what's interesting about that is two to the 28 is about the biggest circuit size you'll see, right? And all the literature analysis, like people run their asymptotics and they go up to size two to the 28 and we haven't really seen much bigger than that. And so already we're talking about trying to prove statements that are at the edge of what people have used. Another really interesting thing about this primitive is we're trying to use a snark as a black box. So really we're just trying to get incorporated into this payment channel protocol. And we don't really want to have this snark impose any extra requirements on the protocol itself, right? We just want this snark to be this black box. We plug in a scalar table, we get out a proof, that proof goes on chain, you can verify it. And you don't really impact the security of the system in any way based off of your snark. And then yeah, the final thing here, the business side of this, oh yeah, can you make this whole process of proving and verifying costs less than $30? Otherwise it's not very useful to the indexer. So thanks. Go. All right, so now we're going. We got our challenge. We're trying to prove this massive table of data and basically prove this massive table of signature verifications. How do we know whenever we're done, right? How do we know that we've succeeded? There's a bunch of different metrics to quantify snark performance. We use prover time, prover memory, proof size and verifier compute. So prover time is basically just, it's the amount of time that the prover spends generating their proof, right? So in this case it's the indexer. The indexer has their big table. They're gonna run this proving algorithm. It's gonna take them some amount of time to generate that proof. Prover memory, this is the actual physical requirements of the machine that they're using to generate this proof, right? So they've got, if they got a laptop with 16 gigs of memory, you're not gonna, the algorithm requires more than 16 gigs of memory. You're gonna run into issues. You're not gonna be able to generate a proof. Prove size, this is the size of that proof that gets spit out of the snark. This is what gets sent on chain. So this is obviously important, right? The bigger your proof is, the more expensive it is to store it. And then verify or compute, these are the computations that are run on chain in the verify algorithm. And for the purpose of this talk, whenever we talk about the verify compute, we're really gonna just highlight the most expensive operations that the verifier is going to run. And so this gives us kind of like a quick way to filter out techniques and estimate gas costs and all that. Just another thing on these figures, right? We'll see them repeatedly. This x-axis, basically this is showing our statement size as it's growing, right? So we said we wanna prove this big table of signature verifications. The goal is to get to this kind of size, two to the 28 instance. And then by seeing how these metrics trend, we can kind of get an idea for like engineering solutions, right? And we get an idea how our problems are growing and stuff like that. So those are our plots. And now we start our story and I like maps and I like stories with maps. And so we're gonna have a map. But a quick caveat about maps is this is a map of the world in 450 BC. It's accurate, but we can tell it's not the full truth, right? There's a whole lot to be discovered still. So here's our map. This is cryptography land as we saw it at the start of this program and especially in particular when we're looking at snarks. So we've got kind of two major continents of snarks. We've got transparent snarks and we've got these non-transparent snarks. And so non-transparent snarks, these are snarks that require some sort of trusted setup. So we saw yesterday when we were talking about dang-sharding and we're gonna have this KZG trusted setup ceremony. That ceremony is what is required for these non-transparent snarks. Transparent snarks, the idea is they don't require this kind of trusted setup ceremony. You can kind of run them out of the box. So that's our map. Now we say, where do we begin, right? How do we start this story? And really, when we started out, we said, okay, one of these unique properties of the problem, it's a black box. Like we said, we don't want the snark to impose any security requirements on top of the system that we're using. And so when we think about this trusted setup, we can debate how like the practical implications of this trusted setup, right? Like if you only have two people running the trusted setup ceremony, you have to trust that both of them are honest. As you increase the number of participants, that level of trust might change. But the point is you're still making an argument, right? There's still some other additional argument that goes on top of the math of your proving system. And so initially, we said we want this thing to be as black box as possible. We don't wanna have to deal with those extra arguments. So we wanna start with the transparent snark. All right, so now knowing that we're gonna be using a transparent snark, where do we go from here? And so we start by looking at our problem statement. And we start trying to find what's the next snark to use. Thing that's unique about this problem statement, right, is it's highly structured. So basically we're kind of proving the same function a million times. So if we could kind of reuse these circuits, right? Maybe we could significantly reduce costs, maybe proof size, verification time, that type of thing. And so in particular, what we're curious about is we could come up with one circuit, this is some F circuit that can be used to prove all of these snark things for a single row. And so then if we could do that, then could we generate proofs for each individual row and then somehow aggregate them all together? And then we get some aggregate proof. And the hope is that aggregate proof will cost only about the same to verify as verifying this single small proof. So people have been looking in snarks. You can see where we're kind of going with this. We are going to recursive snark land. And so in this space, there's a couple of primitives. Halo is one of the big ones that we hear about. And there's talks on it this week. But at a very high level, recursive snarks, it's kind of like what I was saying, right? We have the idea is we have a circuit. We want to repeat the computations on that circuit and then kind of aggregate these proofs together. And the way that recursive snarks tend to get around this in practice is you take your original circuit, you can augment it with some snark verify circuit. So it runs the verify algorithm of your proving system. And then you have some result at F prime circuit. And then this F prime circuit is kind of what you start chaining together to prove all of your rows. In our case, prove the rows with the scale of the table. And the really important thing here is the cost to verify and like the cost improve size is really only tied to the cost for proving and verifying this one F prime circuit. So that's really encouraging. Maybe we could significantly reduce our problem using this. We use a primitive called NOVA. So it hasn't seen too much traction in this community that I've seen yet, but it's a newer primitive. It was presented at crypto this year. What it really has going for it is it can do kind of what Halo does, but it has the smallest constant size verifier circuit. So we remember that F prime, you have that little verify circuit. NOVA is the smallest that exists in the current literature and it's constant size. So it doesn't depend on the size of your original F circuit. Yeah, just a note, in our case, this F prime circuit ends up being about size two to the 15. And so this is this constant proof size and the verifier work is tied directly to this kind of two to the 15. Another interesting thing about NOVA is it uses another IOP called Spartan. And what Spartan does, or its advantage is it's a very fast prover. And it might still be the fastest prover in the literature. It doesn't use any of the FFTs and it also has a relatively efficient verifier. Some more notes about NOVA, the actual open source implementation that they have, they've instantiated it with bulletproofs IPA. So this is kind of like the expensive IPA that people talk about in the literature, or the expensive polynomial commitment scheme. But that is, this bulletproofs is only used to, for a circuit of this size. So you end up with a bulletproofs instance on your polynomial commit and it's tied to this size. And then just another note on their open source implementation they're using these POSTA curves. So similar to Halo, when you're generating these recursive proving systems you have some like kind of unique mathematical primitives that you gotta use. And so that particular is called these cycles of elliptic curves. And NOVA uses the same thing that POSTA does and they actually work together on this. So nothing too surprising there. What gets surprising now is we actually start looking at our costs. The first thing that we notice is these constant size here. So the proof size is constant, this verify is compute is constant. So basically what we're saying is as we increase on our x-axis here, we're basically proving more and more rows in our scalar table. And this proof size and this verifier compute stay constant because again the proof and the proof size and the verifier compute are tied only to that F prime circuit. So we get this nice kind of constant proof size, verify compute that doesn't depend on the number of rows that we're trying to prove. The prover time here, this is pretty much linear in the instance size that we're trying to prove. So linear in the number of rows that we're trying to prove. Because basically the prover has to do the work. So in this particular instantiation the prover is just kind of going row by row kind of proving and accumulating. So you kind of just see this linear growth here. And so I mean, based off the implementation that we have available, we would estimate 51 hours to prove using Nova for an instance as big as we want to get. That may or may not be a fundamental limiter, but really what we see the big limiter is this verify compute. So even though verify compute is constant, it still is a very expensive operation that needs to run. And so in particular, it's part of this bullet proofs polynomial commitment scheme. You have to run this elliptic curve multi-exponentiation and it's size two to the 15, so 32,000, basically elliptic curve multiplications. And so the problem really is, Nova is working to work with positive curves. Ethereum only has pre-compiled support for one curve, all to be in 128. And so this is kind of a famously known problem at this point. So if we wanted to run this verify algorithm, we would have to implement smart contracts for positive curves so that in itself is a cost that we would have to absorb. And then if we did, we would see, based off of some people who have done similar work, a scalar amount would still cost about 350,000 gas. And so if we could use some algorithms for speeding up this multi-exponentiation, we could get these total costs down to 764 million gas or $76,000 off of some estimate of gas to dollar ratio. So clearly this isn't the solution that we're looking for. Maybe there's some engineering things we could do, we could take advantage of all BN128, it also has a cycle, but for now we'll table this and we'll go look elsewhere. So where do we go from here? Again, we want to transparent snark and we really like to use primitives that can take advantage of things that are supported by Ethereum. So we look for primitives that use all BN128, all BN128 is a pairing-friendly curve. So we're gonna look for transparent snark primitives that use pairings. And we don't really have to look too far. So NOVA, the same authors who wrote NOVA, they also authored something called quarks. And so this is another transparent snark primitive. And in particular, what's unique about it is they invent some pretty unique polynomial commitment schemes that use pairings, but they don't require a trusted setup. And so they can get some significantly better performance than say bulletproofs from a verifier standpoint. So it's pretty unique. Again, similar to how NOVA was written, they're using Spartan as their IOP. So basically they take one of their polynomial commitment schemes, either copus or dory, pair it with Spartan, and then now they have a snark. The nice thing about them, they've got fast and space-efficient provers, that's a property of both polynomial commitment schemes and the Spartan primitive. The proofs, they're a little bit bigger than what you would get out of something like bulletproofs, but they could be manageable. And then the nice thing about them too, they have relatively cheap verifiers. Oh yeah, then just another comment. There's actually some more research by the same kind of group of authors about Spartan that is used to prove kind of like SIMD computations, right? So you have basically our scalar table, right? We have one circuit, we have multiple inputs, single input, multiple data. And so they've got some stuff off the shelf that can seemingly help us with our problem. So we get really excited about this. So then we start digging into quarks and we want to use it and we want to try to build snarks with it. The first problem that we run into is there's no open source implementation. So that in itself makes things pretty challenging. There's no copis, nor is there a dory PC. Although I was talking, it sounds like there might be a dory implementation available somewhere as of a couple of days ago, but I haven't seen it yet. So knowing that this polynomial commitment scheme is kind of like the primary cost driver for these snarks, we implemented the copis PC using the Rust ArcWorks libraries. And then we ran it to get some benchmarks and kind of get some estimated costs. And so these are the results for a copis PC. The one thing that we see in our prover time now is pretty nice, right? That's 565 seconds for the biggest incident size that we'd want to prove, so yeah, that's nice. The prover memory requirements, if you have a machine that has four gigs of memory, you should be able to run this. Again, this is our proof size, so we're in the orders of kilobytes here, right? So the small, basically at the biggest incident size, we got a proof of about nine kilobytes. And then this verify compute. This is, again, we'll see this becomes a big problem. We're talking about doing elliptic curve arithmetic again. Similar to how bulletproof was doing. The incident sizes are significantly smaller, but there's still significant work to be done there. To contrast copis with Dory, which is the other polynomial commitment scheme, Dory takes advantage of some pre-computation to reduce this verifier time or this verify compute work even further. And as a consequence, their proofs are about three times bigger, so just take these proof sizes, multiply by three, and then the verify compute is significantly less, like we'll see on the next slide. So quarks look promising, at least the polynomial commitment schemes look promising on paper. The problem is now, if we wanna start, again, running this verifier on Ethereum, the problem is, particularly, even though there's Alt-Bn128 support, there is no GT exponentiation support. So yeah, so that's a significant problem. And basically we simulated, we implemented some GT arithmetic, we simulated the total cost, and we got down to about four million gas to do one exponentiation. And so a whole Dory verify would cost about 125 million gas or $12,000, so smaller, but we're still not there yet. And so now we start asking questions, where do we go, do we really wanna use a transparent snark? Let's go see what this Planck is all about that everybody's using. So Planck's very popular, it's got a ton of support, proofs are small, verification is, the cost is known, and really what we'll see really importantly is, Planck is supported, the verifier is supported by pre-compose in Ethereum. So all of the heavy arithmetic is cheap. So we dig into Planck, fortunately, like I said, Planck is so popular, there's a lot of high quality open source limitations, there's a lot of high quality blog posts, describing Planck, and we see the famous small verify compute, small proof size. The problem with Planck, and this is a known problem too, and this is why everybody is trying to make this proofer efficient and try to optimize circuits, is this proofer time and proofer memory is expensive. So Planck needs to run FFTs, FFTs require N log N work, and they are also not space friendly. And so if we try to prove just a raw two to the 28 size instance, we're looking at, that's 500 minutes, so we're looking at about eight hours, and you need about three terabytes of memory on your machine to be able to complete a proof of this size. You could do it, you could go to the cloud, rent a GCP instance, and you could get it down for about $200, but you're not gonna be able to prove this out of the box. All right, so now we start asking our questions. We've started getting introspective, we've surveyed some snarks, we've flip flopped between transparent snarks to trusted set of snarks. What are the important questions here? So one thing that really popped up is, why is Planck's verifier so much cheaper than say Dory's verifier? And so if we just look at the algorithms that are being used, Planck's verifier requires pairings, pairings require GT exponentiation. So a pairing should be more expensive than a GT exponentiation, and if you actually do the math, Dory's PC should cost only about 16 times what Planck costs. And so that seems like a reasonable trade off that somebody would be willing to make if they don't have to run a trusted setup. And so the reality is, as we saw, the cost is about 500 times Planck verifier. And so really it's this pairing check EIP. And so one of the big points that we're trying to take away here is, we've seen that there are kind of cost competitive transparent snark primitives, in particular there are interesting polynomial commitment schemes, these COPA schemes, Dory schemes that could be useful. But we're not gonna be able to run, we'll never be able to run them on Ethereum mainnet because things are too expensive because they're not supported by say pre-compiles. And so one of the questions, and this is kind of just like a thought question, is Ethereum ecosystem artificially selecting for snark primitives with cost that don't reflect reality? We say Ethereum is driving snark research, and it is, and we're seeing like a flurry of development, especially for primitives like Planck. But is, I mean the reason is it's cheap to verify. And so the question is, that costs aren't reflecting reality. We wanna address this question, if there are other people who have kind of run into some of the things like come talk to us, we have ideas of how to address this. Yeah, with the last minute, where do we go next? All right, so we've gone all over the place. We've surveyed a bunch of snarks. Actually, there's a ton of snarks in practice, right? And we look at all of these. This was our path, but there's a whole bunch of places we can go. The other point here is snarks, generally we think of them as proving kind of arbitrary programs, NP complete, or NP statements that powers a cost. There are other proving systems that have cheaper costs. Signatures are one such proving system. So we sell away from the land of snarks to the land of homomorphic signatures. And so what a homomorphic signature does is it basically allows you to sign data. And then if you like sign two messages, you can add those two messages together and the result is a signed message for the sum of the two underlying messages. So it's a pretty cool primitive. Haven't really seen it used much in practice, but we have a unique application here on blockchain. And so we can take advantage of that and run this referenced scheme. And basically the bottom line is we get small proofs, small verify time, similar to Planck. These costs are about the same cost of aggregating just regular bill of signatures, so elliptic curve arithmetic. And we can get something done for less than $30. Quote I like, it's worth thinking about. Again, this is who we are, Edge of Node, Semiotic Labs, record developers for the graph. I'm with Semiotic AI. We're looking for people who are interested in these types of problems. We're also looking for people who are interested in AI, reinforcement learning, all kinds of good stuff. We're looking for people. If this was interesting, reach out. Thank you.