Zac Williamson & Joe Andrews: Aztec - Privacy-preserving hybrid ZK rollup #499

Transcript

welcome to epicenter the show which talks about the Technologies projects and people driving decentralization and the blockchain revolution I am Friedrich and I'm here with maheroy today we're speaking with Zach Williamson and Joe Andrews who are the founders of adztec and CEO and Company president respectively second show you have been on the show before um twice actually in your case Zach can you briefly remind us what's what what as ad stack actually does and how the vision of the project has changed since Inception so yeah hi hi everyone and thanks thanks for having us on so Aztec has changed changed a lot over the years

um um also since we last spoke I think uh so it's been about it's almost six years since we got started in this space and Aztec's always been a privacy Focus company so building privacy reserving infrastructure 4.3 however the um the way in which we go about this has changed radically over the years as as the technology um uh that we can work with has improved and so our main focus now which I think Joe can speak more about is building a fully programmable privacy preserving um smart contract layer effectively an end-to-end encrypted blockchain yeah thanks for having us on I I can

finish some more more details I guess like to speak to what Zach was hinting at like over the years we've tried to build products with what was currently The Cutting Edge of cryptography and a lot of that's been pushed by kind of our internal research done by Zach and AV and F cryptography team um but the goal has always been to kind of build a kind of programmable private version of ethereum we just didn't have the the technology to to actually do it kind of at various points over the years so we had to settle for uh I guess slightly less functional versions of the technology and and some of those people will be familiar with so we had kind of Aztec 2 which is the first time we had CK money which did

just basic Z cash style private payments um and then we spent about a year upgrading that to add Aztec connect functionality in the form of kind of private D5 mediated on on L1 um and all of that was really kind of trying to push out technology with um the best of ZK snarks uh in 2021 and 2022 um but it wasn't really kind of the end goal it was kind of showing the the state of the technology at that time um and yeah we're thrilled kind of over the the recent months that we've been able to kind of actually work on our our end Vision which is uh abstracting those Roll-Ups into a fully generic version

that other developers can deploy programs to and that's what we call Aztec 3 will shortened now to just Aztec kind of the the realization of our kind of ultimate vision so if you look at each of these stages so basically the first time we had you on um you guys had just launched CK money so basically and you could you could deposit any erc20 token into your L2 and and you could transfer it within there too privately and you could withdraw it back to the L1 and then basically in ad stack 2 which is the second name we had you on um you had you had a lot of you know

these private token transfer trans transfers on L2 plus you had some D5 Integrations so basically you could send um tokens from a shielded pool to some L1 D5 contracts um and so basically the tokens they they were in fact resielded um so that kind of in a way gave some in some sense anonymity to D5 users on L1 this was super useful but as I understand it at stack 3 kind of radically expands on that Vision can you give us an idea of what when it launches and I think we

have to be very clear that basically this is um this is still there's not even a test net yet right so basically you want to launch this by the end of next year soon and that's it yeah um we could talk about the the roadmap in in a second but maybe just to kind of highlight on the point about the the functionality changes so if you look at kind of uh just the payments version of Aztec that was one circuit uh or one one kind of contract you can think of it written by the Aztec team um and it took kind of probably six seven months for the team to write that and and audit it and deploy it to make the the basic erc20 um L2 transfer uh functionality and then

with kind of Aztec 2 and Aztec connect we we upgraded that to add in kind of a few more uh contracts or circuits um an account circuit and uh which gave aliases and these D5 circuits which let you um kind of send send uh kind of tokens to L1 as you described um but those circuits kind of took a very long time for our team of cryptographers to to build an audit and the reason and for that is that they were all acting on on shared state so it's not really something that you can extend very easily so the main kind of breakthrough in functionality that Aztec 3 kind of affords is developers can now

write their own circuits um and they can have siled state or in interoperable state between different uh contracts um and kind of really generalizing what we were trying to do with with Aztec 2 and removing us from having to write the circuits we'll write one execution environment and then everyone else can deploy their own contracts and programs do that and and that's kind of the premise bar in Aztec uh there's a lot to unpack here and um maybe I'll start with kind of the cracks of the matter that I don't understand um yet I hope I will understand it by the end of this episode so there you are talking about different kinds of state

and I think this is kind of what I want to understand I want our listeners to understand by the end of this episode so how do we actually um have something without intermediaries um where you can have different sets of state that are still consistent with one another so maybe let's kind of start at the beginning so what our listeners will be familiar with hopefully um is um the zkevm because we very recently had Jody and David on um so the way that the zkevm works it basically it takes every op code um on ethereum and transpires it into a corresponding ZK of code and this is

very much what you're not doing so kind of work us through why because in principle um that seems like such a good way of kind of making everything private right basically you just take what you already have and what you know the evm can deal with and you kind of build a you know a ZK version of it so why did you not chose to go down this route and how um because yours sounds way more complicated um so yeah just walk us through this I can I can I can try field that one so the reason why we've gone down the street just because you cannot just wrap

the ethereum virtual machine in aziki snack and make it private and it's because of um the information that's revealed when you modify state so a a blockchain address core is a glorified State machine um you have some some database of information and transactions come in that change the database and you have nodes that check that those transactions follow the rules of your blockchain and the problem is that the that that database is public so even if you wrap the evm in Ezekiel snug you create ZK op codes the actual information that's going into this um like the database that makes up the state of your chain that it doesn't like the like wrapping

wrapping the the validation logic in a snot doesn't make the information um that's being transmitted private by like like nothing nothing changes about it um you could take you could go one step further and say okay well now let's let's encrypt the ethereum database let's say that every single storage slot on ethereum is encrypted with some encryption key that's um somebody has even then that's not that gives you very very weak privacy no privacy at all really because if you think about the um ethereum State database phase is basically it's a big key value database where let's take for example your ethereum accounts you have an address that's linked to a balance let's say you can encrypt that address

and you can encrypt the balance and you can still drew them through Ziggy snarks through ZK op codes you can modify that that balance that's the leaks a lot of information because you're if you repeated if you make repeated transactions from that address the same like on the same position in the database is going to have it's not values change so even if your addresses encrypting your value is encrypted um like you can see those encrypted values changing per transaction and therefore you can build up the transaction graph and build up like I did an identity of of who a person is this time not defined by their their ethereum address is defined by their position in the ethereum state tree that um that that encrypted balance lies

