Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Joe Andrews & Zac Williamson: Aztec Protocol – Bringing Scalable Privacy to DeFi

Episode Date: August 17, 2021

Aztec Protocol enables private transactions on Ethereum. It uses a zero-knowledge proof system, allowing users to effectively create shielded representations of tokens, which can then be sent and redeemed for the underlying token. They recently launched Aztec 2.0 and their rollup service for Ethereum, zk.money. This allows users to submit Ether to the Aztec rollup contract with the options to shield, send privately, unshield and emergency ushield (escape hatch). The latest version also allows DeFi users to save gas and participate anonymously in DeFi transactions. We were joined by Zac Williamson, Co-founder and CTO, and Joe Andrews, Head of Product, from Aztec, to give us an in-depth look into the Layer 2 project and explain how version 2 of the protocol in a game-changer in terms of privacy and scalability.Topics covered in this episode:What has happened in the last year since Aztec were last on the showHigh-level overview of AztecHow the Aztec rollup works in DeFi applicationsThe challenges privacy introduces for DeFiSNARK, the core technology that powers AztecNoir (zkSNARK DSL)Episode links: Episode 335 - Aztec Protocol – Bringing Zero-Knowledge Transactions to Ethereumzk.moneyDiscordAztec on TwitterJoe on TwitterZac on TwitterSponsors: ParaSwap: ParaSwap aggregates all major DEXs and makes sure you beat the market price at every single swap and with the lowest slippage - http://paraswap.io/epicenter - paraswap.io/epicenterChorus One: Chorus One runs validators on cutting edge Proof of Stake networks such as Cosmos, Solana, Celo, Polkadot and Oasis. - https://epicenter.rocks/chorusoneThis episode is hosted by Sebastien Couture & Dev Ojha. Show notes and listening options: epicenter.tv/405

This is Epicenter, episode 405 with guests, Joe Andrews and Zach Williamson. Hi, welcome to Epicenter, the podcast where we interview crypto founders, builders, and thought leaders. My name is Sibbe Sanquitio, and I'm here with Dave Oja, who is a new co-host on the Epicenter team. So Dave is the co-founder of Osmosis. He works very closely with Sunny. He's been working with Sunny for several years on like Sica and other projects. So Dave, welcome to the Epicenter host roster. Can you tell us a little bit with yourself and introduce us off to the audience? Thanks, Sebastian.

I'm Dave. As Spatch mentioned, I'm a co-founder of Osmosis with Sunny. There's also another epicenter host, you should probably know. I also run the proofstick validator Sica, which mainly validates Cosmos chains. And I've been working with Sunny for a number of years with that. I used to work on tenement core in the college SDK, and I guess I'm now working both these actively again, with Asmosis. Prior to osmosis, I was doing a lot of research on how to improve snark recursion and how to build Starks with Alessandra Keza and like many other great folks at UC Berkeley. So privacy and snarks are very near and near to my heart.

So I'm pretty excited to the podcast today with Aztec. Yeah, and I think it's really fitting that you're here because today we're speaking with Joe Andrews and Zach Williamson, head of product and CTO at ASIC Protocol. all. And so we had Zach and Tom, another team member on the podcast in March of last year. And so we're here for an update today. Thanks for joining us, guys. It's a pleasure to be here. Yeah, thanks for having us. So before we talk to Joe and Zach about Aztec and the evolutions for that project since we last high of the bond, I'd like to tell you about our sponsors for this week. With Paraswap, you can beat the bare market price with every single block. It's fast. and highly liquid, and they've just integrated with ledger. So if you're like me, if you're using a ledger device,

you can now swap directly in the Ledger Live app. So this makes it really easy to do swaps without having to connect your ledger to the browser. So check them out at Paraswap.io. Are your assets sitting idly in your wallet? You can start earning rewards and contribute to network security by staking with Course 1. As a staking provider securing over a billion dollars in assets

on over 25 decentralized networks, including Solana, Cosmos, and Ethereum, it's one of the most trusted staking providers in the ecosystem. If you're interested in running your own branded nodes, they have a managed white-label node as a service offering, which leverages Chorus's highly available and proven infrastructure enable you to participate directly in decentralized networks. Head over to corus.1 to start your staking journey today.

So since the last time we had you on, how has the company grown and what's been the evolution of Aztec in the last year or so? Yeah, quite a lot has happened in the last year. I believe the last time we chatted, we just published our latest cryptography research at Plunk. And since then, we've put it into practice by releasing the first private layer two on Ethereum using that research. It's a network that allows users to shield Ethereum and other tokens and send it private. And that's been the main focus of the company for the last year. And now that's starting, we're moving on to bigger and slightly more ammessious things that we're happy to dig into as well.

Yeah, I mean, the last time you were on, we talked a lot about, you know, how the shield of transactions contract worked and like how that works for the user and also under the hood. But we did talk about defy a little bit. And I think that, you know, looking at what you guys are doing now, that that's definitely like more. on your radar. How has the growth in Defi in the last year or so, like, helped shift your focus? Has it, you know, was it an accelerator in shifting your focus more towards Defi or, you know, were you already sort of on that track? Tell us about that journey. Yeah, definitely. So I think the explosive growth of Defi really shifted our focus from focusing on kind of more Web 2 use cases and it's created a market for privacy on Web 3. So when DeFi was only kind of low

tens or hundreds of millions. There wasn't that much of a need for privacy. But now we're in the kind of 50 to 100 billion of market capital locked inside DFI. There's a huge need for privacy there. So it's definitely shifted our focus and the product offering as well and the network's capabilities to focus pretty much entirely on D5 with the upcoming release. Cool. So for people who are not familiar with ASDAQ, give us the high level overview of, you know, what you guys are working on and we can kind of go from there. Shorthy, so plastic uses state-of-the-art cryptography to enable users to high their identity when transacting on Ethereum.

Right now, one of the main problems with transacting on blockchains is the fact that everything is public, which means that everything that you do, every transaction that you make is viewable by the entire world. Now this isn't necessarily much of a problem and people that are just dabbing around with cryptocurrency, but when we're moving to a world where more and more financial transactions are being moved on chain because of its value as a settlement's layer, it started to become a problem. It's going to be, in our opinion, the problem over the next few years with regards to blockchain. And so, and we're here to solve it. We use a niche branch of cryptography

