Intro to Noir for Aztec

Transcript

All [Music] right. So, this is Noir for Aztec. We're going to go over basically the various ways that you use Noir or like we're using Noir at Aztec Labs. Um, actually, let me step back. I'll introduce myself first. My name is Josh. I lead the developer relations team at Aztec Labs. Um, been working with Aztec for a little over three years. So, I joined actually a little bit before we even announced Noir publicly as as a thing. Um, so it's been really cool to see it

launch, evolve, see how the community is using it, and just yeah, how the engineering team has been using Noir to just build this rollup um that we're building at Aztec. So in terms of structure of the workshop, I'm going to talk a bit about how Aztec is using Noir. Um then depending on how much time we have, we can actually do some workshopping things, but it's just going to be going through essentially the contract, the counter contract tutorial um in our docs and kind of like explaining the things that I mentioned in the slides along the way. Um the various ways that Norah is being used.

You got the >> uh yeah, it's right there. So I'll linger here for a moment. Um, so I'm going to talk a bit about what Aztec is, talk about how we use it in various ways, which is essentially smart contracts. We're using Aztec the network for state management and function execution of Noir programs. Um, noir by itself is stateless. So you're just essentially creating statements that are proven or verified. Um Aztec the blockchain um makes this more capable and more featureful through

state management and function execution. Um we highly leverage macros when writing Aztec contracts. Um all of the protocol circuits that enforce like the Aztec protocol rules are written in Noir as well. um as our accounts on Aztec. Um and then we're using some cool nonblockchain specific use cases in in our test net. And then yeah, the example I want to talk about is uh the counter contract. So what is Aztec? Aztec is a layer 2 on Ethereum. So it's a ZK rollup where all transactions are proven um using noir, whether that's private execution or public execution. Um, so it's it's nice to think of it as an

execution environment and state management system for noir programs because by itself noir is basically just a statement checker. Um, you have these circuits that you write and you can generate proofs of statements and then other people can verify them. Um, you need to plug those into web applications or other blockchain networks um or Aztec to actually uh make those like execute and make them make them useful. Um, so some key components that differentiate Aztec from other networks, there's private and public state and there's private and public function execution.

Um, whereas most blockchains you guys are familiar with just have these public components. So >> like other CK roles got >> Yes. So I haven't built on like alio but uh in terms of like ZK sync or like scroll or other ZK evms they they all have public state and they're not zk in the sense of zero knowledge they're ck they're using zk for like essentially um verification of computation. So it's just like validating that state transitions are correct and you can do that you can verify those transitions very cheaply and quickly using zero knowledge proofs.

Um but essentially there are zero knowledge proofs where all inputs to the circuit are public. Um whereas on Aztec and noir programs you can have private inputs to these circuits. >> And one follow uh how did ASIC change or did it change because I remember it was around like already five six years ago and uh there was some G app zk money. >> Yeah. >> Where created like a >> shut down and I don't know what what happened in between. I didn't hear about it much actually. So >> yeah. So I think this will be this is the fourth blockchain that Aztec Labs the company is building. Um the first two were simple confidential payments networks very relatively simple roll-ups so you

could send and receive money like you could hide basically send a recipient token in amount um but beyond that it wasn't very capable. Then there was Aztec connect which we launched that was like mid 2022. Um that had a bit more functionality where there was this message passing concept where you could like send bits of data from the rollup to the L1 and do things. So like we had a unis swap integration so you could do trades, you could open and close like uh borrowing and lending positions I think on uh wasn't LUSD. It was one of the it I think it was LUSD actually. Um but basically we stopped working on

those because we have we had the tech and we had the capability to build what we're building currently which is full smart contract programmability and composability um on this layer 2. So basically just focus all engineering effort on basically the endgame um and we don't need to like maintain these previous roll-ups that we've built. Um, so the biggest component of this is like Aztec is a layer 2. We have smart contracts with programmability and these smart contracts can interact with each other. Um, yeah.

>> So these smart contracts have private and public state. Um, private state is a set essentially just a set of Merkel trees stored on Ethereum. um the roots are stored on Ethereum and then we're updating these things by creating note hashes and creating nullifiers um in a UTXO based model to maintain privacy. Um you can't build a completely private system in a like public state tree architecture similar to like what Ethereum has. Um even if you encrypt all of the values in your smart contracts, every chunk of data has a specific location in that tree. So if you're updating an encrypted value, um you're going to that specific location in the tree and updating that

value. So you're revealing a lot of information just by um interacting with uh that sort of architecture. So this this private state system is built on a UTXO based model where there's essentially just a bunch of uh we call them notes um built there's put into a big tree and um those are essentially commitments to private state and then if you ever want to update that private state you have to invalidate the you invalidate some note hashes or some of that private state you invalidate some of those UTXOs um with nullif ifiers and those nullifiers are deterministically derived from notes um but they're not directly linkable without some secret

