Programmable Zero Knowledge with Aleo - Howard Wu

all right up next we have howard all right welcome to the live stream howard we've got some zero knowledge going on is that what we're gonna discuss today yeah oh yeah and first i just want to say thank you for having me on here i'm very excited to be here excellent it's our privilege all right take it away all right so uh let's get started um so i'm howard and um today i want to talk a little bit about some of the technology that we're building at leo as a as a high level overview first i want to just say this has been a project that we've been working on for many years now it actually started off as a research project about four years ago and at the time with my co-authors we were looking at the blockchain ecosystem and evaluating the technology out there um there was really two verticals to evaluate on um you know we found that there's programmability and privacy um as most of you know bitcoin is quite low on both um ethereum had went one direction to offer high programmability and zcash went the other to offer high privacy but there was this upper right hand quadrant of high programmability and high privacy where um there just wasn't a solution available and there wasn't for you know a lack of trying you know people people were definitely coming up with different approaches but they all made different trade-offs whether it be using trusted hardware um or potentially um having uh large large compromises on crypto economic security and um because of that uh you know we kind of set out for ourselves to say could we devise a protocol that could be not only offer high privacy and hypergrammability but have uh minimal trust assumptions primarily just on basically pure math and uh what we've built is actually a system which hopefully will create some intrigue that um you know allows for effectively zero gas fees as a requirement and also unlimited application run times and i'll get into a little bit more on that in just a second um but uh you know with that work that we did we basically designed a new system called sexy it actually stands for zero knowledge executions and it is a new model for doing decentralized computations fundamentally um zexi can be broken down into three parts there is the setup the prover and the verifier and with the setup it's a one-time setup in this case a universal setup and what that means is that at the genesis of a system like this um all participants the ideas have everybody as as part of just getting the system up and running participate in an mpc that will then create entropy or randomness that is then used to seed a proven key and verification key for every application in the system from there provers execute the application and provers are naturally motivated in the sense that they um they take in some program they take in these proving keys and they provide and produce a state transition and lastly this then gets bundled into something uh something called the zero knowledge proof which verifiers can quickly check um and one thing that i want to call out is with a system like this just as bitcoin can't run the evm um you know ethereum can't execute sexy or to the extent that people have have tried to bake it in you know it's really hard to get all the benefits of a system like this on it on on ethereum and so because of that we've designed a new system called alio which introduces zero knowledge executions for decentralized systems and the way that we we think about it or like to think about it is to break it into three parts there's write run and deploy and for application developers the idea is to start in this programming language that we've been working on called leo leo looks and feels a lot like javascript or typescript and under the hood what what it actually does is it will compile that down into something called a zero knowledge circuit a zero knowledge circuit itself is effectively a representation of that high-level program that the developer defined um and it comes with these proving keys and verification key that is then used for execution so once the developers run their application um they can then ship it off to provers and provers as i had just mentioned you know their their job is to take in this code along with some input and execute a state transition which is then encapsulated into a transaction um that transaction is then broadcast to an open network in this case you know blockchain which can be quickly verified um because the transaction itself is represented with a zero knowledge proof um we actually get transactions that are constant time and constant size which is which is quite uh remarkable but also convenience for many reasons and and i'd like to talk a little bit about the properties of this now um so first with a system like this um we've built something that's that's really good for speed and what i mean by that is this model uh allows for applications to run once and once only um there's no minor re-execution unlike existing smart contract platforms which have to re-execute every single state transition you know for for the remainder of time to verify the integrity of the ledger um and because of uh every transaction itself it's very it's very concise it's constant time and constant size to check um we can then pack a lot of transactions into blocks and and and just by virtue of that we can have a very high throughput the second point to make about it is that with a design like this um it really creates a system for integrity um you know unlike existing existing solutions where there are trade-offs on crypto economic security um has no compromise on compute on on computation computational integrity the idea is that instead of having crypto economic security you have cryptographic security and more so because of the design of off-chain executions in this model um users actually get to control their data they get to own their logic and we don't compromise on that um and because every transaction then is private um this allows for effectively zero mev so in the mempool um you know miners have no advantage other than by random chance to try to game a system like this and i think that this is something that is very valuable for d5 protocols that are coming out today but the last point to really call out is just this idea of scale um you know in in canonical uh layer one thinking um scale is usually about tps and this is where i'd like to try to call out something that's a little bit different which is to say scalability in the runtime of an application you know on on existing smart contract platforms um everyone has to time share a global computer and because of that everybody is fighting or competing to you know effectively get this 100 millisecond runtime of their application and and by just just just buy that property alone it really limits the flexibility or expressivity of applications that you can run um with a model like this applications can run off chain verifiably and so because of that we get unlimited application run times what i mean by that is instead of being bounded by that hundred milliseconds um you can now run an application that takes you know a second maybe a minute an hour half a day you know you name it and because everything is represented as a zero knowledge proof here um those transactions themselves still are very succinct uh about a kilobyte in size um and so because of that this allows for far more expressivity in applications and that lets you do things that you know just aren't possible on existing systems you know for example people talk all the time about you know having bonding curves and bond curves usually have to be hard coded and fixed but what if for example we could have a dynamic bonding curve be a linear regression you know you take the last hundred trades um you uh you plot them and then you basically do regression to find the tangent for where the bonding curve should lie you know there's there's far more applications which take multiple seconds in this case to run that just simply aren't gas efficient and so because of because of this this design we're able to support new types of applications or and certainly take defining in directions that just don't exist currently but one thing that i really want to call especially as a workshop is that you know we've been working on a product called heliostudio which is an ide um for writing zero knowledge applications and the alias studio itself is a batteries included one-stop shop solution for writing these types of applications that i'm describing it has leo baked in we're currently working on getting a package manager built into it and also getting like clients integrated into it and i'd like to to show you alias studio first hand now to give you a taste for an example application and to walk you through how it how it works so over here is ailer studio it's open and i have a simple roulette example in front of us in this example i want to call out this function the main function for every leo application the main function is the entry point in and it takes as input user-defined parameters oops sorry about that it takes as input user-defined parameters and it outputs user-defined state in this case because the application is roulette let's walk through how this executes we start by defining a struct called roulette and you can see there's a roulette.leo here which itself encodes some logic we will get to in a second going back to this main function um this initializes the roulette table could you increase the text size for us so we can read yeah absolutely excellent thank you very much uh maybe one more yep awesome um so we start by initializing a roulette table um and the next step here is uh because this is a round of roulette for a specific player we want to encode the player into this round and so we take the player's address which is passed in as input and convert it to bytes so that we have this participant encoded in bytes and next we take the round parameters so there is a round number that's passed in in this case this is the the round of roulette that we're playing so maybe it's the fifth spin of the wheel or the 20th spin of the wheel um that's this number we also encode the player again as well in here along with the bet the specific bet that the player's making and a bet amount and these are things that we're then using in an encode function and if i scroll up here you can see that all i'm really doing is actually just encoding um these into byte arrays so we we return effectively just arrays of bytes and the reason for this as you'll see in this next step is that we're going to use it to evaluate so once once we've encoded this data into these two variables which we call the seed and the data we then start to use this and so we pass this into an evaluate function which in this case calls blake to us the idea as as many of you have probably seen is that verifiable randomness in decentralized applications is very difficult to achieve um natively and certainly there's been many attempts at getting random beacons up and and certainly vrf services that are through oracles in this case because everything is executing in azure knowledge proof we have verifiability for free effectively and what we need now is a good randomness and so we're using in this case a pseudorandom function like 2s to evaluate on the seed and data some output this output we call a digest and in this case we encode it as a variable called round hash so now that we have this round hash which represents this state the the deter the deterministic verifiable randomness state for this roulette spin we can now pass it in along with the bad data and um and now now let's go back to that roulette struct to see how the spin works so if i open up roulette.leo you can see here that we have this spin function which takes us input the round hash the bet the bet type and the bet amount the first thing we want to do is use the round hash to determine where the ball landed on the wheel and so it's a simple operation where we basically just encode it and check to see out of 37 for european roulette what the number is once we have the number we do a console.log which i'll talk a little bit more about in a second um but this allows us to print out where we've landed on the wheel um so this will say we landed on some number and the next step of course is to figure out did we win anything from this right so we made a bet we want to know whether this is a winning bet and so this is some logic to check for the different cases and up here in the comments i actually just quickly made a note of the four different types of betting styles that that this example gives which is um to bet on on a modulus to bet on uh zero basically to bet on a specific number to bet on on a dozen or to bet that 18s and so um this this logic here basically checks um you know whether you've won and once you have that the next step is to say if you did win you know what is the expected payout and so of course with with with a roulette table there are different payouts for different types of bets some are two to one some are 36 to one some are three to one you know true one and in this case we can calculate um what that payout would look like and so we return basically a variable which which is a boolean that says whether you want or not in addition it returns the payout which is you know how much you want if you did win and so if we go back to our main function again we can see that that spin outputs basically is winner and amount and now we want to print the result so the first thing to check is did we win if we did let's print out this amount that came out of that spin and say you want this amount of tokens and encode that into the outcome or if you lost then we want to return the bet amount not the you know not the payout amount but the bet amount in this case and and encode that into the outcome and finally we have this return method which will now return uh the round number plus one since we've now spun the wheel one more time um along with the player's data um whether they won or not and that outcome and so with that i want to run this main function so you can see it in action for yourself so i'm going to hit this play button up here in the right hand corner and if you just give it a second it will effectively execute and you can see here it says compiling the main program it landed on 13 um you won 36 tokens and complete now you may be wondering you know where did this 13 come from and why did we win 36 so this gets into a concept of input and output state so remember that i had mentioned here with the main function that there are inputs we take in um and execute the state transition on which are then encoded into the output so where does this input state come from well in the zaxi model everything is encoded in something called records so records define the state the payload effectively of that application and those records are executing in the state transition that you're seeing here if we go to the inputs folder here you can see that there's actually some some there's two files here there's roulette.in and roulette.

