Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Tom Pocock & Zac Williamson: AZTEC Protocol – Bringing Zero-Knowledge Transactions to Ethereum

Episode Date: April 14, 2020

AZTEC Protocol is a protocol that enables private transactions on Ethereum. At its core, AZTEC is an Ethereum contract, otherwise known as the AZTEC Cryptography Engine. The protocol uses a zero-knowledge proof system, allowing users to effectively create shielded representations of tokens, which can then be sent and redeemed for the underlying token. CEO and CTO, Tom Pocock and Zac Williamson have plans to build AZTEC into a fully functional DeFi stack with which all kinds of trades, swaps, and financial operations will be possible, with privacy.Topics covered in this episode:How Tom and Zac met and founded AZTEC ProtocolWhat AZTEC is and what problem is solvesHow AZTEC enabled transactions work in practice from a user perspectiveThe challenges of making DeFi systems like MakerDAO fully privateHow ERC-20 tokens could be issued as private tokensThe AZTEC trusted setup ignition ceremonyZKPs for privacy vs scaling solutionsGrowing the privacy ecosystem and getting people excited about privacyThe security guarantees of using AZTEC and other ZKP systemsEpisode links: AZTEC ProtocolAZTEC Protocol - SDKAZTEC Protocol - research papersAZTEC Protocol TwitterTom Walton-Pocock TwitterZac Williamson TwitterReset EverythingSponsors: Least Authority: Register for Security Sessions on April 30th to learn about security audits for your blockchain project - https://leastauthority.com/meetupStatus: A multi-purpose communication tool that combines a peer-to-peer messenger, secure crypto wallet, and web3 browser - https://status.im/This episode is hosted by Sebastien Couture & Friederike Ernst. Show notes and listening options: epicenter.tv/335

This is Epicenter, episode 335 with guests, Tom Pocock and Zach Williamson. Hi, welcome to Epicenter. My name is Sebastian Kuccio. Today, our guests are Tom Pocuck and Zach Williamson. So, respectively, they are CEO and CTO of Aztec protocol. ASTEC is a platform that enables private token transactions on Ethereum. So at its core, it's a smart contract. It's also known as the Aztec Cryptography Engine. And here's roughly how it works.

So when a user wants to make a private transaction, they deposit funds into the contract, let's say 100 die. And then the system issues a zero knowledge note which corresponds to this die. So as a holder of this note, you can split it up into smaller amounts. You can send it to whomever you like. And then they would redeem that note for the corresponding amount in die. So this is one basic example. An Aztec enables a number of use cases and we go into that during the interview. The way Aztec is built, it requires that every participant in a transaction is using a wallet that has integrated the protocol. So they built an SDK that allowed developers to do just that and built Aztec into their own wallets. Felaika actually participated in the trusted setup ignition process, which took place last year.

And so she and I did this interview together. So here's what you'll learn in this conversation. How Tom and Zach met and founded Aztec protocol. what it is and what problems it solves, how Aztec works in practice and under the hood, the challenges of making defy systems like MakerDAO fully private, how ERC20 tokens could be issued as private tokens on chain, the Aztec trusted setup ignition ceremony, the types of transactions and business logic made possible by the Aztec cryptography engine, the prospect of dark contracts with privacy built-in, the security guarantees of using ASTEch and other ZKP

systems, the use cases for ZKPs for things like privacy and scaling solutions and the growing privacy ecosystem. These are some very unique times. So it's time for us to think about resetting healthcare, education, money, privacy, environmental policy, work and collaboration. It's time to reset everything. So on April 29th, I'm organizing a conference where academics, entrepreneurs, and thought leaders will come together to discuss the lasting effects of the COVID-19 crisis. So let me tell you about some of the great speakers that we already confirmed. I'm really excited about these. Mark Miller, who's been on the podcast, a Goric Chief Scientist and Forsyte Senior Fellow. Science fiction author, Corey Doctoral,

will give a talk about how we need to either decentralize or die. Another former guest, Robin Hanson, Associate Professor of Economics at George Mason University, will give a really interesting talk about flattening the curve with deliberate infection. One of my podcast idols, Jeff Jarvis, author of the great book, What Would Google Do? And Professor of Journalism at CUNY will also be speaking about the impacts of COVID on journalism. We have former NASA scientist Creon Levitt giving a talk about the potential upsides of COVID-19. Brian Belvedorf of the HyperLedger Project will speak about the blockchain's role in mitigating the impacts of pandemics. We couldn't talk about COVID-19 without, of course, having Ryan Selk

and also Riva Taz, Senior Director of Strategic Initiatives at Intel, will be speaking. So these are just some of the speakers that have already confirmed and we're adding new speakers every day. So please register. Registration is free and you can sign up at Reset Everything That Events. About 300 people have already registered and we hope to have enough speakers to make this run for 24 hours. So once again, it's reset everything. That events and it's happening on April 29th. I want to talk to all your founders out there. You're building something that you're you're you're super passionate about. And as a founder, you need to think about a lot of stuff, like

which platform you're building on, token economics, building a team and raising money. And you're also thinking about security because keeping your users' funds and data safe is a top priority for your business and its reputation. So the crypto space is like a big experimentation lab. And lots of these experiments involve people's money. I mean, just think about the very project we're interviewing today in this episode, Aztec. We're talking about. We're talking about the very project we're interviewing today, We're talking about very, very cutting edge crypto here, like as cutting edge as it gets. And for these guys, security should be, and I'm sure it is, it should be woven into every aspect of their organization. And we're not just talking about smart contract audits here, but everything from the company's

security policies to front-end user applications. So to help you get into this security mindset, the privacy-focused security consulting company, Lease Authority, is hosting their first security sessions on April 30th. It's a free online meetup where you will learn about the low-hanging fruit common vulnerabilities that you can fix today, what a security audit actually looks like from start to finish and exciting developments in blockchain security research. You can ask questions to the team of expert security researchers and get advice about the things that you're most concerned about. And it's free. So to sign up, go to leased authority.com. Once again, it's happening on April 30th, and there will be several sessions to accommodate all time zones.

