Aztec Foundations: Protocol Architecture Overview

Transcript

Good morning, GMGM. Thank you everybody here for taking choosing [music] to spend your time at our third inaugural Noacord. >> Amazing. Thank you. Hello everyone. Welcome. My name is Kieran Nightingale. I actually work for a company called Siphon, but at the moment I'm working with the Aztec team to help them with some technical education. So that's why I'm here. And yeah, so we're just going to do an intro to Aztec. This is going to be pretty informal. So, it's more like a chat. Uh, it's going to get more interactive later in the day. So, Josh is going to be doing a run through of getting your development environment set up. But before we do any of that, we need to understand

what Aztec is. So, what the hell is Aztec and then also how is it different from Ethereum? So, because things have private state, which hopefully you guys know, but if you don't, no worries. then it is a a little bit different from Ethereum and Ethereum compatible or Ethereum equivalent chains. Um, so you need to know about those differences. This is pretty quirky stuff. It's a bit weird. So if you don't understand it in this session, I'm not worried at all. I kind of just want to give you familiarity with some of the concepts, some of the words so that when you hear them, you're like, "Ah, I kind of know like what that sort of means." And then you can go back to the documentation, read up on it again, read around the subject. Um, and hopefully it'll just

like keep repeating because repetition is the mother of skills. So, and I keep talking. I I talk a lot is what you're gonna find out. So, yeah, let's get on with it. Uh, there was something else I was going to say, but I can't remember what it was. Oh, it Who here is a developer? Can I Can I see a show of hands? Yay. Amazing. [laughter] I was banking on that. So, who here knows Solidity? Solidity developers also amazing. Thank you all for being here. Um, and then also if you if that you already know all of this and you decide halfway through that like you want to go to a different room, I'm also not worried because I've been in talks before where I'm like, "Oh, I feel like I should have been in a different room."

If you want to leave or come in and out, like that's absolutely fine with me. So, also feel free to do so. That's what I was going to say. Yeah. So, the prerex, what I'm going to assume you know, which apparently you all know anyway, which is amazing, is that you're a Solidity developer. You know what a smart contract is. You understand why blockchains are awesome. you understand a little bit about what zero knowledge proofs are and why they're cool. I'm not really going to be going through that. Um, and you understand what Merkel trees are and the Ethereum state model. If you don't know about the Ethereum state model, also fine because we're going to go be going through it briefly, but hopefully it'll just be like a little recap.

Uh, hopefully you all will understand why Aztec is awesome. Aztec is awesome because we have programmable privacy. What is Aztec? It's a all of these words, but I like to say zkzk rollup because I think it sounds funny. Um, but it's just a zk rollup. So, we're using zk proofs for proving state changes like normal zk roll-ups. Um, but then we're also using zero knowledge proofs for proving private state. So, I don't want pala to be able to see my balance. I don't want you guys to be to be able to see my onchain activity. So, we have privacy because blockchains are really awesome. We have transparency which means that no one can lie. We have verifiable state because you can

literally see it. But that is at the sacrifice of privacy. And in the web 2 world, the amazing thing about web 2 is that we do have privacy. It's centralized privacy, which isn't great. But what if we could have a world where we have decentralized privacy, which would be flipping awesome. And that's what Aztec does. Aztec as a top line is a privacy focused L2 on Ethereum. So if you take one thing away, it's that if you don't understand anything else from the rest of this presentation, I don't really mind. It's just that just this. So we got private state.

So Aztec has two different types of state. Not everything on Aztec is private. That was my assumption when I started learning about Aztec. I was like everything in the whole of everything is private. That's not the case. You have public state and you have private state. So it's up to the users and the developers to choose what state they want to be public and what state they want to be private. The private state is vis the public state is visible to everyone in the same way that it is normally. Everyone can just look at the blockchain and see the total supply or whatever they want. And then the private state is visible only to the person who owns that data. So let's say the simplest example is your balance. you will only be able to see

your balance. You're the only person that will have as access to that, unless of course you choose to share it with someone. Public state is a lot less complex than private state. So, we're going to go through that first. It works exactly the same, well, pretty much exactly the same as it does on Ethereum. So, it's accountbased. It's all all p all public functions executed onchain and all public state is stored on chain in a public state Merkel tree. So it's exactly the same. Well, it's a it's a it's a Merkel tree rather than a Merkel Patricia tree. So there's some small differences, but from the developer perspective, you can consider it to be exactly the same. So it's accountbased.

