Private Value Transfer in 10 Lines by Maxim Vezenov | Devcon Bogotá

foreign [Music] and I'm a software engineer slash language designer here at Aztec Network and I'm going to be introducing you to Noir today Noir is our rust-based domain-specific language for writing zero knowledge circuits I'm going to walk you through a basic circuit and then also show you how to go about proving and verifying that circuit in typescript so first I want to talk about what actually makes Noir unique Noir aims to be more flexible in its design than other domain-specific languages that currently exist out there and we do this by rather than compiling to a specific MP complete language we're compiling down to an intermediate representation we call this intermediate representation the abstract circuit intermediate representation or the Acer as I'm going to refer to it throughout this talk this IR can then be compiled down to a rank one constraint system or plonkish languages whichever you so choose this is analogous to the lovm IR but rather than converting down the IR to a specific instruction set architecture we're compiling down to the constraint system of a given ZK proof construction this actually enables us to essentially decouple the back-end proof system and the language we currently have one fully integrated back-end system and that's Aztecs brettenberg library and we also have plans for Integrations with The Arc Works proving systems such as Marlin and growth 16 but anyone if you can compile it down to whatever you'd like this to our knowledge is the only DSL that currently has fully integrated proving system optimizations so rather than just having an interface for language system optimizations we actually have it on the proving system as well but like where do we actually get from this so we now different use cases require different kinds of systems and now we actually have a language that separates the middle end a front end middle end and back end of a language and developers can then Converge on a common architecture standard the fact that Noir has the ability to support proving system optimizations enables us to have the addition of optimized Black Box functions a few that we have are listed right there but if a back-end system has integrated that specific Black Box function the front end can then access it the ultimate goal here is to lower the barrier to Circuit development by incorporating cryptographic safety into the language itself while maintaining performance so I'm mainly going to be talking about how to prove and verify in typescript this very high level compilation overview also shows our package manager nargo that I specifically want to note that allows for approving and verifying circuits this is very similar to Cargo so you can build your circuits using this but because to actually prove you have to require requires a proof system you see that line on the top going all the way over to the proof system as well in order to compile nargo you need all integrated so now I'm actually going to take you through what a Noir circuit looks like and and I'm going to use one of the most common examples where ZK proofs are used to enable private transfers and rather than you know simply showing you the entire circuit at once I'm going to walk through kind of each part of the circuit and this is to highlight noir's unique features for and also for those who may be unfamiliar with how to write a private transfer circuit how that may be done if you're already kind of familiar with it you may have to Do's from the inputs that the circuit essentially boils down to a Merkel membership proof similar to how noir's rust based the syntax is rust-like as well but the main thing to note here is the usage of the pub keyword all inputs to the Noir circuit are going to be private by default and that keyword allows you to then say this also has to be supplied to the verifier as well currently anything outputted from the function must also be public and to take note of our native data type that's called the field this is in the Aztec brettenberg back end a field on the BN 254 curve but we also support smaller data types such as u32 u8 you can even have u3 but these are less efficient as they require range constraints and but that's all to the needs of the circuit developer if you want to constrain using our data types rather than directly in the circuit yourself now we can actually get into the logic of the circuit and we're going to start off by using two of our standard Library functions the schnor fixed base scalar multiplication method so we can construct a private public key from the private key that was supplied to the circuit and then also a Pederson hash function which is going to take in a list of field elements and return turn a point on the bn254 Curve we first you we use the random input secret that was shown in the previous slide to keep our note commitment private and not associated with any one account once again this is using the Aztec brettenberg back end but if a back end supports these functions then the front end can access it and now we actually have the the meat of the circuit where we're first going to generate a nullifier and this nullifier has to be unique and this is used to prevent double spends and the circuit the contract that integrates the circuit is going to have to make sure make sure of that where we provide the no commitment that we just calculated in the previous in the previous Slide the index of the snow commitment in the Merkle tree and then the private key to act as that identity differentiator and then finally we have a check membership function that's going to take in the hash path the index that note commitment and a note root it's going to calculate a note root using the hash path and commitment provided and if it matches the the note route there that we provided from the circuit which is public we then know okay that this that those no commitment that was calculated within the circuit is actually the the person proving it does possess that no commitment and finally we return our nullifier and our recipient this uh is actually constraining these two values with the outputs it's a little syntactic sugar that we have for our return values you could instead for example not have the nullifier be returned as public output you could instill Supply it as public input and you would have to then write constrain like nullify or hash equals nullify or index 0 there but this is happening implicitly when we return it from the circuit right there as this circuit is the title of this the presentation is it's Noir uh private transfer in 10 lines so we don't really show a lot of what the Noir syntax looks like so I wanted to quickly highlight what else also exists in Noir we do have compound data types such as arrays tuples and structs as you can see right there and you can then we also have sub modules so you can easily separate your functions as you as you see fit also just recently added Global consts which you can also import as you would in any other programming language such as rust or control flow we have for loops and if statements and we're looking to add recursion soon as well we also have recently added to generics which is highlighted right here which is a great benefit to the developer experience just to recap we try and be high level as we want to make this the development experience easier but also abstract away some of that cryptographic safety that you might be familiar with in other ZK circuit languages or where you have to directly specify essentially every constraint and that's the ultimate goal of Noir to have safety and the a greater development experience now I'm actually going to kind of walk through how you would use our wrapper to prove and verify this circuit in typescript and then ultimately in the browser so that clients can you can prove on the client side we have a Noir JS package which has been created to allow developer to you can directly compile your circuit and typescript as you see there but in this in this uh package you can also read in from the Acer from file that would be generated by the nargo package manager that's a choice of the developer but in this example we just uh we just show you how to compile it directly in typescript so after we have an object representing our Acer we then just have to specify our ABI and the ABI is what the prover is going to be providing to ultimately construct our proof which has our private and public inputs and that's going to be used to generate the witness and ultimately generate the proof so because Noir is back in agnostic though we have a separate wrapper around the Aztec ruttenberg back end and that's any other backend that's gets integrated is going to have to do the same thing as well because this backend has been made to match the Acer interface in order to set up the prover and verifier we simply pass in the Acer and as you can see right there and then that ABI that we specified earlier to construct our proof and then we just pass it along to our verifier one thing you might note though is that you don't see any public inputs being passed to the verifier even though we have we had that in our circuit currently the proof that gets spit out by brettenberg is pre-pending those as 32 byte hex string inputs but we plan to separate that as developers might like to have those inputs separated for their own development purposes but that's just to take note of why you don't see any public inputs being passed to the verifier there so we can this it's cool that we can actually verify in typescript but we want to be able to also enable this in smart contracts as well so Aztecs brettenberg backend does allow you to compile from a Noir program to an ethereum contract improving systems looking to integrate Noir are going to have to provide their own implementation of how to generate a solidity verifier or if you choose to use any other smart contract platform you're going to have to provide that implementation yourself if you're integrating a back end this script here shows you how to generate a solidity verifier using that Aztec brettenberg back end and it's important to take note though if you change your circuit and don't change your you don't regenerate your solidity verifier with the script your circuit is ultimately going to fail as you're going to have a new Acer and you're going to have a you're going to need to regenerate that verifier in order to have accurate verification and finally we can actually have our ta-da moment and verify our circuit and solidity so using your favorite deployment method you can deploy your turbo verifier as you would any other smart contract and then you can take that proof that was spit out from brettenberg in the exact same way with the pre with the public inputs prepended pass it to the verifier and if your public inputs are correct and your specified your circuit correctly it should it should ultimately return true in the case of our private transfer we're going to be checking is that nullifier hash been used before is the root uh the correct route and upon having a verified proof we can actually then perform a private with a withdrawal and that that note that will be entirely private so that's that's it there and you can see a more full example with the uh simple Shield but ultimately here the benefit is that we can enable autonomous execution in contracts based off verification of Noir circuits and I want to also discuss some of the future work that we're going to be doing in Noir one of the main things that we want to add is verify proof this will actually enable us to have recursive snarks inside of Noir itself which enables many more use cases than you can currently have uh the wrapper itself is pretty new and we want to improve this development signifi these development tooling submit significantly to make it easier for anyone looking to integrate with Noir we also want to integrate it with Rebels such as ZK Rebel if you're familiar with that online IDE Integrations other debugging tools a language server lots of development tools to add and in the medium to long term we're going to be adding Noir contracts and Noir contracts are going to be the next stage of Aztec's platform where we'll actually have public and private state which is has its own challenges which you can attend Mike Connors talk at 2 30 from Aztec who's going to be discussing that infrastructure and how we actually are going to enable Smart contracts in Noir if you have any questions uh please shoot and thank you [Applause] thank you so much Maxim so we have two volunteers there you go this is our balloon two coming hey good afternoon uh very impressive um right now how does the how does your tooling work for this uh you have to compile the Noir contract and then deploy it into into the layer two into the layer two or the layer two test net or something not right now that's that's the next iteration of Aztec's platform when we add the Noir contracts this is a purely a zkevm DSL right now where Aztec can generate that solidity verifier and you're going to be proving circuits on a evm platform uh you can you can gener like I showed in that example you can compile your circuit in typescript but you can also use our package manager which I briefly mentioned to generate that intermediate representation that intermediate representation can be used the same way that that that it was used there you just have to read it you're reading it in from file using our same our wrapper method so you don't have to do anything extra for serialization that's handled that's handled by our wrapper yeah right now but you can also you know ver you can verify without the evm as well you can just verify using typescript and you don't have to necessarily have a verification using a solidity contract that depends on your needs but a lot of people like to have that autonomous execution we have time for more questions one over there in the left side then we have two more here hey hi uh it was amazing uh I wanted to ask let's say as a developer I have the choice between sarcom and Noir now both as an end user feature provide proof systems with Planck and growth 16. it's exactly the same value proposition so why would you say that uh we should experiment with Noir instead of just going with sarcom sorry to put you in a position no no it's okay uh they do serve slightly different use cases circum is definitely a much more low level you're going to have to be specifying a lot of the constraints individually while in the language we specify those constraints for you a basic example there when I talked about if statements you can constrain your your on if statements you don't have to use a multiplexer and things like that that make it just easier for the developer and kind of lower that barrier from someone who's maybe moving from who's never coded ZK circuits before and you can also constrain on data types outside of just our native type because they everything that we have ultimately translates to that and we do have uh I know you can currently do Planck but I believe right now Noir is the only language that actually has truly fully integrated Black Box functionality where the proving system is specifying the custom Gates and making those functions faster hi um why base Noir off rust are there certain properties of rust that make it you know a better language for this well we want to one of the main focuses of noir's safety and Noah and rust that same thing in Russ right and rust is also just a nice language uh thanks a lot for for the talk uh I was wondering do you have some tools where am I looking sorry I'm here oh hey hello uh thanks for the for the talk uh do you have some tools for uh testing the logic of the circuits uh right now it's essentially you're gonna have to write your tests in typescript we hope to add debugging tools that's one of the main things that need to be added to make the tooling more effective uh yeah you're gonna have to essentially test it either in typescript you can test it in Rust too and use the nargo package manager that's up to you but I only highlighted typescript here because most contract developers are probably going to lean towards that okay thanks we still have time for more questions five minutes more there you go on the right thank you uh just a quick question on the first uh like code sample you had uh I could see the STD the STD package was under a depth uh namespace and I was wondering where that is that's just our I guess native kind of dependencies and that's how we do it like we you can also import from from GitHub or you can have modules as you would normally in Rust within your uh where it would be like mod something and you can also import packages from within a crate as well where it would be like create this uh and that would be the import that's just how we import our standard Library yeah like rust crates uh our our nargo kind of it it's not like a copy of cargo but it kind of mocks that functionality with crates and modules so you can have you can import modules from within your crate using use crate and then whatever else you'd like it's a very nice talk uh in the next phase of of Aztec 3 uh can you talk about the process process of converting existing circuits to Noir what do you mean existing circuits you mean contracts like the uh so in Aztec 3 you're planning on converting existing circuits to Noir I assume so that's actually probably you'd want to go to Mike's talk to see more it's very interesting how the infrastructure works essentially though each function in the contract is going to be a circuit but how that actually gets integrated into the system you're going to have to attend Mike's talk to get more info on that it's very interesting we have someone from Team here as well if you want to complement anything like to add on top of the conversation hello yeah I just want to ask so with Aztec free we're not actually trying to be ZK evm compatible right it's a separate no right yeah just making sure cool there's one more over there this side oh yeah that was my question again um that was he said he was he they made a preamble to the question so that means that Noir the since Nora is going to Target to EVMS uh Arctic 3 is not going to be using Noir for this for for its inter for the circuits so we're going to be using Noir for circuits but you don't necessarily have to Target the evm there we just Aztecs backhand does allow you to compile an evm verifier from a Noir circuit and that functionality will still exist but no R contracts and Aztecs platform are not going to be ZK VM they're going to they're going to be Noir so yeah so that means that you also have the your go you right now have the target for Aztec or you are going to have or you're going to build it yet sorry can you say it again the start the compilation Target right now it's only ebm but you are planning to to be able to migrate to to be able to compile as well to Aztec in the future yes yeah so currently Noir is just a language for creating circuits um and you can create a solidity verifier that allows you to verify those proofs uh on the on the ethereum once we extend extend the syntax to have a contract terminology uh Aztec free will be built and it will have its own VM and you can compile those contracts to the Aztec free VM not the ZK evm hi hi well I am now in nor right now it's so new for me and I would like to know whether the main applications that they are using now right now the main applications using Noir right now yeah uh well there hasn't been many uh mostly the examples you can find on my GitHub or inside the Noir repo testing the language um but there's anything you can think of where you would need to verify a proof and do something based off that ZK proof you couldn't theoretically do a Noir so that can be quite a lot of things synonymous proof of membership uh private games on on public blockchains lots of different things all right big round of applause to Maxim from Aztec [Music]