uh so so functionally it gives you very little just to turn ethereum into a CK snot you need a bit of a more uh more involved model to actually get strong user privacy and a big part of what we're doing is whilst the architecture is relatively complex the abstractions that you can layer above it and like kind of the heuristics you can you can apply to use it at least if we do our jobs right those will be very simple all right it's gonna add a few things like even if you could solve kind of the the act of kind of uh updating encrypted State and there's been a few papers where people are trying to solve this um you you still end up in a pretty weird world where you have race conditions so let's say I want to pay Zack

um and Frederick also wants to play Zach well we're both trying to modify the same piece of encrypted State um so basically you you can't have a system that resolves that on ethereum the The Entity that resolves that is the block Builder who executes the transactions um so we now give those transactions to a block Builder to execute then again you have further privacy leaks so um yeah you really can't get strong privacy um in in the account based model um so you have to have a very different uh kind of model and data type to actually build a privacy chain um and this is why we say kind of externally sometimes that the evm is not

privacy compatible so that's why we we don't build a zika evm we built a ZK VM which can have kind of privacy preserving properties which maybe Zach can talk a little bit about how that actually works so um from my perspective like I think like restating what what Zach has said maybe we start off imagining you know the The Ledger or the state as being you know um for Simplicity like rose rows and columns with like each row indicating let's say an account to start with and then the data that's there is kind of like balances data and

then there are transactions happening like if it's a normal blockchain this this transaction is happening and a transaction is subtracting from one of the rows and it's adding to another row in this model if you think of what a ZK evm like polygon is doing the fundamental thing is doing is when let's say I send a transaction and I subtract from Row 2 and I add to row 17. then uh it is the ZK VM is in the end generating a proof that when you execute my transaction The Ledger adds plus 10 to row 17 and minus 2 from me and that this is correct so if if there

is another copy of The Ledger with the updated balances plus 10 minus 10 the proof just tells you that uh that new Ledger is indeed correct what it doesn't tackle is the problem of sort of hiding that uh it is plus plus 10 in the first place right like ideally what we want to behave is the fact that 10 was shifted and we also want to hide the fact that 10 was shifted from 2 to 17 the problem that ZK evm deals with is once you have the transaction and this was the consequence of the transaction

the consequence is correct that is what Ezekiel evm is deals with but it doesn't deal with the fact that how do you con how do you conceal the n and how do you conceal rows two and rows 17 and that's kind of the problem that that you're starting to starting to solve yes that's that's exactly it that's a that's a great explanation thank you for that and yeah that you have you have to break away from the evm model to solve it when initially we talked about your Aztec cache or or the first version of your system it it was already solving this problem of if you have two in rows 2 and row 17 and

there is a simple subtractions as simple additions how do you kind of obfuscate all of that uh but that this was already achieved by Z cash in in some sense in um in in product history and now on now your jump is that if you imagine row number 16 let somehow that row number 16 could represent an entire smart contract with its code and with a data set that is more complex than a than a simple balance is that a is that a good way of imagining it yeah it's it's it's good Let me let me try and expand on that so what a small

contract domestic does is it um it effectively it controls a set of rows in the in the database um what rows they are it's it is up to the contract depends how many storage slots you're using um uh but you'll have some contract that defines the the rules and the logic around like which rows in the database can be modified who can modify them how they're encrypted and then what well sort of what will happen is that a a user will when they submit a transaction they will they will basically they will be submitting requests to to modify some encrypted state so they'll say here's some here's some old encrypted values here's some new encrypted values

this is a bit of a simplification actually I can explain why it doesn't actually work some but it's a simplification so you say here at serious and all the group of values here are some new encrypted values and here is a ZK proof that proves that I followed the rules of this of of the of the smart contract that controls these rows and um therefore you can if you verify the proof you can trust yep okay this is legit I don't need to know what's inside these encrypted values I can just the the the node can just update the state right so I mean if so if we if we kind of like imagine our huge accent sheet maybe it has like tens of thousands of rows we can say that let's say like rows 1000 to rows 2000

they are encrypted right like you can you cannot make sense of any of it and let's say like they belong to a to a Smart contract which which may be like a voting smart contract for example right so rows 10 1000 to 2000 belong to a voting smart contract and then what you are essentially allowing me to do so if I am a voter in in one of these elections I am basically sending a transaction and it's going to make some changes to rows 1000 to 2000 some part of of the state but what comes in is kind of like one

thousand and two thousand is kind of encrypted what comes out is also encrypted and but I'm also so when I'm submitting a transaction I'm submitting a proof that despite the input being encrypted the output being encrypted my uh the transition is kind of correct and my vote was counted correctly and I did not interfere with the election process yes um that's that's pretty much it it's kind of hard to do there's um but like I can yeah we can talk through some of the some of the some of the details of how to how like how to make that happen if that would be on Pinterest yeah why why is it hard to do maybe on a high level on a high level there are two problems possibly three one of them is

that if you have an encrypted database if you have it if you have a database that says there needs to be privacy preserving you can't really you have you you have to use a utxo model for your state so you can't use an accountabase model uh because it's not enough just to hide encrypt information associated with a row when a transaction modifies a row in that database you also need to hide which row is being modified which is a little bit hard to do in an account based model where you're basically every every state variable is is a is a it's a key and a value um and you can encrypt the value but the key describes like what's like what

information are you actually adding and changing to the in the database you can't really encrypt that to give an example of why it's difficult to hide State changes in a private environment let's consider the the basic token transfer case let's say I wants to I want to I want to pay you my how I want to be Joe I want to play um free trick um then what I'll be doing is I will be deducting tokens from my balance and adding to your balances um the problem is that in a in a if in an account based State model even if my balance is encrypted you can see three transactions coming in changing the same balance so you know that

um those transactions are affecting a person you don't know it's me but you know it's somebody and you know that for every transaction and therefore you can start to build up a transaction graph of what entities are interacting with which other entities even if you don't actually know their addresses and so if you want a private database you need it to be append only so so if you have a smart contract that modifies that can that can control some private State um it doesn't so much control rows in the database as it has the ability to add new rows to this database but it can't can't change existing runs it could only add um and then you can you can use the same tools as ecash used to delete records in the database so effectively you you have

