Zk-zk-Rollup & zk.money with Zac and Joe from Aztec

Transcript

[Music] welcome to xero knowledge i'm your host anna rose in this podcast we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promise to change the way we interact and transact online this week i chat with zach and joe from aztec protocol the folks who recently released zk money we talk about this exciting new private zk roll up or zk zk roll up and explore how this is built and what role it aims to take in the ecosystem

but before we start in i want to share two quick notes first if you're looking to start working on zk tech and you are a student cryptographer software developer practitioner and blockchain or privacy tech researcher or engineer or even if you're not working in the ecosystem yet be sure to check out an upcoming event that i'm putting together called zk jobs fair this will be an online social event giving you the chance to connect with some of the coolest zk companies in the space you can follow the zero knowledge twitter account for more info and be sure to apply today to get access to this event it happens on april 22nd i've added the link in the show notes hope to see you there secondly i want to say a big thank you to this week's sponsor ave

ave is an open source decentralized non-custodial liquidity protocol on ethereum with ave users can participate as depositors meaning they provide liquidity to earn a passive income and they can also act as borrowers to borrow in an over-collateralized way or in an undercollateralized way think one block liquidity flash loans that we've discussed a few times on the show avi has also deployed a new market on polygon sidechain to let users pay much lower gas fees assets can be transferred from ethereum to the polygon bridge and put to use on avi's polygon markets you can learn more about it in a blog post that i've shared in the show notes and if you want to find out more about ave visit ave.com

so thank you again ave now here is my interview with the guys from aztec so today i'm chatting with zach williamson and joe andrews from aztec hi guys welcome to the show hi uh yeah it's great to be on thanks for having us yeah likewise very excited to be here this is actually my first uh podcast so ever i think so i've listened to it so exciting that's very cool so yeah zach you've already been on the show i think this might be your third time coming on yeah yeah yeah i think it is i was on a while ago back when we just launched our first iteration of i guess what was zk money using a very different kind of crypto

protocol um since then you also came on with ariel last year to talk about plonk and it was very crypto heavy one um i'm gonna add links to both of those in the show notes i guess if people want to hear a bit of the history of this project and joe as you mentioned this is the first time you're on the show let's start with you actually why don't you introduce yourself what are you doing at aztec what's your what's your gig sure so me and zach originally met nearly three years ago now back on the entrepreneur first accelerator program and i guess my role at aztec is uh trying to hide away all of the zero knowledge cryptography that zach's been coming up with over the years and make it either user friendly or

developer friendly so really focused on i guess the the go to market and putting this technology in the hands of everyday people um which is super exciting would you call yourself a product person uh yeah i would say so i'm kind of originally technical but not the same degree as zach or ariel like i kind of i put the cryptography of black boxes and they understand what each one does but i can can then wrangle that into a hopefully a nice to use product it's true that working in this space the term like a technical person kind of changes like the level of technical you need to be considered a technical person definitely increases yeah it's a bit weird because in a normal company jojo because he's an

extremely technical person um it's just a different kind of technical yeah some people think i'm a technical person but in my mind i like i'm i'm the podcaster like that's the level of technical that i get to be um but yeah zach i want to hear from you like given that it's been over a year that you've been on the show what's new what's what's happening for you on the aztec side yeah what's new a lot uh a lot of change so so last time was on the show um ariel and i were very excitedly i believe talking about this this cool new research project we published called plonk which is a an extremely fast universal zk snark peruvian system and since then we've been uh we've been building building plonk uh and actually implementing it turning the paper into something real

and this is culminated in the launch of what we're calling zk money it's the the world's first private roll-up um that we launched from ethereum in march this year um and so it's basically um it's scalable private transactions uh on top of the running stop lithium blockchain which uses our state-of-the-art uh pruning system to combine both strong user privacy using zero-knowledge proofs um so that when you're performing cryptocurrency transactions all the information is encrypted but you can still prove that you've followed the rules that you're not double spending et cetera by serving as xero knowledge proof proving this and we've also used our technology to do some scaling as well so um instead of sending these private transactions to a blockchain like ethereum to be validated one by one what we actually do is we aggregate a

large number of private transactions inside a zk roll up so we have a snark second which verifies the correctness of a large number of other snark circuits and what that allows us to do is basically just post one transaction to ethereum that represents hundreds of transactions wild i want to dig in on this but i do before we do that i want to i want to kind of follow the path from aztec 1 to aztec 2 because or is that what you're calling it is it like aztec version 2 that is currently live yeah i'd say so um we're kind of like there is an aztec three in the works as well but uh yeah so we could talk about that as well but uh yeah the current live version is aztec two but like aztec one going back to that early really first episode that we had

you on there was this different zero knowledge proof construction like have you thrown all that out and now it's plonk has that is that what replaced what was there or is there other changes yes so there are other changes but the yeah we've completely re-architected the protocol and thrown out the old proving system aztec one was kind of um i guess it was our first attempt at privacy on ethereum and that was um it feels it feels like a long long time ago but i guess it was only about two and a half three years but back then universal snacks weren't really a thing like if you wanted to take a general abstract program and turn it into zeros proof you needed to use uh snark construction as that required trusted setups for every single program that you were writing and for what we wanted to do which was

um we wanted some level of programmability so that users could kind of create their own private crypto assets and uh program how they get transferred around we thought that the this requirement to do all these setups was a little bit untenable so we were looking for workarounds and so asic one was a zero knowledge proof which tried to solve some of those issues but in a very different way to modern zika snacks it was what's called like a sigma protocol it was quite an old-fashioned bit of tech i guess uh looking back uh and it had a lot of compromises that we weren't happy with it's why we started researching universal snarks that's why i as ariel and i put together plonk so once we had plonk basically that that immediately obsoleted all of our old texts so we yeah we thrown it out cool i think it's worth adding and then

