Web3 Galaxy Brain 🌌🧠

Nicholas: Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week I sit down with some of the brightest people building Web3 to talk about what they're working on right now. This is a very special episode. Today I'm joined by Brandon H. Gomes, CTO at Manta Network and Poseidon Labs. Brandon is one of the smartest people I've had the good fortune to meet this year. He's deep in the ZK technical stack and able to clearly communicate the core mechanisms of ZK to lay people. In this episode, we discuss what zero knowledge proofs enable, the difference between ZK as a technology and its specific application for roll-ups, and various cool things you can do with ZK. Brandon shares his candid opinions of the ZK protocol landscape and what the best path is for Solidity devs interested in building ZK applications today. We discuss a ZK-powered poker game he's building at ETH SF, and we explore the Solidity-compatible ZK future that he and his colleagues are working on at Poseidon Labs. This is one of my favorite episodes of the show yet. It was a pleasure getting to learn from Brandon. I hope you enjoy the show.

Brandon H Gomes: How are you doing? Good.

Nicholas: How are you? It's been a little while. Last time we spoke was in Bogota.

Brandon H Gomes: Yeah, yeah. That's true. It's been busy here at ETH SF also. Just a lot of conferences.

Nicholas: Oh, nice. Are you doing anything special at ETH SF or just hanging out?

Brandon H Gomes: I'm working on a mental poker, actually. So basically it's a primitive for doing fair shuffling on-chain. So basically what we all do is we all participate in, let's say, shuffling a deck of cards if we want to play poker. And we do it in a way that nobody can learn what the shuffle was, and nobody knows what cards you hold in your hand.

Nicholas: How much of it is on-chain? Is my mental model correct that when you use ZK, not for even for a roll-up, but you're keeping some of the data off-chain and then you're able to verify it against data that is on-chain? Or are you, all the state is really stored on-chain, let's say in the example you're talking about?

Brandon H Gomes: So basically what we have is we have secrets that are stored off-chain and then statements about those secrets that are stored on-chain. And then if we make those statements, then we can do interesting things. So let's say we want to play a game of poker together, the two of us. So what you do is you sample some random secret key, just like your Ethereum secret, like your seed phrase. But you just do one just for this game. And then what we do is we encrypt a deck of cards together. And what I'll do is I'll first encrypt it. So now I'll encrypt it and then I'll shuffle it. So now when it's shuffled, like all I'm doing is just like moving the cards around. I'm just doing a shuffle. So I know what the shuffle was because I did it. But the cards are encrypted, so you don't know what the shuffle was. Does that make sense? Yeah. So you don't know what the shuffle was because I encrypted the cards. So now like it's just a bunch of nonsense. You can't see the structure of the cards that they are. But then you do a shuffle, right? So if you do a shuffle and then you encrypt again, then I don't know what shuffle you added to it.

Nicholas: OK. Yep. Got it. Makes sense.

Brandon H Gomes: We each contribute a little bit of our own secret to it. We do it off chain and we prove that we did it correctly. Neither of us know what the other one shuffled. Once we do that, then we can start drawing cards from this deck and neither of us know what the next card is going to be because we both shuffled it.

Nicholas: And when you say draw a card, what kind of computation has to be, do all of those shufflings have to be undone sequentially in reverse order in order to figure out what the actual card is that a person has drawn?

Brandon H Gomes: Exactly. Exactly. So if I want to draw a card from my hand, right, and I want to be able to see it, you have to unwrap your layer that you added to it.

Nicholas: And you can selectively unwrap just the relevant data for that card.

Brandon H Gomes: Exactly. Exactly. So we're doing the dealing for a game of poker. So we've done the shuffle, the two of us. And then the first card that ended up at the outcome of that shuffle, it'll go to you. And then the next card will go to me. And then the next card will go to you. The next card to me. And then I ask you to take off your layer of encryption. And now I have a card only I can decrypt. And I know what the card is now. But none of us knew what the card was before doing this shuffling process.

Nicholas: Wow. And this really works.

Brandon H Gomes: Oh, yeah. And yeah, it's legit. This is all inspired by a paper. I forget the name of the paper, but it's basically this like fair shuffling algorithm by Aaron Groth. And Groth is like a big name in ZK. He invented the Groth 16 scheme. And this is like the most popular ZK scheme that everybody uses right now. It's very, very efficient proof sizes, which are great for Ethereum because you got to pay for like posting that data on chain. So everybody uses Groth 16. And the same guy also invented the mental poker scheme.

Nicholas: How do you spell his name?

Brandon H Gomes: Groth. G-R-O-T-H.

Nicholas: G-R-O-T-H. Okay, I'll try and find it. Put the link. Efficient zero knowledge argument for correctness of a shuffle? No. That's something else.

Brandon H Gomes: Yeah, that's it. That's it. That's it. That's it.

Nicholas: Bayer something?

Brandon H Gomes: Yeah, Bayer Groth. Those are two authors.

Nicholas: Got it. That's incredible. Why is this not the Metaverse casino already? What's what's...

Brandon H Gomes: Right, right, right. Yeah. So this is the thing we want to solve for the hackathon because if you look at this paper, it's actually very, very complicated and it's very expensive to run on Ethereum. The scheme that they wrote is efficient if you want to do it off chain, like the full entire game off chain. But you want to do interesting stuff like you want to put the tokens you already own in the pot if you're playing poker and you want to do all sorts of interesting DeFi on top of these poker games. And so you need to have that data on chain somehow or you need to have like the result of the game on chain. And so their scheme is not very efficient to run. So we have to sort of tweak it a little bit and make some compromises somewhere to like get their scheme to work on chain. So it's going to be slightly slower than because they like really, really optimize it to run off chain. But for us to do to get this interesting leverage between existing Ethereum assets, for example, in this game, we need to do some modifications to it. So that's the thing we're working on this week at ESF to try to get a nice full end to end Texas Hold'em prototype on chain.

Nicholas: So on Ethereum, really fully on Ethereum, no cross chain dependency, nothing?

Brandon H Gomes: No, no, no. So like for the hackathon, I think it's on optimism, but like the same exact contract you can deploy. Yeah. So it'll just be like a single contract and then basically SDK that you run in JavaScript that does like the proving that you did the shuffle and this kind of thing. And does that require that the clients retain their secrets like you would really need to just during just during the game, then you throw it out and you make a new one for the next game.

Nicholas: Okay, because essentially, when the game is finalized, people take their ether die or whatever and walk away and the game.

Brandon H Gomes: Yeah, exactly. Exactly. So the contracts like you go into the contract, you lock up your tokens in the contract to set your betting. And then after the game is over, the contract knows who the winner is, because it's like it's doing all the verification and then distributes the pot, however it is at the end of the game. And then you go home with your money or with no money.

Nicholas: As the case may be. Yeah. You know, you're just the person I need to talk to today because I'm talking to PeopleDao. I don't know if you saw the tweets, but they found another constitution.

Brandon H Gomes: Oh, they did?

Nicholas: Oh, man. So they're going to be auctioning off another constitution. And I was talking. so ConstitutionDao created the people token, the auction failed, the people token is now a claim on the ETH and the treasury. Everyone can get a one to one refund minus the gas. And they threw away the keys. So that's over. So there's this PeopleDao and a couple other DAOs, but People I think is the main one, who are kind of like a cultural community of people who love the people token and the mission, even though they have no control over the DAO or I mean, there is no DAO, they just created a cultural institution. Right, right. Sort of parallel. So and they're talking, they were a little reticent at first, but now they're pretty excited about maybe doing something for the constitution again. I don't know if it's going to be a good idea, but you know, might as well give it a shot. See what happens.

Brandon H Gomes: We have to try. So

Nicholas: one of the things that people are talking about is it would be nice if you could do the raise without maybe, I'm not sure that totally obscuring the amount raised is the right approach, because I think actually that number ticking up as part of the momentum building around the effort. But at the same time, it would be nice if you weren't entirely disclosing what the total treasury is, because obviously that's how they lost the last time. So is this like a trivial problem from your perspective? Because it sounds like you do it pretty well. Although I guess one advantage of the poker example is that you can throw out all the data when the game is over. So it only needs to endure that that long.

Brandon H Gomes: Yeah, yeah. So I think it depends on the approach, but yeah, it's slightly non-trivial. because basically you one thing you want to do is you do this like addition, like let's say you're adding up this total that you're running total of the like the Dow's like balance. Then you want to like open it up and actually make it spendable. Like in the naive way, you need to like give your money to this like this controlling thing, which if you wanted to do a key sharing for it, it'd be very complicated key sharing. Like in the case of a Dow, you can do like this multi-sig stuff, right? You can just say like you have some committee inside the Dow that's like controlling the funds after like who's responsible for actually buying the actual physical constitution and being part of the auction. But you do that in ZK, you have to do like multi-sig in ZK and that's kind of expensive. And there's people who like their entire startup is dedicated to making that kind of thing really fast. I wouldn't say it's like a very easy problem. OK, definitely.

Nicholas: I'm trying to. maybe, you know, Matt Wyatt was chiming in with they're working on, I don't know the name of his team, but they're working on something like this multi-sig. But OK, so essentially, like in order to keep secrets in ZK, is it fair to say that you need something that looks like a private key to someone who's familiar with EVM? Like you need someone to hold some private information who ultimately has control. And then the solution to making that multi-party would be to have a system like a multi-sig where there are many people with separate secrets who collectively control something with some kind of threshold of controlling some smart contract wallet or something. But eventually, you still need some kind of off-chain. People who are familiar with EVM can't just put their resources together directly on EVM without some additional information of the nature of a private key, something like that.

Brandon H Gomes: Let's just try to go step by step about how the money flows in. So let's say first you have, let's say a contract that's storing all these funds. Right. If the funds come from regular ETH addresses, you can just watch the input, like just watch the storage of the contract. That will just go up. And that number is not hidden at all. And if you look at, let's say, all the shielded pool technology that we use in like when we're building like private payment systems, like you know always the total balance stored in the pool. Right. Because those tokens have to be stored somewhere. Right. You have to keep a reserve for the people to withdraw from the pool later. Right. Let's say like I want to do like a tornado cash system. Right. So I have one ETH and I want to put it in the tornado cash mixer and then get back out like half an ETH. So for me to put in one ETH, I basically put in my claim and I literally deposit my tokens into the contract. So now the contract owns that one ETH. Now, of course, the contract is written in such a way that it can't just go willy nilly spending it. So instead what I do is I come back and I say, look, I have a claim that I put one ETH here yesterday and I can get half that ETH back or whatever it is. Then the contract gives me control over that half ETH and that gets deposited to some regular ETH account. But the whole time the money was stored in that tornado cash contract. So there's no hiding at all about the total volume of money moving in and out of the pool. So for you to hide this kind of thing, I would need a pre-existing set of tokens that are already hidden. You see what I mean? Like you can't come in fresh. If you come in fresh, everybody can see the fresh tokens coming in. So you need like a pool of money that's already bigger than the DAO, what the DAO is expecting to spend. It already needs to be bigger than that. If it's small, you're already just going to be increasing it and everyone will see how much you increase it by. So you have this sort of chicken and egg problem.

Nicholas: So there are chains that are specialized in this, Aztec, Zcash, Monero.