a you have a data structure where you can you can add records you can destroy records but you can't change them and so you have so to to emulate um obviously you in the real world you do want to change values you know um if I want to um if I want to represent things like balances but you have to emulate that um by having some private state that represents a balance if I then want to send a token to Joe that balance gets destroyed and a new balance that represents my balance gets recreated at a different Row in the database and that is one less than my old balance and you can cons You Can Craft um your system such that you cannot link the creation and destruction of of data um which sounds a little complicated but

it is essentially what how Bitcoin works with it with its concept of unspeed transaction objects except just that we extend that to instead of representing cryptocurrency values it represents whatever a smart contract wants it to represent I think I I understand this so it's kind of it's It's a mesh up between the utxo and the account based model um but what I'm wondering isn't that terribly inefficient basically that if every time you kind of touch any state marginally you kind of have to destroy that kind of uh piece of the state and kind of recreate it at the end of the uh at the end of the

Excel spreadsheet in your example again yes yes it is uh it is it is a problem with privacy preserving systems um so take take it there for example if I want to send some ethereum to somebody my ethereum balance gets modified um which in the serious cost model is 5000 gas if I wanted to create a new account from scratch and add a balance which didn't exist before it's 20 000 yes uh privacy Business Systems have this um uh problem felt it felt it felt a bit more acutely because if you want to modify an existing um variable you need to create some information that destroys it well that's like one storage slots you could consider and then you have to recreate

the variable in somewhere else which is two storage slots so it does the the data throughput of a private privacy preserving blockchain is a lot higher than a transparent public chain which is why data availability Solutions are so important to us um and things like eip4844 uh there are other um ways to to mitigate this cost as well um particularly maybe I think we something else I don't want to jump the gun a little bit um by going into this but the in order to build complex privacy preserving applications it's not enough to have private state because the problem with private state is that

it's encrypted and therefore effectively is owned by somebody or a set of individuals um the the people who possess knowledge of the decryption key effectively own that state um and if you don't have that decryption key you can't change it which creates some large some some problems when it comes to creating complex applications any smart contract that requires a global state does this model doesn't work take for example if I'm building a decks and I needed I'm creating a liquidity pool so I need to know how much how many tokens I have or be given um of a given token type that needs to be public information um that is constantly updated every time a entity deposits into the into the

liquidity call you can't make that private not without very complex multi-party computations that are slightly beyond the scope of what we're trying to do at least in the next couple of years and so what you really need for complex private applications is hybrid State you need private state which is encrypted it's owned by individuals um you don't know when it's created you don't know when it's destroyed you don't know who owns it you don't know which contracts control the state um and a suit excerpt based and then you have regular Normie account based public state which operate which acts operates an X just like ethereum's State model does and and smart contracts have the ability to modify both okay let let's kind of dig into this a little bit say for instance I have

um private a private account with kind of private token balances no one knows it's me sort of thing um and I want to interact with a public amm um how would that work and what of the information that kind of I divulge um becomes public and how do you make sure that it's not traceable back to me I can start maybe with the user experience so I guess it it comes from the fact uh that that on Aztec an account is is defined by a private smart contract um not not an externally owned account like ethereum so effectively when whenever you do a transaction on on

Aztec you satisfy the conditions of your private account so it starts as a private transaction so you you modify some private State um and then if you're if you're kind of function call calls a a unisaw contract um you'll probably set up that swap in the private realm so you'll migrate some of your die balance um to the uni swap uh private contract um before you kind of send it to the public land for the amm swap you'll do all of that in in the private realm client-side local to your device and then the last thing that the kind of private setup function in the uni swap contract will do is make a a public

public L2 call to kind of execute the swap so leading up to that point all you can see on the L2 is someone somewhere modified some state that resulted in uh this public L2 call and then the contents of that L2 core will have some public information defined by kind of the protocol you're calling so in unisob's case it will likely be the asset you're trying to swap um maybe some slippage um and like a notional um but you can't see anything about what led up to that point um to kind of leak further information so you can't see my dress you can't see

it see anything like that and you can just see that it's a valid private transaction leading up to that point and at that point kind of the sequencer takes over and can kind of execute that much like a public transaction on on any other L2 I can try some like um summarize so this is what I'm about to subscribe is abstracted away from the user experience um but functionally what would happen under the hood is you want Shield to a random address um so everyone is for 10 East and to die iron shield tennis to a random address no one knows so so Tony has popped up it's owned by like ox like you know X Factor no I'm gonna say that is because it's just created just with this

transaction then that um that money then gets put into uniswap for uh instead of say either die trade and so people will see that the amounts of they will see that each got done shielded from somebody they will see that but they don't know who they will see that it gets put into unit swap and they'll see some die coming out um the die will be recovered by that like random address uh and then um that die will get shielded into the my my the my private account and again you can you can construct it's such that you don't know um yeah that that shielding action also provides you with no information so you you effectively you get anonymity you hide the identities of the people

interacting but you the critical logic is transparent so you still know the values going through unison the the imagination that's cropping up in my mind is like this idea of a Public Square and private houses where um where I mean you have a Public Square and whatever happens like in in a town and then whatever happens in the Public Square is kind of trackable seeable when you have you have private houses and in principle what happens inside my house is is just known to me and maybe in in Aztec you know the Aztec State can be visualized as the

combination of both the Public Square and the private houses where um anytime anytime I kind of interact privately with myself or with another users I have an anonymity set of all of the private houses so I let's say I send money from like my house to another house from the outside nobody knows what house the money came from and where it went except except the owners of these two houses sort of but then when I want to interact with an amm I can suddenly transport teleport my money from one of these private houses seemingly

into the Public Square in do a trade which might be an exchange of one coin into another coin in the Public Square everybody sees that like the Public Square activity is kind of genuine and then and then that resulting coin I can again transport back into my private house and the anonymity set is again the set of all private houses so nobody exactly knows which private house it went into but it actually went into my private house kind of that is I think that's a great analogy I could extend it a bit um with some kind of um it's not just like going from the house to a a particular stool in in the Public