Let's say it's a balance. Again, you'll have some key like your address, which will then map to some value, which is your balance. This is then stored. Did I put the slide? No, it's stored in a Merkel tree. So then when you update your balance, you'll be pointing to a specific storage slot in the Merkel tree and it'll be updated and everyone can see it. Everyone can see what storage slot you're accessing. The end. private state cannot be stored on chain and private functions cannot be executed on chain because of course if we did that everyone would be able to see it.

So that would not be a good thing. So we can't do this. Therefore we got to do things differently. So instead we execute private functions offchain and we store private state offchain in its raw form. We then prove the execution onchain by sending a zk proof to the sequences. That's pretty much it. Sounds not too complex because to be honest at this point it's not. >> Private state is offchain, public state is onchain. That's it. Imagine if it was that easy.

>> Yeah. Three years [laughter] working and it was that easy. >> Yeah. Well, there you go. >> Go figure. >> What took all this time? Huh? [laughter] >> Right. So private state is not accountbased like public state. Why is because let's imagine for a second that it is accountbased. Let's say we just encrypted our key and encrypted our value. Let's say again it's a balance maps to some encrypted amount. We would then store that in a Merkel tree. And then when you access that Merkel tree, let's say I'm updating my balance, even if the values are encrypted, you will leak which storage slot you're accessing and that itself leaks information which breaks privacy

assumptions which is not a good thing. So we definitely don't want to do this. So that is why it's a bit more complicated and has taken more time. >> Exactly. [laughter] >> So instead of using an account-based model, we use a UTX based model. And who who knows about UTXOs? Who knows how they work? >> Huh? >> Okay, pretty much everyone. So, this is going to be really easy. Nice. It works exactly the same. Well, pretty much exactly the same as physical cash. So, rather than storing a full balance somewhere, you instead have individual notes that will add up to your balance, but you're never actually storing the full amount. And now, this on Bitcoin is just balances. But for Aztec, this is going to be any data. But we're going to stick with the balance example for now

because it's the simplest to think about. So let's say I wanted to I had a $20 bank note and I also have a $10 bank note. I want to pay Paula $25. I would have to give him both of my notes, my my banknotes and then Pala would have to give me five back. So then the the the value transfer is 25. Um and that's pretty much it. And so with private state, it works pretty much the same except rather than it just being normal UTXOs which are stored on chain, it's stored offchain in something called notes. And notes to me when I started learning

Aztec were like so confusing. I understood it conceptually and then I was like, okay, but like what actually is a note? It's literally just a strruct. It's just some data. The data we call a note because it has some special functions as well as this strct to be able to do some things that we're going to talk about later. But from your guys perspective, it's literally just some private data. So these values can be anything you want. Here I I've given the example of a U in note. But these can be anything. So we've got some owner, some randomness, and a value. The randomness will come into it later.

>> I don't think the mic's working by the way. >> Yeah. >> Hello. 1 2 3. >> I don't think it's working. Can you guys hear anyway? >> Okay. Well, I'll just continue anyway and then hope for the best. Pray for my voice, please. Um, yeah. So, it's just a private strct >> and then these notes are stored offchain. So, you've just got your collection of notes which you store on your local machine and that's it. So, yeah, you got all these notes here. But how do we track track this private data? How do we make sure that everything is still verifiable? We can't store them on chain as these raw notes because obviously we don't want everyone to be able to see it. So instead we create commitments. Who knows what

commitment is? Also want to see a show of hands for that. Okay, pretty much everyone. A commitment is basically just a hash but you can't it it just protects against brute force attacks pretty much. So we create these hashes of the notes and then we store them in a note hash tree which exists on chain. So no one can see what the notes are because they're hashed and then they're stored in this tree to make sure that we can have verifiability because people can prove that they own the notes by proving they know the pre-image to a note to a note hash that exists in the Merkel tree.

This note hash Merkel tree is append only. You can't edit in situ. You can't change a note. You can't delete notes from the ah we're back. We can't delete notes from the tree. So when I let's say I'm paying palar again. I've got a 10 token note and a 20 token note. I want to send him 25 tokens. I'd need to first find a way to either edit my notes or get rid of my notes and create my new five token note and a 25 token note. So a 25 token note for pala and a five token note for myself as my remainder.

But if it's append only and I can't remove notes from the tree, how do I know which ones are used? How do I know which ones have been removed? And how can I how can I edit them? How can I remove them? >> Yeah. How do you prevent double spends basically? >> Pardon? >> How do you prevent a double spend? >> How do you pre prevent a double spend? Exactly. Thank you. And the way you do that is through nullifiers. So I have to create a way to delete these notes effectively and mark them in the Merkel tree as spent. I have to be like these these notes in the Merkel tree have been used and they can't be reused.

