Learn Noir in an Afternoon

NoirCon 3 at Devconnect Argentina 2025 · 20 Nov 2025 · 48:21

Harsh Bajpai, a DevRel engineer working on Noir, introduces the fundamentals of the language and shows how to start building private applications quickly. The session is aimed at developers new to zero-knowledge programming and serves as a hands-on entry point into the Noir toolchain. It was held at NoirCon 3 during Devconnect 2025.

Speakers

Topics

From NoirCon 3 at Devconnect Argentina 2025, hosted by Aztec Network.

Transcript

Good morning GMGM. Thank you everybody here for taking choosing [music] to spend your time as our third inaugural Noir. >> Welcome everyone to my talk. The talk is called the Noir Sniper Talk. Uh don't ask me why I named it the Noir sniper talk like I just found that would be a good name for the workshop. Uh but the goal of the workshop is to get your nerd sniped on client side proving noir and privacy. So uh first of all like how many of you have like never written anything in noir or like have never written a pre oh okay that perfect okay perfect uh so uh so the goal is uh firstly to show you a little bit about uh like give you an intuitive model

about client side proving and what the comput like how how to think of com like rightly about the model of private computing then I'm going to introduce the language but then the cool thing is that we have like two really sick demos in this in this talk, right? So, these are like real working demos and yeah, like I hope and I will like leave you with some really nice ideas. So, yeah, let's get started. So, firstly, who am I? Uh, I'm H. I do I'm an exploration engineer at AIC. I my job is to build cool stuff. That's it. uh I built like I I build cool things with Noir and Aztec and we have this small exploration team at Aztec and our goal is to explore the

design space on what's possible with these primitives that we are building. So the agenda for today uh no we are not going to invent the AGI the invent the the agenda is pretty simple it's to nerd snipe you to noir so that when you walk out of it out of this room you feel like oh I really should write some no I really should write some privacy software so the we we're going to start with developing an intuitive understanding of zk and client side proving then we're going to go on zkms versus zkdsls a little bit uh a very gentle introduction to noir so I'm not going to read the full documentation to you. I'm just going to show you what a circuit looks like, what is proving looks like and then we get to the fun stuff which is like cool demos like

showing you real things that work. Uh and uh yeah that's that's where like a lot of fun will be and then I will leave you with some inspiration for what you can build with noir and not very simple things like real things that I think can be fun that can have some impact uh out in the world and then yeah like a small Q&A session if time is left. So uh yeah so let's start everyone is hearing about ZK everyone wants to get in and everyone is confused and that has been the state of zero knowledge cruise for quite some time uh to just give an example of uh how confused people used to be back then about ZK's I participated once in a hackathon I made some privacy governance software I won the hackathon but they

gave me a prize because they thought I made a zk rollup right so like that's how confusing uh the state of zero not like what zk is has been for people and let's try to make it a little simpler. So what's the goal of zero knowledge cryptography? Uh the goal is to allow proving of knowledge of information uh without actually revealing it. You do get some interesting scaling properties with it as well. We're going to talk about it but you could say like in a privacy context that's the useful thing like most of the time which is like it allows you to prove some knowledge of information without actually sharing that actual piece of information. So what does it look like? Uh you have this you have these two entities. You have a prover and a verifier and prover

possesses some knowledge or some some piece of knowledge some information and the prover doesn't actually wants to give this information to the verifier. Right? So uh and the verifier is just interested in knowing that you do have the piece of information and it's correct but they are fine if you don't show them everything about the information. Right? So that's the real world interaction that we are trying to ideally enable with this. An example could be if anyone recently participated on the Aztec uh token sale website there's a ZK passport and like basically what you're trying to prove to the very yeah what you're trying to prove to the uh verifier here which is uh let's say the AIC platform in that case is that

you are a legal citizen of some country and yeah like you have a legal passport and then you're doing a face ID test and you're not actually you know like sharing your actual data for that u and And it's all happening client side. So that's the construct. You have a prover and a verifier. Prover doesn't want to share information. Verifier wants to verify the information, but it's fine if they it doesn't sees it like it just wants to make sure that it's actually correct. So yeah, so that's what it looks like. Uh this construct between them via zero knowledge cryptography is a zk proof which a prover has the ability to create and prove their knowledge of information and the verifier can very succinctly verify uh this piece of information. Now I said a bunch of stuff but the question

