Unchained - Why Zero-Knowledge Proofs Are Critical to Ethereum’s Future - Ep. 473

Episode Date: March 28, 2023

In this episode, Stanford cryptography professor Dan Boneh and a16z General Partner Ali Yahya elevate our knowledge of zero-knowledge proofs and their applications in the blockchain world. Listen as they dive into the intricacies of succinct proof systems, the difference between SNARKs and STARKs, the magic of recursive SNARKs, and why zero-knowledge systems are essential to the evolution of Ethereum. Show highlights: how Ali became a general partner at a16z Crypto and why Dan started working on “the science of blockchains” what a succinct proof system is analogies for understanding zero-knowledge proofs the difference between SNARKs and STARKs and whether centralization can be fully avoided how zero-knowledge technology became so crucial for blockchains the reasons to push computations off-chain and the applications of this technology why zkEVMs are essential to help Ethereum scale why privacy is important not only in financial transactions but also in other areas like social networks and gaming the challenges that arise from trusted setups and whether it would be possible to create false proofs how to mitigate the trusted setup problem with different proof systems what is being built to make zero-knowledge proofs cheaper to create whether a privacy-focused technology can be pursued while staying compliant with regulations how zero-knowledge proofs can improve the security of blockchain bridges Thank you to our sponsors! Crypto.com Halborn Guests: Ali Yahya, general partner at a16z crypto Dan Boneh, professor of computer science and electrical engineering, Stanford University; and senior research advisor, a16z crypto Using ZK Proofs to Fight Disinformation Links Unchained: zkEVM: The Computing Overhaul to Help Scale Ethereum Previous coverage of Unchained on zero-knowledge: Can You Trace Monero? 'It's Hard - But Not Impossible,' Says Nick Bax a16z crypto: Privacy-Protecting Regulatory Solutions Using Zero-Knowledge Proofs: Full Paper zkDocs: Zero-knowledge Information Sharing How the Coming Privacy Layer Will Fix the Broken Web CoinDesk: Polygon Rolls Out Zero-Knowledge, Privacy-Enhanced Identification Product   Learn more about your ad choices. Visit megaphone.fm/adchoices

Hi, everyone. Welcome to Unchained, your no-hype resource for all things Crypto. I'm your host, Laura Shin, author of The Cryptopians. I started covering crypto seven years ago, and as the senior editor at Forbes was the first Main Tree reporter to cover cryptocurrency full-time. This is the March 28th, 2023 episode of Unchained. Buy, earn, and spend crypto on the Crypto.com app. New users can enjoy zero credit card fees on crypto purchases, in the first seven days. Download the crypto.com app and get $25 with the code Laura. Link in the description. Web3 projects lost nearly $4 billion of crypto assets in 2022,

but nothing is more expensive than losing trust. Secure your company with Hallborn's best-in-class security advisory solutions. Visit halborn.com for more. Today's topic is Zero Knowledge Technology. Here to discuss our Ali Yahya, general partner at ASI, 16C Crypto and Dan Bonay, Professor of Computer Science and Electrical Engineering at Stanford University and Senior Research Advisor at A16C Crypto. Welcome, Ali and Dan. It's great to be here. Thank you, Laura. Thanks, Laura. Let's start with each of your backgrounds. Ali, how did you come

to be general partner at A16C crypto? Sure. I'll give you a quick rundown of my story. I was born and raised in Mexico City. I was always into tech from an early age. I was always into computers and I knew I wanted to come to the U.S. So I came to Stanford, studied computer science, focused on computer systems, computer security, computer networking. And actually, in 2010, I was doing computer security research under David Mazzierrez, who's a colleagues of Danz and a professor at Stanford. And that's when I first discovered the Bitcoin white paper, which was actually too early

to discover it because, I mean, 2010, this is very early. It was very easy to think that it was just a toy, which I did. And so even though I mined it and played with it, I didn't really keep track. of any of the private keys for anything that I might. So that was my first very visceral lesson in crypto, and that was seared into my memory thereafter, especially in 2013 or so when I started to pay more attention. And it started to dawn on me how important technological innovation was at the core of Bitcoin.

I was super interested in the space since then. It was hard to actually work full time in the space. And so I actually took a job at Google X, working on machine learning for robotics and then moved over to Google Brain where I did a little bit of the same. And throughout this time, I got fascinated by Ethereum and was thinking about it and playing with it nights and weekends. And then finally, in 2017, I got connected to the firm to Chris Dixon, who had been investing in crypto for a long time and had started the practice, the crypto investing practice here at the firm. And back then, it was all still kind of

consolidated with the main firm. So his pitch to me was you should leave Google, you should join us, and we should start a crypto fund. So this was before the kind of the proper crypto fund really existed. And so I joined, we kind of saw Ida, I just about everything. So it felt like a, like a great opportunity. I joined in 2017. And in 2018, we started the first, the first crypto fund. We recruited a number of other people. And that team, like just me and Chris, grew eventually to now include something like 80 people or so, like the full crypto team has, has become a much bigger effort within the firm and it's been quite a ride. So that's a quick run-down of my story. I'll pass it over to Dan. Great. Thanks, Ellie. Let's see. So I fell in love with that

cryptography pretty early on. It's a field that involves beautiful mathematics and people really care about the result. It's applicable in the real world. So how can you not fall in love with cryptography, a wonderful, wonderful field to work in? And then I've been a professor here at Stanford for, let's just say a long time. I focus on cryptography, computer security, blockchains, and things and all things like that. I teach all the classes on those topics here on campus. I'd say about a decade ago, my students started asking me about this thing called Bitcoin, and we started looking into it, and we realized, wait a minute, this is like an incredible application of cryptography. Yeah. And so I kind of switched gears to kind of work on

blockchains or at least kind of applications of cryptography to blockchains. And it's, it's been so much fun. I can tell you. The past decade I, it's the most fun I've had in my entire career. Just because there are so many new problems, you know, the blockchain sort of opens up very new challenges in cryptography. It's very interesting questions to think about. And not only is it interesting to think and develop ideas to solve these problems, people really care. They take these ideas and deploy them, and they're then used in the real world to protect real assets. So it's been so much fun to work in the space that I've, you know, I've just, I really, really Yeah, I feel the same way. Out of 25 years of doing journalists in the last date, covering this

space has been definitely the most fun. There's just no question. Actually, one thing that maybe I'll add quickly is that when people ask me what I work on, I like to say that I work on the science of blockchains, and there really is a lot of science in the area of blockchains, which is basically all the underlying technology. that makes blockchains possible. So it's really kind of an amazing area with lots, it's very interdisciplinary and there's like room for anyone. Yeah, Dan, what do you say is basically it brings in aspects of

cryptography, distributed systems, mechanism design and game theory, economics, even political science with questions of governance. It's just kind of hard. It's actually hard to find a scientific field that is more interdisciplinary than crypto and blockchains in particular. And I'll say that even the community is very, very inclusive. in that anyone who has an interest in contributing,