And we do that using nullifiers. So let's say you have all of these notes stored locally on your machine. Some of your notes that you have used will be spent. And to mark them as spent, you will create a unique nullifier which will be based off of the data in the note plus the person who can spend them to make sure that it's unique for each person. So each note that is spent will have its own nullifier. And then these nullifiers are stored on chain in their own Merkel tree called the nullifier Merkel tree. Yay.

And that to be honest is pretty much it. So let's go through an example. I'll have my original example. So I've got a 10 token note and a 20 token note. I want to send Pala 25 tokens. So I first need to nullif well first I need to prove that I know the pre-image to two commitments in the Merkel tree. So I prove that I have ownership of these two notes, the 20 token note and the 10 token note. I then need to nullify both of these notes. I need to mark them as spent. I need to destroy them. and I can't remove them from the tree. So I create two nullifiers and I add them to the nullifier Merkel tree. So these two token these two notes are now used. I then create two new notes. One 25 token

note which I give to Pala and one five token note which I keep. How do I share my 25 token note with Pala? A little bit complicated. I could share it offchain. I could send an email. I could create a QR code which he could scan. I could send it via carrier pigeon, but I could also use note discovery, which is a little bit more complex. Maybe Paula, you could give a little bit of a spiel on note discovery. I haven't prepped him on this, so >> no, not at all. And I know it has changed yesterday, literally. >> Oh, >> I'm not kidding. [clears throat] Yes, uh, there was a question.

>> Oh, sorry. >> Uh, how are the nullifiers computed in such a way that they don't reveal the information about the nodes? >> Yeah. Do you want to take it? Yeah, go for it. Okay. So, Nifier is a hash right >> same as the uh same as the commitment it's a different hash altogether and the thing with nullifiers is they need to be deterministic like you need to be sure that whenever you have a note and you produce it nullifier it's always going to be the same otherwise you could produce different nullifiers and spend your note multiple times. So what we do is we take um part of your private key if you will is shuffled into that into that hash that we use for producing the

nullifier. That way the nullifier is a commitment to the note and it's something that only you as the owner can produce and no one else because otherwise uh let's go back to example where she had sent me a note for 25 bucks. Then whenever I nullify that note, if I didn't include anything secret in there, she would know when I spent the note she gave me. And we don't want that. So we mix some secret thingies into that commitment >> here. Okay. >> Okay. Amazing. >> Yeah. Sorry. >> Okay. >> Just speak very loud.

>> Yeah. I just speak up. >> Go back to some question about the private uh private state and public state. >> Yeah. >> Which one? >> Oh, just that the private state is stored privately. It's not on chain, right? So I I suppose it is somewhere like in the client wallet >> in the water test >> the private state. >> Yes. >> Because it's storing privately. So I assume it is storing in the client wallet. >> Yes. Y >> and if I somehow like uh screw up my computer for it and how do I is it possible to restore my private states like it's only the commitment that >> we call that the throw your laptop in the ocean test.

Not kidding. We we've been using that term for a long time. And it's going to depend on two things on your wallet and the application you're interacting with. As Kiraas was mentioning, you could architect your smart contracts like your your applications so that whenever a note is sent, it's actually broadcasted on chain encrypted so only you can find and discover it and actually understand what it means and that ultimately since we are a rollup that goes into Ethereum blocks like it gets stored somewhere that you can retrieve later. What's the downside with that? It's expensive.

You're paying for blob space. So it's up to your it's up to the application you're interacting with to decide whether every single note every single piece of private data wants to be emitted onchain encrypted or not. So that's an application decision. Then you have a wallet decision which is how am how am I going to back up all my client data. So for all of those nodes that were not emitted encrypted on chain how am I storing them? And yes, one option is store them locally and pray that your laptop doesn't fall into the ocean, which is definitely not the best option.

So most wallet teams that were working on are looking to some backup solutions like they encrypt your private state and back up to cloud provider or whatever it is or multi-device or anything else. But yes, it's a very good point. If you haven't emitted those notes on chain encrypted, you need to make sure that the wallet the client is using, the end user is using has some sort of backup. Otherwise, you lose access to your stuff. >> Thank you. >> Sure. I'm sorry. I think like what this goes into well is that a wallet in Aztec is a much bigger beast than it is in Ethereum. It's not just something that signs. It's something that needs to execute code locally, that needs to generate proofs, that needs to keep

