Aztec Protocol – Bringing Scalable Privacy to DeFi

Sebastien: Since the last time we had you on, how’s the company grown and what’s been the evolution of Aztec in last year or?

Zac: Quite a lot has happened in the last year. I believe the last time we chatted, we just published our latest cryptography research PLONK. Since then, we’ve put that 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 privately. That’s been the main focus of the company for the last year. Now that’s done, we’re moving on to bigger and slightly more ambitious things that we yeah, happy to dig into as well.

Sebastien: Last time you were on, we talked a lot about how the shielded transactions contract worked and how that works for the user and also under the hood. We did talk about DeFi a little bit, and that looking at what you guys are doing now, that’s definitely more on your radar. How has the growth in DeFi in last year or like help shift your focus? Was it an accelerator in shifting your focus more towards DeFi or were you already on that track? Tell us about that journey.

Joe: Definitely the explosive growth of DeFi really shifted our focus from focusing on more Web Two use cases and it’s created a market for privacy on Web Three. When DeFi was only low tens or hundreds of millions, that wasn’t that much of a need for privacy. Now we’re in the fifty to a hundred billion of market capital locked inside DeFi. There’s a huge need for privacy there, it’s definitely shifted our focus and the product offering as well. The network’s capabilities to focus pretty much entirely on DeFi with the upcoming release.

Sebastien: Cool. For people who are not familiar with Aztec, give us the high-level overview of what you guys are working on and we can go from there.

Zac: This Aztec is a state-of-the-art cryptography to enable users to hide their identity when transacting on Ethereum. Right now, one of the main, we believe one of the main problems with transacting on blockchains is the fact that everything is public. Which means that’s everything you do, every transaction that you make is viewable by the entire world. Now this isn’t a necessarily much of a problem and people that are just dumping 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 the settlements 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, 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 steadily building our technology and architecture to support more and more use cases.

Sebastien: What use cases does this open up, because shielded transactions are cool and there’s lots of people working on that. Recently we had Tornado cash, although they’ve got like a quite different approach, but what does a zero knowledge like a zk roll up effectively? What does that enable in terms of new types of use cases?

Joe: This culminated in March with the release of Zk money and Zk money is the front end on top of zk-rollup. It enables for the first time an Ethereum transaction to exist fully privately. You have ironclad privacy guarantees very similar to the Zcash protocol. The circuits use a similar underlying 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 being on Ethereum, and being in a world where lots of people are building applications. You can have your cake and eat it to speak. You can have privacy, but on the chain, where there’s the most developer activity.

Zac: I can expand that a bit as well, with regards to the zk-zk rollup. At the core of approaching this action is the idea that instead of sending to the blockchain like the basic information about your transaction who you are, who you’re sending crypto to. Instead, you send a zero-knowledge proof. Basically, you say here’s my old encrypted balance and here’s my new encrypted balance. I can prove to you mathematically that I followed the rules of the blockchain.

I’ve deducted something from my balance and added it to somebody else’s balance, but I’m not going to tell you who I am, who I’m sending my money to, or how much my money was. However, zero knowledge proofs are very computationally expensive to check. Requires a lot of niche cryptographic operations, which means that it costs a lot of gas. The question, one of the questions is how do you get cheap transactions on Ethereum?

For us, the question is how to get cheap private transactions on Ethereum. The solution is a bit of inception-esque but you go one level deeper instead of sending zero-knowledge proofs to the blockchain, which represents private transactions. You create a zero-knowledge proof, which proves the correctness of a large number of a zero knowledge proofs.

It allows you to send one 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’ve taken to calling it a private roll up because it rolls off the tongue a little easier.

Dev: 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?

Zac: Exactly. Correct. It means that the entity creating that meta mega zero knowledge proof doesn’t need to know any secret special information.

Dev: Isn’t this process like starts to be really expensive. How does this being done or how was like this aggregator, a sequencer being able to do it without a high fees?

Zac: Well, that’s been, that’s the question and 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 criticisms to get there. Specifically, we needed to create a zero-knowledge proving system that was fast enough that you could make these gargantuan proofs.

Because yeah, generally, if you want to create a zero-knowledge proof of a computation, the act of making that proof is going to be about a hundred thousand to a million times slower than the original pre-construction. Actually verifying zero-knowledge proofs inside zero knowledge proof is one of these computation <inaudible>. One of the, one of the advantages that we have is as a company is, our chief scientist, is Ariel Gabizon.

Zac: He’s one of the best in the, one of the best cryptographers in the industry, and together we’ve not just published the PLONK cryptosystem, which was one of the, which is one of the extremely fast Zk Snark, but we’ve been able to modify and update and mould our probing system to engineer it, to be tailored towards our specific needs.