Brandon H Gomes: Aztec, Zcash, exactly. So you have to say like if you wanted to buy the constitution for however much, let's say what was the last time that they sold it for?

Nicholas: Too much. Forty seven million, something like that. Forty five.

Brandon H Gomes: Right. So let's say they bump it to like 80 million this time because everybody's like going really crazy. So it's like 80 million. I want those illegal constitutions. Right. So now you need to have 80 million worth in, let's say, Zcash. Well, Zcash is not a good example because Zcash doesn't have other tokens in it. But let's say Aztec, right? You have to have 80 million in Aztec already. At least if you have less than everyone will see.

Nicholas: That's probably not the case right now. Yeah.

Brandon H Gomes: I'm not sure. I'm not I don't know the number exactly, but like that's a lot of money that you need to have already in there. And that has to be owned by the members that want to contribute. Right. So you sort of have this like, OK, you want the DAO to be private. That means everybody before the DAO existed had to be private. We don't have that yet on Ethereum. OK.

Nicholas: OK. So this is going to be very difficult to do in a short amount of time.

Brandon H Gomes: So, OK. So one thing that's cool is that so right now I'm at Jesse's Hacker House. Jesse is a she's on Twitter. I can send you the link later. But Jesse, basically, she organizes these hacker houses. And I think one before this one or two before this one, somebody entered into a hackathon and they were able to do a Vickrey auction on chain without adding ZK. So this is a really, really strange thing that happened. Basically. So a Vickrey auction for people who don't know is a second price sealed bid auction. So people put in their bids and they're all hidden. And at the end of the auction, the auctioneer opens up the first two bids. Sorry. No, they open the second bid and they see the price of that and they charge that much to the first price person. Right. That's a fair auction scheme and it's more fair than first price auction. for a example. It finds a better economic value for the for the object you're selling. But anyway, the point is that it's a private auction. So nobody can see the bids or who's bidding. And what they were able to do is they were able to leverage some edge case in the EVM called the Create 2 opcode that lets you basically pretend that you're sending money to somebody when you're actually not sending it. What they were able to do is like you were able to bid into this auction when people just thought it was regular transactions, but they were actually bids. And then at the end, when the auction ended, the bids were all opened at the same time and then you could see the winner. So this kind of like counterfactual address thing. Maybe I can point you to the resource, but it was called the Create 2.

Nicholas: Create 2 is used to know to predetermine the address that a contract will be deployed at.

Brandon H Gomes: Exactly. Exactly. That's what you were using to bid in the auction.

Nicholas: Oh, because you send ETH to some address that has no activity on it and then you instantiate a contract at that address.

Brandon H Gomes: Exactly. Exactly. So you somehow get this like this like weird scheme.

Nicholas: This came up in the Royalty discussion too. I was considering options for like block lists essentially. And one of the I think the most salient refutation was, well, you can just do this counterfactual address thing and so you'll never know until it's too late.

Brandon H Gomes: Right. Right. Right.

Nicholas: That's pretty cool.

Brandon H Gomes: So maybe you might have to do a scheme like that to sort of bootstrap this problem because otherwise if you wanted to do it like sort of with standard techniques, you need to have this problem of this chicken egg problem where you have to already have all this money privatized.

Nicholas: So essentially you would just to play out the full example, you would have people send their donations to addresses that have zero activity and then those addresses would be predetermined to be the address which contracts that would give the authority to, let's say, the DAO or whoever the custodians are who are going to off ramp to fiat to pay. They would have control based on the source code that would predetermined deploy to that address or that set of addresses. And so they would essentially have to pay the gas to claim all the tokens that were sent to those things and then maybe even swap them to eat if you sent things that were not eaten.

Brandon H Gomes: Yeah. Yeah.

Nicholas: Yeah. It would be kind of it would be kind of complicated anyway or it would be very gas expensive in any case.

Brandon H Gomes: It would be very gas expensive, but that would be one thing you could explore.

Nicholas: That would be very cool. I think for the circumstance, one version of this is like a mix where you do like a public raise so people can see the number going up and everybody gets excited and regular people can just do regular normal transactions. But then whales can maybe give a million dollars through some more complex technique.

Brandon H Gomes: Right. Right. And in that case, right, if you have sort of this like backing by whales, then the whales can just use like tornado cash style stuff also. Right. That's another option.

Nicholas: True. True. True. Although maybe some chilling effect around tornado lately, but yeah. Or something.

Brandon H Gomes: Sure. Sure. Maybe not. Maybe Aztec. Let's not say tornado. But yeah. Yeah. Yeah. Yeah. Exactly. Exactly. So I mean, yeah. It's it's a fun problem, I think it's it's slightly non-trivial. So it's not not as easy as you may have thought. Maybe the impression I gave when I spoke to you last is that it's actually easy, but it's not easy.

Nicholas: Yes. I remember quite a bit of alcohol that night and I don't really have a discussion about this. Although you did say something that the thing that made me walk away saying this is the most brilliant person I've met in this country was your take on the UX of optimistic roll ups versus ZK rolls, which I thought was very, very interesting. Right. I don't know if you want to re-explain that briefly.

Brandon H Gomes: Yeah. Yeah. So so for ZK roll ups, right, what you're doing is you're taking this fact that ZK lets you do off-chain computation and just taking it to extreme. Right. You're saying, OK, I'm doing off-chain computation. What's the computation I care most about? Well, it's the blockchain itself. Right. So I'll just run the EVM. I'll run the virtual machine of the blockchain. I'll run it off-chain and then prove that I ran it and then just post a proof and the like outcome of the result. Right. You don't care what the intermediate result was. You just care what the what the outcome was and just make sure that it's totally, you know, cryptographically sound and then that's all you need. So ZK EVMs are sort of like simple in that sense that they're just a very clean API. But what they do is they have this latency problem where it takes a long time to build this proof and it takes a long time to like collect enough transactions where building the proof is worth it economically for you. Like if transactions are dripping in really slowly, it's not worth building this huge proof and spending all this hardware and all this money to run this machine. It's only going to do a few transactions. So you kind of have this latency problem and that introduces something that I would call like, well, you just call it like the objective finality. Right. So finality, right, is this is this concept of people know the state of the blockchain a little bit into the future, but it hasn't been finalized in any real sense. This hasn't been actually secured by the blockchain itself. So we can't trust that number, like the value that we get out. So if I send you something, it's unfinalized. Maybe it gets rolled back. Maybe it doesn't get included. Like I want it to be included and that's fine. This is what we expect from these systems a little bit.

Nicholas: I met a kind of crackpot at a Chainlink event once who was telling me that Bitcoin is the first serious quantum computer. for this very reason, because you don't know the final state of the blockchain.

Brandon H Gomes: I mean, that's a little crackpot because it's not it's not quantum. But yeah, I mean, it's funny. Yeah. Right, right. There are many more useful quantum. I mean, Google has a more useful quantum computer, I'm sure. Right. So basically this finality question and finality is a lot related to UX. Right. So if you're on your dApp and you're trying to send money or you're doing a swap or whatever it is, and the thing tells you your transaction pending is a little spinny circle, that feels bad. And that makes it feel very like, oh, yeah, Web 3 just kind of sucks compared to Web 2. Web 2 is so fast. Why is Web 3 so slow? And so one thing you get is like, OK, optimistic world. They say, OK, look at this. We'll give you instant subjective finality. So we'll make that like that little spinny circle on the UI. that'll go instantly. It'll go like it'll just make it become a checkmark right away. And then what we'll say is we'll just. I mean, that's the word optimistic. It says like we'll just pretend it's true. And the reason we're able to pretend it's true is because there's so much money backing that fact up that it's true that if it weren't true, they would be in serious trouble of like risking all that money. They would get slashed. Right.

Nicholas: So the idea of like a terror argument in a weird way, it's like we've got the whole economy hostage. Actually, maybe I don't understand optimistic world well enough. What happens if there is be a kind of attack on an optimistic roll up at that point? that would cause it, you know, that would cause a fraud proof to be executed or whatever, roll back the roll up? What would happen if like seven days of history get rolled back or something? Wouldn't that screw up the whole chain?

Brandon H Gomes: Yeah, I mean, well, yeah, we'll get to that. But basically, basically, the idea is this, right? Like there are economic players. They're incentivized not to behave badly if they have enough money at stake. So basically what this is, you could just think of this economic security. Right. And at the end of the day, at the very bottom layer, everything is really just economic security. Right. I can buy a big enough machine. I can break any system. So it's just about money really at the very bottom layer. So what we're doing is saying, look, OK, there's already all this stuff securing the system. We'll just take advantage of this fact that they don't want their money slashed. Right. So we'll just say like you have to act honestly or we'll take your money. And it's like holding them hostage. to being truthful. Whereas in the ZK rollup scenario, there's nothing to be held hostage. Right. When you post the proof, you just check it if it's true or false. There's no there's no argument about it.

Nicholas: So you don't have to optimism in ZK systems. They don't have this period where it's unclear.

Brandon H Gomes: Exactly. Right. Exactly. And this comes into the UX. Right. So if it's not optimistic, I have to wait for that bubble to keep spinning for it to be actually true. Right. So there's nothing else holding up the truth of it except the proof. Whereas in optimistic rollup, there's money backing that fact that it's true.

Nicholas: Sorry, you said in ZK you don't have to wait for the spinny because you do or you don't.

Brandon H Gomes: You do. You do have to wait because you have to wait for them to build the proof and then to post the proof on chain.

Nicholas: And that takes I mean, that's it's interesting. So ZK gives you the kind of affordance that like even just EVM mempool transactions give you where if you just send an invalid transaction, it's just not going to be included in a block. or, you know, or if it's valid but reverts, then it just reverts. Like there is this kind of immediate knowledge of simulation depending on what you're doing, of course. But if you try and move tokens that aren't yours, like it's just not going to work.

Brandon H Gomes: It's not the user submitting something bad. Right. That's not the issue. The issue is trusting the rollup to submit something.

Nicholas: OK.

Brandon H Gomes: OK. Yeah. Yeah. Sorry, sir. It's the sequencer that we don't trust. All right. The sequencer is the one that has the that can post the data on like. the sequencer is the one doing the work off chain. The one that's supposed to speed up is doing the scaling. Right. It has to be. It's cheating. Right. It's not actually running it on L1. And so we don't inherently we can't inherently trust what the sequencer does.

Nicholas: So the sequencer is acting. I mean, maybe it's not useful to draw a direct parallel to EVM stuff. Exactly. But what? who are the different players in ZK rollup? There's a sequencer who is collecting transactions and then bundling them into a proof and then posting that on. Yeah. Is that. Yeah. That's it. How long does that take approximately or like today?

Brandon H Gomes: So so it depends. But like the standard you can think of is like one hour, one hour. Yeah. One hour is a is a pretty fine.

Nicholas: If you had like a billion transactions a second, you could be posting it more frequently because it would be worth the gas for the sequencer.

Brandon H Gomes: No, it's because you can't even build that proof fast enough.

Nicholas: Like, like, like it takes time.

Brandon H Gomes: Yeah. Compute wise computer. It takes time. So like currently it's about an hour. I mean, of course, hardware gets better and better. And this this number goes down. But in the like short term, let's say the next few years, you're going to have to wait a pretty significant amount of time. Well, from the point of for the point of view of you're like like literally just your user experience. Right. And that's why this sort of user experience question comes up is that you have this pretty stark difference between immediately getting the transaction through versus waiting for the proof to be generated and submitted.