>> do the fact nullifier does that adds um a lot of latency anywhere given that there would like every single state say update is doable >> it's doesn't doesn't add latency it's a nullifier is essentially just like a essentially a 32 byt value so it's just a >> but they all have to be stored right Um yeah, so it adds storage cost. Yeah, but we like we're we're posting these like all of the updates, all the note hashes and nullifiers to the DA layer um on Ethereum blobs layer and >> yeah.

>> So is this similar to how some of >> I believe so. >> Yeah. Yeah, I'm not sure how they nullify like if they have a concept of Pedro you may be familiar with I know you've worked with semaphore before but just in terms of like making commitments and then nullifying data um semaphore has a similar >> trees >> another tree for the nullifier >> yeah yeah so the short answer is yes >> I mean to access the private state and this verifier will each user has to keep some private data in order to calculate these verifiers and use them >> yeah This gets into like um some of the deeper aspects but in terms of uh when users are interacting with Aztec there

is like we have this we call it the private execution environment but um the private execution environment runs locally on on your device and that is like basically holding your private state for you. So it has your secrets it has your information and it can generate these nullifiers to invalidate old state. Um, in terms of how it relates to NOR, in terms of contract compilation, we have a tool when you're developing on Aztec, you use Aztec Nargo, um, which is just an Aztec flavor of Nargo. It's largely the same.

If you look at our Aztec packages repo, um, we're actually just pulling in Nargo, the the Noir compiler into our monor repo at a specific tag um, to do a lot of our compilation. And private functions that you write in smart contracts are just noir verification keys. Um they're the same thing. Um public functions are different because they're being executed by the node network similar to other blockchains, but they're essentially producing AVM bite code, Aztec virtual machine bite code. So it's just like public functions are producing op codes that are then executed um according to the Aztec virtual machine spec.

functions there limitations in terms of how flexible they be click and receive and >> like you need a different function for each specific >> in terms of like >> for the for the developer experience you essentially I can show this a bit later but you basically just add like a private annotation to any function that you want to run privately on user devices and like the compiler handles making all these verification keys for you you just have a contract that may have like three private functions and four public functions. You just run compile and it produces an artifact that you'll then serve with your web application or whatever. Um and then when a user calls whatever private

function the SDK will just generate it before we were discussing how each circuit would have a different verification keys and yeah taking the simplest example of showing that your number is not equal to mine. If you give me a different guess, I would need a different circuit and a different verification key. >> So the question here is that >> you don't need a different if like just for guessing and like checking or like doing verifications, you don't need different verification keys like these verification keys when you do compilation and you generate your contract artifact, those are essentially set and then if anybody's ever interacting with that contract that you wrote and compiled um they're using those same verification keys. And actually when you deploy contracts onto the network, um there's commitments to those verification keys that you're

using in your in your smart contract, um they're actually kind of baked into the smart contract address in a way. Um because there's a bunch of there's a hash tree that's built up that includes the verification keys. Um so yeah, we have anology on private functions, sorry, public functions cannot have private inputs, right? >> Correct. All inputs to public functions will be public. They'll go on chain. Yeah. And they need >> in in >> Aztec when you're running private functions.

Practically speaking, they'll all be private inputs, but like you could pass you could pass some information from a private function to a public function. I think the next slide is on function execution. There's some interesting things with how that's set up in terms of how the code looks. Yeah. And like a difference between I say many entry points but like noir circuits define a main function in in your file and like that's essentially what defines a circuit. But when you're writing asset contracts any one of those private functions could like essentially be an entry point to like they're just all circuits themselves. Um so I touched on this but private state is represented by notes. There's a note hash tree that holds commitments to all

of the private state on the network. So when we're sending private notes, like we're sending tokens to each other privately um and updating this private state, all of those updates are going into this note hash tree and changing the the root of that tree. Um when I want to spend notes, I need to nullify my old token notes and I need to create new notes for whatever recipient I want to give them to. Um, and I mentioned, yeah, nullifiers are deterministically derived from notes while remaining unlinkable for privacy reasons. Um, and then when I create a note for somebody, I want to make sure that they receive that note information so they know that they should add this note to their private execution environment and they

should be like, "Okay, Josh sent me this note. Um, I now have it in my database so I can spend it." Um, currently we're encrypting that note information and putting it on chain so someone can just scan the chain and find all the notes that are relevant for themselves. Um, but we're going to I think we'll add uh flexibility around this in the future just to reduce cost and um yeah makes it makes it more flexible. Um public state management is just like other public blockchains. So your mental model for how other how blockchains traditionally work maps. Um there's this weird case where um we actually have this cross between private and public state where since