called zero knowledge proofs to enable users to prove the correctness of their transactions without having to actually leak critical information to the wider world, things like their identity, the amounts they're transferring, the assets they're transferring. We're, yeah, we're steadily building out our technology and architecture to support more and more use cases. What kind of use cases does this open up? Because, like, shield of transactions are cool, you know, and there's lots of people working on that.

Recently, we had tornadoes cash, although they've got, like, I think, like a quite different approach. but, you know, what does a zero knowledge, like a ZK, ZK roll up effectively? What does that enable in terms of new types of use cases? I think this culminated in March with the release of ZK Money, and ZK Money is the front end on top of our ZKZK Roll Up. And it enables for the first time an Ethereum transaction to exist fully privately. So you have ironclad privacy guarantees. very similar to the Zcash protocol.

The circuits kind of use a similar underlying kind of set of nullifiers to get strong privacy guarantees. But for the first time, that transaction is actually cheaper than a layer one, Ethereum transaction. So for us, it's this seismic shift where users don't have to choose between privacy and kind of being on Ethereum and being kind of in a world where lots of people are building applications. You can have kind of your cake and eat it, so to speak.

You can have privacy. but on the chain where there's the most developer activity. I can expand that a little bit as well with regards to the ZKCKRL. At the core of a prior transaction is the idea that, well, instead of sending to the blockchain, like the basic information about your transaction, you know, who you are, who you're sending crypto to, instead you send a zero-s proof. So basically you say, well, here's my old encrypted balance and here's my new encrypted balance, and I can prove to you mathematically that I follow the rules of the blockchain,

you know, I've deducted something from my balance and added it to something, somebody else is spandant, but I'm not going to tell you who I'm sending my money to or how much my money was. However, zero-in-lose proofs are very computationally expensive to check. It requires a lot of niche cryptographic operations, which means that it costs a lot of gas. So the question, one of the questions is how do you get, well, in general, how to get cheap transactions on Ethereum? But for us, the question is, how do you get cheap private transactions on Ethereum? And the solution is a little bit of inception-esque, but you go one level deeper. Instead of sending zero-knowledge proofs to the blockchain, which represent private transactions,

you create a zero-knowledge-proof, which proves the correctness of a large number of zero-knowish proofs. It allows you to send one kind of mega-transaction to the Ethereum blockchain that proves the correctness of hundreds, if not thousands of individual private transactions. That's what a ZK-ZK roll-up is. We take into calling it a private roll-up because it rolls off the tongue a little easier. So, like, you're doing one zero-knowledge proof of a bunch of transactions, but those transactions are themselves, like, using zero-knowledge-proofs to, like, be valid or, like, get privacy?

Exactly. Correct, yeah. So the entity creating that meta-meagrear-Zer-N-A-R-Proft doesn't need to know any secret special information. So, like, isn't this process, like, starts just really expensive? So how is this being done, or how is, like, you know, this arrogator, or, I guess, sequencer doing, like, being able to do it without high fees? Well, that's been, that's been, that's the question.

And the, something that we've been spending the last two to three years focusing pretty intently on. And we had to make several relatively significant advances in the state of the art when it comes to these kinds of cryptos systems to get there. Specifically, we need to create a zero-nals proving system that was fast enough that you could make these gargantuan proofs. Because, yeah, generally, if you want to create a zero-in-lawed proof of a computation, the act of making that proof is going to be about 100,000 to a million times slower than the original

pre-construction. So actually verifying zero-in-old's proofs, inside a zero-old's proof, is one of these kind of computation and lightness. One of the advantages that we have as a company is our chief scientist is Ariabazzon, he's one of the best cryptographers in the industry. And together we've

not just published the Plont CryptoSystem, which was one of the, which is one of the an extremely fast zika snuck but we've been able to modify and update and mold our proving system to to engineer it to be to be tailored towards our specific means and so that meant that we have a lot of agency to make the proving system particularly good for things like verifying zero knowledge proofs and doing quite advanced and difficult computations and that's that's really why why we've been able to to create this kind of construction on the theory I believe currently it's the

this request that we have is the only one that's actually viable on the Ethereum blockchain given the limited cryptography you can do inside a smart contract Super cool, I've definitely been following that story of Plunk. I remember when the paper first came out and made such huge waves during a, what a snark temper of that year? What's the story of the name Plunk? It's such an interesting name.

Interesting is one way of putting it, yeah. So, originally it was a placeholder name. So, Ariel and I were struggling to come up with the name for the paper. And I suggested Plonkin as a bit of a laugh, partially because, as you said, it was this month's not temper, like over the last few months in that year 2019, quite a lot of seminal cryptography papers had been released. And quite often had like ambitious names, you know, like powerful names, things like, you know, sonic or darks and

starks and Marlin and and I just I felt like it would be yeah basically I thought it'd be funny to its name of Plunk it's British slang for cheap low-quality wine and I feel like there's a little similarity because you know understand you know

getting getting to the bottom of plonk requires making questionable life choices bit like a bit like you know real Plunk and and you know gives you a headache if you spend too much time with it so basically okay so basically We call it Plont, we published it to Eprint. Generally, Eprint takes, like, a week or so.

Eprint's this big, like, like, a website that is a repository of cryptography papers. Generally, it takes a week or so to approve a paper for release. So we thought, Analyst is published it now and deal with the name later. But they published this one overnight, and then people started tweeting about it and saying, hey, what's this Pplom thing? And so basically, the kind of word got out about it, and we figured it was a bit too late to change it. And, you know, it was kind of funny. So here we are today.

But it got kind of like backwards name, right? Oh, yes, yes. So, yes, I think one of the only useful, well, not useful, one of the main skills that I picked up from a degree in particle physics was elaborately named acronism. So it stands for permutations over the Lagrange base, that's the P and the L, for ecumenical, which means all encompassing, non-interactive arguments of knowledge, and the A is silent. great. I love it. I hope we can push for snorcs as a word about skarks.