Nicholas: Right. I think the way you said it to me in Bogota was something like from the perspective of the user, an optimistic rollup has instant finality versus ZK, which takes an hour. So optimistic, although actually for seven days you don't have finality, it feels like it's much more instant than ZK.

Brandon H Gomes: Right. Right. And that's the distinction between subjective finality and objective finality. Right. So optimistic rollups have the instant subjective finality, but seven day objective finality versus ZK rollups, which have one hour of both subjective and objective finality. The really the inherent tradeoff between ZK rollups and optimistic rollups is trust. So in the ZK rollup, I don't trust anybody involved. And so they're both waiting for an hour, like subjective or objective. I don't care. We have to wait because we don't trust these people. But in optimistic, you sort of like you try to use the economic structure already inherent in the safety of the whole system to try and leverage that to like, you know, to build like a trust mechanism to let us get away with this like instant finality, even though it's not really, really final.

Nicholas: I don't want to spend too much time on optimistic because whatever, it's the past. But which financial value am I lording over people's heads in order to make them comply? It's the value that is already on that rollup or it's some other value.

Brandon H Gomes: No, no, no. It's value. on L1 they stake. They have to stake that on L1.

Nicholas: Ah, OK. So that's like, yeah, like validators of optimism or.

Brandon H Gomes: Yeah, yeah, exactly. So they they're subjective. They're subject to being slashed on L1.

Nicholas: OK, so it's like it's more like a staking proof of stake kind of.

Brandon H Gomes: It's like a staking. OK, it's like a staking.

Nicholas: Yeah. OK, so the risk is for the people who are allowed to submit proofs to the chain that if they were to cheat that they would be slashed on L1. Is that? Yeah, that's a good summary. Yeah. And then in the ZK case, so we said an hour, that's an hour to do the computation. But it's like in current practice, the sequencers are like collecting transactions and then every so often bundling them into a proof.

Brandon H Gomes: Yeah, they sort of have to make a tradeoff again between the cost of individual like it's like a demand supply issue, right? Like if there's not enough transactions, you wait a little bit more to try and collect enough where it's like. the marginal cost is enough for you to be worth posting the proof now versus 10 minutes from now or whatever it is. But around an average of like an hour.

Nicholas: OK, so like collecting them and assessing which transactions are valid and that they want to include in their like L2 EVM.

Brandon H Gomes: Like in their L2 block, in the block.

Nicholas: Yeah. OK, that's and it's a geez, I'm trying to think of how. So it's like they're running an EVM locally. Exactly. And they're collecting transactions, choosing based on whatever algorithm, which ones they want to include in their blocks, which they can run at light speed because they have no constraints. Like it's essentially proof of authority or it's like it's a local chain. It's not. Right. Is that a fair?

Brandon H Gomes: So what it does is they don't have to do this replicated state machine issue. So on L1, right, everybody has to run these transactions through their machine. It's replicated everywhere. Right. And this slows down the network. Right. So instead, the sequencer is the only one who has to run this this thing. Right. The sequencer just runs it locally. They build whatever insane hardware they want to run like this extremely fast EVM and then just post the proof once they once they assemble the proof that they submitted everything correctly.

Nicholas: OK. And there are many sequencers simultaneously doing this or not?

Brandon H Gomes: No, no, no. Right now, every L2 is centralized. Basically, they're all one run one sequencer they own.

Nicholas: You know, people give Polygon a lot of shit, I think, for being a sidechain, not an L2 when the reality is. OK, so there's like a sequencer. So there's like one sequencer for each L2 currently.

Brandon H Gomes: But in the future, basically in the future. Yeah. In the future, there's some story that they have for decentralizing. There's still a bit of time to go for that because the hardware is so the hardware is still very, very expensive and very specialized hardware. And so you have this like ASIC versus CPU problem for like in blockchains in general. Right. But it's just about like resource management. So these are ZK-ASICs? Yeah, they're basically ZK-ASICs. Yeah.

Nicholas: Wow. That's cool. What company does that?

Brandon H Gomes: I don't know the names of the companies. They're like they're sort of coming out recently. They're not necessarily established names yet, but yeah, we'll see them soon. We'll see them soon. Like lots of interesting hardware companies to accelerate the rollups and make them decentralized.

Nicholas: That's all proprietary kind of hardware. It's not open source hardware.

Brandon H Gomes: Yeah, for now it's proprietary.

Nicholas: Interesting. OK, so I'm a sequencer. And so what's? examples of people who are doing sequencing now are like the names of all the chains that we mentioned earlier? Are the people responsible? Yes.

Brandon H Gomes: Yes. Yeah. They're all basically centralized.

Nicholas: OK, so they're collecting transactions. And then when there's enough transactions to be worth the L1 gas to post the proof to Ethereum, they do an hour long computation while queuing other transactions that are coming in, but will be dependent on the state change in the current batch that they're building the proof for. Like you have to do it in one hour blocks sequentially.

Brandon H Gomes: Yes. There's lots of schemes that you have for just like making sure that this streaming process works well and you don't like step on your own feet while you're doing it. But yeah, like the whole thing just runs sort of smoothly. It doesn't like have these like gaps of like no activity. Like it's pretty smooth. Like the engineering is totally like. well understood for that. That part of the process. Yeah.

Nicholas: OK, because I guess you know that you're going to get to a proof so you can. Yeah.

Brandon H Gomes: Like, you know, and you know how long it takes to do the proof and you can plan all that stuff in the pipeline. Yeah.

Nicholas: OK, interesting. So everything we've been talking about now is ZK rollups. But really rollups are just like one application of ZK, right? This is just like yes. And Ethereum is solving a problem for Ethereum using ZK. But that's not really. what's the like core like insight about ZK? Is there is there a single one or is it so revolutionary that it can't be stated so simply?

Brandon H Gomes: I think there is one. And it's basically just the ability for me to prove things about my data without revealing them. Now, what those things that you prove about your data can be sort of go crazy, like be very creative, like go with your heart's content. What kind of things you wanted to prove. But it's really just that I have some secret data and you want to know some property about it. And I want to tell you what it is without revealing all my data. And that's all it is. For example, let's say I have a biometric scanner or something. I want to prove to you that I am a member of some collection of people like I'm in some database, but I don't want to give you my fingerprint. But I do have a mapping between the fingerprint and the database entry. Like there's some encoding in my fingerprint. So what I'll do is you'll tell me like we'll agree on what this encoding is. Then I'll go back to my machine. I'll take my fingerprint and run it through that encoding and give you back the code. And the code will say, oh, look, I'm in the database. So now you'll let me into whatever access to something. ZK lets me do that. Like it lets me like keep my fingerprint secret.

Nicholas: Okay. But if you have a scanner like a world coin, if you know that the scanner is the same every single time, then you can prove that this person is already been included in the database or whatever you can.

Brandon H Gomes: Exactly. And that's exactly what WorldCoin is. So WorldCoin is literally a ZK machine on that orb that takes your iris and turns it into an into a code. And it proves that it ran that code correctly and then post the proof and the code on chain.

Nicholas: Incredible. If only it wasn't yet another startup. Okay. I mean, it just it's not going to change the equation on anything. It doesn't seem to have any solution to that. Maybe you have different opinions. But OK, hold on. We got to rewind. Who are you? What? Oh, yeah. What is your background? A little bit. You have a very intimidating Twitter bio unintentionally, I'm sure.

Brandon H Gomes: Really?

Nicholas: That's like, yeah, so it just says math or something like that. Yeah. What's your background? A little bit. And then we can get it. Yeah. I actually do that.

Brandon H Gomes: Yeah. So so basically, I I just graduated last January from Rutgers, from New Jersey. I studied. Thank you. I studied math and physics. Physics has been my like my passion for many, many years. I had a very, very influential teacher in high school, sort of fostered that in me. And I always wanted to do like string theory or something insane like that. And then I went to college.

Nicholas: Your name?

Brandon H Gomes: Yeah. Yeah. Jeremy Mormon from Summit High School. So, yeah, shout out to him. So basically, yeah, I went to Rutgers to study physics. I did some research there related to the project that we were doing. It was a collaboration with CERN. I don't know if you've heard of CERN. It's a research lab in Geneva doing a little bit. Yeah. High energy physics, basically, like just building these huge machines to smash really small things together and make little explosions to try to study the universe. And we were doing some some research there. And then I moved into the more into the math area. And sort of my my thing in math was always like understanding how the fundamentally math itself works. So not like any particular area like, you know, you have calculus, you have algebra, you have things like engineers, the kind of math engineers use or even the math that goes into ZK and cryptography. I wasn't really interested in any specific one of those, but more like what does it mean when I say I do math? Right. That's what's interesting to me. I really got into this concept of type theory and as a way of like thinking about the world and thinking about how to build like abstractions, how to build mathematical objects, how to think about things mathematically. And that was what was really fascinating to me. So I studied this field basically called formal verification and automated theorem proving. And that was sort of the research I was doing. The work I was doing there was with Professor Kontorovich. He has a pretty intimidating Twitter if you want to look at that. He has a lot of Twitter activity. He does complex analysis and he does a lot of focus on education. He also appeared on Veritasium, if you know the YouTube channel Veritasium. He appeared there a few times and he runs the Quantum magazine. Yeah. So I did some research with him in formal verification for some of the stuff he was working on. And basically what this idea is that like you should be able to teach computers how to do math and how to do math, not like calculation math, but like proving things about the world kind of math. And this is sort of this like frontier of of of like computation. that's like maybe maybe next like 50 years or something. We'll get something really insane that comes out. But that's more like a very long term.

Nicholas: Proving things about the world. What kind of thing?

Brandon H Gomes: Like proving mathematical facts. Like I want to prove. I want to prove that like calculus exists or I want to just do like mathematical proofs, like proof properties on mathematical objects, like do research math and the things that professors are doing. Got it. Like that kind of thing or or things in like quantum gravity or whatever. Just pretty mathematical statements. Right now, machines can only calculate what we tell them to calculate. Instead, we need to imbue them with some creativity and give them the ability to turn that creativity into like useful knowledge and then take that useful knowledge and sort of use that to build new tech, build new understandings of the world and science and all that kind of stuff.

Nicholas: So it's like when you say creativity, you don't mean like neural net kind of stuff. You mean a whole different branch of math?

Brandon H Gomes: No, I mean like so. to me, math is actually a creative endeavor rather than like an analytical one, because when I'm already at the step where I'm like doing a computation, I've already done the creative part before to get there. The computation, you just run it through the machine. You just you just crank the wheel. All right. It's knowing what wheel you want to crank. That's the thing that's the creative part. And so the machines don't know how to do that yet. But once they know how to do that, then we get some sort of like superpower here because machines can scale so much better than human brain. And so that's the kind of for example, that's the kind of A.I. that I care about is like A.I. that can do math research rather than A.I. that can do image recognition or or like video generation and things like that. Awesome. So that's the kind of stuff I was studying in school. And then I sort of found I was looking deciding whether I wanted to go to grad school or wanted to get a job. I decided I wanted to get a job. And then I found Manta, which which is the startup I'm currently working for right now. And Manta was doing all this crazy stuff in ZK. And so I sort of took my skills and type theory and applied those to the ZK world and sort of learned ZK while I was while I was at the job. And and yeah, so now I'm now I'm working at Manta as the CTO. And Manta is also transitioning a little bit right now into Poseidon Labs. And Poseidon Labs is sort of this bigger company that has a grander vision and also wants to explore other chains other than Polkadot, which is where Manta started and also exploring Ethereum solutions. And then this is where I sort of got into roll ups, because the place where the tech that we built for Manta makes the most sense is as a roll up. It was like a L1 contract.