these private and public are happening in two different execution environments, public state isn't directly readable when you're executing things in private and private state isn't directly readable when you're doing things in public. So we have this special data type called shared mutable. Um it's shared because it's shared between private and public and it's mutable because you can update it. Um but yeah, it's there's there's some nuance there. I'm not going to go into the details, but um it's one of the difficulties of working in uh this system where there's uh multiple function execution environments.

>> Shared mutable. Yeah. Um so I mentioned there's private execution and public execution. Um the reason we have these two different execution environments is basically to maintain like as much privacy as possible. And if you want things to be truly private, you essentially have to execute them yourself. Like you can't send your secret data to a third party in the cloud or to a remote blockchain network and have them execute information for you because as soon as your secrets leave your computer, you can assume they're no longer secret, right? Um you're trusting some other third party to maintain your secrets for you. So you have to do private computation with secrets locally

on your machine. Um so when you're doing private you're doing this in your private execution environment that we've built um for interacting with Aztec network. Um this private function execution is going to produce outputs that you send to the network that are then verified using the protocol circuits and then um public execution happens remotely on nodes just like on Ethereum. um like when you do private execution, you're going to produce a proof of correct um execution. So when you run you execute these private functions, you're going to have private inputs and you're going to generate a proof that basically says, "Hey, I'm interacting with this contract. I have these inputs and it successfully executes it spits out a

proof. There's also going to be these note hashes, which are commitments to private state updates." And then nullifiers if you're invalidating previous state, you're basically sending these three things with some other things. um to to the network and the the Aztec nodes are going to verify those proofs and the inputs that you provide and basically say okay what Josh executed privately locally is following the the the rules of the contract that he's interacting with as well as the rules of the protocol defined by all of the nodes running running the Aztec software. Um >> so if I just as a web 3 dev if I want to like go beyond the contract and like um

>> basically verify things for for example data availability level level check does this does this correspond to state as much as I can see that from private state and has this been nullified yet so you know these kind of things might do on either scan if you real just hit Ethereum. Are there tools for that or does it kind of have to all go through like state calls? >> We have so we're posting all this data like so you can recreate the state tree basically um all the necessary state trees on >> um you it's it'd be kind of a manual

process right now. But we don't have the tools like cuz we're currently still like working on our test net. Um you can go to like block explorers now. Block explorers are getting more featurerich where you can see all of the note hashes and nullifiers that are generated as part of a transaction. Um all of the logs that are emitted um I think Aztec scan is adding contract verification. So you can basically upload like the artifacts and basically say oh yes this contract that I'm interacting with has this functionality. Um, so we're getting there, but yeah, right now it would still require like a good chunk of manual work. Um, but in theory we could build these things. Yeah.

>> How do you deal with race conditions? I'm just like thinking of the ZQL model as now as far as I understand there's a centralized sequencer that sequences transactions and then proofs are generated not for each transaction but for blocks or like even sequence of blocks like these 10 blocks all together in this sequence are valid. But if I exit, say we have some kind of DEX and I want to make a trade and I do a local proof with some private state on my laptop and you do the same on your laptop, our transaction conflict and only one of them can be valid. So >> how how is this resolved?

>> So private state is scoped to specific accounts. >> So typically you're not going to be updating private state that somebody else also has access to. this is private to you like someone else would not be able to access that piece of information because it's like has your it's basically scoped to your your account. Um Dexes are an interesting example because for a lot of the current DEX designs we have it actually requires public information in terms of like how many tokens are in the pools. Um that's how you determine the price. Like that part actually needs to be public. So like if we look at building dexes on Aztec what you actually get in terms of privacy is you don't know someone can do a trade it's going to actually have some

public execution component which is the actual swap. Um but the private privacy that we get is we don't know which account is actually calling like doing the trade. Um so you basically get account privacy but you don't have privacy of like which assets are being swapped or how much is being swapped. Um, and since that's happening in public execution, it's like with on a on Ethereum today, it's like many people can be swapping ETH for USDC at the same time on Uniswap and the block builder just chooses the order in which to execute them. >> Can you maybe give an example like which is the like what could be the use case where it would be um valuable for me to update it but no one else has access to the state. So it's not like some shared

state but state linked to my account specifically. >> Yeah. Um what I'm particularly interested in like voting applications and like interacting with Dows where essentially you can basically validate that someone's in a specific set um to part to do some onchain action. It's like, okay, to participate in this vote, you need to be hold these tokens or have this NFT or or something like that. And then you could um hide which users are actually voting on things.

>> So, if I want to vote, then what is my private state and how >> um you could have like a certain number of tokens in your private state that qualify you to participate in a vote or you could have like a specific NFT that's been issued to you that allows you to participate to vote. So you would like in private execution you'd do that check um that this that you qualify to vote and then after the private check you can um in Q a public function call that basically actually does the the vote >> just proving I don't like in this use case I'm I'm not executing anything on my private state I just prove that my private state is in this like satisfies this requirements proof and the proof