like uh even though we kind of stopped supporting it publicly it's it's had some resurgences aztec one in in the in the private blockchain space i mean we don't kind of uh really support it as a company but um it's been used by the bank of thailand for a pilot on kind of cbdc's uh which is really cool and they basically just took it as is as an unsupported piece of tech to get a formal privacy on a private version of ethereum which was pretty cool to see that even the the kind of old world tech as zack's probably thinking about it these days is is still useful in some applications i want to talk about plonk and kind of the impact that plunk had generally in the ecosystem because

when you presented it last year like i remember like arielle and yourself you you were you were excited about this finding and since then what i've seen is so many more teams get excited about it it's almost become like at least maybe not the de facto but a de facto for a lot of these teams especially the new zk teams what what have you seen around that like did you expect that or are you excited yeah we're really excited by it um but certainly when when our light put it together we realized it was kind of it solves a real need that we had and we knew that other other teams in the space had the same need which is like we want um a fastest ck snack that doesn't need a ton of trusted setups um but it still needs to be succinct so you need to be able to like

efficiently verify proofs in an ethereum smart contract um and we knew that like that really flock was the only anything that really fit the bill um i guess when we first published plonk we knew we knew we were onto something something good we've worked a lot on it since then so we've created another version which we call turboplonk um which has these things we call custom gates which is really taking off um and our latest version using this lookup research we've been working on is called ultra plunk um but yeah like it's it's amazing it's it's it's really quite um kind of a heartening to see it take off in this space and see the number of awesome products using it so i think like the electric coin companies building plant-based things media protocol they're using a very planck mata labs are using plonk and like many others which i'm i'm

forgetting i think one of the reasons why it's it's taken off so much is because i think this is really the first zk snark proving system that was kind of um engineered because all of the other systems kind of they've come out of very academic contexts which means that they they have some trade-offs which for for use in industry might make them a little bit less than ideal um just because the designers had other priorities in mind when they were putting them together but with planck because um we kind of combined ariel's deep theoretical crypt knowledge with some of my experiences as a software engineer and we really sought created to solve some problems but we actually want to write real world programs with this um and you know put them on blockchain how do we actually kind of uh mangle and mutate the mathematics to get

this working in in a way that you can engineer meaningful programs yeah i think and that i think that's one of the reasons why it's taking off because it we're not the only team with many many other teams have the same problems that we have with regarding needing extremely fast snark proof constructions i think it's also just great to see the amount of brain power that's kind of collectively being poured into it is is actually making it i think more more trusted as a as a technology base for for the whole community so if it was just an aztec project still today i think be hard to kind of convince people around its kind of security guarantees but now the underlying technology is pretty widely understood that burden i think is shared and there's a lot more kind of community resources

helping people understand the kind of really complex cryptography behind it another kind of big finding i feel this year was like the introduction of halo but also this sort of formalization of what halo does did that influence or is there any sort of impact on the way you're thinking about plonk given some of those new findings have you incorporated anything like that so we would like it to impact how we think about plonk because haley was like a really impressive and cool piece of tech so this idea of proof aggregation is certainly something which is um on our minds for future versions of plonk to see if we can if we can jerry rig some version of it um into into what we're using um and it's certainly like the plonk proving system is is really uh ideal to be adapted into it to be

used with this halo star recursion because you can create all these custom gates which kind of make these very niche prime field operations that halon requires efficient because we're working on a theorem we have some rather unusual constraints we're working under which is that um right now ethereum only really supports one elliptic curve that's powering friendly it's going to support two in in in the future bn254 and bls12 381 but neither of these are particularly halo friendly so the problem is if we if we implemented halo as is the the verification gas costs would be uh hundreds of millions of gas if not like maybe tens of millions but but either way a little bit too high for us but yeah if there are any protocol changes to make halo verifiers practical on ethereum we jump to a heartbeat for sure um and there's certainly a lot of meat

on the burn regarding proof aggregation that can be adapted by other other halo-like systems for sure this is actually interesting because i like from what i understand you're saying is like a plonk vanilla plonk not on ethereum could could already be used with some of these proof aggregation techniques alone but because of the particular curves that are available on ethereum it becomes i guess just more expensive you can do it but it would be just not worth it exactly yeah so we've had to use different a different kind of way of doing recursion technically formerly it is a proof congregation scheme but that's kind of more semantics well no it's not it's because basically um with this private role we're doing we do need this thing called like recursive proof composition you need you need to basically create a zknox circuit that can verify ziggs not

proofs which is typically very hard to do if you only have access to one of the curve it's really hard to do um but that's one of the things that we really engineered plonk to solve particularly this version we call turboplug so the way the way that we do it is kind of we take a brute-force approach where if you want to verify a snug proof you've got all this very complicated and expensive theoretical operations and prime field operations that aren't easy to do in a snark and we can't just brute force it prank is fast enough to get the job done regardless okay um we do do a little bit of proof aggregation um to reduce so basically um the planck proving system to verify a plan proof you need to do elliptic curve by linear pairing but if we're doing this recursively we

aggregate a bunch of plunk proofs together so we only ever end up doing one pairing um so it's got overlaps with halo but halo has a much more elegant solution for how to verify proofs that um unfortunately we can't really use because theory only supports got it recently i think it was in a talk that i did with um justin drake and isaac meckler from mina we talked about that sort of these three layers of the zk stack plonk kind of fitting in that middle layer the iop layer what we're talking about now is the aggregation layer which is layer three but on the layer one on the polynomial commitment side is is that where that ethereum like what ethereum supports is a problem or not a problem or is that