Nicholas: Got it. Is it worth exploring a little more what Manta's tech is or what Poseidon is worth?

Brandon H Gomes: Yeah, yeah, yeah, yeah, definitely. So Manta's original focus is basically just building a privacy layer for Web3 and building all the infrastructure you need to deploy privacy as a service and put privacy into your application. And so we built originally. we're building right now, actually, on on Polkadot, on Kusama and Polkadot. The idea there is that in that world, you have these like interconnected chains. It's like each chain sort of does one thing really well and the chains connect together to each other. And so what we what we're offering is like, OK, we're the privacy part of this network. And so then you can do whatever is cool that you do. Like, for example, if you want to run an EVM or you have this like really crazy idea for an order book or you want to build on-chain games or you want to do like social, then you just add the word privacy in front of that. And that just means Manta integrates with you. So like private social, anonymous social, that's just Manta plus your social chain.

Nicholas: Is Manta like a pallet? Is that what it's called?

Brandon H Gomes: So it's a. it's a parachain. Yeah.

Nicholas: Oh, OK. It's a parachain. So it's not like something you import into your chain. It's its own chain.

Brandon H Gomes: No, no, no. It is own chain and it provides you this privacy service. And then you just connect with your your existing application, the privacy layer to it. And it adds privacy. So, like, for example, if you have like a social like you want to do some like Web3 social on a parachain and then you want, let's say, private messaging or private tipping, then you use like Manta's system for that and you just integrate that with cross-chain messaging.

Nicholas: How does this relate to what we talked about earlier with like you kind of need the liquidity, sufficient liquidity already in the mixer? Is Manta, you pass some... Right.

Brandon H Gomes: So basically, Manta is the mixer for the whole Polkadot Kusama ecosystem. That's the idea.

Nicholas: Got it. OK.

Brandon H Gomes: So everybody would put their mixings through us. But it's more than mixing, right? So the sort of this one of these issues with like Tornado Cash is that sort of like only a mixer. What we're doing is we're saying, like, look, privacy is just a fundamental thing that you want. And so once you put money into this privacy system, it just acts like a regular account. Like, I don't want it to be this weird thing where you have to pay this insane gas fee to like hide your tokens. It's like that's very clearly like a sketchy behavior, right? Like the price of privacy can't be too high because then it's like, well, what do you mean? Why do you need privacy if it's so expensive? Right. Like, what are you hiding? Right. If privacy is like as cheap as non-privacy, this is a no-brainer. So basically, our goal is to make it like this no-brainer thing and then integrate it into this existing, like, vibrant ecosystem of lots of different things going on and try to like build that privacy for them.

Nicholas: So that's the idea of a tech stack. Is it a ZK based thing?

Brandon H Gomes: Yeah, it's all ZK. It's all ZK based. Is there anything you can say about how it actually works?

Nicholas: that would mean anything to someone like me? Can we explore what that tech stack is like a little bit or whatever?

Brandon H Gomes: interesting Sure, sure. Or relevant going forward? Yeah. So I think one thing we can point out to is sort of the contrast with something like ZK-AVM, right? Because I think this is an interesting point, for example, because ZK-AVMs don't have privacy, right? And this is sort of a weird like, it's just like people have a misconception. Yeah. People just have a misconception about what ZK-AVMs are about and what. whenever you attach the word ZK, people think privacy. No, no, no. That's not what it means off right off the bat. You have to like actually design your system to be private. Like ZK-AVM is not private at all.

Nicholas: Which of the things that we know are ZK-AVMs like is StarkNet or Aztec?

Brandon H Gomes: Yeah, yeah, yeah. StarkNet, Aztec, Scroll, Polygon. ZK-Sync. I guess ZK-Sync, all of them. Right. So they're not private by default. They have to add extra stuff to make them private. And it's something that like Aztec is trying to do. And in that world, what you then call this thing is a ZK-ZK roll up, which is a horrible name.

Nicholas: Basically in that one, the second ZK is or the first one, whatever, is privacy. Privacy. OK. Right.

Brandon H Gomes: So what we're saying is like, look, just let's do the ZK for privacy, right? Because this is the thing that we care about here. Like maybe Ethereum cares about scaling and somebody will solve the scaling problem. We care about the privacy problem. So instead, the ZK for us is privacy. And what that means concretely is it's a different person in the system that's doing the ZK. OK. So for ZK EVMs, it's the sequencer doing the proofs. Right. In privacy world, it's the users doing the proofs. Right. Not the sequencer. The sequencer just reads the proof. The sequencer just accepts like a regular sequencer, like a regular, like a node. Right. So your blockchain is like a normal blockchain. It's the users that are doing the proofs. It's a completely different space. Yeah. That's what Mantis is doing. So basically.

Nicholas: That requires that you have, just from a UX perspective, the thing that comes to mind first is like when registering ENS, you do this like commit reveal scheme so that you can't be sniped, which requires that you have like the secret in local storage on your browser. So if you were to be browsing in a private tab and close it, or if you were to reset your browser cache history, whatever, you would lose the ability to claim that ENS even though you already did the first of two transactions in ENS. Is it a similar kind of problem where to do something like what Mantis is doing, the ZK on the client, that the client, you need some state stored on the client, right?

Brandon H Gomes: Yeah, that's true. That's true. Exactly. That state is sort of a local copy of the state that's stored on chain. But it's the copy that sort of is only spendable by you. So like if we think of the network being sort of this big summation, this big grouping of everybody's ability to spend money, then you only take out the part that you care about. And that's the copy that you keep on your local machine. But of course, all this stuff is built in with the same backup systems as regular blockchains. So you have a seed phrase, you can always recover from that. It's not like you actually lose anything. It's still the same kind of UI, sorry, UX, as like regular seed phrase.

Nicholas: So you don't need more, like you can just have a seed phrase and that's enough to recover everything that was privatee?

Brandon H Gomes: Oh, yeah. Yeah, absolutely. Yeah, absolutely. It's the same. It's the same principle as the public version. Yeah. That's the thing. It's like we need to make the UX almost exactly the same or else you're going to have this disparity and it's going to make the adoption harder. It's going to make it easier for regulators to be like, no, this is different than regular transactions. We really, really like focus on making the UX almost identical if we can.

Nicholas: But that seems like a much more interesting place to have the to experience and sustain the EVM network effect lock in. It seems better to do it at the level of the wallet or the at least the UX around private keys rather than like this sort of commitment to ZK EVM where you don't get any of the benefits of privacy. You just get the scaling benefit.

Brandon H Gomes: Yeah, exactly. I think one. So one thing you have to worry about, right, is that we were talking earlier before about, oh man, it takes so long to build these proofs. Right. What does that translate for the UX for the user? Right. Because if the sequencer is doing this really big proofs, it's taking a long time. What does that mean for user? Right. So the thing that we've really spent a lot of effort on at Manta is to optimize the user side proof a lot and optimize it on many fronts. So the first thing is the protocol itself. Right. So as ZK EVM, you can think of it as ZK EVM itself, like that machinery that you have to run, maybe like a million or 10 million times more complicated than a private transfer. Right. Which is what we're doing. It's like a private transaction. And so like the proving time is really, really small compared to something like ZK EVM. So that's the first thing. you don't have to worry. It won't take an hour to do a transaction. Right.

Nicholas: So it's the first thing you can do in JavaScript on a browser.

Brandon H Gomes: Yes. Well, that's the second part. The thing is, most of the open source code that this stuff, you know, that you write this stuff in is like CPU based, right? It's not browser based. So we spent a lot of time trying to accelerate WebAssembly so that you can plug in like a WebAssembly accelerator into your thing and then compile everything to WebAssembly and put it in the browser. Right. So we want native browser support and even more stuff like native MetaMask support with stuff like MetaMask snaps that are coming out soon, I think. I don't know if they're completely out yet.

Nicholas: They're in beta. But would you be able to treat Manta like because Polkadot, you treat it like it's just another RPC you import, right? Or do you need a separate wallet? I forget. Yeah.

Brandon H Gomes: So you need a separate wallet to do this, like to do the privacy part, right? Because the privacy tokens are not stored in the same way as regular tokens are stored. So you need a privacy version of the wallet. But the idea is just make this privacy wallet as much as possible integrated into your existing wallet experience. So something like Talisman, for example, on the Polkadot side, you could do like a Talisman plugin for your Wasm so that if you're on like a Manta Dapp or if you're on any Dapp that supports Manta, that like it knows that you're using it so that it'll give you access to that Wasm bundle that has like the Manta Prover inside of it.

Nicholas: What does the Manta Prover do?

Brandon H Gomes: It takes your privacy and can decode it? It builds the transaction. No, that's the one that builds the transaction, not the decoder, the one that does the actual proof generation, the thing that takes the longest time. Yeah, got it.

Nicholas: OK, so that's something that would you imagine live in the UX of a wallet experience on top of Snaps or whatever, on top of something that's right on top of Snaps in Ethereum or Talisman in Polkadot.

Brandon H Gomes: Yeah.

Nicholas: OK, got it. That's very interesting. And then what's Poseidon?

Brandon H Gomes: Poseidon Labs is this new sort of this new branding for the total space of all research projects that we're working on right now. Manta is one of them, obviously, and that's the thing we're committed to most in terms of the product side. But we have a new research project that we're working on sort of on the side, which is the Poseidon VM. And this is the part that sort of plays into the Ethereum ecosystem, into this roll up story. So Poseidon VM is a new kind of roll up design. It's different than Optimistic and it's different than ZK Rollup. It's sort of this hybrid of the two. And there's some interesting design space we want to like. we want to tackle and explore how we can accelerate transactions and make them private at the same time.

Nicholas: So do I understand correctly that basically what you're doing is ZK on the client so that the transactions are private, but then Poseidon is maybe the other half of like taking that and then putting that on chain with a roll up that not ZK AVM, the ZK part and then let somebody else solve the scaling problem. And then maybe Poseidon comes in with some other solution for like giving you the benefits of an optimistic roll up in terms of perceived finality.

Brandon H Gomes: Yeah. So the the Manta private payment stuff is a separate thing, right? That's just a product we're building for Polkadot, for example. The Poseidon VM is a new way of scaling ZK transactions. So if privacy private payment is one thing, but you have other things like private voting, private social, private gaming, ZK gaming. So all those all those applications themselves, we want to scale those guys more. So right now, if you look at, for example, the only thing that right now is scaling Ethereum transactions, right? You take any any system like Optimistic or ZK roll up and what they'll do is they'll uniformly scale all transactions. And so what we want to do is specific scaling, not uniform scaling. So for regular transactions, they'll go through like an optimistic system. We'll just let them go through, let's say, like optimism or arbitrum style system. And then the ZK transactions will especially then go through an extra special scaling layer that's specifically designed for scaling ZK transactions. And those will get scaled more than if you ran them through uniform scaling. So the ability here is to distinguish between ZK transactions and non ZK transactions. And the fact that they're ZK lets you optimize this speed up further than you could have done uniformly, basically.