allows me to pro proceed with the public execution, right? >> Yeah. Yes. >> But you actually will define the private property because you don't want to allow to multiply allow you need to say use a right variable like budget and it's false and then I can only produce a proof if I simultaneously switch it to true and then I can no longer produce any other proof. Right. I I don't know the specifics. No, but for example, I guess like can >> a cool pattern that I've seen is for like voting specifically is you can actually use the nullifier tree for whatever you want. You don't have to use it specifically for like updating private like invalidating previous like note commitments. So you could

create a nullifier like somebody participates in a vote and you just have the smart contract emits a nullifier um based on some conditions like based like maybe it hashes message sender. Well message senders can be private so that's not a good uh input to the nullifier generation. But you can customize how you generate a nullifier and then emit that. So if the same person tries to call the vote function twice, it's going to fail because a nullifier for that person already exists. But you need a way to like generate that where it's going to be deterministic for this the same user multiple times.

>> So just as a followup um about the private public u thing um they're separate, right? So you can have um private tokens but then it wouldn't be possible to actually trade them on a public unis swap pool. So in our current there's like we're figuring out what token standards look like on the network currently. Um we've been working with D5 wonderland on this and they have a pretty good standard. They have a repo where it's published and it's I think they shared a blog post recently. Um but the design pattern there is is like there's in a single token contract there's often times a public balance and a private balance. Um and you can move tokens between the public state and the private state. So, it's like, oh, I want

to shield my tokens. Like, I have a public balance of tokens. I want to shield them. So, I'm going to put them in my private balance. Or like, I have a public balance. I actually want to send them to you privately. Um, I can make them I'll I'll remove them from the >> distinguishable from like sending them to someone else or different accounts. >> Yeah. Depending on how you're interacting with them. Like sometimes the sender recipient's public. Obviously, if you're interacting with public state, some of the stuff's going to be public, but you can look at the function interface and be like, "Okay, this is going to reveal some information." Um, but if like if I have private tokens, I want to send them to you in private. Like the only thing you see on a block explorer is like someone did something. You don't know who you

don't know what contracts being interacted with. You don't know what the execution logic is at all. >> Yeah. Yeah. Good. That could just mention the null right tree. So that means that you can basically introspect into the availability into the nullifier tree in one. >> It would be you'd have to look at like the transaction history of Aztec to see which like nullifiers are generated. But yeah, you could reconstruct that and see like all the nullifiers that have been generated. >> That sounds quite big then. So you have to feed in basically the whole tree or feed in like all the tree in order to in order to prove that something is

nullified or not modified. >> Yes. >> That's more efficient than just maintaining the state. >> Well, >> I don't know. I' I'd have to like try it and see. Um >> again the modifier cannot be linked to the the modifier is a commitment to something right so if you cannot link what you're committing then you can just store it in a tree in the ving contract right there >> you could generate the nullifier in a private function and then pass it to public and it gets emitted and >> I mean you're just making sure that we emitted this specific fire for this

specific application right so usually the only fire at least in the focus it takes some information which restricts the scope of what you're notifying. So for example, it could be the string body plus system secret. >> You just need to practice. >> Yeah. And the protocol rules will check like if a nullifier that exact nullifier already exists, the transaction will fail and it will revert and it won't won't apply the updates. Um yeah, so private execution can incue public calls. So you can actually be executing a private function and say oh I want to execute these three public functions as a result of this private execution um and they'll all succeed or fail atomically. So like if anything in

private call private fails the public execution won't happen. If a private function call incues public calls and any of those public calls fail the private state updates associated with that execution will also not be applied. So it essentially reverts. Um so similar to how you understand Ethereum where like if any of the transaction logic fails um the whole thing reverts. If you call the public functions after a private function, it's obvious which function you called it in.

>> Sorry, >> if you if you if you chain some public functions after private function, then you should give him visibility into what function you called in, >> right? Yeah. So, you can incue public function calls. All of the inputs to those public functions will be public. They'll go on chain. Um and then you do reveal information about like which contract is calling those public functions. So if if you're calling um yeah there's a there's some bit of information that's revealed there.

Um we have these various contract macros that are used frequently when writing contracts. So like um writing a contract looks like a no program but it has has these annotations um for these macros. It's just private functions get the private annotation which just injects relevant private context um when it's actually doing execution. Um same with public. There's view functions that are essentially readonly contract functions. So if you want to get state from another contract it may expose um a view function that allows you to read that state from another contract. Um there's a utility annotation which is essentially an unconstrained

