Tangible Zero Knowledge Data from a Non PHD by Brian Wilkes

Hello. Good afternoon. Everybody hacking here. Hands up for hackers. Yeah.

So, I am too. I'll be excited to see all your guys' projects. Please feel free to come say hello. Um, today I'll be talking about tangible zero knowledge data from a non-PhD. I am the non-PhD Brian Wilt.

You may know me by outsider analytics. So what's on the docket for today? We're going to look at how zero knowledge is used on Ethereum, how to find zero knowledge proofs on chain and specific ZK project characteristics and what they mean. So this talk comes from a grant I received from the Ethereum Foundation privacy scaling and explorations team that I did this talk in Devcon as well. So I you stole some of the graphics as you'll find.

So, we're not going to go over Waldo. Sorry, Waldo. I did make that graphic myself, but we will go over some quick brief overviews. So, what are zero knowledge proofs? You have Alice, you have Bob as is standard, and Alice wants a drink.

Bob says, "How old are you?" So, Alice provides the birthday into the zero knowledge circuit, which then produces a proof over to Bob who's the verifier. And then assuming that is correct, alcohol will flow to Alice who can change the state of her sobriety. So um the important thing to know and how this translates over to actual onchain Ethereum is there's a prover, there's a ZK circuit, there's a proof and there's a verifier and no alcohol. So if we're going to let's look at one of the first applications here, which is scalability.

So obviously Ethereum does about 13 transactions per second and we need to scale that up significantly to be able to do transaction settlement for the world. So let's assume that we have a layer 2 blockchain. This layer 2 blockchain is producing blocks independently. And what you do is you can take that blockchain's state and you can put it into as an input the zero knowledge circuit that will pop out as a proof and then that proof will be given to the verifier smart contract on the Ethereum main chain. So then the layer 2 state source of truth will be updated assuming that that proof is true.

Moving to privacy. So obviously as a data scientist um we can find a lot of stuff on chain and um if you know the addresses so we need to have privacy before we can really move to mainstream. So the way you would utilize zero knowledge proofs to be able to provide privacy on chain is you would have a secret. You would put that into the zero knowledge circuit and then that proof that came from there would then be put on chain in the verifier smart contract which then would release funds in circumstance like tornado cache. So now that we know generally what they are here, let's actually talk about where they are on chain and how you find them.

And I did build this as well. So uh now the search for verifiers we are going to search for verifiers on chain. How are we going to do that? So the important characteristics of a zero knowledge proof are in the circuit. Why is that?

Here's a good example of zk sync v1 for one week in September of 2022. It produced in that week 270 blocks or 2,170 blocks, 2,600 or 265,000 transactions which were batched into 214 inputs. Those inputs went to the zero knowledge circuit which produced 214 proofs and those proofs were then verified onchain with the verifier smart contract. So each circuit has a unique verifier onchain. So if we're going to use public blockchain data, how do we find those verifiers that represent the circuits on chain?

So we'll go through some tools. So the first tool we used was BigQuery. Um I tried Dune, it wasn't quite fast enough. So um BigQuery is a system that you can go on and it has public blockchain tables from Ethereum um layer 1. And on there I used contracts, traces, and transactions.

those tables which you can query on big query using an account. So um if you the first thing I did is I searched through the bite code for contracts and in that bite code you can search for constants directly because those are put in as a hash. So that hex for the for the contracts or finite fields is this big ass number right here. Um it is very unique and it's only used for finite fields of doing modular math for cryptography. So after searching through that I found 584 contracts with that finite field contract finite field constant.

So I checked every one of those on ether scan and most were not verifiers. So moving on we went to what's called the transaction decoder. So this is a tool I think are there any data scientists in the crowd? Anybody? Yes, that's what I'm talking about.