Do yourself a favor and get your organization into the security mindset. Sign up for security sessions at leasta30.com slash meetup. The status mobile app is now out, and it is available in the Apple App Store and Google Play Store. Once you've installed it, join the public channel, epicenter. Come and say hi. And if you ask us, we'll give you some SNT tokens to help you get started and register your status ENS name. So the speed at which status is changing is really mind-boggling. So they just released version 1.0. Version 1.2 came out last week. And with 1.2, they've upgraded it from the

Whisper Protocol to this new peer-to-peer messaging protocol called WACU, which can handle 10 times as many daily active users as Whisper and has a lot of bandwidth consumption optimizations and things like that. So they're constantly upgrading this thing and making it even better. I was just talking with someone from the status team a couple of days ago, and they're telling me about all the things that want to build into it. Like, for example, push notifications. There are no push notifications right now in status because, of course, if you have push notifications with like iOS, all that data is made visible to Apple. So they're thinking of really creative ways to get around those constraints and making sure that the messages that you receive are truly private. And privacy is of the utmost

importance. Now, let me tell you something. When you sign up for status, there's no phone number, there's no email address, there's no identifying information. You register with a seed. You create a private key the way it should be. And this is what secures your messages and make sure that only you can read them. It has a decentralized messenger, a crypto wallet, and a mobile DapStore. You can explore the ecosystem of DAPs and safely send, store, and receive crypto, including ERC20s and some ERC 721s. Download the status app at status.m or go directly to the Apple App Store and Google Play Store. And with that, here's our interview with Tom Pocock and Zach Williamson.

So we're here today with Tom and Zach, the co-founders of Aztec Protocol. Tom and Zach, would you be able to tell us what you did before you co-founded? Thanks for having us. Originally, I trained a long time ago in maths at undergrad and then had a glancing blow trying to sing for a bit. I didn't go very well. And then I was in banking for a few years, financial services more generally. And it was in about 2016 that I started to hear about Ethereum. I was quite excited, actually, for its prospects to provide clearinghouse technology to private capital markets.

So that was really why the business got going in the first place. I met Zach around that time, and we started to work together on building a platform to enable the capital markets to issue and then trade private debt, principally. And then it wasn't until later on that we switched to Aztec protocol, which was at the beginning of 2018. What about you, Zach? What did you do before Aztec? So before Aztec, I started out as a particle physicist. doing experimental new tino physics, then decided that really academia wasn't the life for me and transitioned into software engineering and programming and development. And after about a year of doing that, I started dabbling with blockchain. I met Tom. We started working together on

as Tom says, and then from there, kind of fell into zero knowledge cryptography and fell down that rabbit hole and that ended up being becoming Aztec. So what was it about the zero knowledge technologies that you guys found particularly interesting and that made you want to really dive in headfirst in these protocols? In the first instance, it was just we couldn't really progress the platform we were building on. We wanted the clearing benefits, the trustless trading benefits of Ethereum for these private loans. We knew that it was going to be a non-starter to do any kind of business on public blockchains without privacy. So really that's why Zazan, started to look into zero knowledge techniques when we were on the Entrepreneur First program

because there seemed to be no other solution for efficient privacy. So that's really what got us going on this. It was a need rather than kind of being aesthetically pulled towards this technology. I heard Entrepreneur first. So you told us before the show that you actually met in a private setting beforehand and then went on together to Entrepreneur First. Tell us about what this program does. And you also met a lot of the people who now work at AdStack there, right? That's right. Yes. So the idea of the Entrepreneur First program, which started in London, is now gone, I think, to six cities globally. And the idea is that they have both capital and then a location for putting founders in touch with one another and giving them some seed capital.

And the idea, certainly when we joined, was you'd have someone with a domain background. So in that case, this was me, I had background in banking. and then someone with ideally a deep technology backgrounds, in that case it was Zach. And they try to pair these people up and put them into a team. They put them through a six-month program. And at the end, you then get to present to a lot of the leading, both European and US investors. Zach and I were a little unusual in that we had been working, certainly, weekends together, for about eight or nine months building this thing before we joined.

So we really joined because we thought it would put us in front of the top VCs in a relatively efficient way, rather than looking for a co-founder. But as it turned out, we found two very talented other people, one Arno Schenk, who's now our CEO and one Joe Andrews, who's now our CPO, and we asked them to join whilst we were on the Entrepreneurface Program. Let's move on to ad-tech protocol itself. So in a nutshell, what does it do? So in a nutshell, it enables private tokens on Ethereum. It's a kind of a privacy layer that you can use to either create a private token like someone like a EEOC20 token, or you can wrap an existing EIC20 token and make transfers of it private.

Although I should qualify that by saying, what will be obscure are the values being sent around so that you can send me private wrapped Ethereum or private dye, and nobody can see how much you transferred, but at the moment, we do expose identities. This is a very deliberate decision to keep the gas costs of the protocol to a minimum. That's currently what the Asset Critical does at the moment. We have plans to significantly enhance its functionality over the coming year, based of some research and develop, some research that we've incubated, that dramatically increases the scope of what we can do, because we now have a kind of a system of general purpose private computation that we can use to create, not just private tokens, but

complex business logic, complex transaction flows that has applications that go beyond simple value transfers. Cool. So that's Planck. And we'll get to that in a bit. Just from a super practical perspective, say, I have 100 zero knowledge die and I want to send them to Sebastian. What do I do?

You would use a private wallet interface or some software that uses the Aztec developer toolkit. From your perspective, it would look exactly like a regular transfer. you would say, I want to Sebastian's address, I want to send him 10 die. The only real difference from the user's perspective will be a couple of extra digital signatures that need to be signed over a traditional U.S.C. 20 token transfer. But our focus on when it comes to our tooling and resources has been to make this a, from the user's perspective, completely indistinguishable from a regular token transfer. And would Sebastian then also need a wallet that kind of supports zero knowledge die,