function. Um and I don't know if Pedro talked about unconstrained functions in the previous workshop but essentially there's no there's no constraints on these functions like they're not actually doing um generating proofs or like enforcing the computation. So it's a way to to generate like optimized um well in the case of Aztec you're basically using unconstrained functions when you're not doing onchain execution. So if you just want to like do off-chain reads of some state of a contract, you might define some unconstrained or like utility functions in your contract that say, "Oh, I just want to like return some of the state variables." And like this is for your private execution environment that's running in the

browser or like in a wallet. And you're just like using this utility function to like read contract uh state. Um that's primarily how they're used. And the reason we don't need to enforce like constraints on the return values there is essentially you can assume that the incentives are aligned for you to be reading correct data right like you want to be reading the most the correct data from the the contract. Um so we don't need to constrain that output. We're we're doing it for ourselves. Um we have an initializer annotation which is essentially just a constructor. Um it's

not required that you call initializers for calling all functions. Um but if you want users or if you want a contract you can enforce um that initializer function is called before any other functions if there if you require some setup or something. Um we have the note annotation for actually defining um what notes are and this basically just adds some additional methods to um the strruct like it adds getting a note ID computing the note hash for that note that you define how a nullifier is computed how to pack and unpack it for um efficiency there's a storage one for defining how storage is laid out in the contract and

then um one for tests as well similar to regular noir We're using Noir for all of our protocol circuits which is doing proof verification. Um we're actually doing a bunch of recursive proof verification. So all private function execution generates proofs. Nodes are verifying those proofs and then also generating proofs of correct execution which includes um the verification checks of private execution. And then when we're building blocks, we're doing uh recursive tree building uh proof generation and verification of all the transactions in a block. So ultimately we can build a transactions tree and then a proof of a whole block and then submit one proof to Ethereum that when it checks is basically says oh all of

the private execution and public execution included in this block is valid and follows the protocol rules and the application circuit rules um defined by the smart contracts that are called. the protocol circuits ensure that state management is done properly. So it's tracking these note hashes and nullifiers and it's validating the state transitions. Um yeah I mentioned how it's aggregating all the proofs. Um one of the advanced or more advanced topics in Aztec is account abstraction but like essentially every account every account on Aztec is a contract. Um there's no concept of like externally

owned accounts. There's nothing that's just controlled by a private key. Um it's essentially just a noir program that has a specific function implementation um that does a val essentially an authorization check and that authorization check can be anything. So like our example account contracts in our monor repo right now do like verify shore signatures and ECDSA signatures. So you can use keys but like this is just a noir circuit. So you could have the circuit be like a password checker. Like you could have an account contract that's just controlled by a password. Or you could use like ZK passport proof check to basically say, oh, someone needs to be able to provide a proof um of a that they have a passport with this um ID or something to control an

account. There's a lot of cool things you can do with this, but like um yeah, it's very unopinionated at the protocol level. Can you >> can you control to account twice at once with this idea like because this is similar to Bitcoin you take some model like you run a circuit or a script and you can fill in whatever you want these are just basically there is no and so on. >> So can you control two accounts at once just by proving that they can access more than one?

I don't know what that would look like in practice in terms of um transactions have to originate from some place and you basically think of account contracts as like an entry point of a transaction onto the network and the account contract is then going to call other >> Part of the proof that's my question with me. So the target of the transaction not part of the proof that's like an >> um I guess it would be part of the proof in the sense like you're specifying which contract you want to interact with. um when you're generating this when you're generating an Aztec transaction.

So you would specify like oh I'm going to like create a transaction that interacts with this contract calling this function. So you're like specifying the entry point of the but like you could have account contracts like maybe similar inputs could go to multiple contracts. Um but >> is it realistically impossible to offiscate or hide the logic that um uh an account contract would use to to verify your >> Yes, >> it is.

>> Yep. You could actually use you could have an account contract that is not actually even deployed to the network and use it um to send transactions to the network because um essentially this is gets pretty in the weeds but um there's a hash tree that has a whole bunch of inputs or like various things that basically ends up in the account address. So or the contract address. So the contract address essentially includes a commitment to all of the private functions that are included in that contract. So if I'm executing some contract logic, I can prove that

just with that address that I'm interacting with that that address includes some private functions, some private function logic. Um and that private function logic might be account authorization logic for sending um interacting >> private function logic. You mean the actual function is private like you cannot see what the function is. >> Yeah. You don't have to publish that anywhere. >> Yeah. So you can you can have complete like we could we could deploy an escrow contract or something similar where um well we wouldn't even we wouldn't technically have to deploy it but it just has private functions um and we use that to escrow some funds and then it's like release funds based on