local states, and also needs to have your own keys. >> Thank you, Pella. >> Anytime. >> Very good [clears throat] answer. Uh I've just created a little slide about when to use private functions. Actually this is stolen from Josh. So thanks Josh. Um yeah so basically anytime that you're working with private state you'll want a private function. If you want sensitive data that you don't want stored on chain of course. Um if you want to hide any fun function execution if you want to create a proof against historic data. So there's an archive Merkel tree in one of there's five Merkel trees by the way in Aztec.

There's I'm going to do try and do this off the top of my head. >> [laughter] >> Hope for the best for me. Public state Merkel tree. We got the note hash Merkel tree. We got the nullifier Merkel tree. We have the archive merkel tree. And then we have the L1 to L2 messaging Merkel tree. Sorry, just testing myself there. [laughter] And yeah, so proving against historic data. And then let's say you wanted to move some state from p from public to private. Um, yeah. I don't know what's what's an example of when you'd want to move it from public to private.

>> Shielding your assets. >> Okay, fine. Yeah, shielding your assets. Great example. Thank you. >> Anytime. [laughter] >> When would you want to use a public function? Pretty much the same as you would normally. So, yeah, anytime you need some shared state, maybe it was like a total supply or some health factor that you need to like the minimum health factor. Um yeah, interacting with current head of state, using the block data, block time stamp, that sort of thing. If you want information to be available to everyone, of course, you need it to be public so that everyone can see it see it. Taking data from p private to public. Um and then also anything which you want to reveal at a later date. Let's say, yeah, it's like a card game and you want to reveal the

cards at the end of the game, you'd need to use a public function to be able to do that. And then there's some a slide which I have stolen again from Josh. Thanks Josh. Um on the transaction life cycle. I think Paul it would be really helpful if you could go through the trans transaction life cycle. Feel free to use the slide or just spitball if you want. >> Yeah absolutely. Um so the idea is the let's start with the separation of the different branches here that involve the transaction life cycle. First the separation between purple and yellow, right? like purple which is everything that happens in private land is what happens in the user device and it happens when the user is sending the transaction. They they specify what they want to do. They execute they generate

the proof etc etc. That all happens at one moment in time. It happens when the user is creating a transaction on the on their device that that transaction gets sent to a node and eventually as in Ethereum it gets picked up by a sequencer and included in a block. When that happens, the public side of the transaction is executed. Remember, transactions have can can involve private functions and public functions. And you can have p private and public functions in the same contract operating in tandem with one another. Like you could do something in private to prove you have some assets and generate a side effect based on that on public. Or you could check a condition in public that you couldn't check in private. For instance, you could allow people to participate in an event up until that

event gets filled. So you can handle the participation in private, but you do the check on hey, has the event completed or not in public. Why? Because public happens when the transaction is actually mined gets actually included in the block. Same as in Ethereum. So that tandem between private and public lets you do as much as you can locally on the client without revealing anything and only rely on public when you need either interacting with other things like was mentioning or validating that you are in a good moment for the transaction to happen right things that are time dependent or inclusion dependent or dependent in the global state.

So what's the overall life cycle like the user is going to accept from the wallet sending a particular transaction same as in Ethereum and then the wallet is going to work with a local component that we call the pixie private execution environment which is a client side library that we built at Aztec uh which wallets are developed by external teams and we expect to have a lot of wallet diversity but all wallets are going to rely on this small component uh that again runs client side. is in charge of actually executing all the private functions involved. Not just executing but also generating a zero knowledge proof at um the Pix is going to have a couple of callbacks to the wallet like

the Pix is going to ask the wallet for instance to provide the notes that the user is holding like in the example where K is sending me money. What's going to happen is um the user is going to say to tell the wallet that they want to initiate the transfer the wallet is going to call into the pixie saying I want to call the transfer function. the private transfer function this of this particular token the pixie will start execution at some point the token contract logic will say okay give me note to get up to 25 tokens that's responsibility of the wallet and how the wallet is persisting state to provide those nodes back into the pixie which will keep executing contract logic will probably involve showing ownership of those nodes nullifying them etc etc and

ultimately what gets out of the user machine is a zero knowledge proof of correct execution with a bunch of commitments and a bunch of nullifiers and that's it and optionally a bunch of public function calls to be executed on the sequencer side on the node. So when the transaction gets included first of all the knowledge proof is verified to make sure that the user is not lying and the public functions are actually executed and those those effects are actually added to world state on the chain. >> I think that's amazing. Sorry, L1. Yes, we are a roll up at the end of the day.

So, all of this gets rolled up and sent to L1 eventually. >> How long does it take to make such a transaction? Because like >> Yeah. How long does it take to make such a transaction? Because it's way more complex than a normal. >> Yes. I think we're in the order of 12 seconds Josh. Something like that, give or take. Uh so, of course, the most expensive thing is proof generation by far. uh like private execution is pretty fast and like the local the private local database of the user is not that big like remember you're just going through the user's notes it's not the entire world's notes um so all that part is relatively fast and the proving system

