ZK HACK - Introduction to Aztec Connect

Transcript

hey joe hey how's it going hi hi hey everyone hello okay i'm taking this down welcome zac and joe today we get to learn about aztec connect uh zach actually who's going first here zach right uh yes perfect so why don't we get your slide set up and then you can take it away sounds good yeah let's let's get this get the show on the metaphorical road um by jumping in halfway through the presentation we can see both of your slides here i think you mean to show the other one yeah okay one second let me just uh i'm just gonna i'm just gonna kill my

second monitor because i don't think my web browser is oh actually when you when you do the um share you can actually choose which browser sometimes or screen but if this works yeah it works i think it's worth um around sergio can you just heckle if people are asking questions because i can't see the chat at the moment uh yeah i can uh i'll also post them as questions yeah perfect yeah questions for anyone who is asking questions put them in the sessions chat not the events chat if you see there's event my agenda sessions just pick sessions chat there's also the q a the q a will potentially like bring that more to the forefront sometimes questions can get a bit lost

in the chat but yeah take it away uh now we get to learn for zk hack all about uh privacy defy with aztec connect looking forward awesome uh thanks thanks and yeah hi everyone um yeah super excited to be here and be a part of this um with you all so uh i'm zach um i'm here with joe um we're both the uh co-founders of uh aztec and uh i wanna talk we wanna talk about our latest project that we are deploying to mainnet um in the next uh one or two months called aztec connect and going through how one how to build with it um and what it is and all of that all of that goodness this might be a little bit of a more higher level um uh

um workshop than some of the other ones because um this is all about us again is all about how do we um interact with layer one smart contrast from a layer to in a previously preserving way and um specifically around um we're going to be talking about the cryptographic protocol that we've developed to do this and how one actually interfaces with it um in the form of by creating a layer on smart contracts that effectively um uh perform a translation step um uh that that maps the the uh like um takes tokens coming in from the asset network um puts puts them into layer layer smart contract gets some kind of output and returns it back to the

network um we call it these these things d5 bridges and um we're pretty excited about what they what they um open up on ethereum in theoretical other blockchains uh as a way of both scaling ethereum adding privacy um without some of the drawbacks associated with liquidity fragmentation and all of that jazz um but yeah um so that's that's kind of the high level what we're going to be doing um we're going to split it into um two talks i'm more kind of theory just going to be than doing some some on the applied side running through actually how does one program with classic can it have one build these privacy preserving bridges um doing and doing it an interactive coding session uh so joe would you mind sharing some links in the chat because there if folks

want to get um kind of set up with that we have some tooling and resources in a starter kit that joe will be using quite heavily um yeah just paste it in the chat so awesome so yeah basically um high level background what are some of the issues well i think we've all probably used ethereum or at least heard about some of its problems it's crazy expensive to use because of the extremely high demand and limited throughput and um on top of that um something which is getting more more of an issue day by day is the more that more that uh people individuals kind of economic activity um is being put on chain some more information is being leaked about their identity uh and if we don't solve this um fairly fairly soon then we're going

to um web 3 is going to go the very same way of work two where the primary monetization model is going to be farming people uses information uh which i don't think any of us here want it's why we're here so that's what that's what we're trying to solve um and and so uh one of the steps along this very long pathway is um uh this aztec connect project that we're we're building um effectively it solves the these two issues on ethereum today um it enables users to interact um privately with default particles on layer one without having to fork or migrate a protocol to a to a layer two um and it's quite a is easily um can the goal is for it to be easily integrated into existing projects um

with uh very little actual um cryptographic knowledge required to use the interface um uh so briefly how we talk about d5 pointing how does it work well imagine you've got a bunch of people that want to do the same kind of transaction like say sort each to die on unit swap well um if they all have funds on the asset ait uh what we will do is we will aggregate all of their transactions together and we do that through zero and seek stocks um so each of these transfers is private transfer where each individual transaction is itself as if he's not proof um and then inside our layer two um we have something called a well it's a dk roll up and in our roll-up circuit we verify the correctness of a large number of these individual transaction proofs and the con and in the context of

default pooling uh this means that um everybody's um transactions get effectively added together so that when um this roller block is processed on layer 1 as part of the public inputs there'll be an instruction to send a single transaction to a layer one smart contract to swap the aggregated sum of everybody's eth for die in this case um this will happen through the through a bridge contract um where the idea will be that the bridge contract understands the asterisk layer 2 interface and understands the smart contract interfaces swap talking to it'll perform the unisop exchange send the tokens back to aztec and um then the proceeds will be disseminated back to the users in the correct ratios again visual zeros proof in the output of this will be um uh

encrypted notes where uh the identity of the um individual transacting has been hidden at every step of the way so i've been mentioning i mentioned bridging a lot um how does it work well we model a1 smart contract interactions as um either secretary synchronous token swap so the idea is you have a couple of input tokens tokens um yeah the dresses can differ the exchange rate doesn't have to be known ahead of time and the brisk contract will will um uh receive these tokens from uh our aztec well small contract um the british contract will then do some kind of predefined deterministic interaction with a layer on a smart contract or multiple smart contracts and then return

the funds back into return the output tokens back to aztec anybody can write these british contracts um uh the the the internet network is going to be completely permissionless and um we're quite excited about some of the applications this this this opens up things that you can't really do on ethereum right now things like um fully blind auctions or private voting anonymous voting as well as the more standard use cases like being able to uh cheaply and privately access um like trading and lending protocols uh so i would like to go a little bit into the the actual circuit architecture because this is the zika hack so i imagine um folks are a bit more interested in the lower level governance of how this actually all works

uh um particularly what are zk what are the zika stock circuits um constructed as because uh actually executing this kind of um protocol is fraught with challenges both to ensure that it's efficient to use as a lot of zenora's person to be constructed on the client and these are relatively complex uh but also to ensure that no information is leaked any step of the way uh was made ensuring validating the security of the entire architecture uh so asset connect um consists of uh four uh zika snark circuits um so the left hand ones are kind of what we call user circuits because they they represent individual transactions and my headphones are um

circuits whose proofs are generated by um third parties that have a reasonable amount of resources um say like you know like a steady talk core machine and they aggregate uh batches of individual user groups together um and this is an untrusted um component uh where like there's there's no um sensitive information they have access to um by that point um all information has been obscured by the user proofs and so we have this this uh joint split transaction which is um this genesis came from uh z cash and the the zerocoin paper that they implemented where you have two kind of inputs ut encrypted utx objects that represent value um

uh they get destroyed you create two utx objects in their place um and you validate the the the the input the sum of the input nodes that have been destroyed matches some of the opponents that have been created um and the appendix can have different owners this is how you do transfers uh you can modify it relatively trivially to also handle deposits and withdrawals of erc20 tokens and ethereum from layer one and we've also modified our transparent circuit to perform these d5 deposits and then the d5 claims circuit will um basically uh it'll take the result of a of a layer one interaction uh presumably a defined traction doesn't have to be there and um can convert those um convert the the the notes created in the d5 deposit step uh

back into um fundable output uh tokens and finally we have our roll up circuit which will aggregate all of these transactions um enter into a single uh proof um uh and we actually have a also but then a root roll of circuit which will aggregate relevant circuits um and so instead of doing doing so if you say want to aggregate 512 transactions in one shot instead of making one big circuit to do that you split it up into these into this kind of um tiered hierarchy uh to make it more efficiently parallelizable and so this this makes very very heavy heavy use of recursion using techniques that we developed um uh roughly 12 months ago um

so um yeah actually i've just um i've kind of combined two slides and one i'll skip over the slide link because i've already said this um uh as a diagram this is what it looks like um to do a d5 deposit so the idea is uh the traditional way that you represent value in azdek is using these value notes they their commitments to a public key which defines the owner of a note um an asset id and a token and the value of the notes um i've uh left out here there's also a secret um associated with the notes that you need to bring knowledge of in order to spend it um and that's that's what makes the commitment hiding uh so you have two input value notes they get destroyed and in the place you have an output