they'll be heard and they'll be, you know, they can make a, yeah, it's funny because sometimes people will ask me like how to work in this space. And I'm like, everybody that works in it was doing something else before. So I'm sure you can figure out a way to contribute. Our topic, as we mentioned, is zero knowledge technology, which is also actually quite multidisciplinary. And people in the blockchain space are super excited about it for a number of reasons, such as privacy and scaling, among other things.

But let's start by defining a bunch of terms. So let's just actually explain what zero-knowledge technology is or zero-knowledge proofs are. Maybe I'll define it in two steps. The first step is what we would call generally a proof system, a succinct proof system. Sometimes these are called snarks. Sucinct, non-interactive arguments of knowledge

is what this stands for. And what it allows you to do is basically it allows a prover to convince a verifier that a certain fact is true. Yeah? And the amazing thing is that no matter how complex the fact is, the proof that the fact is true is going to be succinct, which means that it's very short and it's very fast to verify. So I can take an incredibly complicated computation and the prover will be able to generate a succinct proof.

So it's short and fast to verify. It's a succinct proof that the computation ran correctly. the verifier can easily be convinced by checking the proof that the computation ran correctly, then things will proceed. Yeah. So this is the concept of a succinct proof system. Again, what's called a snark, a succinct, non-interactive argument of knowledge. So that's just for proving that a certain computation ran correctly.

When you add in zero knowledge to it, not only do we want to prove that something worked correctly, we also want to prove it in zero knowledge, which means that we prove that it's correct, but we reveal nothing else about why it's correct. So there could be secrets involved in explaining why something is correct, but I can prove it to you without revealing those secrets. And I guess the classic, I have to give the classic example. We can't not give the classic example, which is you have a puzzle. I guess people always like to give the example of a Suduco puzzle,

and I want to prove to you that I know a solution to the Suduco puzzle. I can do it in zero knowledge, meaning that you'll be convinced that I know the solution, but you'll know nothing about what the solution is. Another example was in this wired video that was in the Zero Knowledge Canon that you guys sent me. And he explained it to like a 10 or 11 year old. He said, okay, I have this image here and it's a bunch of penguins. But there is one puffin in this image. And I know where it is.

And the way he proved it to her was he had a bigger piece of paper that had a single hole in it. And then he moved the, he put the image of the penguins behind the paper in such a way that only the puffin would be visible in that little hole. And so he proved to her that he knew where it was without revealing anything about where it was. And I just thought, oh, wow, what a great analogy. Well, and just to add, I mean, I think both of those examples highlight both the privacy aspect, the zero knowledge aspect, because you're not revealing the actual solution. but they also highlight the succinctness aspect

in that both of them are really efficient to verify that you actually, as the person who's receiving this zero knowledge proof, can very immediately know that actually, yes, the person who's proving this fact to you does in fact have the answer. And in the first case, in the case of the Sudoku puzzle, it's usually the case that verifying that a Sudoku puzzle is correct is much faster than actually solving the Sudoku puzzle,

so it's succinct in that sense. And then same thing with the cutout, at the Puffin penguin cutout, you can actually see the penguin that has the right color through the cutout. And so you know that it exists, but you don't know where it is. And you can do that efficiently and sort of verify that that proof is correct very quickly. So one other aspect of this that I want to explain for people is in the process of creating one of these, there's different entities such as the prover and the verifier. Can you explain those terms?

Yeah. Maybe just to step back one second again, I think it is kind of important to understand that there are two separate concepts here. One is this concept of a succinct proof. I just want to prove to you that something is correct. There are no secrets involved. I just want to prove to you that something is correct. Like, for example, that, you know, the falling solution to a Sudoku puzzle is really a valid solution to the Sudoku puzzle. There's no secrets. I just want to prove to something is correct. And the point is it should be a short proof that's fast to verify, no matter how complicated the computation is. That's one concept. So here there are no secrets. And then an additional feature that you could add on is the zero knowledge feature, which you could say, not only do I want a proof to be short and fast to verify, I also want it to be zero knowledge. Yeah, so that it reveals nothing about why the statement is correct. And those are two, it's kind of important to understand that those are two separate concepts. And so, yeah, so there's a, the players in the space are the proofer and the verifier, as you say. There's a third player,

which we'll add in just a minute. So the prover is the one that is producing a proof that the statement is correct, that, for example, the computation ran correctly. And the verifier is the one that is sort of limited in compute power, and it needs to be able to verify the statement, it needs to be able to verify the proof very, very quickly. And so those are the two players. There's a third player, which is sometimes called the setup player,

which is used, or maybe sometimes it's, called the pre-processing player, which is used to sort of set up the system so that the prover and the verifier can actually, one can generate the proof and the other one can verify it. And so those are the three players in the system, but we'll primarily focus on the proof. And in my research, I also came across the proof generator. Is that different than prover or the same? That's the prover, yeah. Proof generator, prover, yeah. Okay. And one thing that, you know, I kind of wondered when I was researching this is, so if there is

this one prover, then does that mean that when you use your knowledge technologies, that there has to be an aspect of centralization involved? Not at all. Not at all. Actually, that's a wonderful, wonderful question. So traditionally, when the prover wants to prove that the statement is correct, it is true that this single prover would generate the proof. But in fact, just in the last two or three years, there's this concept called a collaborative proof that allows a collection of provers to jointly generate a proof that a certain statement is true. So imagine, imagine there is that each one of the provers knows one aspect of why the statement is true. Think of like the big elephant and each prover only has one side of the elephant. Yeah. And together,

they want to jointly prove that what they're looking at is an elephant. Yeah. And so it turns out even that is possible. That's called a collaborative proof where they jointly, they talk to one another through what's called a multi-party computation. And together, they're able to generate a proof that the statement is correct using the combination of their witnesses. Nobody reveals anything about their witness other than the fact that the statement is true overall. Yeah.

So usually we do talk about a single prover, but that's not inherent in the concept. Yeah, we could actually have multiple provers. And in the cases where you do have a single prover, even though there's only one in or one entity that's generating the proof. It's also the case that they are not really able to falsify the proof and that the work that they're doing has to be correct by construction. The proof ultimately guarantees that whatever it is that they're responsible for doing, whatever computation they're responsible for running, will ultimately be correct.

And so even though in that case, you could say that there's a central entity that's doing the work, there's very little that that entity could do to try to subvert the system. So the centralization isn't as bad as it would be in the case of, say, like a consensus system where if it were controlled by a single entity, that centralized entity could essentially take control of the whole system or sort of subvert the system in some meaningful way. Okay. One other term that I want to define is also there's ZK Starks. So how is that different from a ZK. Snark?

Yeah, so Starks are basically a particular type of proof system. Yeah. And typically at least that's how the term is used. So a snark is basically, I would say, snark or a ZK snark is kind of the umbrella term. And what we now use the term stark as a way to refer to a particular type of proof system, a particular instantiation of a snark. Okay. So let's also now talk about why it is that there's so much buzz about this now.