is optimized for a lot of recursion so sorry folding technically but recursion uh so that you can have multiple function calls involved in your transaction and do not you don't need to pay a big overhead for that And it's also optimized for low memory consumption. So you can run in a mobile phone without issues. I think the last tests were around the 10 12 seconds and uh 300 megs of RAM. Uh so we we strive to keep the memory usage under one gigabyte to make sure that proofs can be safely generated on the browser. And I think we're fine. I think that around 10 seconds was for >> I think that 10-second proving time was for a transaction that was doing a swap

on an AMM. So, it was interacting with two token contracts and an an AMM contract. So, just a simple token transfer will be will be faster. Yeah, like your transaction times are highly dependent on what's actually going into the transaction. Um, one of the wallet teams yesterday was doing a demo at the ecosystem dinner and they got it proving natively on a mobile device and I think a simple token transfer on a phone was like 10 seconds just for a token transfer >> which is pretty good. >> Um, and then if you're on your laptop or desktop it's going to be much faster.

Just have a lot more resources. Um, so you were mentioning all these trees. If do I have to manually update all of that? >> That's such a good question. Luckily, no. Even as a developer, you don't really have to handle that. So, creating the nullifiers and the commitments is handled in the note itself. So, I was saying there's some methods associated with the note as well as the strruct. Those methods do create those nullifiers and commitments. And we have created some notes for you guys and also there's like templates and things like that to be able to basically just easily create notes to create your own notes with

whatever data you want inside there. And then in terms of like actually adding it to the Merkel trees. So smart contracts on Aztec are not written in solidity because obviously you have to be able to handle all of this complexity. So instead they're written in noir and we have created well the Aztec team have created um Aztec noir which is basically wrappers around noir syntax that makes it so that you don't have to touch any of that. You don't have to handle any of the adding to the Merkel tree or like any of these things because Aztec Noir does all of it for you. That's kind of the point of it. It's just a framework that that handles all of these complexities. Yeah.

>> Yeah. Like if you look at the token contract in Aztec, you define a mapping from addresses to balances to a set of nodes that represent balances. So you get pretty much the same abstractions that you are used to when working with regular smart contracts. And the library, this library, think of it like operating system calls like handles for you all these manipulation of nodes and modifiers and whatnot. If you want to go low level and do it yourself, please by all means, but yes, we have this higher level library. So to make your life easier, So with the um the public state change proofs that makes sense to me but with the private ones if only the hash goes on chain what prevents me from >> generating you know a state change that

I'm sending a thousand tokens to you and then double spending privately what I if it's only the the hash on chain I don't see what prevents you from >> generating valid state changes. >> Do you want to take it one or >> no you can go for it. >> Okay. uh the nullifier tree uh the one condition for the global state to be valid is that you cannot emit the same nullifier twice like the nullifier tree guarantees that every nullifier is only present once in the same >> yes that's the key nullifiers are deterministic given a note >> sorry >> the address yeah basically out of your

let's say private key, if you will. You derive a secret that's deterministically derived from your private key and gets mixed into the note to generate the notifier in a deterministic and secret way. >> Um, if I can uh follow up on the question of who maintains the Merkel trees. So if I my goal is to use notifier to hide the uh the consumed uh UTXOs that I want to spend uh I need to generate the Merkel proof uh based on the Merkel tree and then that feeds into the to the circuit to generate ZKP for inclusion.

>> So I'm not going to give the UTX cells I want to spend to some other party to generate that right. So the best way is for myself to generate the the Merkel proof and then ZKP. Is that right? >> Yes. >> So >> so as a result if I'm using a mobile client then I better have the Merco tree inside the clients. >> Yes. Right now you depend on having access to an AIC node that has the trees and can serve you with the proofs. sorry with the Merkel proofs because otherwise you like that node that you're quering for the Merkel proofs can link and can associate what nodes you work with because they

see the kind of queries you make. Yes, that's a very good question and yes, we assume that we have a node that you trust that is not going to leak your privacy in that way. Could be a not running at your home, could be a provider you trust in that or if you're on your machine, could be something running on your machine. In your laptop, it's sorry, in your mobile phone, it's impractical to have the entire the complete set of Merkel trees. Something you can do, however, is you can store like existing Merkel paths and like whenever you need like you keep them and you just prove against an old world state. That also works. That's also an option. But yes, it's a it's a leak and

