 Hi everyone, welcome back. So our next speaker is Brian Wilkes, and he'll be comparing the performance and security characteristics of some zero-knowledge proofs that are commonly deployed in the Ethereum ecosystem. So Brian? Hello, wow, that's loud. So who are my data scientists in the room? Raise your hands. Very few. Devs, devs out there? Lots of devs, nice. Investors, DGENs? Yes, put it down. How about expertise? Who's a beginner in zero-knowledge? Just get the basics. Cool. Who knows what's going on, but has not written a circuit before? Who's a true ZK expert? Knows a ton about ZK. You, perfect, all right. Well, thanks for having me. My name's Brian. I am a grantee with the Ethereum Foundation Privacy Scaling Exploration Team. So today I'm going to be talking about ZK-proof performance and security characteristics. So what's in the docket for the day? Search for it to go over some background. So we'll just give some background on what ZKPs are, try and work through what they actually mean for on-chain data. Then we're going to look at how to actually find those zero-knowledge proofs and verifiers on-circuits on and off-chain. Then we'll look at some of the characteristics behind those and what they mean. Unfortunately, Waldo's not going to be with us today. So this is the second best piece of art I've ever done. So I hope you appreciate it, everyone. So what are ZKPs? About high level first. We'll go through this quick and then move on. But we have Alice. Alice wants a drink. She's a prover. We have Bob. Bob is the bartender, is a verifier. Alice does not want to give all of her information to Bob. And so therefore, she can put in her birthday. The circuit will output a proof. Bob can verify that proof is correct that she's old enough to drink and the survey so will flow. So what's important for this is you have a prover. You have inputs. You have the circuit itself. You have the proof popping out. And then Bob decides if it's true or false. It then does an action based on whether that verification is true. So why do we need zero-knowledge proofs in Ethereum? So the first thing that we struggle with is scalability. So right now, we can do about on main chain, 13 transactions per second. And we really need to get into that 13K transactions per second, if not significantly higher, to get in the visa range. So how does zero-knowledge proofs help us? They can take fully separate chains and they can impart the full security of Ethereum to those chains. So privacy as well is something that's a hotbed issue to me. Ethereum is public. If you're a data scientist, as a few of you are, you can go online or you can go on Ethereum and see anyone, everyone ever does. So I don't want to live in a world where you have scalability and everything sits on that platform without having the privacy behind it. So let's talk about on chain. So this is what it looks like. You have your layer two blockchain here. So they have the blocks going. You aggregate some of the transactions together. And then you batch them into a ZK circuit. So you take those transactions. They go into the circuit. The circuit produces a proof. This is all off chain. So then you have your Ethereum main chain where things are expensive. So you're able to take your proof and post that to the Verifier smart contract. And then the layer two state source of truth can get updated. So that's what happens with the scalability side of things. Now let's talk privacy. It's very similar. I won't have reveals for you. I'll just go right to it. There's the secret. There's the ZK circuit. You put the secret through. It produces a proof. And then that proof goes on chain to the Verifier smart contract and funds are released. So that's very similar. That's going to be your mixers, your chain of caches, different things. What's important for both of these two is that you have off chain and on chain. And on chain is where the Verifier and the proof gets posted. And off chain is where the circuit and the proofs are. So this is the best piece of artwork I've ever done. So I appreciate it while you can. So let's find some ZK proofs on chain and figure out where they're at. So this is called the search for Verifiers. So why are we searching for Verifiers? The important characteristics of a zero-knowledge proof are in the circuit. So the circuit's going to generate, they're going to have the different characteristics that are important to us. Let's look at a particular ZK sync transaction flow, for instance. So between September 20th and September 26th, there were 2,170 blocks, 265,000 transactions which were batched together into 214 inputs, proofs, brought on chain. So what you want, the ZK circuit did not change, but those inputs and the proofs did. So each circuit has a unique Verifier on chain. So for each circuit or circuit systems, they have their own unique Verifier that's there. And if you want to know about circuits and you want to use on chain data, you need to go through the Verifier. So going through the Verifier, you use the L1 chain data. So let's talk about how to find Verifiers. So the first section is, if you guys haven't used BigQuery from Google, I highly recommend it. It's a great tool. It allows you to search through lots more data than things like Dune do, as much as I love Dune. So different queries that time out within 30 minutes for Dune will go in about two seconds for BigQuery. So check it out. The three tables that I used for this project were contracts, traces, and transactions. Since you're almost all devs, I won't go over traces versus transactions, but the start versus end of things. So, okay, so the first way to try and search through bytecode is to go for constants. Constants will show up in bytecode as a big hex. So if you can get a big enough number that's unique enough for what you're looking for, you can take that and search with very simple SQL queries in through the bytecode. So this is both a big and unique value. It's the finite field. So the finite field is the range at which you modulate over when you're doing different cryptographic things for zero knowledge. So this is it in hex form. It's massive. So the first way that I looked through the data was to search for this finite field. Unfortunately, it didn't exactly give me all the verifiers. So it gave me a lot of different noise. There's 558 contracts that have the finite field constant and after checking every one of them manually, most of them were not verifiers. So I moved on to trying to get into method IDs. So the second tool that I think is really important and apparently it's new according to EtherScan is the transaction decoder. So the transaction decoder, what it does, if you look through it, is if you go through and look at a transaction, it will tell you the exact flow of what happened through that transaction. So looking at this here is another ZK sync example. First it proves the blocks after going through some proxies and then in the verifier contract, it calls a function called verify aggregate block proof. So after doing some modular addition down below, it outputs true and the state gets updated. So method IDs, the method IDs are the first 10 characters or four bytes that come through with any input or transaction call for traces or transactions. So just going through them briefly, you can see that this function here is for starkware and it's a fry verifier. So this is what is actually verifying the proofs. So if you wanna know what the method ID is for this particular function here, then you take out all the chaff, if you will, from inside and then you run the KCAC 256 and you take the first four bytes plus the indicator that it's hex. So that there, the OXE85A6A28 is the method ID. It'll be the first 10 characters in any call when you look through the data. So a great resource, again, I like to show the resources that I get to use. The four byte directory is fantastic. You can input any method ID and it will tell you what the text signature for what it should be is. So now what do we find? Essentially, there's about 65 confirmed verifiers on main chain. Now there's probably a few more, maybe 30 more that are not verified public contracts. So in those 65 confirmed verifiers have done over 600,000 verifications. So of those, there are about 16 that are active still. That's active according to me and some of them are very minor projects. If you're trying to squint, it's because I made it small so you'd have to go on the GitHub at some point, so sorry. I was surprised by how few verifiers that are actually on main chain, but moving on to the characteristics. So we'll look at proving systems. So your proving systems here that are actually being verified on main chain you have your classics. I'm sure you guys have all heard of these, but your Grot 16 from 2016, that runs your tornado cache, your Hermes, your loop ring in a bunch of other different privacy functions. You have Planck, which is Aztec Connect ZK sync. Then you have Turbo Planck, which is the original Aztec. Aztec Connect uses Turbo Planck before it gets on chain, but then it uses Planck on chain, if that makes any sense. Then you have Halo 2, which is coming out. ZCash uses it, and then also scroll is gonna deploy with it. Most people I talk to are really moving towards that Halo 2 move. It seems like it's a really good proving system. So it's not on main chain yet that I've seen. So then you have your Starks, and that includes all your Starkware projects. So Starks versus Snarks. Snarks, the succinct, non-interactive argument of knowledge. And then there's Starks, which are scalable, transparent arguments of knowledge. And the major difference between the two, there's a bunch of them. These are the base level for what happens. But quantum computing is probably going to be able to take down Snarks, but Starks will probably be resistant to it. So what is quantum computing? When will it come? I have no idea, but if it does, this will happen. So looking at these different proving systems, you have Groth 16, which is in blue, really taking off. That's on the back of Tornado Cache, as well as Bloopering. And then you have down below, you have your Stark slash Fries that are coming through. Those are the Starkware projects. They have really taken off. DYDX posts a lot of data to chain often. Then you have your Plonks, and unknowns are probably Plonks, but I wasn't quite confident enough to say that, so. Okay, let's talk about trusted setups. So a trusted setup is where on the elliptic curve you should evaluate the different ZK proof. So it's kind of an agreement in a spot that a prover or verifier can kind of verify through what that Snarks can look like. So I like to think of it like a trust fall. How many people have done trust falls before in their life? A couple, yeah, it's scary. So you get up there on a big standing, and then you fall backwards, and as long as one strong person below you is there to catch you, then you should be good. So as long as the trusted setup is kind of similar. If everybody's toxic waste gets collected together, if everyone gives their secret out, I mean doesn't want to catch you or is distracted, then the Snark can be, then the trusted setup will not work, and someone will be able to write proofs that will be false positives, and they'll be able to take money from you, if that makes sense. So this requires one honest participant from the MPC ceremony. I also like to think of it like Thanos. If you have enough Findi stones, if you have them all, you can destroy the proof, and it'll be good, so bad actually. Okay, so what are the trusted setups? We have Grout 16 over there on the end. It has a two phase trusted setup. And then the universal setups came in, and that's a Planck and Turbo Planck, and that only requires one. So whereas Grout 16 needs a new ZK circuit, or needs a new trusted ceremony for each circuit that it produces, Planck and Turbo Planck have a universal setup, and that allows them to only have one total ceremony. So if anyone here wanted to create a Planck, you could use the universal ceremony that's already been created and already been done. And then you have Halo 2 and Starks. They do not require trusted setups, so that's obviously you want the least amount of trusted setups as you can. So moving on, the actual projects themselves, you have Grout 16s are loopering, polygon Hermes, they're withdrawal, and then Trinocache. Those are the major ones that are currently being in operation. So the number, these are trusted setups. They use the perpetual powers of Tau, which is basically an on-chain step one for the different trusted setups. Then they had a step two. That step two, these are the number of participants that were in those ceremonies. So if you can get to 16 people from the loopering that did it, if they all compromised, then that will not be a valid trusted setup. Then those funds will be able to be taken. So you have 16 for loopering, you have six participants in the polygon Hermes, then Trinocache had a whopping 1,114. Moving on to plonks, so like I said, you only need one trusted setup ceremony to be correct, and then anyone can use it. So they're all using the Aztec Plonk universal setup. It is, all these you can see access stations on GitHub to see how they worked, but they had 176 participants in that. So that's all your ZK sync, your ZK space, Aztec connect, Aztec, all the way down the line. And then you have your Starks, which do not have any trusted setups. We'll talk about recursion. This is the other major thing that people are looking for for performance. So as you go through performance, a recursion is the ability to take a big computation and break it up into a bunch of little ones and do them together, and then recursively prove back to the top. So what this allows you to do is parallelization of proof generation. So you can decentralize and have a bunch of provers doing you this in parallel. So get out your Asics, because you just got rid of them for the merge, but, and then it also lets you do proof chaining. So you can have the output of one proof be the input for the next proof. So what provides recursion? Pretty much everything, but Grot 16 is now doing recursion and they're doing it in better ways, I guess, as you move forward. So that was the other, why would anyone use Grot 16? If you can't do recursion and you have a big trusted setup, it's faster and it's cheaper to verify. So it's the OG, it's been there for a long time, but people are moving on because of those two problems mostly. So now I guess we can talk about my favorite topic, which is data availability as a data scientist. So we'll talk, this is gonna be about L1s and L2s. So for the purists out there, L2s would only be roll-ups, but I'll use both back and forth. So ZK Validiums, Validiums, they have their state route is on the bridge contract and then they have their state reconstruction that's off chain. It goes through a data availability committee to go on chain to be able to make it so you have that data, but it is permissioned on that side of things. Then the alternative, which is supposed to be gold, it kinda looks like bronze, so forgive that, is you have your state reconstruction and your state route for the ZK roll-ups down on the bridge contract. So that allows you to always have that data to be able to generate a proof in case you do escape. So why would you do a Validium over a roll-up? It's many more transactions per second. So your IMXs and your different StarkX projects are able to be a lot cheaper. So moving forward, let's look at your Validiums that are currently operating. You have StarkX, which is immutable X. You have Rynify, SoRare, Apex, other ones that are coming out. You have ZK Porter, which is coming out from ZK Sync. Then your roll-ups, I'll run through these because you guys probably all know them, but you have the YDX, loop ring, ZK Sync v1, use ZK space, StarkNet, so I'll pause for the camera. Then moving on, there's a couple more that are, the newer ones that are coming up for roll-ups that are exciting. You have ZK Sync v2, which I think is under 30 days now, which is exciting to mainnet. You have Scroll, which is going for a higher level of EVM compatibility. And then let's see what's next. Then you have all of Polygon's projects, which are all exciting in their own right. So let's talk about what it means to be a roll-up. So everyone talks constantly about how the full security of Ethereum is being inherited by these roll-ups. So what does it mean to have the full security of Ethereum? You need to have the right to be able to force exit from that chain. So if you have on your Layer 2, if they have decided to be against you, you need to be able to submit your transactions directly on Layer 1 to the Ethereum bridge contract and get your funds. So right now you have your happy user down here that's from Walmart. It's kind of creepy, actually, the more you look at it, so don't stare at it too long. That the transaction goes to this, the happy sequencers here, they put the transaction into the Layer 2. Those transactions are batched into the ZK circuit. It produces the proof and it goes to the Ethereum bridge contract as we talked about before. So this is how it's supposed to function. So let's say that the sequencers become evil and start smoking cigars. You get unhappy. So your transactions can't make it to Layer 2 and your funds are frozen. So what do you do? You take your transaction and you go directly onto Layer 1 to the bridge contract. So when you take your Layer 2 transaction, you go directly to it, then the validators have a certain amount of time to actually include your transaction into the Layer 2s. So usually it's between seven and 14 days. So if they don't do it within that amount of time, then hell freezes over and the chain freezes. So your Layer 2 cannot update state on Layer 1 and the zero knowledge circuit, then you as a user can produce a proof from the circuit, then that proof will provide you the ability to get your funds back. So that sounds great, but it's also kind of difficult. How does the average user, especially when these proofs are off chain in usually sometimes proprietary, how do you generate that proof? That's one of, there's a few things that you have to really do to inherit full Ethereum security. So let's go through them. You have to have the available data on Layer 1. So if you don't have that available data, then you can't reconstruct the state proof and therefore you won't be able to properly get your funds back from the L1 contract. Secondly, you need to have functional and accessible force exits. So those force exits have to be in code and they have to be accessible for the average person. They need to be able to generate those proofs. They need to be able to take that data and pool and directly send it to that L1 contract. That for a lot of devs, it's not a big deal that the front ends are all centralized, but we need decentralized front ends to allow people to escape in the case of one of the sequencers going evil. So then thirdly, you need time delays for the L1 contracts. So if the Layer 1 contracts have time delays or if they're immutable, then it gives people the chance to actually exit from that Layer 1. But if they don't have time delays, then they can just change the contract and everyone's funds will be frozen from there. So then last is, this is a nuanced one, but the amount of money that you can secure from L1 is really based upon the amount of locked funds on Layer 1. So if everyone force exits, then the Layer 1 contract, which is the bridge contract with all the assets, they will impart all their assets to the people, but if there's more total locked value above on Layer 2, then somebody's gonna be out of luck. So the best way to think about this is, a lot of the L2s are starting to get traction with direct transfers to them. They might even have their own state from different contracts and native tokens. If you have a native token on an L2 and you don't have assets backing it up on the Layer 1 bridge contract, then the ability for you to inherit Ethereum security and take your assets off isn't there. So it's really important that as we move forward, that any state that is native to the L2 is known for that risk that it has. Now, let's get into, I guess this is the end of my talk, so I'm gonna try and implore you to get into the data directly. Don't be like Waldo and be sad because other people tell you what's true and what's not. We have, I tell you, I'm very impressed with these projects. I think you guys should all check them out. They're all open. You have BigQuery, you have Dune, the Dune's getting better and better and then the BigQuery is a public database that has all of Ethereum Layer 1 posted there. They'll give you $300 credits to go on the query through it and you can really differentiate yourself, especially as a data scientist. You have the project that I actually completed. Please check it out. There's the QR code for it. I'll have it at the end too, so if you miss it, it's no big deal, but please go check out the data tables, all the SQL queries, any of the different things. Please feel free to let me know what I screwed up. It'll be good. And then L2 Beat is just such a great resource. I'm sure everyone's heard of them and I'm sure you've been to their booth yesterday, but they categorize a lot of risks and a lot of specific things happening within these different projects and I just can't recommend them enough to check them out. They're doing bridges now too, which is exciting. And then the Layer 2s. I haven't got to the data on Layer 2s, so it would be really great for everyone to check out the different. We're going to a different layer, modular blockchain, where you have Layer 1s, Layer 2s, and Layer 3s and these Layer 3s are going to be deployed on Layer 2s and the privacy things already are for like semaphore. So I highly recommend that I'd really like to see somebody check out Layer 2s and be able to do the same data type projects for that. So I have some thank yous I'd like to get ahead of. So I'd like to thank the Daily Glay Discord channel and podcast for being so great. That's my favorite Discord channel there is. If you need studs, know things. There's so many helpful people. There's the Zero Knowledge podcast. It's so good for all the new pressing things. I highly recommend them as well. L2B, I'll show them again. And then the Ethereum Foundation Privacy Scaling Exploration Team. That's not their symbol, but I think that their new logo for DevCon is really cool, so I put it up there. And then I'd like to thank Justin Martin for all of his help in getting me into this and I'd also like to thank Mark for all your help getting me through this stuff and really brainstorming through it all and trying to get through all those issues. So I got, thank you very much. I will take, yes, please. I'm sure. Yeah, they'll have a mic for you. Unless you're really loud and then you can just go for it. I was wondering if you comment a little bit more on the security considerations when dealing with native assets on L2's. Like I get that you can't withdraw the funds on the L1, but can you double spend or can you validate like forge a balance or things like that, given the stage rolled up? No, I don't think that those are concerns to do double spends and things, but I do think because your state is, the state source of truth is really sitting on layer one. So you're not gonna be able to, one of the reasons they do some of the delays and things I believe is to stop double spend from happening. But the, and that's why they freeze the state route on layer ones, but I don't think that, if you understand, I won't go back over the ideas of, but if you have tokens that are here in the values more there than on the bridge contract, then you won't be able to get your money back off of that. So that makes sense. Hello, when you're talking about state on layer one, have you had any thoughts in regards to upcoming state expiry? Not yet, but I would love to hear your thoughts on it at some point. I'm kind of practical on the side of things as far as what that should look like and what you believe in. Yeah, please go ahead. Sorry. Yeah, I don't have any particular thoughts just that I think current plans are to expire state after a year or so and then you'd need some other way to get the state. My understanding is there will be, I mean, zero knowledge proofs that we'll be able to construct that and prove that that's true. But then you'll also have, so you're kind of using the same different technology, but I'm not gonna speak too out of turn when I don't know what it's all about. It's a great question though. I'll definitely, I can look into it and get in touch with you about it.