is how is that even possible because uh yeah I just basically described that's what it looks like but yeah how would how would this actually work u so let's take a small dete rather than talking about zero knowledge cryptography let's talk about something that we all understand which is computation so what is computation computation is a stepby-step processing of information you have inputs uh you have uh like some processing done on it and then you have an output and that is computation. Right? Now if you look at multiplication of two numbers, you have an input X, you have an input Y, you do some processing on it which is multiplication and then you get a result which is let's say here um X into Y equal to Z. So how do we verify

computation as of now? And the classic way of verifying computation has been recomputee. So the prover in this case when they want to prove that they did a computation correctly just gives the input the exact computation the output and the verifier will be like hey here's the input here's the computation that was done I'm going to redo it again and I'm going to see whether it's all correct or not right and hence recomputee and verify and you get verification of traditional computation but the problem is what if the computation gets really heavy right like so let's say you delegated someone to compute something for you and it was very expensive. But now if the only way to verify that it was actually correct is recomputing yourself that really

sucks, right? So that's where we have this model of a verifiable computational model, right? Like where what if we could uh prove correct execution. So what if we could like prove correct execution without like actually recmputing all of it. Uh so that's a verifiable computational model where every time you produce an output of any computation, you also have a proof of computation and that makes the job of verifying computation really easier, right? So you could have an input, you could have a proof of computation and you could have an output and the person verifying your computation can just verify the proof of computation which ideally has to be like taking less time and should be cheaper and faster than

recomputing itself. And we have cryptography out there to enable this. So this model of computation you can say is a model of verifiable computation. But then the question is how is any of it related to zero knowledge proofs? Like I just talked about verifiable computation like how how does that give you any understanding of the zik stuff? Uh what if you could hide some inputs in your verifiable computational model. So what I mean by that is that in the old approach when you wanted someone to verify your computation you were giving them the input a small success proof of computation and then an output but what if you had the ability to hide inputs where you could say here's a proof of computation here's the output that was produced of it but I'm not going to give you the inputs right and uh for example

take here like in what if we could have a computational model where we have x and y which are the input and then you have you compute on them which is like the multiplication of them and then you have this proof of computation. So if you have the ability to hide x and y themselves then you have the ability to prove that you know 2x and y which multiply would result into a z without actually sharing x and y. So this is the computational model that we use when writing client side private software where you give someone a proof of computation. You have the ability to reveal what uh information you want to share and what information you don't want to share.

So in this case like you can prove that you know two numbers when multiplied are 12 without actually sharing like what them are. Like if it's 12 then you don't know whether the person knows four or three or whether they know six and two. So yeah so the ability to hide inputs and be able to still prove computation gives you proof of knowledge of inputs because the only way you could have produced the proof of computation is if you knew the correct inputs. So that's that's the model of how you uh write like provable software like and private software and this ZK cryptography gives you two primary properties which you also get with noir where you can prove knowledge of information without

actually sharing it like being able to hide certain pieces of knowledge and still being able to prove properties around them and then also the ability of scalable computation where you could like prove something once and then it can be verified as many times wherever you want in very success uh time. Yep. Cool. How do we write a ZK program? Currently, there are two ways to do it. One is a ZKVM way of doing it. Well, you have a virtual machine. So, it's like risk 5. It could be a Z like it could be a ZKVM and you just write your computation once and uh yeah then it like the ZKVM has a circuit and then your computation gets

proven like I don't think like a lot of ZK a lot of ZKVMs right now are actually ZK like I don't think like if a lot of them give you the ability to actually hide your inputs like not sure but the examples are SP1 R zero Cairo uh Lita which is like a custom ISA but the thing is that you can like take a language like first C++ and then you write your computation once in them and then you have this virtual machine which is capable of producing zk proofs and then the second way is of a zkdsl which is what we use with noir where you write it in a custom DSL language which is like noir circom etc and then it compiles to a zk circuit and then you can use any proving system you want and then you can

prove uh the knowledge of inputs you can prove correct execution with it. So yeah, that's the D ZKD DSL approach. And here's a small comparison between both of them, but it's pretty intuitive. Like a ZKVM is you have a virtual machine, anything that can run on the virtual machine can be proven in case of a ZK DSL like noir. You write your circuit in a domain specific language and then it gets proven later on. Okay. So about Noir. So finally we get to Noir since we now understand the model of private computation. Uh it's a Rustlike looking language. So if you know rust you already know noir I would say to some extent. So a lot of you might ask then why even not like just use rust. Uh it's because like rust has