That meant that we have a lot of agencies to make the preview system particularly good for things like verifying zero-knowledge proofs and doing quite advanced difficult computations. That’s really why we’ve been able to create this construction on Ethereum. I believe currently that’s the only one that’s actually viable on the Ethereum blockchain given the limited cryptography, you can do it inside a smart contract.

Dev: Super cool. I’ve definitely been following the story of Plonk. I remember when the paper first came out, I made like such huge waves during a Snark temper of that year. What’s the story of the name PLONK it’s such an interesting name?

Zac: Interesting is one way of putting it. Yeah. Originally it was a placeholder name. Ariel and I was struggling to come up with a decent name for the paper. I suggested Plonk as a bit of a laugh, partially because as you said, it was this month’s Snark temper. Over the last few months, in that year 2019, quite a lot of seminal cryptography papers have been released.

One of them had like ambitious names like powerful names, things like Sonic, Darks and Starks and Merlin and I just, I felt like it would be, basically I thought it’d be funny to name it Plonk, it’s British slang for cheap, low-quality wine.

And I feel like there’s a lot of similarity because getting to the bottom of Plonk requires making questionable life choices, that a bit like real Plonk and it gives you a headache if you spend too much time with it. Basically, we call the Plonk, we published the e-prints.

Generally, e-print takes like a week or like a website that is a repository of cryptography papers generally takes about a week or to approve a paper for release. We thought, let us publish it now deal with the name later. But they publish this one overnight.

Then people started tweeting about it and saying, hey, what’s this Plonk thing. Basically, the word got out about it. We figured it was a bit too late to change it. It was funny. Here we are today.

Sebastien: But it got like backwards name right there because.

Zac: Oh yes. One of the only useful, not useful. One of the main skills that I picked up from a degree in particle physics was elaborately named acronyms that stands for permutations over the LaGrange base. That’s the P and the L for ecumenical, would mean all the encompassing, noninteractive arguments of knowledge and the A is silent.

That’s great.

Dev: I love it. I hope we can push for Snarks as a word instead of Starks. I don’t know if we’ve lost this one though.

Zac: It’s, it would be nice, wouldn’t it? Yeah. We’ve got a few years of inertia to push back against, unfortunately.

Sebastien: 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 privacy in DeFi, and you mentioned that privacy makes DeFi paranoid, and the way you described that is by using a maker as an example. Could you elaborate on what you meant there and how privacy technologies break certain applications in DeFi?

Zac: Absolutely. One of the questions which is relevant when it comes to private transactions is how on the basis do you make a private DeFi protocol? Because it’d be really nice to have a private version of Maker, you can make a CDP and nobody knows how much it is.

It would be nice to do things like have a private, 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 very public state invariably leaks information about what you’re doing.

For example, things like Uniswap. For Uniswap, you need to understand the total supply, you have a bit of an asset to perform to establish liquidity you have. If you deposit into a liquidity pool, then you’re changing the total amount of liquidity. That’s public variable. People can see what you’ve deposited. That’s not private.

Similarly, for MakerDAO you create a collateralized debt position. That’s private. That means it’s encrypted. How in the blazers is anybody supposed to figure out if you’re becoming under-collateralized. And if they are, how they’re supposed to liquidate your position, because it’s encrypted only the CDP creator knows how to decrypt it, and they’re not going to help you liquidate their position.

That’s one of the fundamental problems with privacy and the paranoid comes from, for example, you could create a private MakerDAO where you have a CDP where the CDP creator has to constantly send effectively proofs of life. They have to continuously prove that their CDP is over collateralized. Because then any person can create these proofs.

If they don’t save the proof, there’s proof of life in like a day or two, then they get then there’s something bad happens to their position. 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 DeFi.

The holy grail solution is to use multiparty computations, where, for example, if you want it, 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 will have their own orders and prices that are all encrypted, and they slowly engage in these NPCs with one another to drip feed information about their orders, to counter parties that have matching orders.

In aggregate you can achieve very high-quality priority with these kinds of approaches. However, the complexity of these approaches is absolutely enormous. We know we’re near the point today, where you can bootstrap these kinds of protocols. There’s hardly anybody in the world who can develop them to be efficient enough to work.

You don’t, you don’t have that mass appeal that you have with Ethereum where anyone can code up a smart contract. But we do have a much simpler solution for privacy when it comes to DeFi, which we could expand on if that would be, I don’t want to pre-empt any questions there.

Sebastien: Please. Go ahead. Explain.