something else i'm kind of curious like how you're dealing with yeah that part it's slightly something else um so the curves that ethereum supports constrains what aggregation schemes we can use it also constrains what polynomial commitment schemes we can use but the two are kind of uncorrelated that makes sense yeah yeah so it's something even like above that that's basically determining which track you're going to be able to use it's actually for for the private roll-up context it's the client prover because these proofs are running on on user devices in our roll up compared to kind of a normal zk roll up when they're they're running on like a big aws machine it's the memory footprint of the approver being able to run on the client device that lets us select the correct

polynomial commitment scheme and the team has been doing a lot of work on that uh to kind of shift the polynomial commitment scheme to try and get under the wasm uh memory limits for actually running this on on mobile devices so we've got a lot of constraints from ethereum to to kind of old android phones or old iphones uh being able to run these things yeah yeah definitely so yeah there's been some iterations on the on the commitments team side too um plonk was published uh it was like kind of deliberately scheme agnostic um but the version of the protocol we described in full use this convincing by uh anarchy cutty but our latest versions that are in development we're migrating to the commitment scheme that was described in the schlunk paper uh by ariel gavison and justin drake and yeah there's also be some really cool

innovation in on the commitment scheme's side i know like mary males published uh recently a paper where a commitment scheme where the asymptotic the performance is is strictly better than the existing extremes but again the problem with all of the new stuff is that it requires new cryptographic primitives which you just can't access on ethereum right now so i feel like we jumped in really deep for our listeners pretty quickly maybe we take a little bit of a step back and start to describe on a higher level what zk money is and what like that product is and then maybe we can fit back in where like plonk and all of these things exist within it so why don't we go through

what does like zk money look like so ck money is just a front-end really it's it's our flagship product of what's possible um with the aztec kind of technology stack and i think we built it because scalable private transactions weren't possible on ethereum before um so we felt we needed to kind of show what was possible and all of the work that zach and the team's been doing on on getting plonk uh to be super efficient on the client side has kind of i think reset uh the user experience expectations of kind of clients running uh zk snarks on their devices so we built zmoney to kind of show that you can get almost like a web 2 kind of experience

like a venmo style experience for paying people but this is running on kind of a web 3 zk stark stack that's why we built it and the goal of it is to kind of showcase to users and developers what's possible uh on the network and we've had pretty incredible uptake and demand from users trying to kind of get privacy on ethereum so you're saying the zk money that's sort of the front end to this thing behind the scenes is what's running a zk roll up or is it something else yeah so it's a it's a with a zkz roll up so as zach was saying earlier we're kind of calling it a private roll up so we have very very optimized wasm code which runs

in our sdk in the browser and that's kind of the first i guess gateway into this kind of proving system the client there is creating proofs to obscure transaction data from a rollup provider and so we're processing transactions that contain said key snark proofs rather than just public ethereum data so that's step one and then that transaction once it's constructed on the client is then fed into our roll-up approver and they're all bundled together to validate hundreds of thousands of transactions in one go on mainnet i'm trying to kind of picture how a token moves through this thing so you send something to a contract on the l1 it locks kind of like this the

same way we understand a zk roll up but somewhere in that there's this privacy element and i want to i kind of want to understand even closer where that is and where that happens sure i'll take a stab and zach can uh take it fill in the technical details but um yeah so we surely we we have a different state model to ethereum um so like ethereum is obviously account based um and it's it's quite hard to do privacy uh or full privacy in an account based model so once the tokens are deposited to uh the layer one smart contract the ownership record is uh stored in effectively two merkle trees so all state is is recorded as these utxos

uh in in two merkle trees so it's a similar design to kind of the original zcash protocol but kind of retrofitted to an ethereum smart contract and then users could prove existence of uh value in those merkle trees and if the leaves are encrypted uh you can get end-to-end privacy and so there is when you move that you've you've put one token into the smart contract a new one has been has appeared in the roll-up but it's not private yet right it's like it's this sort of unshielded version first well ish um so but you you get a you get a little bit of privacy from the start because what happens is uh so as joe says you put your your you deposit into aztec

our aztec royal smart contract acts kind of as a custodian of your tokens um and in return it issues you a zero knowledge notes so it issues you this encrypted object which is a claim on the tokens you've deposited that you can freely exchange back into tokens whenever you want and then obviously you can trade around this claim to other users you can split it up you can do whatever you want with it so obviously if you make a deposit everyone knows how much you deposited because that transfer is public but the zero notes you get issued nobody knows when you've spent it and nobody knows the identity of the aztec address which owns the note um so you get some obfuscations straight off the bat by making a deposit is that but is that all roll-ups that's kind of something that all roll-ups already have or no

well no because uh with all roll-ups you would have like a special roll-up identity like like a roll-up address um that would be public so what happens now is when you in asic when you make a deposit you get your zero knowledge notes it has an owner but that owner address that asset address is encrypted no one knows what it is i see okay yeah and actually what i've seen on most of the roll-ups is like you'll have the equivalent address on both the roll-up and the main net and here you don't i guess you have the main net address that you're using for that wallet and on aztec you already have something else exactly yeah i think that's an important point it's it's kind of on zk money we've given users uh aliases um eventually they'll be replaced with ens domains but it's the first time when