a lot of features that you just don't need. Like noir is like it looks like rust. It has very it has the most important feature sets that you need but then for example you don't need dynamic dispatch in noir in a language like noir. So like there's no point trying to do that. So yeah so it's a rest like syntax language. It has an intermediate representation. So any Noir program compiles to Acer and it's an intermediate representation. Any prover that works with Acer also works with And then it's highly optimized for client side proving. That's where the edge is like like before this we only had circom and it's a very complex looking like has anyone here written like anything in circum? Like has anyone Oh yeah. Oh yeah. So like if you all

know the pain of writing circum right like it it looks like this very uh alienated hard uh language doesn't look like anything that we have mostly written uh our computation in so yeah noir is very rustlike very high level it has a rich standard library and yeah rich ecosystem of apps and and and it's maintained by the og a team so the highle pipeline of noir is that you have a noir uh you have a noir program It compiles to Acer and then you can execute and gen you can execute it. So like the process of executing it is basically generating a witness and then any prover which is compatible with the aser representation and the noir

pipeline can then go ahead and prove it. So uh yeah so that's like the highlevel pipeline and let's look at a real like working noir program. So, I'm going to open my cursor. Uh, is is the code visible or is it like too small for people at the back? I need to zoom out. Okay, cool. Is this better? >> Oh, yeah. Cool. Let me try to make it fit. Real estate screen. Real estate management seems to be quite a real problem. One second. Command B. Okay, cool. Now I think it should be uh good enough right like visible for everyone

now. Okay cool. So uh here's what a noir program looks like right like it has if if you written rust just like main you have a main function which is the entry point for your binary like here you have a main function which is the entry point for your circuit and then you have an uh in like you can have like any sorts of input configurations that you want here. So for example we have this input here and you see this word field. So field is a fundamental data type in basically any uh zk cryptographic construct. Uh just like you have a U32 U64 we have field elements here. Field elements have their own properties. They wrap. So for example uh they have a they have a

certain bit size and a specific prime number till then which they go. And if if your computation overflows from there rather than throwing you an error like the number will wrap uh so it's basically modulus happening there like you're basically working in doing doing mod every time the number overflows but for now like just think of it as like an unsigned integer and in most of your cases you won't even overflow the size of the field. So right now just think of a field as an unsigned integer but it has some special properties in case of an overflow like the number would just wrap back and then uh here's the written of your is the written value of your circuit which for now is a boolean so a true or false. So what is our program

trying to do? Our program is trying to check that if a given input here belongs to one of the elements inside the array. So like this is an array of five field elements 1 2 3 4 5. So you can think of it as checking some sort of a membership proof in a list and then you loop through the length of the array and then you check if one of the elements in this array uh is basically whatever the input value is. So it can be very useful in certain scenarios where you want to do membership proof checks and things like that, right? So uh so yeah that's that's basically what a noir program looks like. Now you might have seen this one word called public and the word pub or public means very different in noir than

what it means in rust and most of the other languages. Public means that this piece of information will be shared with the prover and since we don't have since we don't have the word pub before our input this piece of information won't be shared with the prover. So when we would run this circuit right now and when we would prove it we won't actually be sharing uh yep second. Yeah, we won't actually be sharing this input element. Uh so basically what we would be proving is that I know one element which is either 1 2 3 4 5 but we won't actually share which one it is and the pro and the verifier would know that you know any one of the elements out of these five elements but the verifier won't

know which one you exactly know right so uh so yeah let's let's uh test it out so the first step is so you can download the noir uh tool chain later on from here and everything is available on my GitHub I can uh share at the end of the talk but yeah like this is how you can install it uh there's no need to follow along right now you can just watch me doing it and later on try it for yourself but we have separate noir talks so feel free to visit them so yeah like we are going to do the first process is to compile your circuit so you do a compile and yeah basically what happened here I think we can bring back the file explorer yeah I can delete the target folder