I'll talk to you specifically. So the transaction decoder is a really useful tool from Etherscan if you want to know what a transaction is actually doing. So here it's the transaction decoder and then it shows at the bottom what the execution trace is. So the execution trace for this zkync um block proving is first it takes the proof it goes into the prove block section which then goes into the verify aggregated block proof function and it produces true at the end which means that the zk um sync v1's state can be updated on layer 1. So utilizing that data, you can use method ids to try and find things that have happened on chain.

What's a method ID? So the method ID is the first four bytes of input data that's put in for a function or a trace. A function or a trace for transactions or traces. So let's take an example. This here is the fry statement for starkware.

It verifies a fry. So if you take this function take out all the names of the variables in whites space and take the first four bytes of the kac 256 hash of that then the method ID is this in red which is the same as the first four bytes which is in the input data. So you can search through a bunch of data using whatever those function ids are and the method ids are also on a public database called four byte directory. It's an open- source uh project and it's great if you want to know what's actually happening. You can put in the bite signature and it'll pop out what the text signature for that function is if it has it.

So what did I find? I found 96 confirmed verifiers on mainchain that were that had verified 763 times. So um I think you can see it kind of the verifications do a little bit of a downturn once tornado cashache got sanctioned pretty hard. that these are the 16 active contracts from those 96 on Ethereum main chain. I know they're too small, but I will show you a QR code later you can look at and I will go over this, I promise.

So, let's look at their con their characteristics. So, the first thing we'll look at is what proving systems they'll use. So, these are the proving systems that are snarks. You have groth 16 which is being used by tornado cache and its forks. You have Hermes.

You have looping and then you have plunk. Plunk is used by ZK sync, ZK space and then you have Ultra Plonc which is used by Aztec. Um you have Halo 2 which is used by Scroll and then you have the Starks and Starks are being used by as you can imagine Starkware. So all the Starkware projects. Starks apparently are going to be in trouble when quantum computing comes out but we don't know when that will happen.

So the UFOs might get us first. Um trusted setups, let's look at what trusted setups are first. So it's where on the elliptic curve the um verification and proving is happening. So we won't get too deep into that, but basically you use an MPC um multi-party computation um ceremony to be able to prove or provide a secret on chain. So how many of you did the KCG ceremony um commits?

Yeah, we did some. So we'll we're going to do one soon. It's a big ceremony to allow proto dank sharding um within Ethereum. We're actually going to make a big ass explosion and measure it and then put that on chain as a secret. So hopefully that'll go well.

But that is an example of a trusted setup that's being done with multi-party computation. I like to think about this as a nerd, which is as Thanos in the Infinity Stones. So if Thanos gets all the trusted setup pieces of secrets, then they can wipe out the universe of your trusted setup and they can go and um attack your proof. So you do not you want at least one of those stones not to get into his hand so that you can continue to have a secure protocol. So what trusted setups are these different projects using?

Um groth 16 uses a two-step trusted setup. The first step is the perpetual powers of Tao which is on Ethereum. And then the second step has to be unique for each unique circuit that's being verified. This was improved by Plonc and Ultralon and all the other PLS that are out there. Um and that is essentially it's a it's a single universal setup.

So they did one ceremony and everyone can use that ceremony for any plon circuit they write into the future. And then Halo 2 and Starkware in the Starks they can use um no trusted setup at all as long as they're set up in certain ways. So what the projects are hopefully you guys can see that but um we have Loop Ring Polygon Hermes and tornado cache we're using groth 16. Um these were the perpetual towers of tow plus a step two. In that step two loop ring had 16 participants.

Polygon Hermes had six and Trinoach had a 1,114. So if you got all six Polygon Hermes participants secrets, you could break Polygon Hermes, which I think they're moving to ZKVM, so it's no big deal anyway. Um, moving on, if you wanted to do Plonk, all of them that are in production have used Aztec's Plunk universal setup. So, um, all of them use the same setup. You can go on GitHub and check it out.

It's pretty cool. And there are 176 participants for that ceremony. And then you have your Starks which is StarkX um in your Starkware projects. Those did not have a trusted setup because they're Starks. Recursion.