you can actually say hey pay me at this address but you can't see anything about my payment history when you look up that address so yeah we're we're kind of using that that style of system to allow us to tell users where to send funds but because the actual zk node is end-to-end encrypted there's no kind of further information that could be gleaned uh from the alias other than the public key that's used to encrypt uh the value so it's it's a it's a pretty cool system i like to think of it like uh kind of the signal uh enter encrypted messaging but for payments so it's a similar design i'd say although we we haven't quite finished the journey though right this is just that first jump where where does it go after like why do you even have shielded as an

option i have checked out the website by the way so yeah this is just the kind of the what we consider the end of the beginning with regards to what we're building asic to become so you're right now the main value is privacy private transactions you can shields and then once you've shielded your tokens you can either within our roll-up you can privately send them to people and i had this rather an interesting experience that when we launched zk money somebody sent me point one east cath i had no idea who it was um so whoever that was thank you um and then when you when you make it with when you withdraw from the system when you convert your note back into tokens the withdrawal the address can be any address you want and nobody can link your deposit transaction with your withdrawal transaction because

when you create one of these notes nobody knows when you spent it other than you so that's that's kind of where we are the moment where we want to be where we're going in the future is uh programmable privacy because right now we think fundamentally like privacy is is necessary uh for blockchains to really fulfill for their their true potential because the more that people's economic lives and financial activity move on to a blockchain the more important privacy is going to become because the more information you're leaking you know when if we live in a world where your salary gets streamed on a blockchain or where a lot of your payments and your payment history is being made in a blockchain that's not going to be something you want to be broadcast to the world we want to fill that for that gap basically where in the future

we can use our technology to make fully programmable private smart contracts so not only can you create your own private cryptocurrencies you can also define the kind of the semantics around how they're transferred you can add terms and conditions and logical checks um like regular erc20 tokens uh you'll be able to create private non-fungible tokens where you know the owners are private or also importantly you can kind of obscure certain information about the nft and kind of conditionally prove things for example you could say you know i've in total i've spent less than a certain threshold amount into this month uh and so you and you can do other things which are kind of a little bit more boring but quite important things like uh know your client and anti-money laundering checks as well you can have things like identity tokens so you can you can have

kyc tokens to prove to prove that you're on some kind of approved list without um revealing who you are things that are going to be key for working in kind of regulated environments but as well you can use up um this programmability to create a very feature-rich ecosystem of d5 protocols that kind of work in concert with these private cryptocurrencies to enable effectively private defy where you can get you can engage in similar d5 protocols as today or even exactly the same d5 protocol system today working on layer one whilst um hiding who you are one question here though you sort of said that this that the zk money and that zkzk roll up is more utxo based how do you then reincorporate programmability into that because i always understood that as sort

of like that's one of the reasons why zcash isn't as programmable because it has that format it certainly does make life a little bit harder but i think most of the reason why you can't program private privacy systems right now it's mostly a technical obstacle because adding kind of user-defined programmable circuits hasn't really been possible until like you know the last few months really um just because you need universal snarks you need to be extremely fast because you're making these fields on the browser you need to be able to handle recursion efficiently there's a whole host of technical ingredients that were required that have only just really come together the state model does make things a little harder though because you can't um easily have a kind of account model you can certainly apply an account abstraction layer above a utxo model but that's something that your front end

has to handle it's an extra layer of complexity it's something that our sdk handles for example so that we try and abstract away this utxo stuff from the user all right but it does certainly require different way programming things um it's why we're putting together our own zika snack priming language because in a private world state variables um have to be owned by users everything is encrypted and only only specific people will be able to decrypt those objects and if you want something which is fully private you can't have global variables like you can as smart contracts like that are publicly visible to everybody if you're doing some kind of token or amm you can't have a like a total supply that's public because that leaks too much information so there are there are a host of difficult issues that need to be solved to make

program privacy practical but um we think we're one on the way to solving to solving them and there's also just to just to finish on this i think one interesting thing is actually um when creating d5 protocols that you want to interact that you where you want to protect user privacy you can still do so basically what's most important is that the actual representation of value um the cryptocurrencies that they are private and once that's happened uh you can build public default protocols that interact with this private these private assets and private pools and to do so in a way which is still privacy preserving because um as if you can see everything that's going through the diva protocol but you don't know who owns the trades or the positions then you still have extremely strong privacy guarantees you have some sort of privacy there for

sure we did an event about two months ago and zac you gave a talk there it was actually about privacy and defy maybe we can actually talk a little bit about that because in that talk you did present some ways that you could incorporate privacy into d5 protocols even like you know these amms something that i feel we've also seen a lot of counter research saying you cannot just blanket add privacy into an amm because it actually breaks some of the things that one needs in order for these things to function it needs some sort of transparency but you you had some ideas around how to fix that for this yeah privacy privacy is hard and there's a lot of things you just can't do privately that you can do in the public

world you certainly can't make a fully private a m right now without using extremely advanced multi-party computation techniques which are not really practical in the present day and most d5 protocols right now you can't just like magically make a private version like take for example um uh make it down right if i want to make a cdp to borrow some dye eventually you want to do this privately so you have an encrypted cdp so you basically you've effectively um staked some of your ethereum privately to create a private amount of dye now in order for the dye system to work you need to know the contract needs to know when your position becomes under collateralized and once you become under collateralized it needs to automatically liquidate your position neither of these things can happen if it's encrypted because the contract doesn't if the contract has the