value note which is kind of like your change node um a remainder node and a claim that and claimnet is a bit of a weird construction because what what it is is it represents a claim on a future transaction that has yet to be um persist particularly specifically this um um layer one def interaction uh it's its components are it has a value that the the the amount of value that's been um uh deposited uh this thing we call the interaction nonce which is um it's just basically um it's a unique identifier for the defined direction so every d5 interaction the aztec makes we'll have a unique interaction once um uh but we do some rather um um i've extracted away a fair bit here

because the when you're making a one of these proofs using rsdk um you don't require knowledge of the interaction once that gets added in later um uh by when the ruler block is created because otherwise you'd have a bit of a race condition there um you have this bridge id which describes the um what define traction you're performing uh as well as this thing that we call the partial state uh so the um the bridge is is the easy one to explain it basically describes what's the input asset what are the two output assets um and what's the contract address of the bridge um that's being talked spoken to and the but the partial state is is a bit more um complicated what it really

is is it's it's it's half of a value note commitment um because what we want the the main goal that this solves is this claim note represents the some some future transactions going to happen and when that transaction happens we're going to transform this claim rate into some value notes so for example if you're doing an ether to die swap then you're destroying eth and the claim note represents a claim on future die that'll then have to be in a later transition converted into a die value unit um but we don't want the user to do that because that's a pain in the neck right like if you're if you're transacting with um a theory or another layer one um or even even layer two and you perform a default reaction you expect that to use it to be non-interactive but if i if i trade on

unisop i don't have to i don't want to have to like come back a while later and then kind of perform this kind of conversion proof to convert a claim to manually um and so we're taking advantage of the fact here that our commitments to value notes the the pedestrian commitments um so they just they just use um uh um uh that creation developed a curve so that the curves have this very nice property that they're homomorphically additive and so um it's possible to create a a partial commitment to a value node basically it's a value unit that doesn't have a value and it doesn't have an asset id but as everything else has the secrets it has the user public key and then at a later stage we're going to complete the commitment um uh once we

know what the value of this note ought to be and what the asset id ought to be we will then um create that partial commitment and um match that together with a partial state to to to create demand unit and this can be done completely trustlessly by a third party um the user that created this this um deposit circuit proof doesn't need to be involved so that's why we use it obviously this does um leak some information uh specifically the user identities here are all hidden but the um the value is not because in order to perform this define aggregation um the uh you need to know what's being like how much um value is being put into the d5 into a

into a bridge contract in a given roller block um and so that's uh that's public its components are public so um in terms of uh like your privacy anonymity and anonymity um this is uh a d5 interaction or an asset connect interaction could be very much modeled as a like a traditional withdrawal interaction from a for or an unshielding interaction from a privacy preserving network it has the same properties where you um you identify um that you expose a value that you're extracting from the network and therefore um uh uh if one is not being careful about when they do this and the values being used then it could be some information

that can allow transaction graphs to be to be extracted in a similar manner to um in properties of the z cache protocol um so anyway that's plain doesn't claim this that's our d by deposit flare uh the role of circuit with an aggregator he's giving the values together um for uh uh per bridge id and that's what gets spat out as public inputs um each aztec rollup block can process four define directions up to four um like as in like um four can talk to four unique british ids uh and and each um one assumes that each interaction will have a relatively large number of batched aggregated transactions this is valuable because the the expensive cost of that layer 1 interaction gets

shared across all the users in the batch and so when it comes to actually um redeeming um this claim note um yeah this is this is the redemption uh circuit so once you um if you create a d5 deposit proof um you send that to the asset network that gets aggregated by a rollup provider and then in a nasdaq block that gets processed on chain then the layer on smart control performance definer action and it'll generate this this this data structure we call it interaction result which just basically has to disclose what happened exactly we've got one question quickly just on the past partial state uh yes

um just there any other places where this is used or kind of literature about this this idea of kind of a partial commitment and then uh like extending it i guess is the question not that i know of um i don't think this is particularly common um although i do i suspect it's also quasi folklore um um so that's like fancy photographer term for just um uh it's probably been done before but not like written about in an academic journal uh because it's it's a bit um these partial state objects would be creating like part of the commitment and then combining it later on uh you're you wouldn't do do that in like a

traditional kind of cryptographic protocol like a commit reveal type scheme because uh it leaks information right like this um by creating this partial state and then completing it later on you expose um the um some of the the plain text for that thing that the data that you're encrypting this specifically this is the value of the note um and in most pr in most kind of like basic characteristic protocols that would kind of be a bit of a deal breaker um uh but but in our in our case it isn't because it's um uh because of the the way that the the anonymity network is structured it's it's the same uh anonymity guarantees as a um uh as withdrawal from the network the important thing here is that the

identity of the no toner um is um hidden uh that's what uh which is important um uh i yeah so that's um so get back to the inter interaction results it basically describes like what was the bridge id that was that was spoken to what was the interaction launch um how many tokens were um shoved into it uh and how many tokens were received um there can be up to two taken to upper tokens or two upper values and also a um um a success variable a boolean which describes whether this interaction result was was successful or not because one of the properties that we wanted

from this this architecture was that you could um kind of successfully fail a transaction so if you do a definer action that fails for some reason um because you know some conditions weren't met on the on the in the d5 protocol your funds aren't lost you get back your input asset um uh um so we're kind of taking advantage of the the fact that you can kind of um inside an ethereum smart contract you can transaction you can partially revert a failed transaction so whenever the roll-up um contract performs a defined direction uh if that defined traction fails in any way then that that that component of the rollout transaction will get reverted and so it's like the the

tokens never left the network at all and so you can for a failing defense interaction you can take your uh user claim notes and effectively convert them back into the uh the the input well you can but you can you can use them to create a note whose value is the same as the as the as the value units that were destroyed um to create it um but if the if if the interaction did succeed then um you use this interaction result data to take claim note and convert it into this into its um uh a lot of output notes um just doing a simple ratio check so you take like how much is this note worth as a proportion of the entire um

uh the entire amount of um tokens that were sent into this in this defined direction and whatever that percentage is that's how many of the output tokens for each asset type that they're also due um uh i did have out some formulas here uh on but they didn't get correctly copy across to the slide and i really just noticed that but this is basically the system you take the the user's input value divided by the total input value that's your ratio um and then you you multiply that by either the the output value for the a or b output token to get the these these output values v1 or v2 um uh and additionally those asset ids of the output nodes they're also conditional whether the interaction succeeded or failed if their interaction

succeeded they're going to be defined by the the output token ids of the bridge id uh but if the interaction failed they'll just they'll be equal to the input token um ids um so the important thing here is that the from the user's perspective this entire transaction is not interactive they don't have to worry about making this claim conversion proof the role that provider can do it um and we've also um something i missed out here is we've embedded some information the claim note to ensure that the royal provider gets paid a fee for performing this conversion step so isn't that economic incentive to do so um specifically uh when you um in this d5 deposit flow um i've mentioned here that the

transaction fee paid the raw divider it's the difference between the sum of the input and the output um values what i didn't mention is that fee gets split across two transactions so the um the roll-up provided by half of that fee when this circuit proof is is is aggregated to block but the other half of the fee is recorded inside the claimant directly um i can only get again it's only kind of released to the real provider when this claim conversion proof is processed which provides the economic incentive for the for the for this second component to happen uh automatically from the user's perspective um so yeah um any ques any questions before i uh move on