I don't know. We've lost this one though. Occumenical instead of... I mean, it would be nice, wouldn't it? Yeah, we've got a few years of inertia to push back against, unfortunately. So last time you were on, we talked about Defi. Before we did this interview, I listened to that episode.

And one of the things that we talked about was, you know, privacy and defy. And, you know, you mentioned that privacy makes defy paranoid. And the way you described that is, you know, by using Maker as an example, could you elaborate on what you meant there and, you know, how privacy, you know, more broadly, or at least privacy technologies, you know, break certain applications in defy? Yeah, absolutely. So, yeah, to expand on that paranoia.

So basically, what are the questions, which is relevant when it comes to privacy, private transactions, is how on the basis do you make a private defy protocol? Because it would be really nice to have a private version of a maker, that way. You can make a CDP and nobody knows how much it is. And it would be nice to do things like have a fully private decentralized exchange, where you have a private order book, but you can still match trades. But the problem with these approaches is that in a private world, you can't have public state because modifying a public state variable leaks information about what you're doing.

For example, things like Enoslop, for Neoslop, you need to understand the total amount of supply you have a big of an asset to perform, to understand which liquidity you have. And so if you deposit into a liquidity pool, then you're changing the total amount of liquidity. That's public variables. So people can see what you've deposited. that's not private. Similarly for MakerDal, if you create a collateralized debt position that's private, that means it's encrypted.

And so how in the blazers does anybody supposed to figure out if you're becoming under collateralized? And if they are, how are they're supposed to liquidate your position? Because it's encrypted. Only the CDB creator knows how to decrypt it. And they're not going to help you liquidate their position. So that's one of the fundamental problems with privacy. And the paranoia comes from, for example, you could create a private MakerDAO where you have a CDB, where the CB creator has to constantly kind of send effectively proofs of life.

They have to continuously prove that their CDP is over collateralized because they only personally can create this proof. And if they don't serve the proof, this proof of life, like a day or two, then they get, then there's something bad happens to their position. And so there are ways of getting around this. We wouldn't be doing what we're doing if we didn't think that we could provide practical and valuable privacy to defy. The Holy Grail solution is to use multi-party computations.

where, for example, if you want a, for example, a decentralized exchange with a private order book, but you can still match trades amongst people. In theory, you can do that through multi-party computations, where you have like a ring of individuals. They all have their own orders and prices that are all encrypted, and they slowly engage in these MPCs with one another to kind of drip feed information about their orders to counterparties that have matching orders. and in aggregate you can you can achieve a very high quality of privacy with these kinds of approaches. However, the complexity of these approaches is absolutely enormous, and we're nowhere near the point today where you can bootstrap these kinds of protocols.

You know, it's hardly anybody in the world who can develop them to be efficient enough to work. And so you don't have that kind of that mass appeal that you have a theory where, you know, anyone can code up a smart contract. But we do have a much simpler solution for privacy. when it comes to defy which we could expand on um if that would be a i don't want to preempt any questions there please go ahead explain so yeah so how do you okay so how do you how do you get private defy well the the the the the the simple answer is you don't um basically you leave you make you keep the defy protocols public you know unoswap make it out you leave them where they are you're hanging out on layer one completely public everyone can see what's going on and what you do is you make

the assets private. You ensure that individuals have, their holdings of various cryptocurrencies is anonymous. So if, for example, let's consider the, they make a deposition again, imagine, you know, you know, make it as public so you can see when a CDP is created, you can see as value, you can see when it comes under Calais and liquidated, but you don't know who holds it. And that's a very high quality privacy, because that, I mean, it could be anybody. And so the most important thing isn't to, in an operating, to make the, the, the, the, the, the, the, the, the, the, the, effectively, like the sites which interact with value private. The important thing is to make the value holders private and give them anonymity. And, and that's how we're planning on doing and on, on, on achieving privacy. So it's like, uh, you have, you hide all the addresses. Then you kind of publicly, when you do a trade, it's what's public is at a, uh, it's, it's, it's, it's, it's, it's, it's, it's, it's, it's, it's, it's a, it's, it's, it's, it's this amount is going from some address that has the right thing, does public action, and it goes back to a new, like, private access.

So you can see, you know, you can see like, you know, 10, for example, like, you know, 10, eth has gone from address, question mark, question mark, question mark, it's gone into uniswop, got out a bunch of dawn, that's gone back to address question mark, question mark, question mark, question mark. And so that kind of quite, we think quite effectively solves a problem. You know, these, these protocols can still exist in all the, all the magnificent complexity, without having to kind of rewrite themselves to be private, but you still get the benefits of privacy that users care about. I've got an analogy that would be helpful for

the listeners. Internally, we call it the DFI bus. So you kind of see the Aztec roll-up contract as being like a bus station. And there's all these buses that have kind of tinted windows. And you can see the front of the bus. It says, I'm going to Uniswap to swap beef die. And people can get on the bus. And you can't see who's getting on the bus. And you can't see who's getting on the bus, but it will go to uniswop, take the EF to uniswap, and it will bring back a load of die on the return journey of the bus and give it back to the users in the Asset network. So I think it's a good analogy for kind of showing how this network interacts with the rest of the defy ecosystem and whilst giving strong privacy guarantees to everyone who's on that bus

or in that transaction. So from a user perspective, I just want to like walk us, as I understand it, walk through the transaction flow here. I want to trade on uniswap. In order to do that, let's say I want to trade like eth for die. I send the eth to the Aztec contract. I get into the bus effectively. Then that trade gets made and then I'll get say die back at some point. Couldn't someone just be watching my address and see that I interacted with the contract? I interacted with, as you call it, this uniswap bus and just deduct that I've just made a trade on uniswap? I mean,

so it's a bit more, it's a bit kind of, if you do a direct deposit like that, in the same transaction, there would be kind of a way to link your layer one address to that trade, but the flow actually is a bit more, it's going to have one more step. So users have funds already on the Aztec network,