information to understand what it's worth so does everybody else so you don't have privacy and if you do it privacy then the contract can't liquidate your position yeah so basically our position is for the time being it's not really practical to create private versions of default protocols what is much more practical and achievable is to uh interact privately with public d5 protocols to basically anonymize your holdings before you engage in in these d5 protocols so if you for example use aztec to so let's say you want to you know you want to put a thousand eth into compounds if you has it to anonymize your holdings so that you have these random addresses on ethereum the whole leaf nobody can link them to your original accounts and we think the most important thing for enabling privacy preserving techniques and on default is to ensure that transactions are uniform

if you imagine you have like um an ether die pair on compound and every single trade is say 100 eth or 10 ether or like you have these fixed denominations now that does limit the user experience somewhat but because if the identities of these holdings are all anonymous and the values are all uniform you have no real meaningful information about who's controlling these trades and obviously if you want to make larger trades that you just you submit lots of smaller traces of batch which is typically how a lot of traditional markets work um for example we're planning on using this technology to solve uh kind of the front-running and um issues and defy and the fact that if you're trading large nationals you move markets because right now if a so-called whale like wants to do a trade on defy then typically the way you do this in

the web two world is you you know you split your big trade up into lots of little trades and put them out into the market slowly over time so that you don't master each of the market but the problem is because of analytics on chain everyone if you start selling your position they know exactly so everyone says look the whale's training let's move the market let's take advantage yeah yeah and like the only other solution is just to like to push your entire trade through as quickly as you can to prevent front running but then you you're taking a horrible spread on on your trade because there's not a lot of liquidity to satisfy these trades and access solves this um instead what you do is you just you can now split up your large holding into a lot of smaller holdings that are anonymous that nobody knows they're all

linked and so you can then put those trades down to the market slowly over time without people realizing that that you're doing so it changes the dynamic dramatically um we actually i did an entire episode with guillermo and tyrone all about the private amm work they're doing i'm gonna link to that in the show notes if anyone wants to kind of like hear that in even more detail and i think guillermo actually spoke just after you zach and he was really kind of impressed that your thinking had already reached sort of those those levels that they had been working on in terms of ways to actually fix this but what you just said is this this is still a future thing like this isn't something that's implemented today right this is like where are we at with with the product right now no it's in progress i'd say i mean i

think we've laid the groundwork so our private roll up today has kind of more than one transaction type um so we have kind of the standard we join split transaction which allows you to send uh private funds but we've got kind of the early versions of programmability in there with another type of transaction which is an account transaction so users have like accounts and they can kind of modify the the state of their account change which keys can spend on their account change their their username and change their kind of encryption keys and if you kind of fast forward a few months there'll be a third type of transaction which is kind of uh we're calling it the d5 bridge uh users will be able to kind of send their their value notes

to almost like a kind of contract address on on the roll-up and that contract will have a predefined kind of layer one outcome so it could be as i said earlier deposit a thousand die into compound uh it could be a swap uh one ethon on uniswap and all of these kind of uniform events will be bundled up in one roll up and you get this kind of privacy effect by everyone looking the same but doing aggregate transactions um so we're well on the way to achieving that probably having an early summer launch uh is is the road map whoa okay that's a lot faster than i expected well i think i think we've got all the ingredients because um yeah like our old architecture is already

programmable it's just that right now we have to bring on the circuits um because it's a lot of extra architecture and it's going to be quite a complex operation to make these circuits user programmable so we're planning on watching that so we're in in the meantime we're going to write our own like d5 bridge circuit as just says that allow people to talk to layer one protocols but to do so as a batch so i said well making like one transaction to uniswap to represent a trade but that will be shared amongst like 100 or so users so the cost of that transition is amortized uh over lots of users on the defy side did they do those d5 protocols have to do anything in order to interact with this no so we're going directly to layer one um i think the the layer two landscape

is is a pretty exciting space to watch but right now there's kind of a last check i think it was close to 100 billion of capital on the layer one contracts and we don't see that going anywhere anytime soon so our approach is for for users who care about their privacy um those users are probably willing to pay slightly more um for for a transaction um still cheaper than ethereum mainnet obviously but they're willing to pay a bit more to uh have strong privacy guarantees and it's just like they're doing that transaction on mainnet but with with privacy um so it's kind of a hands-off approach for uh layer 1 d5 protocols is it kind of like because i mean i reading the documentation basically to

sort of finish that journey that we started earlier in this episode of the these tokens and you did hint at this it was the idea that like once you actually have moved funds off the l1 into aztec into a shielded environment you can then send that directly back to l1 without having to like unshield and then on like even though i guess somewhere behind the scenes it is unlocking and unshielding but like you as a user could just send it right in so you would basically as a user just send it right into one of these i guess yeah correct so it would look like very much like a kind of if i was sending it to to you or on your username that the end user kind of user experience would be very similar um you'd create a proof on your client the destination is just a

predefined default action rather than a user so we're pretty excited about that and i think that where things get more exciting is kind of as developers start to think of the new types of d5 that are possible once you have kind of a uniform set of users because uni swap has a it's it's a good model for public ethereum but kind of the slippage costs and and and all of these things that occur based on on large trades aren't necessarily applicable when you have a privacy um you can start to kind of design systems that maybe are a little bit more stable in terms of price and that's where i guess stage three comes in of noir and uh full programmability and we kind of take the training wheels off the off the network and

let other people define what you can do with these destination contracts on on the network and that's when things get really exciting i think it's worth talking about that for a little bit because there are a few kind of cryptographic hurdles to to overcome there but that's on the way to doing it i'd say let's introduce noir like we did an episode with or i did an episode recently with alex osdemere where we went through kind of a survey of languages and noir had just like i had just pinged you i or i'd pinged you zac or or arielle and just said like do you guys have a language and then you were both like oh yeah but it's not out yet i was like okay so i think we mentioned it but there was nothing we couldn't really like look into it