Zac: How do you get private DeFi? Well, the simple answer is, you don’t. Basically, you keep the DeFi protocols public. Uniswap, MakerDAO, you leave them where they are. Hanging out on layer one. Completely public. Everyone can see what’s going on. What you do is you make the assets private.

You ensure that individuals have their holdings of various cryptocurrencies is anonymous. If, for example, let’s consider the, make it our position again. Imagine make this public you can see when a CDP is created. You can see its value, you can see when it gets liquidated. But you don’t know who holds it.

That’s very high-quality privacy, because of that it could be anybody. The most important thing, isn’t an operating to make the DeFi protocols private. It’s not to make this effectively like the sites, which interact with the value private. The important things to make the value holders private, and give them anonymity. That’s how we’re planning on doing on achieving privacy.

Dev: It’s like you have you hide all the addresses, then you publicly, when you do a trade, it’s what’s public is that this amount is going from some address that has some, the right thing, does public action. It goes back to a new like.

Zac: Exactly. Yeah. You can see how you can see 10, for example 10 Eth has gone from address question mark question mark has gone into Uniswap, that’s going back to address question mark question mark. That quite, we think quite effectively solves the problem. These protocols can still exist in all of the magnificent complexity without having to rewrite themselves to be private, but you still get the benefits of privacy that users care about.

Joe: I’ve got an analogy if it would be helpful for the listeners. Internally, we call it the DeFi bus. You see that the Aztec roll up contractors being like a bus station. There’s all these buses that have tinted windows, and you can see the front of the bus that says,

I’m going to Uniswap to swap Eth DAI and people can get on the bus and you can’t see who’s getting on the bus, but it will go to Uniswap, take the Eth to Uniswap and it will bring back a load of DAI on the return journey of the bus and give it back to the users in the Aztec network.

Joe: It’s a good analogy for showing how this network interacts with the rest of the DeFi ecosystem and whilst giving strong privacy guarantees to everyone who’s on that bus or in that transaction.

Sebastien: From a user perspective, I just want to, 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 Dai. 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 DAI 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?

Joe: It’s a bit more, it’s a bit if you did a direct deposit like that in the same transaction, that would be a way to link your layer one address to that trade. But the flow actually is a bit more, it’s got one more step. Users have funds already on the Aztec network, they’re already shielded. You would have in a separate transaction you would take your Eth, and you’d make it zk Eth and then you have these encrypted UTXO notes on Aztec.

And you can use those to interact with any L1 smart contract through our DFO bridge. As in this case, you’ll choose interact with the Uniswap Eth dipole. You send a transaction that says, I want to put one Eth into the next bus going to that pool. The owner of that Eth could be anyone who’s ever deposited Eth to the Aztec smart contract.

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. Say Zac also wants to trade to ETH. A few other people are also getting on the bus.

We’ll send an aggregate then transaction from the roll-up contract out to Uniswap say five Eth in total, and we’ll bring back Dai to the Aztec roll-up contract. That will then be dispersed in zero knowledge notes to the holders who participated in that transaction.

You’re actually not getting the proceeds of the DFO interaction on layer one, you’re getting it in encrypted form on layer two, which is how the strong privacy guarantees maintain through that.

It’s quite an interesting way of doing it and Zac 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.

Sebastien: Okay. It uses the same note system as like the previous version. That’s what I missed.

Joe: The new systems actually not graded form because the old Aztec just had confidential notes. Here both the balance and the owner is encrypted. That’s what gives us the anonymity we need to do these transactions.

Dev: How is this looking like from a user perspective? Right now, as a connect bed and masking yourself sub site and just press a button to do a transaction. Is it still pretty similar where on like the Aztec site, there’s still way back to my wallet and just do the trade that do the transaction, does all the three steps go to L1, swap and go back to L2?

Joe: We have a we call it zk money and it’s like a showcase of what’s possible with the Aztec SDK. In the next three months, the main venue for these trades will be zk money and you’ll be able to connect Metamask. It will show you either if you have on layer one or if you’ve already used the Aztec network.

It will show you zk Eth and you’ll be able to do these various different interactions. All of that will be abstructed from the user via SDK. The three to six months goal is the SDKs integrated on a lot of these L1 front-end protocols. You can actually just go directly to Uniswap or Aave or some of those protocols and perform, have the option to perform interaction privately.

Dev: Very cool. I feel like this general approach is the future of practical privacy for DeFi things. It’s often, if you want public information constant product market makers or cost function, then you have to have the swaps in public.