so they're already shielded. So you would have in a separate transaction, you'd take your EF and you'd make it ZKE, And then you have these encrypted UTXO notes on Aztec, and you can use those to interact with any L1 smart contract through our Defi Bridge. So in this case, you'll choose to interact with the Uniswap-Eth dipole. So you kind of send a transaction that says, I want to put one ETH into the next bus going to that pool. And the owner of that ETH could be anyone who's ever deposited ETH to the Aztec smart contract. So your identity is completely hidden throughout that process.

The roll-up provider will then bundle all those transactions with any other user who wants to do the same trade. So say, Zach also wants to trade to ETH and a few other people are also getting on the bus. So we'll send an aggregate then transaction from the roll-up contract out to Uniswop, say, five even total. And we'll bring back Dye to the Aztec roll-up contract. And that will then be dispersed in zero knowledge notes to, the holders who participated kind of in that transaction. So you're actually not getting the proceeds of the default interaction on layer one. You're getting it an encrypted form on layer two, which is how the strong privacy guarantees

kind of maintained through that. I think it's quite an interesting way of doing it. And Zach can talk about the actual cryptography because it was a bit of a breakthrough moment for us to actually get the identities hidden through the process. Okay. So it uses the same note system as like the previous version. I think that's what I missed. The node system's actually not graded for them because the old Aztec just had confidential notes.

So here, both the balance and the owner is encrypted. So that's what gives us kind of the anonymity we need to do these transactions. How is this looking like from a user perspective? Like, you know, right now, I have a connect metamasking your soft subsite and I just kind of pass a bud to do a transaction. So is it like, is it still pretty similar where on online? like the Aztec site, there's still a way to connect my wallet and just do the trade that, do the transaction that like does all these three steps, like go to L1, swap and go back to L2. Yeah, so we have a kind of, we call it ZK money and it's kind of like a showcase of what's

possible with the Aztec SDK. So in the next kind of three months, the main venue for these trades will be ZK money and you'll be able to connect Medamask. It will show you either, if you have, on layer one or if you've already kind of used the Aztec network, it will show you as EKE and you'll be able to kind of do these various defy-interactions and yeah, all of that will be abstracted from the user via SDK. The kind of three to six month goal is the SDK is integrated on a lot of these L1 front-end protocols. So you can actually just go directly to uniswarp or are they or some of those protocols

and perform, have the option to perform the interaction privately. Absolutely. Very cool. I feel like this general approach is like the future of like practical privacy for defy things. It's often like you, you know, if you want public information like, you know, constant product market makers or cost function, then you have to like have the softly public. I mean, yeah, I think it's kind of the best of both worlds because you get the kind of the transparency of layer one defy, which is kind of what's made it grow to be so popular. But you also don't have to sacrifice what a lot of people take for granted in the web. world as just basic transaction privacy. No one can see my Robin Hood account. No one can see kind of my Revolut account. So I think this allows new types of kind of user experiences that give you the best of, I think, L1, DFI, but also strong user privacy guarantees.

Yeah, sorry, I just want to like stay on this defy topic a bit. So in that case, then you would need to create, I mean, like Unisop would need to add a, like Aztec-Eth, Aztec dye pair, I suppose, and if you wanted to trade those assets? That's one of the key parts of our approach is that we're looking at the kind of the evolving layer two landscape. And right now, kind of the impetus is on having split liquidity

because if you want to benefit from the fee reductions that you get from operating on layer two, you've got to move the actual defy protocol into the layer two and it has its own liquidity pool that has its own asset pairings, etc. But for us, we felt it, we wanted it to be very much felt like what users want is to leave the actual sources of liquidity on layer one, because that's where they're going to get the best prices, but interact with it cheaply.

And so even if you have shieldedastic assets and you're using our DeFi bridge to interact with an AL1 smart contract like UNISOP, you're still talking to the UNISWP's layer one liquidity. So the Etheridge's dye pairing that you're getting and the associated price, it's still based around the global unit swap pool. So in order to perform an integration with ASTIC, you need some kind of facility ability to shield user funds using the ASTAN network, but that won't materially affect the price that they're getting from using our protocol. Okay, interesting.

What about collaterization? how would collateralization work using Aztec? For CDPs, do you mean? Yeah, like a CDP, for example. Yeah, so there's two methods, really. You can have a SAC kind of mentioned earlier on, like a unique CDP for you, where you don't really benefit from huge gas savings,

but you have strong privacy guarantees, or you can have kind of tier CDPs. So you can kind of have a system where we all agree with 100 other users that we want to enter into a three-month term CDP, and the LTV ratios can be kept at a certain amount. And then everyone's kind of doing the same thing. So you can get pretty strong gas savings as well as privacy savings from doing that. So it depends on kind of the end user product.

We're starting to see a lot more fixed rate kind of protocols come online in DFI. So I think that's where I think the kind of retail users, will end up is kind of on more structured products rather than wildly swinging pools. But that's kind of, I think, the approach that we take with collateralization of blends. So I think I didn't quite follow. Are you imagining that the collateral is held, like, just like one big collateral pool held by the contract? Or you imagine that there's somehow like a, and like my share of the pool was private,

but handed on the roll-up side? Yeah. So you could have like a Aztec, Q4, ECDP, and you could have different clatterization ratios. So this would be the 150% cladterization ratio. We'd all enter on a certain date and it would be a three-month term. And kind of that would be one approach to doing it. And in that case, you get like a much better gas cost per user

of actually taking out that form of debt. Or you could have a lot. the case where if you're a large user and you don't mind paying kind of the L1 gas fees yourself, you can just have free flexibility by entering in kind of any CDP of your choosing, but you wouldn't get any batching in that circumstance. You'd still get batching on the cost of privacy, so you'd be able to have your transaction batched with other zero-knowledge snarks that are doing different things, but you'd pay the full cost of the entering the CDP position. So you get kind of a bit of scaling in terms of privacy.