Nicholas: Got it. So in this world, you're not assuming that everybody is going to be doing ZK client side, ZK private transactions for every single transaction. Some will be public still.

Brandon H Gomes: Some will be some will be public. And that's a really important point because that distinguishes us from something like Mina, where in the Mina world, everything is ZK transaction. And it's sort of uniform again, but on the other side of the spectrum. Right. So EVM is uniformly public and Mina is a uniformly private. We think that the real best trade off space is somewhere in the middle and not in the extremes.

Nicholas: So why preserve some public transactions? What's the advantage?

Brandon H Gomes: So the advantage here is like is basically shared shared public state. So think like AMMs, right? AMMs, we all contribute to this liquidity pool and we all share the fact that liquidity is there. And then basically, the more that people contribute, the better like pricing I get for the AMM. So we still have this like public state that we are sharing together. Like the blockchain is about sharing that public computer. And so there's still things we need to do together in public. But there are some things.

Nicholas: ZK Uniswap would be able to allow me to swap without revealing who which LPs quiddity I'm swapping through, correct? Like on Mina or something?

Brandon H Gomes: Yeah, yeah, yeah. So not to say you couldn't build a ZK Uniswap. What I'm saying is like it's just as a metaphor for this like sharing global state thing. Even if you had a ZK Uniswap, you still have to share global state, which is who owns the backing funds of this contract. That still has to be managed in public because the contract itself is a public resource, not a private one.

Nicholas: Right. I guess I guess I'm. the nuance I'm not understanding is if ZK allows you to know something to be true and prove it without revealing it, then what applications would be limited by? or is it just that sometimes it's nice to show things publicly and those those transactions can be even further optimized if you do a kind of variable compression, ZK compression. Or is there some some application that actually you would want to? because you can also presumably publicize whatever the private key equivalent is in ZK, the secret.

Brandon H Gomes: Yeah, yeah. So you can technically do anything. Right. So in EVM, you can technically do anything. It's Turing complete. And the same thing, you can technically do anything in Mina as well. It's just more about the what is the right programming model? What's the right mental model for people building these applications? Right. And so it becomes like if you box yourself into a certain design space, some things are easier to do and some things are more efficient to do and some things are harder. And so in the EVM.

Nicholas: Providence of an NFT, for instance, might be an example where you really want it to be public from the start and forever.

Brandon H Gomes: Exactly. And I want the choice to do that. Right. It's like in Mina, I have to go around that. I have to go around the fact that it's all ZK and sort of cheat my way into getting that effect in the end. Whereas in EVM, it's a very simple expression that I can do. It's a very simple way that I can express that concept of Providence. Right. So it's also about the developer experience and about in the different ways that you build these systems, what is easy to express and what is hard to express. And that also comes down to concrete efficiency as well. If you have a prominent system, it's very easy to do in EVM. To do it in Mina, you have to still run all these ZK stuff. You can't turn off the ZK stuff. You're still paying for that ZK.

Nicholas: So in this Poseidon VM, is that what you call it? Poseidon VM?

Brandon H Gomes: Yeah, Poseidon VM.

Nicholas: Your work is building the actual VM and how it functions. And from the perspective of a developer, they're going to be writing some high level language that probably, I guess, doesn't exist yet.

Brandon H Gomes: No, no, no. So it does exist. It's called Solidity. Oh, really? Yeah, yeah, yeah. The idea here is we want to make... Here's the thing, right? Rollups have so much design space to explore and we just want to make a reasonable compromise and a reasonable hybrid model that's still very accessible for people. The worst part is that ZK has such a high barrier to entry. We don't have ZK. ZK is not taught in Ethereum tutorials. There's very few educational materials and when they are there, they have a huge mathematical barrier for people. And also the API of ZK, like what do we even mean when I have something that's private? Like what does privacy mean? We still have a long way to go in terms of educating people on that. And so the goal of Poseidon VM is also to solve this education problem where in majority of cases, let's say 90% of the time, you never have to touch any ZK code yourself. You only write Solidity code.

Nicholas: So you think Solidity network effect is more or less locked in?

Brandon H Gomes: Yeah, it is. But it's not just Solidity. It's any Ethereum tooling, right? It doesn't have to be Solidity. It can be any language you like to use in Ethereum right now. You'll still be able to run ZK with those languages. The idea is basically we have an SDK that comes with the VM and that SDK is especially designed to build these like layered abstractions. so you can treat ZK just like any other concept in your existing language. It doesn't require you to go to a special ZK specific language or to start learning a new tool set. The idea is just try and stay as much as possible in the existing tool set.

Nicholas: You believe it'll be possible to abstract the logic gate construction of ZK proofs into what feels like a regular Solidity library or Viper or whatever people are used to?

Brandon H Gomes: Yeah. So basically the idea is in majority of cases, people won't have to write their own logical systems at all. They'll just write the APIs that they want. So here's an example. At the very bottom layer, we have a thing called the ZK friendly storage. So what that means is in regular storage, you can think of regular storage as just the key value database. So I store in my in my contract, I store some key value pairs, like for example, ERC20 is a key value pair store. Or you can store your NFTs as well like that.

Nicholas: Yeah, all my favorite applications are key value pairs.

Brandon H Gomes: Yeah, exactly. They're basically, I mean, Ethereum is basically a key value store.

Nicholas: I mean, is Facebook also in a way? I guess not because you can index them. But OK.

Brandon H Gomes: Yeah. But anyway, so the idea is, OK, what's the ZK equivalent of that? Right. And what's the API for that, for whatever that equivalent should be? Right. So the idea is in a ZK version of a key value store, you instead of passing in the key and getting the value out, you pass in a proof and an encrypted value. So you pass in a proof that you read a key that actually exists in the map. OK. And the value that you post is the value that is inside that key value store, but it's encrypted. And you just use ZK to prove that you encrypted it correctly. So we are doing a read. We're reading from the map, but nobody knows what we read. So that's the...

Nicholas: You say that you're also passing in the value or you're receiving the value being returned to you?

Brandon H Gomes: It's the same thing in...

Nicholas: You're describing storing information or you're describing reading it.

Brandon H Gomes: I'm describing reading it. So by read, we mean we need to give access to that value to other parts of the contract. That's what a read means. Right. So when I read from the key value store, I want to get a value out and then pass it on to the next part of the computation to do something with it. Right. Like if I'm transferring money, I read from the balances and then I take the value that's there, subtract it out. You know that much amount of transfer and I want to add it back.

Nicholas: Check if there's enough associated with that.

Brandon H Gomes: Right. All that kind of stuff. So it's about passing a value from one part of the contract to the next part of the contract. Right. And so for a ZK map, instead, you're reading it but encrypted. So the API, the only difference in the API is that the value you get out is just encrypted. That's the only difference in the API. And so then what we have to do is give you an API for encrypted values. And so that's all part of this SDK, basically. And you still treat all the sort of control flow of solidity like this data goes from here to there and it gets passed into that function. And then we do like an if statement, all that kind of stuff. That's still all regular solidity. You don't have to change any of that for the ZK stuff.

Nicholas: So it'll just feel like a like a library or a struct or something.

Brandon H Gomes: It's just like it's just a library with special structs and you just learn the struct APIs and that's it. And 90 percent of the time, that's all you really care about in ZK. The last like 10 percent of the time you're doing something like really, really custom where you want to do one of these like reads, but you want to do it a very special way, very optimized way. And this kind of thing is is sort of akin to like gas golfing.

Nicholas: Or dropping into Yule for right.

Brandon H Gomes: Yeah, exactly. Exactly. So like majority of time you don't have to do that. if you're really hardcore, you do that and it's totally fine. But it's about getting access to ZK application development for people. This is a huge barrier to entry right now. And so having a tool like this SDK and this VM that's optimized for the SDK is, I think, super valuable for that.

Nicholas: Yeah, definitely. So what do you think about Cairo? or what? or what do you think about these other other other languages like Cairo? Yeah, yeah. So I guess something.

Brandon H Gomes: Yeah, yeah. So Aztec is Noir and Cairo and there's another one called Circom. I think Circom is the best, has the best ecosystem and the best tooling right now. And Circom is sort of the most integrated into into EVM. So one thing that Circom gets for you, for example, is when you write your custom ZK circuit in Circom, you can literally ask it to compile you a solidity verifier. For that, it just prints it out for you. So like you have your like in your like little startup, you have your crypto guy. He writes a circuit, prints out the solidity thing, hands the solidity guy and plugs it in. So very clean separation there. And basically the thing that we want to do is integrate Circom with our like our VM development experience. So again, the 90 percent of the time you never have to touch it. Then for the last 10 percent of the time you get like a Circom very nice integration with the system.

Nicholas: Very cool. I love how concerned you are with the developer UX because that feels like the elephant in the room for all the ZK stuff. Just it's so difficult to approach.

Brandon H Gomes: It's so difficult. Yeah. And it's and that's really the shame because it's such a powerful like cryptographic primitive. And the thing that we're building like Poseidon Labs, Manta Network as well. Like this is we're an infrastructure company, right? We're trying to build the tooling so that developers can come in and build their products. And so if you have this whole domain that you don't that you know about, but you can't access and there's so much creativity out there in terms of people building products, like. we just want to give them access to that. And then they come build on us. Right. I think it's a very. it's a very like symbiotic relationship you can have there. Just the people who are the most expert in ZK, they know that this can be used to build really insane and cool applications to just make it easy for people to develop on it and then provide them a platform to develop on. And that's it. Right. So they'll come and they'll build anything.

Nicholas: So there are some people who will be listening to this who are Solidity developers. Today, what is the best path to building something that is ZK enabled? And then how long do we have to wait until Poseidon has an answer that is on Ethereum? Yeah.

Brandon H Gomes: When SDK.

Nicholas: When ZK, yeah. When SDK, yeah.

Brandon H Gomes: Yeah, exactly. So basically right now, if you want to build something today, if you're a Solidity dev, your best bet is to start learning Circom. Yeah, it's sort of like JavaScript. And Circom has the best tooling and the best Ethereum native tooling. So you could go to like any sorts of things like maybe like Noir or Cairo. They don't have nearly as much integration with EVM tools. Like, for example, there's a Circom hard hat plugin. Right. There's like Circom Visual Studio code. Like it's all like regular standard Ethereum dev experience. It's all there. So I would recommend Circom, definitely. And there's lots of. there's lots of people getting into the like education space. There's not very many right now. I would recommend someone on Twitter named Porter. I'll get you his handle after. He's doing a YouTube series right now on ZK. It's like a mini lecture series. It's streamed on YouTube. Really great content. Basically stepping you through the prerequisites for building ZK stuff and then taking you through examples and sort of the next steps and getting also like big picture.

Nicholas: If I go and play with Circom, what will that let me deploy to? or what's the... I can compile to what?

Brandon H Gomes: To Solidity right now.

Nicholas: OK. So the prover is Solidity and then I store the proof.