so that I can see everything happening from scratch. So I come and I say nago compile and then you see a target folder has been made. Uh and we have a compiled circuit right and then this has like a lot of intermediate data uh that is then needed to generate fitness and and and proving stuff right and then you see there's this file called uh so we also have to run this command called nago check and this will generate this file called provertoml. So let me do that. Yeah. So uh once uh yeah you would have to like right now I already have the file but when you would run it like it will generate a proverl and this has an input uh field here that I can set to

whatever I want right now it's set to seven but whatever I will assign as the value of this int would be whatever would be the value of the input here in this uh main function. So for now let's try a real scenario where it should work. So let's say I'm going to say uh yeah I'm going to say I know an element two and then I'm going to second it looks like I have shifted to Greek. No. Oh yeah. So I'm going to let's say I know an element two and then it's part of the list. So like when I'm going to prove it should actually work. So the first step is to generate a witness and a witness is basically an execution of this circuit with some specific data. So in our case it is execution of the circuit with this input data 2. And then

uh when we say see here like we have generated this uh we have generated this file called this GZ file and this contains the witness data for this specific circuit. Why is it not showing up in my target directory here? It's interesting. Second. Oh yeah, it's here but like it's not actually showing. It looks like the cursor isn't updating but I can see it on the CLI that the file does exist, right? And then the second step is yeah then the second step is actually now uh proving it. So we did now go execute and then we can use a prover which we have which is BB which is the

prover that is maintained by the AIC team. You can check out our GitHub. The installation instructions are there and then now I can generate a zk proof of uh this fitness on on my device locally. Just a second bb proof and then yeah I'm saying that the circuit file is here and then I'm saying this is my witness file the specific execution of the circuit that I want to prove and then put the proof in the target directory. So now when I do this again it looks like uh my my directory isn't updating here but if you go and say ls target we can see that there's a proof file and there's a public input file and the public input file is whatever is the public

information related to the circuit which is the written value and while the proof file itself is basically the zk proof that the prover can use to verify. So I can say BB verify and then I can so I have to now firstly generate a verification key. So I can say BB uh it is yeah I think yeah BB prove and then there's this thing called BB verification key. Yeah BB write VK right. So now this will create a verification key and a verification key is a key that you use to verify the computation of the circuit. So uh yeah, so we now just created this specific verification key.

And now this verification key is also what is used when you use uh when you're verifying your proofs on chain. Let's say on a solidity contract. So you have the ability to verify the proof here. So I'm going to say BB verify and then second. Yeah. So like I'm saying that this is my verification key. This is the part to my proof. These are my public inputs. Let me bring it back. Okay. And then when I do this, this says proof verification successful. What if I try to play with the prover if you try to play with it to say that I actually know an input uh input let's say three which belongs to uh like I need an input three

but let's say if I actually don't know know it like I don't have the proof for it right. uh so what would happen in that specific case scenario the prover will actually uh fail to uh verify it so let me uh show this around to you so what if I say here just a second click inputs oh yeah let's say I try to prove let's have a pro like a like an element seven and I'm trying to say that seven belongs to this list and then what I'm going to do is I'm going to copy this old public input file here and then I'm going to quickly generate I think every time I type it, uh, yeah, it gets out. But yeah, like I'm just I'm super quickly going to execute like a

create a new witness and then I'm going to prove this specific witness. Oh, it has to be BB proof. And then if I will now try to convince the verifier that I know an element seven which belongs to the list the by dropping this old public input file here it will fail. So if I will come here and if I say yeah replace it with the old file I'm trying to like like spoof the spoof the verifier here it it won't work. It will say no you you don't know this. Yeah you can see that it says uh yeah the second it says that the verification failed and the proof verification failed. So you can't uh

yeah you can't fake uh proofs in here. Cool. So that's basically a very quick demo of how like writing a circuit works, how verifying proof works, how everything else works. But now I'm going to show you like some real fun stuff that we have made with it. Right? So uh if you go to this thing and you can probably play it on your laptop as well like it's already uh working on this link called privacy/pool.versal.app. If you type it on your laptop, it should pop up on your laptop and you should be able to play with it. Uh what it is is that it's a privacy pool implementation in Noir and uh it's already live and uh basically the way it works is uh you have you you like it works like just