Like what developments have we seen in recent years that have enabled zero knowledge technology and zero-knowledge proofs to kind of, it feels like they're almost on the precipice of, you know, some kind of tipping point or something. Oh, yeah. So that's a great question. I mean, the question is always like, why did it happen now?

Why didn't it happen? Why didn't it take off 20 years from now? Or 20 years ago or 20 years from now, like why now, why at this particular time? And I think Snarks and generally zero-knowledge proof systems or proof systems in general is a remarkable success story for the theory of computer science. Yeah, this is an idea.

the idea of proof systems and zero-knowledge proof systems, that idea dates back to the 1980s. It's not a new idea. It dates back to the 1980s. But for many years, it was considered this theoretical thing that A, is not clear exactly where it applies. And B, it had performance issues in that it looked like it was quite difficult to generate proofs for very complicated statements.

Yeah. And what's happened over the last couple of years is, first of the first of the, of all, this became like a pretty critical enabling technology for blockchains. It's important to understand this, that like for blockchains to evolve to the next level, they need these proof systems. Yeah, they're kind of a pretty critical enabling technology for blockchains to continue to develop. And so what's happened is there's a lot of effort from industry and from academia, of course, to try and make these things as practical as possible. I want to mention that like in the early 2010s or so, around 2012, 2013, there were a couple of critical results

that basically showed how to improve, these are algorithmic results that showed how to improve the provers. So better algorithms for generating proofs. In particular, what happened is prover time used to be quadratic in the size of the statements, which meant that we can only do proofs for relatively small statements. and that was reduced to linear or quasi-linear in the early 2010s. Yeah? And the fact that now all of a sudden we have linear time provers,

that actually enabled us to develop proof systems that can do proofs for much more complicated systems, and that is what made it practical. And then, of course, what happened is all the commercial need for these things meant that there is a need to develop platforms and frameworks that make it easy for every day. developers to use these systems. And as a result, the field kind of literally just took off over the last couple of years. And I think Ali would agree that these days we can do things in proof systems that just a few years ago looked like science fiction. I mean, this is like unbelievable,

unbelievable advance that we've seen over the last couple of years. I mean, there aren't that many examples of technologies where, you know, five, ten years ago, things that look like science fiction are now completely, completely possible. Yeah. And that's really, the massive transformation that has happened and that is due to both both theoretical contributions and the fact that blockchains need these technologies to continue to evolve yeah it goes to show i think yeah like the rate of improvement that you end up having when you have a whole ecosystem of startups working closely with researchers in academia to make all of these things much much much better than they used to be and that is that is largely because uh zero knowledge proofs or

zk technology is kind of like the holy gray cryptographic primitive for blockchains. And I think it's actually worthwhile explaining why that is. And I think it pops out of the definition that Dan gave at the beginning, which is that, I mean, one of the uses of zero knowledge proves is to prove that the output of a computation is correct. And one of the things that your listeners may already know is that a blockchain, the best way to think of a blockchain like Ethereum is as a computer. And it's a computer that is, controlled by a broad and diverse community, which is to say that it's decentralized. And the way that a blockchain, like Ethereum, guarantees that the computations that run on top

of it are correct today is that every node in the network has to run every instruction of every computation that users submit to this computer. And of course, that's a very inefficient process. It's what causes blockchains to not really scale, at least not in the form that they exist today. And it's also what makes zero knowledge proofs such a perfect primitive to solve this problem, because with zero knowledge proofs, what you could do instead is have any one node run the computation and generate a proof of its correctness. And then because that proof is succinct, which again means that it's small and it's very fast to verify, every other node in the network can just verify that proof without having to do the heavy lifting

of actually running the competition themselves. And so because zero knowledge proves have this beautiful application to blockchains, They have improved dramatically over the course of the last five years or so by many orders of magnitude. Like the Prover generation costs are much lower than they used to be. We've got much better algorithms. We have optimized implementations of some of these algorithms. And then we're also starting to see hardware acceleration for all of these things, such that it all becomes so much better.

And it's now becoming feasible to reimagine what a blockchain might look like in terms of zero knowledge proves, not that they were available. And that's maybe something that we can dig into. I think it's an exciting application of zero knowledge proofs to this space. And we haven't even started to touch the ideas of privacy, which is a whole other kind of interesting section that we can also discuss. But actually, let's build on that. Actually, if it's okay, Laura, I'd like to actually, I think what Alie said is like a fantastic way to introduce roll-ups.

So let's build on that just a little bit in that really the application, the reason why proof systems are so useful for blockchains is that they fund fundamentally enable us to outsource computation to an out into an external server. Yeah. So you can think of a blockchain, as Ali said, a blockchain is a computer. Yeah, you can think of it as a, it's like a computer, but that will run arbitrary programs. The problem is that it's a very slow and very expensive computer to run. Yes?

And so just to keep, you know, you always have to keep in mind. Ethereum can process like 15 transactions a second. So it's a computer, but it's a slow and expensive computer. And so if we ask this computer to do a very complicated computation, we're going to run into trouble because it's going to be, it's going to take a long time and it's going to be very expensive to do. So what we'd like to do is we'd like to move as much computation off this computer as we can. Yeah. And in fact, there's massive industry effort and just getting computation off of the blockchain, right? So the blockchain can just do as little as possible because it's such a, you know, a slow and expensive computer.

And so when we talk about outsourcing computation, we'd like the computation to run on some external server that's like, you know, fast and cheap to execute. The problem then is how do we know that what the server told us is correct, right? So the server is going to push the results back to the blockchain. But how does the blockchain know what the server computed is actually the correct result? And that's exactly where proof systems come in. So proof system let us do is they let us move computation from a slow computer. onto a very fast one, that fast computer will compute the result and will also attach a proof to that result. And that proof is going to be short and it's going to be fast to verify so that

when we push it onto the blockchain, the blockchain can now quickly get confidence that the result that it's looking at is correct. And everything follows from that. By the way, I'll say that it's not just blockchains that can benefit from these proof systems. Also, you know, if you need to do a computation on your wristwatch, right? Your wristwatch is not a very powerful computer. It's the same principle. You can move the computation to a fast server in the cloud, and the server can generate a proof along with the result to convince the watch that the computation is correct. And really, a lot of the applications follow from that. And Ali mentioned ZK roll-ups, which allow you to process many transactions, right? So we can take a thousand transactions,

have a remote server processed those thousand transactions and produce a proof that they were processed correctly. And now we just push the proof onto the chain. So now all of a sudden, every transaction that's sent to the chain actually corresponds to 1,000 transactions. So instead of 15 transactions per second, now boom, we're at 15,000 transactions per second. Yeah, and that's where the scaling comes from.

But there are many other reasons to push computations off of the chain. And maybe I'll mention them quickly, and we can come back to them later. It turns out when you come to bridge between blockchains, building a bridge between different blockchains, there's a need to push computation off-chain. It turns out if you're doing complicated financial modeling that you'd like to do on the chain, it makes sense to do the financial modeling off-chain and push proofs on-chain. And so this idea of outsourcing is a very powerful idea.