so why don't we talk about noir this language and what that means for for your next steps yeah absolutely so so we need programmability yeah so right now the way that we're building our stock circuits it's quite uh you can't need to be in a cryptographer to really to do it securely which is not sustainable in the long run and so we want to be able to give developers and users the ability to program uh snark circuits in high level language that's intuitive that you know you don't need to know all sorts of crypto knowledge and so there's a lot of other languages which are which are trying to solve this problem but we have some rather unique requirements which we think means that the only the only real solution is to is to develop our own language which is basically um because this language is designed explicitly so

all the zk proofs you're building with it are constructed client-side probably in a web browser using webassembly which is much slower than native code for cryptography so it needs to be incredibly fast it needs to be optimized to produce really really tight circuits and it also longer term we want to add semantics into the language which kind of abstracts away private state management so that you can have kind of a little bit like a city smart contract where you can have storage variables but they're but they're private um and owned by individual users so we have a lot of like custom semantics that we need we have a and we need the graphic backend to be extremely fast so the approach we're taking with no is so it's the products being led by uh kev wedderbaum is uh our uh kind of language guru it's an

open source project uh where we have this this language front end which kind of compiles down to an intermediate representation it's a bit like lvm for for zk proofs we're calling scr and the idea is to have multiple cryptographic back ends because this is an open source project so you can have a plonk back end you could have a l16 backend you could have a modern back end to make it look kind of a very flexible language that can be used by a lot of different teams right now the back the other back end is the only backend is punk because um it's a very new language so we just write our own back end into it um but the goal is to support other cryptographic criticals longer term why what made you make the decision to write your own language because i mean this actually was something we

talked about where there's a lot of teams that have built kind of their custom architecture and then creating a language to interact with that is there a reason you didn't decide to use some existing out of the box language yes um and that's because of the abstraction layers that they they used to compose circuits specifically especially the time all the existing languages they they used i guess you can call intermediate representation called r1cs for sensor rank one constraint system it's a way of defining your snark circuit as basically a series of linear additions and multiplications it's a very efficient representation of circuits for non-universal snark systems like cloud 16 like the the the slightly older snark proving systems that came out in 20 like between 2013 and 2016 but uh universal snarks like plonk don't

really um they're not really very friendly to a normal cs abstraction um it creates quite inefficient circuits and it doesn't leverage any of the core strengths that block has plonk strength is these things we call custom gates it's basically you can define your own custom little arithmetic operations like getting all the mini gadgets that that's um are extremely efficient to evaluate inside a plonk circuit so you can do things like do elliptic curve point addition in a gate you can do things like efficient poseidon hashes pedes and hashes you know you can do parts of a of a charity of six hash you can do things like eight bit logical exclusive or operations all of these like explicit instructions which are needed for real world circuits but they're all quite custom and so we wanted to cryptographic backend which understood what these customer gates were and be able to

convert this high-level language directly down into these customer gates to make extremely optimized and tight plonk circuits the existing solutions out there didn't really do this because they had this one r1cs abstraction layer which wasn't really suitable for us but i mean since then there have been there are languages now that that can do that as well right like i feel like there's some projects that are coming out where they also removed the r1cs aspect um i think so they're still quite very in development um and i think most of them the ones that i know of very much kind of don't really have privacy in mind that their main focus is on constructing circuits that can be web proofs constructed by third parties with a lot of computational resources so they don't have the kind of the focus on on

optimization that we really need for our circuits got it how do you feel like a kind of just the last question on this point but it's like something like arc works is there any way for you to incorporate what you're doing into that or like does it have to remain sort of these separate uh language ecosystems so they don't have to remain separate we're completely open to collaborating um with other teams to build a kind of a more general purpose language because there is a lot of fragmentation in the zk language space that's one way or another needs to be resolved um i guess the problem is because right now we're still in a really early stages where every team has very like the proving systems there's a huge trade-off space between like performance ease of use like synthesis there's all

these parameters that you can tweak with your zk proving system to optimize it for your individual use case and because the overall the operating systems are still relatively inefficient right like the difference between doing a computation and making zika proof of computation from like for most common algorithms like that the difference is a factor of about a million and because of this all these teams are very specific use cases of mine i have to really tweak the parameters of the zk premium systems to be optimized for their specific use case and therefore their languages as well which means that all these like you have all these slightly different languages that are all not completely compatible with each other because all these teams have very different needs so i i think a lot of this will get resolved as these printing systems become more efficient and you can take a more universal

approach so we're kind of happy to see how things shake out but in the meantime you know we're completely open to collaboration with other teams uh if if we have kind of mutual goals makes sense i think um noir is also the first kind of uh of best effort of trying to i guess bridge the gap of that fragmentation we're saying that you should use this open source project as your kind of front end for language so everyone's working on the same syntax and then if you have a slightly different kind of need for your proving system you can hook up the intermediate representation to a different proving system that may not be plonk um it could be it could be something else and if we can start to kind of get that methodology working within the community the project should take off and yeah kev's got some some thoughts

about this uh in terms of if the the language itself has a lot of kind of a standard library that's very feature-rich i think it can attract developers to uh use that language because they don't have to re-implement a lot of standard functions which kind of people are doing all over the place like a range constraint or a particular hash function um there should be kind of one repo with the fastest or the best beside in hash function or shot 256 hash function and if you give that to the community i think you can kind of encourage people to to work on the same project rather than different ones and to do that it has to be fully open source so that's what we're committed to cool is it is it rust-based or is it based on something else