uh there's one question i'm not sure i fully understand it but we've got uh can we have a case where u1 is negative while u2 is positive on layer um i'm not quite sure uh no no no um so yeah we explicitly forbid negative values because that um creates problems uh um uh so yeah we use a tonne of range trips here to make sure all the tech conveyor all the values have to be positive here there's there can't be any overflows of copying underflows um technically note values and stick are 252-bit integers so um a token value is a 256-bit integer in in in a smart contract so um in theory you can't represent a complete token balance but in practice you you

you can because um uh apart from some like some very niche custom created token the um it's unlikely that you have individual transaction values that um uh extend beyond 2 to the 252 because that would be um uh 1 16 of the entire potential maximum valuation of that like number of tokens in that network um uh so yeah um so just to summarize this um the goal is to is to to create kind of composability to layer one transactions that are aggregated by ziggy it's not proofs um this allows relatively cheap access to label defined protocols without

splitting liquidity um across multiple networks because the actual liquidity of the d5 protocol that all stays on l1 the only thing that changes is the the the the ultimate kind of like the the the the um the assets um that individual's holes move to there too uh but the actual default protocols and the logic and the execution of that protocol stills on layer one um and all including all of the associated liquidity um so the the uh the goal is for this to be to is to create a very pleasant user experience where the transaction is relatively cheap um and the uh um they never getting the best rates and the best prices because they're not having to take a risk by um porting

migrating to um a fragmented liquidity pulmonary but most importantly uh for us at least identity is a hidden uh so the um uh so it uh when used um in uh uh when you when you when it's correctly it's it's completely privacy presenting with a sufficiently large anonymity set um and our target is uh this is a little update we're going to be targeting rule of looks every 10 minutes on the network but this is very much a function of throughput and demand um and yeah um anyone can write these british contracts um and then get get a roll up um and have a roll up block uh kind of um aggregate these bridge transactions um

and uh we have this that's why this is why we're part of the sega hack workshop is because we want to we want to encourage folks to to experiment play around with these bridge contracts um try some some some normal applications uh if they're uh if any of these if these are kind of um uh igniting any brain cells because it can it can enable some rather interesting flows that aren't possible at the moment um things like yeah time wages purchases subscription services that are private um uh being able to do blind bidding private voting um kind of genuinely uh enable some some like genuine anonymous styles where you don't have the the issues of kind of

social peer pressure or group or group pressure um influencing how um stakeholders vote um uh so yeah um i think this is this is where i'll hand off to uh joe um who's gonna go dive into how one actually goes about programming um these these privacy preserving bridges and doing a bit of an interactive uh coding session thanks zach um yeah just on on the blind auction uh one just just before you go is it worth doing uh what could have happened if the constitution dao had been inside aztec i think you that you had a good analogy uh to that that's maybe worth sharing um yeah i can remember it so yeah so the constitution that was it was it was an awesome project right like it really

showed the potential of what web 3 technologies enable you know disparate groups of individuals being able to coordinate and organize with one another towards the chef purpose in a way which is really just isn't possible using any other technology and the but the downside of this was that well everything was public and everything was transparent so when they were trying to buy the constitution but everyone could ever all these competing bidders could see exactly how much money constitution down had to spend on it which is a bit of a problem uh in an auction um so uh you know we're not without saying oh there should be zeste because uh because i mean that second isn't launched yet so they couldn't have um but um uh the

like the end goal is that dials like these can accept deposits from users through privacy presenting network like aztec and so that uh nobody apart from uh a very like apart from like um like like some kind of coordination committee within the dao would actually know uh what the the total amount of um the positive value was uh cool thanks zach um before i start i'll just dive into these questions yeah on um uh on the block time um so this is a zk roll up so there's no kind of um withdrawals like uh the optimistic roll up so there's no kind of withdrawal time the reason we've picked a target of a 30 minute block time um is just for batching of transactions

um the layer one uh roll-up costs around 400 to 500 000 gas to validate so if someone wants to pay the full cost of that uh we can do it every ethereum block um they just will be paying a lot more for the cost of privacy uh so we're trying to get uh kind of several hundreds of transactions um batched together and split that over a number of default interactions but there's no real theoretical limit on kind of getting this down i think the current proof cost takes about three minutes to make um so that's kind of a latency that you could expect if you're willing to pay yeah yeah just just just just just uh like the current agency's three minutes if if that was a bottleneck we could get it down um significantly

uh but the um the the reason i i mentioned 30 minutes is because yeah um basically you need you need to aggregate a relatively large number of transactions say 100 to 200 to make these transactions economical for the user and so how many blocks you can you can process um in in an hour depends on how many transactions you have um so yeah if if we had a high throughput then we we would get go down from that uh from 30 minutes to you know 10 minutes to five minutes down to three minutes then we'd have to do some work on the core architecture um so to get a lower than that yeah just for the current state so zika money which is using um sully older system is able to do 112 transactions in around 20 minutes

we currently don't send those proofs so unless the roll-up is full and we can have two blocks every two to six hours currently on the current system if the roll-up's full it will go in around 20 minutes um it takes about 20 minutes to construct the proof but yeah it's not paralyzed at all um if you were a chain that kind of had cheaper gas prices and people were willing to kind of pay and yeah you could have cheaper uh much faster latency um yeah i think uh bannon smart chain i think has the required op codes and maybe later next year we'll do some

analysis on kind of uh which other side chains or um optimistic rollups we want to deploy to but for now the focus is uh layer one uh liquidity because we think the the strongest demand for privacy is is on l1 uh with our one default criticals cool i'm gonna get started um this is uh i don't know how far we'll get through this um just a quick agenda uh we're gonna kind of do a quick demo of the uni swap bridge on the girlie test network kind of see how you interact with this with rsdk um i'll run through some more slides just to kind of um hammer home some of the things zach was saying on how this actually works when you're thinking about uh coding up

one of these contracts and then we'll dive into the starter kit um run through the code behind the ud swap uh contract and then we if we have time we'll start looking at how we're planning on implementing uh the element finance bridge contract which is going to be one of our launch partners uh they do stable lending so the last part is going to be like a completely live coding so please forgive any any errors but it should be quite fun um so let's get started uh just reiterating what uh what zach was saying here [Music] depending on the d5 protocol we can bring 10 to 30 times gas savings directly to layer one this is using

batches of kind of around 10 to around 100 depending on kind of how much savings you want to give to the actual user uh and all of these interactions are anonymous and so great privacy uh to existing uh l1 smart contracts um it's just a quick schematic on on how this works there for the uni swap example which we'll see in a bit more detail in a minute um just again to run through uh some stuff that zach said i think this has all been explained um in terms of actual gas costs uh i think the one thing we didn't go into uh in the earlier slides are kind of the cost of one of these interactions um we're targeting around 8 000 gas per transaction

at launch that's the cost of privacy um so kind of the shared cost of being in one of our roll ups you then will split the cost of the layer one transaction between all users who are in your batch uh you always have the option of kind of going it alone i think of it a bit like a private uber and kind of being in a roll up with other people but doing your own default interaction um if you don't want to kind of wait for uh that kind of aggregation to happen uh wait for kind of 10 to 50 of the users other users um so you have these these gas savings uh pretty significant when you're looking at layer 1 d5 protocols because an average uniform transaction is around

170 000 gas some of the more expensive lending protocols come out at close to 350 000 500 000 gas and we'll see in the case of element uh finance the end-to-end flow for some interactions can be close to 750 000 gas um when you're kind of dealing with complex urine volts and the complex interactions that the costs add up quite quickly and have priced out a lot of users from layer 1 d5 um in a bit more detail um actually we'll do this with the code so i'm going to skip this slide for now um uh the interface uh i think is an important