some conditions that are met. But we technically wouldn't even have to we wouldn't have to publish the code anywhere to so nobody would actually know what that logic is and we might not even have to deploy the contract actually deploy the contract to the network depending on um what what it's doing >> just a hash private function >> the the contract address. Yes. So the contract address essentially acts as a commitment to all of the code in the contract itself. Is every private function its own contract then or can you one contract with public and private functions?

>> Yes, the latter >> and then how would it be represented private functions? >> Um well they're like if we if I don't deploy the contract anywhere um well with public functions that contract does have to be deployed because essentially the remote network of node operators is executing it. So you have to deploy a contract with public functions to the network. um because you're having these other people essentially execute the logic. Um but with private functions that they're not executing anything. So if you just have this commitment to specific private functions that are in the contract with with the contract address um that's sufficient to ensure that anybody interacting with that

address is following rules defined in whatever specified. >> You wouldn't even see that on that same contract. >> Correct. But if I wanted if I wanted anybody to interact with that contract, I'd have to give them the code so they could execute it on their side. So like if if you and I have a private escrow, I'd have to like write the escrow and then give it to you and then I can execute my part, you can execute your part. But as far as anybody else is concerned, they have no idea what the heck this thing is even doing. It's only interacting with private state. Like they don't even know what the side effects of this interactions are. It's all encrypted. It's just generating note hashes and nullifiers.

>> So, so the nodes which are running this, they would obviously have some kind of code that have to verify that it is correct or not, right? >> But that code would by that point be so it would be so offiscated it would be it would basically be an offiscated circuit. >> Yeah. So that's basically protocol circuits are like they're not well documented currently like we have some old designs in in our unpublished docs in our monor repo but like yeah a lot of the protocol circuit design is going into like hiding a lot of information between various steps of like the recursive proof aggregation and like yeah making this flexible but also like maximally private.

If I want to send valid just I want to say the true is is that a public function on the contract as well. >> It depends on how the tokens well you mean on the L2 >> native coin like on your like if let's say >> um it depends on how the token's written. We don't have a native coin like on the L2. >> Yeah, I don't touch on this concept of protocol or portal portals at all in this presentation, but we essentially have this um way to pass messages from L1 to L2 and L2 to L1. And like we can basically link um any contract that's deployed on Ethereum L1 to any contract that's deployed on Aztec L2. Um, and

they stage messages to go back and forth between each other. And these are just they're just arbitrary messages essentially. So then, uh, like bridge developers would say, "Oh, I received this type of message that scopes from this specific contract address. I'm going to mint tokens." So like the idea is somebody would send ETH to the portal contract on L1. And then they're allowed to mint corresponding ETH tokens on L2. >> Yeah. I mean, but it's on L2. Yeah. So there's that it's locked in L1. Yeah. And then where like let's say I mint ETH on L2. I send you those tokens and you're like, "Oh, I want the ETH out on L1." You send the message, it it burns the representation on L2 and then you can pull it out of L1.

>> Yeah. And then on L2, that token contract could have private state and public state >> or it could have only public state or could have only private state. It's like very up it's up to the developer um on what they want to do. But generally I think most tokens are going to have private and public state components and then users can just be like oh I want this to be in private state and have complete confidentiality or I want it to be in public because I want to swap it or I want to send it publicly for some reason or whatever. Um there's flexibility there. I wanted to mention just like ZK Passport that we're um working on integrating with our test net in like a nonblockchain way at all. Um I don't

know if you guys saw ZK Passport. It was in this room um just before a workshop on it just before this. Um but the problem we're seeing right now is like test net is essentially a proof ofstake chain um with nothing at stake because it's a test net. So we can't have people staking real real things. So like we have a civil problem. a bunch of people are spinning up a bunch of nodes and it's unreliable and there's a lot of bots like airdrop farming or whatever. Um, and a cool thing a cool tool we can use for this is ZK passport which essentially just proves the idea is it proves you're a human and bots won't have access to these proofs to um basically say run the node. So like we have this Q to join the

validator set on our test net. Um, currently it's gated because of this problem. There's nothing at stake. we can add uh ZK passport check to the queue and it's actually onchain on L1. Um so it's gonna be an onchain passport check that allows a Aztec validator to get added to the queue. Um and then we're going to add 10% of the current size of the network to the network every day. So we can like if we have 500 validators running on the network um we'll add 50 validators the next day. So we can actually um get more people into the network participating um while maintaining network health. So that's a

cool way that we're using noir kind of like outside of the blockchain context. Um but yeah, there's a lot of cool things you can do obviously with noir that are not not just on blockchains. Um for examples, automated market makers. I talked about public token pools while maintaining user identity privacy. We talked a little bit about private voting. Um, and then there's this counter contract example that I could run through. I don't know if we want to run through the counter contract example, but uh what we're at 115. Um, I might skip this, but uh