It really allows the blockchain to do things that it simply can't do today. And that's, again, that's why this technology is such a critical piece of technology for the continued evolution of Ethereum. Well, one application that people are also excited about is just straight up ZK EVMs. And I wondered what your thoughts were on those. I think around the time this comes out, Polygon will be releasing its Zero Knowledge Ethereum Virtual Machine

is what that means EVM. So what's your take on ZK EVMs? Yeah, I mean, one way to think about a ZK EVM is as an instance or a way of implementing what we've been describing, namely a zero-knowledge roll-up, where you have some way of proving EVM bytecode computation using a zero-knowledge proof that can be outsourced from the layer one blockchain to some faster computer, as Dan was saying, something that can actually perform all of those computations off-chain, produce a proof for them, and then push them back

to L-1, and then have L-1 just verify the resulting proof very efficiently. And as ZK EVM just suggests or just alludes to the fact that it should be backwards compatible with the EVM, that you should be able to take a solidity smart contract and compile it down to the EVM and then have the resulting bytecode still be provable by the ZK roll-up. So it's one way of essentially scaling. Like I think like the interesting, just to step back, the interesting thing about zero knowledge proofs is that it unlocks this whole new design space for new architectures for, blockchains that are able to scale better than existing blockchains. One approach is this ZK roll-up approach, which is a combination of a layer one like Ethereum, plus a layer two,

like Polygon, as you mentioned, and there are many others like Matter Labs and Scroll, and there are many other projects that are working on similar approaches, which essentially outsource the computation to a sequencer. Sequencer is a faster computer that performs all of those computations and produces a proof. Other approaches might include re-architecting the entire blockchain from scratch. So instead of having an L1 like Ethereum that already exists and attaching an L2 on top, you could build, for example, a blockchain that's sharded. And this goes back to many of the attempts from 2017 and 2018 to build a sharded blockchain. But the difference now is that zero knowledge proofs are much more efficient. So the problem of building a sharded blockchain has gotten much, much

easier because before the challenge was if you have multiple shards, multiple interconnected blockchains that are somewhat independent from each other, how do you know that the work that the other shard did is correct? And before in 2018, there were all of these kind of game theoretic solutions to try to get out a solution. But now, because of zero knowledge proofs, again, you can do the same thing, have one shard, have the nodes in one shard generate proofs for the computations in that shard that other shards can then verify to the problem of securing a multi-shard system becomes much easier. That would be a completely new architecture that is now possible, that may have not been possible before. And it might also be compatible with the EVM.

And so technically would be another instance or another form of a ZK EVM. Another architecture might actually, I mean, as Dan was alluding, you can actually have the computation be done either fully on chain in a data center or you could imagine the computation be done on the client. Like you might not have a server at all and you might have the browser or the phone do the computation associated with the transaction that is submits to the blockchain on the phone and then submit the transaction together with its proof to the blockchain and then have the blockchain simply just incorporate it such that you don't even need something like a like a sequencer or a server that generates the proof. Essentially the user can become

their own prover. So that's just to illustrate that there are many new kinds of architectures that have become possible and that will become increasingly viable as the technology improves, some of which will be compatible with the EVM and therefore deserve the moniker ZK EVM, and some of which might actually take a completely different approach and might not be backwards compatible. It might be better in other ways. Maybe I could give you also an example, because this is what you asked is such an important question. Maybe it's worthwhile going through an example in that suppose, you know, suppose you have a program that you want to run. Yeah. So,

Typically, if you want to run this program on the Ethereum computer, you would write it in a language called Solidity, which I'm sure many of your listeners are familiar with. And then you compile it to byte which runs on top of the EVM, right, the Ethereum virtual machine. So on this program, right, one thing you can do is you can just send the program to the blockchain and then have the Ethereum blockchain itself execute the program. But it's expensive, right, because programs could take a while to run and so on. So this could be, again, it's a slow and expensive computer, so that could be expensive. What's cool is that now we can actually outsource the function of this program. We can outsource it to a remote server. Yeah, so the remote server will actually execute the EVM bytecode that you give it.

Yeah, it will produce a proof that it ran it correctly and then push the proof onto the chain. So the chain now, instead of running the actual program that it's supposed to run, all it has to do is just look at the proof, verify that the proof is correct. And then it trusts that the program ran correctly. So you're able to move computation, a lot of computation off-chain to this remote server. And that's exactly what these succinct proofs enable you to do. All right. So in a moment, we're going to talk about privacy applications of ZK technology.

But first, a quick word from the sponsors who make this show possible. Now streaming on Paramount Plus. It began on the shores of New Jersey. The calls of Jim, tan, laundry, reverberated north to Canada, where a new type of party animal, resides. They move as a herd migrating to their favorite watering holes, asserting dominance

by flexing, grinding, and twerking. Coupling is quick, steamy, and sometimes in hot tubs. When morning arrives, they do it all over again. Canada Shore. New original series, now streaming on Paramount Plus. Amazon presents Jamal

versus the Shih Tzu. Descending from the gray wolf, Shih Tzu's live by their own untamed primal code of not giving a single shih Tzu. But Jamal shopped on Amazon and bought dog treats, chew toys, and 32 ounces of carpet cleaner. Hey Jamal, you've been promoted to pack leader. Save the everyday with deals from Amazon. Join over 50 million people using crypto.com, one of the easiest places to buy,

earn, and spend over 250 cryptocurrencies. New users enjoy zero. credit card fees on crypto purchases in their first seven days. With crypto.com earn, get industry-leading interest rates of up to 14.5% on over 30 coins, including Bitcoin, earn up to 8.5% on stable coins. With the crypto.com visa card, you can spend your crypto anywhere. Enjoy up to 5% cash back instantly, plus 100% rebates for your Netflix and Spotify subscriptions, and zero annual fee. $3.8 billion of value was stolen from crypto projects last year due to compromised private keys, exit scams, flash loan exploits, and other preventable causes. Hallborn offers preventative security solutions for every stage of your software development lifecycle. From smart contracts, layer one, and DevOps audits, to advanced penetration tests, risk assessments, and incident response.

With over 150 industry partners, including Anamoka brands, Salana Foundation, and Ava Labs, Halborn's best-in-class security advisory solutions ensure the safety of company assets and user trust. Visit halborn.com for more. Back to my conversation with Ali and Dan. So there's been a lot of activity also in applying ZK technology to privacy to these very public blockchains. which, you know, unfortunately, some of the criminals in the crypto world have unfortunately realized that, yeah, it's really not as private as they thought. So what are the ways that we're seeing this technology being applied to privacy? Maybe before we talk about, we should probably talk about first the need for privacy, right?