or would that just be on my end? And what kind of wallets are out there that currently support this? So, Sebastian would need a private wallet to redeem the die and convert to either send it to somebody else or convert it back into public tokens. Our protocol we released it. I think it's been just about every month now. There are a few teams currently building integrations

and we're building something we're calling the kiosk, which is kind of a demonstration, DAP that uses private transfers as a model to build off of. We're opening for some wallets to come on stream in the relatively near future. You can actually go and have play around with this k money is the address. It's very quick. There's not a complicated sign-up process.

We decided to build it really because even though our principal business is providing private technologies to developers, we're getting a lot of demand from people in the crypto community wanting to play around with ZK Dai and obviously not wanting to wait for lead time to wait for DAPS to come out. So we built this ZK.com money so people can play around with ZK Dai and ZKKRAps ETH straight away. So I want to come back to this practical aspect for a moment. Frederica would like to send me 100 dye. So Frederica is very privacy mindful. And maybe I'm not so privacy mindful, right?

I'm just using an Argent world like everybody else. And she's like, hey, I'm going to send Seth some dye over this confidential transaction. I have his Argent ENS name. And I'm just going to send that transaction to that address. Is this possible? And like with the die, like what would happen to that die if, I don't have an Aztec enabled wallet. Can you talk about some of the practical aspects of how this actually works?

So practically, it does require both the send-you and the recipient to have some kind of wallets that can talk to the Asset Protocol and like send the Ethereum transactions required to convert into and out of the private sphere. But other than that, it should be relatively, like the flow is the same. You can extract all the information you need to send a private transaction through an NIS domain name, So that is all that Frederica would need. And then once she sent that private die to you, it would be like the equivalent of receiving any else you 20 token,

and you would need some wallet support to actually access those funds. But yeah, those funds be waiting for you until you could. In order to go from having just regular dye to this private die, what are the steps necessary? So would this just be built into the wallet where you send that die to like a smart contract? Or can you talk a little bit about so the specifics of like how this works under the hood without getting into ZK part of it, but just sort of the specifics of how that works. Happy to do so. Under the hood, you do need to make a deposit transaction. So in ZK.

Don't money, we have an explicit flow for funding awards where you would effectively send a single theory transaction that will convert some dye that you own into private dye. The way that works under the hood is we have a smart contract called Ace, the Aztec Cryptography Engine, is a custodian of your public tokens whilst they're in kind of a private form. So what will happen is you will send Ace some die tokens. Ace will then give you in return a zero knowledge claim on that die. That you can then trade around. You can split it up.

You can send it to whoever you want. And then anybody who has one of these notes can then redeem die from a ACE, I can exchange the tokens. Okay. So just to sum up, as a user, I'm using Aztec enabled wallet. I send funds to a smart contract. That smart contract then holds these funds and issues a note, which essentially represents these funds. This note represents the private die.

So let's say I sent 100 die for this smart contract. I then get a note representing 100 die. I can break that up in how many parts I want and send it over to someone. When that person receives the note, then I suppose they can just extract the die back into sort of their public. wallet and then send that to any Ethereum address. Yes, precisely. I was thinking about this while reading your blog post. And is it the case that if very few people, because you mentioned earlier that identities are

not obfuscated or not private, but if very few people are using this smart contract, maybe not for die, but let's say it gets implemented for another ERC20 token that has little usage or a lot less volume, would someone analyzing this contract and sort of like flows of of tokens coming in and out, be able to perhaps extract who's sending money to whom. I mean, maybe not in the amounts themselves, but make some assumptions about whose transaction with who is, with that? Is that like an attack vector that you guys have thought of? They certainly would. As we're kind of confidential only at this point, you're right. I mean, the fewer transactions you have going through the system.

Pseudo-anonymity only gets you so far unless you have a lot of volume going through the network. There are a couple of things I would say here, which is first of all, Aztec was originally built for assets that were zero knowledge from day one. In other words, what we've applied it to is where the crypto capital is at the moment, which is visible die. And so we've created these contracts to enable people to kind of convert in and out of that visible die through this deposit scheme that Zach was talking about. But our kind of our long-term vision of how people will use privacy is that these assets will be created in zero knowledge from their very creation. In other words, something like die at some point in the future, it's the process of opening a CDP, getting your die, sending it, the whole process start to finish would be private. And that would then remove the ability or vastly reduce the ability for people to mine the network for data. The second point is also, we don't hide the transaction graph at this point, but we will do when we make our upgrades at the Planck system. That obviously also introduces a greater opportunity for people to data mine and see who's transacting with who. That is.

something that we will be eliminating in our future network upgrade. I mean, these data mining attacks, they are pretty common in the zero knowledge space. So basically you see them on tornado and then green and so on. But let's say I now have ZK. Dai. Is there any chance I can actually use them in a confidential way, say on uniswap or so? At the moment, because the protocol is brand new, all of the existing defy infrastructure, you can get it to work in a zero knowledge world, but it requires a little bit of work to do. So what we have at the moment is we don't just have the ability to do basic transfers.

We launched the protocol with seven distinct types of transaction flow that you can, seven distinct zero-nals proofs that you can assemble to create more complex business logic. So you can do things like financial swaps if you want to create a decentralized private exchange. And we have things we have ways of performing dividend payments so that you can have interest-bearing or dividend-bearing private financial instruments. The long-term aspirations is to make it so that you never need to leave the private sphere, so that once you have private funds, either from a public asset or from a fully private asset, any kind of economic activity that you want to do with that asset you can do through zero-a-law's-proof zero-notch protocols