like how any privacy pool works. So you can create notes but what you're what you're doing essentially on this app is that you can deposit into a privacy pool and then you can withdraw from it by creating a zero knowledge proof that you made a deposit to this privacy pool and you have the ability to withdraw from it without revealing anything about your address. So for example imagine or imagine it as like a like a ZK like debit card, right? So I can come and deposit to this application and it processes my deposit and now I have $50 in this privacy pool. Everyone else can come and deposit uh their balances as well. So in case of a debit card like every user's balance can be on this pool and that every time you want to spend

from this debit card you can generate a client side proof. So if I come and look show you what happens on the console u you can see that uh you basically are creating nodes and you are putting this notes inside a Merkel tree and then you have the ability to prove that you are you have one of the entries in you have a one of the valid entries inside this Merkel tree. So you have the ability to basically withdraw from the pool and spend it. So for example I can spend an amount let's say uh 50 and I can say withdraw and now it's generating a client site proof. So you can see generating proof and the proof is done and the withdrawal is done right. Uh so yeah I think let me use okay cool yeah

so uh yeah so basically this is one this is a privacy pool uh that we made. It does client side proving and you can check the open source code out. It's on my uh GitHub. So if you go to uh my GitHub which would be batchpy 244 and the the whole code is available open source for you to check it out. So second I think my internet here is a little slow but yeah like I can later on share it on my Twitter as well. It's on my Twitter uh pinned there as well the code like the whole source code.

Cool. So uh that's about like a privacy pool in Noir but let's look at like so this is like one of the prototypes that I've shown you that we have built like a whole working uh privacy pool in there. Then what are other people building with it? So we have like a team called ZK passport which have been able to create client site proving of password information. This is what we have also used on used on our own platform at Aztec uh to prove uh that you have a valid passport and to be able to do identity proofs without actually sharing any of your specific information. So we do have uh the ability for that and then ZK passport team is pioneering it. Then we have the

pay network. It's a it's a it is a debit card and it allows you to pay anywhere with your card but then the transactions are not visible on a block explorer because with other cards out there it's all available. So if you are like using a card on a nosis chain like the whole explorer has everything available. You can go and see that someone is spending $2 here, $5 here and then like you could basically use all of this information to get all of this micro details about these users and it's just like out there naked on public blockchains while pay uses Noir and they have been using Noir to create a private uh payment processing network for this and yeah

noir is being used there. Then we also have this team called ZK email which is again written in noir and it allows you to prove stuff with noir uh like prove stuff about your email uh with noir like prove that let's say you want to prove that you have worked at a specific company you can just prove that you had an email from them that you actually joined it and that should give you a proof that you actually did work there. So what are some cool things you can build with noir? Yeah, second. I think it will be back.

Cool. What are some cool things you can build with Noir? Like build a client side provable game. Has anyone here played like Dark Forest? Like it was a game that used to be on X die. Uh yeah, like I I think like someone should just redo it again in uh someone should definitely redo this this game again in Noir because it was so fun back then. It was written in circom if I'm right. And I would love to see if someone would like redo this game in noir and bring all the like bring all the client side proving that we have uh in here. Uh like this this is like just a fun stuff. I don't think like this would this is like it's just fun. Like I've always been thinking that a lot of people have been writing ZKVMs.

Uh and I was like oh what if someone writes just an AVM interpreter in Noir like you get a ZKVM. But again this is just a fun idea. I'm not saying that you know like it would be the best one but yeah like this is also a fun idea. But like another cool one is taking Noir to new proving systems. So basically right now Noir works really well with with our BB uh prover and our proving system. But I think it can be pretty interesting to like hack it up to Halo 2 like hack it up to stacks. I don't know like a stockified noir. But yeah, like you can do all of this really cool fun stuff with it because Noir itself is very extens extensible. So you can just like extend it to any proving system that you want out there. So that's something

really fun you can do. But here's my favorite one. My favorite one is build privacy applications and that's the one that I really enjoyed. So like I started my career in crypto in privacy. Uh like four years ago I was working on a ZKD ID protocol and back then like no one really cared much about it like to be honest but now I think people do and that's why I think that's my favorite thing to do with Noir. That's what I started learning noir for right. So my coolest thing is to build privacy applications and I think the best place to build it right now is with Azic because AIC allows you it basically gives you the ability to create private Ethereum like applications. So right now when you're out there and developing on

