 Thanks for coming. So I'm going to talk about transparent snarks from Dark Compilers today. And this is joined work with Alan Trapaniak and Ben Fish. And the main problem that zero-knowledge proof solve is something that you can see here in the Bitcoin transaction and the same holds for Ethereum transactions. It's that if I want to check the validity of a Bitcoin transactions, then I need to know the check for a Bitcoin transaction is that the sum of the inputs is greater or equal than the sum of the outputs. And to do this check, to check that the transaction is valid, I need to know these amounts. I need to know how much money is being sent. And very similar in Ethereum, I need to check that the person who's sending some money has enough balance in their account to send the money. The difference is actually the fees here in Bitcoin. The problem is that this is actually really bad for privacy because everything is public. So what this means is if I get my salary in Bitcoin, for example, in Ethereum, then my salary will be public on the blockchain and everybody can see it. And that's not something that I want to have. So for example, also if I'm a supplier, then if I'm a company and I buy some supplies for my company, then all of my competitors will exactly see how much I'm paying for these supplies. And that's an important business secret. And this really leads to this maybe slightly controversial statement, but that Bitcoin in the way that it works now, it's really unusable for businesses. And in a similar way for Ethereum, if I run maybe some investment fund on Ethereum, then everybody can see exactly what my investing strategy is. My whole bit of this secret is the whole secret sauce is my investment strategy. But if this fund is on Ethereum, then everybody can exactly see if it's on Malin or something, then everybody can exactly see what I'm investing in. They confront me, it creates all sort of problem. And this really means that Ethereum is unusable for many financial services. Well, luckily, we sort of know how to solve these problems. And that is by using cryptography and especially something called zero knowledge. And there the idea is that instead of having a Bitcoin transaction that looks like this, I'm going to hide all of the amounts. So I'm going to use something called a cryptographic commitment to hide all of these amounts so no one can see what these amounts are. They're basically encrypted. And the question though is then how do I check that the transaction is valid? How do I check that the sum of inputs is equal to the sum of outputs plus the fees? And similarly, in Ethereum, how do I check that the sender has enough money in their account to send the transaction? And the way to do that is using something called a zero knowledge proof. And this is really a magical cryptographic tool where Peggy can convince Victor, so the prover can convince a verify, that something is true without giving up any information about why it's true. So for example, I can convince you that I'm committing to a positive number, like the remaining balance that I have is positive. But I reveal no other information, and especially I don't reveal what my balance is. All of that remains private. And the way that this works is basically one way to imagine it is through this interactive challenge response protocol where Victor gets to ask questions that Peggy wouldn't know the answer to if this wasn't true. She could not answer these questions if the statement wasn't true, if the balance was negative. But the answers don't reveal any information whatsoever about what the statement is. So what we really need, though, in a blockchain setting, is not this sort of interactive proof. And in the end, Victor has no idea what access, but it's positive, and Peggy must know it. And what we really need in this interactive setting is a NISIC, a non-interactive zero-knowledge proof of knowledge, where basically the prover can just write down the proof, and the verify can read it and check it, and everybody can read it and check it. It's publicly verifiable. And this relies on some common reference string that both the prover and the verifier have access to. And there's many different kinds of zero-knowledge proofs. There's maybe you've heard of Snarks, you've heard of Starks, you've heard of Bulletproofs, and then there's also a bunch of others. There's a tremendous development happening in this space. And I'm going to vastly oversimplify. Ooh, this went wrong. The orange ones should be green. The orange ones are good. So the vast oversimplification is that looking just at Snarks, Starks, and Bulletproofs is that Snarks and Bulletproofs, they're good on the proof size, Starks not so much. The verification is great for Snarks and Starks. And Snarks are great now, but unfortunately they have this thing called the trusted setup, where someone needs to perform a trusted setup. I'll talk about the trusted setup and why this is a problem in a second. But basically, there is this party who creates a proving key and a verification key. And if that party cheats, then really bad things are going to happen. And maybe a little bit more and more in-depth comparison that I don't want you to read, but this is a recent comparison. And basically, there's no Snarks without trusted setup that doesn't have our no-proof system without trusted setup that has logarithmic proof size and logarithmic verification time. And this is exactly what I'm going to present today. The first practical Snark with logarithmic proof size and logarithmic verification time. So Snarks have this trusted setup. So what is the trusted setup? It means that there's some party, some really nice guy, who creates a proving key and a verification key. And the prover uses the proving key to create the proof. And the verify uses the verification key to check the proof. But if that party colludes with the prover, if that party cheats, then it can break math. Then it can say that 3 plus 3 is equal to 4 or 7 or whatever. And why is this a problem? Well, if the trusted setup is subverted, the prover can create fake proofs. And what this means is, if we have subversion, then I can create money out of thin air. I can have one z-cash coin and create a million out of them because I can break math. And that's really problematic because suddenly we have undetectable inflation. The privacy still holds. It's really, really bad. You can alleviate that through a distributed setup, which is what z-cash did. And they did a really good job with it. And those are the smartest and the absolute word expert in Snarks. And they still messed it up. The setup was broken. They luckily caught it before something bad happened. Or at least we think so. We don't know. But the setup was broken. So it's really difficult to get this right. And one other thing that is really annoying is for the most efficient Snarks. Every time you have a new functionality, you need a new setup. So for example, if I want to have one snark per smart contract, then I need to have a new setup every time. And every time that setup can be broken. So this is quite problematic. So really the goal is to remove this need for a trusted setup. And Bulletproof, for example, does that. But Bulletproofs works for small and medium complexity transactions. But for large complexity transactions, it just takes too long to verify. It doesn't have the succinctness property where it proves they are very efficient to verify, even if they are very complex. And Snarks have that. So this is why we built Darkproofs and SuperSonic. So how does that work? Well, the main thing that we built is a new polynomial commitment. So what is this? So this is a cryptographic tool where the prover has some polynomial. So 3 plus 2x plus 5x squared and so on of degree d. So it has d plus 1 terms. And the prover sends this commitment, which is a small value, even though the polynomial is large. The verifier can send a point z. And then the prover can tell you the polynomial evaluated at z is equal to y and give a small proof that this is true. So this is a polynomial commitment. And recently, there was this cool new proof system called Sonic, which is a new kind of Snark by, I dropped the reference there, but Mary Mahler and Chambault and others. And it's a Snark system that uses a polynomial commitment scheme. And it has a trusted setup still. But the trusted setup is only for the polynomial commitment scheme. So nothing else requires a trusted setup. And it's also, it already is universal. So it already removes this problem that you need a new trusted setup per circuit. So it already is great. And it got even improved. The constants got improved by new proof systems called Planck and Mahlen. But they're all the same family of proofs. And what we do is we build a new polynomial commitment scheme, which uses so-called DO-14 arguments of knowledge. So integers, integer equations. And that's why we call it a dark. And it uses these so-called class groups. And it has logarithmic communication time and logarithmic verification time. And most importantly, it doesn't have a trusted setup. So what does this give us? Well, we have Sonic. And now then we plug in this new dark proofs. And then we get this sort of messed up. But we get, what happened here? I'm going to fix this piece for this slide. We're going to get supersonic, which is the first snark with short proofs and no trusted setup. The proof size is less than 10 kilobytes. Verification time is less than 100 milliseconds. So it's very nice. So how do we build this? Well, we built this something. And now we're getting into the technical part, trying to understand how this actually works. So we're building this using something called a polynomial IOP. So what is a polynomial IOP? Well, basically, think of it as if the prover and the verifier have access to some polynomial, maybe in multiple variables in the sky. And then in every round, the prover sends maybe a new polynomial, the verifier sends a challenge, and you get some new polynomials, and so on. Some interaction where the prover and the verifier send you some polynomials, and then you send the verifier sends you some challenges. And these polynomials may be large. But what we can then do if we have a proof system like this, and Sonic is a proof system like this, then we can use a polynomial commitment scheme to not send the polynomials, but just send the commitments to the polynomials. And it turns out this is interactive. So there's a generic transformation called the Fiat-Chemure transform to transform this from an interactive proof to a non-interactive proof. So basically, all we need now is this thing, and then we can focus on compiling these things down. So this is the general recipe of how we can build these snarks. And a lot of different snarks actually fall into this category of polynomial IOPs. So if we build a new polynomial commitment scheme, it helps improve all of these snarks and make them all of these proof systems and make them have no trusted setup. So that's exactly what we did. And Sonic, as I already said, gives you a five round IOP with 24 oracles. But in general, we can make this work. So let's focus on the main construction. So the first thing of this polynomial commitment scheme. So this is what we're trying to do. We've boiled it down to we just have to build this polynomial commitment scheme. So let's recall what a polynomial looks like. So what we're going to do is we're going to take this polynomial and encode it as an integer. So what we do is we simply pick a large queue. So all of these, normally these polynomials are in a field, in a prime-order field, zp. But what we're going to do is we're going to represent it over the integers and pick a queue that is larger than each of the coefficients and then just simply evaluate the polynomial at queue. So this might seem a little bit weird. Why are we doing this? What does this mean? Well, let's think about it very concrete. So our polynomial is 4xq plus 2x squared plus x plus 3. And then we take q equals to 10. And we evaluate f hat at 10. Well, what do we get? We get 4, 2, 1, 3. It's literally just the coefficients written next to each other. Because 10 is where we're thinking in decimal. So with 10, it looks really nice. But you can do this with any other number. If I had chosen 8 or 5 or whatever, this would have worked as well, or 100. So what we do here is we transform our polynomial into an integer. So why do we do that? Well, this integer encoding has very nice properties. So if this queue is large enough and there's no overflow, then actually this has homomorphic properties, additive properties. So I have one polynomial, 4, 2, 3, 1. I just give you the integer representation. And another one, 1, 4, 4, 3. And it turns out that if I add these integers, I get the encoding of another polynomial, which is literally the sum of the original polynomials. So if I add the polynomials and then encode, it's exactly the same as if I encode and then add the integers. So this is what we call a homomorphic property. So this is an additive homomorphism. And it turns out there's also a multiplicative homomorphism or monomial homomorphism. So if I want to shift the polynomial by a degree x to the k, say x squared, then this is simply equivalent to just multiplying it with q to the k. So x squared times h of x is 5x squared plus 6x to the fourth, blah, blah, blah. And this is simply equivalent to just multiplying 100 times the encoding. x is 10, or q is 10, 10 squared is 100. So all of this works. So now we've transformed our polynomial to integers. So why does this help? Well, there is these cryptographic tools called a group of unknown order. These integers are still large. If my polynomial is large, the integer is large. So I cannot send you the integer. That would be way too large. But now cryptography comes into play. And we have this thing called a group of unknown order. And all you need to know is that basically this is a commitment to integers, which shrinks down the integer. It doesn't matter how large the integer is. Could be hundreds of millions of digits. It shrinks it down to something that is constant size. But the homomorphic properties, these additive properties, are still preserved. So I can give you a commitment to integer 3 and then 1 to 4. And then if I add these things, then I get a commitment to 7. And so what I can do now to commit to my polynomial is I lift it to the integers, I evaluate it at q, and then I compute g to the f of q. So now I have a way. And then I can still do all of these additive operations up to a certain bound. So this is the way that we commit to the polynomial. And this is the main tool that we're using. And then so what are these groups of unknown order? Well, there's different ones. But one that you could use is this class groups, which in general cryptography, it's important to think about abstractions. So don't go looking up class groups. It's not worth your time. Just use them as a tool. But there are a group of unknown order. And so we believe that computing the order is hard. We believe that taking roots is hard. And most importantly, they do not require a trusted setup. So I can generate this group. I only need to do it once. And it doesn't have to have a trusted setup. And they're a little bit, compared to, say, elliptic curves, which, by the way, elliptic curves are not an integer commitment because I do know the order. So if I commit to some large integer, I can reduce it and mod the so-called order of the group. But the problem is that these groups of unknown order to be secure, they need to be quite large. But that's unfortunately something that we have to deal with. So how do we build a polynomial commitment? So let's think of this, again, just in terms of polynomials. So what I want to do is I have a polynomial of degree d, so with deep terms. So it's this large polynomial. And then we're going to use recursion. So to use recursion, we'll split it up into two parts, the left half and the right half. So fl of x and fr of x, such that fl of x plus x to the d over 2 times fr of x is equal to f of x. The prover then sends fl of x and fr of x to the verifier. The verifier checks that this equation holds. Checks that f of x is equal to this. Using again in the end, this will use these homomorphisms. And then the verifier sends a random challenge. So this is a random alpha. And then the prover combines these two polynomials just using the linear combination, fl plus alpha times fr of x. And this gives us f prime of x. And importantly now, after this one step, we now have a polynomial of degree d over 2. So we reduce something from degree d to something to degree d over 2. And then we can just repeat. And if you do the math and you had, how often do we need to repeat? Well, we need to repeat log 2 of d times. So say the polynomial is of degree a million. We need to repeat 20 times. If it's of degree a billion, we need to repeat 30 times. So of course, we cannot send these polynomials in the clear. So what we're going to do, we will really send these encodings. Again, we evaluate the polynomial at q. We raise it to the power and so on and so forth. But it's important to think about this interactive thing. But I also want to evaluate the polynomial at a point. This doesn't, there's no evaluation here. So what I'm going to give you is additionally, I'll give you, I'll claim that the polynomial evaluated at z mod p is equal to y. And then basically, in parallel to sending these things, I always also send you, you know, fl of z in zp and fr of z in zp. And these things are constant size. So these things are small and you can efficiently check. And then again, you can efficiently, you know, check this equation, right? So this would be yl plus z to the d over 2 is equal to yr plus yr times yr is equal to y. So I can check this equation both for the polynomials and for the evaluation very efficiently. And then I can compute my y prime. And the last round I compute my y prime, which is equal to f prime of z, which is equal to yl plus alpha times yr. So maybe that was a little bit too fast, but it turns out that basically, you know, like I send you these polynomials, I split them in half, take a random linear combination and then recurse. And if I want to evaluate this polynomial, I also do this on the evaluation. And then in the final step, I have a polynomial, which is just a constant degree, right? It's just a single element. Doesn't have an x term anymore. And I also have the commitment to the polynomial and I have the proposed evaluation. So the proof is just since then f0 in the clear, degree zero, and the verified checks that f0 is a small constant and that c is equal to g to the f0 and that f0 is equal to y, right? Or f0 mod p is actually equal to y, but you know, that's the detail. And so what this gives us is a polynomial commitment with two log d group elements in every round. Two log d field elements and we can use lots of batching tricks to make this really efficient. And you know, there's some more tricks that you need to apply to make the verifier efficient. So for example, you know, you need to use some tricks to make sure that this check here is efficient, but using some recent work in the space of PDFs, we can also do that and yeah. So I am done with the main part of the talk. I think maybe it's, I can talk about some optimizations, but maybe, you know, there's some questions and I think I'll just take the questions now. Thank you.