And so right now, blockchains are not private, right? At least Ethereum is not a private blockchain in a sense that if you look at the Ethereum transactions, you can see exactly who's transacting with who. You know, that sort of fundamentally is not compatible with businesses, right? So if businesses, like, you know, if the university decided that they want to pay my salary in crypto, you know, everybody will see exactly what my salary is, right? Or if, you know, if manufacturer wanted to pay suppliers in crypto, everybody will see exactly how much they're paying for parts. That's fundamentally kind of not acceptable to businesses. And so if the chain is ever going to be used for businesses, there's a need for privacy, private transactions. Right. So that's kind of a starting point. And because people realize this actually

fairly early on, you know, we do need some version, some privacy mechanism on the chain. And there have been many, many proposals and attempt and actually deployed systems to provide private payments on the blockchain. Let me actually also add a couple of other good reasons that why privacy is important. I think one of them is what Dan alluded to, which is that if you wanted to run anything that's akin to a business using a blockchain system, there's just no way that you could do that without privacy. But there are also many other kinds of applications that aren't really possible without privacy that are kind of independent of whether or not they have anything to do with payments or anything to do with running a business.

And a good examples, a few good examples. So there's this big category in the space known as decentralized social, people building decentralized social. People building decentralized social. networks, things that look a little bit like Twitter, but don't have a monopolistic tech giant in the middle that controls everything and that is able to censor any one user or de-platform anyone user or control who you get to follow and not follow. And instead has all of the relevant functionality on chain and a decentralized system such that users own their own data, users decide who they get to follow. Users decide what client they install. such that they can determine and decide on what recommendation algorithms are used for the feeds that they are exposed to.

And building something like that is possible with a lot of the technology that already exists. But you could imagine that certain aspects of that might have to be private. Like, for example, the recommendation algorithms that the system uses, it might not be a good idea for that to be fully public, because if it were, it could be easily gamed. So you might want to have a notion of a private recommendation algorithm that is still verifiable, right, that you can still generate a proof for because people in the community would want to know that it's being sort of correctly applied and then it's not discriminating. And that could be one use of zero knowledge proofs. It could also be that maybe users want their data to be private in some way, but still be able to prove aspects of that data to other users. So decentralized social networks, huge area of application for zero knowledge proofs.

and in particular for the privacy aspect of zero knowledge proofs. Another application area is that of gaming. There's a very big movement of people in the gaming world who are now intersecting with crypto people, who are building games that are crypto-enabled in some way. And that could be that the game has an inbuilt crypto economy that's real that is connected to a blockchain and therefore makes the in-game items portable.

It makes it possible for a user to actually own the thing, that they own in the game, to take those things out of the game and potentially take them into another game and to therefore have a persistent identity in this multi-game world that starts to actually allude to this whole vision of the Metaverse, which is a whole rabbit hole that maybe we can save for another time. But I think if you wanted to build a decentralized game where most of the logic and most of the activity happens on chain, you might also need privacy to some extent, because you might want to be able to add to the game a notion of a fog of war, right, like a layer of uncertainty that players can't pierce through such that players cannot

know what other players are doing, because if they did, maybe the game wouldn't be as fun. Uncertainty is often a fun and important component of games. And Dark Forest, by the way, is a good example of a game that's mostly on chain that implements the fog of war using zero knowledge proves and using the privacy aspect of zero knowledge proves to make sure that there is uncertainty in the state of the universe and that players cannot just automatically know everything that there is to know about the game in particular. And maybe a third, a third interesting application for why privacy is important. You can think of this whole new intersection of fields between crypto and AI.

So this is kind of ZK machine learning world where you could imagine having a machine learning model that produces predictions. And you can imagine wanting to make the model private for the same reason that you, you would want to make the recommendation algorithm in a social network private, such that, you know, people can't see how the model does what it does. Maybe the model is like a trading strategy in a defy protocol. And it would be, it would not be good if that model were fully public, because then the trading strategy would be useless if everybody can see what it does.

So you would want it to be private. And maybe you would want to prove that the strategy is being executed correctly. So again, you could use as their knowledge proof. And then it could also be that the inputs to the model, like a user might be submitting, for example, their information, their personal information to a machine learning model that produces a credit worthiness score, like a credit rating. You wouldn't want the user's personal data to have to be public. Right. So same here. Like you would want to maybe obscure or encrypt those inputs, the personal user information using ZK technology to have this machine learning model that produces a credit.

score work in a verifiable way without kind of revealing, revealing personal, personal identifying information. And like that, there are many other applications. So privacy is important not just because users care about their own privacy, but because it unlocks a whole new region of the design space that is just fully inaccessible today with public blockchins as they work today. Laura, actually, can I give two more examples that are, I think, are very appropriate, given the times. So Ali, I gave a fantastic overview of kind of different ways in which privacy could be used, particular zero-knowledge proofs, right? So now we're not just talking about proof systems.

We're talking about zero-knowledge-proof systems that prove that something is true without revealing why it's true. And so maybe one more example that is very appropriate these days. It's actually, when assets are recorded on chain, it's actually possible to give what's called a zero-knowledge proof of solvency.

So you can actually prove as an exchange, for example, you can prove that you're solvent. In other words, you have more. more assets than obligations to your customers, and you can do it in a zero-knowledge way. So without revealing how many assets you have, without revealing what your obligations to your customers are. Yeah? And so because it's automatic and it can be done in zero-knowledge, you can imagine that banks

or exchanges could, like, every day, generate a zero-knowledge proof of solvency. I guess this is all very relevant these days. Very. So a very nice application of zero-knowledge, and I'm very hopeful that this will actually be put to use in the near future. Yeah, we're recording this just on the tail end of the Silicon Valley Bank situation. So definitely very, very apropos. Yeah, and signature also being closed.

Yeah, one other thing I wanted to cite was Polygon ID, I guess, was just rolled out. And, you know, that's another way to have identity, which is obviously an area where people want privacy using zero knowledge technology. And from reading that and just some of the other things around that, I realized like, oh, this could be combined maybe, or you tell me, with kind of like anti-money laundering slash know-your-customer type compliance controls. And even I was reading something else that made it seem like you could also provide like auditing trails for regulators or something using zero knowledge proofs. So you would maintain the privacy without it being like a complete black box for compliance purposes. Yeah, absolutely. I think it is connected to the kind of the use case of being able to prove something about who you are or the state of your finances or your solvency or whatever else in a way that still preserve some of your privacy.

So from a KYC standpoint, instead of providing all of your personally identifying information like a copy of your driver's license and passport to some centralized entity, that that then stores it in a way that could that then get lead. or hacked, you could instead provide them with a proof that's maybe signed by your bank that your balance is greater than some amount, right? Or that they're kind of underwriting you for a certain level of risk or whatever else. And it could be compounded with maybe signatures from other parties into one thing that can give the party that you're interacting with confidence, that you're either a real human or a human who's solvent or a human who has certain characteristics without you having to essentially share everything as you do today in a KYC process.

