Reflecting on the State of ZK w/ Kobi Gurkan (Geometry)

**Speaker A:** Hello. **Speaker B:** Welcome back and thank you for joining us for another episode of the Strange water podcast. In October 2021, I was still brand new to crypto. I had heard Hayden Adams explain Uniswap on a Bloomberg podcast back in May, and in August, one of my friends had given me a T. Rex and a tuxedo NFT for my birthday. But by October, I was fully in. And by fully in, I mean I was buying random stuff on Coinbase, never withdrawing from the exchange, wildly misunderstanding Risk, and reading more and more and more and more and more about Ethereum. It wouldn't be another year before I really understood what a KZG commitment was, and then probably another few months before I realized that ZK was where the next revolution in crypto would inevitably take place. But in October 2021, some people already felt the certainty so strongly that they realized that they needed to get ahead of it. And so a few of these people came together to create a research and investment firm to take all of the energy and the vision already growing in the ZK community and provide it with rocket fuel. And so roughly at the same time that I was buying Soul and getting frustrated that I couldn't withdraw to my Ethereum wallet, Geometry was born. For those of you who aren't already familiar with the ZK entrepreneurship space, Geometry is, in my opinion, one of the most important firms that we have today. Not only are they funding some of the most exciting companies building ZK based products, three of which, by the way, Risk zero Nguyama and Herodotus we've spoken with on this show, they are producing research that has been critical to moving this space so far forward in such a short space of time. And so, as you can clearly tell, I am incredibly excited to introduce today's guest, Kobi Gerkin, a co founder and the head of Research of Geometry. Kobi has not only been contributing to this space via Geometry, he's deeply involved with the ZK community, including his personal work with ZK Hack and his frequent appearances on Anna Rose's ZK podcast, which by the way, is a required listen and follow. Today we have an incredibly fun and enlightening conversation on the state of the ZK industry. Kobi gives us his thoughts on the development of the technology, the current state of the research, and what he sees as the more promising areas of innovation. We also spend a good amount of time discussing what it's like building in a field that evolves so quickly, and how to design systems with upgradability in mind. Not financial or business advice, but There's a lot of alpha here if you're thinking about being a builder in the imminent ZK boom. Speaking of financial advice, one more thing before we begin. Please do not take financial advice from this or any podcast. Ethereum will change the world one day, but you can easily lose all of your money between now and then. All right, without any further ado, Kobe Gherkin. Kobe, thank you so much for joining us on the Strange Water podcast. **Speaker A:** Thanks for having me. **Speaker B:** Of course, man. This is a. This is a really exciting one for me because, I mean, spend five minutes in this space, you know that geometry is like one of the beating hearts of crypto and cryptography, let's be clear. And you're a huge part of that. So really looking forward to talking to you. What. Talking to you about what ZK is and how it's going to change everything that we're doing. **Speaker A:** Yeah, looking forward to the conversation. **Speaker B:** Great. So I'm a huge, huge believer that the most important part of every conversation are the people involved. So with that, as like a preface, would you give us your background, tell us how you found, I guess, mathematics and cryptography, and then how you found crypto, like the industry, and then ultimately why you didn't run away. **Speaker A:** Yeah, for sure. Yeah. So I got into crypto a while ago, and actually that was while I was studying for my master's in math and I heard about the bitcoin a while back. Like, I was. I was listening to this podcast called Security now, and in 2009, he was describing this crazy thing called bitcoin and how he mined 50 bitcoins on his CPU, which was great. But I never got really deep into it until I had an opportunity during my masters to just give a seminar about any topic that I wanted. So I said, okay, that's the time, that's the opportunity, and that's what I did. And yeah, ever since then, I just got very deeply into the space and got to work on a few bitcoin stuff and managed to discover Ethereum before it launched and got involved in a few things there, pre projects, did some contributions, whatever I could back then, which was very fun. It was really, really fun to see Ethereum starting from scratch and, you know, to see what it has become today. So that's amazing. Yeah. But a few, like, if we jump ahead a few years, at some point I got. I discovered this topic called Snarks and zk and through some prodding of people around me, which was. Which was very, very useful. And because I really loved it and that's, that's what I've been doing for the last five, six years in terms of a topic of interest, like really deep into snarks and threshold cryptography have been my top favorite topics in those years. Yeah, I led the crypto team in Celo where we did some ZK Life client stuff which was, which was fun and also worked with the Ethereum foundation on zk. But so a couple of years ago, more like two and a half now, I started Geometry with Tom, which is a combination of an investment fund that invest in companies that have some deep math or cryptography as their basis as what makes them unique and succeed, but also research group which comprises, which is comprised of a few applied cryptography engineers. And we use that to try to push what we can in the state of the art and help portfolio companies and so on to use cryptography in the best way possible. But yeah, that's briefly. **Speaker B:** Yeah. Well, man, we'll get into all this in a moment, but I just want to take a second to say that in let's say January to March this year, I had a ZK idea and it was essentially KZG or Plonk as a service. And we had, we met Sriram from Eigen Layer before things had gotten super huge and he had told us like, hey, look, like we don't necessarily want to do the KZG commitments for Eigen Da if we can outsource that, would you be interested in doing it? And so just bringing this up to say that venture didn't end up working out. We had some. It wasn't the right fit with the co founders but like the shining beacon on the hill, like the number one VC that we wanted to talk to and be involved with was geometry. **Speaker A:** So that's very flattering. **Speaker B:** And again, as someone a little bit about me, I entered crypto in 2021. I heard Hayden Adams on a podcast describe Uniswap and my brain just completely broke on the concept of Etherium. And yeah, I've been down the rabbit hole since, but you know, my journey has basically gone from like I was buying this time two years ago, I was buying Cardano and Polkadot on centralized exchanges. And before, before you saw the light, you know. Yeah, well, before I even realized that they were different things. Ethereum and Cardano and all this stuff. I. Anyway, so it's, I guess one, to just remark on how quick this space moves. But two, just to like really hammer home what geometry means. To like this, this corner of this very small space is, you know, Again, I really mean it when I say the beating heart of cryptography and ZK and so just thank you. **Speaker A:** No, thank you. I'm blushing here. If people could see, you know. Yeah, I think that, you know, when I got into this topic, it was more about privacy. Back then the people who were talking about scaling were more academics and it was more like an idea. It was not super practical for scaling back then, but it was definitely something that would have been a good end game. But back then it was practical, even if slow, but it was practical for privacy and that's what the zcash team has been doing. So first of all, I was interested personally in zcash, like something that I've heard about and I looked at and it was definitely mind blowing. It was very complex for me to digest back then and I really wanted to stay in the affinity of that area. And in parallel back then I was working on very non ZK stuff. I was working on a multi signature wallet actually back then. And I then had the opportunity to get in touch with people who were creating a company around Snarks for back when, when it started, it wasn't super clear for what, but it ended up very shortly after to be Snarks for identity. And yeah, that, that was a really unique experience because I got to work on tools that were very, very, in a very nascent form and everything was, was unsafe, everything was undocumented. You had to figure out things by either reverse engineering or reading papers. But to give some credit to the zcash team, they have a wonderful spec that's maintained up until this day and that has been a really great reference for ZK people, one of the best ones in that era. And yeah, we managed to build cool circuits that would solve problems, interesting use cases around identity. And yeah, I think that the fact that you could do something completely private without revealing anything in a way that was non interactive because I knew of simpler protocols that would be between two people or that would be for blind signatures and things like that, but for general computation and inclusion proofs. That was completely mind blowing for me. It was mind blowing that it would be at all efficient. I would have expected it not to be practical at all. And I guess that was the case. Right? That was the case before 2010. Right. So it wasn't practical, but it became practical and that was amazing to see. **Speaker B:** So yeah, yeah, well, I think one of the, like you've been on the other side of the table, but on the entrepreneur side, once you start getting into these pitches, you know, you have the same little quips. And one of the things I used to like, love to say was that, you know, cryptography as a science, like we invented back in World War I and 2 to basically encrypt and like hide messages. And then for what, 80 or 90 years, like, we thought this entire science and mathematical field was just to get better and better encryption. And then in 2009 or 2008, Satoshi Nakamoto comes along and drops a white paper and says, actually there are two use cases for cryptography. And I think like, what we're now in the era of is realizing like, the world doesn't work in twos, it works in. It's things work for one thing or things work for end things. And like, right now we're really figuring out like, what those end things are. And you made a comment about back when you found zcash out, like, nothing really worked and like, all we could do was build just for the sake of building. I mean, it's. It's kind of funny how far we've gotten and how things haven't really changed because, like, man, you're. You're over there investing in these companies. Like, I'm so proud and impressed of what people like Succinct Labs or Inguayama or Sisic or any of these companies are doing. But let's be real, what everyone is just doing is we're not really sure what these tools are for. Let's just build them and make them as performant as possible and make them available for the application layer. **Speaker A:** Yeah, I think that some of it is definitely right. I think that a lot of companies are working on infrastructure without clear users, but a lot of them already have some clear users. So yes, maybe there are different levels of users, right? Like you could already say that there are some users that are interested in block space if you talk about it in the abstract. And I guess layer 2 is already solved for that. For the users that need block space. It doesn't really say what the block space is for, but there is already some clear demand for that. And yeah, it's obvious that there is a lot more to explore in terms of applications to end users. I agree with that. But yeah, it's clear that there is some growing demand for some applications. So like you say, Uniswap was something that was unique and widely used. And I guess we'll talk about it more later on. But I do see a growing number of crypto or let's say on chain native applications that might make sense now that didn't before. Which. Which might mean that it's good to have been patient and not pushing things too fast before. **Speaker B:** Yeah, for sure. And I think the important thing is to stratify between, like, users, what we're talking about, because I think we're clearly at the. Just on this podcast, I interviewed Herodotus and like, they clearly have users, but they're other blockchain developers. And so, like, if we think like in close in, we can build products that have users, but I think we're still pretty far away from figuring out, like, why grandma would ever care about this technology. **Speaker A:** Yes. We have a lot more work to get to grand migrate. **Speaker B:** Yeah. Cool. So I guess now is like a kind of good time to pivot into, like the state of ZK as it is today. So one, I think as a good jumping off point, your work with zcash, what you were kind of pointing at is that you were realizing that the technology and the math and the concepts were at a point where we could apply ZK cryptography to general computation. So can you talk a little bit about what does that mean? I guess let's try to address that for people that don't live and breathe zk, but what does it mean to be able to compress and project and use ZK for computation? And then let's talk a little bit about what that means in a modular blockchain world. **Speaker A:** Yeah. Okay, so let's try it. Let's see if that's the angle you were aiming for. So imagine that you have a program that you run locally and you usually write C code or Rust today or whatever, and then you run it on a server, you put it on aws and you run the code and you get some output from that code. Maybe it was some neural network, maybe it was just some financial application, whatever. But you really trust that it ran correctly. Right. And what ZK allows you to do is exactly get the guarantee that given that you specified the program very clearly, that you wrote the code correctly and clearly, and you specified what are the inputs and what are the outputs that are. Are related to this program, then you could be sure that you offloaded that program correctly to a server. And I think that's a good mental model for developers that are out of ZK to think about ZK generally. And I think that the first papers or the first ones that were aiming for practical use in ZK, and I think specifically I'm thinking about Pinocchio Pghr 13. That's exactly what they're talking about. They're talking about the use case of offloading to cloud and that's kind of a thing that you could get from for example from either trusting AWS or that you could get that from trusted hardware. But if you just want to trust math for that, you are also able to do that. And that's kind of the mind blowing thing for zk. **Speaker B:** And so I guess like I'm just going to hop in here to a hard question, but how do you think about convincing people, everything from the end user to the intermediaries to the developers to everyone that this kind of like concrete provable trust matters? And I, I'll give you an example that we have today, right? Like basically every computer application that you download online, like how you, what you should do is downlo any open source application, you should download the source code, compile it yourself and then check it, read it if you're capable. But at the very least you should compile it yourself, hash it and then check the hash against what the like website says is the commitment of the code. **Speaker A:** Which actually doesn't usually work. Right. Because like you don't have deterministic builds. **Speaker B:** Yeah. Well, how about this? I'll tell you, I don't know if it normally works because I've never done it like 99% of like users I've done it. **Speaker A:** It doesn't work. **Speaker B:** Yeah. So I guess my question to you is like we live in this world where we already have like kind of these paradigms and these tools to achieve just like the very basic forms of what we're building towards and it seems like no one cares. How do you think about just that reality as we're like, we're pushing full hog into the ZK world. **Speaker A:** No, I think that's a really great point and I think there's a lot of bridge here. Specifically, I think that if you talk about mass adoption and the Web2Space, if we call it like that, it takes a while to change trust models, in my opinion. And for a while when the Internet started, we worked with completely plain text Internet, right? Like we, we just had HTML pages go very transparently on the wire and people could just sit in your neighborhood and change the web pages and insert viruses and things like that. I remember doing that in network hacking courses and that was really fun. **Speaker B:** Yeah, I actually studied computer science at Stanford and one of the courses they had was essentially download Wireshark and let me show you all the things you can see. **Speaker A:** Exactly, exactly. But if you do it today, you don't see a lot. Right. That's the thing. And there was a huge shift into having everything run with TLS and now everything is encrypted and now we see this nice lock or the nice green check mark. We actually don't see the green checkmark anymore because it's so default that you don't need it anymore. But that has happened. It took a while together, but that has happened. And I think similarly we've also seen that even more recently. So let's talk about encryption again. We have Google Drive and we have other kind of storage and we put everything there and we don't really think about whether Google can scan it or see what's there and what's going to happen if it gets hacked. And the data centers and the guards there goes and looks at the hard drives. But even, even if you look at what happened, I think it was a year ago, maybe it was a couple of years ago, but Apple introduced end to end encryption to icloud. And that's something that is really, really unique that end users, they just need to enable one, one thing in their phone or in their icloud account and then you have end to end encrypted everything, which was really, really cool. And to me it was a bit unexpected even. But what I'm trying to imply is that the trust and the kind of redundancy, reduction in trust, it happens. It happens slowly, but it happens. And I think eventually that's the end game. So that's what happens. It's just that we have to push for it as an industry and not just in the blockchain space. I think that just specifically in the blockchain space it's easier because it's a very skeptical space in general and you want to. And you have like this fundamental assumptions that yes, my layer one is trustless, so I can't start adding very trustful stuff there. So you have to already make everything trustless and that pushes the boundary of what you need to do with cryptography and other technologies. But this reduction in trust happens globally in at least in some levels. And I think it will just keep happening. It's the natural thing to do. But it will take a lot of time to get to grandma, let's say. **Speaker B:** Yeah, I mean I definitely for me the bet on Ethereum is really a bet about a changing world and a world. Let me just speak for America for a moment and not get political about it. But like trust is completely breaking down. Like I don't care if we're talking about in our personal relationships with our relationships with our government. Like it's just I. I can't even really put it into words but like I'm watching the world fall apart and like nation states and like the way we found consensus and coordinated not working. And then like literally my favorite thing to say is if I ever am looking for proof for aliens, like Satoshi Nakamoto is an alien, like he showed up while trust was breaking down to like give us computer based trust. Like so I guess I take your point that it when these things happen slowly and they happen in the background, but then suddenly one day you boot up wireshark and like everything's gone. **Speaker A:** Yeah. And sometimes there's a pushback. Right. Sometimes there are some bills that we need to backdoor encryption but usually and hopefully it will not work for the long term. **Speaker B:** And how much do you think about how app like when you think of the entire realm of ZK cryptography, how much is ZK cryptography a technology that is associated or related to blockchain and how much of it is like much more general purpose about all the other stuff we are finding ways to use Compute. **Speaker A:** Yeah, I think that's another great question. I think again blockchain found the use case for ZK really appealing and we started with privacy and then eventually the very big use case that is now being ZK is being used for is scaling. And both of these play very well in this trustless and skeptical world of blockchain. And leaving that aside, even though there are growing, growing number of use cases in the blockchain space itself, because we just have let's say more data or that we have more diverse use cases or we have history like you said, you mentioned neurodivers and we have history to read and process and things like that. But if we're talking about how it would look like for everyday stuff and the wider space, I think that the technology itself in terms of what it could provide is very useful. And one example that I really like and that has been talked about more in the last couple of years, but also actually not, not only in the last couple of years, but also many, many years ago, even before ZK became practical, would be the topic of I guess proof carrying data and specifically this way of provably showing transformation on media without revealing the original media itself. So for example, if you have an image that is signed by a camera and then you take this image and you do some improved transformation, for example, you blur faces or that you crop, but you can show the provenance up until the original camera and that's something that a bunch of groups have worked on around Tromer back many, many years ago, and Dan Bonet more recently, and Daniel Kang. And that's a super interesting topic. And it's again becoming much more practical right now and potentially even more important with proliferation of fake news and AI content and things like that. And once we get into the realization that we need to start reducing our trust more and more, I think that these tools would find more concrete use in the wider space. But the caveat is that currently, and maybe rightfully so, we are allowing ourselves to offload our trust to some other corporations. So, for example. Yeah, so, for example, if we're about proving this transformation of images and blurring and cropping, we could also do that in trusted hardware like sgx. And we say, okay, I already trust intel to run my financial transactions in my bank, so maybe it's okay to also trust them to, to prove to me that they cropped images correctly. But I think that once we get into very adversarial scenarios or very adversarial environments more correctly, that we have much reduced trust, then this would be places that would be more natural to adopt these things. And from there it might be the way to get to a wider usage. But there's a big challenge in making it developer friendly, user friendly, and that's something that we have a lot more work to do. **Speaker B:** Yeah, no, I mean, I think everything in this conversation will always point back to, like, how early we are. And so I think, and you know, there's something so special, so, so, so special about crypto. I don't know about you, but I was at Stanford SBC in August and like, that to me was the moment where it just clicked how special things are where you go to a conference and it's literal. Professors who, who are like writing Moon Math like the day before go up on a stage and present out their research. And then like a ton of kids in the audience are writing it down, trying to figure out how do I implement it today, like, how do I put. And I don't know if that's like a function of like how we're a little outside of like the regulatory environment or that there's just like a weird amount of energy or maybe it's like the internationalness of our, our little cohort, but there is just something so dynamic and fast and changing that I think if anyone asked me as hard a question as well, what are the uses of ZK outside of cryptocurrency, I would say I don't know, we have barely scratched the surface of cryptocurrency. We'll get there when we get there. **Speaker A:** Yeah. And I think we have some seeds, but we have more to do and we have more to develop in the culture in the sense that we need to make sure that we don't trust the people we shouldn't trust. **Speaker B:** So I guess with that as a good pivot point, let's talk a little bit about the state of the union, I guess, for ZK today. So can you talk a little bit about what are the most exciting things or advancements that are being worked on in the ZK space, at least from your perspective right now? **Speaker A:** Yeah, I think that a lot has happened in the last few years. Like really, really a lot. So for a few years we had only one proving system that was widely used. Like we had Growth 16 and Starks and like a couple of them, right. And those were very specific. You had this and you had this and that's it. You know, you were good. You could you say, I want a transparent snark. I go to Stark and I want something that has a trusted setup. I go to growth 16. That's it. I'm good. But then Plong came out and that was already a big jump because then we had universal setups. But then in the last three years, we had big or huge amounts of research as to how to optimize these proving systems for use cases that are more important to what we know that we already need. So for example, we had a few papers on the topic of lookup arguments in the span of a few months, which was already, each of them already either incrementally improved on top of the other, but by huge leaps, or that they just worked in parallel and released things just in parallel. And those were very influential in getting us to work on code that we know already, instead of having to redesign our programs to fit the weird models that proving system got us to, to work on. And I think one way to see that is that Barry Whitehead wrote a post about the lookup Singularity which was super interesting and described what if we had a proving system that only had lookups and that lookups were super faster, then we could probably do a lot of, or we could probably prove a lot of the programs that we run today without having to change a lot. And in some sense we, we, we got to a point where we can say, yes, we, we can use lookups very efficiently and do binary operations without thinking about, about it too much and it will be hyper efficient, which is really, really great. And on the other hand, we also have seen the design of other proving systems that are extremely efficient for the things that we know today. So, for example, for inclusion proofs, that's actually been part of the lookup protocols papers. But if we look at all these plonk variants, hyperplonc, and even if we look at these topics of folding like NOVA and Supernova, we just as a community or as more that, I guess academic and engineering community, has managed to really hyper optimize all of these proving systems to what we need. And I think that we just need to sit down now and for each company or each team that is building a product, they just need to understand how to use it, because we had a lot of papers and we have some implementations and all of them are correct. Like, I don't think that there are problems with the results or the benchmarks that they got, but integrating them into specific application is still pretty hard. And I think that is a good picture of where we are today in terms of translating the huge theoretical advancements that we had into practical use. And that's also a lot of what has been exciting for us to work on in geometry. We tried to bridge some of that. Yeah. **Speaker B:** Wait, so to summarize what you said, correct me if I'm wrong, but essentially, like, we're making incredible strides both on the efficiency and the speed of proving systems, as well as coming up with some new proving systems. But I think what you just said is like, the interesting point where we're at is the research is moving faster than the company building or the application. And I think so there. You know, I know that this is maybe your first, like serious foray into venture and it's like right into this field, but can you maybe reflect on like how unique and special that is and like what that means as a builder? **Speaker A:** You mean in the sense of the fact the research moves so fast? **Speaker B:** Yeah, just that we're in this like, weird industry where like, somehow the developers are taking cues from the mathematicians and not the other way around. **Speaker A:** Oh, I see. Got it. Actually, I think it's a feedback loop. I think that the fact that engineers or company builders have been having efficiency problems or have been wanting to solve specific use cases has been informing the academics as to what to look at. I think that works really well. There is a very tight feedback loop and especially it works well when the researchers are also the company builders. And we see that in some places. But not only. I think that we, like you said, we have these professors at SBC they work with protocols, right? Like they, they talk to them and they collaborate and they're happy to do it. Like the, everyone loves to work together. It's a good community and that is a nice feedback loop. But in terms of research moving very fast, it does affect company building and it does affect how you prioritize or how you choose the technology to work with. And let's give you an example. So yeah, right, we have folding and we have lookups and we have all of that technology. And but now if I want to build an application today, what do I need to do and what are the tools that I have at my disposal? And if for example, you asked me a year ago, I would probably tell you, you know what, you still need to go to Circle, you still need to, if you want to deploy something fast and test some assumptions and maybe get to users, you maybe want to go to circumstances, do a growth 16 circuit and start with that and do trusted setup and that would be your first version. That might be okay, but eventually it really depends on the use case. And maybe some use cases require you to hyper optimize from day one. But the situation is that probably if you want to get somewhere fast and you want to get to users, you have to compromise and not use these new tools immediately. Although I feel that it's changing, I feel that the tooling is becoming more practical for let's say everyday ZK user. **Speaker B:** Well, I guess my question for you, and this is obviously going to be super dependent on like the company or the product that we're talking about. But when we're in ZK world, how modular and abstracted out is the ZK from the application so that these upgrades can be implemented? Let's do a hypothetical, let's take Inca Chain, that's a ZK roll up and let's say that Inca Chain was deployed at the beginning of last year and so its underlying proving system is plonk based and now we're a year later and like there maybe like we want to do a fri scheme or there's all this like crazy interesting stuff and the Inca Chain team is like huh, maybe like we made the wrong ZK choice but we want to keep all of like the, the roll up infrastructure that we've built like for again depending on the company. Like are we, is, is this the type of industry that is able to like continue to build in parallel while we research or are the companies that are built today going to be tied to the tech that gets outdated very quick? **Speaker A:** Yeah, that's a great question. So like you said, it depends on the use case. But my sense is that upgrades take a lot of time anyway, even if you think about plonk in general, just plonk. And that's also something I mentioned on a recent ZK podcast episode. I think where you have theoretically this advantage of universal setup so that you don't have to do a setup per update in your program, but actually deploying that update is really hard anyway. Even if you don't do a setup because you need to audit, you need to stress test it, you need to make sure that it doesn't have any security problems, that it doesn't have any edge cases and like even completeness edge cases. And that's already really, really hard anyway. **Speaker B:** Yeah, and has nothing to do with zk. **Speaker A:** Exactly. It. Like, I mean, ZK might make it so that we don't have the enough mindspace and enough knowledge how to look at it the best way. And we don't have the tooling to to evaluate the security or completeness or other aspects of it as well as we do in other environments. But yeah, it's a general problem even out of zk and updates are really hard. And in things that involve private data and things that involve real people's money, you can't really just do it and do AB testing on people and just do continuous integration. It's not exactly the situation that you can afford yourself. And that translates as to whether we can even do upgrades at all. And I think the answer is that it would be hard to immediately hit the target on day one. So I think we need to acknowledge that a company will have to do upgrades eventually, and we need to acknowledge that it will not be easy. So it's hard to prepare for everything from day one. But for example, like you say, maybe there is modularity. So some use cases will have modularity fundamentally, because the proving system will not be the one that informs what I use for my storage merkle trees. So for example, if my merkle trees use Shadow 56, that's really generic and everybody uses it. And every proving system will strive to have an efficient Shadow 56 gadget. But if I let my proving system inform how my data structures look like. So for example, I use Poseidon, and Poseidon depend on a specific finite field of a specific size, and that will inform what is the hash function that I use in my data structure, then it would be more painful to change it later on because if I switch to another proving system like one that is just based on Binary things. I will have to change my data structures and that transformation is possible, but it will be a migration phase. So maybe I will have to have a circuit that will convert every time a user uses data from the old data structure, I would have to first convert it to the new one and do this migration phase. Or like ZKash did when they switched proving systems, they had this turnstile migration phase where you had to unshield and then shield again. And that allowed them to for their specific case it was about mitigating the risk that was from the bug that they found in the. Yeah. In the paper. But it's also just a migration path. Right. So that you can use. So I think it's not impossible to do these changes and it's just going to be hard sometimes if it's not modular enough. But to be honest, I think it's okay. Like we have to accept that because sometimes we have to make this decision. **Speaker B:** To. **Speaker A:** Let our proving system inform and let it control our entire stack just because we need to have concrete efficiency. So that's something that you have to do sometimes. **Speaker B:** Got it. Sounds like there's two takeaways from there. One is regular computer science stuff. Build with modularity and abstraction and then try to contain your brand new piece of research as much as possible. And, and then secondly, it sounds like maybe there's an opportunity for researchers as they're pushing forward in this field to keep like a very strong emphasis on how on upgradability. And so maybe if you're coming out with Plonky five, like have a section in there on like what a migration path would like that would be safe and secure would look like. **Speaker A:** Yeah, that's a good idea. I think sometimes it might be hard for like the Plunky five authors to predict that because they're not involved in every application that Plunky 4 was used for. But they might have some ideas and that would be cool to do. **Speaker B:** Yeah, yeah, cool. So final question on before I want to talk about some of the more like underdeveloped or under researched parts of zk, but while we're still talking about the research here, when you're looking forward and looking at kind of a more mature industry, how do you see this kind of shaping up? Do you think that like all of these primitives and like proving systems and ideas are going to settle into like battle tested open source public libraries or is this more going to be kind of a service model that is running open source code? Like do you see this more a red hat style industry or a like, I don't know, just like JavaScript tools, like a Node JS style industry. **Speaker A:** Yeah, good question. I think that one thing that must happen is that the verifier code is open source and that we know how to reason about it and the circuits are open source because if we don't have that, we are no better than trusting some other people's code that we don't see. So that's something that we have to have open. And if we're talking for example about prover code, I think that there, there is more to play with. There is a wide spectrum of what you can do. So one thing that you could do is you can release one open source prover. Just that I don't have to depend on the company surviving. So if for example, the rest of the application is designed correctly or designed in a way that is exitable and that you can withdraw your funds whenever you want, even if it's harder, then you will be able to do it. That's probably something that it might be nice for companies themselves to do, but also the community might be able to do that by themselves if the papers are written clearly, if the verifier code is easily testable and so on. So that's something that I think would be a good model for as a basic step, like to have to have an endorsed or not endorsed. Sorry to have a way to make sure that there is a path to not depending on the company by having clear specs and so on. But general, I think it's also fair to make a market out of it. It's okay that if I want faster provers and I'm able to, for example use proof, system composition to do some client side proving that preserves my privacy locally and then send it to another party, doesn't see my data but just aggregates it and compresses it so that it's cheaply verifiable on the blockchain. I think that's a part where this kind of a service model might make sense and it's okay that you can then optimize it, you can then run it on special hardware and that doesn't hurt the security at all and creates opportunities to still push the state of the art and still push the usability and what people could benefit from. **Speaker B:** Got it. So it sounds like you're saying in this future world it's totally valid both to say I want to start Maya chain so I'm going, going to like work with this centralized company that we're just going to send all of the data, they're going to give us back the proofs and like that's fine. But also the founders of Maya Chain could decide like we don't want to work with third parties, we're just going to download the libraries and use them directly. And both like are valid. **Speaker A:** I, I think that, yes, but there's also, there's also some part that you, that you probably want to preserve and that's some decentralization, again, not depending on the company. So you really don't want the company to hold you hostage in any way. So you want to be able to always withdraw your funds. So you need some permissionless system. You still need a permissionless system and you still need to be able to force transactions in even if the sequencer for some reason doesn't like you and censors you. So you still need all of these components in order to have these guarantees. But once you have all of these components, then it's okay to start offloading some of it to parties that do the proving really well. I think that's fine. **Speaker B:** So as long as you have like the emergency way to fix things, it's totally fine to go with the guys with the expertise who can do it faster and cheaper. **Speaker A:** Yeah, and I think that's really how things work in the world in general. And as long as we don't put trust in some other parties, I think that's fine. **Speaker B:** Cool. All right, so let's talk about, with our last 10 minutes or so here, let's talk about what are the areas of ZK and of cryptography more generally that you are really excited about and think deserve more attention? Yeah, I guess what would you say is like what is under explored even if it's tough to monetize? **Speaker A:** Yeah, yeah, I think that first of all, maybe things that are not as tough to monetize, but definitely two topics that I think will become important and I think we start seeing the use of them would be this topic of proof system composition. I think that, yeah, I think that opens up the way to create these modular or compose proving systems that allow you to work on different cryptographic primitives or different functions without compromising on efficiency. And the tooling for that is still in early days, but we already see some use of it. So that's really cool. And client side decay I think will become another important thing that we may have forgotten of for a while, or not forgotten, but we may have not felt the need for a while and I think we might feel the need again soon. And Just focusing on getting ZK being fast on client devices like phones and even other resource constrained devices is something that I would really want to see develop further. But now to get to the hard to monetize potentially stuff and something that might become important for people or for even companies just in terms of them wanting to collaborate and keeping privacy, would be technologies like mpc for example. And you know, if I want to collaborate with you on let's say training a model trustlessly like a neural network, or that they want to collaborate with you and understand something that is the combination of our data because I hold a part of it and I hold, let's say the secret keys and you hold the public data. And we want to figure out something together that's like a summary on my data, but with an aggregation of the public data that you hold. Those are technologies that are really, really important, but inherently they're very two party, right? And when things are two party, it's, it's probably a company that has a specific application in mind or that they have something that this would be really beneficial for, that they would be able to push the state of the art. But I think that on the other hand it might also be that these companies will not directly be the ones that will make a developer friendly open source library that will be usable by the community. There is a bigger tension there because in contrast to zk, which is publicly verifiable, you don't have that advantage. And I think that is a hard gap to bridge over. And I think we've been lucky that some academics and some groups still do that as public goods. But it's nowhere as advanced as the ZK tooling and that's something that's going to be missing. So I would really love to see ways to move that forward. **Speaker B:** Got it. And so sorry, just jargon, mpc, multi party computing. And so I think what you just said is that what makes multi party computing different from like the core ZK work that we're doing, even though they use like kind of the same primitives and the same mathematical ideas, is that like the whole idea with ZK is we have these output outputs that are public, that they go out into the world and that anyone can verify that, like even if you can't look into the binary of the prover, whatever we know, does it prove or does it not? And the problem with npc, it sounds like you're saying, is that there's never this step where you're like giving some piece of the process to the public that they can confirm. And so like essentially you just have this black box that unless you're working for the company that's implementing it, you might never be able to understand or prove what's going on. **Speaker A:** Yeah, like it's a conversation between the two of us and we, each of us are sure that we, the computation was correct, but we cannot prove it to a third party. So that sucks. I will say that there are some constructions that combine the two and there have been some works around that, but those add a significant overhead and sometimes that's not always needed, but maybe that's the way to push that forward. Maybe if we do this ZK MPC that is publicly verifiable, maybe maybe the applications that would work on that would be able to get the public good part being done as well. So maybe there is some way to do it through there. **Speaker B:** Cool. And sorry, last thing I want to talk about before I'll let us sign off here. But when I entered ZK or sorry when I entered crypto back in 2021, like we were just at the beginning of really like taking this concept of ZK and making it about blockchain scaling and rollups and all this stuff. And we are just leaving this world of the purpose of ZK is privacy. And I think both those things are true. But I do think we've lost a lot of the conversation of like how ZK provides privacy and, and what cool is happening there. So with kind of to send us off, would you talk a little bit about what gets you excited about ZK and privacy and then maybe if you're feeling very ambitious, how that work can be applied to like core Ethereum and like how that changes just like the block space, space as we know it. **Speaker A:** So in terms of privacy, let's say traditionally, like if we look at five years ago, traditionally privacy has been about financial privacy. And you know, some people would say that maybe that's the first thing that you need and without it you don't have anything. Like if you don't have financial privacy, you're done. But maybe there are also some ways that we could do non financial privacy. For example, if we look at our identities and we look at our on chain data and we can prove some properties about it, we can prove our trading volume or we can prove our ownership of some assets or some NFTs or whatever and we can prove that we've participated in some event because we were ones that were hurt by the DAO hack or things like that. Right. So this claims and queries about your identity are things that I think we will find greater value moving forward. And especially something that I'm getting more excited about recently is this import of web2 identities into web3. Because we do have signatures and we do have some cryptography that already allows us to import some data about our identity and using that maybe in a positive way, not in a way that can hurt us, but in a way that can enable new use cases that would be really good. So the whole topic of identity is something that I look forward to see developing more. When I worked on it, I think it was probably way too early to try to do that. But I think that there is a chance that the time is close or already here. And additionally one other thing that I would say privacy makes sense and is am likely underused a bit would be. Would be to. To do some, some protocols like auctions or like, like, like trades or things of that sort in more private manner. So we can do it. We can specifically look at auctions concretely but we can also look at votes like I do private delegations for validators or that I would. Or that I would have something like Uniswap but that would be batched within a block or things like for example Penumbra does which are really cool and those kind of smaller gadgets that allow you limited time privacy just to get. To prevent. To prevent maybe harmful types of MEV or to. Or to give you some greater assurances as to what are the result you're going to get are things that would be exciting to see deployed. **Speaker B:** Yeah, for sure. I mean when people ask like when I'm feeling like a little sassy and people ask what is going to be the thing that makes Ethereum kind of mainstream or what's the killer use case for Ethereum? To me it's so simple. Right? It's. We already have made it very clear that passwords don't work. So what's like the. The killer app for Ethereum is this is our single sign on machine and I think that like so much about. There's so much opportunity and noise and whatever about the financial side of crypto and blockchain. But I totally agree with you that so underexplored is identity and just like digital nativism and like what this means in a world where every single day North Korea tracking every single database and so that's. That's like one of the things that's so small but is like so exciting to me about the technology we're working on. **Speaker A:** Yeah, let's see where it goes. **Speaker B:** All right, cool, man. Kobe, thank you so much. I, like, it hurts me right now to end this conversation because there's so much I just want to keep riffing off of. But, man, I just once again want to take the opportunity to thank you and to let you know that, like, geometry is everything that we can all hope to build. And I'm just so excited to know you and to watch you continue to push the space forward. So thank you so much. **Speaker A:** Thank you. It was really great to have this conversation. **Speaker B:** Thank you. And before I let you go, can you just tell the audience where they can find you, where they can learn more about geometry? And really specifically, one I want to get across is how do you get involved in zk? **Speaker A:** Oh, wow. Okay. So first of all, if you talk about geometry, the best way is to go to Geometry xyz and we have a bunch of cool articles in our notebook and you can see the different kind of topics we're interested in and work we've done. So please take a look at it. If anything is interesting to you, reach out for me. You can probably find my sometimes half serious tweets on Twitter, so find me there. But yeah, if you want to learn about zk, one thing that, that I would really recommend, and that's the shirt that I'm wearing now that probably the audience will not see, which is another thing that, that I started with Anna Rose, and that's an initiative called ZK Hack. And that's. That's a place where we have a few things, like we have cryptography puzzles, so, so people can learn about advanced cryptography protocols through trying to hack them, which is fun. And there are also workshops about topics in ZK across the ZK space. But most importantly for learning about zk, I think is that we have a few study groups that are going on. And there are study groups around Justin Teller's book, which is great. So it goes. It goes understanding about understanding the fundamentals of how ZK and some checks and things of that sort work. And Justin Tyler himself is the one that's giving that. There is another group about the Moon Math Manual. And there is another one that's starting soon about the recent paper from Alex and Guillermo about how to reason about the security of, let's say, I guess, proof systems or through linear algebra, randomness, which I found a really great paper. And it's a kind of a shorter study group. Like it's going to be a few sessions, but I would recommend people to come and join and learn. **Speaker B:** Yeah, awesome. Well, I did not know about the study groups, but I will be there. So thank you for that. Okay, man. Again, Kobe, I just once again want to say thank you and I want to just put out there if you want to learn more. Also, the best podcast in this industry is the Zero Knowledge Podcast by your friend Anna Rose. And also you are on there so often that again, that that is where I is always, like where I start and figure out like, what is happening and who is talking in zk. So once again, just thank you. Thank you for Strange Water, thank you for everything you do for ZK and hope to talk to you soon. **Speaker A:** Yeah, thank you. Sat.