Joe: 100 % yeah, it’s the best of both worlds because you get to the transparency of layer one DeFi, which is what’s made it grow to be popular, but you also don’t have to sacrifice what a lot of people take for granted in the Web Two world is just basic transaction privacy. No one can see my Robin Hood account, no one can see my Revolut accounts. This allows new types of user experiences that give you the best of, L1 DeFi but also strong user privacy guarantees.

Sebastien: Sorry. I just want to stay on this DeFi topic a bit. In that case, then you need to create a, a Uniswap would need to add a like Aztec Eth, Aztec Dai pair, I suppose. If you wanted to trade those assets?

Zac: That’s one of the key parts of our approach is that, we’re looking at the evolving layer two landscape. Right now, the impetus is on having strict liquidity. Because if you want to benefit from the fee reductions that you get from what operating on layer two, you’ve got to move to the actual DeFi protocol into the layer two.

It has its own currency pool that has its own liquid asset pairings, et cetera. For us, we felt we wanted it to be very much felt like what users want is to leave the actual source of <inaudible> in layer one, because that’s where they’re going to get the best prices, but interact with it cheaply.

So even if you have shielded Aztec assets and you’re using our DFO bridge to interact with the layer L1 smart contract like Uniswap, you’re still talking to the Uniswap layer one liquidity pool. The Eth to Dai pairing that you’re getting and the associated price.

It’s still based around the global Uniswap pool. In order to perform an integration with Aztec, you need some facility ability to shield user funds using the Aztec network, but that wouldn’t materially affect the price that they’re getting from using our protocol.

Sebastien: Okay. Interesting. What about collateralization? How would collateralization work using Aztec? For CDPs Do you mean? Yeah like make like a CDP, for example?

Joe: It’s there’s two, there’s two methods really, you can have, Zac 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 could have tier CDPs.

You can have a system where we all agree with a hundred other users that we want to enter into a three-month term CDP and the LTV ratios can be kept at a certain amount. Then everyone’s doing the same thing. You can get pretty strong gas savings as well as privacy savings from doing that.

It depends on the end user product. We’re starting to see a lot more fixed rate protocols come online in DeFi. That’s why the retail users will end up is on more structured products rather than a wildly swinging pools. That’s the approach that we take with collateralization of blends.

Dev: Sorry, I didn’t quite follow. Are you imagining that the collateral is held, can just like one big collateral pool held by the contract or imagine that there’s some out of a, and then like my share of the pool was private, but handled on the roll-up side?

Joe: You could have like a Aztec Q4 Eth CDP and you could have different clatterization ratios. This will be the 150% clatterization ratio. We’d all enter on a certain date and it would be a three-month term and that will be one approach to doing it.

Then 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 the case where if you’re a large user and you don’t mind paying the L1 gas fees yourself, you can just have free flexibility by entering in 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. You’ll be able to have your transaction batched with other zero knowledge Snarks that are doing different things that you would pay the full cost of the entering the CDP position. You get a bit of scaling in terms of privacy.

Dev: Oh, it’s still fine to hold the collateral in this. I’m sorry. You have the loaned amount being it’s private. Aztec L2, but just collateral has got to be on chains since you need liquidations to be able to see it, or?

Joe: In that case, it would be, in a single user case, it would be like a smart contract within the position. That’s smart contract would be like crate to opcode you would have a new smart contract for every CDP that was created, whether it was just one user behind that CDP. Just the source of funds that do the initial clatterization are coming from the Aztec network, not from a tainted L1 address.

Dev: Very cool. On this privacy idea, I remember like Zcash there’s a problem of people would go from the transparent pool into the shielded pool. Then it almost immediately go from shielded pool back to transparent. Or in this case, it’d be like shielded pool to a Uniswap trade, the exact same balance. How are you thinking of mitigating the linkability there just exact amounts? If you use the full amount.

Zac: It’s a big problem. It’s partially of it’s an educational issue and part of it as a UX and design issue, because of the, this privacy tech is relatively new. A lot of users don’t fully understand how it works and that you but effectively you buy when you shield your tokens, the activity of the depositing into the shielded pool is public.

They can see for example, that Dev put 10 Eth into Aztec, and then, and if you then immediately withdraw, it’s very easy. What’s happened if you see Dev deposited ten Eth into Aztec and then in the next block, draws 10 Eth from Aztec, it’s obvious.

What you really need 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 10 Eth.

The way it would ideally work if you for an educated user is you deposit 10 Eth into Aztec, you wait a few hours and then to a different address, you withdraw the 10 Eth in Aztec. That 10 Eth could come from anybody who like from now to the dawn of the pros to start the protocol deposited 10 Eth into Aztec or acquire 10 Eth within the Aztec network somehow perhaps through DeFi.