it's just linking to this counter contract in the docs. So, if you just go to the docs, go to the build tab, um maybe I'll talk through it real quick and not just go through all the steps. Um but it's the first contract tutorial where um have any of you guys used the Aztec sandbox at all? It's basically just our execution environment without the networking side. So um it's a place it's like a local development environment. So you can just like spin up the execution environment, start writing contracts, deploy them, do

some basic interactions um before going to test net because test net is in development. Um it's it has been quite stable. I think it's actually down right now. Um, >> it's not a test. >> What does it do? >> What's the question? >> Yeah. What does the sand box like? Is it It's not connected to a network. I just said, >> correct. >> The idea is you you use it to develop uh contracts quickly. So you can basically like in this example, you write a counter contract. Um, if you start the sandbox, it just

instantly mines transactions. It doesn't actually do proof verification or proof creation. So, it's super quick. Um, it just reduces the feedback cycle and the iteration loop for for building. >> Yeah, exactly. So, the idea is you develop your first versions of your contract on the sandbox. Um, get rapid feedback and then once you're like, okay, this is actually pretty cool. tools in a place that I want to like share with more people. Then you deploy to test net um and then yeah that's a >> widely available more full tail so we can >> um >> I'll say

is sandbox in browser or >> it's just running in your terminal. >> Um it doesn't have a browser component. You can actually submit all. >> Yep. And actually uh I built this starter repo um which is a really nice way to get started. It basically does the project setup for you. Um if you don't want to have to like copy paste contract stuff, this is definitely the easiest way to go because what you should be able to do is just um install the sandbox and then uh like run the tests that are defined here. So if you want to do a bunch of stuff like quickly, um these tests are a good example of like

this is a voting contract example. Um this has like tests defined of like setting up the sandbox, deploying the contract. Um casting a vote, ensuring that people can't vote twice. Um so there's like predefined tests here that you can see you can run. You can actually write tests. Um TypeScript. >> Sorry. >> How come that was in Typescript? >> These are like the integration tests. So like um I mean we're writing all of our tests internally in TypeScript as well.

>> SDK. >> Yeah. So we have the AztecJS SDK which is um all of our SDKs right now are in Typescript I guess is the is the answer. Um our node software is in Typescript as well. Can I generate storage proofs and verify? >> You should be able to. Um, >> there's some specific flags you'll have to add. I can look for those. There was a recent question on Discord about doing that. >> Yeah, I think I asked that >> cuz you want to do recursive. >> No, I want to verify state on a >> right. So, do you have an Ethereum storage proof like in Noir already?

>> Uh, no. I haven't tried it out. >> Okay. Yeah. So, there's what you would do. This is pretty cool actually. You can you can verify any Noir program in an Aztec transaction um like in private execution. So like in this example, you want to create a just regular noir proof of some Ethereum state. So like the noir proof will take like an Ethereum block header, um a contract or like whatever information you need to actually verify that state. Um, and then that's going to generate a proof. You're going to pass that proof as an input to an Aztec transaction. And you basically want to verify that proof is correct in

the as private execution of an Aztec transaction. Um, which should be possible, but like that's a pretty powerful primitive when you think about like you can just generate any arbitrary noir program proofs and then verify these in uh SX transactions. Um but yeah should be possible. So just uh real quick on Aztec starter um we have a you can also write tests and execute them in like noir itself. So similar in like to how foundry you can write tests in solidity and just like run your tests in solidity. It's like kind of handy for various reasons. Um you can do the same thing in Noir. This

is like I'd say it's mostly good. It's it's definitely not fine-tuned. It's not perfected. Um but we do a lot of testing in Noah itself. Um I think one of the most handy things is the scripts that are defined in this Aztec starter. So there's like very simple TypeScript files that just show how to deploy contracts, deploy accounts, handle fees. Fees is actually quite a tricky problem on Aztec. Um I don't it's not a tricky problem. It's just uh very flexible which makes it a little difficult to understand like what's possible because you can just do a lot of things with it. We have fee

abstraction where anybody can pay transaction fees for anybody else. Um that flexibility comes with some um considerations. So this example shows how to pay all the fees and all the ways. Um >> you say like metering. >> Yeah, there's metering. Um, gas is interesting on Aztec because when you do private execution, you don't have to pay the network to do execution for you, right? You're generating you're doing the execution locally in your private execution environment. Um, nodes are just checking the proof and then there's going to be state updates with note hashes and nullifiers. So, you have to pay for those. But then there's public execution that has metering of like op codes certain amounts. Like these nodes have to execute this stuff. So like

there's a familiar concept of gas in public execution >> in the AVM. Yeah. Um but like you can think of like you can have arbitrary compute in private execution because like the network isn't doing private execution for you. You can do a whole bunch of execution in private and it's not going to necessarily cost you more in terms of transaction cost. It will cost you more in terms of proof generation time for a user that wants to create the proof of the transaction.