Ethereum and when you're developing something like unis swap every trade is public but Aztec gives you a primitive to decide what you want to be public and decide what you want to be private. Noir is the smart contracting language on Aztec. So if you know Noir, you can basically program Aztec with it. And then you can basically build a private DEX, a private lending market. And you can do all of those things on Aztec because it's a private world computer. You can decide what you want to be private. You can decide what you want to be public. And that's what I really think is like some of the coolest things that you can do with uh with Noir. Yeah.

So another demo dam. Now I'm going to show you something really cool between Aztec and Zcash. So how many of you have heard like about Zcash here like Okay, cool. I think uh yeah that's nice to know like that a lot of you have uh like a lot of you know about it. Yeah, it's it's it's it's something that like has been it's a very old project like I think more than seven or eight years and now suddenly it's it's the one that has like been in a lot of hype and Zcash allows you to do uh private transfers. So you can do private transfers with it, right? But it has it it lacks programmability like you can't program it. So I wrote this uh piece of article where I was like okay Zcash has programmability as Zcash has just the

ability to transfer assets and AIC has programmability like you can do private program with programming with it. What if you could like use Zcash on Aztec? And that's an exploration project we did. Like can you privately use uh Zcash with Aztec? Can you have Alice and Bob in a situation where Alice can privately, let's say, sell her Zcash on Zeke and get back privately some USDC on Aztec without Alice knowing who Bob is on Aztec and without Bob knowing who Alice is on Zcash and without the person or the app which is facilitating it knowing who Alice is on Zcash and who Bob is on Aztec. So like complete end

to-end privacy. I think this is this demo is going to be tough because uh it requires internet and it looks like the internet right now is very low. Let me just check is it [snorts] just because of my mobile but yeah but then the the the construct that we're going to use here is one of a partial note. So basically Aztec has this thing called partial notes and they basically allow you to receive payment from anyone without revealing your Aztec address. So for example rather than saying hey give me my USDC on this specific address because of noir and AIC and the way we have designed our private state you can say hey give me my USDC on this cryptographic information which is a partial note I will receive my USDC but

you won't know my address you will only know that you pay to a partial node but my partial node cannot be linked back to my address so that's the primitive we're going to use Alice is going to privately send her Zcash to an intent solver on Zcash and then the and Bob is going to give the private part the partial note to pay on Aztec and this way Alice would be able to pay Bob without Alice knowing who Bob is and without Bob knowing who Alice is on their respective chains. So let's do this demo. Uh I hope it works because it requires a little bit of internet but let's see. Yeah. So we have this interface uh and then for the Zcash side of things and then we have this

interface for the AIC side of things. So this screen is the screen for Bob. This is where like you can see Bob's current Aztec USDC balance is zero. And then let's say Bob did some really hard work and now wants 100 USDC back for his work from Alice. So what Bob's going to do is Bob's going to create a partial note address to get 100 USDC from Alice. So we are generating uh like and this is happening on the AIC sandbox. So I have an AIC sandbox running in the background for me. So let's wait. Yep.

So going to happen soon. Oh yeah, it happened. So like you can now see I have this like address to a contract that holds partial note of uh partial note of Bob and then Bob's let's say has given it over signal or any chat application this partial note to Alice and now Alice is on this application which allows her to send uh USDC to Bob by selling some of her ZE. So what the app is saying to Alice is that hey if you pay some amount to this address I'm going to pay whoever you want on Aztec uh 100 USDC. So I'm going to put uh Alice is going to put the partial note

of Bob and then she's going to put I need you to pay 100. And then Alice is going to copy this address and she's going to go and open her Zcash her favorite Zcash app. So for me right now I'm running an Android emulator and then uh I can I will come here and I will say I want to send some amount and it's happening on test net don't worry I'm not burning real ze for this uh but yeah that is going to send something like 0.01 01 and yeah she's going to send it and now what has happened is that Alice has sent a private transaction on Zcash to this intent solver and she's like okay so yeah like it's client side

probing let's just wait for this to happen yeah so now the transaction has been sent and now it has sent the intent solver to give Bob back 100 USDC privately on Aztec now Bob is currently waiting for confirmations waiting for this transaction to actually get included in Zcash. So if you go and look at the current test net of Zcash, the block explorer in there, there should be something in the meool. So yeah, here's our transaction. Uh the transaction is in the Zcash test net meool and the moment it will be mined, which should be like in 30 more seconds. Uh we will get like one confirmation then like the intent is going to give Bob some USDC here. So let's just wait like for 10 15