Oh, so it's still fine to hold the collateral in this, or sorry, you have the loaned amount being in this private, as a tech L2, but just collateral's got to be on chain since, you have, you need liquidation to be able to see it, or? Yeah, so in that case, it would be like, in a single user case, it would be like a smart contract would own the position, and that smart contract would be like, I know, create two op code. So you'd have kind of a new smart contract for every kind of CDP that was created, where there was just one user kind of behind that CDP. It's just the source of funds that do the initial categorization are coming from the Astate network, not from kind of a tainted 1 address. Very cool. On this privacy idea, so I remember like ZCash, there was this problem of people would go

from the transparent pool into the shielded pool, and then it kind of almost immediately go from shielded pool back to transparent, or in this case it would be like shielded pool to unosop trade, the exact same balance. How are you thinking of like mitigating like the linkability there of like just exact amounts? Yeah, it's it's, it's a full amount. Yeah, it's a big problem. And it's part of it as an education issue and part of it is a UX and design issue. Because what it, what, because of the, this privacy take is so relatively new, I think a lot of users don't fully understand how it works and that you, effectively, you'll buy, when you shield your tokens, you're, the active of that of depositing into the shielded pool is public so they can

see, for example, that, you know, Dave puts 10th into Aztec and, but, and then, and so if you then immediately withdraw, it's very easy what's happened, you know, if you see, you see Dave's deposited 10th into Aztec and then in the next block, Dave withdraws 10th from Aztec. It's, I mean, yeah, it's kind of obvious. But what you really need to, you really need to. to do is deposit your value into Aztec, wait a little bit, and then withdraw to a different address, the one you originally deposited from. Because, let's say, because we try to encourage through our UI people to deposit in relatively fixed amounts like one 10th. So the way it would ideally work, if you're, if you're for an educated user is you deposit 10th into Aztec, you know,

you wait a few hours and then to a different address, you withdraw that 10th in the Aztec. And that 10th could have come from anybody who from now to the dawn of the start the protocol deposited 10th into Aztec or acquired 10th within the Aston network somehow perhaps through DFI.

But most of it I think it's just making sure in the user interface that the user is informed of what they're doing and so that if they're if they do this this firmware you immediately deposit and withdraw then the UI goes you know hey you sure you want to do this and Joe I think you can you can expand on that

bit. Yeah, there's a few cases. We're kind of touting this idea of a privacy score. So kind of just really helping to inform the user of how private a transaction they're about to do is. And as Zach was saying, that can be anything from, hey, you're, you're unshielding to the same address you deposited from. That's not private. Or there's a high linkability risk there. Or things like if you're kind of unshielding to a very large, significant number of decimal places, then that's also kind of can add to the linkability of those transactions. The great thing about the kind of the default bridge, it doesn't fix all of these things,

but it's the first step in the road is that privacy kind of starts to become by default, not opt-in. And I think the issue with some like other privacy systems is that when you have to choose between privacy and not having it, traditionally the user experience has always been worse or always been more expensive. So it's always been, the incentives is to get out of the privacy shield. And what we're trying to do with the next couple of versions of Aztec is change that, flip it on its head so that users should be comfortable keeping their funds in the Aztec network.

And then those kind of opportunities for a privacy breach should become a bit more reduced. But you still have to kind of be a bit careful when you're interacting with the defoe bridge. if you kind of deposit, I don't know, 90% of one token to the Aztec network and then there's a defoe bridge trade for 90% of that token, you can kind of start to figure out what's happening. But where the defoe bridge, I think, comes into its own is if you have kind of smaller trades that have drip fed into the market over time, if that trade is kind of pretty homogeneous compared to like the normal size of a transaction on the network for that asset pair, you great privacy and that's what the UI will kind of enforce and try to guide the user around

with a privacy score. Oh, that's very cool. So you're like detecting these cases where you think it's easy to link back and then giving a warning right then saying, look, this transaction is likely linkable. Maybe you want to break it up or wait some more time. Yeah, that's the idea. And I think like on day one, it may be kind of just like one of those password indicators. that's kind of like strong weak or kind of extra strong.

But we're working on kind of the metrics to put into it right now. But I think that's the easiest way to identify the user of a potential issue because a lot of this is just user experience. You haven't had to think about this in a Web 2 world because you have kind of privacy from everyone except your service provider. But in a Web 3 world, there are kind of these different cases where you do need to kind of be notified and users, have to kind of accept different norms.

And I think it's on apps and applications to start to think of better user experiences to notify what data is public and who can see what. And this is just one thing we're trying. Very cool. And I guess there's also a sort of thing where the amount of warnings you get really goes down over time as more assets or more historical records are there to be like selecting from. Definitely.

Yeah. Yeah. As the kind of privacy set grows, you should see less and less warnings. and yeah, the kind of network effect around privacy and the ASEAN network grows stronger. And I think also the amount of times you want to kind of leave the ASTAT network will also kind of shrink. So you should kind of have less of these opportunities to accidentally break your privacy. I think we can talk a bit more about like how we get past kind of defy and the longer term goal. And that would kind of explain a bit more about kind of how noir fits into all of this and how long term we think a lot of more applications will have.

and within the network, so there'll be less and less chances for those privacy breaches. Yeah, sure. Just John, talk about how you're imagining noir and more privacy, or more applications on the private side. Yeah, so this is, this kind of defibrillage thing we're building is merely the stepping stone to our, kind of our grander aspirations. It's an architecture that we're calling, like the working title is S-DIC 3. where right now, with what we released in March, you can shield cryptocurrencies,

you can sit around privately in a unilateral way, which is, it's useful, but it doesn't really tap into the massive ecosystem of innovation that's happening in the blockchain space, which is where the default bridge comes in. But even that only provides, it provides good access to public layer one protocols, but where we think privacy really starts to shine

is that it opens up a whole, new category of interactions that just can't exist today on a blockchain because of the, because so many, so many applications in, for example, like traditional finance or payments or like the kind of use cases that everyday individuals desire require strong user privacy guarantees. And so what we want to do is effectively recreate the Ethereum smart contract ecosystem inside Aztec, but where privacy is preserved. so that to give developers, engineers, users the ability to write their own smart contracts

that have privacy baked into the core so that you can just, it's not just that you can have a private token, but you can decide how it's transferred, who can own it, how to mint it, how to settle it. Because what this really enables, and what really excites us, is that this is the first time that you can meaningfully put your identity on chain

