 Next presentation is by Adrienne from Aztec, the future of Plonkish Systems, and I expect Adrienne on the Zoom later, yeah. Hi everybody, I'm Adrienne and I work at Aztec basically making Snarks faster. I hope you're all having a wonderful time in Bogota this week, unfortunately I wasn't able to make it due to getting sick at the last moment last week, and so this is why this presentation has been pre-recorded. I'm going to be talking about some thoughts and hypotheses I have about what the next generation of Plonkish Systems is going to look like. By the way, there's going to be a Q&A once this video finishes, so write down any questions you may have with slight numbers, I'll do my best to answer it at that point. Here's my Twitter and Telegram handle if ever you have any questions that come up later. So I'm going to start with a brief recap of the evolution of Plonk until now. In 2019, Zach and Ariel came up with this certainly name-proof system that kind of revolutionizes the ZK space. The state of the art until then was basically growth 16, which is based on R1CS, but the per-circuit trusted setup made it a bit more complicated to deploy. With Plonk now, we had a ZK snark with very similar performance profile, but it only required a one-time trusted setup, but really I think one of the main innovations was that we're now able to represent circuits in a much more practical way, which made writing circuits easier because the resulting representation looked a lot more like the actual functionality you wanted to compute. Over the years it followed, many new techniques and tools and improvements were introduced that basically tried to tackle concrete efficiency. There's the introduction of different custom gates, which allowed for more efficient elliptic curve group operations for different hash functions or really any kind of more specific computation you might have in mind that might appear several times inside of a circuit. We also got lookup protocols, which allowed us to essentially pre-compute the inputs and outputs of more complicated functions that might be a lot harder to do inside of a circuit and in a way that we can just look up the results from these huge tables. This made a big difference, especially for operations or functions which are hard to do inside of a circuit that works over finite fields. It also made range checks a lot easier to check that an integer is in a certain range. Beyond that, there's also a lot of work done on just improving the tooling and the introduction of quite a few languages and DSLs like Noir or Halo 2, which essentially help make more optimized circuits. One thing I want to note with all of these improvements is that they all try to tackle the same thing, which is prover time. With a lot of these, what you're trying to do is make the circuits smaller, more optimized, but the real concrete effect of this is that the prover has to do less work. Unfortunately, there's only so much we can do, and we're still faced with the same roadblocks like the FFTs, which mean that the provering time is going to be lower bounded by N log N. So you may wonder, what's next for Plunk? Well, recently at ZK Summit 8 in Berlin, Benedict Bunce from Espresso System announced hyperplunk, and it claims to drastically increase the efficiency of plunkish circuits. The main improvement is that there are no more FFTs involved, and the proof can now be generated in time linear in the circuit size. At the heart of hyperplunk is sum check, an incredibly efficient protocol from the 90s. Even though it's been out for almost 30 years at this point, I don't think it's received nearly as much attention as it deserves, especially in the context of Snarks. But this is great, because this means we've got a brand new problem that's ripe for optimizations. So in this talk, I want to go over some of my personal hypotheses about what changes we're likely going to see around ZK Snark circuits and deployments, and that we've got this new proof system to work with. So instead of Snark, we need an efficient way of checking that N different polynomial equations vanish over a predetermined subset of a finite field. Previously, this was done using a quotient test that relied heavily on FFTs. However, we've now found out that this is doable with sum check as well. From a high level, this table shows the main differences that come up when we use one system over another. First of all, we have to change the way we represent polynomials. Instead of interpolating a vector as a univariate polynomial over the roots of unity, we use multilinear polynomials over a binary hypercube. In terms of efficiency, we notice something particular. We have to sacrifice small proofs and fast verifiers in exchange for faster provers. But when you want to implement Snark, these asymptotics hide way too much detail. And I'm going to argue the benefits for the prover are actually a lot better than just removing this log N overhead from the FFTs. So let's get into the weeds bit. Recall that we usually want to prove that we have this polynomial p, usually called like the Planck identity, which is a polynomial which equals 0 when it's evaluated over all points little h belonging to a larger subset h. Now, what does this Planck identity really look like? Well, I'm going to give you a simplified view of it. But essentially what it does is it is a sum of all the different gates that make up our circuits and multiplied by different selectors which either activate or deactivate a gate depending on which operation you're actually trying to do in each row. Now, I want to emphasize that this is a cross simplification of what is actually happening, mainly to get everything to fit in the slides. And so don't go implementing this stuff. If we look at this identity I wrote down, what we have is a certain number of custom gates. And each of them are multiplied by this multilinear binary selector polynomial sj. This is just the interpolation of a vector of 0s and 1s. And it multiplies this more complex gate polynomial which is going to be 0 if the gate is satisfied by the input wires w along with some fixed constants q. So both w and q are multilinear polynomials and g is just a function which combines these. If we take a closer look at the selector, we can see that it's just an indicator function over specifics of hj. Now I'm choosing to partition h in this way because it makes it more clear in which parts of the circuit, in which rows each gate is active. And this is going to help us a bit later on. Basically, the circuit is valid if this polynomial vanishes, which is only the case when either the selector is 0 for each gate or the gate itself equals 0. The way you'd prove this in a standard plonk is just by computing the polynomial which divides this polynomial p where the division is by the xn minus 1 which equals 0 over all the roots of unity. How do we do it with some check though? The way it's usually presented is that it allows a prover to prove a claim of the type sigma is equal to the sum of all the evaluations over h of a certain polynomial function p. Now, this doesn't help us right away, but instead if we said p prime is equal to p multiplied by this weird random equality polynomial that's often used in some check proof systems. Well, we can set sigma equal to 0 and because this random linear combination is 0, well, proving the sum check essentially is equivalent to a vanishing test. Now, unfortunately, due to the time constraints, I'm not going to be able to get into more detail about how to perform the actual sum check. There's a lot of subtleties involved and I need to make some implications. But one of the key observations I wanted to make is that if we look at the sum check sum for one particular gate, so we just take the gate from the previous slide and multiply it by this equality polynomial, this selector polynomial plays a big role because we notice when h ranges over big h, well, s of j is going to be 0 whenever the gate is not active. So this means that we can rewrite the sum ranging over the set of points at which g is active. Now concretely, this means that the prover only actually has to evaluate this polynomial equation g in the number of times that it's actually used. In other words, the proving time is now much more closely linked to the time it would take to evaluate the actual circuit because we don't need to evaluate the gates at indexes where they're not active. And the verifier time basically only depends on the maximum size of a circuit log n. This is due to sum check. But for each additional custom gate that we have, it only adds a constant amount of overhead. So if we take a step back, what do we actually get when we use sum check in practice? So what I expect to see is it will have provers defined with way more custom gates than we previously have. And you may have some which have way more complexity, which are able to do a lot more work at once, even if those gates are not used very often. Because essentially due to this sparsity that's preserved by not having to do the FFTs, the prover is only going to be running the gates that are actually active. In other words, you're only paying for what you use. To me, this kind of feels like we're heading to a more, an architecture for circuit that resembles a bit what we had with like x86 processors, which are complex instruction set processors where you've got many different kind of functions. This is compared to the risk or reduced instruction set type of processors where you only have a couple of instructions to use from. So it's kind of interesting to see this difference in how we do circuits compared to processors. However, this isn't the only thing that we get from sum check. In fact, if you've got like rather optimized implementations, you should be able to see way smaller memory footprints than what we currently have. And another nice thing about the memory is that the access patterns are a lot better. Everything is more sequential, which means that you're able to way more easily paralyze this sum check procedure. Now, unfortunately, we're still going to have to deal with this annoying log in verifier cost and proof size. But the one thing that's happened over the last few years is we got a lot better at doing recursion and we understand it a lot better. And what this means is we will be able to more efficiently and more easily write a standard plunkish circuit that just performs the sum check based plunk proof verification. And therefore we end up with a best of both worlds situation where we got a really fast prover with relatively small overhead to generate a proof. And the final proof is going to be constant size with fast verification. Another really nice thing is that sum check doesn't really rely anymore on a specific field. So because we don't do any more FFTs, well, we don't really need any specific field which has a large root of unity, which means that we might be able to deploy snorkels over different curves now. Although that also depends on the trusted setups we have available, et cetera. So with that, I hope I've convinced you that there's a lot to look forward to in terms of improvements for snorkels and that the future is going to be bright full of possible optimizations. And I, in any case, can't wait to see what everybody is going to come up with. Please let me know if you have any questions. And again, here's my handle if ever you have any questions that come up later. Thank you. So any questions for Adrian? I actually have a question. Oh, you have a question? Go for it, yeah. Thanks for the presentation. I have a question about the sum check argument. How we can handle not these things cancelling out to zero? Are we going to need to choose a specific field size? So because we are just adding up this stuff and we are assuming if they are all zero, the addition will be zero. But what if sometimes they are not zero and they somehow cancel each other out? Would that be possible or why it's not possible? I'm not going to zoom, but I just started from the video. I didn't know if I'm late or anything. But if I get your question right, it's like when you have the sum over all the gates, what I'm missing here is like the linear combination factor like the kind of one you would have in a plonk as well. That's your question. Yeah, it's like a random linear combination. But I get that we can do that for combining the addition for different circuits. But for each circuit, we have a sum on Hj. So why that summation would not be zero even in cases that all the terms are not zero? Does it make sense? Great. So I missed all the actual sum check protocol but what happens is you're proving that sum by sending univariate restriction polynomials. So you sum over part of the points and you keep one free variable and you send log n univariate polynomials, which need to satisfy some property. And that's the second character assumption. OK, we can continue this discussion async. But thank you, Adrian. Cool.