# 🛠 Building on Aztec

- Channel: [ETHGlobal](https://streameth.org/ethglobal)
- Date: 2022-10-09
- Duration: 58:14
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-I5M8LhOECpM
- YouTube: https://www.youtube.com/watch?v=I5M8LhOECpM

## Description

Welcome Josh Crites, Lasse Herskind and Maxim Vezenov from Aztec for a workshop titled "Building on Aztec".

00:00 Introduction
05:42 Hackathon Resource guide
12:22 Building with the SDK
30:19 Building Aztec Connect Bridges w/ Lasse
47:54 Writing Circuits with Noir w/ Maxim

You can find more detailed information about building on Aztec for the ETH Bogota hackathon (getting started guides, prize info, useful links, core team contact info) in our hackathon resource guide here: https://docs.google.com/document/d/1YYJQM0T0tdIpaIgDwm1gl07Yrqg9VvlViykD4-xtfKo/

Join us October 7th-9th, and kick off Devcon Week with thousands of developers and creatives just like you. We're picking up where ETHMexico left off, bringing in dozens of top teams and speakers to help you take your ideas to the next level. Get hype to win $300k+ in prizes, build next-gen primitives, and catch talks from luminaries like Vitalik Buterin.


---------------------------------------------------
Follow us: https://twitter.com/ETHGlobal​
Check us out: https://ethglobal.co​m
Email us at: hello@ethglobal.com

#ethereum #web3 #blockchain #eth

## Transcript

foreign [Applause] [Music] hackathon Workshop uh I'm Josh Kites and I'll be talking about uh Aztec Network and my colleagues will come in a bit later and share some details on Building Bridges with Aztec and uh using our domain-specific programming language for writing zero knowledge proofs that we're developing as well um we are really excited to be sponsors for eat Bogota um and we're excited to support you guys um in learning about the Aztec Network and building some cool new applications so in this workshop I'll do a brief overview of what Aztec is let's talk about some hackathon specifics like prizes and some resources that you guys can use to learn leading up to the hackathon I'll cover some specifics around the SDK lastable cover Building Bridges and then Maxine will cover Noir so what is Aztec Aztec is a privacy focused um privacy focused Network deployed on ethereum right now so it's a it's a scaling Solution on ethereum um built on zero knowledge proofs so it's actually uh recursive zero knowledge proofs so for the Privacy aspect of the network users are generating zero knowledge proofs to verify ownership of specific assets those are sent to a roll-up um back end and users encrypted transactions are rolled up and then published to ethereum layer one um this provides some unique capabilities that other roll-up designs do not have um mainly we have this capability of doing Atomic transactions with the rest of the ethereum layer 1 Network directly from the layer two so that means I can enter and exit a D5 position directly from the Aztec roll up and not have to withdraw my funds to ethereum layer one to do that so you can do like basic erc20 transfers you could do D5 deposits or D5 claims um and really like since the Aztec processor contract lives on ethereum L1 and it um is designed such that it can be manipulated by any user with assets on the rollup um the roll-up processor can dispatch These funds out to the rest of the ethereum layer one network so lastly we'll talk a bit more about how you can connect the roll-up processor with essentially the rest of ethereum with these Bridge contracts it's a really cool feature that Aztec has [Music] and one benefit of that is like all of these defy interactions that you'd be doing from Aztec are actually private so um what you see on ethereum layer one is just that some user from Aztec send a transaction out into uh ethereum layer 1 did some D5 interaction um or other interaction whether it's like Unchained voting I saw someone at East Berlin recently made a private voting contract um we're thinking about what nft contracts might look like what do what capabilities can we get with private nfts things like that um this is still like this has been deployed for a few months now so it's still relatively new and we're just starting to really build out this ecosystem it's pretty cool um so yeah on the Aztec Network you get cheap private D5 so you don't have to interact with ethereum layer one you can just send assets privately on the Aztec Network itself cheaply since it is a roll-up so if you're transferring assets within the Aztec Network you get complete privacy where you don't know or nobody else on the network knows who the sender or the recipient of the transaction is or the transaction amounts when things are going to or from ethereum layer one obviously amounts have to be public if you're depositing funds you know like it's public information which address is depositing to Aztec or if you're withdrawing funds it's public information which uh which address the funds are going to as well as the amounts um so yeah all states on ethereum are still public but Aztec adds some new capabilities so as I said Aztec is a roll-up of a roll-up so what's really happening is we can roll up a whole bunch of transactions um especially if these are like defy interactions um if there's let's say there's a handful of positions that are swapping each for wrap staped eats on Aztec um these interactions can be rolled up into one transaction um those roll those rolled up transactions can then be rolled up um into another layer by the back end infrastructure and that roll-up is then published to ethereum as well as the transaction information needed for data availability to recreate the state of the s-tech network um so yeah Aztec is recursive zero knowledge roll-ups um I want to share this QR code this is the this is actually this Google doc right here um this is Bogota hackathon resources list we're adding to this page right now so we have our test net there's information here about how to connect to it our block explores uh General developer resources um this we're adding to this list so this is kind of like our one pager go-to resource guide for people that are starting to or developers that are starting to like build on the network so a lot of the information that you might be looking for will be here um if you need more um definitely feel free to reach out to us um you can always ping me on Discord or Twitter my Discord is Josh C pound001 or Twitter at kreitz Josh underscore um but yeah so that's a good guide for just like resources for developers um I want to touch a bit on the prizes that we're offering um so we have 20 000 worth of prizes up for grabs um I think it's 10K for first prize um 5K for second prize and then third and fourth prize would would each get twenty five hundred dollars um those last two mounts might not be exactly correct but um something like that so we have a list of projects that we'd like to see and we'll publish more information about this on like our Twitter um and you can reach out to me if you if any of these sound interesting um but we're thinking about things like uh private nft Bridge um I know Joe's been thinking about this so he's got some details that he could share um we'll also be happy to talk more through like the specifics of what these can look like at the hackathon so if you guys are interested in building this um reach out to us and like I mean we want to see these things built as much as you guys might want to build them so um we're definitely interested in collaborating with you guys and just helping you build cool stuff [Music] um so yeah probably the nft bridge is one or just like um thinking about ways that using nfts privately um in really like any use case that you guys might come up with could be interesting um we have existing Bridges um like swapping for rap staked eth entering element positions we have some like published bridges that we haven't deployed yet that we're going to make available for the hackathon on the test net um so then when those goes like go live on Main night you guys could have um one of the first interfaces potentially so take these front ends like we have a dollar cost average Bridge that's um in the spinal stages of being audited so that would be like you can deposit some dye and then just specify I want to buy like ten dollars worth of each every day for the next however many days um so this is just like a nice automated way to dollar cost average into eth or you could go the other way for selling um it'd be cool to see like a payment streaming front end I actually don't have the bridge written for that yet but that would include like you need to write a bridge contract and then do streaming payments I think payroll is a really interesting use case for Aztec a lot of people don't want to make their payroll information public we have a audited 4626 volt standard um and since that's a standard across T5 like we can make it very easy to just add any protocols D5 protocols that support the Vault standard I would just be like a contract that would have to add to the bridge contract address so building a web interface for interacting with both standard contracts would be really nice also liquidy we have a liquidy integration for entering positions it'd be cool to like get support in a liquidy wallet for actually um interacting with this so hopefully we have the liquidy bridge on our test net um I'll publish a list closer to the hackathon dates of the actual bridges that we're going to have deployed on the test net that aren't on the main yet those will be fun to hack on um something that I'd be really interested in seeing is a standalone application for account management um we have ZK money which is a um let's just go to it real quick and I'll go to it on my testnet account I'll probably be doing this on the demo um but it allows you to deposit funds register an account enter some D5 positions like element Lido we have urine live now um but the wallet I can like send Shield I can register an account so it would be cool if we had an application that did a count um more account more specifics around account management like being able to like recover an account that you lose the keys for or do account migrations we have these things in the SDK but we don't actually have an application that can do these things yet so um and a kind of a wallet that's more focused on account management not just like managing uh funds because Aztec does have this interesting account abstraction model built in the way account notes work in our infrastructure another cool thing could be an airdrop manager um so creating an application that could allow people to airdrop tokens to users but on Aztec so this is all this would all be private um we have the docs would be a really good thing to reference if you're interested in building this just in terms of how accounts work how account Keys work how you could design a system where um someone sends funds to an account and then shares a private key or there's different mechanisms that we can make this work but I think an airdrop manager would be cool airdrops have been a obviously a big driver for user adoption in ethereum so making the same for Aztec would be sweet um with that I think I will go into a building with a SDK um I want to show here I'll go to the um I made this repo it's essentially a command line tool it's a command line application for interacting with Aztec and it's basically just a command line wrapper around the SDK so I'm kind of using this as the kind of like reference code for the SDK I've been working on it pretty regularly um and it shows a lot of the features of the SDK so I kind of want to just go through some of this code and show what the SDK can do um so yeah it's just that creates Josh Aztec CLI if you guys want to clone it um Let Me Hide this we can look at my vs code so this is a Oak Cliff command line tool and I'll highlight the pieces of using the test net first and I'll go into just some basic commands so you can see how it works but um you can see like a lot of the specific SDK commands that will be useful um if you're going to use this the Aztec SDK is written in typescript so it's really nice for building web applications or just anything that supports typescript [Music] um the first thing I want to note is using that SDK version in this right now I'm using this test net version since we're developing on the test net if you go to the uh 10 pm page you can see in on the Aztec SDK page there's a bunch of versions published just check this and see what the latest published version is we've been we're developing on this actively so these versions change pretty regularly and the back end is tightly integrated with the SDK so if you have a version mismatch it might break everything yeah so with that um package Json I guess so all the code lives in SRC um Network config as I guess is the first thing I'll mention um the our test net is chain ID 677868 [Music] um so you'd have to add this to your metamask let's see if I go to metamask if you guys can see that expand the view okay here we go so I go to networks um you guys will add this information um it's Aztec made net fork and then RPC main net Fork Aztec that Network chain ID um so yeah when you're using ZK money or the command line tool you'll most often connect with metamask you can generate your Aztec account Keys using metamask by just signing a message with your with your ethereum account [Music] okay so going back to the coat um so let me take a step back real quick and just like do a very high level of what this tool does um I think it's pretty cool because it's a command line tool so it's pretty easy to interface with um just type in some commands but it allows you to connect to metamask or wallet connect through a command line tool so you can use truffle dashboard to open a local RPC endpoint that will forward transaction requests to your browser so you can use metamask to sign so that means you could use a ledger or any hardware wallet the metamask supports or if you use ball connect as your wallet it will display QR code and you'd connect to the command line tool using wallet connect and then message signing requests will go directly to whatever wallet connect wallet you've connected with um I've tested this almost exclusively with metamask not as much with wallet connect so some of the wallet connect stuff might be broken um if you run into that stuff like let me know what the hackathon and maybe we can hack on it and fix it um but here's some commands on how you can install it uh to use just like with the Aztec CLI command but if you're running this from this repo um you can just do T bin slash Dev or dot slash bin slash Dev and then the command so I'd run like balance and that would be the balance command um this is just the convention that Oak Cliff uses so I mentioned the network config this network config info will come from the connected wallet so whatever wallet or whatever Network your metamask is connected to that's a network that the command line tool will use so if metamask is connected to mainnet you will be sending transactions on mainnet if you're on Aztec mainnet Fork testnet you'll be using that Network so it makes it easy to switch between mainnet and the test net just be aware of that so there's this base command that is run before all commands in the commands directory everything in the commands directory is just a command so there's the cut info command head key balance D5 Bridge deposit get fees history register transfer withdraw before all of those like before each one of those commands is run when you run it through the command line This base command runs so this base command let me get rid of this for now so we can see more um basically what it does is it like checks what wallet you have set in config um so this would be like metamask wallet connect I always just do wallet connect and you can read more about like setting this config in the readme there's details on like how it works exactly but like once if it's like wallet connect it does this if it's uh metamask it'll go through this but it's basically setting up your ethereum provider once that's set up it gets the chain ID so you don't have to like annually specify it it just gets it from the wallet um you can use the log SDK flag and the command line tool to debug to run the debug flag on the SDK so it prints a whole bunch of extra stuff just to see what's printing but then it sets up an instance of the SDK with the ethereum provider and a server URL um this is just the Aztec back-end infrastructure and we're just connecting to um the back end that we run for the appropriate Network um so this will basically get all the proof data that you need all the data that you need to like verify your transaction history generate proofs and do all this stuff so we'll run the SDK to like get all the data and sync it up and there's a couple additional commands for like getting a Aztec signer um and then getting your Aztec account keys um so we can just look at the balance command um where we'll just like print your balance and actually let's just run this so we can see what it does we'll connect to metamask so if you travel forward dashboard this is going to start you can see here in my browser just started treble dashboard I'm going to connect my metamask to this [Music] confirm the connection turn back to vs code go to a new terminal S command I'll run the balance command rather and what this is going to do is start the SDK looks like it's kind of slow right now maybe because I'm recording and doing a bunch of other things simultaneously um so now it's a way to use your signature of see the incoming requests on shuffle dashboard I'll process it I'll go to metamask here's the message it wants to generate my Aztec privacy key this is having me sign a message these send messages from my ethereum account generate my Aztec keys and I can see my Aztec balances here um yeah I was looking at the balances so yeah this command line tool is really nice to see like how you can like get your account keys and second account um by seeing how these are implemented here um let's see how to do something like a deposit that's something that what most users will want to do um actually let me take a step back and mention this concept of account aliases um so when you register an Aztec account on the network you can or you have to specify an alias this is just like a alphanumeric string I think it's 20 characters or less but this can be basically anything that hasn't already been claimed so this just makes it easier to send funds to people because you can send it to a name instead of some crazy long number hexadecimal number that nobody remembers so it just makes it much more usable [Music] um you can send you can deposit or transfer funds to Aztec public Keys directly or to these aliases um so in a lot of these commands you'll see like in balance and deposit you'll see this like parse Aztec recipient function which like the recipient can be an alias or uh Aztec public key you know it's like parse it and specify it will return and as the public key um but if it's an alias it will resolve to the appropriate public key if it's a pub if it already is a public key it will just resolve to um so yeah registering as Tech accounts is Handy um because you can also specify additional spending keys that are different than like your root private key um your root private key is the key that you'll use to initially register accounts but then spending keys can be different and you can add like an arbitrary number of spending keys so you could have a different spending key for each device so you don't need to copy and paste private Keys around devices um and then those can be uh yeah you can just add those as well um so yeah there's this like type of account abstraction with ounce that's really handy um so going back to the deposit example um you can like get your Aztec account Keys these this would be like your public key and like route to prep root private key um settlement time would be instant or next roll up press the recipient you can check if the account is registered with SDK um here I'm checking a flag if the spending key is required um the SDK for some of the controllers texture is a good thing to dive into there are these controllers in this case the deposit controller with the SDK which will do a lot of the proof generation and transactions signing requests and management on behal figure so it's pretty easy like once you have kind of this setup phase of like the assets you want to use the amounts um the accounts that you're using and you can just create a deposit controller with your ethereum account the amounts where they're going and then you'll just call a number of functions on the controller to basically interact with the Aztec back end so creating the proof signing a transaction um paying transaction fees or like in this example seeing if there's pending funds if there's not pending funds like waiting to be deposited into the network you'll submit a request to deposit those funds um and then actually sending transactions on the network so that's all super handy um there's controllers for depositing funds registering funds there's a register controller um transfer controller withdraw and there's also a account migration an account recovery controller those aren't in the command line tool yet and this would be something that would be cool to add for like a wallet management application um but yeah those are in the SDK and they're functional so it's just we don't have an interface for them yet and you can view all of this stuff uh in the SDK or actually um probably better places just go to Network there's a lot of good information on the SDK right in our docs with examples that are more um they're probably more clear just because there's not a ton of code around them it's just like very specific to the actual case so like you can see the register controller here how you'd set it up what it takes it might be useful to look at these docs pages in conjunction with the command line tool to see how it's implemented in like a working application [Music] but yeah I think with these docs pages and this like reference application um you're probably in a good place to start digging into like what the SDK can do and how it's actually implemented um and this command line tool is actually pretty useful if you're building other applications on Aztec um one of the difficult things with developing is all the transactions on the network are encrypted so like even just looking at the Explorer um you can't get a lot of information you can see there's like oh these transactions happened um recently I look at it and there's just like a bunch of encrypted data so like even just knowing if your transactions are working or like where they're failing can be difficult um so having a having two applications to compare and contrast against is helpful to figure out like if things are working um when I'm been developing this command line tool I've been using ZK money a lot so like I'll look up what ZK money is telling me um and what my command line tool is telling me and if there's a discrepancy then there's a book somewhere I need to add something about this D5 Bridge command um this is a work in progress it is functional as it's written but it's just doing a eat wrap stick to eat swap um passing the bridge id5 um eth and Ethan and rhaps take to eat out all the stuff is hard coded um it's setting it up and then using the D5 controller to actually um do the interaction if you're doing anything with Bridges he'll do something similar with the SDK but yeah all the stuff is hard coded in and this is functional so you can use it as reference but if you have questions about it feel free to reach out and we can dig into more of the specifics in Bogota um so yeah I think that's all I need to add [Music] um I think latte's up next talking about writing D5 Bridges um actually writing the contracts in solidity so thanks for listening and see you guys soon hey I'm Lizzie I'm part of this Aztec smart contract team I'll be giving a short introduction to how to on how to build Bridges to r1d5 from azteconnect so they did it for today will be they will look a bit into some background then we are getting started how to design some of these Bridges what do you need to think about writing a bridge contract just yeah I can where do you start on this testing and a couple of gadgets so as background from on as the connect you can essentially see the index in between as the connect and the bridge as a swap with two input assets and two output assets where the output might be delayed for some period of time uh this delay depends on whether the approach is a synchronous or asynchronous synchronous just being here that it's like instant is happening to send protection and async meaning that it will happen later an example of an async bridge is the element bridge that is live now where you insert some point and after the maturity uh you will be receiving tokens so or any of these a b c and d assets um can be if a supported esc20 a virtual asset or nothing and every of these assets have like a unique ID where the virtual assets when you're returning these so this will be when you're mending them from the bridges I'm sorry um the ID will be the interaction nons and a a virtually like a ID offset something to be aware of is that the amount of tokens A and B that you're sending to the bridge will be the same value mean that if you're setting if and die to the bridge you might run some issues that you would sell them set like one eighth and one die um but this is a way to get around some free rider issues that we have if we don't do some of these things we're looking at like getting rid of these but at the moment this is how it is so essentially we are having the good old trade-off for me you I've received a and b you receive C and D from the point of view of the bridge um a note on rebasing tokens if you're depositing a rebasing token into the uh as the interested connect then no WB generated for internal accounting is based on the value when you deposit it meaning that if you're depositing state if when you want true like withdraw it you will withdraw the same amount that you deposited so you will like lose all of your your rewards this is why we're using the Reps they give as an example so going back to just how this was outlined the reasoning behind outlining is as like a two two for two swap is that we can essentially do this for all bridges of a list I huge deal of bridges and which allow us to have this same circuit as all of the bridges can be like specified in the exact same way from the point of view of the boom as the connect roll up so we are specifying like what to do through something we're calling like Bridge call data so this is a un256 that's a uniquely specify what interactions should happen it's not fully using all 256 bits mainly because the field that we have in our circuits is a little less so we have a bit that's just empty but if we specify like what bridge should it be using what is the input output assets some configuration and a bit of aux data and this aux data is uptrend data that can be used by the by the bridge often this will just be like a flag for entering or exiting a position but it can also be like a price or whatever you is since you don't want it to be and but this is specific to the bridge so when you're doing a D5 deposit or an interaction with a defy protocol from Aztec you'll have this like blob it's a bit simplified but you have this blob of data that is your transaction so it have some public Bridge called data which specifies like what will you be interacting with and a public value for the divided deposit and there's a couple of other public values so here we you can essentially see like what is the amount that will be deposited into this D5 interaction from this transaction but you cannot see from who the reasoning behind the D5 deposit value and the bridge is called Data being public is that you like L1 needs to know what it has to do and how much fonts to send a nice thing with this is that when we are doing this publicly and we can use it to like save a lot of gas because we can aggregate Bridge called data that are like the same so if you have two users that both want to swap ease at the same price with the they can have like different values but you can like aggregate them up on this like one defy interaction is that that swaps 50 Neath and and then you have these D5 deposits like on the side but from L1 point of view you will just see like one user or here being the roll up performing this action on the bridge um so there's a couple of important points when we talk about aggregation if you just do like Naval aggregation here as we're saying like clef swap if to ref State leaf through proof status and then rubbing it you will have an issue of like okay you didn't specify any like price or slippage show now you just have like infinite slippage um it's private but don't help you if you lose all the fonts if you just take the root of specifying like a minimum output amount you have that another issue that you just can't aggregate these because okay now they differ and even if they had the like both of them were depositing five E's if they were both expecting like 4.7 out as output minimum when you aggregate them you would have like 10 if deposit still with like 4.7 as the minimum output so it doesn't really help there we'll essentially the device source of the input before where we're specifying like a price if we have both of them want the same like minimum value per if then we can actually get them up which just gives us this one interaction on mainnet then we have a couple of different types of these Bridges so beyond the single day sync as we briefly talked about we have a stateless and a stateful bridge so a stateless bridge is what you might know as like a sap or spill or recipe it's essentially a bundle of um transactions you could say that executes and then you end up with some other token in the end it will like not often it won't hold any fonts Beyond when it's actually doing the call and the code is often pretty small if I do this is very nice for doing like fungible positions or if you're just like moving some of this simple stuff um or when you're interacting with like stuff like urine where okay everything is integrated in another protocol and they have this way of managing their positions and then you have the stateful ones which handle some accounting internally and they might hold funds between instructions generally you have a large footprint of days because yeah they need to handle the accounting and they often useful for like more long-standing actions that are non-fungible so if you have like a borrowing position if you're doing like teasing limit order stuff like this uh is is useful um then a couple of other nodes just on the bridges is that the gas usage on a bridge is bounded so a bridge will be listed on the roll-up with an upper limit on how much gas I can spend this is to ensure that the entire roll-up will not fail if a bridge fails with an out of gas um but it also means that you need to be aware of variations in gases you guess uses that depends on L1 State and can be ordered by other parties this you might end up in this listing the bridge with two gas in some cases and then sometimes it will revert and you might need to list it again with a higher limit to to actually get out of the position and if a bridge will revert in a call the roller will not fail but it will emit a an event where it's just like Falls for failing um but otherwise we'll just continue executing this can make debugging a bit tricky if you start with doing end-to-end test uh just because you won't see any of your revert messages directly you would need to look for them inside events um so to get started on stuff like this you essentially you can go to wow like we have an Aztec connect Bridges repo which has like a small introduction on how to set this up we are building it up with The Foundry and so you can also use the like The Foundry book essential to to get some help there on like how to run Foundry or if you have specific issues um that are Foundry based you can take a look there otherwise go to to our Discord to task for help then we'll be there um when the signing Bridges you need to like just keep in mind that for a couple of things like should the bridge be synchronously synchronous should it be stateful or stateless can the bridge be done by just like using it like esc4626 if it can build the esc-4626 instead and then use the generalized 4626 Bridge um or of course only do this if there's not already like a canonical 4626 if there's one of these just okay listed instead don't need a separate Bridge if any of the output tokens are rebasing is there a wrapper already for some of these tokens so for like reps like these is one of these canonical rappers but for other basic tokens such as at the a tokens that is not really canonical rabbit right now but there's one soonish um but you might run into issues where there's no wrapper so you need to make one and then you need to think about how can you use the aux data to support the bridge so it's something that is useful to just pass along instead of having to fiction from an alcohol or whatever so if we look at the curve State div swap this is sincerely like a synchronous Purge it's just doing a swap it doesn't need to hold any stake a state so stateless could we do it with an esc-4626 probably but it will be a bit annoying it would not be as compostable as just using like rap State instead yeah let's take the officer rebasing so we are using web State div and what can we use the aux data file here we can use it for Price data related to the slippage so with this in mind we can essentially draw a couple of diagrams where we are going from the roll up to the bridge bridge will swap like when we're entering Schwab Eve on curve stay with his wrapped and return to roll up and reverse order when we're doing the um the withdrawal this allows us to support like rebasing token honest is take connect um yeah when we want to implement the bridge we just do the figure out what language would we like to implement the solidity fiber half if you're into that if you want to implement it in Viper be aware of there's a couple of quirks because our like execute function is called convert which is a keyword in Viber so if you look at this bybook vlp bridge for reference you will see that we have Brute Force they selected a function name that will hit the same selector for solidity we have a bridge base that you can use it contains some addresses that might be useful for you as like a subsidy and also a couple of like useful error codes modifiers some of this stuff then you also need to think about can you do pre-approvals or do you need to approve like the roll up or other contracts every time on some uh Bridges you can do a pre-approval um on off the roll up to just pull the fonts it will save some gas when you're doing the executions better than others if you're like listing new assets down the line you might not be able to do this full pre-approval and need like a function to to do it later on but it will say you some gas if if this is possible um when you get to testing we have like two stages which since you'll have unit testing where you just show that the word Bridge works when it's by itself so you test edge cases all of the stuff where you check that all the reverts are here that the output values are actually what you expect them to be and that you like first values that can be fast so go look at the example unit uh T dot solve for reference of this and then the end-to-end testing you can use our like Bridge test base to mock roll-ups um and like execute the defense action and to check that the events um from the Defiance action is thrown uh throwing like failures when you expect it to and at the output tokens are actually transferred as we expected to and we have an assembly into and test for reference there a couple of cultures that we just need to keep in mind is yeah both of even though you have two input values or two input assets you only have one input value the gas estimation is used up front often we also use it from there like the sequencer to figure out how much you use to pay and this can happen like multiple hours before the enticing is executed so it's pretty important that it's somewhat precise and when testing with the roll up if the brace will work it don't revert the rule up so you need to check the like events and when you are like aggregating it to try as identical call data so think careful about what you're putting into the aux data um as otherwise it might be impossible to aggregate efficiently and then ending node on building a bridge with depth if you're building a bridge that will hold depth so say like an opening another position so deposit a token a use that SQL borrower token C now the bridge will have so in CS depth what happens if the bridge is liquidated because of market conditions can a user deposit um and borrow on another risk value or risk and get just risk parameters if they can they might be able to borrow using someone else's collateral which is not ideal so you need to think of some of these case like all the cases where the balances of the bridge can be changed by someone else in a negative Direction needs to be taken care of when doing this and for borrowing this is yeah a bit more complex hello today I'm going to be showing you how to make a basic zero knowledge circuit in Noir and how to interact with it using typescript Noir is a domain-specific language that enables creating and verifying zero knowledge proofs so first you're going to want to go to Nora's GitHub page which I have open right here and clone the Repository Noir is written in Rust and heavily inspired by rust thus you're also going to need to install rust before being able to use Noir more instructions can be found here in the Noir book that gives it some more information on installation and also on the syntax data types and other information that might be critical for your development so we're gonna head here where I already have the Noir repository open I'm going to CD into crates slash nargo and I'm going to do a cargo install I'm specifically going to install it and store it in my path so that I can access it from anywhere else in my machine however unless you're on Linux you might have some issues with installing this Noir specifically compiles down to an intermediate representation that any proof system that is compatible with that intermediate representation Noir can then generate proofs using that proof system right now Noir is specific to Aztec C plus plus back end which can lead to some build issues on different machines so if that's the case and you're having some trouble replace this line This Aztec back-end dependency with this line here and this will use the SQL C plus plus back ends was an executable instead and this should this should develop this should build on any machine so I just did a cargo install and now I have nargo I'm going to head to a separate example project and you can see I can do a nargo help now and I can see all the commands that are possible within our go so I'm gonna create some a nargo project so I'm going to do nargo new circuits this is just a blank hard hat project that I initialized using yarn for testing purposes so I'm going to do nargo new circuits and you can see very basic project with a main file and anargo.tomo similar to Cargo in Rust so we're gonna now edit this circuit and I'm gonna make some slight changes anything returned from the main function must be public that's why you can see this Pub word here all inputs to main are by default private but you can specify Pub if you want it to be a public input our circuit is going to be very basic we're just going to calculate what x times Y is and we're going to return that we're not even going to put in a specific constraint into this just yet so now if you want to check whether or not the syntax is valid you can run a nargo build oh you can see actually here I am not inside of a nargo project so I have to CD into circuits and now I'll do nargo build you can see the constraint system was successfully built and then two more files have popped up approver.tomo and a verifier.tool you can see it already found the specific values that I need to specify in the proverbed optimal I need both the private and public inputs while the verifier just needs the public inputs so we're going to start with some basic examples so I'm going to do 3 times 4 equals 12. so save both these so now we can actually compile our program I'm going to do nargo compile p and P here will just be the name of the build files that I create we successfully generated our intermediate representation which is called our Acer which stands for abstract circuit intermediate representation to be specific and you can see two build files inside circuits.acer and Dot TR dot TR represents the solved witness which you can use or can't use and we'll get to right now as I describe how we're going to prove and actually verify this circuit so now I have this test folder here that I can use you can see I have a few packages I need to install these represent the typescript wrappers around a lot of the Noir logic that would normally be done in Rust but is now enabled in typescript so I'm going to do a yarn add Noah wasm I'm also going to do a Noir ad for the breitenberg library which is the C plus backend and proof system and then also the Aztec backend for some specific logic and different ways of verifying proofs that I'll show you so these packages are getting installed okay now that they're installed we can actually verify some proofs so we need to fetch our Acer from the the intermediate representation from the file so I have this helper function I made here path to you and eight array it just reads the file and specifies it in a in a un8 array that's just due to this function requiring a un8 array so I'm going to first oh you're going to want to read in the byte array and and then deserialize it this this is the same thing we're actually going to do for our Witness and then we can actually set up our proverb verifier using that intermediate representation we can then create a proof using our Witness and we can then verify it and we can then write a test verified dot equal to true and that's our basic test right there so if I then run MPX hard hat test these are all passing although this is there's nothing inside these tests right now so I'm going to show you some different strategies for how to do this this witness byte array relies on the solution that the rust came up with but this is not necessary you can actually compile the Noir program itself using this compiled inside of the Noir wasn't package and then this will store this has then the Acer the intermediate representation and the program API you can then specify the ABI directly within typescript here and then you're going to do the same thing that you did previously where you set up the proverb verifier you create the proof and verify the proof you'll notice here though and create proof with witness we pass in the Brett brettenberg witness array while in just create proof we pass in the Acer and ABI which is what generates and they generate the witness array within the within the typescript package so we can kind of combine these strategies how you'd like um to your to your own preference and I'm just gonna copy and paste a couple of examples in so here we can we can read the Acer from file but still specify the API directly like this and then we can also compute the witness ourselves and then use create proof with witness if we so choose this is probably my preferred strategy or just compiling it directly I prefer the JavaScript objects to this array it's important to note though when you're Computing a witness to have an even number of bytes specified as it's not going to the program will break otherwise so now we can save this and run our tests and we have four passing tests where we have now proven and verified our program so there will be other links in the description but updates to this example repository will be made here and you can follow along as updates are made to the typescript wrapper and Noir itself and this this can be used as a reference thank you