and link it to your crypticester. currency accounts without splashing your personal information all over the internet. It means that you can conditionally prove parts about yourself without revealing that to anybody else in the wider world. For example, you know, you can have, you know, an identity token that you can have some, some cryptocurrency that's conditioned, that's holding as conditional having one of these identity tokens. Or even more, like more, it also opens up like more other innovative spaces like, like

for example, private NFTs, where you can have some data fields that are private, but you can prove parts about your private NFT to other people under certain conditions. You can have, it opens up a whole innovative trunch of blockchain-based games, where you can actually have information asymmetry. So, you know, the players of the game actually can not know things about their counterparts, which isn't really the case with the fully transparent setting. But all of these things require programmability. It requires the community to decide how they best want privacy to be used in their applications

and to have the tools and ability to program it themselves. And that's where NARA and Aztec 3 comes in. Noir is our highly efficiency case not programming language, is beheaded by Kev Kuev Fedab Vedababababababab. And it's a rust-based syntax language that compiles directly to highly optimized long seconds. And we're planning on using that in a, in a, in the kind of the next iteration of our protocol design, where instead of our kind of ZKZK roll up, verifying the same transaction type over and over and over again, this list is like

private transactions, private transactions and private transactions instead, what the rule that verifies is a zero-in-old's proof that's over, it's come from a one of these circuits that's been written in noir and uploaded into our network by anybody. Basically, it's, it's the NASDAQ Eastern technology, which allows us to create a fully permissionless, private programmable cryptocurrency network. And that's, yeah, that's pretty much once we're,

once we're put out the defypitch, that's where we're heading with all our energy and attention of resources. Well, very cool. If I want to unpack it, because there's a bunch of components there. So the programmability idea is like, I want to be able to put my,

is it like the Zexi model, where I guess you're from there. There's a couple of things trying to do that where you have a public or you have like a program on chain or on the NASDAQ chain that you just can interact with in sort of a private manner where the contract can maintain both the public state and private state and every interaction just updates both of these.

Yes, exactly. But where I think things differ is the fact that what we've been very much trying to structure this architecture to look a lot more like a systems platform that would be more familiar to software engineers. So it beg to kind of eight familiar blocking concepts. Like you have a, when you're creating these transactions, you have a concept of a call stack. You have contracts I can call other contract. You can have one contract with multiple functions. And you can kind of have reasonably like somewhat arbitrary transaction debts.

So you can have, you know, contract people call it, contracts quality other contracts called a other contracts, called upon the contract over and over and over again. You don't have some of the restrictions that other systems have like Xexi because of the, well, their restrictions come down to the fact that the protocol was designed for this kind of limited recursion technology that was available at the time. And I think things have moved along a bit like a little bit, like there's been a lot of development on these like on cycles of electric curves with this halo recursion system with the stuff that NASIC's doing, which means you can have this kind of arbitrary depth recursion where, where you can have ZKPrews, verify ZK Proust, Verify ZK Proust,

all the way down. And this enables, yeah, it enables your ZK SNARC circuit to encode an algorithm which starts to look a lot like VM-based cryptocurrency protocol where you don't have to like learn new and like kind of

oblique different types of transaction semantics in order to program it. Oh, cool. So it's starting to look more like Base Layer-Eath where it's solving the old problem of a, I could really only interact with one contract or like a small set in one transaction because just limited approving tech for certain curves. But now you're saying like with the Aztec unbounded repression, and this is like fixed.

You can now, in theory, I'm going to throw my hands, okay, we've not built it yet. So the mission for our company is putting this in practice it over the next 12 months. Cool. I guess a question, maybe this is a bit technical for folks, but like how does the proving work here, where essentially you're having, suppose you want multiple transactions interacting the same contract per block, but they all affect state.

Do you have some out, off-chain aggregator like bundle these together and make one proof? Or is there some parts that are like available to the block proposer for them to do the proofs to get many transactions to one contract for block? No, it's a good question because you do run into some, so-called like, race conditions when you're dealing with these kind of off-chain aggregation services,

particularly with private, when protecting privacy, where if you have multiple individuals who wants to talk to the same contract, then they're kind of that they want to, they're effectively modifying the same database. And you can kind of get into problems with, you know, lots of people kind of, it's been like lots of people wrestling over the same, over, over a single piece of cake and going, you know, I want this cake, I want this cake. I don't know, that's a great way of describing a race condition. But there's a fairly straightforward way of solving that, which is basically to have this aggregator be the entity performing state updates so that when individuals send transactions to the aggregator, they request state updates to be made on their behalf. And if they're private, then they'll be encrypted at their public.

They won't be. But it's actually the aggregator who's doing the mechanical process of putting these variables inside a database, modifying those database values. So, yeah, I think at this point, it's a realistic self-problem. Okay, so it's not really a privacy leak in that the aggregator already accessed the private database, sort of like the private state. So that's, like, there's no new information they're getting. Exactly. I mean, if you're basically, when you create your privacy proof,

that that proof will spit out a bunch of variables, but they're all encrypted. And those variables need to be added into a database. But the aggregation doesn't have, like, doesn't, know anything about those variables to them if they just sort of like random numbers. Oh, they don't need to know these random the actual data entries to handle state conflicts. Well, the idea is basically you don't have a state conflict. So, well, this may be getting into the weeds, but dealing with private state and public states, they need to be treated differently. So with private, the way the way that handles private state qualifications is

you, well, using this kind of this Bitcoin's social. unspent transaction object. The idea is instead of having an like an accounts where you have something like a balance which you can modify over time, you instead have these these notes that you can either be created or destroyed. And so this makes the state model quite simple because a note can either exist or doesn't exist. It can't change value. And so if you want to perform a state update as a user, you want to create some private state variables, then you're basically you basically, you want to create a bunch of these UTX notes and you want to delete a bunch of existing UTXernets.