>> Pretty much fixed cost. >> Okay. But where does the verification? >> Yes. But it's pretty much a fixed cost like small amount and it's not going to like doing more private execution isn't going to increase the verification cost. So it's just like fixed cost per transaction. in the previous workshop doing the verification and sh for that circuit was very expensive but that's because >> it's very expensive but that's also fixed cost essentially like he's like oh it's 1.5 million so that's verifying it in a solidity contract that's being executed by every node um >> so that's why it's more expensive like if you do it >> this this verification of an asset

transaction isn't happening directly on the Ethereum chain it's happening It's being done by Aztec node operators. >> It's not even the AVM, right? Is it is it the AVM or directly in the clients? >> It' be be on the nodes. >> Maybe the question is is the BM gas optimized because you could say, you know, verify proofs cost 10 gas fixed you can say it's part of the protocol then and it's cheap. >> Yeah. Yeah. >> Right. But the question is do you have like special optimizations in the sense to make proof verification cheaper? >> Um, we haven't gotten to optimizing that yet. It's still pretty cheap. Um, yeah, and we also haven't gotten down to the specifics of what gas or like this pricing is going to look like. Um, like

what's the real cost for node operators on their hardware and then um yeah, we're we're still have to refine the fees piece, but >> wouldn't make sense to have it, right? >> In the AVM, >> the verification of these proofs of private consultation, you want to have it as cheap as possible. So, it would be on the clients directly, right? would be native execution. >> Well, no, it has to happen on the nodes because you can't >> on the nodes, but like not in a VM. >> Probably not in a VM. >> Yeah, it'll probably just be part of the node software that everybody's running, but it >> just like have pre-ompiles that are not, right?

>> But it does be okay, that's pretty much it. Um, no, that wasn't like super noir focused, but I and it was like kind of like a whirlwind of what Aztec's doing, but um, I hope you guys learned something. I hope it was interesting. And uh, if you have questions, let me know. I'll be around here all day. So, you guys like I saw like is doing like a right now. Yeah.

>> Do you guys provide boot camp before you have an instructor? >> Not currently. >> Not in the near term. We just don't have resources unfortunately. >> Um is are they doing a boot camp or is it just I saw that seven hour course that they published? >> It's on their website. So it's like uh just seven hours or they have it split into chapters of four different >> like self-paced self-paced. >> Okay. >> But no. >> Yeah. No, we definitely we've worked with other teams that do boot camps in the past. I'm definitely interested in that. But like in terms of like what we have to work on and like the resources we have, which just like >> we have not recently um they're top tier for sure.

>> Yeah, I'm really close to if you're interested. I can move along pretty bad. >> Um, >> yeah, I think it's we're getting close to auditing Noir. I think we might have even started doing like internal audits on the compiler. >> and like once we get like version 1.0 no stable released, it's going to be a lot easier to like do a heavy investment in this sort of thing because like this has been changing so much over the past year that it's like we can't invest in these like more heavy resources because it's just like obsolete. Like even the civer people messaged us and they're like, "Oh, we were creating a course and we were using version 1.

>> 0 beta.3 in our course and now it's.7 actually." So it's like and like the.3 version of the docs is gone and that's what they're referencing in the course. >> I saw the first like hour and that's what they said. So like we use 043 just FYI. >> Yeah. But and like that's not in the docs right now. And like the docs are 99.9% the same. >> Um but that version number is different and it could cause some confusion. >> Yeah. How does audit work for the compiler? I mean is are you guys doing external audits?

>> We are doing external audits. We're doing internal audits first. Um, just cuz our team's obviously the the most aware, but if we're we can't only do internal audits, right? Because we're we're too close to see certain things. Um, so we do have external audits staged as well. >> External audits. Do you call like Spirit or something or call the security firms or >> Yeah, Savio's been talking to them. Savio is here. He's the PM for Noir. Um, >> his name is Savio. >> I'm interested curious on that side, too. >> Okay. Yeah, he's he's definitely the man to talk to. And like I imagine we'll get at least partway through our internal audits before we're going to do the external engagements.

>> Yep. And then there's also the proving system side that we need to get audited. I mean, that's crucial for the Aztec network. >> There's like a $20 million fund right now. >> 20 million >> for ZK VM, I'm assuming. the whole stack >> like provers, the VMs, compilers, all of that. And a lot of people know that. >> Nice. >> Yeah, I should introduce you to Savio. >> Cool.

>> I'm doing a workshop later on vibe coding >> Noir. Yeah, it's like 2:30 or something. >> And >> I'm just going to show tools that I found to be interesting >> and I want other people to come. If you guys are vibe coding stuff, like come share tools cuz like literally every day there's new stuff and there's not enough time to explore it all. So, it's going to be collaborative and