it is rust-based so yeah i'll cryptographic backend has written c plus plus uh for a few reasons but uh because we want rust we wanted to be more compatible with other teams of building we just decided to build it in rust so you mentioned wasm earlier and now i'm curious what does this actually mean for the construction is there any limitations that come along with that uh when you're programming for the web the primary languages you have access to are very very limited because uh code executed web browser needs to be secure so you can't just like you know you can't just like directly manipulate a user's cpu um because you know you can get hacked that way so webassembly is basically a new standard for um extremely fast competition on the web it's an assembly language for an imaginary computer that kind of closely maps to

instructions that you find in real computers so the idea is that if you have webassembly code and running read by somebody code is kind of almost as fast as running native code on your cpu um because there's not much kind of a interpretation that has to happen between turning webassembly instructions to real cpu instructions however that's the ideal the reality of it is that for cryptography webassembly is really slow compared to running code like nate that's natively compiled onto your computer because modern cpus have very niche mathematical the maths that we do for cryptography and those instructions are not available in webassembly which means that if you have if you have a smart proofing system if you compile it to run on a computer and then you compile it so with web assembly the website version

will be about eight times slower than the native version on top of this it's extremely hard to do multi-threading in webassembly because you can't run multi-threaded web assembly codes because that's a huge security risk so you have these kind of parallel problems wherever some you can't even do multiple instructions on them that we use heavily to do slow to begin with so once you have all these extra slowdowns how do you how do you make the whole thing work how do you deal with this lack of speed basically and the memory limit as well so that's what we were kind of uh hinting at earlier with the the differences in the commitment schemes is is it's a wasm problem um it's in in most kind of devices you have between one to four gigabytes of uh available kind of proving memory and uh that really limits you on

uh the expressiveness of your your program in a normal kind of snark world plonk has issues as well but we we really need to get to ultra block to kind of break down those barriers and uh i think to go back to the question by the time ultra blocks kind of in the wild will have usable web assembly provers with full programmability so it's probably six to eight months off yeah cool you just called it ultra plunk right yeah for some reason i just heard octo planck and i was like whoa that also sounds very [Laughter] um can you elaborate like what did you have to do then

to do the work around even now like with what you have pre ultra plunk yeah so so there's a there's a lot of work that we need to do for example like the most time-consuming part of constructing uk proofs is is basically um prime field arithmetic and prime file multiplications and you've got two large prime numbers and two large numbers and you've got them multiply the modular big prime number so we have these really like tightly optimized regular assembly algorithms uh implementations for that that you can't use in webassembly uh we had to write our um these prime field operations in a way which kind of compiled into maximally efficient web assembly which is actually quite counter-intuitive to do that uh but the the main thing we managed to do is we managed to get a form of multi-threaded web assembly like if you have a seamless plus program

or rust program that's multi-threaded and you compile the tawasm you lose your threads because um since the spectrum meltdown attacks browsers better disable multi-threading and web assembly code so what i said we do is we actually spawn separate like web processors in your browser uh each one of them kind of takes on computing a little part of the pl of a plonk proof and so it's kind of a coarser version of multi-threading but we get similar results out of it and that gave us like a factor of like four speed up compared to what we had previously so that combined with the algorithms that have basically been designed with webassembly in mind have made our printing system fast enough for basic privacy git stock proofs um we think with a bit more work in the future we'll it'll be it'll be more than fast enough to handle like

fully programmable smart contract proofs as well but then what like you mentioned sort of the ultra planck is that the difference that you're describing that like once that's in it'll be easier or is there something else that ultra planck offers oh yeah it's all ultra punch so ultra plug doesn't help with speeding up web assembly it's just a lot it's just a much much faster printing system um because you can you can do common like all of the algorithms that we're running uh they require far fewer gates to evaluate using ultra plunk because auto plunk uses lookup tables this sounds really primitive like if you're if you like by regular programming standards basically what we've done is we've found an efficient way of being able to access lookup tables inside of long circuit and so you can use that to do things like model dynamic memory so you can

have in your primary language you can have like vectors and genomic arrays without them being incredibly inefficient so this is like really primitive stuff right you know like normal programming languages have had you know dynamic arrays since the 1960s um so uh but that's where we are and um it also you can use lookup tables to do snark unfriendly algorithms so um snarks generally are really bad at doing binary operations like doing um exclusive or operations or like logical operations because you have to work on individual bits and lookup tables kind of solve this problem for us because you can just have a big lookup table of your boolean logic to kind of do these operations kind of eight bits at a time instead of one bit at a time what did it enable so is um calling it the kernel snark but in order to get to

this kind of end state of full programmability and have that run in a was improver you need to kind of define the rules by which developers can write their programs so you can think of it a bit like a vm but it's it's how we allow user-defined noise circuits to interact with this private state and that's kind of the last bottleneck that we need to kind of overcome with ultra plonk to to get this really working at a high speed on on client devices i feel like you've mentioned words with the word plonk in them a few times throughout the show and i actually just wanted to run down and maybe you can just help me position it in my mind there's plonk regular there's turbo plonk which is what you're using now

yes okay there's splunk which i don't know if that's a thing or that was just a paper or a joke or whatever um it's splunk um yeah uh so yeah uh justin's uh wanted yeah i mean i i can't comment on silly names you know i'm i'm throwing rocks in the glass house um so yeah it's a variant of plonk um that um yeah it's currently a paper we're using we're borrowing stealing the commitment scheme from it but the actual full paper is is kind of a different way of constructing plonk snarks okay and then ultra planck is the next iteration yes so ultraplonk is turbo plank with lookup tables pretty much and then maybe octoplonk after that maybe yeah octaflonk megaplonk