so that you never need to convert your assets into public tokens and then obviously reveal information. The bet we're making as a company is that whilst we're not necessarily using these blockchain systems, for day-to-day transactions, the amount that we care about privacy is potentially pretty low. As we start to shift more and more of our day-to-day identifying transactions onto these networks, that's the point at which we expect privacy to have to percolate throughout these systems, because otherwise we'll be leaving extremely valuable pools, reservoirs of data available for the whole world to see and to analyse. And therefore, we would expect privacy to be a kind of prerequisite

for dealing with DFI systems in the medium term. There are some very interesting problems that I'd say are probably as yet unsolved about enshrouding DFI with privacy. Just some really interesting practical problems. So if you just think about something like Maker-Down, obviously we all know it's a super exciting project, but of course comes with enough problems even in the visible setting. Now imagine putting all of its collateral base into a private wrapper.

So how now does the MakerDAO system make sure that its CDPs are not underwater? Say it's hard enough even when you know the price of which ethers trading and what all the collateralization ratios on these CDPs are. Now make all of that collateral private, make the die balances private, make the CDPs private. And what you now have is a massively paranoid defy system, because the defy system has to keep on tapping every CDP holder on the shoulder and saying, I don't believe you're not underwater now. I know you weren't underwater 10 seconds ago because you sent me a proof, but please send me another proof. And please send me another proof. And it'll have to keep on asking all of those borrowers from the system to prove that they're still in a position of excess collateral, that

they're not underwater, in other words that the die is fully supported. There are interesting ways that you could solve for that. For example, if you knew what the asset type was that was backing the system or the particular CDP, if the system was allowed to know, well, okay, I don't know how much collateral's in here. I don't know how much dye has been issued off the back of that collateral, but I know what the collateral type is, and I know the price is trading at, you can then start to reduce some of these problems of the system having to keep on, in this paranoid fashion, asking for more and more proofs that you're in a position of excess collateral. there are ways that if you as a borrower from the system were prepared to give up just a little bit of information, you could stop the system from pestering you too often.

So there are probably ways to solve that, but putting Defi in a totally private setting is going to be quite a complex enterprise. What parts of the Defi ecosystem can we make private without too much complexity and overhead? I mean, could we conceivably make all ERC 20 token transfers private without provoking like this computational or sort of this overhead? Are there parts of DFI that you think we could make private like Dexes, for example, or like token transfers in uniswara or something like that? I'm asking this from a very sort of like novice perspective because I'm like, I'm super, super familiar about your knowledge technologies. The really low hanging fruit here is ERC 20 tokens that are not backed by another form of collateral. So, for example, if you have, I don't know, it's MakerCoyne or there's a load of assets out there. I mean, I suppose that's backed by the collateral with its cash flows.

I may not be a great example. But if you have an asset whose value is inherent to the asset and there's no further collateral to look behind, it's very easy to issue that asset afresh in a zero knowledge context. But in order that you don't have this issue where, you know, in the case of ZK die, currently you put the die into the contract and you get back a kind of a sleeve, a zero knowledge context. knowledge wrapper, the zero-hledge equivalent, you have less visible trace because everyone sees that you've put in 20 or 30 die. So for anyone issuing new ERC-20 tokens or wanting to fully migrate to a private setting, they can do that. And thereafter, every single transaction that's done in

that ERC-20 asset will then be completely confidential. So that's the kind of the easy answer to that question. The other thing I think, which could be done basically instantly, is something like, USDC. So that does have, obviously, it's collateralized, but it's collateralized in an off-chain asset, which is not visible to the world. So there's another example of where you could have a stable coin. Now, whether you call that defy or not, I mean, some people wouldn't qualify that as defy, but that's another type of asset you could put on main net without ever leaving a visible trace of the amounts involved. Right. Perhaps even security tokens or, you know, real estate back tokens or this sort of thing. Exactly. It was security tokens that,

was originally designed for in the very first place. When it comes to zero knowledge at Dufi, there's a hierarchy of complexity that Tom was describing. You have, the most basic thing is kind of unilateral transaction. So if I'm sending somebody or you're sending somebody some tokens or some assets or something like that, where it's completely non-interactive, it's very easy to translate to a private setting. The next level up are bilateral interactions. So trades between two people. Like I'm trading something like an additional asset with you.

or I'm engaging in some kind of futures trading or betting system. And that is also quite practical to achieve in a zero knowledge world. It takes a bit more work, but you can do it. You then get to kind of multilateral computations which become a lot harder. So things, as times say, things like dye, things where you have some kind of collateral base, where you need to form quite complex computations involving inputs from lots of different people, like, for example, managing a CDP.

That's significantly harder to do. And we see our kind of efforts focusing mostly on the first two use cases in the short term. And then once we've summited those peaks, then we'll focus on the more complex systems. We kind of understand what ADSEC can currently do and what you're looking to be able to do in the future. So let's look at how this works under the hood. So basically, this is all powered by zero knowledge proofs. And for that, you actually did a trusted setup that you call the ignition ceremony. So tell us about this.

and then let's kind of unpack the steps of creating a zero-knowledge proof from there. So as far as the ignition ceremony is concerned, as you may be aware, for zero-knowledge snark systems, they depend on this kind of piece of mathematical scaffolding known as a reference string. And it's a way of really making the computations that you need to do for a zero-knowledge proof sufficiently speedy that you can get this stuff to public networks straight away. So it allows the kind of the proof sizes to be quite small. and the amount of work that needs to be done for you to send a transaction to be kept relatively low. What it does mean, though, is it's predicated on computing a kind of encrypted number,

but no one must know what that encrypted number is. And so the way we did this was through a sort of form of multi-party computation, where we went to our community of people who were interested in the Aztec protocol and said, will you take part in this ceremony? And this ceremony is such that it would require every single one of the, participants to collude with everyone else in order to be able to reconstruct this number that actually needs to be destroyed and never known. So if just one person behaves honestly and they destroy their toxic information, the system's secure. So we thought we can design this ceremony