Square um you can effectively imagine that uh you can route your your funds or your data through through any house around the square and you have to follow the logic to find in that house so let's say there's a let's say there's a kind of um a customs officer who does some sort of um stamping that this is this is a legitimate trade coming through you can write a stool in the Public Square that will only accept um kind of transactions that could have come through a certain path um uh which is defined by the logic of a composable smart contract and you could then also have two Public Square stores that could talk to each other so

um there's full composability between all the houses kind of on on the outside of the square and all the stores inside the square so it's not just a case of kind of how it was in Aztec connect where it's a bit more single shot where you can go and do one one interaction with your asset the interaction scope is defined by the contract and the set of functions um that the developer writes which can cross private to public boundaries so um actually that's that's really interesting right so now there's like actually you can maybe imagine the three sets of you know Land one is like the Public Square One is these private stalls which are basically the private

smart contracts as I see it and then maybe these houses are kind of like the ends accounts of the users that are holding the coins maybe we can imagine it like that and you've kind of mentioned this kind of interaction where I could start from like the end house according to a stall prove something to the private smart contract and then that uh that sends the funds into the Public Public Pool something happens in the public pool then it goes back to a stall and then it goes back to a private office could you give me an example of a real world application that would have such a such a flow now I can do an obvious one um I guess which we don't see on on

chain right now but kind of Consumer Finance so I could I could prove something about my um my private house which is kind of the income coming into it from from my job I could prove that to a private store which is kind of a loan broker um and that that stall can give me a credit score um and I can take that credit score uh to the to the Public Square um and receive a loan based on that credit score into my into my private account and kind of the only thing that's been made public in in that interaction is that someone's asking for a loan and they have a credit score above 600.

um but that that it's not revealing which house it was or anything like that or any of the information about the proof that was required by by the kind of credit score um private store so that's one analogy there's kyc checks um also some interesting game state that Zach's been thinking about as well cool yeah I think I understand um the vision of kind of where you guys uh want this to be at taught me through the technical roadmap and the challenges that you face along the way so I mean even for um I mean all of us we're eternally optimistic about timelines I mean I've been wrong about this many times and for you guys to say um you will have this ready by the end

of next year sounds like there are some major roadblocks in the way uh so I'll do the short-term roadmap and then that can kind of fill in some of the the major obstacles because there's there's definitely a few roadblocks uh in our path but um what we've been able to do for the roadmap is to kind of condense which parts are needed for mainnet uh and and kind of put those in one bucket and and then separate that bucket from which parts are needed for developers to kind of start to write applications and test out what's possible in this new this new design space and so in in the second bucket um we've actually managed to kind of remove a lot of the the heavy lifting away from uh the protocol and just

Define an optimistic version of the protocol which we're calling Aztec sandbox um and we're we're hopefully gonna have a release of that uh in early gonna Q3 um so you'll be able to kind of take that run it a bit like a local ganache or Foundry node and write programs in in our smart contract uh language bar um against that so test out these types new types of applications as soon as kind of Q3 this year um and then we'll kind of expand that functionality with a with a more centralized actual test net with persistent state so you can interact with other people's applications not just just local ones which we're targeting uh towards the end of the year and then we'll expand that again with a kind of decentralized test net

um uh in in kind of early 2024 um and then the rest of it will be kind of filling all the blanks and to actually get this onto mainnet which Zach can talk a bit about the challenges on on that Journey because it can no longer be optimistic at that point yeah so I guess the one of the reasons for the for the local map is is because we we we're also like aware of how how optimistic timelines normally are in this industry and we've Fallen prey to this ourselves in the past where we've internally been far too optimistic about how long it would take us to execute on building Aztec on Aztec connect and so part of the reason for the end of 2024 timeline is because we actually want to hit this one um it's uh it's not two years optimistic it isn't two years um

but uh well one and a half now there are three key obviously core technical components to to Aztec one of them is the um is decentralization as I said like we want to launch on mainnet decentralized from day one um there's the there's what like I guess can be turned heavy engineering which is just like building out the nerd architecture the software to run a node to run a sequencer um like this the the the the kind of the core protocol level technology and then there's cryptography which is actually building out our cryptography back-end software like the the actual algorithms that we'll be constructing these are notes and verifying them and um and and also I guess under my

cryptography is also the the circuit architecture actually building out the ZK circuits that will got like govern um this entire protocol just the heavy engineering work alone I would I would I think is is I would I would wager is more complicated than um many other um L2 projects out there just because of the complexities around this hybrid State model um and then on top of that you have this um like decentralization like track where we're building out the decentralized sequencer um long trivial and then there's the cryptography which is uh there's a reason why no one's really attempted anything at the scale before and that's

because the cryptidus isn't wasn't good enough um I took a lot of work to make it good enough there's been a ton of advancements over the last few years uh some of which we played a hand in but uh we're confident we're in a place now where the fundamental proving Tech is fast enough to construct these very complicated xenos proofs um in a on resource constrained platforms like laptops like phones in web browsers but it's going to take a while so build that out and audit it and make sure that it's secure yeah to give you an idea maybe of the kind of uh cryptographic kind of challenges so I think for

for these programs to actually run in the browser you have to prove the correct execution of a set of rules so you have to know that private program has uh kind of it's only updating uh or adding utxos um that it owns and signatures in checked fees have been paid all of these rules that are defined by the protocol have to be kind of checked by by a protocol level circuit and every time you call a smart contract on Aztec you have to do that proof um and and you do that through recursion and over the years and then I think with Aztec Aztec 2 we used to do recursion in our roll-up circuit and it would be done

on a 32 core uh kind of machine in AWS and it would take minutes to kind of do a single recursion um with some of the latest work we're doing for some L1 private voting work we've got it down to 15 seconds in the browser but for for Aztec uh Aztec 3 or the next version of Aztec um we need to be able to do multiple levels of recursion for a single transaction in kind of a couple of seconds so we've got to go down another order of magnitude um which which is probably a nice segue into some of the cryptography research and and Goblin plonk uh that we've been working on um just to kind of um repackage this a little bit and basically the the entire