state roulette.in is actually this input file which is an encoding of the payload in the in that record and in this case the record has with it the round number which is 15 the player and this is their address the bet was on the number 13 the bet type was one which means they're actually betting on the number one and the amount that they were betting was also one and so with that um the reason why this result was that you won 36 tokens is because you landed on 13 you had chosen 13 and because you had bet on that specific number it's a 36 to 1 payout and so you won 36 tokens that's the idea um one other thing that i want to call out which is which is i think quite quite interesting or unique is this idea of unit tests and integration tests um you know unlike other other uh dsls that we've seen out there um we have yet to see a really good framework from other dsls for effectively writing zero knowledge applications with testing and so we've we've made unit testing a huge priority in this language and actually in this case we have a test roulette function that looks very similar to this main function and the point being um is to highlight that it can replicate the same type of logic that a main function can in the language natively um unlike the main function though the final output is a little bit different instead of returning the outcome we're actually doing some assertion checks in this case console.assert on the winner and console.cert on the amount and so i'm going to run this for it for y'all so you can see the test case and as it's executing i also want to just discuss a little bit about this idea of console so as you can see the console has said the winner case here is true the amount is 36 and it also is correct and therefore the test returned okay meaning it succeeded now console is actually a unique keyword in the leo programming language and the reason that we have this keyword is because unlike in traditional programming languages leo is compiling on a high level this language down into something called a circuit the circuit itself has to be generic and flexible for use um for effectively the remainder of time in a system like this on a blockchain and those consoles are primarily executed only at compile time and so this is an easy way for for developers to debug to quickly assert that the state of things is behaving that they want but not encoded into the final circuit if they don't want it to be certainly they can write assertion statements there's nothing that prevents them from writing assert statements in the native form but whenever the the keyword console is used that means that this is only during compile time or effectively the developer development time that they're using this to evaluate and to sanity check that the application is behaving correctly if they wanted to do actual asserts they could simply write you know a very simple function assert and basically define a and b and pass it in and check that these cases equal this is actually something that we're looking at into the language very soon ourselves but the point being is that console is something that allows for um a a compile-time check rather than an execution time check um and with that i also want to call out the output style so as i mentioned in this main function once you take in some input it executes and then we uh we output some state you know what happens to that state well that that state actually outputs for one effectively a proof about this execution to say that it was correct and in addition it outputs the circuit that represents this program so that it can be deployed to the blockchain these are these are uh uh pieces that currently um reason basically from from the in and out files that i've described for example this in and those are records themselves that live on chain and so you know in the current form as you see here this is actually encoded in a record that lives on chain and that's something that we're taking down and then executing and then putting back on chain in the form of a transaction and this is the state transition that we're talking about um so this gives you a high level on on one example which is roulette hopefully it helps to elucidate some of the some of the potential use cases or applications beyond here in this case you know having effectively a vrf in a system like this without having to go to some third-party oracle or to go to some external system and have have very good transparency on how it works is a huge value add that just is very difficult to replicate on existing smart contract systems and so with that um i want to open up to q a or if there's anyone who's interested to ask specific questions i'm happy to answer as well excellent thank you howard let me just double check in here let me get into the comments sure um i can pull that off for you if you guys have questions for howard got some compliments for the talk excellent from from sturkey cool um a question maybe to extend on kind of what you were talking about with the vrfs what are some other use cases beyond gaming and things like that um that you guys have explored yeah so there's actually a um there's actually really interesting um like uh like domain of specifically for d5 that i think is really underexplored right now um with with a a system like this um you can build applications that just aren't possible on on ethereum today for example dark pools are or or really a really effective mixers and what i mean by that is that um you know because everything is public on a system like ethereum those smart contracts aren't actually hiding or are able to shield any of the data or orders that are open in an exchange and so in this context it's um it's really easy to build dark pools that can be used for you know either otc trades or just for darkfield trading on its own but in addition it's also great for shielded wallets because applications on chain themselves and code state in an encrypted form and so because of that uh it's easy to basically shield your assets on a system like this um i'd say kind of a third area that that beyond gaming and d5 that's interesting is interoperability you know i know people have talked a lot about interoperability over over the past few years um but um you know it's primarily been been very much kind of closed ecosystems in the sense that you have a hub and spoke model for for a new ecosystem because xero knowledge proofs themselves are chain agnostic they can reason about the state of other chains um and and effectively transfer state from one one chain to another and this is a nice way of encoding state so that for example if i wanted to lock tokens in a smart contract on ethereum with a with a with the with a commitment i could give a zero knowledge proof on elio um that you know i know the pre-image to a commitment for a transaction that where i locked up an erc20 token over there and unlock it over here a virtual equivalent that's a that's a two-way bridge in this case that lets you move seamlessly between systems um and so that's that's kind of a third area where i think for value transfer or for helping other l1s get exposure to the default on ethereum or or or to bring assets uh other l1 assets over to ethereum's d fiber system you know this is a natural way of doing bridging as well and so those are kind of the three areas that i think are promising yeah cool cool um looks like somebody's asking about if there's limitations transaction per second yeah it's a great question so basically every transaction has to be verified so every transaction itself is a zero knowledge proof and it has to be verified it takes about 10 milliseconds to uh to check that that proof and so the the limitation is really on um like basically just cpu bounds like how quickly you can execute you can execute the verification and and how quickly you can pack as many transactions into a block as possible um the the real limitations here aren't on re-execution unlike in the ethereum model because miners don't have to re-execute by the time the transaction has already reached the mempool it's already been executed and the proof gives an attestation saying that the outcome of that state transition was correct and so um yeah the only limitation in tps is really your hardware excellent excellent um i'm not sure this doesn't mean much to me but i i'd let you interpret that sure yeah yeah is this related to the nickel pals yeah so this is related to nipple pals and like there's also like um with james prestwich's work on like zk rollouts uh um you know these are concepts that we've been exploring quite a bit because it it basically allows you to start to bundle state um using a zero-knowledge proof and send it over to another chain so for example i could on elio take um the past you know let's say the past 20 blocks and then check the proof in each of those 20 blocks into one single proof which i then send off to um ethereum in a smart contract and in an ethereum smart contract verify that proof which then validates that you know a transaction in the latest block um for example has had 20 block confirmations on elio and that could be a nice way to basically translate state or transfer state from one system to another and then and as you can probably imagine it's not just limited to tokens but it's limited but it can be extensible to arbitrary types of data beyond just tokens yeah yeah uh here's one he says uh how do you handle circuit versioning within high-level language yeah um strat thanks for asking that one it's a very good question this is actually one of the hardest uh or harder parts of of um of our discussions in terms of developing vo so so effectively the way that we've been thinking about it currently is to have three formats there's basically um on a high level um the leo code that you've written there is then effectively an intermediate representation that we're currently working on that intermediate representation is what we would host on a package manager and the rationale for well i'll get to the rationale for that in a second but finally then you have the r1cs circuit itself which is what's persisted in an on-chain circuit registry um and going back to the ir the ir itself is intended for composability so that on a package manager um the idea is if you do do versioning um the ir is where you you basically mux to a new version um but it's also a way for you to do inter-contract calls and so you can compose different pieces together um in this ir and basically compose new types of applications from that um and and the idea here is to minimize the amount of bloat on chain for like circuits that you would want to represent um but uh yeah like that's that's something that we've been actually having quite a bit of open discussion for for designing um but would love to chat with you about it um and uh like uh with regards to them what's then then encoded on chain basically what you deploy on there is the final version and if you want a new version you basically can in the same way as on ethereum with proxy contracts have basically a proxy option where if you're like a contract dot owner you can authorize us spending the death program for a record either from the current circuit or some uh owner defined a new circuit a predicate id basically um so so that's that's the that's the high level on that hopefully that gives some context there hopefully excellent um we've got one here from radio operators says they love the approach um are there validators so uh i guess uh invalidators are in the context of like poop or is that proof of state validators yeah well i'm not super sure i'll attempt right answer hopefully it's it's it's the right one um but um basically like every uh the system itself uh is uh is a proof of work based system um and so we we use miners um in this case and actually you may be wondering why the rationale is that we're devising a consensus mechanism called proof of succinct work and the goal is just like in bitcoin where you grind shot 256 to basically find a solution and then get a block reward we actually are grinding snarks and then using that to then then incentivize miners with a block reward and and the goal personally is is to actually develop specialized hardware for zero knowledge proof generation and incentivize miners to develop that um since um as as many of you know um zero knowledge uh has only become really practical for small to mid-size applications in the past two to three years um you know the goal is to really continue to push those boundaries to have people start looking at gpus fpgas a6 and get us to basically you know 100x performance improvements for zk one way to do it and the best way that that we know how to do it is effectively with miners um basically incentivizing miners to do that and so we've built a consensus algorithm that is proof of work based and instead of branding shot 256 you grind snarks in this case um i'd also like to call it one other point of that which is that that's the minor side of it but there's also the prover side to things which is with provers you know we want to give the ability for anyone to to be also a facilitator of executing state transitions so um you know there is um it in zak see a uh section that we call deliberate dpc and the idea is that with delegate dpc is that you can delegate your execution to a trustless lead to a third party and they can't cheat because well either they execute the state transition correctly for you and give you a zero knowledge proof back attesting to it or nothing happens at all and so with the delegate model this opens up another avenue where one can be both a minor and a approver and they're not mutually exclusive and this gives different avenues for people to actually be involved with their hardware cool cool one last question i think uh before we have to transition but uh if you if we want to learn more about zero knowledge uh what would you recommend to learn yeah well first off i'd give a huge shout out to the zero knowledge podcast um there's a lot of wonderful material there to you know learn about the different approaches people have taken um in terms of the the primitives and the photography that we're using for elio i would highly recommend checking out developer.alia.

org which is where our developer documentation is it gives a high level overview on one how to you know how to conceptualize um this model that we've been building but also um to just get started on writing your first new application in this case um and so developer.aila.org is that link and you know if you want to start programming in in the studio that you just saw um the link to download that is alia.studio great thank you very much howard here's john no thank you really appreciate it awesome presentation thanks man we appreciate it yeah no thank you for having me this was awesome no problem at all man have a good night you're gonna play chess sorry are you playing chess i i'm not playing chess at the moment but uh maybe you know the tournament tonight we have a new denver tournament happening like right now oh i gotta go so i gotta go play some chess with i gotta go take i gotta go beat iwawaki on all of this so anyway thank you howard we really appreciate it yeah no thank you thank you for having me you got it all right take care