Zero Knowledge Virtual Machines Running Rust code inside a Zero Knowledge Proof - Jeremy Bruestle
Ethereum Denver·Mon, Oct 9, 2023, 12:00 AM
Zero Knowledge Proofs have a lot of promise for both increasing privacy and scaling by verifying the correctness of off-chain computation. However, the development of traditional circuit based ZKPs is challenging, since the programmer needs to learn new languages, new concepts, and new development tooling. A new class of Zero Knowledge Virtual Machines is attempting to allow ordinary code, such as Solidity or Rust to run inside ZKPs. This talk will describe how such ZKVMs work, including a basic background on ZKPs, arithmetic circuits, permutation arguments, and representations of memory, as well as providing resources for getting started using ZKVMs to implement off chain logic. https://twitter.com/BruestleJeremy Jeremy Bruestle Chief Scientist RISC Zero Jeremy Bruestle is a computer scientist and entrepreneur based in Seattle, WA, specializing in the applications of emgerging research and mathematics to practical problems. His past areas of focus have included cryptograph, computer security, mesh networking, computational biology, and machine learning. More recently, he has been working on the implementation of general purpose Zero Knowledge Proof systems, and in 2021 he co-founded RISC Zero, where he currently serves as Chief Scientist.
Transcript
[Music] foreign thank you foreign [Music] foreign hello everybody uh my name is Jeremy brustel and I am the chief scientist at risk zero and today I'm going to be telling you guys all about how you can use zero knowledge VMS to run arbitrary code including rust code for example inside a zero knowledge proof uh so I'm just gonna get started on that uh so just you know as a rough piece of background what are zero knowledge proofs well they allow you to prove that a statement like say for example you know this chest position has Checkmate one move uh you can prove that that's true to someone and you can which is called soundness and you can also do so without revealing all of the information necessary to do that computation so for example you can say well I'm not going to tell you what the move is that leads to Checkmate but there is one uh which is called which is the zero knowledge property that zero knowledge crews are named after and then finally you can do that in a way which is uh doesn't require the person checking the proof to actually do all the computation so the the verifier can run much faster than the prover uh this is called succinctness and why is that relevant well I mean obviously the zero knowledge part is hugely important for uh privacy and because you can now trust some third party to correctly execute code and you can check their work faster than they took them to do it that turns out to have lots of important applications for scalability in terms of blockchains um so I won't go into too much more detail on that uh but I think lots of people have seen sort of the emergence of zero knowledge proofs and how useful they are um so I wanted to talk a little bit about how you actually write a zero knowledge proof how do you program them so at the underlying mathematical level there's this whole process by which you translate like a human understandable statement like this position has you know Checkmate in one move into a system of polynomial constraints over finite field Elements which you know may not be the most programmer friendly way to represent things right so there's been work to try to make it easier on programs first so the the first option in terms of how you could actually uh you know make a zero knowledge proof is to actually go and write the arithmetic circuits yourself you know this has an advantage of being the lowest level giving you the most control the best performance but effectively you have to learn an entirely new syntax it's also not really programming in the traditional sense it's more like building a circuit like uh it's more like Hardware design there's no Loops you know you there and you have to also understand all the details of the math you need to know what a finite field is you need to know what polynomial constraints are this for example here is some code that actually just to either switches the order of two values based on uh whether another value is zero or one and you know it's not super self-evident um the other option is that you can make a high level language that then compiles down to a circuit this is what some people like Elio for example do uh it's a lot easier it's much more like normal programming um but you still need to learn a new language uh you still do need to understand the basics of some of the math under the hood and it has very limited sort of control flow you can't generally for example do a loop over you know some number of elements that where the number of elements isn't known when you build the circuit and you can see for example here's a example from the ailial examples of a tic-tac-toe prover and you can see that all of the logic has been totally unrolled because of this sort of limitation with regard to Loops so again you know useful and for many cases totally sufficient uh and it gives you a fair amount of control but probably not the best option so this idea has come up of there's a zero knowledge virtual machines which is what if you wrote one circuit that actually acted like a little VM and so now one person's in charge of making this complicated arithmetic circuit thing but then everyone else can just use it and you can run different programs on the same circuit by just taking your code compiling it down into some representation that the circuit understands and then having the circuit sort of execute your code right so this is this idea of azure knowledge virtual machine and oops uh hold on just the right yeah so the question is what if you oh yeah I'm sorry this is right so once you have a zkvm uh that gives you a bunch of advantages so when you have a zkvm now you can actually run general purpose code you can have control flow you can have loops you can have RAM and you can treat it like writing normal code um and one thing you can do is you can then make a custom zero knowledge virtual machine with a custom language on it which is what say uh you know Stark net is with Cairo and um so it's a much better programming environment than something that has to compile to a circuit but it still has issues because you still have to learn a new syntax and you still have to use understand finite fields and also you know you're limited to what every time you make a new language you start over in terms of ecosystem in terms of libraries in terms of you know support for um existing stuff so what if we instead made a zero knowledge virtual machine that could run actual ordinary existing code that already exists we don't make a new language we want to build something that can run something you would already use okay and actually that's exactly the idea behind all of the sort of ZK EVMS that are out there right now uh and so the theory behind this is well everyone writes in solidity so if we make a virtual machine that's zero knowledge virtual machine that can run that solidity code that can run evm op codes then suddenly you don't have to rewrite all these things you can actually just make zero knowledge proofs of existing code and that's super cool and there's a ton of really cool projects out there doing this um I I mean there's more than would fit on my list here and so I won't I'm not gonna there's a lot of good work being done there um so you know at risk zero we wanted to actually say well what if you wanted to run non-evm code what if you wanted to just run some Rust code or some C plus or some go or a really traditional language um which is great because all those languages have really huge ecosystems and so that's our idea is to basically make a ZK VM that allows you to run code in a normal language that you know lots of programmers already use in our case we focused on Rust as our primary sort of most well supported mechanism and what's cool about here is that not only does this code look just like ordinary code you can run any kind of thing you could do in Rust there's no limitations in terms of I mean besides the fact that it runs slower because it's in a zero knowledge proof system um and it also allows you to leverage all of the huge existing ecosystem that these languages have right so for example uh if you want to prove this thing about Chess positions I was talking about earlier you don't have to rewrite the rules of Chess in this in a new language you don't have to do any of that work because someone has already written a chess library that can in fact knows all the rules of Chess that can process whether a move is in fact you know a Checkmate or not whatever so so that allows you to really quickly develop new uh new code uh in a zero knowledge proof and you can still get all the zero knowledge properties right so I think that sort of ZK VMS in general are kind of where uh you know zero knowledge is moving there are still use cases where it makes sense to go hand write a circuit but I think for the vast majority of use cases you're going to see these sort of ZK VMS and including ZK EVMS um as something that's moving forward so just to go into a little bit of details of sort of what this looks like um and the workflow would be you know similar for an evm uh basically you start off with rust code and in our case you actually compile it down to a risk five executable risk five is just a type of processor like an Intel processor or um you know an arm processor we chose risk five as the thing to write our VM in in part because the risk 5 processor is uh has a very small instruction set so it lends itself to a very fast and small VM which is important because you know we have to fit it inside of a zero knowledge circuit so you basically compile the code down you get a image and then you basically hand that binary effectively to the actual zero knowledge virtual machine which then actually executes that program inside the VM and then what that does is that results in a your knowledge proof that you can then show someone then allow them to verify that you correctly executed that code from that particular binary so it allows you to basically prove arbitrary things to people in a very sort of uh developer friendly sort of manner right so uh I think this is a super useful fundamental technology and you know we currently have open sourced our entire approver our verifier the GPU acceleration for all of these things so this is something that you can actually use right now to do this actual zero knowledge proof process uh so but one question is so that's great it's really cool that you can make zero launch produce but how do you actually get these zero knowledge proofs on chain right and I think that if you look at sort of the use of your knowledge proofs across the industry there's lots of different ways that people have uh done this and basically we are here introducing we just introducing this new technology which is called Bonsai which is basically a way to help make it easier to interact with your knowledge proofs across multiple blockchains and so this is something that we we just announced so what exactly is Bonsai it's basically a way to allow you to run arbitrary zero knowledge proofs and to get those proofs on chain and to make it easier to build on-chain apps that take advantage of the capacity for zero knowledge proofs um and so to explain a little bit how that works um you know if you say wanted to have an ethereum you know uh smart contract that wants to do offload some compute let's say you're doing a you know something complicated like order matching and you paid costs a lot of gas to do all the order matching so you'd like to move all the computational complexity off chain to his inner knowledge for compute and then just verify that you did in fact do the proper order matching on chain so how would you do that so the idea is is that we for each chain we integrate with we provide this on-chain proxy contract you basically send to the proxy contract this is the thing I would this is the program I would like you to execute please go execute this prove it and are basically we have a we'll we'll watch the chain we'll see that this was done we'll go to our uh the Bonsai proving Network there it will be proven inside of the xenology proof system and then we basically roll up all of these proofs into a single uh Master proof which we then post back onto chain and verify on chain and so all that verification mechanism is done by all of our on-chain proxy contract so at the end of the day in terms of how you would actually use this in practice you basically just ask the proxy contract to prove something and then sometime later the proxy contract says Hey I've proven it and now you can basically move a huge amount of your you know compute heavy logic off chain and moreover you can write logic that is a easier to represent in normal languages so if you have something like you know a game physics engine or something else that might be awkward to write in solidity or wants to use make use of existing rust or C plus code for example you can do that in a really useful way so and what exactly how does this all actually work um so the idea is that when you make a proof there's an initial proof request and that proof request goes to the uh proving Marketplace uh where basically there are approvers that run uh and that produce the proofs now the nice thing about generalized proofs is we don't have to trust the people who are making the zero knowledge proofs because if they make a bad zero knowledge proof the verifier will fail to verify which means that it's actually easy to make an Open Marketplace for people to do proofs um and then that those proofs then also need to be rolled up uh which is basically this mechanism using uh recursion which is a way in which you can use a zero knowledge proof to run the verifier inside the prover so that you can prove that two proofs are correct in one proof uh it's a very fun fun little trick and this is also many other zero knowledge proof systems are using the same mechanism for recursion and then what we do is we then take that resulting root proof that we generate and we actually posted across any sort of chains that we integrate with and of course ethereum is you know sort of our uh you know main initial Target but we're looking to support other chains as well and so the idea would be that you would be able to verify these proofs on multiple chains now once it's once that proof has landed on the Chain then your RR app our um proxy contract can let you verify your specific proof that you care about is in this sort of rolled up proof by doing a miracle inclusion proof on chain um so if you want to check any of this stuff out uh we have the uh sign up link for Early Access to uh Bonsai which will allow you to uh get into our sort of uh program for Alpha users so that you can uh start experimenting with Bonsai uh the existing zero knowledge VM itself uh is actually already you know ready to go uh it is uh open source and available at our GitHub as well as sort of the developer starter template for Bonsai so you can kind of see what's going on with that we also uh have a Early Access program for other for General Uses if you want to do some kind of crazy thing with the ckvm um but it looks like I'm actually running a couple minutes early apparently so I would like to take some questions from the audience if anyone has any questions um sorry uh could you just go over like the performance impacts of running these this code inside of a VM hello uh yeah absolutely uh so the question was what sort of performance impacts are there in terms of running these sort of things inside of a zero knowledge VM um so of course zero knowledge proofs uh do take a lot more computational work than just running something directly uh currently our zkvm runs at about 50 000 instructions per second uh which means you can run you know reasonable and non-trivial things inside the zkvm and prove them uh additionally we are adding support in the near future for a mechanism called continuations that allows us to parallelize the proving process across basically as many nodes as you want and so we should be able to achieve uh performance in terms of compute per second as as large as you would like if you're willing to pay for it effectively and also we do intent we do ex our continually making improvements in sort of the base uh oh by the way when I say 50 000 cycles per second I mean on my M1 Macbook so just to clarify what Hardware that involves uh probably a lot faster on a fast GPU but I don't actually have the latest numbers for that uh we're continuing to improve the performance on that um although I would you know it is expensive effectively are there code size limitations I can imagine if you can import all the libraries you want that might be a problem uh so the question was are there code size limitations and the answer is uh currently the ZK VM uh has a maximum memory uh size of 256 megabytes so as long as the program you are compiling down and running fits within we typically Reserve half of that for code and half of that for data so you know if you fit in 64 Megs or 128 Megs or such you should be good which all many many things do uh we are working on a new version of the circuit which probably is a good couple months away where we'll actually go up to the full four gigabytes of addressable memory um so I'm excited about that but that'll be a bit other plans to support other instruction sets like double lvm uh so the question was are we going to support other instruction sets uh so I think you mentioned llvm is that correct yeah so llvm actually already compiles down to risk five so if you have something that can back into lvm you are good to go in um in fact actually I I believe one of the projects we're going to start looking at at some point is actually there's a solidity to llvm uh translations so we might look into that as a way to run solidity code in these things um but uh in general there are you know we are looking at lots of other ways to transcode different kinds of use cases to this system but yeah yeah I've noticed that you guys are doing something like a benchmark testing could you give us some sense on that uh yeah so we have been participating in some benchmarks um you know I I don't actually have the URL to them but I believe if you go on to the some of the things you'll be able to find them uh the short version is I think we've compared very favorably I think we come to other uh sort of dkvm proof systems um we the benchmarks include things like comparing how many Shaw hashes you can do per unit time um some other general purpose Computing use cases um things like that uh but I think that we we are very interested in being very transparent about all of the performance and we actually are very strongly encouraging other people in the ZK ecosystem to start to try to consolidate and uh actually have more comparable benchmarks across more proof systems because we think I mean personally if I didn't know a huge amount already about zero knowledge proof systems and I went out into the ecosystem to look around about which sort of you know prover to use and how to do things I actually think it's quite confusing and hard to compare systems out there right now so we really strongly believe that the industry needs to sort of be uh more transparent and uniform in terms of how it reports benchmarks so I think I'm almost out of time too but in your career Network are you also Distributing verification are there verifiers that are separate from the party that's submitting the compute request I'm sorry yeah yeah so the question was uh what sort of are the people in the network who do proving the same as the people who do verifying and how do you uh make sure that the verifiers are are not dishonest and basically the short version is that um one of the wonderful things about zero knowledge proofs is that uh you can verify an arbitrarily large amount of proofs with a single verification using recursion and when we talk about when we post this to ethereum we actually run the verifier or or will be running with the sort of bonsai release We Run The verifier inside the ethereum evm and so presuming you trust the you know uh ethereum evm which if you don't we got bigger problems the uh the the short version is that you can trust that the verifier was honest and as long as you know the verifier is honest everything else follows from the mathematical properties of zero knowledge proofs all right well I think I'm out of time so thank you everyone uh and have a great day foreign [Music]
Automatic transcript — names and jargon may be misspelled.