it's something that we're working on. So you don't need to have your own note. Yes. >> Okay. Thank you. >> Very good question by the way. >> Hi. Uh [clears throat] so about how long then for transaction in the sequencer uh received from the sequencer to be processed uh for one block only uh at the blockchain and how long does it take to be eventually finalized? Just just want to get a few of the youth. >> Uh that's in flux. Today it's 72 seconds for going onchain for going to L1. Uh we commit state every every 72 seconds, every six L1 blocks. That may change in the future. Not that much. And proving

happens every 32 times 72 seconds. Uh can someone help me on that? It's 32 * 72. That's in seconds converted to minutes. That's how often state gets finalized and by finalized I mean someone puts a validity snark a validity proof on chain of correct execution and that's whenever you can exit from L2 to L1 because you have convinced L1 that the transactions were valid. That's like the best finalization you can get from an L2 perspective. Then you can also wait for the block in which the L1 proof was included to be finalized as well if you want even more assurances.

>> Okay. >> Anyone did the math? >> 35 minutes. >> 35 minutes. Okay. That kind of checks out. Yeah, every sort of every half an hour you can exit L21 because an SK proof is sorry validity proof is expected to land. And if I have a use case that I want the same account to be used on the mobile and browser that would depend on the wallet like implementator on how to make setting the private state right >> yes basically because like you don't want like both wallets to be consuming the same note at the same time otherwise you'll have two transactions going on the chain with the same nullifier so one of them is going to invalidate the other.

Um Josh, you mentioned a swap happening between two assets. In that situation, is the wallet handling basically it's like bundling a bunch of these operations? Are are we like recursively building proofs on proofs within each kind of like project's code? It's one transaction and private functions in one contract can call private functions in another contract can call private functions in another contract. So like we have full smart contract composability. Um basically I'm not exactly sure how the contract's written where like I mean you

call the AMM and then it's going to call the token contracts. Um but yeah, there's essentially recursive proofing happening. Um so it's not like bundled transactions. That's one transaction that's just calling multiple functions on multiple contracts. [laughter] >> This is a good exercise. >> I was going to say lovely getting steps in. [laughter] >> Um just a question on the transaction life cycle. Um >> can you explain a bit more how the other side of the equation works? So when I receive something, how do I know it's mine? Um it does do are you indexing all the nullifiers and like brute forcing to figure out what belongs to you and what component actually does that in this uh

architecture? >> Beautiful question. Um a connect used to work like that like you were expected to brute force the entire chain and like use trial decryption to figure out what what nodes were were meant for you. We're not using that here fortunately. Uh there are two options. One option is off-chain delivery of the note as K was mentioning which is the most efficient one in a way because you're not paying for blob space on L1 ultimately to actually store that still sometimes you need to actually prove that you have sent the note to your counterparty like let's go um there are two very very clear examples on this like let's say I want to buy a coffee from her so I would

I would send her like a note for how much are you charging me for a coffee nowadays. >> Oh, like a $100. >> $100. Must be very good coffee. Okay. I send her the $100 notes. >> Thanks so much. >> And like I show her like I send them via WhatsApp QR whatever the note. If I don't send her the note, but I have sent the transaction. What happens is okay, I have lost the note because I have consumed it. She cannot use it because she doesn't actually have that note. She only sees a commitment that's completely opaque to her own chain, but she's not giving me my bloody coffee because she didn't get her money. So, I'm sort of incentivized to give her the pre-image to the note, like the note with the the 100 bucks.

Let's go for another example. Let's say we're in a trade like I'm interacting with edex as Josh was saying and I'm actually uh taking an order for I don't know die to ETH or whatever or well their respective assets in in in Aztec. So I could fill that order privately. I can get back whatever tokens were stored there for the trade. But then I never send the note to the guy who actually put up the order and I'm running away with my side of the trade and briefing the other guy. So that contract when you code it as a developer that needs to guarantee that the other person person actually gets the notes and in that case you need to make sure that that note

goes on chain and is discoverable which goes into your question like how the hell does a recipient find that we have a a tagging scheme basically where the pixie can issue queries to the node saying hey I want to I want to find out about notes about encrypted notes that look like this and they refer to a prefix in the node and the node whenever the node syncs world syncs from from L1 they sync the state of the chain they also sync these encrypted logs and index them based on these prefixes. These prefixes are not like the address of the recipient because otherwise you would have linkability. You would understand that

there were two different transactions sent to the same person. So to any external observer this those tags are not related at all but the pixie the user wallet knows how to derive okay these are the prefixes I'm interested in issue that query to the node and the node replies back with the previously indexed data which is the data that the user wallet needs to decrypt to actually form their nodes. So to sum up, sorry I went in a massive tangent here. Thing is this is really fun. Actually we spend years building this.