And so basically you go to derogation, you go, hey, I want to make these UTX notes and I want to delete these other like UTX notes. But the key thing here is that they're all encrypted. The notes you'll be created and encrypted, and the notes you're destroying, they are, they're encrypted, but they're encrypted. But this is really getting used to reasons. I think maybe is, I'm going to struggle to explain this properly in the, in the time you have available. But basically the idea is when you want to destroy a note in Aztec,

the way we record a notice is being destroyed uses a different encryption algorithm, which the way that we record a note being created. So basically, the mark in our kind of ledger which says a note has been destroyed, uses a different encryption algorithm to the mark on a ledger which says a note has been created. So you can't ever link at like a destroy notification to a create notification. Oh, cool. So it's like you're making everyone has to do UTXOs, these private contracts define, like, validity to the UTXOs, but then when you do a transaction, the new UTXOs get created, but you break the linkage,

like intra-batch between inputs and outputs. Yeah, exactly. I mean, it's extremely similar to how Zcatch handled it. I think they were very much kind of trailblazers on this with this regards. Cool. So, okay, so then like, Noir is spinning into this by baking this like DSL for folks be able to write these contracts that are in this UTXO model and compile to programs? Exactly. So Noir's going to have quite a lot of layers to it, because like the first, the first thing that Anar needs to solve is that these programs that people are creating

need to be turned into extremely efficient zero knowledge proofs because one of the main problems with zero knowledge cryptography is constructing these proofs is generally quite slow. As I said, it's like a factory of 100K to a million times slower than running a computation. Now, one of the ways that this can be sold is by delegating proof construction to third parties. So a lot of scaling solutions that aren't private take this approach because it's a bit of no-brainer. You know, it's hard competition to do. We'll just send it off to, you know, 1302-AWS machines and then you'll get it done in a few seconds. But because we're dealing with private transactions, you can't delegate proof construction to a third party

because then you're leaking information secrets to that third party. So effectively all of these programs that are being created in Noir, they're all being turned into zero-harmes proofs that where the proof construction is happening be made directly by the user, you know, by people with old laptops, crummy phones. And so you're very constrained in how much horsepower you have available, which is why it needs to be efficient, which is why we developed a ton of advances with our proving systems. And then, but then you've also got to make this the user program, which means you've got to have the abstract kind of smart contract semantics, state modification semantics, you know, and all of that associated paraphernalia. That's easy to understand to the user. And so that, like, to be complete transparent, that is still very much a work in progress. I'm not going to be arrogant. It's not to say we've solved that problem yet.

But I have every confidence that we will. I mean, I think the first step is, is a, is a. abstracting the cryptography from the developer and then the second step is kind of baking in more functionality and that's where the kind of the bit we're working on but at the moment you can kind of use more to just kind of write a snark circuit but it doesn't really fit in with the rest of the kind of the Aztec role-up ecosystem so that's kind of the next focus of the company post-devo bridge is to build that part of things but the actual language kind of early syntax is written and we're actively getting

feedback on it right now as kind of a new way to write SNARC or Planck circuits. How important is all this to I mean, it's a sort of broader adoption of zero knowledge technologies, you know, in and outside of crypto, I guess,

like privacy preserving technologies. Like, I think if you take the average web developer, like, or even iPhone developer or whatever, I think a lot of these developers have very little understanding of how zero knowledge technologies work and how did it implement them. So how important you think this work is to sort of broadening the scope of use cases for zero

knowledge tech? I mean, I think it's foundational. I mean, we just have to, we have to look at why Ethereum became so successful. It was because anyone could write a smart contract. You know, you had this incredibly powerful technology. This just, just distributed leisure that suddenly stopped by coming. It wasn't as kind of this, this, this incredibly, um, difficult concept to wrap your head around and difficult to interact with.

But instead, it went from that to going like, you know, here's how you make a cryptocurrency token in three lines of synergy code or however many it was. And it was very easy to access. And I think it's absolutely essential to propagate zero-in-lawful proofs and this kind of cryptography to a wider audience. You've got to explain it in terms that people understand that are familiar to them. And you've got to abstract the cryptography away. As you said, most people are probably saying quite widely, like, incredibly intimidated by this

copatography. And, you know, there's the very common old analogy, you know, don't roll their own crypto, don't roll their own crypto. It'll end badly. And I say it as a cryptocry. So creating an abstraction layer, which presents very complicated cryptos systems as easy-under-sign programming languages with clearly understandable semantics, where the, where you know that whatever you produce, the cryptography behind it will be sound and secure. It's absolutely. essential for the for the wide-scale adoption of this technology. And what are the risks here? Because, you know, we've seen in crypto that, you know, the bugs can be catastrophic.

We've also seen, so the cascading effects of, you know, layers upon layers of dependencies, you know, breaking large-scale applications on the web, like, recently with like all this NPM kind of stuff. stuff happening around there. For a developer, I'm speaking mostly like developers outside of crypto, but even people coming into crypto and who are like some background

of development, how do we ensure that you know, they use cryptography responsibly and that they're using the right, that they're using libraries that are, you know,

vetted and audited. And, you know, even if they're developing at a higher level of abstraction, but that, you know, someone doesn't use like a cryptography library and like,

to build, I don't know, some kind of messaging app, for example, and, like, exposes everyone's messages, or, like, something catastrophic like this, right? Like, what's the right balance of, like, expertise to, in general availability that we're looking for here? It's a good question. And I'm not sure this one with a particularly easy answer, because, like, the risks are real. I'm not going to try and trivialize what we're doing here. I mean, the complexity, the amount of complexity involved in these advanced cryptosystems, is absolutely astronomical. And then if you add on the complexity of a very complicated systems

level architecture that's almost building, using tools that have been developed to turn it into a grid into a zero-in-lawish proof, then there are certainly risks there. But I think that it's going to be an evolving process. You know, I do think that it's obviously, there are some basic things you can do, right? I mean, like you can make sure that at every layer, your technology stack has been fully audited and that, you know, it's been written by, people who are the experts in their fields, you know, like, we're very lucky in Aztec to have RLGabazons as like, you know, to be able to able to help us with like internal audits, which, to be honest, before we released out, our private role did reveal several security