computation that has to happen client-side that's because you want to divulge as little information as possible and you kind of create the the proofs client-side instead of just sending it somewhere right basically if I send like um a vanilla ethereum transaction that that's like literally zero computation overhead for me I just send it um to the mempool and that's it but basically because part of the system runs client-side this kind of uh creates this overhead that needs to be handed in browser or in the client correct yeah the prime the private side of the system all has to run Cloud side so before we get into like the

cryptography um the novel cryptography Goblin plot that that you have created um I am actually curious how the system you are targeting differs from Mina which is another one of these systems that are building privacy preserving smart contracts is it the case that these are radically different versions or are the similar Visions with different technical approaches I think there's somewhat similar Visions but from very different perspectives um when we there's the reason why we've only recently embarked on building this

program elastic network is because we weren't comfortable with the state of ZK cryptographies and we figured what we really want to do it'll be too slow uh the previous will be too slow it'll be a bad user experience uh effectively what we want to do is we want what we build to look and talk and Quack Like a smart contract where you don't need to be a cryptographer to write smart contracts you it's like we've got this language called it's called a rust-like syntax uh it's but um anybody using it at least in its full version it should feel familiar to solidity in terms of how it operates

with it differs slightly from meaner and that's so obviously I'm not an expert on Mina so I don't want to mischaracterize what they're doing uh so um with Mina the getting the kind of composability that you get on ethereum is is possible but it's it's a little bit more involved where you need to sequence what would normally be one transaction over many transactions and uh I don't believe they have their own like specific smart contract programming language at its core the the thing about Aztecs architecture is that we want full composibility which means we want contracts to be able to call other contracts I can call contracts I

can call contracts and effectively each contract call is it has to be its own Zero's proof of correctness and therefore you need ins if you want if you want that kind of compatibility at a bare minimum you need a some kind of higher level ZK circuit that the that the user the client is running creating a proof of that will verify all of these private contract calls and sequence them properties so that like they're they're all they're called semantics are all correct and everything is is the rules are all being followed in reality it's actually much more convenience and more practical to do multiple arbitrary layers of recursion so you have lots of pre-verify pre-verifying pre-certified proofs and I believe my understanding is at least

when Mina launched that wasn't really practical um to do client-side uh so that they've taken a different approach um but that's kind of where my my understanding of the protocol ends and I don't want to miscarriage what they're doing is is a extremely impressive project and yeah um I I just think that they've made some slightly different design choices I think part of them are motivated by the fact that they're only at one so they they um they have different uh requirements to us as well on that front right so is it fair to think that you're betting on kind of like this recursive proving kind of architecture because fundamentally as we said like there are like private houses stalls and

then public squares and then my my big transaction has to go from a private house to a stall to a Public Square back to a private store to a private house so it has to touch all of those pieces and somehow like the recursion is you take one step and you generate a proof for it and then the next step verifies the proof for the first step does something generates a proof for both the steps together then the it goes to the Public Square that's like step three it verifies the proofs for the first two steps that's something generates a proof for the entire thing and so on so this is essentially why you need recursion

source of maybe I can try and rephrase that because it's not quite that iterative so what happens is Imagine imagine if you if you imagine you're moving between private houses and you're moving between private schools uh and like each action like each time you're between let's call that a step what you really need is you need some entity monitoring these steps checking that they're all following the rules basically you have some kind of spy that's spying on the on your on your actions going okay it's the step correct it's a step correct is this correct correct this is what we call the the kernel circuit it's it's the meclashes borrowed from from zaxi so effectively the color circuit is is the entity like the the that verifies all these steps are correct and obviously because it's basically acting like a giant spy um the proof of the candlestack it must be made

client-side uh without elix so you need way too much information if you send it to a third party and that kind of circuit is doing lots and lots of recursion and um you also it's it's more practical to architect things such that the you actually have recursion at the kernel circuit level so you can think about it one one way of thinking about it like um is that you have this kind of millisecond which what it'll do is it'll it'll verify that one of these steps between like the private houses the private stores is correct and that's it um but but what the kind of second also does is it verifies a previous iteration of itself so you have a kernel circuit for step one verifest at one and then at step two you have a kennel cycle verifies step two and the candle circuit they're verified

step one um and on and on you go and so you've you've made all of your private um steps and then you step out into the public sphere and then that that proof of the kennel circuit gets kicked off to a sequencer to complete the transaction and so that's um it requires a lot of compute complexity to to pull that off um in a ZK system right and so your fundamentally or these Aztec wallets will need to be able to generate these recursive proofs inside the browser and like that's also going to be an engineering challenge to build wallets of such complexity yes so so we we know how to

do the cryptography at least we're very confident we do uh but it's but it's turning it from paper to code is is not a trivial process the plan is that the um we will be maybe Joe can speak about this more but what we're calling an Aztec wallet is it's more of a it's something that is something that if you're actually building a proper like wallet um to manage Aztec funds you would you would incorporate our software within it it's basically um it acts like a little bit like a miniature node that's uh um it's a bit like considered like web3.js or ethos.js1 anything like that wibbling equivalents like aztec.js and you can make calls to it so to construct

these proofs um so yeah the goal is to abstract rule that away from the actual like from application Developers yeah like for for kind of like an end web page um you'll connect your your version of Aztec JS which will be running uh like an RPC client server model um and and your wallet is basically implementing that through through our open source software and that kind of gives you access to private State Management um so which utxas are yours um and also kind of the ability to simulate and execute uh these private smart contract programs and ultimately construct the proofs so we can do some of the kind of engineering uh for

wallets and to kind of make this a little bit easier but there is still a lot of a lot of work ahead of us to actually get it fast enough uh to be a good user experience um which which is kind of the extended timeline we have here so I assume that the amount of gas that you have to pay on Aztec is also uh linearly related to the computation but it seems to me that as a user you can't always know how much computation you actually have to touch in order to do something because basically you say if if like um if you're touching a state that like a thousand people have access rights too you kind of need to update that accordingly right so basically if

you add like one more person who can update something you kind of need to deploy an entire entirely new contract to do that um I mean if I do some something on ethereum I kind of know um what kind of gas is attached to any of the op codes that I use and kind of it modifies that state is that necessarily apparent on Aztec I can try with a private private world and then it's actually I'll talk about gas metering in the public world because I guess in in the private world you you don't pay for compute um because the act of executing uh the kernel proof is is proving that you've done the compute correctly yes