>> I knew you'd enjoy it. >> I love this. Yeah. So bottom line what you get is there are encrypted logs emitted as part of transactions. Those encrypted logs have think of like a index topic as you have in solidity. Each note is going to have a completely different index key. nodes will index that and the user wallet every now and then will tell the node hey give me everything you have for this 100 key values for this sorry this 100 keys and the node will return that data back to the pixie the pixie sorry when I say pixie it's actually user wallet and the user wallet will decrypt

them and store them in their local database >> okay so on the the latter it's like a filtering mechanism on the former one this offchain communication you're Are you pinning any of that onchain? Is it related to what you're doing on the node or it's completely separate to what? >> No, on the offchain case is completely offchain. So you don't have to pay anything. >> So it can happen at any time and on the user's wallet they need to be able to coordinate onchain to offchain mechanisms. >> Yes. So that and that's going to be very application specific because it depends like is it a payment application? Is it uh I don't know a ticket to a venue?

It's like and how you actually receive that data, that private data, it's going to depend on the application or how the wallet wants to orchestrate that. What the recipient is expected to do though is whenever they receive that note, that data, they need to check that there is a commitment for it on the global state. Otherwise, they are given something that whenever they want to use, they won't be able to prove that it's a valid note that they own. So, it's on the recipient to check that the note they got actually corresponds to a valid note that was created and is committed to in the note hash tree.

>> Sure. >> Any other questions? >> Nope. See the time? >> Okay. >> Oh. Oh, there's a question. >> I love how dynamic this is. >> I love how dynamic is this is. We're getting very good questions. >> Yeah, we are. >> Uh, so what's the actual state of the wallets? >> Good question. There's currently two wallets, well, two main wallets who are building on Aztec at the moment and that is Asgard and Obsidian. They are here at Dev Connect, so you should go speak to them. Um, I actually not too sure on the difference between the two. Maybe Py Josh, do you know too much? I think um Asgard is uh like a browser extension

wallet and then Obsidian is an embedded wallet. Yes, I got that correct. Come on. Um but yeah, they're the main two building at the moment. >> But is it guys are building? >> Oh, that's a good point. >> Z email and Z passport in their wallet. >> Okay. features >> and is it is it like doable or possible because I'm I'm trying it. I am still like failing but basically to connect like preview uh with with uh estgs because like I'm I don't know this these two wallets are still very experimental and why not have a third experimental

wallet [laughter] >> is privy just like a normal EOA like wallet >> yes and they support uh all EVMs they support bitcoins Zulana, but they support just designing uh basically everything and there is like a SSH example from SEC in this X est package and in theory it should work but I still didn't figure it out 100%. >> Yeah, you're not going to be able to use Ethereum wallets just like with Aztec because we have these additional keys like the nullifier key.

>> Um there's public keys associated with accounts. So you can encrypt notes to recipients. You could create, we have a con abstraction on Aztec. So you can create Aztec accounts that are controlled by ECDSA keys. >> Exactly. This is my approach. Yeah. >> But there's additional keys that are required to make Aztec work. So like wallets in theory could have I think they could make deterministic generation of the additional keys from those ECDSA keys. But >> yes, >> I'm not totally sure about the cryptographic security of that because I'm not a cryptographer. But like um >> for Aztec Connect, we did generate Aztec Connect keys from signatures with

MetaMask accounts um which was cryptographically secure. So, I think we could I think it would be possible to build something, but I'm not exactly sure how it would work >> with Metam Mask snap or just like we >> Oh, it was literally just a signature like a MetaMask would pop up, have you sign something, and then the the randomness in the signature is sufficient to actually use as a private key. Okay. >> In in Aztec Connect, um which was our previous Aztec connect. This was our previous product that's no longer >> but it still >> like the same approach would still work if I want to build my own like like on top of preview or metam mask it should still work right like

>> amazing >> like to be clear like you would generate your private key out of uh like a private key for your Aztec account from MetaMask or whatever it is but then you need a full-blown AEC wallet to actually run the thing because you need something that can execute code and can generate proofs and metamas cannot do that. >> Yeah, MetaMask cannot do this. Okay. >> Okay. Thank you. >> Is it possible to connect? >> Yeah. Is it possible to connect in some sense like Aztec and and Zcash? So for example, >> yes and um that is exactly what Harsh has worked on. He created a project

