zkSessions: Zac Williamson — Programmable Privacy with Noir

Transcript

um hi everyone so i'm zach uh i'm the ceo of aztec and we we are our man um mission is to provide practical programmable privacy on top of ethereum and other commissions blockchains and um yes so i'm trying to talk about noir which is um our flagship uh privacy preserving programming language um uh who's development is being spearheaded by kev uh so i guess the first question is why a new language um given the preparation of snot languages so far and it's because we have some very specific requirements um noir is very much a privacy first um language um for for snarks so it's not really focus focus much on scalability as much as

uh ensuring that the user who is creating these proofs from circuits built by noir can efficiently and effectively hide data um so we want to have previously preserving semantics built into the language so the ability to create um kind of private state variables inside a private smart contract architect type architecture um this will likely actually be a part of a framework that's kind of applied on top of the core core languages in the form of the library and the focus is is very much um on efficiency and the performance of our proof algorithms doing a private transaction um you cannot delegate that proof construction to a third party um efficiently without leaking secrets

or information which means that law proofs um are typically going to be constructed on relatively wimpy hardware um by users engaging in a privacy preserving gap um where um they're likely going to be running um this software web browser so you're having to having to use web assemblies to make the proof as well which kind of even even further limits performance so efficiency is key and that's why no plugs into our ultra planck um cryptographic back end where we have kind of handled sub-circuits for common um commonly used cryptographic algorithms um and allows us to do really pretty pretty efficient recursive proof compositions and and other advanced um cryptographic algorithms like each rt56 and um

signature verifications the this is an open source project and the goal is to support other cryptographic backends too because noir is deliberately architected to be proving system agnostic which i can get to in a little bit uh and the the end game here is is uh we want to use noir to build privacy preserving smart contracts um that plug directly into um a um kind of a a layer two architecture that we're building that's designed for that purpose um but more generally we want noise to be able to be used for a wide variety of cryptography projects um uh that quite a strong privacy um uh preserving guarantees so a little bit about private smart

contracts because this is kind of more of a um uh it's auxiliary to the actual language but i think it's quite key because this is how we want plan for the language to be used um similar to how solidity and isolation is particularly useful as a language but because it is a programming language for smart contracts that's where it has it has a large amount of utility um so um if you think about like um typically if you want to do privacy presenting transactions you need to do um yours your database cannot be a traditional database like an ethereum where you have accounts with balances that update but instead you have um you need a more bitcoin style type of utxo um situation um where uh you um kind of create and destroy these

unspent transaction objects in the course of a transaction but where a utxo knows in bitcoin just represents some value in in a more general system that's previously preserving these notes can be encrypted and they can represent as generic state variables and the transaction rules around how you modify these notes um can be modified by programmable snark circuits that's kind of the core of the the the the the high level of how state management would work but um if you want to build a privacy preserving layer 2 where you can create private where you can have user-defined smart contracts added into it then you're effectively adding on trusted credit the way that we're planning on permitting this is with us sexy style um uh

channel snark circuit um well influenced by sexy where the idea is you have a multiple tree of verification keys where each verification key maps to a private smart contract and the kernel smart circuit verifies the correctness of a single private transaction so this so the kernel circuit will fish a verification key out of the michael tree the user will provide a proof against that verification key that the kernel sector will then verify and also just to ensure that the the the the rules of the of the layer 2 are correctly followed so that you know there are valid digital signatures from the transaction sender and all of the semantics are correct um this proof of this kernel circuit can then be sent to a layer two um aggregator or roller roll-up roof

constructor um and the entire process is previously preserving um because uh the the kernel circuit is uniform and um any observer third party even the roller provider has no understanding of the smart contract called within or the identity of the users or senders or recipients or knowledge of any of the state updates um being performed because they're all encrypted um so that's at a super high level quickly how one could do privacy presenting smart contracts this is when noir comes in so the the workflow for noir is you take some front end some use case that you want to that you want to write circuit for you write it in the normal front end and then that will get eventually spat out as

both um you can then construct proofs over there over there over that program and also will spit out a verifier smart contract that you can deploy to ethereum to verify circuits so this is um eventually we want we will we will be verifying our seconds directly into satellite but for now in the alpha state um it just fits out a verified smart contract you can deploy itself yourself to mainnet and we will always we will be maintaining this feature um as time goes on as well um but the the way that it translates a program into constraints is by is through an intermediate representation um that's called says abstract circuit interventi representation it's a bit like an llvm but for stocks um and this is what makes noise proving