But most of it is just making sure in the user interface that the user is informed of what they’re doing. That if they’re, if they do this for you, immediate deposit and withdrawal, and the UI goes hey, you sure you want to do this and Joe, you can expand on that a bit.

Joe: There’s a few cases, but we’re touting this idea of a privacy score. Just really helping to inform the user of how private a transaction that we’re about to do is, and Zac was saying that it can be anything from, hey, you’re unshielding to the same address you deposited from that’s not private, or there’s a higher linkability risk there, or things like if you’re unshielding to a very large, significant number of decimal places.

Then that’s also can add the linkability of those transactions. The great thing about the DFO bridge. It doesn’t fix all of these things, but it’s the first step in the road is that privacy starts to become by default, not opt-in. That 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 has been more expensive. It’s always been, the incentives is to get out of the privacy shield. What we’re trying to do with the next couple of versions of Aztec is change that, flip it on its head that users should be comfortable keeping their funds in the Aztec network.

Then those kinds of opportunities for a privacy breach should become a bit more reduced, but you still have to be a bit careful when you’re interacting with the DFO bridge. If you deposit, I don’t know 90% of one token to the Aztec network and then there’s a DFO bridge trade for 90% of that token, you can start to figure out what’s happening.

Why the DFO bridge comes into a zone is if you have smaller trades that are drip fed into the market over time. If that trade is pretty homogeneous compared to the normal size of a transaction on the network for that asset pair, you have great privacy. That’s what the UI will enforce and try to guide the user around with a privacy score.

Dev: Oh, that’s very cool. You’re like detecting these cases where you think it’s easy to link back and then giving a warning right then and saying, look, this transaction is likely linkable. Maybe you want to break it up or wait some more time?

Joe: Yes. That’s the idea. On day one, it may be just like one of those password indicators. That’s like strong, weak, or extra strong, but we’re working on the metrics to put into it right now. 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 Two world because you have privacy from everyone except your service provider, but in a Web Three world, there are these different cases where you do need to be notified and users have to accept different norms.

It’s on dapps 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.

Dev: Very cool. there’s also thing where the amount of warnings you get really goes down over time as more assets or more historical records are there to be selecting from?

Joe: Definitely yeah. As the privacy set grows, you should see less and less warnings. Yeah, the network effect around privacy in the Aztec network grow stronger. Also the amount of times you want to leave the Aztec network would also shrink. You should have less of these opportunities to accidentally break a privacy.

We can talk a bit more about like how we get past DeFi and the longer term goal and that would explain a bit more about how Noir fits into all of this and how long-term we think a lot of, lot more applications will happen within the network. There’ll be less and less chances for those privacy breaches.

Dev: Sure. Guess John, talk about how you’re imagining Noir, and more privacy or more applications on the private side.

Zac: Yeah, this DFO bridge thing we’re building is merely the stepping stone to our grander aspirations. It’s an architecture that we’re calling like the working title is Aztec three. With what we released in March, you can shield cryptocurrencies, you can still run privately in a unilateral way.

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 DFO bridge comes in. Even that only 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.

Many applications and for example, traditional finance or payments, or like the use cases that everyday individuals require strong user privacy guarantees. What we do you want to do is effectively recreate the Ethereum smart contract ecosystem insight Aztec, but where privacy is preserved.

That to give developers, engineers, users, the ability to write their own smart contracts that have privacy baked into the core. 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, 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 cryptocurrency 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 can have an identity token that you can have some cryptocurrency that’s conditioned that’s holding a conditional having one of these identity tokens, or even it’s more, it also opens up like more other innovative spaces for example.

Private NFTs where you can have some data fields that are private, but you can like prove parts about your private NFT to other people under certain conditions. You can have, it opens up a whole innovative tranche of blockchain based games where you can actually have information asymmetry.

The players of the game actually can not know things about their counterparts, which isn’t really the case with a fully transparent setting. 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.

That’s where Noir and Aztec 3 comes in. Noir is our highly efficiency. It’s not programming language headed by Kev. It’s a rust-based syntax language that compiles directly to highly optimized Plonk circuits.

We’re planning on using that in the next iteration of our protocol design, where instead of our zk rollup verifying the same transaction type over and over again, this private transaction instead what, the roll-up verifies is a zero-knowledge proof that’s over, gets come from one of these circuits that’s been written in law and uploaded into our network by anybody.

Basically it’s the keystone technology, which allows us to create a fully permissionless, private programmable cryptocurrency network. That’s pretty much once we’ve put out the DFO bridge that’s where we’re heading with all our energy and attention and resources.