connecting Zcash and Aztec. Maybe Josh, can you give a little more more context on what you did? >> I don't know the details. Harsh is literally giving a talk at the same time in the other room. So, he's around. So, like if Yeah, if you just step out and find Harsh. Um, he's wearing a a Noir lab coat. So, um, yeah, >> he also made a video, sorry. Sorry. He also made a video on it, I think. Uh, did he make a No, an article. I think he did a video on something else, but he did an article on what he did with Zcash as well. But yes, you can definitely connect it. We've done it. Um, so you should look into that for sure.

>> I am not sure on the details with that. It will be uh because Zcash is an L1, right? Yeah. Yeah. Yeah. It'll be with the portal contracts then. I assume he was messing around with >> possible. >> Maybe he deployed the portal contracts on to Zcash. >> Better check with Harsh. >> Check with Harsh. Yeah, >> I am I'm guessing there. >> Yeah, it's doable. Like you have full programmability in an AXC smart contract. So yeah, you could totally build something that verifies state from Zcash and consumes it. Yeah, >> if you're familiar with how like the near intense bridge works between Zcash and and Near Harsh leverage the same type of architecture, but instead of near being the other side of Zcash, you did use Aztec. So instead of like I mean

when you're using Near, near is a public blockchain, half of your trade is public. If you do Aztec as the other half, you get full privacy. Anyone else got any questions? Otherwise, we can pass on to Josh if he's ready. Uh, so thank you every Oh, we've got one more question. >> Another one. Go. >> What version you should use package because there is like next from the branches there is like there is like 3.0.0 Devet 5. [laughter] >> Yeah. H but the deployed version is the devet 2 if you connect to RPC but there is also the test net there is also and what I should I pick as a developer I

was going for the devet file but I'm not sure >> and you also there are three more networks that you also don't know about >> oh tell me more >> I'm I'm going to talk about versioning because I'm in in mind but yeah use DevNet but I'll talk about the difference between the versions and which ones to use >> okay >> in in his talk in a second >> minutes yeah He he'll be doing he'll be doing a run through of what to install. So he'll go through all the different versions and which one you should use >> in this room. >> Yeah. So literally in a second. >> What I'm going to do I'm going to jump up here and I'm going to basically show you guys what software you need to get started. We're going to run through Yeah. the nuances between versioning cuz

that's like one of the first hang-ups people run into. >> Um and then we'll start the sandbox and run some scripts and talk about exactly what's happening. We're trying to like make some of this stuff more real. um looking at code and running scripts and they give you guys resources to actually um yeah walk away and know what to do to start playing with Aztec. >> So that's what's next. >> I think we have we have other questions, right? >> Perfect. >> Yeah, assuming we have time. >> Okay, >> thank you. Thank you. Um hopefully the last question um the the encrypted node uh maybe two questions. Do I have the

option of not sending the encrypted node to the chain but just keep it offchain? That's number one. Number two is uh for the encryption scheme, have you guys thought about postquantum security schemes and when is that coming? Thank you. >> Very good questions on postquantum have you speak with Mike from our team? He's been the one researching that. uh on the first question that's up to the application basically the smart contract developers like at some point when you're writing your smart contract like you're writing the code for the token transfer you'll have an option for saying okay I want to send the note to this other guy and you can either enforce it or leave it up to the wallet devel the wallet developer sorry leave

it up to the wallet and then the wallet decides either by itself or on behalf of the user what the user wants to do this basically relates to some code being constrained or not within the circuit we're writing. So you can leave like the fact that the note was emitted, you can leave that unconstrained. So you so the end user can generate a zero knowledge proof of validity regardless of whether they took that code path or not. >> Thank you. Thank you. for for quantum security since we're just storing commitments on chain is the only required. You don't have to encrypt a node and put it on chain. Um commitments are quantum secure. You can't like go figure out what information goes into a

commitment with a quantum computer, right? So when we talk to application developers about how to design applications, I'm even reluctant to suggest people put highly sensitive information encrypted on chain um at all. Like token balances like that may be decrypted in 5 years less sensitive. But like if people are talking about putting medical records on chain and doing stuff there, I'm like maybe don't do that or like just do it all offchain. Um don't put them on chain. just keep the commitments and you can still do compute on them and use them in your application. So >> yeah, >> quick question about what you mentioned before. If you do private function

calling a private function in another smart contract, is that recursive proving or not necessarily >> that is recursive? >> It's folding but yes. >> Okay. So it has good performance. >> It's sorry >> good performance. >> Very good. Yes. >> Cool. That's all the questions and we'll pass over to Josh. If you think of anything else you can probably ask at the end, but thank you all everyone so much. [applause] >> Thank you.