So another thing that people are trying to do when they build these different protocols is um build in recursion. Recursion is basically the idea of taking a bunch of individual proofs and recursively proving them up in one. So why do you want to do that? You need to be able to do parallelization of proofs so that you can decentralize proof generation. Um it also allows you to chain proofs.

So you have from the beginning the input for one proof can be the output from the pro previous proof and then also it can reduce the proof and verification size. So groth 16 cannot do recursion and everything else can as long as they make the implementations full. So scroll my or halo 2 is a little difficult at the moment but um why does anyone use gro 16 if it is so difficult in these ways? It's cheaper and it's faster. So, a lot of implementations will use Groth 16 on Ethereum but use a bunch of other protocols beforehand in order to actually get to that final um proof.

So, data availability, we'll talk about this next. Once again, as a data scientist, I love this kind of space, but um we can talk about what the zero knowledge layer 2s are doing. So, your first type of layer 2, if you're not too much of a purist, is the zk validiums. So they have their state route is on layer 1 in a bridge contract and their state reconstruction data is not on chain except through a data availability permissioned committee. So um the difference is ZK rollups have their state route on Ethereum layer 1 but their state reconstruction data is also put on layer 1.

Um why would you use ZK validiums versus roll-ups? many more transactions per second can maybe be done. So who's a valid? That's your stark projects like IMX, Serify, so rare. You have ZK porter which I don't know if it's actually coming out but it's been talked about many times.

Um, you have roll-ups which are dydx loop ring, zk sync v1, zk space, starknet, zk sync v2, scroll, all the polygons, and then all the zkvms that are coming out from everyone. So, let's talk about force exits from rollups, what it actually means to be able to get off of roll-ups. So, this is a circumstance for how you would look at a layer two. You're the user here and you're happy. You put a transaction through to a very nice validator or sequencer and they put your transaction into the layer 2.

The layer 2 puts it through a ZK circuit, produces a proof and puts that into the Ethereum layer 1 bridge contract. Um, but let's say your validator sequencer becomes evil, then you can submit your transaction directly to the Ethereum bridge contract. And if the sequencers don't include your transaction within a certain period of time, then the bridge freezes and you can produce a proof yourself using a ZK circuit to get your funds back off that bridge. Now, this is a great system except it does cause for some issues. So if you want this to work, you in in order to inherit the full security, a rollup has to have available data on layer 1, functional accessible force exits, time delays for the layer 1 contracts because if they can change the contract, then they can kind of freeze your funds.

And then third or fourth would be the layer 1 locked funds have to be equal to the market value on layer 2. So there's there's nuance to this but generally if you if the if the validators and sequencers become evil then thing if the what the value you can bring back by force exiting has to be all on layer 1 Ethereum. So if it's on layer 2 and you have native assets that are significantly more valuable that are being brought down to layer 1 then those assets are not fully protected by the rollup structure. So um well that's pretty much what I have for you today. I'm hoping you guys will be willing to get into the data a little bit.

So, BigQuery is a great source. Um the this is the project GitHub that I did with the Ethereum Foundation PSC team. L2B is of course just a wonderful um resource that I'm sure everyone has used at this point. Um and then we are actually doing a hackathon that's going to do be a lot of data availability and help people understand what data is happening on chain for a lot cheaper and faster. And if you need that or you're doing your hackathon through it, then please reach out to me.

We'd love to talk. Thank you. So, I'll give some thank yous out to the Daily Guay Discord and um all the people there are so helpful. It's amazing. Um we have the um ZK podcast is a great resource.

I'd highly recommend it. Um L2B once again you have the Ethereum Foundation privacy scaling and exploration team specifically Justin Martin who's been extremely helpful to me. Um and then thank you Mark for all your help on this. Absolutely. Um, so that's what I got.

Thank you very much for your time. Really appreciate it. [Applause] [Music]