right yeah so computer is effectively free but what what you're right and saying is what you will pay for is kind of the the state reads uh and and writes and nullifications that result from that compute um and that's that's where there will be a kind of a gas cost for for the private World um and you can kind of you can see that based on what the smart contract's doing uh kind of what that will be but it could result in a variable gas cost for a certain transaction based on your utxos under the hood so that that's kind of um one thing we're hopeful that's going to be solved by by EIP 4844 if the cost of data goes down a lot it should

become cheap to do private transactions and then when you get to the public World it does act a lot more like ethereum um because someone else is doing the compute there so the the metering there there will be op codes uh in in kind of the public land that will get metered um and you'll pay a fee that has to cover the cost of the sequencer both executing that but also then constructing a proof of correct execution for the public transaction yeah just expand on that and to summarize so for for privates for the private domain you you you pay for state rights um and you know Adobe play State reads it's just state rights and

things like events which again that's kind of your broadcasting data and in the public world yeah it's much more familiar gas metering like it is on ethereum but just like if you think about ethereum most relatively complex contract calls do have a variable gas costs if I'm calling unit swap I don't know the like the routing logic effects how much I'm going to pay and so how do you figure out how much gas your transaction is going to be while you simulate a client site before you send it you do the same on Aztec simulation of transactions is very cheap because you're not making any signals proofs if you're just running the the logic so you can you can figure out ahead of time okay how much is it going to cost before you actually go through the effort of building the ZK proof and sending the

transaction clear I have a couple more questions as to roadmap so um you talked about um like the different buckets and I kind of want to dive into the heavy engineering bucket for now um so you already talked about sequencer decentralization that's kind of part of that to-do list um will that will your sequencer be fully decentralized by the time mainly at launches because none of the other layers have done that right so basically everyone's still fighting with with um sequence or decentralization at this point and basically if if I were to know that any of the other l2s were to be able to solve this by the end of next

year um that that would greatly alleviate many of the concerns I have about the edge ecosystem so is that already kind of priced in yeah I guess some of the the rationale for this this line of engineering is is is based on kind of the the nature of our Network and our desire for it to be kind of uh incredibly neutral and have kind of complete liveness um and I guess so so we're we're based in the UK and then like some of our our colleagues based in Europe and some are based in in the US and no one at the moment can agree on on crypto regulation so um we we feel like uh for any one entity to run uh a sequencer that deals with encrypted State

um is is a is a bit of a kind of Fool's errand um so we're looking for kind of multiple uh sequences to run which can maybe kind of conform to different regulatory requirements if they need to or or just act as like a decentralized uh quite a neutral layer not much like ethereum does so that's some of the the rationale and we face this pressure a bit more than some of the public zkebm based l2s because uh they can kind of just run centralized sequences and have kind of a path to decentralization which I think is part of the reason why no one's made significant inroads here yet because it's it's it's it's not the most pressing problem but for us we feel like

it's something that's needed for for launch and I guess like like how we get there um yeah we're kind of still in the in the RFP design phase uh we've had some some public um kind of discussions on our forum and some great submissions from external teams on on how best to do this uh but really yeah we're looking for a proposal that can take the technology we've built and ensure that if enough entities are running it the network can remain live and and with a good kind of throughput and user experience for for developers so that's kind of the high level goals here but it is going to be an engineering challenge to actually uh launch this uh but that's why we're starting now not not towards the end of

next year yes so so it is it is priced in but it is also the biggest online on the roadmap okay so um cryptography you guys just started talking about this um and we kind of got sidetracked a little bit um talk to us about uh plunken Goblin clunk happy to yeah so sir plonk was um we put together Planck um in 2019 so by in in the standards of ZK how quickly ZK crypto business trunk is absolutely ancient uh um and it was really the first

um practical uh Universal snarkers and it was it was it was a you could write zika circuits in it where you didn't need to con perform this trusses setup process per circuit uh things have moved along a lot since 2019 um where um you know we've upgraded flank says from server plan to ultra Blanc and now there's hyperplunk and there's been a lot of innovations that have happened over the last two years particularly one of them is that we as in the collective cryptography Community um has cracked how to construct uh like plonkish type systems using using a cryptographic primitive called the

subject um which is much more efficient and faster than we were using earlier um for us this is a very big deal because it uses using um it removes the needs to perform a like an algorithm called the phosphoria transform which is very very memory hungry and so um the latest iteration flock of the building which we're calling a hunk for highly optimized Planck uh the fear silent um is uh you use the subjects and we're confident that memory consumption will be once it's optimized at least of 20 of what it currently is um with things like Aztec connect and so that's that's a huge deal um particularly in when you're trying to run a proven a browser tab

um and then there's the a lot of development and work that's been happening on what they're called folding schemes which is effective it's a way of reporting Recreation proofs inside bricks more efficiently than what's come before and Goblin talk is kind of a slightly orthogonal piece of research there which complements folding schemes but it makes it it's effectively a way of doing recursion um efficiently it takes what like every when you're using elliptic curves and you want to verify proof you've got to do this it's called like non non-native um elliptic coverage particularly you you've got to do some very complicated mathematical operations that are difficult to emulate inside the zika snork circuit

and Goblin plonk Kind of re mostly removes that um difficulty uh makes them relatively easy to do and so you combine Goblin plot with folder schemes and then and and clock at some checks and you mash it all together and into a ball and you get a pretty system which is fast enough for Aztec it can do recursion class sites super quickly memory consumption is really light which means you can run complex circuits in a browser and the previous fast enough to to deal with the the earbuds at least that's the uh that's the goal that sounds wonderful how worried are you about using novel cryptography in production because basically it's like it's like super complex complex maths and basically all it takes is like a

single vulnerability right yes but we that is true um however we're not we have the luxury that we have we have our own kind of In-House crypto R D team and a lot of the research we publish ourselves with our own proof of security so we understand that second a much deeper level than a typical um software um development outfit a much deeper level and so that gives us some we so we have a lot of confidence that the tech we deploy is secure at the cryptography layer as in the previous security code the soundness is good it's a cure there's obviously when you're implementing local cryptography For the First Time The the biggest risk is in the software that your software doesn't