um thing to go through because it's kind of written in solidity uh for people who are interested in kind of uh zk programming but uh maybe don't have kind of the deep cryptographic knowledge um the aztec connect sdk and the the bridge enable you to kind of get started with um using and bringing privacy to users but not necessarily having to worry about the kind of deep cryptographic implementations uh on day one so any developer who knows solidity can uh write a bridge contract that conforms to our interface there's only three functions on the interface as a convert and a finalized function and we'll go into that in a bit

more detail but the interface supports up to two input tokens those are shielded tokens coming from aztec and you can give back up to two output tokens back to kind of the aztec network and there's a distributed pro rata to every user uh who took part in the original aggregated transaction um cool so uh just a bit of background on element um which we'll dive into in a minute uh we're likely launching with element through our zk money uh interface um element's a great kind of target when you're thinking about building a bridge contract because uh

in the early days uh when the roll-ups are going slightly less frequently um you're doing fixed-rate lending the interest rate doesn't fluctuate um drastically over time so if you're putting in a small amount of money into one of these lending protocols the difference of kind of 30 minutes to two hours uh being in a batch uh doesn't actually affect kind of the overall return you get from being in this protocol so it's a great target for batching and also the fact that these are going to fix rate interest protocols and fixed term mean the the mass behind this is actually lends itself quite nicely to batching uh and they support a lot of popular assets that people uh usually

would like to hold um because they're they're long that asset but also uh want to earn additional yield just from holding those assets and in terms of the gas costs um it's quite expensive so uh end to end for some of these flows uh for large emotionals um you're talking around 750 000 gas which if you split that between 50 to 100 users a huge gas savings and enables kind of l1 d5 to be used by smaller users who have been priced out which is a bit more aligned with the original i think ethereum eso ethos which we've moved slightly away from uh because ethereum is slightly becoming a whale chain so we're trying to kind of

use some of this technology to uh enable people to interact with all these amazing protocols that have been built on top of layer one and a bit more battle tested on on mainnet so people haven't done this already um and you'll kind of want to kind of code along with me um there's a starter kit at aztec protocol github slash aztec connect starter we also have a grants program i will share the link in the chat shortly the grants program is something we're kind of very excited about uh we're going to be giving kind of engineering resources to helping people write bridge

contracts for their favorite uh default protocols um and we'll also be kind of uh funding both in a monetary perspective and subsidizing successful bridge contracts when they're deployed to the network so if you have an interest in kind of helping code up a bridge contract for popular d5 protocols that you you know about or a part of the community um apply um to our to our grants program and even myself or lisa or john from our grove team will be be in touch to kind of schedule um a call to chat through what you want to do and hopefully we can get some really exciting bridge contracts written just share the link in the chat right now all right

i'm gonna try and switch screens is this coming through okay yep fantastic um cool so um zach mentioned this a little bit on on the earlier call but uh the way you interact with the bridge i think is is important because uh it's just something

that sometimes gets forgotten about um all of these interactions at the end of the day are zero knowledge proofs so they they run in the browser and in order to be privacy preserving you need to construct this proof in the browser so the starting or the entry point for a user who wants to interact with your proof is is not a solidity or ethereum transaction they're going to be making a aztec layer 2 transaction using our sdk which under the hood is constructing a zero knowledge proof uh in this example i'm about to do a demo of we're just running the sdk locally um kind of in node.js it's just a typescript sdk and it runs in the browser

and the way you kind of interact with a given bridge is you have a bridge id uh which kind of defines the smart contract address you want to call um and the assets you're willing to transact with so you can see here down on line 76 in javascript um uh talking about uh i'm just coding up here the uni swap bridge id um and then passing in uh the address of the default bridge which we define up here as our unicorn bridge we'll go for in a second uh while we're waiting for the uh transactions to settle um in this case we're going to be depositing uh eth and getting back some test die on a

kind of girly test network and you can see that the the client code is about uh this does a full deposit um so the user here is starting with shielding the eth um and then they're gonna take some of their shielded balance deposited to the default protocol um and then do a default uh deposit and wait for it to claim and end up with the die on the aztec network so there's a little bit more code here because there's that deposit step but uh it's pretty simple to actually integrate into a front end um so let me just run this and whilst it's kind of running uh we can pull up either scan

and kind of watch what's happening and then we'll talk through the code in a second so the first thing the sdk does is it creates the the proving keys um to enable you it to construct these proofs uh on our test net there's been some roll roll-ups previously so it's just doing a quick sync of our balances uh and then it's already uh starting to generate my if deposit proof in a second you can see what i've done here i've shielded 0.2 eth we're waiting for that to settle before it actually does anything to do with uh d5 and if i head over to one second uh i'm gonna head over to eatscan uh we can see here i was playing with

this earlier this is the the roll-up contract um my deposit has just come into the roll-up contract uh we can see 0.20 uh eve so my my shielded amount plus the network fees um oh i've got a message from zen is the video not coming through clearly um i can see it oh yeah um i'll keep going uh so here you can see basically that this has come from me any deposits into the shield of paula public but what we're trying to do here is show that the interactions inside the pool uh are obviously private um

so uh still waiting for that to settle uh our roll-up provider on girl is a little bit slow uh and takes around two minutes to construct one of these proofs uh but in a second we should get a roll-up proof coming out on the gurley roll-up contract and uh that will effectively give me as a user my shielded balance that i'm then free to spend uh in one of these these shielded d5 transactions whilst we're waiting um i can pull up

what the contract actually looks like so uh the interface for the default bridge contract uh has kind of three main functions um the main one that most bridges will use is convert this is called by the aztec rollup contract um whenever uh kind of a roll-up provider sends a roll-up that contains an aggregated default interaction so when that roll-up's received and validated uh the aztec rollup contract will call out to your default bridge contract uh and it will kind of pass in the

deconstructed bridge id and the bridge id as we talked about before has two input assets and uh two app assets and some input value uh oh so we just got a transaction so we can head back and see the shield just a second this suspense there we go no not yet girl he's a little bit slow i'll comment in a second um

uh i think uh maybe etherscan has to wait for a few transactions a few blocks to go through before it um adds it but the sdk does it instantly uh so you can see that the sdk uh already got its encrypted note here um you can see when the block uh was published it uh managed to decrypt this uh note which had index 593 and the uh note 3 decrypted it and you can see that it was worth 0.28 in way uh once that's kind of been settled we can now spend this uh in a future uh d5 deposit or join split um so we're doing that here buying some

diet privately um we create another effectively join split proof again here where instead of this being uh fund sent another user we're sending funds to this bridge id which will be aggregated by the roll-up provider and uh the roll-up is gonna really flag to set up here we go so you can see the the roll up here looks um fairly bland it's paying some fees out to our fee contracts but uh at this point uh you can't see anything nothing interesting has happened at this point except uh the roll-up has been validated giving me my shielded eath the exciting thing happens in the next roll-up block which i'll show you shortly

so we go back to the interface um in the case that we're just talking about we're not using it for asset b we're only using impossible a and output asset a uh is also being used alpha s b is not being used so in our example impassa a um is this uh aztec asset type that represents eth um and output acid a is in the s20 acid which uh is dye and the input value here is the total aggregate input value on behalf of all of the users who took part in this bridge interaction um in our case it's just one user but uh this if there were 100 users it will be

summed up and be the total uh input value and you can also pass in kind of uh extra data into the bridge id which is useful for doing stuff like purchasing nfts uh maybe setting the slippage um on uni swap if you want to kind of have a slightly wider slippage or do some more obscure things um the org state is quite useful for passing that data so it looks like we just got uh another uh roll-up just came through um so we destroyed our input notes and we created these claim notes as zach was talking about earlier so you can see we nullified uh down here the eth input note

um and i think we also had to now fire second note for our fee um second one eat this down lows we'll see the uh actual swap taking place that's where eater scans slower when you're doing a demo