system agnostics so right now we convert um asea code into plonk constraints um through our plant group together back end but there's no reason why it can't be converted to rcs constraints or um uh that can then be fed into you know growth 16 or marlin and so we're hoping to add those in time as well as the relevant verifier smart contracts for those different proving systems so just to give an example of how essay works the idea is that for commonly used algorithms um assay treats those as a black box that and it delegates um the implementation of those to a cryptographic backend so if you in the program in your program want to do short two by six you'll do range proofs

then um then the uh the it's up to the it's up to your back the back end to convert those into constraints and so for example with with um aztec's ultra clock back end we have very efficient implementations of charity f6 and range groups and things like that um and it will be up to another back end like if if one wants to build a normal narcissist back and it'll be up to that back end to implement these black box functions in an as efficient way as they can and so the idea is basically for most programs um what will happen will be um the majority of the of of the program code will basically just be calls to various black box functions with glue logic in between and that glue logic will be converted into linear

combinations um that can then be very efficiently transposed into either plonk uh constraints or rncs constraints so the high level features that we want from the one is so first of all programs are directly compiled into circuits we don't um implement this through a virtual machine abstraction although we would very much like to um prior the priority is proof of efficiency we just can't tolerate that on when you're constructing proofs from an iphone or or a you know mid-grade consumer laptop um the improving systems that right now orders of magnitude just flow to support that um that means that branching plants and non-constant loops are expensive we want to eventually support them but in a very limited capacity so that we don't um we don't guide developers down up down a path where they're up there

they're accidentally creating extremely expensive circuits but we will be supporting eventually dynamic memory allocations so vectors genomic arrays those kinds of things where you can access arrays at unknown um like proven to find locations uh we can do this because of the media integrated uh our pickup research into our ultra pump back-end which makes these kinds of constructions very efficient to compute because effectively the the typical way you would do you would do um as alex at the start you would do memory access is through permutation networks but because planck has a you can directly commit to permit permutations in cyclone can prove their correctness you can actually implement that kind of um directly via the form of commitments instead of having to

to validate the permutation inside your circuit if that makes sense i can go into that later if that's useful so the performance targets for noir are um so this is all using wasm because that's kind of how we imagine most of the previous proofs are going to be made um uh we can already our cryptographic backend can already make basic proofs in less than 10 seconds and rather the average however like an iphone 8 um uh four circuits that have about sixty five thousand constraints which is enough to do um private tokens value transfers things like autistic wallets uh so um but the the end the target for the next twelve months is to be able to create these kind of advanced multi-recursive private smart contract proofs where you have these inner prison kernel proofs um and to do that all in less than 60

seconds on average hardware and the verified smart contract costs i believe about 400 000 gas um right now to verify um we can probably upload it down a little bit but that's roughly i think where it's going to stay um our development wrote currently the alpha um that that that kev's built is um it's got an integration into our turbo clock back end which is the the very very depth that we've deployed with um we currently deployed to mainnet and we have a the the basic part resistance working the the north front end that compares to assay that then creates a proven verifier in the whole workflow um that's all been built out as well as um uh we support our modules and uh standard library which has um these more advanced cryptographic functions like chara and pedestrian and

um things like that photography features for next year are um more advanced so we want to be able to we will be supporting uh private state semantics and uh cool semantics so effectively a privacy preserving cool stack um so this will be basic very highly influenced by our um our privacy uh private smart contract oil architecture and so these two points will likely be in like a framework that gets layered on top of noir um we'll also be integrating into alternate back end we'll be supporting more cryptography back-ends like for rms for example as well as a strong focus on developer tools which are currently lacking because this is based on the quite early development phase um and then yeah full integration with our private smart contract architecture

so you want to get started this is the link to our repo i can post it in the chat afterwards um and i'll do documentation um if you uh tinkering around with norm we would very much appreciate feedback because as much we want as much information as we can get um uh so to further refine the language and this is just a little snippet for doing something so for doing like a tornado cache style deposit um uh where i can i can uh maybe i can leave this up if we have time for questions but it's basically a simple simple membership check inside america try to prove the existence of a um of a variable um uh in intrinsic code right so that's everything