actually do what the paper um needs to the maths in the paper there's a bug there's some issue there's something you haven't seen which which causes it to become insecure and so that's one layer that errors can creep in is that the implementation of cryptography the other layer that errors creep in is is uh at the circuit level one of the big issues with ziki snook second design is under constrained circuits basically the second supposed to be enforcing logical rules that make sure that your transaction is is correct and it can't double spend however one of the most common types of bugs is where well actually The Logical rules you're applying are slightly more relaxed than you intended because you've ridden the program you've proven your second

incorrectly that's quite common you know we've we've experienced when we deployed Aztec connect uh and and Aztec 2 we we did have under constrained circuit bugs that some of us some of them we found um a couple were reported externally by Third parties um through a bug Bounty uh all of them we fixed and disclose publicly but it does happen and so there are some yes there are technical risks with building Advanced cryptography systems and deployment to production it's one of the reasons why why our timeline is so long is so we have a long longer time to order everything But ultimately one of the one of the frustrating things is that sometimes like if any applied

cryptographer comes to you and says I can build secure compute software 100 no bugs they're either lying to you or to themselves so I can't say that when we launch on mainnet everything's going to be perfect everything's going to work and there's not going to be any security issues what I can say is that we're going to have done our absolute utmost to I did like to to to audit the security to validate that what we're doing is correctly moving very methodically as we build this and we have a very generous bug Bounty um so that to help incentivize um third parties to to review to audit we wouldn't recommend that people throw very large sums of money thoracic in the first year of this operation uh because

ultimately the the only re the only thing that really proves a crypto cryptography protocol is time um this has been the case not just in CK and web 3 but like forever um really even nowadays the fundamental security assumptions that back elliptic curves that you can't solve this computational problem called the discrete leveling problem we don't have a proof that you can't solve it it's just that no one's cracked it for 30 years so we just we're like okay fine um it's probably good yeah basically we're going to do our absolute most at best to internally extort early validate our software glue muscle locally you know we've done this before twice now which is quite rare in this in in the sector to have deployed Advanced CK crypto Ezekiel to production

twice we've done that we've got experience we're going to use all of all of what we've learned to make sure that we've done as good a job as possible and then we will have a very generous about balance to be engaged with the community to try and help us spot issues as and when they come up and we would expect that basically the people's comfort with our second like the the how many how this volume of funds that people are comfortable putting in like we're comfortable seeing going into Aztec we'll just increase over time the the longer that we remain bug free there are some things as well um which kind of have extend our timeline in terms of like client diversity and working out what that

looks like on on Aztecs so um there may be parts of the system um where multiple implementations help get that confidence um so once we've kind of got a reference implementation built uh maybe it's for the roll-up proofs or maybe it's just for the verifiers um there may be ways to build in kind of extra redundancy um that I guess two implementations have to agree of the same code and that's something that will be starting kind of uh in 2024 once we have the full protocol nailed down working on testnet uh for other teams to start building reference implementation start building other implementations of our reference implementation to get extra security and help spot bugs

um that way so maybe one final question so in the history of this blockchain technology I've often encountered a pattern where some capability emerges and then people realize that it's not enough and then the next version emerges with more capability and then they realize that is not enough and then the third version emerges that they realize it's not enough I mean the fourth version emerges and then like this turns out like that actually addresses most use cases and that becomes really widespread so typical example might be you started off with Bitcoin okay I can

send coins and I can write a bunch of fourth like Scripts then people realized okay it's not enough to just send coins in a decentralized fashion we need to do derivatives contracts so a mastercoin colored coin all those things came up then came ethereum uh with a virtual machine and it's like turns out the ethereum is really enough for a massive uh spectrum of activities and then maybe like in the last 10 years if you look at public smart contracts very little has been built on top of the evm itself maybe maybe we can say Solana did parallelization of transaction

processing and maybe that's an innovation people still doubt it right so so that happened in in that space similarly in the Privacy space I see that in the beginning you started off out with zerocoin then came Z cash that did the cash aspect well and now when you did the cash aspect well the natural consequence was hey can we do smart contracts well and now you're tackling that and in your vision if your vision is achieved do you think like there is that next layer of privacy preserving smart contract systems that's that's still possible they are there

like elements of your system where developers don't have certain functionality and you will actually need to build a Aztec V4 or somebody will need to build the next generation of privacy preserving smart contracts or do you think that your capability is actually nail the Privacy preserving smart contract space and that's the EDM of the future in that space I can fill the question obviously I'm generally I'm very biased on this um why else is that would be yes but just to get back a bit and speak widely um like you're absolutely right on the observation right like this this iterative incremental progress I mean this is the really the fourth iteration

of a private transactions helping builds um going back from six years ago and the frustration has always been we've always wanted to do the complex privacy preserving transactions but it's always the text ever being there like the crypto isn't good enough crypto isn't good enough to drive it the crypto good enough and it's always like as soon as we Crest like some capabilities threshold like okay we can do some something more it's like originally Aztec was confidential transactions on layer one very expensive you didn't get an anonymity you just heard your balances it was not that great but it was the best we could do let me count the song I'm like oh great okay we can use this to now do something better we can actually make a proper basically like Z cash from ethereum where you can Shield ethereum let's do that and we did that Aztec Two and I'm

like but this isn't quite good enough um uh is we wanted for primobility and we couldn't get there but we're like okay we've got this we've got we've got teleplunk we've got recursion let's let's interact with D5 let's do like Layer Two to lay one and like D5 interactions and and and um transaction matching we can do that so we did that we did launched asset connection now finally finally we have the secret we're like okay we can do now what we wanted to do all along which was programmable privacy so the way I see things evolving at least for Aztec is that Odysseus like you know pack Downing our tools and going home once we've launched the Aztec network but I I do see that um feature enhancements are iterative and not revolutionaries and there'll be

upgrades to the existing Aztec Network and not completely new architectures that are deployed because I do think that we've summitted the overwhelming majority of all the thresholds that we've been trying to to cross but speaking more widely are there any other Frontiers any other like game changes that can happen down the line there are shoe that I can see one is less specular than the other the I think the next big threshold is multi-party computation with the systems that we're enabling with Aztec you can get um single person like single user privacy and then you interact with transparent protocols in this public private Square subscription that you just that you that you mentioned earlier

