Anna: Welcome to Zero Knowledge. I'm your host Anna Rose. In this podcast, we will be exploring the latest in Zero Knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. Anna: This week I chat with Zac and Joe from Aztec Protocol, the folks who recently released zk.money. We talk about this exciting new private zkRollup, or zk-zkRollup, and explore how this is built and what role it aims to take in the ecosystem. But before we start in, I want to share two quick notes. First, if you're looking to start working on zk tech, and you are a student, cryptographer, software developer, practitioner in blockchain or privacy tech, researcher, or engineer, or even if you're not working in the ecosystem yet, be sure to check out an upcoming event that I'm putting together called ZK Jobs Fair. This will be an online social event giving you the chance to connect with some of the coolest zk companies in the space. You can follow the Zero Knowledge Twitter account for more info, and be sure to apply today to get access to this event. It happens on April 22nd. I've added the link in the show notes. Hope to see you there. Anna: Secondly, I want to say a big thank you to this week's sponsor Aave. Aave is an open source decentralized non-custodial liquidity protocol on Ethereum. With Aave, users can participate as depositors, meaning they provide liquidity to earn a passive income. And they can also act as borrowers to borrow in an over-collateralized way or in an under-collateralized way. Think one block liquidity flash loans that we've discussed a few times on the show. Aave has also deployed a new market on Polygon sidechain to let users pay much lower gas fees. Assets could be transferred from Ethereum to the Polygon bridge and put to use on Aave's polygon markets. You can learn more about it in a blog post that I've shared in the show notes. And if you want to find out more about Aave, visit Aave.com. So thank you again, Aave. Anna: Now, here is my interview with the guys from Aztec. Anna: So today I'm chatting with Zac Williamson and Joe Andrews from Aztec. Hi, guys. Welcome to the show. Zac Williamson: Hi. Yeah, it's great to be on. Thanks for having us. Joe Andrews: Yeah, likewise. Very excited to be here. This is actually my first podcast. Anna: Ever? Joe Andrews: I think so. I've listened to a lot, so exciting. Anna: That's very cool. So yeah, Zac, you've already been on this show. I think this might be your third time coming on. Zac Williamson: Yeah, I think it is. I was on a while ago back when we just launched our first iteration of I guess what was zk.money, using a very different crypto protocol. A lot's changed since then. Anna: You also came on with Ariel last year to talk about PLONK. And it was very crypto heavy one. I'm going to add links to both of those in the show notes, I guess if people want to hear a bit of the history of this project. And Joe, as you mentioned, this is the first time you're on the show. Let's start with you actually. Why don't you introduce yourself? What are you doing at Aztec? What's your gig? Joe Andrews: Sure. Me and Zac originally met maybe three years ago now back on the Entrepreneur First accelerator program. And I guess my role at Aztec is trying to hide away all of the zero knowledge cryptography that Zac's been coming up with over the years and make it either user friendly or developer friendly. So really focused on, I guess, the go-to-market and putting this technology in the hands of everyday people, which is super exciting. Anna: Would you call yourself a product person? Joe Andrews: Yeah, I'd say so. I'm originally technical, but not to the same degree as Zac or Ariel. I put the cryptography in black boxes, and vaguely understand what each one does. But I can then wrangle that into hopefully a nice to use product. Anna: It's true that working in this space, the term "technical person" kind of changes. Like the level of technical you need to be considered a technical person definitely increases. Zac Williamson: Yeah. It's a bit weird. Because in a normal company, Joe would be considered an extremely technical person. It's just a different kind of technical. Anna: Yeah. Some people think I'm a technical person, but in my mind, I'm the podcaster. That's the level of technical that I get to be. But yeah, Zac, I want to hear from you, given that it's been over a year that you've been on the show. What's new? What's happening for you on the Aztec side? Zac Williamson: Yeah. What's new? A lot's changed. Last time I was on the show, Ariel and I were very excitedly happily talking about this cool new research project we'd published called PLONK, which is an extremely fast universal zkSNARK proving system. And since then, we've been building PLONK and actually implementing it, turning the paper into something real. And this has culminated in the launch of what we're calling zk.money. It's the world's first private rollup that we launched on Ethereum in March this year. So it's basically scalable private transactions run out of the Ethereum blockchain, which uses our state of the art proving system to combine both strong user privacy using zero knowledge proofs. So that's when you're performing cryptocurrency transactions, all the information is encrypted. But you can still prove that you followed the rules, that you're not double spending, et cetera, by setting a zero knowledge proof proving this. And we've also used our technology to do some scaling as well. So instead of sending these private transactions to a blockchain like Ethereum to be validated one by one, what we actually do is we aggregate a large number of private transactions inside a zkRollup. So we have a SNARK circuit, which verifies the correctness of a large number of other SNARK circuits. And what that allows us to do is basically just post on transaction to Ethereum that represents hundreds of transactions. Anna: Wild. I want to dig in on this, but before we do that, I want to follow the path from Aztec 1.0 To Aztec 2.0. Is that what you're calling it? Is it like Aztec Version 2 that is currently live? Joe Andrews: Yeah, I'd say so. There is an Aztec 3.0 In the works as well. So we could talk about that as well. But the current live version is Aztec 2.0. Anna: But Aztec 1.0... Going back to that really first episode that we had you on, there was this different zero knowledge proof construction. Have you thrown all that out, and now it's PLONK? Is that what replaced what was there, or is there other changes? Zac Williamson: Yeah. There are other changes. We've completely reworked the protocol and thrown out the old proving system. Aztec 1.0, I guess it was our first attempt at privacy on Ethereum. It feels like a long, long time ago, but I guess it was only about two and a half, three years. But back then, universal SNARKs weren't really a thing. If you wanted to take a general abstract program and turn it into zero knowledge proof, you needed to use SNARK constructions that required trust setups for every single program that you were writing. And for what we wanted to do, which was we wanted some level of programmability so that users could create their own private crypto assets and program how they get transferred around, we thought that this requirement to do all these sort of setups was a little bit untenable. So we were looking for workarounds. And so Aztec 1.0 was a zero knowledge proof which tried to solve some of those issues, but in a very different way to modern zkSNARKs. It was what's called a sigma protocol. It was quite an old-fashioned bit of tech, I guess, looking back. And it had a lot of compromises that we weren't happy with. That's why we started researching universal SNARKs. That's why Ariel and I put together PLONK. So once we had PLONK, basically that immediately obsoleted all of our old tech, so yeah, we've thrown it out. Anna: Cool. Joe Andrews: I think it's worth adding, even though we stopped supporting it publicly, it's had some resurgences, Aztec 1.0, in the private blockchain space. We don't really support it as a company, but it's been used by the Bank of Thailand for a pilot on CBDCs, which is really cool. And they basically just took it as is, as an unsupported piece of tech, to get a form of privacy on a private version of Ethereum, which was pretty cool to see that even the old world tech, as Zac's probably thinking about it these days, is still useful in some applications. Anna: I want to talk about PLONK and kind of the impact that PLONK had generally in the ecosystem. Because when you presented it last year, I remember Ariel and yourself, you were excited about this finding. And since then, what I've seen is so many more teams get excited about it. It's almost become maybe not the de facto, but a de facto for a lot of these teams, especially the new zk teams. What have you seen around that? Did you expect that? Are you excited? Zac Williamson: Yeah. We're really excited by it. Certainly, when Ariel and I put it together, we realized it solved a real need that we had. And we knew that other teams in the space had the same need, which is like we want a faster zkSNARK that doesn't need a ton of trust setups. But it still needs to be succinct. So you need to be able to efficiently verify proofs in an Ethereum smart contract. And we knew that really Plonk was the only thing that really fit the bill. I guess when we first published PLONK, we knew we were onto something good. We've worked a lot on it since then. So we've created another version which we call Turbo-PLONK, which has these things we're calling custom gates, which is really taking off. And our latest version using this lookup research we've been working on is called Ultra-PLONK. But yeah, it's amazing. It's really quite heartening to see it take off in this space and see the number of awesome projects using it. I think there are actual coin companies building PLONK-based things. Mina Protocol are using a variant of PLONK. Matter Labs are using PLONK. And many others which I'm forgetting. I think one of the reasons why it's taken off so much is because I think this is really the first zkSNARK proving system that was engineered. Because all of the other systems, they've come out of very academic contexts. So they have some trade-offs, which for use in industry make them a little bit less than ideal just because their designers had other priorities in mind when they were putting it together. But with PLONK, because we combined Ariel's deep theoretical crypto knowledge with some of my experience as a software engineer, and we really creatively solved some problems. But we actually want to write real world programs with this and put them on a blockchain. How do we actually mangle and mutate the mathematics to get this working in a way that you can engineer meaningful programs? I think that's one of the reasons why it's taking off because we're not the only team. Many other teams have the same problems we have regarding needing extremely fast SNARK proof constructions. Joe Andrews: I think it's also just great to see the amount of brain power that's collectively being poured into it is actually making it a bit more trusted as a technology base for the whole community. So if it was just an Aztec project still today, I think it'd be hard to convince people around its security guarantees. But now the underlying technology is pretty widely understood. That burden I think is shared. And there's a lot more community resources helping people understand the kind of really complex cryptography behind it. Anna: Another big finding I feel this year was the introduction of Halo but also this sort of formalization of what Halo does. Did that influence or is there any sort of impact on the way you're thinking about PLONK, given some of those new findings? Have you incorporated anything like that? Zac Williamson: We would like it to impact how we think about PLONK. Because Halo is really impressive and cool piece of tech. So this idea of proof aggregation is certainly something which is on our minds for future versions of PLONK, to see if we can jerry rig some version of it into what we're using. And certainly the PLONK proving system is really ideal to be adapted and to be used with this Halo-style recursion, because you can create all these custom gates, which make these very niche prime field operations, that Halo requires, efficient. Because we're working on Ethereum, we have some rather unusual constraints we're working under, which is that right now, Ethereum only really supports one elliptic curve that's pairing-friendly. It's going to support two in the future, BN254 and BLS12-381. But neither of these are particularly Halo-friendly. So the problem is if we implemented Halo as is, the verification gas costs would be hundreds of millions of gas, if not maybe tens of millions. But either way, a little bit too high for us. But yeah, if there were any protocol changes to make, Halo verifies practical on Ethereum. We'd jump to in a heartbeat, for sure. And there's certainly a lot of meat on the bone regarding proof aggregation that can be adapted by other Halo-like systems for sure. Anna: This is actually interesting. Because from what I understand you're saying is PLONK, vanilla PLONK, not on Ethereum, could already be used with some of these proof aggregation techniques alone. But because of the particular curves that are available on Ethereum, it becomes, I guess, just more expensive. You can do it, but it would be just not worth it. Zac Williamson: Exactly. Yeah. So we've had to use a different kind of way of doing recursion. Technically, formally, it is a proof aggregation scheme. But that's more semantics. Because basically with this private rollup we're doing, we do need this thing called "recursive proof composition". You need to basically create a zkSNARK circuit that can verify zkSNARK proofs, which is typically very hard to do. If you only have access to one elliptic curve, it's really hard to do. But that's one of the things that we really engineered PLONK to solve, particularly this version we call Turbo-PLONK. So the way that we do it is we take a brute force approach where if you want to verify a SNARK proof, you've got to do all this very complicated and expensive theoretical operations and prime field operations that aren't easy to do in a SNARK. And we can't just brute force it. PLONK is fast enough to get the job done regardless. We do do a little bit of proof aggregation. Basically, the PLONK proofing system, to verify a PLONK proof, you need to do elliptic curve by the new pairing. But if we're doing this recursively, we aggregate a bunch of PLONK proofs together. So we only ever end up doing one pairing. So it's got overlaps with Halo. But Halo has a much more elegant solution for how to verify proofs that unfortunately we can't really use because Ethereum only supports one curve. Anna: Got it. Recently, I think it was in a talk that I did with Justin Drake and Isaak Meckler from Mina. We talked about these three layers of the zk stack, PLONK kind of fitting in that middle layer, the IOP layer. What we're talking now is the aggregation layer, which is layer 3. But on the layer 1, on the polynomial commitment side, is that where what Ethereum supports is a problem or not a problem? Or is that something else? I'm kind of curious how you're dealing with that part. Zac Williamson: It's slightly something else. The curves that Ethereum supports constrains what aggregation schemes we can use. It also constrains what polynomial commitment schemes we can use. But the two are uncorrelated, if that makes any sense. Anna: Okay, got it. So it's something even above that that's basically determining which track you're going to be able to use. Joe Andrews: Actually, for the private rollup context, it's the client prover. Because these proofs are running on user devices in our rollup, compared to a normal zkRollup when they're running on a big AWS machine, it's the memory footprint with the prover being able to run on the client device that lets us select the correct polynomial commitment scheme. And the team's been doing a lot of work on that to shift the polynomial commitment scheme to try and get under the WASM memory limits for actually running this on mobile devices. So we've got a lot of constraints from Ethereum to old Android phones or old iPhones being able to run these things. Zac Williamson: Yeah, definitely. So there's been some iterations on the commitments team side too. PLONK was published. It was kind of deliberately kept scheme-agnostic. But the version of the protocol we described used this commitment scheme by Aniket Kate. But our latest versions that are in development, we're migrating to the commitment scheme that was described in the "SHPLONK" paper by Ariel Gabizon and Justin Drake. And yeah, there's also been some really cool innovation on the commitment scheme side. I know Mary Maller has published recently a paper where a commitment scheme where the performance is strictly better than the existing schemes. But again, the problem with all of the new stuff is that it requires new cryptographic perimeters which you just can't access on Ethereum right now. Anna: I feel like we jumped in really deep for our listeners, pretty quickly. Maybe we take a little bit of a step back and start to describe on a higher level what zk.money is and what that product is. And then maybe we can fit back in where PLONK and all of these things exist within it. So why don't we go through what does zk.money look like? Joe Andrews: So zk.money's just a front end really. It's our flagship product of what's possible with the Aztec technology stack. And I think we built it because scalable private transactions weren't possible on Ethereum before. So we felt we needed to show what was possible. And all of the work that Zac and the team's been doing on getting PLONK to be super efficient on the client side has kind of, I think, reset the user experience expectations of clients running zkSNARKs on their devices. So we've built zk.money to show that you can get almost like a Web 2.0 kind of experience, like a Venmo-style experience for paying people, but this is running on kind of a Web 3.0 zkSNARK stack. That's why we built it. And the goal of it is to showcase to users and developers what's possible on the network. And we've had pretty incredible uptake and demand from users trying to get privacy on Ethereum. Anna: So you're saying the zk.money, that's the front end to this thing. Behind the scenes, is what's running a zkRollup? Or is it something else? Joe Andrews: Yeah. It's a zk-zkRollup. As Zac was saying earlier, we're calling it a private rollup. So we have very, very optimized WASM code, which runs in our SDK in the browser. And that's the first, I guess, gateway into this kind of proving system. The client there is creating proofs to obscure transaction data from a rollup provider. So we're processing transactions that contain zkSNARK proofs rather than just public Ethereum data. So that's step one. And then that transaction, once it's constructed on the client, is then fed into our rollup prover, and they're all bundled together to validate hundreds of thousands of transactions in one go or on mainnet. Anna: I'm trying to picture how a token moves through this thing. So you send something to a contract on the L1. It locks. Kind of the same way we understand a zkRollup. But somewhere in that, there's this privacy element. And I want to understand even closer where that is and where that happens. Joe Andrews: Sure. I'll take a stab, and Zac can fill in the technical details. We have a different state model to Ethereum. Ethereum is obviously account-based. And it's quite hard to do full privacy in an account-based model. So once the tokens are deposited to the layer 1 smart contract, the ownership record is stored effectively into Merkle trees. So all state is recorded as these UTXOs and into Merkle trees. So it's a similar design to the original Zcash protocol, but kind of retrofitted to an Ethereum smart contract. And end users could prove existence of value in those Merkle trees. And if the leaves are encrypted, you can get end-to-end privacy. Anna: So you've put one token into the smart contract, a new one has appeared in the rollup, but it's not private yet, right? It's this unshielded version first? Zac Williamson: Well, ish. You get a little bit of privacy from the start because what happens is, as Joe says: you put your deposit into Aztec. Aztec rollup smart contract acts kind of as a custodian of your tokens. And in return, it issues you a zero knowledge note. So it issues you this encrypted object which is a claim on the tokens you've deposited. You can freely exchange back into tokens whenever you want. And obviously you can trade around this claim to other users. You can split it up. You can do whatever you want with it. So obviously if you make a deposit, everyone knows how much you deposited, because that transfer is public. But the zero knowledge note you get issued, nobody knows when you've spent it. And nobody knows the identity of the Aztec address which owns the note. So you get some obfuscation straight off the bat by making a deposit. Anna: But is that all rollups? That's kind of something that all rollups already have, or no? Zac Williamson: Well, no. Because with all rollups, you would have a special rollup identity, a rollup address. That would be public. So what happens now is in Aztec when you make a deposit, you get your zero knowledge note. It has an owner, but that owner address, that Aztec address is encrypted. No one knows what it is. Anna: I see. Okay. Actually, what I've seen on most of the rollups is you'll have the equivalent address on both the rollup and the mainnet. And here you don't, I guess. You have the mainnet address that you're using for that wallet. And on Aztec, you already have something else. Zac Williamson: Exactly. Yeah. Joe Andrews: I think that's an important point. On zk.money, we've given users aliases. Eventually, they'll be replaced with ENS domains. But it's the first time when you can actually say, "Hey, pay me at this address," but you can't see anything about my payment history when you look up that address. So yeah, we're using that system to allow us to tell users where to send funds. But because the actual zk note is end-to-end encrypted, there's no further information that could be gleaned from the alias, other than the public key that's used to encrypt the value. So it's a pretty cool system. I like to think of it like the Signal, end-to-end encrypted messaging, but for payments. So it's a similar design, I'd say. Anna: Although we haven't quite finished the journey though, right? This is just that first jump. Where does it go after? Why do you even have shielded as an option? I have checked out the website, by the way. Zac Williamson: Yeah. This is just what we consider the end of the beginning with regards to what we're building Aztec to become. Right now, the main value is privacy for private transactions. You can shield, and then once you've shielded your tokens, either within our rollup, you can privately send them to people. I had an interesting experience that when we launched zk.money somebody sent me 0.1 ETH, zk ETH, and I had no idea who it was. So whoever that was, thank you. And then when you withdraw from the system, when you convert your note back into tokens, the withdraw of the address could be any address you want. And nobody can link your deposit transaction with your withdraw transaction. Because when you create one of these zero knowledge notes, nobody knows when you spent it, other than you. So that's where we are at the moment. Where we want to be, where we're going in the future, is programmable privacy. Because right now, we think fundamentally privacy is necessary for blockchains to really fulfill their true potential. Because the more people's economic lives and financial activity move onto a blockchain, the more important privacy's going to become, because the more information you're leaking. If we live in a world where your salary gets streamed on a blockchain or where your payment history's being made on a blockchain, that's not going to be something you'd want to be broadcast to the world. We want Aztec to fill that gap basically, where in the future we can use our technology to make fully programmable private smart contracts. So not only can you create your own private cryptocurrencies, you can also define the semantics around how they're transferred. You can add terms and conditions and logical checks like regular ERC20 tokens. You'll be able to create private non-fungible tokens, where the owners are private. Also, importantly, you can obscure certain bits of information about the NFT and conditionally prove things. For example, you could say, "In total, I've spent less than a certain threshold amount this month." And you can do other things which are a little bit more boring, but quite important. Things like KYC (Know Your Client) and anti money laundering checks as well. You can have things like identity tokens. So you can have KYC tokens to prove that you're on some kind of approved list, without revealing who you are. Things like that are going to be key for working in regulated environments. But as well you can use this programmability to create a very feature rich ecosystem of DeFi protocols that work in concept with these private cryptocurrencies to enable, effectively, private DeFi, where you can engage in similar DeFi protocols as today, or even exactly the same DeFi protocols as today working on layer 1, whilst hiding who you are. Anna: One question here though. You said that the zk.money and that zk-zkRollup is more UTXO based. How do you then reincorporate programmability into that? Because I always understood that as like that's one of the reasons why Zcash isn't as programmable, because it has that format. Zac Williamson: It certainly does make life a little bit harder. But I think most of the reason why you can't program private privacy systems right now, it's mostly a technical obstacle because adding user-defined programmable circuits hasn't really been possible until the last few months really, just because you need universal SNARKs. You need them to be extremely fast because you're making these fields on the browser. You need to be able to handle recursion efficiently. There's a whole host of technical ingredients that are required that barely just really come together. The state model does make things a little harder though because you can't easily have an account model. You can certainly apply an account abstraction layer above a UTXO model. But that's something that your front end dApp has to handle. It's an extra layer of complexity. it's something that our SDK handles, for example. We're trying to abstract away this UTXO stuff from the user. But it does certainly require a different way of programming things. It's why we're putting together our own zkSNARK programming language. Because in a private world, state variables have to be owned by users. Everything is encrypted. And only specific people will be able to decrypt those objects. And if you want something which is really private, you can't have global variables like you can at smart contracts, that are publicly visible to everybody. If you're doing some kind of token or AMM, you can't have a total supply that's public, because that leaks too much information. So there are a host of difficult issues that need to be solved to make privacy practical. But we think we're well on our way to solving them. Just to finish on this, I think one interesting thing is actually, when creating DeFi protocols where you want to protect user privacy, you can still do so. Basically, what's most important is that the actual representation of value, the cryptocurrencies, that they are private. And once that's happened, you can build public DeFi protocols that interact with these private assets and private pools, and to do so in a way which is still privacy preserving. Because if you can see everything that's going through the DeFi protocol but you don't know who owns the trades or the positions, then you still have extremely strong privacy guarantees. Anna: You have some sort of privacy there, for sure. We did an event about two months ago, and Zac, you gave a talk there. It was actually about privacy and DeFi. And maybe we can actually talk a little bit about that because in that talk you did present some ways that you could incorporate privacy into DeFi protocols, even like these AMMs. ---Something that I feel---We've also seen a lot of counter-research saying "you cannot just blanket-add privacy into an AMM because it actually breaks some of the things that one needs in order for these things to function. It needs some sort of transparency." But you had some ideas around how to fix for this. Zac Williamson: Yeah. Privacy is hard. And there's a lot of things you just cannot do privately that you can do in the public world. You certainly can't make a fully private AMM right now without using extremely advanced multi-party computation techniques, which are not really practical the present day. And most DeFi protocols right now, you can't just magically make a private version. Take, for example, MakerDAO. If I want to make a CDP to borrow some DAI, imagine you want to do this privately, so you have an encrypted CDP. So basically you've effectively staked some of your Ethereum privately to create a private amount of DAI. Now, in order for the DAI system to work, the contract needs to know when your position becomes under-collateralized. And once you become under-collateralized, it needs to automatically liquidate your position. Neither of these things can happen if it's encrypted, because if the contract has the information to understand what it's worth, so does everybody else. So you don't have privacy. And if you do have privacy, then the contract can't liquidate your position. So basically our position is for the time being, it's not really practical to create private versions of DeFi protocols. What is much more practical and achievable is to interact privately with public DeFi protocols to basically anonymize your holdings before you engage in these DeFi protocols. So if you, for example, use Aztec to ... Let's say you want to put 1,000 ETH into Compound. If you have Aztec to anonymize your holdings so that you have these random addresses on Ethereum that hold ETH, no one can link them to your original accounts. And we think the most important thing for enabling privacy-preserving techniques on DeFi is to ensure that transactions are uniform. Imagine you have an ETH/DAI pair on Compound, and every single trade is, say, 100 ETH or 10 ETH, or you have these fixed denominations. Now, that does limit the user experience somewhat. But because if the identities of these holdings are all anonymous and the values are all uniform, you have no real meaningful information about who's controlling these trades. And obviously if you want to make large trades, then you submit lots of smaller trades as a batch, which is typically how a lot of traditional markets work. For example, we're planning all this new technology to solve the front-running issues in DeFi, and the fact that if you're trading large notionals you move markets. Because right now if a so-called whale wants to do a trade on DeFi, then typically the way you do this in the Web 2.0 world is you split your big trade up into lots of little trades and put them out into the market slowly over time so that you don't massively shift the market. But the problem is because of analytics on chain, if you start selling your position.... Anna: They know. Zac Williamson: Exactly. And so everyone's, "Oh, look the whale's trading. Let's move the market. Let's take advantage." And the only other solution is to push your entire trade through as quickly as you can to prevent front-running. But then you're taking a horrible spread on your trade because there's not a lot of liquidity to satisfy huge trades. And Aztec solves this. Instead what you do is you can now split up your large holding into a lot of smaller holdings that are anonymous, that nobody knows they're all linked. And so you can then put those trades out into the market slowly over time without people realizing that you're doing so. Anna: It changes the dynamic dramatically. I did an entire episode with Guillermo and Tarun all about the private AMM work they're doing. I'm going to link to that in the show notes if anyone wants to hear that in even more detail. I think Guillermo actually spoke just after you, Zac. And he was really impressed that your thinking had already reached those levels, that they had been working on in terms of ways to fix this. But what you just said is this is still a future thing. This isn't something that's implemented today, right? Where are we at with the product right now? Joe Andrews: No, it's in progress, I'd say. I think we've laid the groundwork. So our private rollup today has kind of more than one transaction type. So we have kind of the standard join split transaction, which allows you to send private funds. But we've got kind of the early versions of programmability in there with another type of transaction, which is an account transaction. So users have accounts, and they can kind of modify the state of their account, change which keys can spend on their account, change their username, and change their kind of encryption keys. And if you kind of fast forward a few months, there'll be a third type of transaction, which we're calling it the DeFi bridge. Users will be able to send their value notes to almost a kind of contract address on the rollup. And that contract will have a predefined kind of layer outcome. So it could be, as Zach said earlier, deposit 1,000 Dai into Compound. It could be swap one ETH on Uniswap. And all of these kind of uniform events will be bundled up in one rollup. And you get this kind of privacy effect by everyone looking the same but doing aggregate transactions. So we're well on the way to achieving that. Probably having an early summer launch is the roadmap. Anna: Whoa. Okay. That's a lot faster than I expected. Zac Williamson: Well, I think we've got all the ingredients. Because, yeah, our own architecture is already programmable. It's just that right now, we have to program circuits. Because it's a lot of extra architecture. It's going to be quite a complex operation to make these circuits user programmable. So we're planning on launching that. So in the meantime, we're going to write our own DeFi circuit, as Joe says, that allow people to talk to layer one protocols but to do so as a batch. So an Aztec will be making one transaction to Uniswap to represent a trade. But that will be shared amongst 100 or so users. So the cost of that transaction, I think, is amortized over lots of users. Anna: On the DeFi side, do those DeFi protocols have to do anything in order to interact with this? Joe Andrews: No. We're going directly to layer one. I think the layer two landscape is a pretty exciting space to watch. But right now, last check, I think it was close to 100 billion of capital on the layer one contracts. And we don't see that going anywhere anytime soon. So our approach is, for users who care about their privacy, those users are probably willing to pay slightly more for a transaction. Still cheaper than Ethereum mainnet, obviously. But they're willing to pay a bit more to have strong privacy guarantees. And it's just like they're doing that transaction on mainnet, but with privacy. So it's kind of a hands-off approach for layer one DeFi protocols. Anna: Is it kind of like, because reading the documentation, basically to sort of finish that journey that we started earlier in this episode of these tokens, and you did hint at this, it was the idea that once you actually have moved funds off the L1 into Aztec into a shielded environment, you can then send that directly back to L1 without having to unshield and then unshield — Even though, I guess, somewhere behind the scenes, it is unlocking and unshielding. But you as a user could just send it right in. So you would basically as a user just send it right into one of these, I guess. Joe Andrews: Yeah. Correct. It would look very much like if I was sending it to you on your username, the end user kind of user experience would be very similar. You'd create a proof on your client. The destination is just a predefined DeFi action rather than a user. So we're pretty excited about that. I think that where things get more exciting is kind of as developers start to think of the new types of DeFi that are possible once you have kind of a uniform set of users. Because Uniswap, it's a good model for public Ethereum. But the slippage costs and all of these things that occur based on large trades aren't necessarily applicable when you have privacy. You can start to kind of design systems that maybe are a little bit more stable in terms of price. And that's where, I guess, stage three comes in of Noir and full programmability. We kind of take the training wheels off the network and let other people define what you can do with these destination contracts on the network. And that's when things get really exciting. I think it's worth talking about that for a little bit because there are a few kind of cryptographic hurdles to overcome there. But that's on the way to doing it, I'd say. Anna: Let's introduce Noir. I did an episode recently with Alex Ozdemir where we went through kind of a survey of languages. And Noir, I had just pinged you or I had pinged you, Zac, or Ariel, and just said, "Do you guys have a language?" And then you were both like, "Oh, yeah, yeah, but it's not out yet." I was like, "Okay." So I think we mentioned it, but we couldn't really look into it. So why don't we talk about Noir, this language, and what that means for your next steps. Zac Williamson: Yeah, absolutely. We need programmability. Right now, the way that we're building our SNARK circuits, you kind of need to be a cryptographer to do it securely, which is not sustainable in the long-run. And so we want to be able to give developers and users the ability to program SNARK circuits and high level language that's intuitive that you don't need to know all sorts of crypto knowledge. Zac Williamson: And so there's a lot of other languages which try to solve this problem. But we have some rather unique requirements, which we think means that the only real solution is to develop our own language. Which is basically because this language is designed explicitly so that all the zk proofs you're building with it are constructed client-side, probably in a web browser using WebAssembly, which is much slower than native code for cryptography. So it needs to be incredibly fast. It needs to be optimized to produce really, really tight circuits. And also longer-term, we want to add semantics into the language which kind of extracts away private state management so that you can have kind of a little bit like a Solidity smart contract where you can have storage variables but they're private and owned by individual users. So we have a lot of custom semantics that we need. And we'll need the cryptographic back end to be extremely fast. Zac Williamson: So the approach we're taking with Noir, the project's being led by Kev Wedderburn. He's our kind of language guru. And it's an open source project where we have this language front end, which kind of compiles down to intermediate representations, a bit like LLVM for zk proofs, we're calling it ACIR. And the idea is to have multiple cryptographic back ends because it's an open source project. So you can have a PLONK back end. You could have a Groth16 back end. You could have a Marlin back end. So make it kind of a very flexible language that could be used by a lot of different teams. Right now, the only back end is PLONK because it's a very new language, so we just wired our own back end into it. But the goal is to support other cryptographic protocols longer-term. Anna: What made you make the decision to write your own language? Because, I mean, this actually was something we talked about where there's a lot of teams that have built kind of their custom architecture, and then creating a language to interact with that. Is there a reason you didn't decide to use some existing out of the box language? Zac Williamson: Yes. And that's because of the abstraction layers that they use to compose circuits. Specifically, especially at the time, all the existing languages, they used, I guess you could call it intermediate representation called R1CS. Stands for Rank1 constraint system. It's a way of defining your SNARK circuit as basically a series of linear additions and multiplications. It's a very efficient representation of circuits for non-universal SNARK systems like Groth16, like the slightly older SNARK proving systems that came out between 2013 and 2016. But universal SNARKs like PLONK, they're not really very friendly to an R1CS abstraction. It creates quite inefficient circuits. And it doesn't leverage any of the core strengths that PLONK has. Zac Williamson: PLONK's strength is these things we call custom gates. It's basically you can define your own custom bit arithmetic operations. I guess you can call them mini gadgets. That are extremely efficient to evaluate inside a PLONK circuit. So you can do things like do elliptical curve point addition in a gate. You can do things like efficient Poseidon hashes, Pedersen hashes. You can do parts of a SHA-256 hash. You can do things like 8-bit logical XOR operations. All these like explicit instructions which are needed for real world circuits, but they're all quite custom. And so we wanted a cryptographic back end which understood what these custom gates were, and be able to convert this high level language directly down into these custom gates to make extremely optimized and tight PLONK circuits. The existing solutions out there didn't really do this because they had this one R1CS abstraction layer which wasn't really suitable for us. Anna: But I mean since then, there are languages now that can do that as well. Right? I feel like there are some projects that are coming out where they also remove the R1CS aspect. Zach Williamson: I think so. But they're still quite very in development. I think most of them, the ones that I know of, very much kind of don't really have privacy in mind. Their main focus is on constructing circuits that can be — web proofs constructed by third parties with a lot of computational resources. So they don't have kind of the focus on optimization that we really need for our circuits. Anna: Got it. Kind of just the last question on this point, but it's like something like Arkworks, is there any way for you to incorporate what you're doing into that? Or does it have to remain these separate language ecosystems? Zach Williamson: They don't have to remain separate. We're completely open to collaborating with other teams to build a kind of a more general purpose language. Because there is a lot of fragmentation in the ZK language space that one way or another needs to be resolved. I guess the problem is, because right now we're still in the really early stages where every team has very ... Like the proving systems, there's a huge trade-off space between performance, ease of use, succinctness. There's all these parameters that you can tweak with your ZK proving system to optimize it for your individual use case. And because the overarching systems are still relatively inefficient, right, like the difference between doing a computation and making a ZK proofer computation, for most common algorithms, the difference is a factor of about a million. And because of this, all these teams have very specific use cases in mind. They have to really treat the parameters of their ZK proving systems to re-optimize for their specific use case. And therefore their languages as well. Which means that you have all these slightly different languages that are all not completely compatible with each other because all these teams have very different needs. Zac Williamson: So I think a lot of this will get resolved as these proving systems become more efficient and you kind of take the more universal approach. So we're kind of happy to see how things shake out. But in the meantime, we're completely open to collaboration with other teams if we have kind of mutual goals. Anna: Make sense. Joe Andrews: I think Noir's also the first kind of of best effort of trying to bridge the gap of that fragmentation. We're saying that you should use this open source as your front end for language. So everyone's working on the same syntax. And then if you have a slightly different kind of need for your proving system, you can hook up the intermediate representation to a different proving system that may not be PLONK; it could be something else. And if we can start to kind of get that methodology working within the community, the project should take off. Yeah. Kev's got some thoughts about this in terms of if the language itself has a standard library that's very feature-rich, I think it can attract developers to use that language because they don't have to re-implement a lot of standard functions, which kind of people are doing all over the place, like a range constraint or a particular hash function. There should be kind of one repo with the fastest or the best Poseidon hash function or SHA-256 hash function. And if you give that to the community, I think you can kind of encourage people to work on the same project rather than different ones. And to do that, it has to be fully open source, so that's what we're committed to. Anna: Cool. Is it Rust-based, or is it based on something else? Zach Williamson: It is Rust-based. Yeah. Our cryptographic back end is written in C++ for a few reasons. Because we want WASM, we want to be more compatible with what other teams are building, we just decided to build it in Rust. Anna: You mentioned WASM earlier. And now I'm curious, what does this actually mean for the construction? Is there any limitations that come along with that? Zach Williamson: When you're programming for the web, the programming languages you have access to are very, very limited because code execution in a web browser needs to be secure. So you can't just directly manipulate a user's CPU, because you can get hacked that way. So WebAssembly is basically a new standard for extremely fast computation on the web. It's an assembly language for an imaginary computer that kind of closely maps to instructions that you find on real computers. So the idea is that if you have WebAssembly code, and running WebAssembly code is kind of almost as fast as running native code on your CPU because there's not much kind of interpretation that has to happen between turning WebAssembly instructions to real CPU instructions. However, that's the ideal. The reality of it is that for cryptography, WebAssembly is really slow compared to running code that's natively compiled onto your computer. Because modern CPUs have very niche maths that we do for cryptography. And those instructions are not available on WebAssembly, which means that if you have a SNARK proving system, if you compile it to run on a computer, and then you compile it to run with WebAssembly, the WebAssembly version will be about eight times slower than the native version. Zac Williamson: On top of this, it's extremely hard to do multi-threading in WebAssembly because you can't run multi-threaded WebAssembly code because that's a huge security risk. So you have these kind of parallel problems, where WebAssembly, you can't easily do multi-threaded instructions on them that we use heavily to do — slow to begin with. So once you have all these extra slowdowns, how do you make the whole thing work? How do you deal with this lack of speed, basically? Joe Andrews: And the memory limit as well. So that's what we were kind of hinting at earlier with the differences in the commitment schemes is it's a WASM problem. In most kind of devices, you have between one to four gigabytes of available proving memory. And that really limits you on the expressiveness of your program in a normal kind of SNARK world. PLONK has issues as well. But we really need to get to Ultra-PLONK to kind of break down those barriers. And, I think, to go back to the question, by the time Ultra-PLONK's in the wild, we'll have usable WebAssembly provers with full programmability. So it's probably six to eight months off yet. Anna: Cool. You just called it Ultra-PLONK. Right? Joe Andrews: Yeah. Anna: For some reason, I just heard Octo-PLONK. And I was like, "Whoa, that also sounds very cool." Joe Andrews: That's a good name. Maybe that's what our next version will be called. Anna: Can you elaborate? What did you have to do then to do the workaround even now with what you have pre-Ultra-PLONK? Zach Williamson: Yeah. So there's a lot of work that we need to do. For example, the most time-consuming part of constructing ZK proofs is basically prime field arithmetic and prime field multiplications. You got two large numbers and you got to multiply the modulo big prime number. So we have these really tightly optimized regular assembly algorithms, the implementations for that that you can't use in web assembly. We had to write these prime field operations in a way which kind of compiled into maximally efficient web assembly, which is actually quite counterintuitive to do that. But the main thing we manage to do is we manage to get a form of multi-threaded web assembly. If you have a C++ program or a Rust program that's multi-threaded and you compile it to WASM, you lose your threads, because since the Spectre and Meltdown attacks, browsers disabled multi-threading in web assembly code. Zach Williamson: So what instead we do is we actually spawn separate web processes in your browser. Each one of them kind of takes on computing a little part of a PLONK proof. And so it's kind of a course aversion of multi-threading. But we get similar results out of it. And that gave us like a factor of like four speed up compared to what we had previously. So that combined with the algorithms that have basically been designed with web assembly in mind have made our proving system fast enough for basic privacy zkSNARK proofs. We think with a bit more work in the future it'll be more than fast enough to handle fully programmable smart contract proofs as well. Anna: You mentioned sort of the Ultra-PLONK. Is that the difference that you're describing that once that's in it'll be easier? Or is there something else that Ultra-PLONK offers? Zach Williamson: Oh, yeah. It's all Ultra-PLONK. Ultra-PLONK doesn't help with speeding up web assembly. It's just a much, much faster proving system because you can do all of the algorithms that we're running, they require far fewer gates to evaluate using Ultra-PLONK. Because Ultra-PLONK uses lookup tables. This sounds really primitive. By regular programming standards, basically what we've done is we found an efficient way of being able to access lookup tables inside a PLONK circuit. And so you can use that to do things like model dynamic memory. So in your program language you can have vectors and dynamic arrays without them being incredibly inefficient. Zach Williamson: So this is really primitive stuff. Normal programming languages have had dynamic arrays since the 1960s. But that's where we are. Also you can use lookup tables to do SNARK-unfriendly algorithms. SNARKs generally are really bad at doing binary operations like doing XOR operations or logic operations because you have to work on individual bits. And lookup tables kind of solve this problem for us because you can just have a big lookup table of your Boolean logic to kind of do these options at kind of eight bits at a time instead of one bit at a time. Joe Andrews: What it enables though is calling it the kernel SNARK. In order to get to this kind of end stage of full programmability and have that run in a WASM prover, you need to kind of define the rules by which developers can write their programs. So you could think of it a bit like a VM, but it's how we allow user-defined Noir circuits to interact with this private state. And that's kind of the last bottleneck that we need to kind of overcome with Ultra-PLONK to get this really working at high speed on client devices. Anna: I feel like you've mentioned words with the word PLONK in them a few times throughout the show. And I actually just wanted to run down. And maybe you can just help me position it in my mind. There's PLONK regular. There's Turbo-PLONK, which is what you're using now? Zach Williamson: Yes. Anna: Okay. There's SPLONK. Which I don't know if that's a thing or that was just a paper or a joke or what. Zach Williamson: It's SHPLONK. Ariel and Justin wanted ... Yeah. I can't comment on silly names. I'm throwing rocks in a glass house. So yeah, SHPLONK, it's a variant of PLONK. It's currently a paper. We're borrowing/stealing the commitment scheme from it. But the actual full paper is kind of a different way of constructing PLONK SNARKs. Anna: Okay. And then Ultra-PLONK is the next iteration. Zach Williamson: Yes. Ultra-PLONK is Turbo-PLONK with lookup tables pretty much. Anna: And then maybe Octo-PLONK after that. Zach Williamson: Maybe, yeah. Octo-PLONK, Mega-PLONK. Sky's the limit. Anna: Okay. One last question is, what's PLOOKUP? Zach Williamson: It's a paper that Ariel and I published last year. So the paper describes how to use polynomial commitment schemes to kind of define lookup tables and to access lookup tables. So what Ultra-PLONK is is basically us taking our PLOOKUP research and mashing it into the PLONK SNARK proving system, so that instead of working with abstract polynomial commitment schemes, you can have a PLONK circuit where you can have specific gates that reference lookup tables. Anna: Cool. Is there any other sort of term that I missed from that? Zach Williamson: Not that I'm aware of. I'm happy to invent a few more if you want to inflect the jargon. Joe Andrews: I think Ariel was working on COVID PLONK, but I'm not sure that's ... Anna: Oh my god. We hope that we'll never have to see that one. Maybe we get to just have post-COVID PLONK. Anyway. I think the last point I want to talk about with both of you is a little bit how the Aztec ZK-ZK-Rollup kind of matches up with all of these other rollups that are coming out, and how you're thinking about them. When you were talking about having a user be able to send funds directly into like an L1 DeFi building block, one of the thoughts I had is some of those projects are actually going to be moving onto different L2s soon apparently. So I wonder with all of these L2s emerging, a lot of them ZK, some of them optimistic, how do you see yourselves fitting into this kind of new landscape? Zach Williamson: Yeah. Our main focus is privacy. We're a private rollup, and currently the only private rollup around. And the users that we want to serve are users that care about transaction privacy and not revealing all their information on chain. We're a little bit different to the other L2s in that regard because we're not really just changing the absolute cheapest transactions possible because adding privacy means that you're broadcasting more data because your data's encrypted. Instead of users that want transactions for one cent, we're chasing users that want private transactions for 10 cents, if that makes any sense. Zach Williamson: Certainly, I think as these other layer twos get deployed, there's going to be a lot of work on kind of cross-layer two swaps to allow people to efficiently migrate funds between layer twos. That's something we'd be very happy to work with. We'd be very happy to create efficient bridges between Aztec and other layers. Anna: Is that what they're going to be? They're going to be like new bridges? Zach Williamson: I think it's inevitable. Because otherwise you're going to get this kind of intense fragmentation of liquidity across all of these layer twos. Anna: But it will be intense, right? Because it's not that all these L2s and not all these kind of rollups are actually consistent with one another. If you were to have to run a light client on those L2s, each one of those may be quite bespoke. Zach Williamson: Yeah. We're going to focus on L2s, which have full EVM compatibility, so things like Optimism. Because what we want is we want to make sure that our users have access to liquid DeFi pools. And so you can only really have those on EVM compatible layer twos. Right now, we're waiting to see how this plays out because right now the liquidity is on layer one. We'll see how much migrates to layer twos and how much stays on layer one. But our focus is on the users. And we want to make sure that our users can interact privately with the dApps and the contracts that they want to talk to. So if they're on layer two, we'll talk to the layer two. If they're on layer one, we'll talk to layer one. Anna: Makes sense. Joe Andrews: I'd like to model that as kind of Optimism or an L2 just becomes quite a complicated dApp. So in the same way we have kind of this DeFi bridge that we're building, it doesn't really matter where we point the bus leaving to go and do an interaction. It's going to go and do that interaction and bring whatever the result of that interaction is back to the Aztec network in order to give it privacy. So we kind of see us growing with the L2 landscape alongside it. It's going to be exciting to see where the different dApps end up and where the different DeFi protocols kind of emerge. And some of them will end up on Aztec, I'm sure, because they require privacy. Anna: I have one last maybe controversial question. But you had sort of mentioned some of the limitations of Ethereum as an L1 in building all of this. Have you at all looked out at other L1s? Please don't hate me, Ethereum community, for asking this question. But I just am curious. Zac Williamson: Yeah. I mean, the reason we're building ... I don't want to sound like we're dumping on Ethereum, you're saying Ethereum has limitations we have to work with. But really we need to work with a layer one that is both programmable and expressive but also has the ability to support these quite advanced cryptographic protocols. And right now, Ethereum is the only game in town. There are other layer ones ... I don't think there are other layer ones which have the kind of advanced cryptographic parameters we need as well as smart contracts. Anna: Or the tooling mostly, I'd say. Yeah. Zac Williamson: Yeah, exactly. So if another layer one pops up with a lot of users, lot of liquidity, that we can easily port Aztec to, we wouldn't rule it out. But right now, Ethereum, it's the place to be. Right? It's the ecosystem with all the users, all the dApps, all the liquidity. It's got the expressability and programmability we need. And they've also really pushed the boundaries with regards to what's possible. Sure, Ethereum has only a limited number of cryptographic primitives available, but they still have those primitives. Right? You can still do pairing-based cryptography in an Ethereum smart contract, which is quite ... I mean, I was on some of the ETH Dev calls when that was happening, and it's quite a difficult thing to coordinate and pull off. So for the time being, we're very happy with the Ethereum ecosystem. It's easy enough to port Aztec to EVM-compatible chains, but we think Ethereum is the home for us in the future. Anna: Got it. Cool. Well, Joe, Zac, I want to say thank you so much for coming on the show and sharing with me and the audience this update of Aztec, the introduction to zk.money, which just came out. It's actually live now. People can actually play with it. Do you have anything you want to share with the audience before we sign off? Zach Williamson: Love to, yeah. We're hiring a lot. We have a lot of open roles because we've got some ambitious plans that we're executing on. So if you're interested in the space, we're hiring pretty much the whole technical stack, front end devs, back end devs. We're hiring applied cryptographers. If any of those roles tickle your fancy, get in touch. We have a jobs page on our website. It'll be great to hear from anybody who's interested. Anna: And I guess people should go to ... It's actually zk.money. That's the website, right? Joe Andrews: Yeah. If you go to zk.money and check it out, get your username registered, and you'll be able to really kind of take control of your privacy. And yeah, we can't wait to deliver more features to you over the coming months. And stay tuned for private DeFi. Anna: Very cool. Thanks again to both of you. I want to say a big thank you to Henrick the editor, Andrew the producer, and to our audience. Thanks for listening.