All right. So now let's talk about some either problems or disadvantages to zero knowledge technology. One that I've read about, and I don't know if this has been mitigated in any fashion, but for a long time people have talked about the quote unquote trusted setup problem. So can you define that for people and then talk about, you know, how much of a problem that is nowadays. I don't know if it's been mitigated in any fashion. Yeah, I guess this is kind of the third player that we mentioned in the beginning, the setup, the setup player. So some of the zero knowledge proof systems that have been deployed

require this trusted setup. And what does that mean? That basically means that there is some sort of a system that generates these parameters that the provver and the verifier will use to generate and then verify proofs. And the issue is, the reason it's called a trust set up, is that if somehow someone subverts this trusted setup mechanism, in particular, there's randomness involved in the trusted setup. And if this randomness becomes publicly available, that would allow the prover to produce false proofs. Yeah?

And producing false proofs is a terrible situation in this world because basically it would allow me to prove to you that certain things that are false actually are correct, and that basically results in theft of assets. Yeah. The trusted setup, the difficulty with it is that it does require some secrets to be kept secret from the prover so that the proof system is sound. Typically, when proof systems need a trusted setup, what happens is that that's done through a massive distributed computation. And as long as one member of the distributed computation is honest and honestly that destroys the randomness that they used, then the trusted setup is fine. Yeah. So that's kind of how, that's one way we mitigate the trust.

setup, we just run it across a large number of parties, and as long as one party is honest, everything is perfectly fine. And in fact, as you may know, the Ethereum Foundation is actually taking steps now to do a trusted setup ceremony across a huge number of participants. And as long as one of those participants destroys the randomness, the trusted setup will succeed. Another way to mitigate the trusted setup is to just get rid of it altogether. Yeah. And those are called transparent proof systems that require no trusted setup. And now actually we have better and better transparent proof systems. They still seem to generate longer proofs than proof systems that do require a trusted setup.

So in one case, in the trusted setup case, the proofs are shorter and faster to verify. In the other case, they're a little bit longer, but they're getting better. Yeah. And so we have ways to do proof systems without a trusted setup, but there is currently some cost doing that. So one other issue that I came across is that zero knowledge proofs don't also give 100% guarantees that the claims are valid. So what's the best way to deal with that? Because as far as I understand, you would need to do like a large number of computations or there would need to be a large number of interactions between the proven verifier to get, you know, closer to that 100%, which obviously

is burdensome. So. Okay. So I think I think I know what you're referring to. And honestly, this is mostly boils down to correct configuration. So these proof systems, you know, they have to be configured correctly. And if they're configured correctly, their soundness error is negligible, sufficiently negligible. And so we know how to do things correctly. It's just, you know, whoever is deploying the systems has to take the steps to make sure that they're configured correctly.

Okay. So one other thing is that I think the technology maybe can be relatively slow or take a lot of computing power. So what are some of the technological constructs? that we have right now that need to be overcome for this to be more widely used. Oh, my God, we could spend a whole hour just on that question. That is a long and fascinating, fascinating question. You know, in some sense, the research of the last 10 years has literally been focused on exactly what you just asked, right? How do we get the Prover to run as quickly as possible?

And so, yeah, so there are many, many innovations that are happening in this area. This is actually the fact that Provers are getting faster is why this technology now is being deployed so widely. Let's see. So if we can put on our technical hat for just one second, I can tell you that the expensive parts of proof generation or two of the expensive parts of proof generation, one is called multi-scaler multiplication or MSM, and the other one is called a Fast Fourier Transform or FFT. and the question is how to speed those two steps, the MSMs and the FFTs. And in fact, actually, Ali, maybe you want to describe the Z-Prize effort

that took place to accelerate? Yeah, so actually ALEO, which is one of the projects in the space that's building a blockchain that uses zero-knowledge proofs for privacy. It's essentially a blockchain that's somewhat like Ethereum, but where all smart contracts that run on top of it are private, hosted this competition known as a Z-Prize competition. to encourage the whole ecosystem to submit solutions to the problem of speeding up for your transforms and MSMs as much as possible. And it was kind of encouraging to see sort of the submissions that came, some of which came from actually outside of the crypto world,

from people who work at places like Nvidia, who leverage very specific features of hardware, namely Nvidia GPUs, to end up with an optimized implementation that dramatically outperforms everything else. which kind of goes to show, I think the ways of improving the performance of the prover piece of a zero knowledge proof can come from deep research, like things like algorithmic improvements, which I think have happened over the course of the last five years, but can also happen through both just optimized implementations, really smart people who write very efficient code, that maybe targets special purpose hardware, either GPUs or maybe eventually we end up with things like ASICs, the speed some of these things up.

And I think things like the Z Prize and other prizes that incentivize people to come up with better solutions will probably be a big part of what gets us to the next level of performance. Yeah. So there's room here definitely. I mean, there's room for engineers that are needed to speed up the implementations of these provers. And there's a need for algorithms, folks, to speed up to come up with better algorithms for doing these proofs. So I can tell you again, the kind of the two heavy steps are this or two of the heavy steps are MSMs and FFTs. In some modern proof systems, actually, we're able to get rid of the MSMs. So we can kind of simplify the proving process somewhat by removing one component. Those still tend to lead to relatively long proofs. So there's still a lot of room for improvements.

Another area, since you asked about the cost of computing these proofs, I'll tell you that another area is not for improvement, is not just the actual compute time. It turns out when you go to very large proofs that you're proving very large statements, it turns out actually just a bandwidth between the CPU and main memory. Yeah, these provers actually are saturating the bus that connects the CPU and main memory. And so part of the effort actually in the last year has been, can we actually build proof systems where the memory requirements are not so bad, right? So that maybe we don't have to saturate the bus between the memory and the CPU.

Yeah, so there's a lot of effort. and reducing the memory footprint. And then I'll say the last, another area that's seen a lot of improvement is this area called recursive snarks. Now, recursive snarks are these things that will blow your mind. This is like one of these things that are really quite magical in that, remember how we said that a proof system proves that a statement is correct? Well, a recursive proof system proves not that a statement is correct, but it proves that I have

a proof that a statement is correct. Yeah? I don't prove that a statement is correct. I prove that I have a proof. And you can further recurse. I can prove that I have a proof that I have a proof that I have a proof that a statement is correct and so on and so forth. And it turns out these recursive proof systems,

they have a lot of benefits. One easy benefit to understand is that in the regular proof systems, you have to have the entire statement in your hands in order to start producing the proof. But using recursive proof systems, you can actually stream the statement. So think of a roll-up system where you have transactions from the public. You're trying to process a thousand transactions on the public. Normally, you would need to collect all thousand transactions and only then you can start building

the proof that these transactions were processed correctly. With the recursive proof systems, you know, you can take the first batch of 100 transactions and produce a proof that they're correct. Then you take the second batch of 100 transactions, produce a proof that they're correct. And then you produce a proof of a proof that those two proofs that you just generated are themselves correct. So now you're proving that you know a proof. And that's kind of the power of recursion. Generally, what they allow you to do, and again, this is for your audience. I highly encourage you to go look up the concept of recursive proof systems. It's a really kind of a fascinating, fascinating concept. What it allows you to do is to take a very large proof and break it into many, many