we'll come back to it um it's it's it's turning away in the background so um i'll check it again in a few minutes um so going back to the interface um all of this information is kind of provided by the roll-up contract and the expectation of the convert function is in most normal cases it's going to interact with the d5 protocol so in our case uni swap and it's going to return the tokens back to the roll-up contract to be disseminated via the claim node process to all the users who took part so if your default protocol is synchronous meaning the the protocol uh

the transaction executes in one ethereum block um you will return an output value a which is the amount of outpass a here and if output value b is not used it's just zero there is a more advanced flow which we're going to get on to in the element uh demo where your d5 interaction can be asynchronous so in this case funds have left the aztec network they're sitting in your default bridge contract and at a later date um something in the wider d5 ecosystem could prod the d5 bridge contract and cause it to settle its previous diva interaction back to users on aztec so something like a fixed term loan this is really useful for it's

also useful for limit orders um those sorts of things so in that case you would return nothing for output value a and b and this boolean would be would be true uh to denote the role of contracts that is asynchronous and uh the other two functions on the bridge are just for asynchronous interactions um they basically just allow a previous call to be to convert which returned uh is async true to be finalized at a later date um so we'll go into that in more detail in a minute uh cool so the sdk is a little bit ahead of uh ether scan but we can see that uh there's another roll-up block now and if

we go into this one that's the previous claim proof here we are uh so this is the roller block um which uh effectively took the aggregated um all the transactions in the roll up in our case it was just one those transactions were a particular d5 bridge interaction uh calls out to our bridge contract in order to swap ether die on uni swap um and uh does the transaction uh i think in my testing uh maybe someone else is also playing with this because this actually put out 0.004 so there's actually been uh

someone else playing with us maybe one of our engineers or um someone else is playing with the test net right now uh but you can see that there was a transaction from our address which is uh 0x87b this is the address of the aztec roll-up um we put this into wrap teeth because that's what the the pool is using and then we swap that um kind of uh for this test token which is basically uh die um and send that back to the the roll up um so you can see here we sent back a exchange rate it's not very good so we sent back a pretty pretty poor uh amount of um

uh die in this actual interaction uh but that was some split pro rata um to the users who participated in the roll-up um so you can see that down here which is uh the end-to-end flow of like doing um a private uni sword transaction um we're in a code freeze uh with aztec at the moment so we're polishing up some of these interfaces making sure this is all kind of working and scalable but uh you can see this is kind of ready to go um putting the finishing touches to it at the moment and really the the interface is now final so um the next stage for us is actually getting on to writing bridge contracts

um which i will start sharing now there are any questions at that point just before i dive into some of the synthetic code there is a question actually from frank how do you configure vs code for development uh oh you also you um uh our lead engineer charlie has uh some very good conflicts uh that he's got me me using um but uh one thing to note for kind of zk development is um we do all of our development on a mainframe computer so we have a large 64 core instance um in

aws and everyone kind of s sshs into that constructing roll-up proofs and testing roll-up proofs uh on on a mac is even with the new m1 max is is not enjoyable um so we kind of uh we have this very large machine and all of our development is done on that remote machine so there's a few interesting plugins for vs code that let you kind of run on a remote machine all of this is actually running on the remote machine right now um so the whole team does that which helps cut down developer wait times when waiting for proofs to be constructed or kind of

compute improving or verification keys from our premium libraries so cool uh so in the aztec connect starter kit uh there's a uni swap bridge and there's some some tests uh that kind of help simulate uh what the roll-up is doing and i'll just just show you what the tests do um quickly so the tests are going to basically run a local blockchain and they're going to run one test

which cause it's going to in our case deploy useful pool um and it's going to simulate your bridge contract being called from a hypothetical roll-up contract so for the starter kit you don't have to worry about kind of deploying aztec creating proofs or anything you just need to kind of write solidity code make sure it uh handles the edge cases of the particular default protocol that you're uh running with um and then you should be good to go so i'll just dive into these tests a bit more in a second but uh this is our uni unisot bridge that um originally was written by one of our engineers layla um

i think we've changed a little bit for this uh demo to update it to the new interface but it's it's fairly simple um it's around 100-ish lines of solidity uh it doesn't support all the use cases uh in uni swap but you can kind of get a feel for how easy these bridges are to write um i'll run through this before we start going into the element idea if we have time so in the uni stop example as i said before you can see that the input asset and output asset are the only assets that are used and we don't use any of the kind of auxiliary data we just have the

input value and uh secondly on return um we're setting is async to be false because this uh interaction is settling uh instantly in this uh particular in the same ethereum block as the roll-up verification um and we're only returning output value a so uh this particular implementation only allows swapping from each to the rc20 uh or erc20 back to e um there's obviously way more pulls on a uni swap than that so one of these whatever to do here is to kind of extend this to be a bit more

generic um we actually were at the unicode hackathon a few weeks ago we had a few people hacking together um useful v3 bridges which was quite exciting like we had people doing kind of um uh l peoples um lp positions range orders and uh people putting in custom slippage and custom fees which was really cool to see using the aux data so all the contents actually doing is it's taking uh the input value and depending on which way round it's being called so in this case uh if erc20 what we just did we're going to call out to the unisort router swap exactly for tokens for the input value

and we're going to set the amount um that we've received back as output value a and return that to the role of contract um inside uh kind of the d5 proxy which is actually kind of it's actually run inside the roll roll-up processor contract um we check that that we've received the amount we specified so i'll run over that in a second but uh we check that the roll-up contract's balance has actually gone up by output value a and you can see that in the user transaction to save gas uh we instead of sending it to the bridge contract first we directly send it to

the roller processor address online 67 which is just hard coded so that's pretty much the the uniform bridge um in this repo we have as i was saying before a bit more complicated contract which is our d5 bridge proxy which uh is the contract that sits before your d5 contract and it's actually going to call out to your bridge contract and it does those checks so you can see that on the way in and convert it's going to transfer any tokens that are required to your bridge address and on the way back um it's going to check

down here that it received the correct amount of those assets um uh our actual implementation of this is uh heavily optimized in um inline assembly by zach but this is just a uh kind of human readable version um so we can have developers just understand what's going on and make it a bit easier to use and then in the tests um we have some tests that can run that basically just simulate the roll-up calling the convert function as if it was done inside a normal roll-up block um and

the tests are quite simple um we're expecting um the proxy balance uh to uh be what uh was returned for the bridge contract um and a few other things to be false uh just as we expect because this is only one uh output asset and it's not an asynchronous interaction so yeah that's uh that's what we get here um in terms of uh element um i think uh the best place to start uh is this

uh spec document that we wrote as a team so one second for those who are not familiar um uh your element is a fixed rate uh lending pro protocol um just make sure this fits okay and and usually you interrupt this through their ui um i think in our example the simplest thing to kind of uh try and code up if

we've got time uh is uh dealing with the die um kind of pull um and what this offers is uh if you have shielded die tokens on aztec the goal of this kind of bridge contract would be to enable you to deposit it in this uh element pool uh and earn three percent ap apr um you can see this is fixed term so it's uh they have a few tranches um i think this one uh the next one's ending at the end of january um and uh it has a fixed apr of uh about three percent

um the way element works is uh they actually invest the underlying assets into kind of variable rate d5 protocols such as yearn um and they split out uh the principal tokens which is your die that you're putting in uh into one asset and they separate it from the yield um tokens which is kind of the variable yield that's coming off that particular investment and the way they make it fixed rate is they uh have a market maker mm a bit like uni swap that lets you trade your die for principal tokens and they trade at a discount so if i've got 100 die um

i can buy principal tokens at an exchange rate of 0.95 so i get a 100 in this case i get 103 0.1 um principal tokens and on the 28th of january 2022 um those principal tokens will be worth one to one for die and there's a redeem function to convert the principal tokens back into die so you end up with as a user who put in 100 uh die here you'd end up with 103.1 die by kind of going through this flow uh so it's relatively simple but um users have been priced out given the gas