square what is okay one last question is what's pluckup so it's it's a paper that r and i published last year so the paper describes how to use polynomial commitment schemes to kind of define lookup tables into into access lookup tables um and so what ultrablock is is basically us um taking our plug-up research and mashing it into the plonk snark proofing system so that instead of working with abstract polymer commitment schemes you can actually like you can have a plot circuit where you can have specific gates that reference lookup tables cool is there any other sort of term that i missed from that not that i'm aware of i mean i'm happy to invent a few more uh if you if you want to inflate the jargon i think mario was working on on covet plonk but

i'm not sure of that oh my god well we hope that we'll never have to see that one yeah maybe we get to just you know have post code yeah anyway okay i think the last point i want to talk about with with both of you is a little bit how the aztec zkzk roll up kind of matches up with all of these other rollups that are coming out and like how you're thinking about them when you were talking about you know having a user be able to send funds directly into like an l1 d5 building block one of the thoughts i had is some of those projects are actually going to be moving on to different l2s soon apparently and so i wonder like

with all of these l2s emerging a lot of them zk some of them optimistic how do you see yourself fitting into this kind of new landscape yeah so our main focus is privacy so so we're a private roll-up and currently like the only private role up around and the users that we want to serve are users that care about transaction privacy and um not revealing all their information on chain we're a little bit different to the other layer to use in that regard um because we're not really just chasing the absolute cheapest transactions possible um because adding privacy means that you're broadcasting your data because your data is encrypted um instead of users that want transactions for one cent which is uses that one private transactions for 10 cents if that makes any sense certainly i think as these other layer 2's get deployed there's going to

be a lot of um work on kind of cross-legged swaps to efficiently like move migrate funds between their twos that's something we'd be very happy to work with be very happy to kind of create efficient bridges between aztec and other layer twos is that what they're gonna be they're gonna be like new bridges i think it's inevitable because otherwise you're going to get this this kind of intense fragmentation of liquidity across all of these layers but it will be intense right because it's not that all these l2s and not all of these kind of rollups are actually consistent with one another like they may have like if you were to have to run a light client on those l2s they like each one of those may be quite bespoke yeah so well we're going to focus on l2s with have evm fully vm compatibility things like

optimism because uh like what we want is we want to make sure that our users have access to liquid defy pools um and so you can only have those on evm compatibilities so right now we're waiting to see how this plays out because right now the liquidity is on layer one we'll see how much migrates to layer twos and how much stays on layer one but um our focus is on users and we wanna we wanna make sure that our users can interact privately with the adapts and the contracts that they want to talk to so if they're on layer two we'll talk to there too if they're on layer one we'll talk to layer one makes sense i'd like to model it as kind of optimism or an l2 just becomes quite a complicated dap so in the same way we have kind of this

d5 bridge that we're building it doesn't really matter where we point uh the bus leaving to go and do an interaction it's going to go and do that interaction and bring whatever the result of that interaction is back to the aztec network in order to give it privacy so we kind of see us like growing with the l2 landscape alongside it um and yeah it's going to be exciting to see where where the different dapps end up and where the different d5 protocols kind of emerge and and some of them will end up on aztec i'm sure because they require privacy i have one last maybe controversial question but you'd sort of mention some of the limitations of ethereum as an l1 in building all of this like have you at all looked out at other l1

please don't hate me ethereum community for asking this question but i just i'm curious yeah i mean the reason we're building i mean i i don't wanna i don't wanna sound like we're dumping on ethereum you're saying there's ethereum we have to work with but really we need to work with the layer one that is both programmable and expressive but also has the ability to support these quite advanced cryptographic protocols and right now with three is the only game in town like there are other layer ones where i don't think there are other ones which have the kind of advanced crypto primitives we need as well as smart contracts for the tooling yeah exactly um so you know if another if another low one pops up with a lot of uses a lot of liquidity that's that we can easily put aztec to you know

we wouldn't we wouldn't rule it out but right now you know ethereum is um it's the place to be right it's the ecosystem with all the users all the doubts all the liquidity has got the expressibility and programmability we need um and you know they've also really pushed the boundaries with regards to what's kind of the possible you know like you know sure ethereum has only a limited number of graphic parameters available but they still have those primitives right you can still do pairing based cryptography in an ethereum contract which is quite i mean i was i was on some of some of the earth dev calls when that was happening and it was quite a it's you know it's quite a difficult thing to coordinate and pull off so yeah i mean for the time being we're we're very happy with the ethereum ecosystem we don't really see ourselves

you know we might it's easy enough to pull aspect to evm compatible chains but we we think ethereum is the home for us in the future got it cool well joe zack i want to say thank you so much for coming on the show and uh sharing with me and the audience this update of aztec the introduction to zk money which just came out it's actually like live now people can actually play with it do you have any anything you want to kind of share with the audience before we sign off love to yeah we are we're hiring um a lot we have a lot of open roles uh because yeah we've we've got we've got some ambitious plans that we we're executing on um so yeah like if you're interested in the space you know we're we're hiring pretty much the whole technical stack

you know front and desk back in devs we're hiring applied cryptographers if any of those are all sickly fancy get in touch we have a jobs page on our website it'll be great to hear from here from anybody who's interested and i guess people should go to is it is it's actually zk dot money that's the website right yeah if you go to zk zk.money and check it out uh get your username uh registered and you'll be able to kind of really take control of your privacy and yeah we can't wait to deliver more features to you over the coming months um and stay tuned for private defy very cool so thanks again to both of you i want to say a big thank you to henrik the editor andre the producer and to our audience thanks for listening