more seconds. If you look, if you want to look what's happening in the background, you can see that the software of the intent solver is looking at the shielded balance and is seeing if the balance is being uh uh completed or not. So it looks like the block has been mined. Yeah, you can see the confirmation is there. And then what the solver did is that the solver paid back to the partial note of Bob. So now Bob privately has 100 USDC. You can see the balance has been updated. And yeah, this way like they are able to do a completely private swap between each of them without like knowing who his who on both of these chains and that's something that we made as well. It's on available on this reposit this repo called Zcash AIC private swap. So we

have this thing called Aztec pioneers and we experiment and build cool things on Aztec on this specific GitHub box. So if you have like some cool idea more than happy to put it here. All of the source code is available here for all of the experiments that I've shown you. We also have an OTC desk. I'm not going to demo that, but it gives you the ability to do private OTC like uh being able to privately swap whatever tokens you want. So yeah, so that's that's basically another demo. Uh coming back to Yeah. So like so you can like do way more than this. You can basically build a private lending market on AIC. You can build private decks with noir on AIC, private lead aggregators, like an Aztec L3 with noir. You can probably do that. So yeah,

there's like so much more to do. And I'm going to end this presentation by saying that we should like the reason why I'm very excited for all of this and why I'm like I like spending my time on all of this is because like it's the right time to do privacy. Like finally people do care. Everyone is talking about oh bitcoin is transparent and uh that's why let's say something like zcash is getting adoption and now suddenly everyone does care about this thing and there's it seems like there is a market out there for people who really want to transact privately and use their defy privately do all their financial activities out there privately so I think it is the right time to build such software and it's yeah like like when people are going to look back at this

time and when they're going to look at noir and Aztec and all of the privacy stuff that's being built out. They're going to look at it as a really cool time. That's like every day I look at like privacy software and zero knowledge cryptography. It seems like something out of science fiction and I think it's uh it's it's pretty cool to build with it. So, I'm going to say the possibilities are endless. And thank you for spending your time with me. I will be Yeah. around here. Let me know. [applause] Yep. Uh yeah. Oh yeah, we got we can have a mic here.

>> Oh why do we need like another language like noir? Like why can't we just use plain rust? >> Oh yeah, I actually answered it like in middle of my presentation. I was saying that like you don't need the whole feature set of rust. So for example, you don't need something like dynamic dispatch, right? Like like rust has a lot of features that you just don't need to build a privacy language. So for example, just take dynamic dispatch uh like then for example you could say lifetimes and all of these concepts. You don't need it to write provable software. It's just like it's just going to complicate your language. So yeah and then like yeah go ahead.

>> Well yes but you do have to create like a developer community around your new language while Rust has that already. Uh also the AI is very much trained on AI on on rust. >> So I think it does provide a lot of value. >> Keep it in rust. >> I think Zach wants to answer this. >> Can I can I feel that one? >> Sorry the stage. It's a very good point and like what what Harsh is saying about about like the restricted set and the simplicity I think is very valid. But you're also right that like there's an enormous amount of canonical like work around how to write idiomatic rust. a lot of resing resources. Um, a huge reason why we decided to make our own

language because we wanted the ability to add in very specific semantics for how to write private programs that didn't exist in Rust that would have required extending extending the language to the point where it would have been unrecognizable. Um specifically we have a lot of keywords in Noah um to do things like um utility functions where the um where where the uh the code being executed is not being proven and you're just computing witnesses and fundamentally part of it is about how to write idiomatic zk programs like checking a computation has been performed correctly is a little bit different to doing the computation and often like the checking part is actually

a lot faster and more efficient. So it kind of changes a little bit about how you want to structure your programs. We have certain like keywords um uh that aren't present in in in Rust. We wanted to extend our macro system to do meta programming in a way that Rust doesn't support. So we were either looking at building our own language from scratch or like heavily heavily heavily extending Rust to the point where we wouldn't be able to say in good faith, oh it's just Rust, because it wouldn't be anymore. Any other questions?