Dev: Well, very cool. I want to unpack it. This is that there’s a bunch of components there. For the programmability idea is I want to be able to put my, is it like the zekc model where 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 Aztec chain that users can interact with in a private manner where this, the contract can maintain both the public state and private states and every interaction just updates both of these?

Zac: Yes, exactly. Where 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. It to eight familiar blockchain concepts. You have a when your equations actually have a concept of a cool stacking of contracts. I can quote all the contracts.

You can have one contract with multiple functions and you can have reasonably like somewhat arbitrary transaction depths. You can have contract pass people, calling contractors calling other contracts over and over again. You don’t have some of the restrictions that’s other systems have because of the, their restrictions come down to the fact that the protocol was designed for this limited recursion technology that was available at the time.

Things have moved along a bit like a bit like there’s been a lot of development on these like cycles of elliptic curves with this halo recursive system, with the stuff <inaudible> which means you can have this arbitrary depth recursion where you can have zk verifies, <inaudible> all the way down.

This enables, it enables your zk Snarks circuit to encode an algorithm that starts to look a lot like a VM based cryptocurrency protocol, where you don’t have to, learn new and different types of transaction semantics in order to program it.

Dev: Oh, cool. It’s like starting to look more base layer Eth where it’s solving the whole problem of I could really only interact with one contract or like a small set in one transaction, because there’s limited proven tech for certain curves. Now you’re saying, with the Aztec unbound recursion, this is fixed, you can now.

Zac: In theory, I’m going to throw my hands, okay. We’ve not built it yet. That the mission for our company is putting this in practice over the next 12 months.

Dev: Maybe this is a bit technical for folks, but, how does the proving work here where essentially you’re having, suppose you want multiple transactions interacting in the same contract per block, but they all affect state. Do you have some, out off-chain aggregator 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 per block?

Zac: It’s a good question, because you run into some-called like race conditions when you’re dealing with these off-chain aggregation services, particularly with private, with when protecting privacy. Where if you have multiple individuals who wants to talk to the same contract they’re effectively modifying the same database.

You can get into problems with lots of people, it’s a bit like lost people wrestling over the same, over a single piece of cake and going, 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.

That’s when individuals send transactions to aggregator, they request state updates to be made on their behalf. If they’re private, then they’ll be encrypted but if they are public, they won’t be. It’s actually the aggregator who’s doing the mechanical process of putting these variables inside the database modifying those database values. Yeah, at this point it’s a relatively solved problem.

Dev: Okay. It’s not really a privacy leak in that the aggregator already accessed the private database, the private state. That’s, there’s no new information they’re getting.

Zac: Exactly there if you’re basically, when you create little privacy proof that proof will spit out a bunch of variables, but they’re all encrypted. Those variables need to be added into a database, but the aggregation doesn’t have, it doesn’t know anything about those there’s variables, to them, they just look like random numbers.

Dev: Oh, they don’t need to know these random, the actual data entries to handle state conflicts?

Zac: Well, the idea is basically you don’t, you don’t have a state conflict this may be getting into the weeds, but I’m dealing with private state and public states. They need to be treated differently.

With private, the way that the way one handles private state modifications is using this Bitcoin unspent transaction object (UTXO), the idea is instead of having an account where you have like something like a balance, which you can modify over time, you instead have these notes that cannot be created or destroyed.

This makes the state model quite simple, because a note can either exists or doesn’t exist. It can’t change value. If you want to perform a state update as a user, you want to create some private state variables.

You want to create a bunch of these UTXO notes and you want to delete a bunch of existing UTXO notes. Basically, you go to aggregation, you go hey, I want to make these UTXO notes. I want to delete this, these other like UTXO notes.

The key thing here is that they’re all encrypted. The notes will be created unencrypted and the notes you’re destroying, they’re encrypted too, but they’re encrypted, but this is really getting used to be the reason, maybe it’s, I’m going to struggle to explain this properly in the time we have available.

The idea is when you want to destroy a note in Aztec, the way we record of it being destroyed, uses a different encryption algorithm to the way that we record a note being created.

Basically, the mark on our ledger which says a note has been destroyed, uses a different encryption algorithm to the mark on our ledger which says a note has been created. You can’t ever link it like a destroying notification to recreate notification.

Dev: Oh Cool. It’s, you’re making everyone has to do UTXOs. These private contracts define like validity predicates 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.

Zac: Yeah exactly. It’s a very, it’s extremely similar to how Zcash handled it. They were very much trailblazers on this with this regards.