Brandon H Gomes: No, no, no. Sorry. Other way. Other way. So the prover is a Wasm. They give you a Wasm prover and a Solidity verifier. So Solidity is the one that goes on chain. The verifier goes on chain with the Solidity code. And then the prover is Wasm, which you can just run through your JavaScript app on the browser.

Nicholas: Can you give me like a small example of something that you know that's been built with Circom. that's like a relatable example for a Solidity dev?

Brandon H Gomes: Let's think. Well, the mental poker stuff we're doing now is with Circom. But it's too hard of an example. But...

Nicholas: No, no, that's great. So can you describe a little bit about how... What is the sort of tech stack for that? So you're using Circom to write. What is the Circom code that you're writing do? and maybe what else are you using in that stack?

Brandon H Gomes: Yeah. So the stack is basically... The Circom code is there for building this like fair shuffling proof. So again, the way the shuffling works is that each one of us shuffles the cards and encrypts them. Independently. But we have to prove to each other that we did that shuffle correctly. And we didn't, for example, switch in more aces or something or erase some cards or whatever. So we have to prove that we did the fair shuffle. And that proof, like the thing that you're proving, is the shuffling algorithm. And that shuffling algorithm, we write it at Circom.

Nicholas: How is it possible at a high level, how is it possible to prove to somebody else that you did a computation? I guess that this is what ZK is.

Brandon H Gomes: That is ZK. Yeah, that's the API of ZK.

Nicholas: But isn't this like a PNP problem? Like, isn't this an issue?

Brandon H Gomes: No, no, no, it's not. It's not an issue. So basically what you do, whenever you have something like this that seems too good to be true, you just basically throw a lot of cryptographic assumptions. So you just say like, OK, it's very hard. So one very example, one very simple example of a cryptographic assumption is that you have a function that's very easy to run forward. But if you had the result of the function, you have no idea what the input was.

Nicholas: OK, hashing. OK.

Brandon H Gomes: Right. Like hashing, right? So you just throw this kind of assumption, you say, OK, hash functions exist. If they exist, then you get ZK. And there's a very clear path that if hash functions exist, then you get ZK. Now the question is, do hash functions exist? It's a different story. So basically it comes down to that. There's no real magic involved except this very specific assumption that functions exist like this.

Nicholas: OK. What's the mathematical phrase for that?

Brandon H Gomes: Like one way function.

Nicholas: One way function. OK.

Brandon H Gomes: We don't know if they exist, but we assume they do. But we have good approximations to them in practice. So it is like Terra model.

Nicholas: We are just going to put enough value in it.

Brandon H Gomes: Well, no, no. Don't say that. The thing is, in practice, we have good approximations to one way functions, even if they're not truly one way functions.

Nicholas: Right, right.

Brandon H Gomes: And from an engineering perspective, it's good enough. Exactly. They'll last us long enough. Maybe in a thousand years, they'll be broken. But by then, who knows if Ethereum will even be around or Bitcoin will be around. There'll be some new thing in a thousand years.

Nicholas: Got it. OK. So in Circom, you're writing logic that is run on the fair shuffling, run on the clients. It's shuffling the cards and it's able to prove to the other clients that it creates a proof that others can verify or even the solidity on chain can verify that everybody did their job correctly and nobody cheated.

Brandon H Gomes: Exactly. So you write in the Circom code, specifically the Circom code. You only write the shuffle part. So you take in as input like a deck of cards. You run the shuffling algorithm, which is just basically. it's like a matrix multiplication. And then you run an encryption step at the end and then you output the encrypted cards afterwards. That's the whole Circom thing. Maybe like maximum 300 lines or so of Circom.

Nicholas: Very cool. And 300 lines of it's I mean, I imagine it's very, very dense. But actually, the first question that comes to mind is there's nobody who can audit or what's an audit cost for Circom of fortune, right?

Brandon H Gomes: Well, yeah. I mean, for something as small as this, you can you can pretty you can be pretty sure that it's correct. Not too hard. But yeah, audits of like full protocols like Mantas private payment protocol or ZKVM. They can go pretty up there upwards of millions of dollars. Yeah.

Nicholas: How many people in the world can write Circom or something equivalent?

Brandon H Gomes: Writing Circom is very easy, actually. I think writing Circom is not very hard. Auditing Circom is very few people I think can do that correctly.

Nicholas: Like like under 200, under 100.

Brandon H Gomes: Yeah, I would say. Awesome. Writing simple things like mental poker and Circom is actually not very hard. And that's one thing that is a real blessing, because to do this stuff, sort of what you had to do a few years ago is you have to do this stuff by hand, like do the actual cryptography also yourself. Whereas here in Circom, you're literally just writing a matrix multiplication and an encryption.

Nicholas: When you say do the cryptography yourself, you don't mean like the writing logic circuits. You mean something else?

Brandon H Gomes: Yeah, I mean literally translating like the translating the Circom into the actual ZK machinery itself, like the thing that generates the proofs.

Nicholas: Like a human compiler or something like a.

Brandon H Gomes: Yeah, yeah, yeah. Like back in the day, you had to do this sort of stuff by hand. Now we have tools like Circom which do this for us, which is great. Right. So now all we have to do is write down what operation we want to hide and then the thing will do the rest for you.

Nicholas: Incredible. OK, so you are writing the Circom. It's going to take you a couple of days, something.

Brandon H Gomes: Yeah, a couple of days. And then so far, full stack is basically for mental poker. is you have the Circom code, then you have a Snark JS. Snark JS is a prover that integrates with Circom. So Circom is just a programming language. But the thing that it outputs is like this binary format for your circuit. And then Snark JS can take that binary format and actually produce a proof for you, like the actual proof.

Nicholas: Sort of like the runtime.

Brandon H Gomes: It's like the runtime. Exactly. It's the prover runtime and that's written in JavaScript. So the Snark JS, it's built with Circom, like the people who designed Circom designed also Snark JS. So they sort of natively integrate.

Nicholas: Integrate in JS?

Brandon H Gomes: Yeah, because it's for the browser. You really want this browser. You really want people to connect with the browser because that's where they're doing most of their ZK stuff. Like that's. one thing that's funny about ZK is that most ZK research is actually done in the blockchain context. Almost no like high level, high level ZK researchers are not involved in cryptography in some way, in cryptocurrencies in some way, which is kind of different than other research areas. So there's definitely a bias towards making sure that whatever you're doing works on a blockchain somehow.

Nicholas: I'm just reading that Snark JS is an NPM package that contains code to generate and validate ZK proofs from the artifacts produced by Circom. So yeah, very interesting. Okay. And then you were saying that it's pretty quick. It's able to do that because it's pretty fast.

Brandon H Gomes: Yeah. So I mean, yeah, they optimize it really well. Yeah.

Nicholas: Like it wouldn't take a second to shuffle in your mental poker.

Brandon H Gomes: No, no. Yeah. I think it's a couple of seconds. Yeah. Okay. At most. At most.

Nicholas: What makes the poker mental? What's the mental element?

Brandon H Gomes: Oh, it's like, I think the word mental comes from like the fact that you're shuffling like in your head. Okay. Instead of shuffling in front of people. I don't know.

Nicholas: It's part of mental magic for like trademarks. But in that, I think you choose what you draw, I think.

Brandon H Gomes: Right. I think mental poker here means like poker that I'm doing in my head. Something like that.

Nicholas: Okay. And is that and what else? So, okay. Circom, Snark JS. So you write the code in Circom, then you use Snark JS to do, essentially you'll make a website where you'll deploy Snark JS. Yep. Plus your bytecode that will execute the shuffling on each client.

Brandon H Gomes: Yep. Yep. And that's the front end. So then the front end is the Snark JS part, which is just proving that you did the shuffle. Then there's the whole like Texas Hold'em game logic, right? You still have to do that. So like the, the bidding rules, small blind, big blind stuff. Um, all the like Texas Hold'em rules, you still have to write your like website for it, right? So you write the website in JavaScript, for example, that's what we're doing. Write in JavaScript, integrate with Snark JS to do the proofs and then submit those proofs to, um, submit those proofs to, to, um, to the network using Metamask. Um, and then Metamask, you know, builds a transaction for you once it gets the data from the dApp. And then you sign it with your Ethereum address and then it goes to, um, it goes to the smart contract that has the verifier for Circom, the one that we exported directly from Circom. Uh, plus the actual Texas Hold'em rules also have to be written on chain as well.

Nicholas: Yeah. That's what I was going to ask you. You're doing the, the reason for doing them on the client at all is just to like visualize the experience or?

Brandon H Gomes: Yeah, yeah, yeah, yeah, exactly. You, you show like a card table and you see it, you're like, you know, what your cards are and like where the, what the bets are currently. Yeah.

Nicholas: Wow. Uh, okay. And then, but the game is actually played on chain and on EVM.

Brandon H Gomes: Um. Yes, yes. On it. Yeah, exactly. So then there's a contract that does the verification that, that comes from Circom directly. And then you write the Texas Hold'em game rules in solidity and just call the verifier whenever appropriate.

Nicholas: And for just, I guess to dive into the details, the verifier is particularly useful at the shuffling stage. Is there any other point where you're using that Circom tech?

Brandon H Gomes: Yeah. So there's two, there's two parts actually. Yeah. So there's two parts. There's the shuffling part and then the drawing a card part. So when I draw a card for me, like I can see it and nobody else can see it. Everybody else has to unwrap their extra layer of encryption. So then there's a fair decryption circuit as well. So there's a fair shuffling and a fair decryption and that's two verifiers actually.

Nicholas: Yeah. Got it. Okay. So, um, if I'm observing from, uh, just watching EtherScan, uh, I can see the players and their, I can see the state of the game, uh, once they've, uh, or actually I can't see the state of the game. What, what am I able to observe? Yeah.

Brandon H Gomes: So, so you're able to see like how many cards you can, you can see the, like that players have cards and you can see what the current, like, um, um, like how many, which cards are face up right now. And you can see the bets as well. The bets are public.

Nicholas: Okay. Okay. Interesting.

Brandon H Gomes: Yeah. Just like a regular poker game. Like if you're sitting in, if you're watching poker game from above, for example, just think like that.

Nicholas: Wow. Crazy. Uh, so, and you're actually going to do this this weekend.

Brandon H Gomes: We're already doing, yeah. It's due Sunday morning. So we're cranking it out right now. Try to get it done. Yeah.

Nicholas: Okay. Well, for anyone listening after the fact, I'll, I'll put it in the show notes and, and definitely send it to me. I'll, I'll, I'll tweet it out for any.

Brandon H Gomes: Yeah. Yeah. So this is, this is all for a eth SF. Yeah.

Nicholas: Eth SF hackathon. Very, very cool. Um, uh, some questions from the audience. Uh, these are zero knowledge questions. I'm not going to tell you who asked them. Sure. Um, risk zero. Is that interesting?

Brandon H Gomes: Yeah. Risk zero is super interesting. So risk zero, what they do is they try to approach the language problem of ZK. Like this whole, you had to do it by hand. kind of problem where before you had to build the ZK prover yourself. And instead what they do is unlike Sercom where Sercom, you have to write your own language, like, sorry, you have to write code in Sercom, right? So Sercom is a language they invented. You write it in Sercom, whatever, right? In risk zero case, what they say is, okay, look, we'll take any code right now that you've already written and we'll use this big machine called LLVM. LLVM is this like a big compiler piece of the compiler infrastructure that everybody shares. So think like Rust, C++, C, Go, everybody, everybody uses LLVM basically. And risk five is this, not risk zero, but risk five is an architecture for like a CPU. So this is something like, it's an open source hardware. It's a, it's like this new alternative to ARM, right? And it has a very, very simple instruction set. And what they do is basically say, okay, any program you already wrote, you don't have to change what you like, the language you wrote it in, just compile it to risk five. Okay. Then we'll run a ZK virtual machine that can prove that you ran a risk five program.