cost of creating principal tokens or buying principle tokens and then redeeming them uh it's quite an expensive end-to-end flow um how are we doing for kind of uh confusion levels uh the questions that people uh want to ask at this point are people following along um or should i back up and explain a few things a bit more clearly i think silence could be a good thing that might be good yeah i don't see any action but i guess

if people do have any further questions they can put them in there in the chat yeah feel free to share anything that your folks are curious about um or if they're not following or if if anything is unclear or you know casual heckles anything uh uh we'll be around to answer cool um let's uh start coding then um i have not done this before so um we have a spec on what we think we need to do for this particular bridge contract but um let's uh let's start um coding and see where we get to um i think if we can define

in comments um what the convert function is meant to do in terms of element maybe someone in the community can take it on apply for a grant and we can help you kind of finish finish the work cool so i'm just going to base this off of the unison approach and copy and paste everything just clean up all of the

uni swap stuff so when we wrote the spec and i can share this quickly we looked at a few flows uh for how this is possible um and because element principle tokens are ese 20 tokens um there's two options so one option is kind of the most simple option which is the one we're going to implement which is the bridge is asynchronous um you put in die and then when the element tranch expires um so in the die case the next trash expires on the 28th of january

uh finalizes triggered and the user just gets back die plus interest on on aztec there's a more complicated flow where you can kind of purchase principal tokens receive principal tokens uh back on our stack you can then send those around they're fundable um and then at a later date um you would do a second bridge interaction to redeem for tokens for die there's trade-offs and benefits to both yeah i'm sure that can be sorry um yeah straight off and benefits to both

um at a high level um the first flow is way simpler to implement um but it does mean that kind of you're locked in for the term um so if you get buyer's remorse at any point uh for some of these longer terms uh your assets are kind of uh stuck for those 30 60 90 days depending on how long the term is um and second flow obviously if you decide that um there's more favorable things to do elsewhere in d5 you can always kind of exit early you may get not the advertised interest rate but you'll be able to get your diet back and do something else with it pay a friend or do something else on aztec or send it back to l1

uh so in our case um we can implement this uh direct uh kind of async bridge flow um it is used with all element assets uh we're only gonna code up die just for simple cases um and uh we can talk a little bit about the user flow here uh but the uh there's some ideas here around um if there's multiple tranches or pools for a given asset so in the die case i think there's like a pool that expires in january and there's another pool that expires in april you may be able to use the orcs data to pick the correct pool expiry date um uh and yeah this really just kind of goes through uh all the steps we think

uh need to happen one caveat uh let's start cody and i'll talk about the caveat uh actually in a minute cool so i guess the first thing that's going to change from the new swap interaction is uh async is going to be true so the first thing we want to probably set uh is is async true which means that we don't need to define this

and those are both effectively zero what this means is uh when your bridge contract is going to be called um convert is going to be called you're going to receive input assets on behalf of all of the users who decided to do this bridge interaction on aztec but nothing is getting sent back because uh we're waiting for the term to expire um and uh yeah effectively at a later date someone needs to call finalize uh to let the transaction settle back on uh on

aztec so the convert function in this case is probably actually going to be quite simple um i'm gonna write some some comments on what i think we need to do if anyone if anyone's got any better suggestions um please message in the chat because um i've only just started looking at the element contracts but uh at a high level i think um element runs on balancer and balances like uh the exchange works a bit like uni swap but it's basically an amm and the way that users get the principal tokens in this case is they're going to swap die for principal tokens on uh balances uh amn

so let me just write a comment here so we want to stop input value in input asset a for the equivalent principal tokens on a balancer let's not have a very long line so that's kind of uh the sole goal of um

this conversion function um before we kind of figure out how to do that uh there's a few other things we we need to do um so to do the swap balancer um so assuming we can figure out how to do that uh i think there's a few things to note um given this is an async interaction that we need to take care of um to enable someone else to call uh finalize um once this is settled uh i just got a question uh yeah the first half of the session where

zach went through kind of the some of the circuits of power this uh is over we're just doing a live coding session now on how to write uh bridge contracts in insulinity if you're joining late uh it's all recorded um we shared on cool uh sorry i didn't know where i was uh yeah so once we've got the tokens um let's just do it as an example um element principle tokens are called i

think they're called p p y is their um prefix uh so this is the state uh gun of the world after we've done done the swap on on balancer um and we need to record this somehow because uh after we've done the swap uh the this particular uh interaction uh has a balance uh of in this case a hundred die uh which we sort of 105 principal tokens and we need to kind of attribute that to this particular uh default interaction so that when finalize uh is called at a later date

um we make sure these 105 tokens uh are redeemed back for 105 die and get split pro rata between any user on aztec who decided to take part in this interaction let's just make the numbers slightly more interesting so to do that um there is a parameter in in the interface um which is interaction once which is globally unique

so every time converts called for any bridge uh the interaction nodes globally will have increased by one and we can use that event to be like a an id um and we can use that to kind of record uh the transaction that's happened and also uh make a note of kind of the future transaction that needs to happen to order in order to settle uh the asynchronous internet interaction back on aztec later so the easiest way to do this is uh

probably have a bad thing uh i can't remember how to do mapping since i think it's like this [Music] i don't think we want a mapping actually because um well let's do the simple case first so in the complex case there can be multiple input assets so uh mappings may

be not sufficient uh for for us because if someone puts in die and someone else puts it btc we're gonna get uh maybe get in a world of pain uh so let's just let's just stop that for now for the simple case so the aztec assets have the following structure um and we can just uh in this simple case just use the erc20 address uh which will be set and we can just block out all our assets uh

cool so um in in the pseudo code example now we can uh set for our given interaction once um what we've returned from from balancer so i'm assuming the balance is going to return some some sort of amount swapped and we'll have to check the interface for this in a minute but um i actually have the contracts up i think

let me just find this uh this is the element um github uh we can just look at the interface here and figure out what's going on uh yeah so

the pool is basically uh on these convergent pools i believe which has somewhere on it okay uh so this is gonna be a little bit more complicated uh but this is this is what we're gonna be doing um but we we're getting back uh the un256 which is the content of our swap so we will just do to do here uh

and we can now take the uh principal tokens returned and uh we need to associate them with the interaction notes that we uh just uh defined up here set by the roll-up contract so um let's assume the mapping is called pending interactions the interaction balances

um so that's step one um second part uh let's just write down what we're doing here so uh that's the one uh record uh the [Music] amount of element principle tokens we also need to record the maturity of this particular loan which i'm not quite sure how to do yet

but um the goal of these two steps is is so we can set up um the contract so that a later date uh we can implement the can finalize function which just returns uh if this particular interaction is ready to go uh and also to finalize function um which is actually going to settle on aztec so you've got a comment oh um so i mentioned it dropped off sorry i just accidentally clicked the share screen button um yeah so so this is this is um for for async interaction like this so um the

bridge itself would have to kind of store it um like i believe uh how long it was it it's going to wait until uh until all the amateurs so um for example one could define like a constant um which will be added on as uh onto the current plot timestamp um uh um and that would then just that would describe the the threshold at which you could then like after which you could resolve the um uh resolve the whole interaction um uh withdraw alone and return the proceeds back to aztec the asset network cool so i need to figure out uh just how to

store these quickly in um these mappings but uh pending interaction balances and then we've got another mapping which is going to be what we call it uh some of the salinity wizards i'm having a brain meltdown how do you do uh how did your mapping is in the sea again hey why do you pick up a live what if you do if you share a live show and basically like scribble graffiti all over your um all of your code uh yep uh one of the perks of the s code for the person who was uh asking earlier um