so that it's not just good for the current Aztec system, but also for future smart systems as well. And so we can go big on this. We can go out to the world and say institutions, individuals who are interested in privacy, preferably as maximally geographically distributed as possible. Please come and take part one after the next, layer in your toxic information, your toxic waste. Please attest to the fact you've destroyed it. And in doing so, we can create this really secure reference string that everyone knows and trusts is not susceptible to corruption. And so that's what we did.

We ran that ceremony for, in the end, about two months. Originally, it was going to go on for just a month. But we had a lot of interest from participants. we had 200 participants in all, of whom just under 180 successfully completed the computation. And those participants came, yes, largely from the Ethereum community, but also from the Tesas community as well. We had major banks and institutions. We can't name any one of those institutions, unfortunately, because we've been going to release that information in their own time. And the point is, if you can look at just one participant, you as a user of the system, and say, well, I trust they didn't collude with anyone else.

you then know the setup secure. That's how the ignition ceremony worked. How did you design this ceremony? I mean, like, was there sort of a threshold that you were looking at? Is 200 sort of a good agreed upon number, or is it the case that would it be better to have 1,000, or does the benefits sort of flatten off after you reach a certain threshold? There's only kind of one perfect number, which is 7 billion, but it's kind of somewhat unworkable. So you'd like every participant in the world who's ever going to conceivably use the system to take part, But the truth is, obviously, it's given the amount of time that it takes to do this computation, I mean, we really actually shrank down the length of this reference string to make sure the

computation could be done on a home computer. And even including 200 people, that took 30 days plus the time that we added on at the end. So at 200 people, our sense was they were sufficiently well distributed geographically. You can see them on a map. If you go to our Ignition website, which is on the Aztec Protocol website, you can actually see where all of these people, where most of these people came from. There were a few people who decided not to declare who they were or where they were from,

and that's fine, but most people have attested. All you need to know is that if some handful of people that I look at, you know, be that Vitalik, be that Tesas Foundation, be that some institutions, if you feel it's inconceivable that these people knew one another, interacted one another, shared their data, that's sufficient for you to know

that this reference string is, secure. So 200 people, there's no perfect number, but it feels that the probability is wound essentially down to zero by having 200 people who provably mostly don't all know one another and have an interest in making the system secure. So how similar is this ceremony to, let's say that the ceremony that goes into creating a root certificate? And in that case, I mean, for the little I know, but the ceremonies is like they're fairly robust and then, you know, people are locked away in bunkers, et cetera. Like, what is the level of security that these ceremonies provide? What's the benefit of having like this level of security as opposed to just doing like a

multi-party computation with 200 people like randomly picked on the internet? The ASIC NPC was structured in a way that we didn't need to take as many kind of extreme precautions as the ceremonies that you're describing. Our ceremony is also the construction of it. it's based off of the Zcash sattling multi-party computation. And so it's the security proofs behind it are relatively conventional. The reason why you would want to do things like lock yourself away in a bunker or drive out into the middle of the Gobe Desert with a laptop that you assembled from like secondhand parts that you've sourced from all over the world,

a lot of that is because a lot of these multi-party computations, they exist in two phases where imagine you have a set of participants. A lot of these NPCs require the... participants to generate some toxic waste, but then keep hold of that toxic waste and kind of preserve it whilst everybody else participates in like the first half of the computation. And then the MPC will proceed into a second phase where everybody then needs to use the toxic waste that they previously generated to perform some extra computations. And that's extremely dangerous because that means that you need to keep hold of this toxic waste,

you need to know what it is, needs to be lying around your computer on memory, in memory, on a hard disk perhaps, and you need to be extremely careful about exposing that. Toxic waste. For the Aztec NBC, it's a much simpler affair where there is only a single round. When you participate in the ceremony, you generate some toxic waste, you force the computations, and then that's it. Once you've taken part in that single atomic process, you can destroy your toxic waste and forget about it. You don't need to hold onto it. And so that makes the ceremony a lot more secure in the means that we don't need to take as many extreme precautions. I'm reasonably sad and that this setup works because I also participated in it and I destroyed my

toxic waste. So now we have this trust. it's set up with this very long number that is secret to every single person. So now what you guys have done is you have created seven different kinds of proofs based on this. So from my understanding that send, swap, dividend, mint, burn and public and private range. So what kind of business logics do these building blocks actually allow you to build in a privacy preserving fashion? So the business logic that it enables is, we have three main types of transaction that you can do with these.

You have your basic unilateral transaction, like I'm sending you private die. You're sending me private die or private tokens. You then have a bash or swap proof, so you can take two different private assets, trade them amongst two people. Like if you and I wanted to say swap private die for private eth, then you would use this natural swap proof to do so without rebuilding information. We also have something called a dividend proof, which is a way of proving that some encrypted sum of tokens is equal to a percentage of another

an encrypted set of tokens. So you can use that to create interest-bearing, dividend-bearing financial tokens. On top of that, we also have what we call mint and burn prints, which is a ways of just directly printing or destroying private tokens without having to convert public tokens. And so you would use these for a fully private financial instrument. So if you wanted to create, for example, a private loan, like at syndication and issuance, you would then use the mid-proof to print, like, these loan tokens. And similarly, a bank proof where you can, which can be used to destroy tokens. So, Sebastian alluded to this earlier.

But basically, the moment that actually something is within the ad-sec ecosystem, I'm actually giving a note, which is a claim on an asset. So this note model is, you know, the UTXO model that we know from Bitcoin, and Zcash and so on. Why did you choose this UTXO architecture? Because basically, working with Comtec Smart contracts is more difficult in the setting, no? It does add complications. The reason why we went with the UATXO model is because it's significantly easier to give strong privacy guarantees in a UTXO model than it is in an account-based model. Because in an account-based model, imagine you and I have encrypted balances of some token. If I want to send you some