Nicholas: Whoa. That's ZK risk five.

Brandon H Gomes: ZK risk five. Exactly. So you take your existing program, like you wrote some Rust code and even if the Rust code imports, like let's say you wrote some regex code, some CSV parsing, or you wrote a game in Rust or whatever, whatever you wrote, just compile it to risk five and run it through the risk zero virtual machine. And you get a proof that you ran the game correctly, like the correct rules of the game.

Nicholas: Wow. You could imagine applications of that for, I don't know, I'm thinking like some AI, some CV kind of stuff that could be useful to know that you correctly ran some code on.

Brandon H Gomes: Yeah. So like you could do some crazy thing like verifiable rendering. So like you wrote a rendering engine in Rust and it's like this like huge beast, like maybe a hundred thousand lines of code or this like extreme rendering thing. You don't have to rewrite a single line of it, right? You just compile it to risk five and pass through the risk zero machine and you get a proof that you ran that rendering algorithm. That's it.

Nicholas: Am I naive to think that this is something like proof of work, but the algorithm is actually useful. you could get out of this?

Brandon H Gomes: Maybe there's something there. Yeah. The idea is basically like I want to be able to verify things that I don't want to have to rewrite code that I've already written to like verify that I ran a piece of code, right? Yeah.

Nicholas: If you could, okay, I guess the problem with the proof of work thing, there's other challenges there, but basically you can be sure that someone ran some code that potentially took a lot of cycles to compute.

Brandon H Gomes: Yes, yes, yes. Okay. I see what you mean. Yeah, yeah, yeah. It is proof of work in the sense that I did the work to do this computation. Yes, that is true. Yeah.

Nicholas: So you could potentially, I mean, there's a little bit of hand, obviously maybe a lot of hand waving going on, but you could imagine requiring that people execute some kind of computation that's actually meaningful in order to, I don't know, produce a block on a chain or something or to earn a token or something.

Brandon H Gomes: Yeah, yeah. And there may be some vague similarity here with like the Alio design. Alio is doing something called proof of synced work. So it's like proof of work, but you're also like doing like ZKPs at the same time. So it's like sort of useful in some regard. There's something we can play with there. I don't think there's been fully explored. Definitely.

Nicholas: It sort of reminds me, you mentioned rendering. It reminds me a little bit of whatever Blender was doing with like Blender render credits that people could.

Brandon H Gomes: Yeah, yeah, yeah. I think there's a lot of opportunities for like these very large scale, repetitive tasks that you just want to run all the time. Like just imagine how many YouTube videos are streaming right now. And then just like that, that architecture for streaming, you just decentralize that by building this like incentive systems around it instead of just YouTube running all that themselves. And a lot of this like repetitive work, like in the same way that proof of work on Bitcoin is this repetitive work, but it's like doing something very specific, like rendering or encoding video or whatever it is.

Nicholas: Right. Sort of reminds me a little bit like folding at home type stuff as well. If you can prove that they were running the right code. I actually don't know how the architecture of that stuff works, but it seems useful. Right, right.

Brandon H Gomes: But yeah, that's that's exactly. that's one thing that like proof of work in the blockchain sense doesn't require ZKP because the act of finding a solution to the Bitcoin like mining problem, very easy to verify. You just literally run the hash function. And if the two values that come out are equal, then it works. But for an arbitrary function that's not just a hash function, you have to do a ZKP or some other crazy thing to prove that you ran the function correctly or else you'd literally just be running it again on the chain and that defeats the whole purpose. So, yeah, you have to that's one place where ZK fits in. And then risk zero is like a perfect architecture for that because you already wrote your code in whatever language, you just run it through the risk zero machine and you get automatically ZKP right out of it.

Nicholas: That's very, very cool. So but that's that's a very specific thing. It's not really competitive with roll ups or any of the other stuff we talked about previously. That seems like a very specific.

Brandon H Gomes: Yeah, in general, like in general, the risk zero machine is like just a general purpose compiler, you could say between risk five and ZKP. And it can be used in a role of context or can be used in other contexts. It's sort of agnostic to that at the moment. I don't know what risk zero's plans on like actual deploying one of these machines is other than just right now just to have it around.

Nicholas: Yeah. Got it. OK. Is there a higher level language than CIRCOM that would let you deploy something interesting to L1? Like, is there some kind of Solidity library? or is there something else alternative to CIRCOM that's a little bit higher level or more familiar to Solidity devs that they could use today?

Brandon H Gomes: To use today, I don't think there's very much. I think CIRCOM is your most native, most anything because it's almost like JavaScript, but nothing like what Poseidon VM has, which is a Solidity native SDK.

Nicholas: OK, well, we love JavaScript, so OK. I assume TypeScript at least.

Brandon H Gomes: Sure, sure. Sorry, sorry. I'll say TypeScript.

Nicholas: No, no, no. It's more memetic. I appreciate that.

Brandon H Gomes: Yeah, of course. Of course.

Nicholas: Yeah, it's the CSS of ZK. OK, ZK Sync, Hermes, Scroll, Starknet. Actually, before we get to all that, is Starkware mostly an intimidating meme or is there is there something there?

Brandon H Gomes: So there is something there. Basically, you have this spectrum of ZKVMs that Vitalik describes. It has a blog post. Basically, whenever Vitalik says one of these things, it becomes like a like a religious statement, basically. But basically, there's a hierarchy of ZKVMs that he describes called basically Type 1 through Type 4. And they are on the compatibility versus performance spectrum. So there's a Pareto boundary. The more compatible you make it, the worse the performance typically. And of course, the less compatible, the more performance you might be able to squeeze out of it. And something like Starkware and ZK Sync, they're more on this performance side rather than compatibility side. So we call them like level Type 4, Type 3, whereas like Scroll is Type 2, which is EVM compatible. So the idea is here, your ZKVM, it doesn't have to be running EVM exactly. It doesn't have to be running the same exact EVM that you're running on L1. But if it's close enough, then it's like good enough for most cases. And you can keep most of the tooling around. But once you get into more insane stuff like Cairo, right, it's a completely different language. You can't use any of the existing tooling. But maybe Cairo is more performant because the EVM itself is very slow to run in ZK. EVM was not designed to be built inside of a ZK system, but Cairo was hand designed, right, to be built like that. So in something like Starkware or ZK Sync, they're making this tradeoff on basically performance, but at the cost of incompatibility with existing Ethereum toolchain.

Nicholas: Got it. So in ZK Sync and Starkware, Cairo, you're writing in a completely foreign to the EVM ecosystem environment. And that code is being compiled to what? Different things in each case, I guess.

Brandon H Gomes: Yeah. So Cairo compiles to this thing called AIR. AIR is the language that Starkware virtual machine can understand. And then in ZK Sync's example, it's not a completely new language, but you can think of it as a kind of solidity. But it's not compatible with all the toolchain solidity. So, for example, the gas cost may be different or you may be missing some op codes or something like that. In that case, it's slightly more compatible than something like Cairo, but it's still not compatible in the sense of like everybody made certain assumptions about op codes and gas that you have to abandon.

Nicholas: Like early optimism was the same way, right? It wasn't exactly.

Brandon H Gomes: Exactly. Yeah. Typically they go through this process of first getting the prototype, make it like sort of reasonable, and then getting into this, trying to become a type two, type one, where you try to become as compatible as possible. So something like Scroll is trying to be a type two, which is EVM compatibility, not necessarily EVM equivalence. So they don't have to match exactly what the L1 block structure is, but they at least match the EVM part.

Nicholas: So you can reuse wallets and...

Brandon H Gomes: You can reuse wallets, you can reuse hard hat, solidity, exactly. Whereas there's an even more extreme case, which is the type one, where it means literally exactly the same block structure and everything is L1. And that is something that like the PSE group is working on. I mean, they're part of Ethereum Foundation, so they're very dedicated to like matching exactly. Whereas people who are outside of EF are more exploratory and doing some more like a crazier, crazier kind of versions of ZKVMs.

Nicholas: Got it. So these are... So Hermes also is ZKVM?

Brandon H Gomes: Yes. And then you have something like Midan. So Midan VM is like a ZKVM, but it's a different virtual machine. It's not the EVM side. So I would call it a type four, I guess. Or maybe not. It doesn't even make sense to put on the spectrum. But yeah, so you have...

Nicholas: Okay. So Midan is more similar to Starkware?

Brandon H Gomes: Yeah. They're all polygon people, right? Like Polygon has three different ZKVMs basically. Hermes, Midan, and what's the other one? And Zero. Polygon Zero.

Nicholas: Okay. Okay. And that's more compatible? More like... Yes. Yes.

Brandon H Gomes: Type two, type one. And then Midan is like type four.

Nicholas: And do you think... Do you have a favorite amongst these things? or do you really prefer what Manta's doing in Poseidon with focusing on client side ZK and let someone else figure out the roll ups? Doesn't really matter. Whatever shakes out. Yeah.

Brandon H Gomes: So the Poseidon VM is a roll up, just like the ZK rolls, but it's not a like full ZK roll up. So it doesn't really fit on the spectrum at all. But it would be somewhere between type two and type one. Or actually more like type two, type three. But it is a roll up design. The idea is that it's just a more hybrid spectrum between ZKVMs. being totally everything is ZK versus optimistic. everything is not ZK. Right. And so we just have a hybrid in the middle. And we have a hybrid in the middle.

Nicholas: Okay. Interesting. Actually, I'm curious. What are your friends who are in this very specific part of the crypto industry? I mean, you're doing this Texas Hold'em project, but I'm curious, like, what do you geek out about with them? Is it? I mean, I'm sure papers and things, but are there applications that you're excited about that you see even like experimental toy applications?

Brandon H Gomes: Yeah. Yeah. So so I mostly geek out about the actual like ZK machinery itself. Like how do Starks work and like how do you do this in Red Austin, this kind of thing. But yeah, some of the applications that I that I'd like to see is one of them that I think is really cool is called At The Station. So this is something that Eason is working on. Eason is part of Xerox PARC and he's spinning out a company for for At The Station called Axiom. And At The Station basically are this where I want to prove some property about previous Ethereum block. Let's say like the Mt. Gox event. Right. There was some block back in that time and you can prove that you were hacked. And that itself is something you might be interesting to prove now, like at the current state. Right. So how do you build like a proof that you were part of that event? And then maybe you get access to some like special club membership and get some NFT or something that I was hacked or whatever.

Nicholas: Because because they may not be aware, but like some things that are on the blockchain are out of scope of the execution of a transaction in the current block. You don't know. Yeah, yeah. Exactly. Who owned an NFT two trades ago. You don't know it.

Brandon H Gomes: Exactly. Exactly. Exactly. So At The Station lets you get access to that information. So it's sort of like an oracle for the previous Ethereum state, but it's totally ZK and totally trustless. Which I think is super cool. So that's one application that I like.