i'll send it on slack uh cool so whilst zach's uh fixing up these mappings um i'm going to switch back to the element con element docs and try and work out where we can get the expiration from so we have mapping interaction answers to

um balances and explorations um so i'm gonna be like stupid actually let's just just find a little structure and be a little bit more efficient i guess um i think cool oh thanks so so if you wanted like th this is just

just some some loose code i mean you wanted to optimize this you might want to you might be able to like mash both of these state variables into a single sword slots um uh if you were willing to like um uh like um do some kind of um truncation of uh like represent store tokens as like a un-128 um because the goal the goal here would be to reduce gas cars as much as possible so um if you could get away with say like one storage slot per aggregated cool then that's that's guess that you're going to save your users uh so i'm just going to do here which is

we've got to query the element tranche which we just found out here it has this unlock timestamp um which is i believe uh the timestamp of which uh post up point um principal token which we get back uh has uh he i'll just pull up the the interface for it but um it has a method uh on the principal token uh i think it's here uh withdrawal principle uh this becomes uh unlocked at that point um so uh

we don't know how to do that yet but let's just say uh query the tranche to get the expiry um and if we have all of this um stored we can kind of move on to the next step um which is implementing can finalize and uh and finalize um sorry i'm just trolling um where were we i'm just doing the cam finalize functions this one's pretty easily easy we get a interaction once um back and we're going to require

what did you call this thing expiration so while you're doing this i could chat

a little bit about the the actual contract architecture um so the way this works effectively like kind of by using callbacks for asynchronous transactions where if you want to finalize a async interaction you go through the aztec reload smart contract that way we can ensure that all these bridges conform to a unified interface which makes interacting with them a lot easier um particularly if um almost for example i create incentive mechanisms so the goal for this is for the roll-up prior to the entity that's actually finalizing these asynchronous schools so that british developers don't have to worry about it um and so

um uh that's much easier everything just gets called through a standard interface that's a good point yeah i mean uh someone's gonna have to pay uh so the way that finalize is actually called um this is in our docs but um there's a public function on our roll-up contract um called process async defy interaction and you give it a interaction notes and under the hood um this will kind of check that the cam finalize is ready um and then it will call finalize um and as zach was saying we need to set up some incentives uh to do this um so likely what will happen in the finalize

function um if you want to set up some good good economics is you'll shave off a little bit of a fee um so whoever kind of ends up calling finalize um maybe gets a percentage cut uh of the of the rewards or there's other ways to do it and that's that's one way to kind of incentivize uh this is being called um so we we may have an additional function on our default bridge which is like uh expire tranches or something um and this this would uh just it could lead through i could do

this um and under the hood what's going to happen is uh this function would kind of pay whoever calls it uh it's going to call out to the aztec contract for any tranches that are ready um it's going to trigger can finalize and finalize uh to be called um and finalize you can think of as just a delayed conversion um convert call so if we go back to our kind of original uni swap thinking uh when we were doing the interaction and sending tokens back um this was an async call so we now have to kind of actually return assets in the finalize function um

which in elements case is a little bit more complex because um we first need to get those assets uh at this point um so just as a reminder i'll write some notes of the what we have at this point uh let me just define some of these so so we have principal tokens for this interaction once so we want to in order to kind of give the user what they originally signed up for

60 or 90 days ago we want to make sure that they have uh their die back on aztec so [Music] we want to redeem the principal tokens for the underlying and just as a note because the now the tranche has expired the tranche has expired the critical takers are now one-to-one

with the collateral so eg 1050 uh py die equals it's element principle let's change these so we've got the the end state at this point um we just need to uh eventually uh withdraw it um and i think the way we do that is we want to

call withdraw we'll draw a principle on the actual token um so let's just say assuming we have a an interface for this token we can call withdrawal principle and we expect our balance to go up by 1050.

uh if we just quickly look into the contracts yeah we can actually do a shortcut here to save a bit more gas and um we can send this directly to uh the roller contract so let's just do pending interactions interaction months balance so we call it zac balance so we're going to ask it to now withdraw the balance of the previous interaction and we're going to send it to the rollup

processor um and this returns an amount so we can grab that out here and output there's a few ways you can you can slice this but we're using a pattern where we're avoiding um requiring this kind of um approved transfer from mechanic because that's a little bit more expensive than just directly sending the tokens to the roll-up uh and by creating this kind of callback structure with a calls finalizing the contract we can ensure that

um if you just directly send the tokens to the roll up if anything can be correctly counted for uh great um i was actually a lot simpler than expected uh we'd obviously want to do a bit more checks here to make sure all of this succeeded um but we need to kind of instantiate all of these structs but i think the high level pseudo code version is done some of the incentives are not um in place yet i might need this that's a very good point it's a yeah it's a good point actually

so the security model of these contracts is um everything needs to be scoped to the roll-up contract like you don't want users to be able to interact with uh these bridge contracts because uh otherwise uh unless specifically uh through a defined function like expired tranches um because if someone else can come along and finalize uh a previous d5 interaction um they can easily just steal the tokens which is hacks are bad uh even though zika hacks are good um yeah we don't we we don't put the hack in zika hack right now um how much more time do we have i'm conscious that we've uh we could keep getting this polished but we've covered

quite a lot right now and maybe it's time to give people a bit of a break you have another 20 minutes uh and then we come on with the announcement of the new puzzle so it's up to you awesome well i mean i think we can we can keep going with folks once uh maybe we can get a show of hands in the chat to see if if anybody's um brain isn't isn't um is it isn't a pile of blueberry jam at the moment um because maybe we should wrap up if if nobody is is particularly keen in chat to um

to be subjected to more solidity programming well let's see what people are saying in the meantime i'm gonna uh just show this form again um say someone wants to submit a grant for any of these uh kind of protocols or any other protocols they're not here um we're happy to kind of uh talk you through uh some of the british contracts we think will be useful work together on a grant application and um uh yeah give you the help to kind of code up one of these bridge contracts they're quite fun to make it requires a slightly different uh way of thinking in terms of facility coding so um yeah if you want to kind of hack around with some pretty edge technology um this is uh the

best place to go yeah and you know it's it it the the the interface needs a little bit obviously we use we're going to be polishing up our documentation that are onboarding but at the the the goal of this is that you know you can write um a effectively like a privacy shield both the privacy shield and um a way of reducing the cost of interacting with an entire d5 protocol in about a day with a few dozen lines of solidity um uh so yeah we if you if that if that if that tickles anyone's senses um shoot us a great shootout application we'd be very happy to sponsor you to

write a bridge contract for a d5 protocol of your choice that you're particularly fond of that you want others to uh ape into privately and actually you guys are also supporting the bitcoin brand effort that we're doing eh yes we are yeah yeah so also maybe something to re-mention that aztec is a matching partner with ck validator and a group of awesome matching partners who are helping to fund some open source ck stuff so if anyone has projects as i mentioned earlier it would be awesome if you do submit so keep your eye out for that um

joe and zach if you do have anything else to share you do have some time to do it and if you don't what i would actually do is we have this networking feature in hop in that we can do where people can actually meet each other and then we can come back in 20 minutes or if there's like if there is anything else that you want to share i don't know um just trying to think i mean we can uh people are interested we can go through kind of uh our current current roll-up throughput and privacy sets which is ck uh related uh maybe that'll be uh interesting uh but i'm also keen just to chat to people maybe some informal chatting will be fun well i could i wouldn't actually i think that

would be cool this is also going to be a video so well who might want to see this afterwards do you want to maybe spend i don't know how if you have 10 minutes could you do about 10 minutes on that and then we do a bit of networking yeah i think that sounds good although oh i just lost joe [Laughter] um so i could talk a little bit about uh zk money um uh and how like um the the current current roll-up architecture how last connect fits into this um and the the the user experience and user flows so the current um in march we launched our original well the what we're calling stick to it's uh