issues that we've, that were resolved because, because there's this complicated beating as stuff and it's very, very, very easy to get it wrong. So I do think that there's going to have to be a period of time where once these kind of these, these advanced, abstraction layers, these programming languages start to become easy to use and more widespread, that they will need to be a pressure of caution, because I think, like we've seen with the adoption of Ethereum, sometimes the only cure is time, right? Like, a lot of, like, I don't think I'm being unfair when I say that, like, the solidity smart contractual language is widely considered to be, you know, somewhat insecure, like it's not. If you were to do the,

if you were going to rewrite Ethereum, all over again from scratch, you would design solidity in a very different way to make it a lot more secure to program. But obviously back in 2015, you know, Gavin Wood was doing this for the first time. You know, so nobody was aware of the issues that would result. But that being said, today in 2021, I would argue that if you're going to write a smart contract, so literally is the best language to write it in because it's been battle tested. And these bugs, these exploits, these problems that have been, you know, found out, unfortunately, sometimes through hacks and attacks.

But it means that you have this large kind of anthology of security practice and principles to draw on. Now, we don't have those for Zika-Syke-Sypregn languages because they're completely new in their infancy. And that book will have to be written. And there's a question about how much of that book is going to have to be written is going to be written ahead of time through thoughtful and careful deliberation of how these ecosystems are built. And how much of that book is going to have to be written effectively in cash from people losing money through hacks and exploits. And, yeah, it's something that's very much on our mind. But I think the only thing you could do is audit everything, develop things thoroughly, maybe very, very considerate about what changes you're making to your cryptographic architecture

and getting the best people in the industry to work on it. Sometimes even auditing isn't good enough or is questionable. Because, for example, with the kind of cryptography we're developing, you know, who can audit advanced ultralcite seconds? I mean, I can count the number of people that I trust to do that on the fingers of both my hands. and they're all busy with their own projects. So, you know, I think it's, I think it's one of these issues that can only really be solved with time and attention.

I could add one thing as well. It's about the amount of the protocol for kind of, if you take the iPhone developer, example, like how much of what they're building needs to be in noir and requires those kind of like fundamental privacy guarantees, like how much of it can be written at layer one, kind of in in terms of like just written in solidity. And it's about assembling that kind of stack of that, I guess, different kind of languages and different pieces of technology to get the end product that the users need.

I think trying to do that all in kind of noir on day one would probably lead to a lot of catastrophic bugs, but doing bits of it in noir to give the privacy that's required, bits of bit of solicity, bits of it don't need to be on chain. And I think there's a lot of learnings in the space generally from 2017 where people were planning or putting social networks on chain and all these things that were meant to be built on a blockchain that don't need to live there. So I think it's about kind of careful design of what needs to live where in the stack.

And that will kind of evolve over time and more things will be in the private end. That's kind of our bet. But it's about making sure the right things are in the right place to kind of do damage, limitation in case something does go wrong. Oh, cool. Trying to mitigate the footguns and you're aware of it, like, you know, they'll make it harder to make an accident. That, uh, I guess actually a question of this is that appears a lot on like the SNARC

DSLs is that, uh, like, how much do you expose like snark optimizations, like, uh, in the language? Like, do you just, uh, just what the big ones like non-determinism or like, if I know the answer to an if statement, do I just, how can I use that instead of computing the answer? But I guess in your case, it's actually a lot more, like with all the turbo plonk and lookup tablework. So is a general approach that you want to hide this complexity, or you want to give it as available to advanced developers? The first step is to hide it all the way, because it produces a simpler language. We can then move from that to the next phase, which is to gradually expose some of the inner workings to advance developers who want to play around with it.

The approach that we're currently taking is in-house we're writing for the common algorithms that people use SNARCs for. So, you know, things like binary arithmetic, inch arithmetic, you know, hashing algorithms, elliptic curve arithmetic, digital signatures, that kind of thing. We're writing our own highly efficient optimized gadgets that use the latest plonk and lookup table techniques that have a very, very small number of constraints. And then those are getting exposed in the language as primitive upcodes. know, like in Noir, you can do a shardt 56 hash of a string, and that Sharkey 556 call will go be piped directly into our optimized widget. And so that's kind of how we're abstracting with the complexity, by giving people these common building blocks that are already pre-optimized.

And the idea is then that all of the complex heavy lifting is done by our optimized widgets, and what's actually programmed in noir is close to blue logic that ties these components together. Oh, cool. That makes sense. Then, like, yeah, hiding this complexity by you building the expensive components that people are tempted to rewrite themselves. Yeah, we saw it a lot. And then a lot of projects kind of would have their own hash implementations. And kind of it's everyone doing the same work. And having a reference implementation, I think longer term is definitely the right approach here.

But it needs to be open source. It needs to be kind of reviewed by everyone. And we're getting to that step for it to be kind of, trusted. So what's your call to action to our audience and where can people find you? Yeah, I think right now if you want to do private transactions, head to at ZK.money. And over the coming six, eight weeks, we'll be upgrading the UI to enable you to do all of your favorite devine interactions with strong privacy guarantees. So we're looking for kind of feedback on the early version of that over the coming months. And for developers,

We've also got a test net. If you're keen to write out your own DeFi bridge contracts, then head over to our Discord. We put links in the description after. And we can kind of provide you with some docs to help build some of these DeFi bridges to make these private interactions possible. Yeah, you'll be curious and I could decide,

you know, head to our Discord, head to our GitHub. Check out Noir, play around with it. We're always searching for more feedback. Well, thanks a lot for coming on. We'll look forward to having you guys on again at some point in the future to dive deeper into how things are progressing. Thanks a lot. It's been a pleasure. Thank you very much for having us.

It's been great. And Dave, congratulations on your first interview. How did you like it? Thanks. It was really fun. I mean, aspect is one of my favorite projects. It was very cool to learn about more of the details of how they're getting privacy and youth right now. It's fun being on the side of a podcast.

Yeah, well, you did an excellent job, so we'll hopefully be able to do this many more times. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the news. letter. So you get new episodes in your inbox as they're released. If you want to interact with us,

guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.