Nicholas: And that would require that some kind of oracle or some incentivization scheme encourage people to write the proofs of those.

Brandon H Gomes: So so basically, so basically what it is right now is the the model is like. Like the Axiom as a Axiom as a service provides you these proofs, you install there like their verifier contract into your contract and then you just request for them to send you these at the stations and you like pay for them. You basically say, OK, give me give me a station that I was part of Mt. Gox and I'll pay you for whatever that costs you. Yeah. That's the model right now.

Nicholas: Interesting. OK, I'm trying to think of how that could be. I'm trying to. I'm thinking like it's a mint pass or something as an example of I was. Yeah.

Brandon H Gomes: Because basically what you want to do, you only want to do that once. Right. You don't want to do that every time.

Nicholas: Exactly.

Brandon H Gomes: So you do that at the station. Maybe it takes a long time to build a proof, whatever. And you just build it. You meant an NFT based on the fact that the proof was successful and then you just use the NFT instead of the proof.

Nicholas: What advantage does ZK give you there? more than, say, doing a similar kind of thing, but with Merkle?

Brandon H Gomes: It's completely trustless and it's verifiable and shit. Yeah.

Nicholas: Got it. Crazy. OK, so obviously toys and applications are plebeian and really the real shit is the actual mechanisms of how the ZK stack is built. So what are you excited about in that neighborhood? Is it even possible to relate to a layperson? What's exciting going on there?

Brandon H Gomes: Yeah, I think so. One thing that's exciting just for me personally is most. so there are sort of two different ZK frameworks, ZK implementations that exist. One of them is this like circuit based approach where I write down basically this big math function and I prove that I run the function. And it's like one approach. And it's the one I'm most familiar with just because like what my experience is and like the tools that I've used that I've used in the past. But there's another model where it's basically this virtual machine model. So instead of being I just run this one function all the way through, I have a machine that I can like repeatedly like ask for the next step in the machine like a clock. I just I crank it through this cranking machine. And this little machine, if I just keep running it long enough, it'll eventually produce, eventually emulate that original function that I had that I wrote down. So I think like like I write some formula, like some math formula, whatever, like x squared plus five and whatever, sine x and whatever like that. But then I have a different machine that can execute any of those functions as long as I crank it long enough. So this kind of like cranking mechanism is the thing that's behind Starks. And that's sort of this new invention. Before we were all using this like formula based approach, we had to write this formula down. And now you have this Stark, which lets you do this like virtual machine approach where you just crank through this machine and just run it over and over long and long enough until it finishes the whole the whole computation.

Nicholas: So it essentially creates the equivalent of a circuit that you could have written by hand. But just by running it long enough, it will solve for the function, whatever implementation is required to achieve the function you defined.

Brandon H Gomes: Yeah, exactly. So it's like. it's like writing a special purpose thing versus a general purpose thing. So before we were writing special purpose machines and now we're writing general purpose machines that we just specialize on the particular instance we care about. And so this general purpose machine, like how do you build that? That's what's interesting. This is interesting to me.

Nicholas: Yeah, that's great. That's crazy. Is it worth going? I mean, is it worth explaining a little bit? Starks and things? I'm actually not that familiar. I've heard the word, but I don't really know.

Brandon H Gomes: Yeah. So Stark is this basically this this way of writing this general purpose machine that you crank through. It's just a special way of writing. You could write them in this old style or this like this functional style. The thing that's really interesting about Starks is. So I guess one other thing that's I think more relatable about ZK is deciding the tradeoffs between different models. So there are three things you care about in ZK, which is prover time, verifier time and proof size. Right. That's the only three things you care about. Because everything else is, you know, any function you can dream of can be written into a ZK thing. It's just a matter of which of those three you care the most about. So one thing you care about in Ethereum is verifier time and proof size. Right. Because verifier time you pay directly with gas and proof size you pay directly. Right. Prover time maybe you don't care about as much. But one thing that's really cool, for example, is that because you can run any function you want inside of ZK, you can actually run a ZK verifier inside of ZK. This is where this like recursive stuff is. people are talking about. OK. So here's an example. Right. Starks are very good at prover time. The proof time is very fast, but the verifier time is kind of slow and the proof size is enormous. So if you were to put a Stark direct on Ethereum, it costs like millions of gas or more. So instead what we do is we do a Stark and then we prove that we verified the Stark inside of something that's more optimized for Ethereum like GROS16, what I mentioned earlier. So you run a Stark, then you verify the Stark inside GROS16 and then you post a GROS16 proof on-chain. And this kind of like really weird gluing together of these systems because they have better tradeoffs in certain environments is something that's really cool, I think. So imagine a user, right. The user cares about the proof speed because they just want to get that checkmark on their on the front end. Right. So they want the proof to be very fast. They don't care how big the proof is. You know, Internet bandwidth is good enough these days. You can send a few megabytes. That's not a problem. Right. Megabytes cost you a fortune on Ethereum, but they don't cost you a fortune on Wi-Fi. You build a proof really fast, you use Starks. But if you were to post a Stark on-chain, it costs you a huge amount of gas. So instead, you have a different service whose job is to translate that Stark into like GROS16. And that service can run independently. That can literally be like a roll up, which is kind of what Poseidon VM does, where they take your Stark proofs, which are really big. You can't post them on-chain. They aggregate them into a small proof and you post it on-chain and then they pay very little gas. So this is something that I think is really cool. Very cool.

Nicholas: So basically because of this kind of recursive, inception architecture, you can basically take one of these dilemmas and get actually to maximize on multiple dimensions that if you were only maximizing in a single plane, you wouldn't be able to achieve.

Brandon H Gomes: Exactly. Yeah. So take the little user that has like a small computer. They need to run the fastest thing possible. Then take a beefy user with a big computer and let them translate the result to make it cheaper on Ethereum. I don't have to translate it myself because like, you know, I wouldn't be able to run in my browser, it would be too slow. So give me the fastest thing possible and then I'll hand it off to somebody else who has like this specialized hardware or whatever to run this like extra step of the recursion.

Nicholas: Just to play this out fully, you think that would, the handoff would be done crypto economically on some kind of roll up?

Brandon H Gomes: Yes. This is part of the design of the Poseidon VM roll up. Yeah.

Nicholas: So I guess the only question I have left is how do I invest in Poseidon?

Brandon H Gomes: There's no direct way to invest. But if you prepare, like become, start learning how to do ZK, then once it comes out, you can like kill your app and make lots of money.

Nicholas: Oh, it's so simple. It's so simple.

Brandon H Gomes: It's so simple, right? Yeah. There's no direct way to invest at the moment. We're thinking about how to do that right now. But the thing is like layer twos typically don't, they have a typically a different strategy for deploying tokens than say L1. L1 you need to deploy tokens, it's just like impossible not to. But L2 is sort of is a weird place between public good and like for profit. So it's like, yeah, it's a different kind of situation.

Nicholas: Got it. We'll have to have another conversation to talk about that because I think these airdrop mechanics are not great for a community of people who get airdropped.

Brandon H Gomes: Well, I mean, you could have retired off of like an aptos airdrop.

Nicholas: Sure, sure, sure. But I mean, that's not a liquidity.

Brandon H Gomes: Yeah. Yeah, yeah. I was too busy doing Starks. I should have been waiting for the aptos airdrop.

Nicholas: Yeah, you should have been looking at the profile pictures of founders raising ground in.

Brandon H Gomes: Sure, sure. Exactly.

Nicholas: I could try EFSF, maybe it's the place to do it during the.

Brandon H Gomes: Well, yeah, now I'm here. I might as well, right? Yeah.

Nicholas: OK, this was amazing. Brandon, thank you so much.

Brandon H Gomes: Thank you for having me. Yeah.

Nicholas: This was an awesome conversation. Where can people find you and what else do you want them to take a look at?

Brandon H Gomes: Yeah, so just my Twitter, Brandon H. Gomes. That's my Twitter right now. I'm still pretty light on there, but I'm going to start posting a lot more. I have a new open source library coming out called OpenZL. It's currently you can find it on GitHub. And so this is basically a framework for connecting all these different ZK systems together. So one issue in the open source community right now is that everybody duplicates work. And there's like literally like 30 different ZK systems in open source right now. And I want to be able to connect them together because they all have strengths and weaknesses. So Circom is a really great language, really great tooling. But the prover is not very fast. And so the really fast prover that I'm working with called Plonky2 and the Plonky2 prover is so fast. What if I could just take Circom code and run it on that? So OpenZL is this like open source, open standard system for connecting all these different tools together into one unified interface. So like you can swap components in and out and really get this really great tradeoff performance thing that I was talking about earlier, where certain domains are really good for certain things. And so if you have this like ecosystem lock in, you're sort of screwed because you have to rewrite your whole thing. So OpenZL instead is a way to connect these disparate systems together. That sounds like a really hairy problem.

Nicholas: Is that, that sounds tough.

Brandon H Gomes: Yeah, we have some techniques for it and I think they're pretty successful. They're kind of technical. So maybe we have to spend a whole other podcast just describing how it works. But yeah, I think we have a pretty good general solution and we're, it's obviously open source. So we're looking for people to contribute and build their own plugins. And yeah, I think it's also a huge community effort that people are interested in. Like there's already been a few other similar frameworks in the past. And it's a lot of like the sort of ecosystem bootstrapping you can do. So, yeah, I'm really excited about that project. That's sort of the main thing you could find me on is OpenZL.

Nicholas: That'll, OpenZL will also, I guess, enable it to be easier to do this recursive ZK Inception.

Brandon H Gomes: Yes, exactly. Exactly. ZK Inception and also building your own L2. That's going to be fun. Like at some point building L2s will be easy enough that people will just build them on a weekend. So that'll be, that'll be fun. Yeah, so Poseidon VM will also.

Nicholas: There was actually another question about that very subject. What's the best way to build an L2, ZK L2 in a weekend? So I guess just circumvent OpenZL is the answer.

Brandon H Gomes: Yeah, yeah. OpenZL. Also OpenZL is the thing that powers Manta as well. So OpenZL came from the Manta system that I built and I sort of like factored it out to make it like agnostic to the project you're working on. So OpenZL also powers Manta as well. Yeah.

Nicholas: Very cool. OK, so people will check those things out. I'll put a bunch of links in the show notes of the podcast version of this. And I really hope you'll come back sooner rather than later. Yes, yes. I have so much left to learn from you.

Brandon H Gomes: Yeah, this is really, this is really fun. Yeah, thanks for having me. Awesome.

Nicholas: OK, everybody go follow Brandon because he's got like a hundred followers or something stupid like that.

Brandon H Gomes: Yeah, I just I mean, if you look at my history, it says I joined in 2014, but clearly I I was not on the platform. Yeah.

Nicholas: Well, welcome, welcome.

Brandon H Gomes: It's a pleasure to have you.

Nicholas: And yeah, I hope we get to talk again soon. Thanks so much. And good luck with your poker project.

Brandon H Gomes: Yeah, yeah. Thanks. I'll also I'll send you a link to that so people can play.

Nicholas: Perfect. I'll put it up. All right. Thanks. Thanks, everybody, for coming through and see you next week.

Brandon H Gomes: Yeah. Thanks, everybody.