>> So, in order to make private transfers between accounts, I understood that a contract was deployed, right? >> Uh yeah, you're correct. >> And can you trace who deployed a smart contract? Otherwise, yeah, it just doesn't make sense. Oh, you're saying like can someone trace that who deployed the smart contract on Aztec? >> Oh, yeah. Like it's upon you if you want to make this information public or not. So let's say there's this concept of being able to deploy a contract privately. >> So basically Aztec has this thing of a where like you can you decide if you want to emit this information that you have deployed this contract or not. But if it's a purely client side running smart contract then and then if you if you don't actually like make it public

you like the contract deployment is also possible privately. So like yeah like in our specific scenario we don't basically public emit that we have deployed the smart contract like it's out there in the private state and no one knows that it has been deployed so no one else can discover it unless we consciously want it to happen. So in our scenario it was private. Okay. And another question, if the idea is to well to make it as private as possible, how do you transfer I know it's like a really specific example, but how do you transfer the information of the escrow basically privately?

>> Oh yeah. So like uh they are like so basically that's a question of you know like what mode of communication you use right and you could you could use two mode of communication right like one is which I said you could just basically give the address of the escrow or like your partial node address over signal to let's say someone like Alice and it's end to end encrypted and you it's basically free to send this information and then she can just use it to pay you and that's let's say how you both discovered this information the other way where let's So you don't want to exchange let's say this these like such a mode of communication could be that Alice could have a public key and then let's say so Bob could have a public yeah Alice could have a public key and

then Bob could privately log an encrypted log of this information encrypted to al let's say Alice's public key Alice could be watching Aztec and then could decrypt this information and should be available. >> Okay thank you. Yeah. Um I just just say that you your presentation is very cool me. It's a a great topic and hard topic for you simplify for us and then thank you um congrats for your presentation. Okay.

>> Thanks. Yeah. um the the witness, right? What what kind of information does that store conceptually versus what the the prover does or the execution of the program? >> Yeah. So like like so witness generation is basically create like it's information about the specific execution of a circuit with some information. So let's say when we saw that specific circuit execution with that specific input of two or three right so then like there's information that's very specific

to executing that circuit with that input and that's like all the information that the witness has and the goal of the prover is to then basically generate a proof around it with the ability to hide let's say information that's not supposed to be public. So let's say uh witness is when you have like yeah witness is basically the result of execution of a circuit with specific information and >> so that that would be um specific to the prover engine uh the witness. >> Uh yeah that's information for the prover that's not information for the verifier. So the prover then takes this information and creates a zk proof out of it.

If that helps or are you asking that is it like very is the format itself tied to a very specific proof? >> I guess no is like a a DSL of sorts for the the underlying prover engine. Yeah. >> Right. So the the witness if I was using a different DSL to write stark proofs you know they would generate the same witness witness file if you were writing if you're using a different DSL to write so noir is like noir is not a proving system here so let's say if you're using a different DSL let's say something like Cairo your witness would look different from what

noir would generate Okay. >> ACR. Yeah. >> All right. Thank you. >> Yeah. It won't be the same. >> Thank you. That was great. Um I was curious more of like practical side. So let's say um as an app developer, right? like privacy app developer and I am bullish on Aztec but say Aztec is still going to bootstrap its liquidity user base etc right so I'm curious to hear your thoughts on how do you guys plan on to like what set of tools do you have maybe like bridges etc to sort of

get the existing liquidity from Ethereum and other chains that could be used on Aztec for for us as app developers to make it easier to >> although this question is not very specific to the presentation but I will still say that like Uh yeah like uh so like we are actually doing this experiment in our exploration team where we are exploring that can you initially use an AIC wallet to let's say swap on other public chains while like still keeping it keeping this information private on Aztec side that let's say who made uh the swap. So for example have you used zashi like the zcash wallet yeah like you can let's say use zashi and you can like right now go and swap whatever asset you want. You can do similar techniques with Aztec with

complete privacy. On the Aztec side of things, you can basically have an intent protocol where you express your intent, you lock your funds and then you say whenever the intent is complete, please pay back to my partial note. So this way someone can go out and solve your intents for you which could be let's say swapping lending and all of those things and then they can pay back to your partial note address and then still fulfill your intent and you you like so basically you could swap on Jupiter while being on Aztec because you could say hey like I have one soul I want 100 USDC and then you express this intent privately and then someone will go on a public chain do that swap for you and then give you your 100 USDC or whatever it is on privately on Aztec And yeah, so

you can technically do that like that's the way to go.