New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Using Zero Knowledge Cryptography to Build Different Applications with Brian Retford

Ethereum DenverMon, Oct 9, 2023, 12:00 AM

Using Zero Knowledge Cryptography to Build Different Applications with Brian Retford

Transcript

hello everyone um I'm Brian Redford with risk zero and I'm here to talk about using zero knowledge cryptography to build more complicated and interesting applications so I'm gonna just do an intro of the company talk about clubs in particular so we're going to examine this idea of of building more complicated applications through the lens of a central limit order book and then I'll talk a bit about general purpose ZK Computing and and what a what we mean exactly by this idea of a ZK coprocessor and then we'll go over some uh data and take a look at what a club that's built using a ZK code processor looks like okay so risk zero if you're not familiar with the company we are on a mission to make using ZK as easy as possible and really utilize the technology to its maximum degree and we've done that by building um the first open source general purpose zkvm and we'll get into what all that means the companies mostly out of Seattle um yeah and we've known each other for for a long time and we use ZK Starks so our sort of core technological innovation is the risk zero ZK VM and this is similar to sort of a zke evm which takes in solidity code and executes that in an evm environment our ZK VM takes in code written in Rust C plus plus and now go and in the future we'll support as many languages as we possibly can and then we use standard compiler tool chains so llvm and GCC to compile this code down into an image that uses the risk 5 microarchitecture which you don't really have to worry about it's just a real micro architecture runs this code and produces a ZK receipt so it's a ZK VM that can execute arbitrary code so rather than say learning any number of specific uh sort of circuit compilation languages you can if you use a zero just write your sort of programs in Rust C plus plus use whatever libraries you want um and not really worry about the specifics of the ZK circuit so uh that's been open source for almost a year about as long as the company's been around and we are now here at East Denver launching a new service called bonsai which lets anybody use this ZK VM um in sorry somebody's waving back there distracted me um so yeah so Bonsai lets anybody use this general purpose ZK Computing platform in a way that posts the results on chain and lets you offload a bunch of your complex logic onto this network so I mentioned at the start that we're going to be considering uh building more complex applications through the lens of a club or a central limit order book so for people who aren't familiar with the clubs they I think the SEC introduced them about 20 years ago and they basically let people this is like your standard stock market system you place orders that you know you would like to buy something at a certain price and other people say they would like to sell things at a certain price and you end up with a sort of order book full of a bunch of you know desires for people to buy various things at various prices and then when there are matches you know the trades are executed so clubs handle the vast majority of worldwide trades so NASDAQ and other major stock exchanges I'll use this format so it's actually really impressive how far unit Swap and dexes have gotten and I'm sure you know they'll keep moving forward but um right the NASDAQ process is about 400 times as much volume as uniswap right now so clubs are generally considered one of the most fair and sort of Market efficient mechanisms for for doing you know trading and exchanging um and I would say at least in my opinion dydx is sort of the most prominent um semi blockchain example I'd say it's a semi blockchain example because of the sort of order book matching logic doesn't actually run on chain and if it did at least by their numbers it would be about a hundred times more expensive than uniswap so about 800 a trade when gas is pretty cheap so it's an interesting question I mean why are there no clubs on chain I guess it's kind of obvious that the gas is very expensive so when thinking about uh sort of the limitations of current chains and how ZK can can address them I thought it was useful to like take a look back and think about some of the obvious examples of um of where you know demand for Block space has gotten so high that it basically forces all normal users out and also you know wastes a lot of money and and I think really holds the ecosystem back um there's a sort of bizarre Dynamic where if your application becomes very successful the cost to use it rise and kind of acts as a natural buffer on the limits of what your application can achieve so I think this is a dynamic that you know on L1 on L2 anywhere like ideally we'd be able to get rid of and you wouldn't have these kind of uh ugolab type situations um I think it's important to look at unit swap costs about eight dollars a swap and goes through about a million dollars a day in gas fees all of which are you know not actually uh useful for the users themselves or uniswap um it's it's critical infrastructure in crypto obviously for Price Discovery but uh you know generally speaking clubs are like better at setting prices um so I think there's also like some recent examples uh I guess this happened two weeks ago apparently somebody told me was something to do with people dumping blur but temporarily you know you couldn't do anything uh unless you wanted to spend a lot of money to do it um this actually doesn't have anything to do with block space but I thought it was funny and um I'm actually really curious what happened to Solana two days ago so if anybody knows uh they could they could tell me later okay so looking at a club uh I don't want to get too far into the exact algorithms people use we'll look at a bit of the matching in a second but it effectively scales and end log n or polynomial time depending on how you implement it and what this means is that unlike uniswap where the sort of cost per transaction doesn't isn't really affected by volume in clubs the more orders you have the more orders you have to match um so the costs in terms of gas rapidly scale up to the point where you know at reasonable volume you're actually using up an entire ethereum block if you write your Club you know in solidity and run it totally on the evm so these are these are measurements from a club that we wrote uh that somebody very skilled in solidity wrote so we're pretty confident you know it's not possible to write a club that's more efficient than this on the evm so uh don't need to get into this too much but if you're curious why it's n log and it's really like M every new order has to be compared to all of the open orders which are generally stored in uh you know sort of binary tree or a Merkle tree so that's where you get these kinds of scaling numbers um yeah yeah cool so uh with all that in mind I want to talk a bit about uh general purpose ZK co-processing and what we mean by this and how it can help solve the sort of gas problems that uh that we were observing with these kinds of applications earlier [Music] so first I want to talk a little bit about just what ZK does in general because I don't know you know it's hard to tell how familiar people are or will be with any of this but uh this is sort of an example of how ZK at least in our system works um you have sort of a host program that runs ZK code which gets verified and produces a receipt which is a much smaller uh sort of it's a very fixed size blob that certifies that a particular program that you may or may not reveal when run with a particular set of inputs which you also um may or may not reveal produces a specific output so in this example you could imagine maybe running Doom in your zkvm guest and having the data from your host to actually be you know Mouse movements so you could effectively prove that a given Speed Run of Doom actually came from Doom source code without revealing actually how you did it so you'd have a sequence of mouse inputs that would be your sort of private data input the code is known it's the Doom source code you run it it produces a very small receipt that can be verified anywhere like one lens on VK so uh is this process of verification and this is pretty important so generating these proofs is very expensive um it's gotten progressively less expensive and I expect it to continue to get progressively less expensive but it's still like somewhere between five and ten orders of magnitude more expensive than um than not doing ZK however verifying these proofs is generally very cheap it can be very expensive on ethereum depending on which cryptographic system you're using um but we won't we won't get into that it's very important though that you can verify these things in constant time independent of how long of a program you're verifying um yeah this is just like a little graphic that explains how this works so this is an example of a of a risk zero example program from from our open source repository and it basically lets uh a user prove that they know the prime factors of uh of a large number without revealing those numbers this is a classic problem in cryptography is it's very difficult to factor uh very large numbers so you generally you know knowing the factors of a very large um number sort of is a way to prove you know a secret that can be used in various cryptographic operations like creating public and private key pairs um so yeah so this example really just reads in two inputs that are kind of hidden from from the user and then commits to this journal the output which is in this case um I think 391 so if the user passes in these two numbers they can effectively prove you know that so tell someone else uh here is like 391 and I know the factors for that now obviously factoring 391 is not hard however if you start using you know 256 bit integers then then you start to get the kind of cryptographic security that you would expect so this is just like a simple example of how you can use ZK to prove um private knowledge uh yeah without revealing that private knowledge there's another example and this is starting to get into where I think uh what we're doing really shines and that's this is actually all the code you need to prove without a given chess board that's serialized in a standard uh sort of Chess format contains a Checkmate without actually revealing what that move is so this is uh utilizes The Shack committee rust library to basically do all the complicated sort of Chess logic and you can basically create these kinds of ZK proofs from existing libraries uh very very trivial trivially so hopefully this provides some whatever lens on uh sort of what ZK is and what ZK VMS can do foreign the other system that I mentioned which is kind of the focus of the company right now I mean we're always focused on improving the zkvm but this is what we're actually launching here at East Denver and it's basically a mechanism whereby you can write the parts of your application that focus on on-chain assets in solidity exactly as you normally would but then you can write the sort of code that actually does complex things like order book matching or running a game engine or doing a lot of data processing off chain and there are a couple other projects uh doing really cool stuff in this space like Axiom they have a quite different approach from us but nonetheless I think this is going to be a modality that we start to see become a lot more prevalent which is compute doesn't necessarily need to happen on chain because it's not necessarily what chains are good at chains are good at moving assets around um so Bonsai has sort of the Machinery involved such that if you were to you know interact with an application on chain it will eventually trigger the execution of this uh ZK image and uh prove it and then we'll spit this output into something we call a universal roll up a universal roll up is basically a summary proof of a ton of stateless computation excuse me um so in this case the state actually lives in ethereum the state kind of gets transited into the zkvm IT produces this proof and then this gets rolled up to a single proof so this lets every user of the system effectively share the costs of proving verifying the one proof across pretty much every chain Our intention is to uh like publish these proofs to every single chain uh we're very focused initially on the ethereum ecosystem so this is uh this is like the weirdest thing about zk's uh or at least kind of blew my mind when I realized this was possible so in order to do this sort of universal roll up because the idea is is to be able to process you know not a hundred or a thousand transactions uh per block but millions or even billions of transactions per block and the magic that lets you do that is this idea of recursive proofs and recursive proofs uh some people call this proof aggregation and there are a lot of different techniques for doing this but this is really the sort of magic that makes ZK Roll-Ups Roll-Ups and basically if you have two proofs you can run the verification of those proofs inside the ZK system and it spits out one proof that effectively attests to both of those proofs so you can compress two proofs into one proof so as soon as you can compress two proofs into one proof you can compress an arbitrary number of proofs into one proof um well I mean that doesn't necessarily follow but the math in this case works out so you can actually do this um so when we're thinking about a system like like Bonsai the main sort of thing that limits the throughput and thus sort of the cost efficiency and also you know the complexity of applications people can ultimately build on it is really this recursion time so this is the amount of time it actually takes to take two proofs and turn them into one is one way to think about it it could be three proofs four proofs five proofs whatever it's kind of gets into the specifics of the machine it's running on on what makes sense so we've spent a lot of time like heavily optimizing the recursion time because it fundamentally tells you how many computations you can fit into the next block or say uh you know with three blocks latency you can almost certainly fit a million proofs into a single rolled up proof but if you're talking about like a four second turnaround time you can only uh you know fit as many proofs into that four seconds as you can uh you know reduce to a single proof in four seconds so uh right now I think we're still about 10 seconds per recursion but it'll be like two pretty soon and we expect that you know inside the year it will be down to like 100 milliseconds which is enough time to get you know just really start including millions of sort of computations um in a sort of single state route there's gonna be a bunch of decentralized sort of marketplace uh aspects to this but we're not really focusing on that today so I did mention you know earlier that maybe one would want to like run Doom inside the inside the guest and then provided some examples some pretty simple and trivial examples of of code running inside the ZK VM and um you know since we released it it's it's continually gotten more mature but it's not it's still like a very you know simple processor I guess in terms of its capabilities so the way we think about it right now is that it's kind of like a fancy Arduino it can address more memory but it's really runs at about 20 kilohertz um on your laptop uh we do have GPU acceleration um although there's a bit more work to do to really get more than the sort of two to five x we see now but we do expect um yeah in the next couple months to get to a point where uh the GPU acceleration gets you a lot closer to a megahertz than than 20 kilohertz um beyond that once we sort of have this fast recursion uh people call this like incrementally verifiable computation we call it continuations but this idea that you can split a computation the proving of a computation up into a bunch of parts prove them independently and then use recursion to combine them this actually lets you run arbitrarily complex computations in a ZK context so thinking about like proving that that this particular Linux kernel binary came from compiling uh all of the Linux source code with certain hashes with a compiler that has to do a certain thing these kinds of very I would say kind of out there ZK use cases will become possible and we'll also be introducing the like ability to address more memory sort of shortly moving into later this year we expect to support like two gigs of RAM and we'll open up our accelerator DSL language which is sort of like Noir or like Leo except it's really focused on building um accelerators that get attached to this general purpose chip so the the kinds of things that you're going to be able to do with Bonsai are going to continue to increase however I will say even a fancy Arduino is enough to run a club in a really interesting manner so I'm going to talk about Club Bonsai which is a a club implemented on top of bonsai so going back to this uh sort of chart explaining how Bonsai Works in this case the club contract which exists in solidity is the ethereum application this is basically the application that lets people submit orders and you know that effectively settles their transactions in this case the orders sort of flow through the Bonsai system into the zkvm where the order matching logic runs and that is actually like 1200 lines of rust um I think the 1200 includes tests um yeah so so doing this um and then the matches flow back to ethereum everything settles on chain so what does this actually do to your costs for running a club well uh based on our measurements it uh it's basically a hundred times cheaper to do things this way uh than using the sort of pure evm club which actually puts um puts sort of on ethereum Club into the you know realm of feasibility to the point where it's actually probably cheaper than uniswap to actually do trades on a club implemented this way and you get a write your code in Rust which not everybody you know loves but you can use uh other languages as well we'll support solidity eventually too but um I guess we're all rest heads so uh one way to think about this in terms of costs is the club that's written purely for the evm uh effectively one percent of the cost of it it was involved in settlement in like 99 of it is uh running the sort of matching engine but the matching engine you know doesn't need to be run on chain it can be run off chain in this kind of ZK co-processing modality um and and that really shrinks the cost of your system to you know 50 to 100x in this particular case um and that's that's assuming well fairly healthy margins for the ZK co-processing systems um but yeah especially as um I think ZK is on like a Moore's Law curve itself beyond the sort of Moore's Law curve of the underlying Hardware that it's on that combined with the sort of amazing work like ingenyama and Overton is doing an accelerating ZK there are many other projects out there I expect the capabilities of what you can do with these kinds of co-processing systems to just continually expand and sort of Drive the the costs of co-processing down even further uh which will really increase the kinds of things you can build to the point where you really could uh run you know Doom effectively uh in a on-chain provable manner via ZK co-processing so we have a bunch of examples uh of the ZK VM stuff I think we have like 20 now uh there's some really fun ones uh including proving that you know where Waldo is in an image and clipping it out without revealing where Waldo is um and then we have for for Bonsai we have a way to build applications like this one in a purely local manner it spins up um yeah like a evm chain and all the necessary sort of components to actually develop these applications the actual Network you can sign up for Early Access now if you want we're hoping I think we just started onboarding people today um yeah and it's a it's a way to experiment with building uh far more complex applications than you've been able to build in the past without needing to migrate to a different chain so in the sort of dydx you know example they moved to their own Cosmos chain and are still running all their order book logic effectively off chain um and this is a way to to kind of embrace the yeah the the potential of of running everything on chain without having to make all of the compromises that people have had to make um yeah about four minutes left so I could do questions if people have any where I can talk a little bit about some other cool things you can do uh with the zkbm yeah ah uh take a picture of the QR code or go to r0.link slash bonsai the question is where you sign up so that should be kind of obvious cool uh well if there are no other questions um I'll be hanging out here for a bit if people want to just chat with me later but I do want to talk about um some cool things you can do uh that I expect people to start doing with ZK in the future um so one of them that I talk about a lot but still haven't gotten around to doing is the idea of like a ZK generative nft so what this looks like is an nft where potentially the code that generates the art is private um so it's kind of like uncopyable in a sense because you can prove that you own the code that generates it the code that generates it could be like in a secure Enclave uh you know buried under thermite I don't know anything you want um but you can actually by utilizing uh sort of ZK at scale build really interesting new kinds of artworks that that are effectively uncopyable um I'm really really excited about private strategy games so if people paid attention to any of this Matchbox Labs recently released a new version of the Xerox Monaco game which I managed to misspell um called Battle of the Titans and this game is sort of like Mario Kart where where the where the carts abilities sort of exist based on like a weird Marketplace so they basically invited a bunch of teams to write strategies that would run for you know 100 or a thousand turns privately and sort of determine what cars did at every step so if you have like five cars racing each other each of the teams you know submits their strategy and they had constraints on how much gas the strategy could use things like that and they're run privately so people basically can compete to see if they can you know create the best strategy without revealing um what they're doing now Matchbox didn't do this uh with ZK for the last version they just told people to trust them which you know you can trust them but it's not gonna like enable these kinds of games to take off um at scale until you can really prove that your strategies uh ran in the way that you committed to running them without uh you know without trusting uh some randos so I'm really excited about the ability to build new kinds of games like this and there are actually a couple people working on things in this realm um yeah with us right now all right I have a minute left um so you could imagine at the limit you know building uh robots for for Doom and doing uh similar things to this so I don't know where any of that is actually going but it's it's really amusing to me that it's a possibility um yeah thanks and uh yeah we're having a developer meet up later tonight I think it's fairly sold out but um yeah if people really want to come let me know thank you

Automatic transcript — names and jargon may be misspelled.