smaller proofs, which you can kind of prove on their own and then produce a proof of a proof that all these smaller pieces are correct. Yeah. And so, yeah, so like I said, this is an area that's also evolving quite rapidly and also holds a promise to build faster, faster provers. So as we said, this is a pretty active area. And hopefully, you know, as more ideas come in, and there's a lot of room for your listeners to contribute to this area, as more ideas come in, you know, we'll end up with faster and faster approvers. Another big area of improvement is the tool chain that goes from the developer all the way down to the actual circuit that gets proven. And that includes often a compiler. And a compiler is a thing that translates a high-level programming language that

is useful and intuitive for a developer to use, kind of like solidity, down to the very bare metal, down to something that I can actually be proven by a proof system. And there is a lot of work that's being done in building compilers that work with programming languages that are intuitive, but that also optimize that translation that goes from something like solidity to a ZK proof such that it's more efficient. And so improvements in the compilation process might also lead to another order of magnitude improvement in performance. But it might also actually allow for special applications that are maybe not just solidity smart contracts, but are more specific. Things like, for example, if you wanted to compile down a machine learning neural network down to a zero knowledge proof, you could come up with a compiler that is specifically optimized and specifically engineered to do that,

such that the proofs or that there's the circuits that emerge on the other side are much more easy to prove than if you were to try to do it from, say, something like solidity, which is general purpose and is not optimized for machine learning. And so I think the tool chains that people will come up with to compile down programs of any kind, whether they be general purpose, solidity, smart contracts, or more specific things like machine learning models or other things, we'll also play a big role in making all of this more performant and mitigate this challenge that today running approval is an expensive thing to do. And also, are there like hardware issues here as well? Because just in my research, it seems like hardware is a component of this.

So are there further developments needed on that side to make this more widespread? Yeah, for sure. I mean, you know, we told you that when you ask about performance, approvers, this is a big topic and there's a lot to say. So definitely developing specific hardware to speed up provers is a big deal, like specifically speeding up these multiscaler multiplications, speeding up these FFTs. This is kind of a big area where dedicated hardware ASICs can actually help a lot. And in fact, there are a lot of hardware engineers right now who have knowledge in how to construct ASICs. What they're working on is accelerators for provers. It's really

quite wonderful to see. I'll say one more area that I think will be interesting to you and your listeners in that there's also a coming marketplace for provers. So today, if you want to prove a complicated statement, you know, you want to generate a proof that the statement is correct, you know, you kind of have to do it yourself. You go and, you know, you have to buy the hardware and

generate the proof yourself. You know, but that's kind of voiceful, right? There are a lot of people who have invested in GPU for playing games or maybe for cloud applications and such. And they don't use these GPUs all the time. Sometimes they're idle, right? And so it makes sense that if you have a fancy GPU because you set up a fancy gaming rig for yourself, maybe when you're not playing a game,

you can say, well, you know, use my GPU to generate proofs, right? And so there's actually a very interesting marketplace of GPUs and general, you know, potentially even A6 and FPGAs that people can put on make them available for people who need to generate proofs, and then they'll be used to generate those proofs, and they'll be compensated for that in some way. And there are lots of very, very interesting open problems

in how to set up such a marketplace. It actually touches on your earlier question about whether or not the prover is a point of centralization. And I think that once we have something like a decentralized marketplace for proving capacity, that will be a way of mitigating that problem. and you could have something like a zero knowledge roll up on top of Ethereum hook to a decentralized prover network, a marketplace of this kind, to always have some prover somewhere available to be

able to generate the proofs that it needs to be able to make progress and continue to work and to not have a single point of failure that might at any point make the system grind to a halt. All right. So now let's turn to a question that I think perennally comes up. whenever people talk about privacy, which has to do with crime. As I alluded to earlier, there have been a lot of crypto crimes that have been solved by the government or other investigators looking at these public blockchains. And I wondered if you thought the implementation of zero knowledge technology in crypto will make it harder to solve these types of crimes.

I think it may be worthwhile talking specifically about private transactions first. and then we can move on to talk about private computation. In particular, maybe we can address the whole issue with tornado cash, the fact that tornado cash was a protocol, an on-chain protocol, whose address was sanctioned by OFAC because of the fact that tornado cash was used to some extent by the Lassarist Group, which is associated with North Korea, to launder funds that had been stolen from another protocol. earlier in the year. Some of the work that Dan and other people on our team have done

tries to bridge the essentially toe the line and strike the right balance between maintaining the privacy of users while still preserving some ability to comply with laws and regulation. And one way to do that, and I think Dan can talk about this a little bit more as well, and we can dive into the tech details, is that you can use zero knowledge proofs to maintain users' privacy while still maintaining the ability to freeze any funds that are connected with any address

in a list that is provided externally. And that list could be the list of addresses that are sanctioned by OFAC. And so, for example, if Tornado Cash had implemented this as a solution, it could have been possible for all funds, as soon as the address, address as an address of the attacker gets added to the list, the OFAC list, which is, by the way,

broadcasted by chain analysis on chain, tornado cash could just freeze all funds associated without address without leaking anybody's privacy. And that alone is a powerful disincentive for the attacker to use tornado cash in the first place. Because there's always this risk. If I, as an attacker, use tornado cash to try to launder the funds that I have stolen, is very likely I will end up with my funds being frozen. So might as well not even charge. And so that could be one solution that simultaneously protects people's privacy and then also this incentivizes the incorrect criminal use of the protocol for uses that are not intended. And there are many other other ways that you can try to balance these two things and strike

different, strike the sort of different parts of regions of this tradeoff. And one of them could be to actually force the de-anonymization of funds that are on that address, which I think would be more, would give more. more power to the government and less power. Like the tradeoff there is that you as a user might at some point get de-anonomized. And that might be undesirable, but maybe that's better because it kind of aids law enforcement. So there's this whole spectrum and a slider that you can play with to try to essentially find the right balance and get to the right trade-off between protecting users' privacy and then also not encouraging illicit activity.

I don't know, Dan, do you want to elaborate? Yeah, yeah, actually, yeah, I think the examples that Ali gave are fantastic. So maybe generalizing this a little bit, I would say that, you know, on the one hand, there's this desire for privacy in the payment system, as we explained. There's all these applications and businesses needed and so on. On the other hand, there's a need to be compliant, right? If we're in the U.S. and we're using, you know, some technology to do payments, we have to comply with U.S. banking laws or U.S. payment laws and so on.