the first layer to that we produced first private roll-up well everyone's leaving maybe i'll get dropped off soon as well um no no i just i just wanted to let you speak go ahead uh i can jump back okay uh and what was that yes so we launched that in march and it enables um shielding and unshielding of of tokens of ether of of native ethereum or on layer one um giving a previous shift to ethereum um where transactions are substantially cheaper than if one were to do it without the benefit of layer 2 without the aggregation techniques of zika stocks so for example uh depositing

eth uh it costs about forty thousand gas and a withdrawals about thirty thousand uh which um we were very happy with at launch uh the current prices of eth uh at the moment uh gas prices mean that that's uh it's it's still a working progress but unfortunately um bridging to and from a layer to uh in for me is always going to be relatively expensive because you have this layer one transaction you can't get rid of um but confident that we can get this down to yeah ensure that deposits are about 30k withdrawals or about um 20k um a gas in aztec connect uh where um for sufficiently large batches you can

do d5 interactions in ten thousand gas um so you're talking so even even if you don't have any thumbs inside the layer to do it and you want to interact with the default protocol just doing it through aztec doing it deposit aztec the defined reaction antenna withdrawal back to layer one that whole round trip will be cheaper than the majority of different protocols natively on that one um oh great you're back here i'm back i i did the thing where you you put your uh the address you want to go to in the uh in the in the address you're sharing from so accidentally close the window that i'm back now um cool so this is our block explorer um someone else was kind of uh asking earlier around

uh [Music] kind of kind of like what what is the state of play today um we're doing around kind of 112 transactions uh every kind of two to six hours um uh we just do this when the roll-up's full so you can see right now we've got 67 transactions in the queue and when it gets to 112 it will spit out the roll-up block um we're actually computing uh kind of the inner roll-ups and and 28 uh blocks as and when they're full uh so the actual final step is is really quick uh we just need to kind of compute the root roll up um we can see this on each scan uh there's quite a lot of people kind of withdrawing and using this uh a bit like a mixer back back to l1 um

and uh in the future um you'll see kind of all of the default interactions down here on either scan uh which would be pretty cool to kind of uh see what we saw earlier on the girlie test network um but with a lot more users um so in terms of the privacy sets um and just pull up this june dashboard that's been in the works um for eth um things have been growing quite quickly um the 18th privacy set is getting pretty pretty great um there's quite a few users who are still depositing uh and then withdrawing to the same address um which obviously breaks privacy for them and we have to

just discount them from the privacy set uh but we can see there's a lot more smaller users um and then a decent amount of uh the users kind of uh going through um and we have the same for obviously the die and run bdc privacy sets but they're slightly smaller um the great thing about aztec connect privacy sets is that um you kind of have new ways to get youth into the system um so each could have come into the system by uh someone uh kind of depositing youth directly or you could have um swap some dive to eat using uh the useful bridge um and uh that kind of has the effect of expanding the privacy sets and uh john who's uh uh on our content and growth i

just wrote a really cool piece trying to explain what we're calling infinite privacy uh which tries to explain kind of how the privacy set grows where not only do you have kind of new forms of uh assets coming into uh the roll-ups through default interactions but you also have yield generating assets um like things get a bit hard to imagine when you can suddenly have uh assets growing inside aztec because they're now yield generating um and you have to start doing pretty complex number crunching to figure out where's the potential set of places someone could have got a withdrawal uh amount from um because it's now not just um uh deposit

amounts it could come from uh i had uh in the element case like if i'm withdrawing uh 10 die um i could have deposited tendai but i also could have put a thousand dion element um and earned uh a fixed yield for a period of time and withdrawn uh some of that die um so the world of kind of uh the process that explodes when you start adding in these defined interactions which is something we're really excited about um anything else that's useful to go through zach uh on aztec connect um no i mean i think i think that's

pretty much ever covered in let's fix up questions maybe we can jump onto the um [Music] uh i forgot the name of it um the thing that anna suggested um if anyone wants to networking that's the one okay i have i have one question before we do that though and zach we mentioned we talked a little bit about this so i i've been talking a little bit in groups maybe on a few shows about doing zk nfts and my question to and like when i say that like yes there's a few small projects trying to do it but so far like when you say zk nft it might be like an nft on a zk roll up but not necessarily a private nft in its

generation and i wonder if this is very like future but is there a way that with aztec connect you could actually do something like that at some point tell me tell me what that even looks like so we can we can use essa connect to create um to enable the holding of nfts privately the downside is it won't be particularly cheap because you don't get any batching effects because nfc is a single owner um but what we we are going to be uh something we have we have uh loosely in the pipeline is effectively um the ability to have um what we're calling a like a private art vault effectively a level smart contract

that is a custodian nfts where the owners are hidden and it makes purchases and bits and trades on your behalf and you you submitted instructions from the aztec network and because your identity is hidden um it means that nobody nobody knows who owns or controls the nfts until the user chooses to reveal that um so the way it would work is for example um you would use the the dsa connect to send an instruction to this um contract saying like i want to buy you know i want to buy a cryptic punk or i want to but here's here's a fixed amount of each like you know um 10th or what 40th or whatever they're going for these days um and um you provide you provide like a um

um a um like a um a token like an an identity which which is linked to um an aztec identity but that that linking happens within the out within the aztec network inside azikinox so that's what that effect it does is it binds ownership of the nft to you but nobody can see that on layer one and then what would happen is you could then um through these bridge interactions emit um a transfer transaction as well which would then so if if this contract is bidded and brought in after on your behalf you could then choose to transfer it to a public theory address of your

choosing or you could just leave it inside the vault if you didn't want to reveal that you earned it so it's it's basically it will be a way of acquiring and trading entities privately but it wouldn't be a way of shielding ownership of existing nfts without well there may be ways of doing that but it's it's difficult because the anonymity sets are very low um given that the these these ethos aren't fungible kind of time frame like at what point would we actually be able to use this are you thinking you can find a bridge contract for this now uh there's a few technical hurdles that like mean that at the moment you you don't have a

guarantee that you are the sole owner of the nft okay i don't know if you i don't know if you're familiar with party bid um but it's kind of like it's a bit like party bid so you could you could write a contract today where like we'll put some ethan uh and like it just goes and it decides to purchase an nft and that nft will be owned by your bridge contract and uh using the output assets um you one of the outpatient types here is a virtual asset which is basically used to cover all assets that can't go inside uh aztec so aztec works with utxo or fungible assets um so we basically take your your nft and we split it into shares um uh and you could do that today or when

we launch um we probably need to make a few slight tweaks to make it a bit more usable so that you can also have the option of not not sharing the nft um if you're if you're kind of purchasing an expensive crypto punk and you end up with 99 of it it may be a bit annoying like um but yeah the tech is the tech is pretty much good to go on that it's just kind of getting the use cases down um and uh opening up to the community ready to start building some of these bridges cool all right well that was my question we have only about seven minutes until we are meant to reconvene

and announce puzzle 5. shall we do you want to wrap up and then we can just actually spend a few minutes meeting some other folks that'd be great yeah yeah thank you so much for doing this workshop for us the aztec connect workshop um so yeah this is the kind of wrap up of this part of the event we have i just like turned on the networking area you can just pop in there basically i believe it just like matches you with another participant for a few minutes i think there's like a timer and then it will kind of reshuffle that so if you want to meet some of the other folks here this is a cool way to do it and i recommend coming back in about six minutes so maybe do two of

these or just do a couple of i don't know try to come back on time because what we're gonna do in six minutes is basically launch the fifth puzzle on in the zk hack of six so this is we're getting kind of into the the last few here so anyway hope to see you back here thanks again zack and joe awesome thanks thank you cheers