an encrypted token, I need to somehow add to your crypto balance. And I, myself, I don't know what your balance is. Now that, it can be done. We chose deliberately to not to go down that route because it would make our zero launch period significantly more expensive to, like in terms of gas costs on Ethereum to verify, which would have made the transfer costs much higher. And the kind of the overheads of ETCS terminal, we can abstract away with our own like, develop. kit so that if you're a developer integrating Aztec, you don't need to worry about the UTXO model SDK exposes like straightforward interfaces that you would expect from a traditional account-based model, like, you know, get some of these balance, some somebody tokens.

Logger term, if you want to break the transaction graph entirely, so you want to hide not just the values being sent by the identities, then that makes an account-vis model extremely difficult to do because if you're hiding people's identities, then you don't really want there to be. be a kind of like one encrypted number which represents somebody's balance because making repeated modifications to this balance, it's very difficult to do that without leaking the fact that those transactions are connected. There are ways of doing it, but they come with some significant drawbacks. It's much easier to use statistical analysis to find out what's going on in these systems.

So you spoke earlier about the fact that you're moving to a new system called Planck. So basically so far you've had these seven different kind of proofs that one could kind of assemble to different business logics. But my understanding is that this Planck architecture allows you to do general computation in a much more general way. So how does that work? And what does that allow you to do? So the way it works is you can create arbitrary

So in the They're technically called arithmetic circuits But effectively their programs You can write traditional computer programs And convert them into zero-notch proofs So you can then effectively prove to somebody Server mathematical proof that you have executed a certain computation And you can choose to keep the inputs and outputs of that

computation private and encrypted And you can use that to create things like private tokens and private transfers, but obviously it's much more expressive and more powerful. And so you can evaluate complex business logic. You can do things like evaluate multi-party computations to do not just bilateral trades, but like multilateral interactions, like rimsynditures or those kinds of more complex systems. And so what we want to do with it is effectively add programmability into the ASTIC protocol

so that as a developer, if you're building a building a, private token or private asset or private anything, you get to program yourself what the transaction logic or the business logic is going to be. And obviously, this is a lot more extensible than having to assemble your logic out of seven specific groups. Let's move on to the ecosystem. And I mean, one of the things that I find particularly challenging with regards to of protocols that build on top of Ethereum is that it's required upon apps to integrate these protocols in order for a large number of people to be able to use them. How do you guys, so look at this problem and how are you working with wallets,

DAPs, and other applications within the Ethereum ecosystem to integrate Aztec widely? and are there ways that we can sort of generalize these things so that anybody using any application would be able to leverage Aztec without the app itself having, needing to integrate it? So I think the first answer to that is the way we're working with the ecosystem is principally through our SDK. So it's this thing dealing with these private assets, as Zach was alluding to you earlier,

it's pretty complicated. You've got to manage private notes viewing keys, all kinds of structural complications. So the first thing we can do for the ecosystem is just try to make these complexities go away. And the SDK is the sort of, I won't say a black box, but it's the management system that makes dealing with private assets as close as possible for the developer to dealing with an ELC20 token. There is some extent to which it is impossible to make privacy, just a switch you can just turn on and off

without any real integration at all, not least because the management of your state, the way you record ownership of assets, is just markedly different by definition to visible assets. And so I think there's never going to be a point at which you can just say, here's your privacy switch, turn it on, turn it off. Again, probably the closest we can go to that is by working, and this is a kind of a long-term project,

both for us and for other people in the industry, to develop some language norms around a dark contract system. So in other words, doing as much as we can to go back to the engineer, to the developer, and say that we don't know

exactly what you want privacy for. And you might want to, you know, tweaks, you might want some additional logic. You might want to keep, for example, stream income. You may not want to just send income. You might want to have all sorts of conditions around escrow management for payments

that we haven't thought of and haven't expressly provided you with a proof to do. And so, probably the best way that we can put that into the hands of the developer is by moving to a dark contract system in the longer term where we can enable the developer to send a variable private to say, I don't want to expose a balance in this asset, or I don't want to expose the conditions or the inputs around how I apportion a payment between two parties. Whatever it may be,

we need to put that power back into the hands of the user. And that's why long term, It's inevitable, I think, that these smart contract languages are going to have to absorb some concept of what it means to turn a variable private. Is there any work being done in this, to sort of move things in this direction? Is this something that we're seeing already, or we're just too early for that sort of thing to occur? It is early. I mean, it requires a slightly more sophisticated form of developer, by definition, because they've got to understand a little bit more about about how zero knowledge technology works. But it is also something that it's firmly on the mid to longer term agenda.

It's just that we can probably deliver privacy using a sort of 80-20 perito rule. We can probably deliver packaged privacy rather more directly without the complexities of an entire language to go around it, through our SDK at the moment, through using a number of kind of out-of-the-box proofs. In the longer term, though, that will certainly, I think our questionably be a few. feature of smart contract programming is that you'll have, you'll actually be in a dark contract setting. So it's not an immediate pressing concern for us because the things we really see that's being used for, things like payments and escrow and that's all the low-hanging fruit that we can get to much, much, much faster. Is there anyone already building on this protocol?

There are people, no one we can announce at this point. As much as anything, you know, we're six, seven weeks into the life of the protocol. And at the moment, it's proof. of concept. So I'd be kind of hesitant to name any names at this point. Obviously, it's a pressing concern for wallets to integrate the stuff, to be able to deal with private assets. And there are some, I think anyone doing payments, whether it's, you know, sending of salary or peer-to-peer payments or merchant payments, anyone doing that kind of activity on Web3, clearly privacy will be a prerequisite and clearly we're trying to encourage adoption using our SDK to those kinds of early users. But no one would prepare to talk about just at this point.