Dev: Cool. Okay. Then Noirs spinning into this by making this DSL for folks to be able to write these contracts that are in this UTXO model and compile to programs.

Zac: Exactly. Noirs going to have quite a lot of layers to it because the first thing that Noir needs to solve is that these programs that people are creating need to be turned into extremely efficient zero-knowledge proofs.

One of the main problems with zero-knowledge proof cryptography is constructing these proofs is generally quite slow, as I said, it’s like a factor of a 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. A lot of scaling solutions that don’t, that aren’t private take this approach because it’s a bit of a no brainer it’s hardcopy issued we’ll just send it off to 132 AWS machines.

Then you’ll get it done in a few seconds. But because we’re dealing with private transactions, you can’t delegate pre-construction for third party because then you’re leaking information secrets to that third party.

Effectively all of these programs that are being created in Noir, they’re also being turned to zero knowledge proofs set where the pre-construction is happening, be made directly by the user by people with old laptops, crummy phones.

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 advanced with our cooling systems.

Then but then you’ve also got to make this the user program, which means you’ve got to have the abstract smart contract semantics, state modification semantics, and all of that associated paraphernalia. That’s easy to understand to the user.

That to be complete transparent, that is still very much a work in progress. I’m not going to, I’m not going to be arrogant enough to say we solved that problem yet but I have every confidence we will it.

Joe: The first step is abstracting the cryptography from the developer. Then the second step is baking in more functionality and that’s where the bit we’re working on. At the moment you can use lot to just write a Snark circuit, but it doesn’t really fit in with the rest of the Aztec roll up ecosystem.

That’s the next focus of the company, post DFO bridge is to build that part of things. The actual language early syntaxes is written where we’re actively getting feedback on it right now as a new way to write Snark or Plonk circuits.

Sebastien: How important is it all this to its broader adoption of zero knowledge technologies in and outside of crypto, or like privacy preserving technologies. If you take the average web developer, or even iPhone developer or whatever, a lot of these developers have very little understanding of how a zero knowledge technologies work and how to implement them. How important you think this work is to broadening the scope of use cases for zero knowledge tech?

Zac: It’s foundational. We just have to, we ask just look at why Ethereum became successful. It was because anyone could write a smart contract. You had this incredibly powerful technology, this distributed ledger that wasn’t this incredibly difficult concept to wrap your head around it and difficult to interact with.

Instead, it went from that to going like here’s how you make a cryptocurrency token in three lines of code or however many it was. It was very easy to access. It’s absolutely essential to propagate zero knowledge proofs and this 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, people, most people are probably say quite rightly like incredibly intimidated by this cryptography.

There’s the common analogy – don’t roll your own crypto, don’t roll your own crypto. It’ll end badly. I see it as a cryptographer. Creating an abstraction layer, which presents very complicated crypto systems, as easy as some programming languages with clearly understandable semantics.

Whatever you produce, the cryptography behind it will be sound and secure is absolutely essential for the wide scale adoption of this technology.

Sebastien: Hmm. What are the risks here, because we’ve seen in crypto that the bugs can be catastrophic. We’ve also seen, the cascading effects of layers upon layers of dependencies breaking large scale applications on the web recently with like all this NPM stuff happening around there.

For a developer. I’m speaking mostly like developers outside of crypto, but even the people coming into crypto and who are like some background of development, how do we ensure that they use cryptography responsibly and that they’re using the right, that’s using libraries that are vetted and audited?

Even if they’re developing at a higher level of abstraction, but that someone doesn’t use a cryptography library and to build, I don’t know, some messaging app, for example, and exposes everyone’s messages or like something catastrophic like this. What’s the right balance of expertise to general availability or that we’re looking for here?

Zac: It’s a good question. I’m not sure it’s one with a particularly easy answer, because the risks are real. I’m not going to try and trivialize what we’re doing here. The complexity, the amount of complexity involved in these advanced crypto systems is absolutely astronomical.

Then you add on the complexity of a very complicated systems, level architecture that someone’s building using tools that have been developed to turn it into a zero-knowledge proof. Then there are certainly risks there. That that it’s going to be an evolving process. I do think that it’s obviously there are some basic things you can do.

You can make sure that at every layer of your technology stack has been fully audited and that has been written by the people who are the experts in their fields like we’re very lucky in Aztec to have Ariel Gabizon is to be able to help us with like internal audit switch to be honest, before we released that.

Our primaral didn’t reveal, several security issues that were resolved because this is complicated leading a stuff and it’s very easy to get it wrong.