Yeah, there's compliance requirements. And so those two things, they seem like they're contradictory, right? On the one hand, there's, you know, we need privacy. And on the other hand, we need to be compliant. And so, you know, this is an example, a very common example in cryptography where we have seemingly contradictory requirements. How can you be compliant if everything is fully private? Where in fact, cryptography can resolve the conflict. Yeah. And so can resolve this contradiction. And so really the issue is just how do we design systems that provide privacy to, the end user, but are also at the same time compliant with local regulations. Yeah, and there are all sorts of designs. Lee gave a really good example there. There's like a whole bunch of designs that we can do. And so, you know, at the end of the day, this becomes kind of a covenant, kind of an interesting technical question.

You know, we can decide on what is the policy that we want to implement in the payments, in this, you know, blockchain-based payment system that would support both privacy and address the needs of law enforcement. And then we can go and design a system that seems to the best of our abilities satisfies both requirements. And again, Ali gave really good example of that. So in the case of tornado, I think you mentioned tornado cash or Lee mentioned tornado cash. The question is basically how do we build a compliant version of tornado cash?

Yeah. And it seems completely doable to do that. Yeah, we have the technology to do it. And, you know, fortunately, there are now four X of Tornado Cash that are starting to implement that. And it's going to be very interesting to see how that plays out. Yeah, one of them was privacy pools, which Amin Soleimani, who I feel like he's always sort of at the center of certain cutting edge or controversial uses for crypto and blockchain. He launched this tool and it uses ZK proofs to prove that a private transaction was not connected to criminal activity. or I think it's the sanctioned activity.

So, you know, that's definitely one of these examples. And it's a tornado cash fork that he used to do that. Yeah, it's a perfect application of zero knowledge proofs because it allows you to prove that you're not connected to a particular set of addresses whilst not revealing anything about who you are. So therefore, resolves this paradox, resolves the tradeoff. Yeah, and it lets people have that privacy that they seek. Maybe I can give you like a very concrete example.

just might help the listeners in that, you know that, for example, the travel rule in the U.S. requires the transactions over $10,000. They have to be, there's extra reporting requirement, required on those transactions. So you could ask, well, if I'm posting, say, encrypted transactions to the blockchain, how can anyone look and tell whether this is over $10,000 or under $10,000, right?

So they don't know whether the extra reporting applies to this transaction or not. Well, you can attach a zero-knowledge proof to that encrypted, transaction to say, well, this is an encryption of a particular transaction, and it's the amount being transferred to the less than $10,000, right? And that's a proof that you don't need to do any more recording that's relevant to that transaction. Yeah. And so that's a very simple and concrete example of how zero knowledge proofs can be used for complaint. Great example. All right. I feel like we've, I mean, we've covered quite a lot of things, but I've also left a number of questions on the cutting room floor due to time. But are there any specific?

topics that you feel we didn't discuss that we really should let the listeners know about? Oh my God. You know, we only scratched the surface, to be honest. This is such a big topic. We literally only scratched the surface. I would say, first of all, the canon is a really good resource. The zero knowledge canon. If your listeners want to learn more, I really would direct them to that list. It's a wonderful, wonderful resource. That's a great way to get started and learn more. In terms of topics that we haven't touched on, there are other applications of these proof systems, for example, for bridging between blockchains. This is actually an up-and-coming area where proof systems are going to play an important

role. And that's to improve security, I believe? Exactly, exactly. Bridge security has been a huge problem in crypto over the last 18 months or something like that. So I think it's something people would be interested in. Let's see. So I guess we have to explain a little bit what a bridge is, right?

So the problem is there are multiple blockchains out there. And let's say, let's say I own an NFT on one blockchain and I want to sell my NFT on a marketplace that's on another blockchain, right? Well, how do I need to move my NFT from one blockchain to another? Well, how do I move it? Yeah, and that's what, that's one thing. That's one application of a bridge where what I could do is I could kind of lock my NFT on one blockchain and have a wrapped asset released on the other blockchain. Then I can participate in the marketplace on the other blockchain. And then I can also move it in the opposite direction.

Yeah. So that's what bridges allow us to do. They allow us to move assets from one chain to another. What I just described is what's called a lock and mint bridge, which locks assets on one chain and then mint's corresponding tokens on the other chain. Yeah. Now, the issue is, how does the target chain know that the source chain actually locked the assets, right?

That's a pretty fundamental thing that the bridge has to implement correctly. If it releases tokens at the wrong time, well, that would result in a loss of assets. And so basically convincing one chain that something happened on another chain is a fundamental thing that a bridge has to do. And that's exactly where proof systems can help, right? Because what proof systems can do is, well, one chain can ask an off, you know, an off-chain server to produce a proof. that the state of consensus on that chain says that the assets were, in fact, locked. That proof could be presented to the other chain. And then the other chain says, oh, yeah, now I believe that the state of consensus on the source chain says that the asset was locked.

And therefore, it's okay to release tokens on the target chain. Yeah. So these proof systems allow you to prove the state of consensus from one chain to another. Or more abstractly, they allow one chain to send a message securely to another chain. And then the other chain can process that message accordingly. So that's kind of why these are up and coming in the bridging area. And there's a number of projects now that actually try to implement and deploy this. And that, by the way, is in contrast to the way that most bridges are implemented today,

which is that you require a trusted intermediary in the middle to essentially make that guarantee to the target chain. And of course, that often is the source of the problem. the fact that having a bridge that's actually secure is very difficult because that trusted intermediary could be hacked or they could be dishonest, they could censor, they could lie. So there are many ways in which a bridge that depends on a single trusted intermediary will not really work in the end, especially given that the amount of assets that can flow through a bridge can be very significant. And so there's a lot of interest in leveraging zero knowledge proves to make this a truly trustless process. So it's that you don't really have to trust anyone other than the consensus of the source chain, given that you have a proof that its consensus accurately converged on the state that you are receiving as a message.

All right. Yeah. There's just so many other things that we could have discussed. And for people who were interested in what we were talking about, I actually also strongly urge you to look at non-blockchain uses for ZK technology because that is a whole another rabbit hole that is all. Another rabbit hole that is also super fascinating. We'll probably just have to do more episodes on this because I think it's just going to become more widely used in our space. And there's going to be, I think, a lot of crossover with, you know, some of the other kind of things happening in tech. So, yeah, we'll just have to have you back or other people to talk about all this because there's so many developments. Well, it's been such a pleasure having both of you. Where can people learn more about each of you

and your work? Yeah, I'm really easy to find. My web page is at Stanford. So if you just Google my name, you'll find my web page right away. And then for us, we are at A16ZCrypto.com. And then also I'm on Twitter at Alive underscore Eath. Perfect. Well, thank you both for coming on the show. Thank you, Laura. Thank you, Laura.

This has been a lot of fun. Thank you so much. Thanks so much for joining us today. To learn more about Ali, Dan, and Zero Knowledge Technology, check out the show notes for this episode. Unchained is produced by me, Laura Shin, with up from Anthony Yun, Mark Murdoch, Matt Piltured, Zach Seward, Juan Arvanovich, Sam Shreiram, Ginny Hogan, Ben Munster, Jeff Benson, Leandro Camino, Pamma Jemdar, Shashonk, and CLK transcription. Thanks for listening.