Okay, I see. And as a company, what's your business model in all of this actually? So that's great question. It's not something that we're publicly nailing our colors to the mast on. That's partly because I think we have to see, to a great extent, how people use our privacy products to be able to work out where best to monetize and we're best to make sure that we're not introducing frictions which will deter users. So, I mean, it's certainly possible to say we've spoken a little bit about these privacy proofs. We've not really talked much about their prospects for recursion, because of course, snarks you can use not just to send a transaction private, but also to roll up transactions and to get efficiency. And so it may very well be that

someone providing, for example, a roll-up service can say, okay, ordinarily it would cost you, let's say low hundreds of thousands gas to do a private transaction which you send straight to main net instead of that send your transaction to us we won't we won't look under the hood we can't because you're sending us a private transaction but we can roll up and aggregate your transactions with 100 or 200 or 300 or 300 other transactions and then repatriate them send them back to main net and so what that means is we've now been able to amortize to split the gas cost of that one transaction amongst several hundred transactions rather than you burying the entire gas cost on your own.

Now that actually, I think, for a roll-up provider, offers in one model of this world, quite an interesting business case because you can say, okay, we've now managed to reduce the cost of doing business on main net, and we can probably make a sustainable margin by being one of the major roll-up providers. There are also ways by which,

possibly in the future, our SDK could earn revenue by, you know, developers paying for use of the SDK to make dealing with private assets really, really easy. So those are kind of two potential avenues of monetization. I won't say we're wedded to either one of them yet, just because I think it's going to depend a great deal on who's integrating privacy into their data. As interoperability becomes a norm in the future,

and I think we can all agree that this is where things are heading, how do you see Aztec play a role in providing private transactions between chains? Is that something that would be possible? and that you're looking, that you're sort of thinking about? It is something that we're thinking about, and absolutely something that's possible. It's going to take a little bit of time to fully implement trustless private swaps

between chains because the most practical way of doing this, or maybe not the most practical, not a secure way of doing this, is to embed light clients into these blockchain protocols. So, for example, if Ethereum had a Bitcoin-like client, as a smart contract, then Ethereum be able to reason perfectly about, relatively perfectly, about Bitcoin state as well as any other Bitcoin need. But obviously, you can't right now implement the Bitcoin critical as a smart contract on

Ethereum because the competition of it has many orders of magnitude too large. But this is something that Snark's cannon will help with. So you can have a, for example, a smart contract on Ethereum that verify snark proofs that where you have a SNARC circuit, a SNAC program, that effectively acts like the Bitcoin-like clients and through recursive snark composition. Basically, you have a SNAR circuit which will validate Bitcoin blockheaders and repeatedly. And so you can build up a kind of an unobstating of Bitcoin state. And to do so, where that kind of that computational burden, it's offloaded to a single

transaction center instead of the entire Ethereum network. And we see that being extremely practical in the future. Zero knowledge technology does need to improve a little bit before that's become, for what's fast enough to do that, evaluate that kind of complex logic, but we think we're at the most only a year away from doing that. And then that will be very exciting

because we can just embed like clients into protocols like Ethereum to do private ones. That would be really cool. I mean, this also brings to mind the question of, you know, use cases for zero knowledge.

And, you know, we've seen a lot of use cases around things like scalability sort of come up in the last one or two. two years. In your view, how much of the ZK research is focused on doing things like scalability through roll-ups and how much of the research, at least in the blockchain space, is more focused on privacy? And do you think there's a good balance there? Or should we see more of research and interests coming into the privacy side? That's a good question. I think the majority of the research is on scaling because that's seen a lot of people, particularly the end of condition,

see that as a kind of existential problem that they need to solve. There is an extreme amount of overlap between scaling and privacy, or at least privacy, like the solutions for privacy can be applied to scaling. It's not necessarily the way around. So I do see them converging in the future. There's a lot of research that we've been doing around for our privacy protocol to improve the efficiency of Plunk that can be directly translated into scaling. So there's some work. that's been published recently that we've done is to make a plot more efficient. But it's also being used to explore scaling specifically representing state trees, like Ethereum's state, in a way that's more efficient than the Merkel trees that are currently used.

And things like that, there's a lot of cross-pollination. So I do see the two kind of research paths emerging in the new future. With all of the innovations that are coming out of the ZK space, so like to the user of cryptocurrencies, people who use Ethereum, et cetera, that there doesn't seem to be a whole lot of excitement around privacy preserving systems. And more generally, I just think, you know,

as someone who uses signal for 90% of their messaging and doesn't have like a Facebook account or this sort of thing. Like, you know, specifically for privacy reasons, I feel like generally it's hard to get people excited about privacy. What are some of the best ways you think that we can get people excited about privacy? Is this something that's reserved to a, you know, a sort of niche of people or are there broader, are there ways that we can make privacy more attractive to, like, the general public?

Yeah, so I mean, I put it that you can more easily get people exercised rather than excitable about privacy. And what I mean by that is, as I alluded to earlier, you know, whilst we're doing things like putting tiny amounts of our capital into CDPs or into compound or whatever, there's nothing really about those transactions that tells us that identifies us that tells us, you know, where we go and get our coffee in the morning where we live, what our spending habits are, what our preferences are. So really, there's no question that privacy becomes important and something that the average everyday person becomes extremely exercised about as soon as they feel that they're starting to use Web3 for things that tell their story about them. So take an example, payments of salary, streaming a salary. As soon as someone's starting to pay salary and to receive a salary on Mainnet,

the receiving salary is going to immediately say, well, I'm not happy with this being broadcast on Mainnet. my onbound transactions, people who are receiving money from me out of that salary, being able to tell how much I've been paid. I mean, we had actually one internal example in our company, which was quite funny because we're a privacy company. It was actually Paul Burke, you know, run Sabley and Tom Waite, one of our engineers. And Paul sent some money to Tom, and Tom was then able to expose Paul's entire crypto trading history just by looking at Paul's account. That's one point at which, you know, before that transaction occurred, they might have thought nothing