Zac: I do think there’s going to have to be a period of time where once these kinds of these advanced abstraction layers, these programming languages start to become easy to use and more widespread, that they will need to be approached with caution.

We seen with the adoption of Ethereum, sometimes the only cure is time. Right? Like a lot of, I don’t think I’m being unfair when I say that the solidity smart contract is widely considered to be somewhat insecure.

If you’re going to rewrite a three molar bring it from scratch, you would design slightly in a very different way to make it a lot more secured program. But obviously back in 2015, Gabizon will be doing this for the first time. It’s, people are aware of the issues that would result.

That being said today in 2021, I would argue that if you’re going to write a smart contract, Solidity is the best language to write it in because it’s been battle tested.

These bugs, these exploits, these problems that have been found out, unfortunately, sometimes through hacks and attacks, but it means that you have this large anthology of security practices and principles to draw on. Now, we don’t have those for zk Snark programming languages because they’re completely new in their infancy. That book will have to be written.

There’s a question about like how many, 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 on how these systems 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.

It’s something that’s very much one our mind, but the only thing you could do is order everything, developing things thoroughly, maybe very considerate about the 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 cryptography we’re developing like who can audit advanced ultra Plonk circuits. 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. It’s one of these issues that can only really be solved with time and attention.

Joe: I can have one thing as well. It’s about the amount of the protocol for if you take the iPhone developer example, how much of what that building needs to be in Noir and requires those like fundamental privacy guarantees.

How much of it is can be written at layer one in terms of just written in Solidity and it’s about assembling that stack of that, different languages and different pieces of technology to get the end product that the users need.

Trying to do that all on day one would probably lead to a lot of catastrophic bugs, but doing bits of that in Noir to give the privacy that’s required bits of its Solidity, bits of it don’t need to be on-chain.

There’s a lot of learnings in the space generally from 2017 where people were planning on 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.

It’s about careful design of what needs to live where in the stack, and that will evolve over time. More things will be in the private end. That’s all that, but it’s about making sure the right things are in the right place to do damage limitation in case something does go wrong.

Dev: Oh, cool. Trying to mitigate the foot guns that you’re aware of they’ll make it harder to make an accident that, actually a question this appears a lot like the Snark DSLs, is that, how much do you expose like Snark optimizations in the language?

Just want the big ones like non-determinism or, if I know the answer to an if statement, how can I use that instead of computing to answer? In your case, it’s actually a lot more like with all of the terrible Plonk and look up table work. It’s a general approach that you want to hide this complexity, or you want to give it as available to like advanced developers?

Zac: The first step is to hide it all away, because it produces a simpler language. We can then move from that to the next phase, which is to gradually expose the, some of the inner workings to advanced developers as you want to play around with it.

The first that we’re currently taking is in-house, we were writing for the common algorithms that people use Snarks for. Things like binary arithmetic, insurance arithmetic, hashing algorithms, elliptic curve arithmetic, digital signatures, that thing.

We’re writing our own highly efficient optimized gadgets that use the latest Plonk and lookup table techniques that have a very small number of constraints. Then those are getting exposed in the language as primitive upgrades.

In Noir you can do a five six hash of a string and that effect is cool, will go be pumped directly into our optimized widget. That’s how we’re abstracting with the complexity, but giving people these common building blocks that are already pre-optimized.

The idea is then that the, all of the complex heavy lifting is done by optimized widgets. What’s actually promoted Noir is close to the logic that ties these components together.

Dev: Oh, cool. That makes sense. Then like hiding complexity by you building the expensive components that people are tempted to rewrite themselves.

Joe: Exactly. We sorted a lot. A lot of projects would have their own hashing permutations and it’s everyone doing the same work and having a reference implementation, longer term is definitely the right approach here. But it needs to be open resource, it needs to be reviewed by everyone and we’re getting to that step for it to be clustered.

Sebastien: What’s your call to action to our audience and where can people find you?

Joe: Right now, if you want to do private transactions, head to zk.money, and over the coming six eight weeks, we’ll be upgrading UI to enable you to do all of your favorite DeFi interactions with strong privacy guarantees. We’re looking for a feedback on the early version of that over the coming months.

And for developers, also, we’ve got a testnet that if you’re keen to write out your own DFO bridge contracts, then head over to our Discord. Put links in the description after, we can provide you with some docs to help build some of these DeFi bridges to make these private interactions possible.

Zac: It would be clear if you head towards our Discord, head towards GitHub. Check out Noir. Play around with it. We’re always searching for more feedback.

Sebastien: Well, thanks a lot for coming on, and we’ll look forward to having you guys on again, at some point in the future to dive deeper into how things are progressing.