what will be very nice is there is no Public Square everything's private but then that that requires a lot a large amount of coordination with a large number of entities that all cannot um like they all they all cannot like know any any anything about the people they're interacting with that requires NPCs they're much more complicated um to execute on you have you have different worst trust assumptions um as that you have to you have to work around and the transaction complexity is a lot higher because you're interacting with a large number of other individuals however we do think that Aztec is basically the network where that'll happen what we're excited one of the things we're excited about with Aztec is that it's we see as basically an NPC incubator

because Aztec smart contracts are the perfect execution environments to um to run a MPC protocol on because you have this decentralized um like validation like validation logic that everyone can trust that can modify um private State shared State it's is what you need and we're going to be launching with NPC premises built in to the uh programming language Noir however we do anticipate it'll take a while before people to experiment but these and actually build Advanced systems the the biggest um Game Changer which I think is a long way away if it really ever if so I'm not sure what's going to happen within within 10 years or even 20 years

maybe 20 is fully homomorphic encryption but more than that verifiable fully homomorphic encryption so um where so fht is a bit of a Holy Grail where instead of proving that a computation is correct so I have some secret data I can I can prove to you that it follows some rules you encrypt your secrets you give them to someone some other smart and they they run the program for you but they don't know anything about the the algorithm they're running they don't know anything about the data that's fhe it's much harder to do it's much slower the amount of information that's required is much higher both of these are problems for for in the blockchain protocol and within a blockchain

protocol what you really actually want is you want to verify an fhc computation that's incorrectly performed um so you want to say I gave my I gave my encrypted data to some third party smoke they ran an fhc program here's the output and by the way this this will happen is and you don't have to trust me when I say an fhe program has run and so that means taking a very very complex Computing operation like an effigy algorithm I've been running that inside a snark hmm that's that's that's the the real Holy Grail but I don't to be honest I don't see that happening quite a long time to come and yeah Aztec isn't rebuilt around that um because it's it's a bit too speculative so it's like what is like the man on the street capability meaning like okay I

understand the man on this street capability for Aztec which is uh my coins are private I can hit a smart contract get get a credit score private and then I can go to the Public Square borrow money based on my credit score and then I can go back to the private world MBC seems to be yeah you can do all that but you really don't even need to go to the Public Square uh to take the loan the loan will also be granted to you on some kind of private Square everything's private but what does fhe provide me beyond beyond that I already feel like that's enough for me

I think city which is why we're not focusing on and given its technical hurdles but I think without it she might maybe might be able to actually create private ethereum maybe uh as in just take regular Theory and wrap it in not in ZK but fhe where you use oblivious um like oblivious Ram to like um to to do the State updates and you might be able to make that fully private with some tweaks uh so we can have the account model of ethereum completely and smart contract writing behaves exactly like ethereum but the whole thing is obfuscuted

possibly I'm a little uncertain myself uh that you have a very different execution there basically if it is possible and and and I think yeah like there we did some early kind of tests on on on using some some kind of fhc methods to help retrieve Aztec utxos and the the compute required is is eye-watering so it's I think to even match ethereum's throughput on today's protocols it's just a complete non-starter um uh but it's it's fun to kind of put put pie in the sky and see why things can things to get to and maybe it will become faster than uh then that we will think that uh it seems quite far away

right now I have one more final question seriously last final question you have made the somewhat controversial decision to Sunset Aztec connect to kind of focus on building Aztec 3 and kind of leaving um everyone who had kind of so far um entrusted themselves to you and your company in building on Aztec connect somewhat high and dry can you walk us through that decision process because I I totally see that kind of maintaining something um where you don't know whether there's an upgrade pass to the successor um it's a pain but also kind of frankly pissing off the people so far

kind of build on your protocol it's probably not a great business move yeah it's a great question um I guess um I I would kind of dispute the the high and dry um like we we've made all of the code fully open source um and if people people want to take the network and kind of take on the costs of running it from a maintenance standpoint and and just resources we encourage that um we can put the the code links in in the reposit in the podcast and for for users um we've kind of offered free withdrawals um for the for the next year so we're hopeful that um even though it's it's not a decision

that uh some a lot of users kind of agree with because they were using that product and enjoying it they shouldn't be kind of out of pocket because of because of that and um we're very hopeful that once once Aztec 3 uh or Aztec the next version goes live um they'll they'll come across and kind of try the the wealth of new applications um that are there um and from our community at least of developers they're all very excited to try the sandbox so I think we've managed to kind of protect against burning Burning Bridges there where possible and I guess on the rationale another hurt like it had a lot of usage Aztec connect um and that came with uh costs so we had

kind of close to 200 000 kind of users um and uh for a company like ours we're still small like we may have raised um uh kind of venture funding but we we were spending kind of close to half of our engineering resources on on keeping that live um and we kind of felt that it was uh not just normal engineering resources that were like replaceable and we could scale up these are kind of ZK snark based brains uh that are not really kind of scalable so it really came down to kind of can we keep this live work out how to upgrade it and decentralize it at the same time as building something as ambitious as as Aztec and just the math

said no um so yeah it came down to being a business decision um on getting Aztec out by the end of 2024 or or not really at all um so that's what kind of four-star Handler okay that's fair enough um if people want to keep abreast of developments um going towards Aztec 3. where's the best place they can follow you on Twitter or Discord or your Forum or what would you recommend yeah I'd say the Forum um so we're trying uh to do a lot of our kind of protocol and product development in in public um and so for kind of key protocol decisions

um we'll be using our Forum which is at discourse.aztec.network um we will obviously be tweeting out about that uh by our Twitter account which is our Aztec network but really we're trying to build Aztec in public and get as much Community involvement in in the design and building of that as possible um so we all have lots of rfps um coming up where we encourage people to kind of chime in on the design decisions we're making everything from sequence or selection through to kind of account abstraction and and token models so if you have thoughts on on how that should work and want to kind of uh debate some of their ideas then yeah please please head to the Forum super cool thank you guys for coming on

again yeah thank you so much for having us yes thank thank you this has been a lot of fun