of it. But as soon as they realized all of the reservoir of economic history that one of them had already built up on main net, thinking actually it wasn't all that significant, that the realization came, wow, this is an absolute prerequisite to doing any meaningful day-to-day activities on these public networks. So I think it's going to be a matter of people getting exercised, not necessarily excited about privacy, because they feel they can't really do anything meaningful on these networks without it. Oh, I'm totally excited about the privacy. see. So the one last thing that I would really like to talk about is the security standards. Cryptography, when it comes down to it, it's super hard maths, and it's easy to get it wrong.

So basically to demonstrate that early last year, so early 2019, Zcash fixed a bug that had been known to them for a year. It was a cryptographic flaw in a paper that they used. The if exploited would have allowed anyone to create an arbitrary number of Zcash tokens that would have been undetected had they been created in the shielded pool. I mean, obviously Zcash has been around for a long time and they have fantastic scientists and basically their subject matter expertise is fantastic. So basically what kind of security assurances can you give the people who use your SDKs and actually deposit tokens in the pool that you give them then a tokenized claim to?

What kind of security guarantees can you give these people? When it comes to the security of a cryptic algorithm, there's really three. three main categories where it can be exposed as being insecure. The first one is just simply implementation. You've not correctly expressed the mathematics and code in your software as buggy. We want to kind of assure people who use our protocol that the code isn't flawed. We've gone through two full security audits on our small contract and associated code to validate that, yes, the code is a correct expression of the mathematics and there's no vulnerability on that side of things. The other two ways that a Cryptrogat protocol can be exposed in secure is either there is a

flaw in the security protocol. So every CryptroGryor protocol has a soundness proof that demonstrates that in terms of mathematically prove that the only way an attacker can compromise a system is by performing specific computations that are considered to be basically impossible, given today's current technology. And so if that proof has a flaw, then the protocol will be insecure. That's what got Zcash. And Asex proofs, our signers proves, they've been validated by quite a few photographers now. I mean, obviously, I can't give like a perfect claim that it will never be, how to be compromised. But, you know, it's extremely confident. I can be extremely confident of that, particularly with the

Garza Plonk, because one of our co-authors was Ariel Gavison, the same person who actually found the Zcash bug. So I'm, yeah, I'm, I'm, I'm, I'm, I'm, I'm, I'm, I'm, I'm, I'm, I'm, I'm, I'm, I'm extremely confident that there's no underlying form of soundness proofs that we have. The third way that a protocol can be compromised is if the cryptographic assumptions being used are not strong. And so the idea is, I mentioned before previously that a security proof will show that an attack has to solve, perform certain computations that we think are impossible. Obviously, if those computations sound to not be impossible and turn out to be quite easy, that's a problem. all of the technology that Aztec uses, all of our cryptography cryptographic protocols,

they rely on very standard computational assumptions. They rely on crypticabic assumptions that are based around elliptic curves, which have been established for decades now, and so relatively conventional. So on that count, also, we have an extremely hard degree of confidence that are protocols secure, and if the underlying elliptic curve primitives tend to not be secure, then basically that has ramifications for things much wider than Aztec. the Ethereum protocol itself won't be secure in that setting. Absolutely.

So from you as a subject meta expert, when do you think quantum computers will break these forms of cryptography? So yes, quantum computers. I might be one of most biased people to ask that question to because obviously the consequences of quantum computing becoming practical are severe for us. We have to move to quantum secure. Pretty systems, they're slower than as efficient, but ideally not one. I don't want to do that. Generally, I think that we're at least multiple decades away from quantum computers being practical. There's been a lot of developments lately from Google and similar companies about the concept of quantum supremacy, whereas a milestone has been achieved in quantum computing where quantum computers can perform a computation more efficiently than classical computers,

which is a big deal. That competition, however, is the measurement of quantum mechanical noise. So I think it gives a false impression of how advanced quantum computing is. Generally, to do something like Run Shores algorithm, which is the algorithm you need to run on a quantum computer to crack an electric curve, you need an extremely large number of quantum bits in your quantum computer, and the difficulty of keeping a quantum system stable increases exponentially with the number of bits.

So like a 32-Q-year system is not twice as difficult to achieve as a 16. big cubic cubic-cubit system is actually, it's at 2.16 times harder to achieve. And so given the number of qubits required to run short's algorithm and the current state of quantum computers, I mean, I'm very confident that we're going to have a, basically, we're going to have a lot of warning, many multiple years of warning before quantum computers were compatible enough to break a liquid curves. So I'll have plenty of times on my grade, and I don't see that happening for a very long time. Well, that's reassuring. So before we wrap up, tell our listeners where they can

find more information about ASTECH protocol, perhaps even integrate ASTECH within their Ethereum apps or DAPS? Yeah, thanks. So the best place to find information on us is ASDICProticle.com. From there, you can get straight into digging through our docks, integrate the SDK. It's a pretty quick and simple process. We've made it really fast because we wanted to encourage integrations at Hackham, so we want people to be able to adopt privacy super fast without it getting in the way

what they're doing at hackathons. And we've got some nice interactive docs there as well. We've got a new research page which shows you all of mathematical research that we've been involved in or produced as a company and some explainers as well. So if you're a kind of amateur mathematician and you want to find out a little bit more about zero knowledge tech, hopefully those explainers will help you understand, get a bit of intuition of what's going on without having to kind of sit through these 2030, 40, 50 page research papers. And also join our Telegram. We've got a telegram channel, Aztec Protocol, and also a Twitter, which is where we send out most of our major news releases, et cetera. And that's probably the

best way to contact us. And yeah, please feel free to reach out. Hello at Aztecprocical.com is a good place to get in touch with us to get help with integrating the SDK or anything else you want to know. Great. Tom, Zach, thanks for joining us today. Thank you guys. Thanks a lot. Thank you very much. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter,

so you get new episodes in your inbox as they're released. If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.