Aztec's Rebirth, The $61M Token Sale & Programmable Privacy on Ethereum

Welcome to Epicenter, the show, which talks about the technologies, projects and people driving geese, centralization and the blockchain revolution. And then today I'm speaking with Zach Williamson. You're not going to launch this thing without decentralization, right? Kind of like you want a decentralized sequencer and provers. We're not doing this out of some moral crusade. We do it. We're decentralized because we need to be. We can't be centralized. We'd have to build in a backdoor.

We don't want to build in a backdoor. Backdoors are really bad. You want to use things that are better tested as much as you can, right? Building novel things kind of means having to build new systems, but trying to possibly fall back on proven systems. There's no such thing. We are the first astic will be the fall back for future generations of private cryptography. Once we get beta we believe much more comfortable making claims about its security.

Will be much more comfortable with people putting large amounts of funds in. But until then, it's it's going

to be a risky protocol. I'm pretty honest, and today I'm speaking with Zach Williamson, Co founder and CEO of Aztec, a Layer 2 network building what it calls programmable privacy for Ethereum. So Aztec was once known for private transfers, but a couple of years ago, the team did something that very few projects actually dare to go through with they shut everything down and rebuild from scratch.

The new Aztec promises fully private smart contracts, not just private balances, but private logic, computation, identity, but still remaining compatible with Ethereum's public ecosystem. We'll dive into all the details in just a bit. This episode is brought to you by Nosis, building the open Internet one block at a time. Nosis was founded in 2015 and it's grown from 1 of Ethereum's earliest projects into a powerful ecosystem for open user

owned finance. Nosis is also the team behind products that had become core to my business and that are so many others like Safe and Cow Swap. At the center is Nosis Chain. It's a low fee layer one with 0 downtime in seven years and secured by over 300,000 validators.

It's the foundation for real world financial applications like Nosis Pay and Circles. All of this is governed by Nosis Dow, a community run organization where anyone with a GNO token can vote on updates, fund new projects, and even run a validator from home. So if you're building a Web 3 or you're just curious about what financial freedom can look like, start exploring at nosis dot IO. Zach, thank you so much for

coming on again. Thank you so much for having me on. It's a pleasure to be back here after all these years. Yeah, absolutely. Yeah, you, you were last on Epicentre when Aztec was still running it's earlier version. Tell us what's happened since.

Yeah. So back then I think we were, we were on Aztec Connect, which was a continuation of the world's first fully private roll up. So it was a layer 2 network where you could send private transactions and use our network effectively as an anonymous proxy into Ethereum Defy. So you could talk to something like a Uniswap or an Ave. contract and have the Aztec smart contract act as your

proxy. Then the result of that Defy traction would come back into the Aztec network and then you could take your claim of it privately. So back then that was the the most advanced thing we could do with the technology that we had available at the time. Something we call turboplunk was a was a was an extension of the original Plunk paper that we put out in 2019.

But that was the Azteca. That was never really the full aspirations of the network. We built it because we wanted to demonstrate that privacy was possible and useful and needed. What we've wanted to do all the long was create a private smart

contract ecosystem. So one where instead of just doing transfers or talking to defy, you know, you can have a sharing complete smart card language where you can write your own states, your own state transition functions and describe the logic of whatever protocol you desired, but with private data as a first class primitive. So yeah, that's what we just, that's what we decided to build,

I think shortly after our first. Conversation, why did you decide to kind of rebuild this completely instead of just iterating on the old system? Because I mean, obviously people were already on there, people were using it that. Would have been nice. We have, I think it was 60,000 multi active users. It was, it was and growing quite rapidly. The the challenge was that Essek Connect was built from scratch with the latest technology we had at our disposal. No one had really built a fully

private rollout before. So we've been figuring out a lot from the first time, and in hindsight, we made a lot of architectural missteps that we wanted to correct that really we didn't really have a viable path to iteratively upgrading as tech connects to add programmability into it. Everything changed. You know, the semantics of how you, how you call create transactions, the cryptographic proving system that you need to use the, the Node software and

its interface and its API. We quickly realized it was what we wanted to build was unrecognizable compared to what we already had, and that we needed to take those learnings and that institutional knowledge and and recast it. But we we didn't see a viable pathway to it's a has to connect, unfortunately. Tell me about the moment that you guys realize this. So kind of obviously kind of as a builder, as a founder, you, you get attached to what you've

built, right? Kind of like it's your baby and kind of like the users kind of you, you feel close to them even if you don't actually know them personally. Kind of you, you, you are somehow indebted to them, right? So kind of you, you have some sort of so, so tell me how that went down. Yeah, I still feel like pain of guilt whenever I talk to somebody and they say, hey, I use SAS to connect. I'm like I'm. I use SAS to connect. It was tricky.

You know, it started with we had some internal conversations. Basically there was, there was this exciting incident where we made some research breakthroughs that made the full programmable version possible. And it was, it was an evolutionary process. You know, a lot of others also were spent maintaining there's no software. We didn't really have the ability to really launch this, what we were calling Aztec Free Project.

You know, some, there were some people we were having discussions that we were like, hey, like maybe we need to kill this. Then that started turning into a internally like quite, quite a quite an active discussion. And yeah, like eventually it was ended up as me and me and Jonah in the coffee shop having a very long conversation about about the future, about what we wanted to do.

We we we came to looking. But yeah, we need to there's no way that we can serve both asked to connect and asked to three. One needs to go and and it should be asked to connect. But it was it was a tough conversation. Which one of these kids do you think we should kind of put up for adoption? Sort of. Yeah, you know, everyone says they love their children equally, but maybe deep down. Like one of them is air secretary. Don't want to acknowledge.

And then we're like yeah, OK, 111 of our kids needs to die. Prepare the sacrificial altar. OK, maybe, maybe let's move into kind of like more theory territory. So one of the kids is somewhat alive again. So tell, tell us kind of like what's what's live now and what's still being built. We're calling ASIC now, we're releasing, you know, it's not ASIC free anymore and it is alive. It's on public test net, it's

fully decentralized. You can deploy contracts to it today, send transactions to it. I think it's is it play around.asic.net network I believe. And we are currently going through a audit process and, you know, doing some last minute adaptations to it to get it ready for Mainnet, which should be happening early next year. Exciting. Very alive kicking, you know, like now. Now we're the main focus internally is basically focus on the Dev X. We, we launched the test net earlier this year.

And you know, we, we've basically transitioning the, the organization from a place where the goal was just get it working, whatever's, whatever it takes, just get it working to 1 where a mandate. Now we need to make it good, easy to use for, easy to develop for. So that's still a work in progress. But by the time we we hit hit our launch next year, that should be all squared away. Fantastic. So maybe let's talk about the way this thing is architected.

So kind of there are a couple of core design choices that you guys had to make and I think maybe it's easiest if we kind of walk through them 1 by 1. So kind of the first I noted down as kind of decision to kind of have a hybrid public and private execution situation. Tell us about that for.

Sure. Yeah. Well, that that came out of again, like I think Asterisk Connect was, was is existentially important for us because this came out of Asterisk Connect like a learning that we were like we realized, OK, so with private state the way currently is, at least if you don't have FHE, we don't have announced NPC like like TESAO stuff, which we do have, but it's not yet like critical level.

At the critical level, all private data is encrypted and you need to use a UTX survey states model to do that. Like like Bitcoin, where instead of having an account where you have a like either balances that can be modified, you have individual discrete like objects of state in your database. And these things have owners so that your balance, your token balance is made-up of lots of these different notes in your in

your database. The reason you need this for privacy is because if I have an encrypted balance and you, you send a transaction that changes my encrypted balance. Well, if that's still one, if that balance is just one piece of data in in in the in the in the network database and you can see it change and therefore you can see the transaction graph. You also need the entire state, right?

Because kind of like in an account model, you don't actually have the account balance noted down anywhere. Kind of like you actually have to walk through the entire history of the state in order to kind of arrive at. You do but but in an account based model.

You stole in this in the state tree you do. You do have like a state, a variable. Yeah, a state tree will have your banners. Finally, it might be tricky, but, and so when a transaction changes that you can see that. And that's not OK if you're private. So instead we have a, you know, we have this, the model that that really Z Cash and Zerocoin propagated where you have individual bits of state, they're encrypted by an owner and they can be created or they

can be destroyed. And that's how you modify them. You, you, you destroy it and then you create something new. The reason why we do that is that the records have destroyed notes and the records have created notes who use different

encryption algorithms for them. So you can't, so that an observer can't link the 2. So if I destroy two of my notes, create 2 new notes, maybe one of them is earned by you, one of them is earned by me. Nobody, the everything observer can see if they look at the network is that tune notes were created, tune notes were destroyed, but they don't know what they are. They don't know how they're linked. Therefore it's private.

However, the problem there is, well, if that's private and it was encrypted, how do you do global state, as in, you know, take Unisop as a smart contract. If you have an AMA liquidity pool, well, you need to know what's in the liquidity pool so that you can perform your liquidity calculations and like a, an or a token which has a total supply. How do you update that? If everything's owned by somebody who holds, holds a description key?

You can do it via NBC. You can do it, which is very challenging, or you can kind of skip the problem entirely by having this hybrid statement where some information you can make private and some information you can make public. So in this context, the simplest way on asset to make an AMM is, well, you make the AMM fully public. So you can see that the, the token values going into the,

into the market. You can see the trades that are happening, but you can't see the identities of the of the

participants. So I could put some USDC into an AM, take out some ETH and people can see what's the, the prices, but they don't they can't, they don't know it was me in in many ways, that kind of system can get you the best of both worlds where you get privacy for the user, but transparency for the protocol, which often can be very important to understand that you're not, you've not been, you've not been cheated, you've not been manipulated, but you can.

Sorry, I'm rambling here a little bit, a little bit of monologue. You know, with advanced NPC shared state prematures like Tatsuya, which is present on Aztec, you can create fully private contracts if you desire it. It's just right now the the info to handle that is less built house than it will be in a couple of years. I understand that there are public contracts and there are fully private contracts.

Can I build something that's in between so kind of that I can kind of share with a select group group of people, so kind of like my own AMM pool that I only allow my besties to kind of trade on sort of thing the. Code for private contracts does not have to be published if you. You need the code if you're going to send a transaction, but it's not published by default.

So if you want, you can just share that code with a selected group of people, have a whitelist so that you can basically have this completely isolated suite of smart contracts within the async network that nobody else knows

about. Can't remember if I did think we've actually added it as a premise of your in our protocol, but it will happen in an update where you can encrypt smart contracts so that you don't just need the code, you need a description key if you really want to go, go that that direction. You can also have hybrid systems in another way where you can have a single smart contract that has both public and private functions.

So a canonical token contractors like this where you can shield tokens, but you can also unshield them and you can send them, send them around publicly. And if you want to go even further, you could only share the private parts of your contract with a select few people if you really wanted. To, OK, walk me through, I mean, so at the face of it's, it's kind of like, it sounds very sensible, but kind of as an engineer, it sounds tremendously complicated to kind of construct

something like this. Walk us through kind of the challenges and the solutions that you found to them. Oh. So many challenges because it's it's not just the difficulties of building it, but also it's creating abstraction layers that allow building on it and for it to be relatively easy and straightforward. The goal is that for you know any web three engineer to be able to to run into play smart contracts, you don't need to know cryptography or weird, weird complicated semantics

around around privacy. I mean, I guess the very first problem was just technological was then if you have private transactions, then each transaction itself is a 0 knowledge proof. And so how do you make that proof? Because you know, normally if you look at things like the, the Zexi paper and, and early attempts at creating private transactions, they, they're very unintuitive to a developer or engineer.

The idea is there is that instead of having a, instead of having code that modifies state, you have state that is a that comes attached with some code which defines how that state variable is created or destroyed. As you know how it used to, that's how it used to work. And it's like it's, it's not intuitive, it's messy.

So we needed to take those models that that existed in the literature that you could create snark sectors for and actually go, OK, no, no, no, we want contracts and those contracts can call other contracts and, and these contracts can manipulate a database of arbitrary state. How do we do this? How do we do this?

So we had to, we had to come up with some very noble cryptography to each and pull this off because if you have a bunch of contracts all written by different people, they all have different verification keys. You basically one transaction that causes lots and lots of contracts is effectively large numbers of 0 knowledge proofs that need to be recursively composed together. You need to hand like to handle large amounts of data transfer between these zero knowledge proofs effectively.

You know, you've got algebraic circuits that you're trying to pretend are iterative programs and, and, and creating a AZK proving technology that can handle that is was very, very challenging. But that was just the first step one. Then on top of that, you know, we needed to cope with an Avi from scratch about how to interpret this stuff. As in, you know, you have a you

have a private function call. It's got a bunch of public inputs in New Zealand. Second, you need to interpret this inputs according to some Avi so that your protocol level circuits can figure out what to do. We need to undertake to figure out how our state treats worked, you know, like even that was non trivial. How do you do events in an encrypted way? How do you do state sharing efficiently?

So if I, you know, technologies like Zcash, I think they've made improvements recently, but back in the day, same with asked to connect. If you wanted to sync to the

network, you need to, to download every single piece of encrypted state and try to decrypt it yourself to see if you owned it. That doesn't scale. So how do you, how do you create a, a world where I can send you a, a note where that note doesn't necessarily represent tokens. It represents arbitrary state in a smart contract. And you know that this has happened and you can decrypt that information without having to sync to the entire network again like that.

That's that's an open problem. It's until we have much more advanced FHE solutions. There's always a trade off there in terms of privacy. So it's figuring out where where to go on that trade off was very challenging. Yeah, this is the start of it. You know, then there's how do you even even basic things not associated with privacy, like how do you decentralize an L2 network? That's actually, there's not a huge amount of work on that in the public domain. We had to figure out all of that

ourselves. You know, eventually we even realized for our particular needs, we needed to build in a very small data variability network into our layer 2 to in order to secure certain light risk guarantees. Yeah, it's, it's been very challenging. There's a reason it's taken us so long to build this. One thing that kind of we haven't yet touched on or you very briefly kind of glossed over just now is that not only kind of didn't did you not want to make compromises in the

privacy RAM? You also told me back kind of like when I last said you on you're not going to launch this thing without decentralization, right? Kind of like you want to decentralize sequencer and and proofers, even if you kind of look at L2 beat now, even the non encrypted L twos haven't come a very long way there, right? So tell us what you learned on that. Again, it's all about fundamental incentives. You know, we're not doing this

out of some moral crusade. We do it decentralized because we need to be. For the same reason why if you take the Internet and HTTPS, you know, where now all, all requests to, to, to, to website, to a server, they're all made encrypted. They're all encrypted. The responses are encrypted if all that traffic flow through one company and one company's servers, they would be the most over regulated company in existence.

You know because everybody every every government agency we go to them going hello, I would like all your information please and thank you the Easter cryptador the same reason for Aztec we can't be centralized not without we'd have to build in a backdoor and we don't want to build in a backdoor Backdoors are really

bad. So we need to be decentralized where it is a genuine distributed network made-up of thousands of different participants that that are all collaboratively participating in this network. And so one of the few networks that generally has an incentive to to decentralize most layer twos. Decentralization is actually corrosive to their interests, because if you're an EVM, either AZK one or an optimistic one, your unique value proposition is price and throughput and

latency. Basically cheap transactions, lots of them, instantly. I would, I would kind of, I would contest that. I think so kind of in kind of because in the failure case that kind of kind of like someone, God forbid compromise the one multi sick that you kind of use to kind of govern URL to kind of all that value that's kind of protected and there's is potentially gone right you're. Talking about security, which is not a value proposition.

It's it's basically it's a protective technology and to be very cynical from it, if you look into traditional Web 2, traditional software, how often do companies invest in better security? Like not, not Barry, if you can spend money to make money or you can spend money to potentially not lose money in the future, You know, the, the, the monkey brain goes, we make the money. We don't, we don't, we don't protect our, we don't protect the future. I'm not saying we have this culture.

I'm just saying that this is very common. So, but you're right that there is there is a desire to decentralize for that security reason, but it's but it's corrosive to the bottom line for. 100%, yeah. I mean, basically best, best business models being AWS, yeah.

Yeah, how do you centralized are you if all your decentralized nodes are running on AWS, this is a genuine thing we it's covering and wrestling with but yeah like you know if you're at ZKL 2, decentralizing makes your costs go up, right? Your transaction latency increases your the throughput like the network throughput decreases, the GPS low goes down and so there's really low design to actually make it happen whereas for us, we need to make it happen.

We can't survive without it. And so we discovered a few things like even our it's protocol to select sequences is somewhat novel. You know, there wasn't anything off the shuffle that we could take and you'd think you'd do that wouldn't be figured out by now. You know, you've got, you have a bunch of LL people who want to produce blocks on an L2. They're sticking on L1. You know how they selected you do that, get sorted, but it's not well, there's many, there's many different views.

Then there's just, you know, we've had to do a lot of work on the peer-to-peer networking side, which again, it's a bit surprising we couldn't use anything completely out-of-the-box, which do a lot ourselves. But the, the most interesting one for us was a unique characteristic of a stick, which is that ASIC transactions, an individual user transaction contains within A to 0 knowledge

proof, right? You have your, your, your transaction data, which describes what you want to do, which will it'll be encrypted, but that's, it's fundamentally still there. But then you have the proof that comes along with it going, my state transitions are all correct. I've followed the rules of your critical and in our roll up blocks, we effectively swallow

that proof data, right. If if you're making a proof of a Aztec block, you are inside your ZPA circuit, you're verifying all of the individual transaction proofs, which means when you publish the roll up block, you don't need the proofs anymore, but you need the proofs to make the block to make the block proof. And we had this dilemma because we did not want to publish the the transaction proof data onto L1 because it's, it's large and that's expensive.

And I'm thinking, well, we don't need to publish it if every block comes with proof. The only challenge is you need, you need your prover. So, so you have a statistic to read block producers and block prover's right, The block producers are making the block. If they're not publishing the, the user transaction data onto L1, you need to guarantee that data exists for about 20 minutes so that a block prover can still

make that block. And so we're like, oh, oh God, we need, we need ADA layer to make this happen. Like we need a 20 minute DA layer. It's not the most impressive thing in the world. It uses some basic economic consensus, but we had to build that out to to make our L2A reality, and that was an interesting detour we weren't expecting. So what we've kind of tried to cover and mostly glossed over because there's a lot of it is incredibly high level, right?

So kind of maybe let's kind of take it down to notches. So imagine I'm an entrepreneur building on Aztec. So what choices do I have to make that differ from building on a more standard roll up like Base or Arbitrum? Yeah. So if you're building on Aztec, I think there's going to be an assumption that you desire some kind of privacy in your app or you want to interact with private accounts. What different choices are you

going to make? Well, we do have to learn a different programming language in a different technical stack. We figured the the semantics around privacy on a blockchain are sufficiently, I think that we needed to go the route of creating our own language to make it to basic so that we could create the abstraction layers that we thought would be appropriate to, to minimize the complexities of this.

It's called Noir and it's, it's basically it's heavily inspired by Rust. So if you know Rust, it'll be very intuitive. If you don't know Rust, it's still pretty, it's still easy to pick up. You know, it's, it's, it's like a any, any low level programming

language. There's going to be a certain custom well, as I said, semantics keywords that you have to learn in terms of, you know, how this how status, how to how to create the state right storage slots, how to how to how to manipulate them when a particular when it comes to private stuff. But you know our docs are constantly improving. I think hopefully by the time that this is broadcast, they'll be our latest docs will be, we're going through a documentation revamp, so

hopefully it'll be done by then. Yeah. So, so, you know, but the, the forms of what you're doing should be very familiar. You know, there is a node that you can install to send transactions to. That node has an API that you can interact with. You know, you can write contracts and there's contracts, you can define an API that's your node uses to get data and you can connect this all to you. Can I communicate all of this with a JavaScript wrapper if you want, so that you can write a

web application. So the, the, the, the forms of it all are very similar. The the details will be slightly different because the, the state model is different. You know, like we have public and private keywords in our contracts, which mean they're not visibility specifiers like normal in a regular programming language. They really mean like this. This can be, this can be seen by the by observers, or it can't be seen. And then, you know, these cut functions can call other

functions and you commit events. You can, you know, do do all the similar stuff you you expect from a contract ecosystem. This is a few more, a few more keywords that you have to think about because of the public, private thing. OK. But so kind of the way that I should think about contracts and gas and wallets and user interactions and so on, that doesn't really change. That doesn't change at all, okay. It's all the same. We have Delta gas, recall it's a

the juice. Yeah, we have wallets in production. The idea is to basically mirror all of the concepts one would be familiar with already in Web 3. Seeing that kind of I have to learn a new contract language that doesn't particularly dawn me. So I'm a physicist by training, which means kind of I'm a terrible programmer, but I'm a terrible programmer in many languages so that I'm I'm not put up, put off by this. What kind of application do you think it would make sense for me

to build first? So kind of which ones do you see where kind of privacy is actually a cool feature rather than an afterthought and kind of I think what, what I'd like to talk about next is kind of performance. So kind of like the trade-offs you kind of make for this. So yeah, I'm I'm also I'm also an ex physicist so I can relate. Hopefully over the years I've become better at certain briga. Maybe when licensing it cope for Aztec. What do you mean I can't do this in Python?

Can do everything in Python. Yeah, well, my case. Fortran. Oh my God. You don't look old enough for this. OK this. Is going to be kind of backwards, you know? This is true. This is true. We can be very backwards. The applications that make sense are varied, but generally they

will revolve around two things. Either you will need an understanding of a person's identity that requires disclosure of sensitive information, or you want to more broadly, you, you, you want to create an application that's based around information asymmetries.

You want an application where you're interacting with somebody at that, like a counterparty and your counterpart in this stuff you don't and you know, stuff your counterparty doesn't and you don't want to disclose it. I know that's very vague. One of the some of the low hanging fruit for that is games. To give an example, the original breakout NFT from 2018, I think was Crypto Kitties, which was all about, you know, you have these cats and you can breed them.

You can combine other cats to great new cats with different traits. And back then what they relied on was code obfuscation. Basically, they didn't publish their source code and so it was hard to figure out ahead of time what how to breed cats get the optimal side effects. Nowadays that won't work. That kind of stuff gets instantly reversed engineered because the overall skill level is much higher. But you could use privacy to actually make sure that you couldn't.

You could. You could use things like Randall and some randomness to to basically make it so that only at the conclusion of your transaction, when you understand exactly what traits you're getting, what algorithm was run. I, I like where you're going with this. So kind of like when I ask you, So what do you think is the most pressing application to, to put it on top of this? Oh, but we can, we can write, we can, we can, we can breed private. This is fantastic.

Did not say most. Pressing sorry, sorry. Is this going to solve all the society's problems? Absolutely. Yeah, it's relevance and and

this will be, there's no demand for that kind of thing on chain. No, I think I think kind of like games in principle, kind of like old school games. I think they're actually pretty good examples because they actually use very little state. I kind of like if you look at kind of like these 80s arcade games, kind of like they're tiny. So kind of running them in this kind of environment, kind of I, I totally see where you're coming from.

More more useful stuff would be for web free native utility would be some basic identity protocols to protect against civil to make for civil resistance. Basically prove a uniqueness so that you can do things like air drops that can't be, you know, farmed by somebody pretend to be 1000 different people. Or if you want to do a sale of tokens, for example, and you want to ensure that it's only one person coming purchase or governance.

So let's say you want to do a vote on the Dow, but you want to use quadratic voting where the more tokens you have, like the less some marginal like voting power of your additional tokens. There you again, you need some versus you need to ensure that one voter like that Kelly Devet wants instead of pretending to be 100 different people with smaller imbalances because then because otherwise you can gain quadratic voting.

And so civil protection, basic identity protocols, I think will be very, very valuable things like Zika passport, then that can be expanded to do finance that is existing in in regulated spaces. So if you need to prove somebody's not on a sanctions list, for example, or maybe you need to approved transaction limits so that somebody is not transacted like above a certain thresholds in a time period or you need to know that somebody's residence in a certain country.

Things like that, where you can basically add in identity credentials to build out D5 protocols that interact with assets that are more originating in the real world. And again, I think this is also one of the reasons why the one of the original use cases of NFTS didn't take off NFTS originally. People were like, why is this for tickets? You know, because decade master is is charges very high fees to get technicians to attack. It's like, why can't I get rid of them?

Well, because one of the reasons is that to make that work, you need to link an identity to a cryptocurrency accounts in a transparent world. If you have identity protocols, that's no other such a challenging. Thing to do. I 100% concur that that would be incredibly useful and kind of like barring kind of like all potential attributes of your person to kind of like who whoever kind of like you want to buy bottle of wine from

obviously doesn't make sense. But if you look at the way that these regulations are drafted and typically proving that you are above 18 doesn't cut it. So typically you kind of actually as the person selling the bottle of wine, you actually have to have some sort of copy. So how do you how do you get around that? Well.

A couple of things here. First of all, there's very, there's, there's a lot of value in adding identity to things that are not, it's for functionality, not regulatory clients, things like, you know, civil resistance for air drops. Then there's basically there's, I think the more, the more mainstream your use case, the more unnecessarily regulated it becomes. To be fair, like, you know, these regulations were not drafted by people that understand that knew about 0 knowledge proofs.

So the idea, you know, when people were drafting here, like proof of age laws, you know, God knows when 1950s, right? Like the idea that you could prove your age without seeing like I, I as I, as I, me, I'm selling wine. I know somebody's 18 without actually seeing some identity that was just inconceivable to them. So I do think there's a, you know, there's some active

accuracy work that we're doing. I do think that legislators, politicians are, they are actually like becoming more aware of 0 knowledge proofs and that this will change. I do think there's plenty of regulations that are actually very amenable to 0 knowledge proofs already.

Things like using ZK passport a particular passport proofs because E passports already thing there's already precedent that that for them to be used and things like passport gates that's there's already a well established understanding that these are very strong credentials. You also have a lot of precedent from the document signing worlds where digital signatures on documents can be as good as the

real thing as you can start. You can kind of combine these precedents to make claims that some of these on check that some of these ZK based identity solutions are good enough obviously. Yeah. I mean, if DocuSign can kind of check that box, then obviously I mean kind of like that there was some, some impressive lobbying going on there to kind of make anyone, anyone agree that this is kind of definitely the same thing as signing something in wet ink like clicking, yes, this is my name.

Yeah, I think, I mean different jurisdictions will progress at different speeds. You know, for example, the US is already in the in the presence of passing several crypto regulations, the DDS acts, there's the Crypto Markets Act. It's got a fancy name, a cover for what it is. Europe will be much slower to to be very blunt, we're not really like. We are always as slow if. You want to do some advanced enterprise privacy stuff. We're not talking with the people right now because Europe

will be very slow. Nevertheless, there is value there, there, there, there's that you can. There's some things you can do within the existing frameworks, but really it's America's taking the lead. There was an opportunity for other countries to take advantage of America's conservatism under the Biden administration, my country among them.

There are many voices advocating for what could be done and the value that can be generated and and so now these countries will pay like will deal with the consequences of inaction. The the economic central gravity of crypto will be America, and that's just the way it is. Tell me about the performance trade-offs for programmable privacy. So it's kind of like what's the bottleneck right now for performance? Is it is it the proving or what

kind of constraints me? Trimming is Trimming is more the user experience bottleneck than the performance bottleneck because your user makes the proof and then they send it to the network. But the when it comes to transaction throughputs, the amount of time it takes for the user to make the proof doesn't really matter because you can you can have large numbers of people making increase at the same time for network throughputs. Right now we are targeting for our very first release on the

three main net. We're targeting whopping 2 TPS, which that doesn't sound like much. However, if you look at the throughput of existing L twos and how much they're being used, 2 TPS is actually quite more

than it's fine. And over the next 12 months of post launch, we'll be scaling it up to 100 TPS. Some of the bottlenecks are, well, there's a lot to prove in a roll up, in a Zika roll up, particularly because we have something I didn't even mention until now, we have a, a public virtual machine, AZKVM. So for all the, all the public things that you're doing like public functions, public trade transfers, they're all proved via AZKVM.

That's that's proven server side either there's some performance challenges there, particularly with like how much can be paralyzed, how much can be serialized, how much is serial? We have issues with our peer-to-peer network throughput, Bammoth throughput because every user transaction is compared by

Zero's proof. And so in your peer-to-peer network to get that transaction into the mempool that you need to propagate this information and your peer-to-peer network throughput will be substantially lower than the bandwidth of of your node operators. And so the Zero's proof size there actually is quite important. So right now it's about 50 kilobytes and you know we have some work scheduled post launch to get that down to four. So that's what that needs to. Be to 4 kilobytes, yeah.

It's not, it's not a hard problem, it's just time consuming. So we haven't done it yet. The using multi, multi polynomial basically instead of committing to 1 polynomial, like one commit per polynomial, you just have one commitment for lots of polynomials. And then this is generally our nerd software because we built everything from scratch, you know, because we had this, the semantics from private state was so different.

You know, we have this thing called the private execution environment, which doesn't even exist in other networks, which handles, you know, state privacy sinking state retrievable as it was proving we wrote this all, all of our node software and TypeScript so we could rapidly prototype. But this is not a performance language. So there's, there's huge amounts of engineering work to do search to improve our performance, like to get from TTPS to 100 TPS.

Most of it's just pure engineering, taking something which is brass backing you and just applying traditional software engineering optimizations to it. One rule of cryptography or applied cryptography is you never build your own systems, right? And it seems like you you've built all the systems. Are you worried about that? What rule? No, I'm not. That's that's a stupid that's a stupid rule. In my opinion. The rule is don't roll your own crypto, right?

Well then who rolls crypto if if nobody does it? Oh experts? Who the hell are the experts? Self appointed. That's that's who they are. Well, I mean everything that's kind of like you, you want to use things that are better tested as much as you can, right? Kind of. And I understand that kind of like sometimes entering building novel things kind of means having to build new systems, but trying to possibly fall back on proven systems.

There's no such thing. We are the first Astic will be the fullback for future generations of private cryptography. There is nothing else. So we didn't have that option. If you are building your own cryptography, there's dangerous there. The typical canonical business of doing your own crypto is targeted towards software engineers that don't understand cryptography. They're not like so, so, OK, so what's the barrier if you want to roll your own crypto?

Well, step one, you need to do your own original research. You need to publish it. It needs to be peer reviewed by cryptographic experts. You need to secure it. You need proofs of soundness, you need proofs of completeness. You need proofs of 0 knowledge. They need to be widely accepted and understood. And they need to use security assumptions that are like widely accepted. So you go, you could probably get away with the algebraic group model just about that, Nothing, nothing weaker than

that. And then you need to once, OK, so then then you have the theory down, then it's implemented in software and now software needs to be audited internally and externally. Then what you have out of that is you have an insecure system, which might work. This is a real work because as you said, the only thing that really guarantees the strength of the security of cryptographic technology is time. The the fundamental assumptions that we are base our security crease around are actually not

known to be true yet. We do not know that the discrete logarithm problem is hard. We just assume it is because no one's figured it out yet. And so we are taking a very security conscious approach to our launch. You know, I, I say we're going to be launching on the three minute early next year. What that is going to be is we're calling it the Aztec alpha because we will not be under any illusions that this will be secure. We will have done our best efforts.

We would have gone beyond gone beyond all reasonable doubt attempts to to to to secure this network with our internal external audits. But that's, you know, any software engineer will tell you it's not possible to write secure code. It's just not in these two battle tested. There will be bugs. This bug will be found hopefully by white hats because of our generous bug Bouncy. We will fix them. But the messaging when we launch will very much be security

conscious. It'll it'll the message will say this is not secure. Do not put too much money through this. Don't put money, don't put in any money you're not prepared to lose. And we're going to, we're going to have a checklist of things that need to happen before we're willing to consider the network more secure. We're going to need to not have any serious or critical bug reports for three months. We're going to need to have something like 99% network

uptime for three months. And once we pass these criteria, then we will consider the network to be in beta. And once we get beta, we believe much more comfortable making claims about it's security, will be much more comfortable with people putting large amounts of funds in. But until then, it's it's going to be a risky protocol just because of the nature of what we're doing and because it's decentralized. There's a lot of fests here.

You, you already kind of talked about this a little bit earlier, kind of the bandwidth issue with kind of submitting the proofs as well as kind of the generating the proofs. How much do you worry about lace latency for use cases? So kind of like when, when you kind of say this is great for games, kind of obviously a lot of games rely on fairly low latency, right? You don't. You don't want to wait for an hour for your opponent to kind of make their move. The latency will be good for

large variety of use cases. We are targeting 12 second latency, so we're not producing blocks every 12 seconds, but because of our previous state network and the fact that we have our own little DA layer and things like that use, we can guarantee fairly with fairly fairly strong guarantees. You can get finality on 12 seconds time limit where at that

point that is a line I'll get, I'll get slashed. And so there's a few, there'll be a few $1,000,000 of value backing that claim. Is that good enough for everything? No. Similarly, but at a fundamental level, the problem is that if you're sending a transaction across a layer 2, you're paying for the highest security guarantees, you're paying for the highest like liveness, sensitive resistance guarantees and there's no market for security.

It's not like you can choose to payless if you don't care so much. And so the solution to this, in my opinion, is the, the L3 thesis, application specific rollout thesis, something that we are post launched, we will be aggressively building out via the Aztec stack. Basically, imagine the scenario where you can write an Astec smart contract and it's, it's all the same as a regular Astec smart contract. But when you, when you go to deploy it, you're not deploying it to the Astec network.

You're deploying it to a roll up that's hosted locally or hosted on an S in, in, in AWS. But basically it's a network where there's only one sequencer. It's not decentralized, there's no data variable. There's a guarantee as you just trust a sequencer and in that kind of model you can get very far, honest throughput, very low latency, particularly if your transactions are all private, because if they're all private, you're not modifying any shared state. So your transactions don't have

any race conditions. And the only serial part of the transaction is recomputing your state trace. But everything else is fully parallelizable. So you can make box very quickly. And this, this L3 component will be very, very valuable for low, low value High Street. But use cases, things like micro payments, things like gaming, that's that's how we plan to solve the problem. OK. That, that also kind of solves your two transactions per second

dilemma to some extent. How do you think about state growth and storage in a word of encrypted data? Yeah, it's challenging. You've got to shot it. Basically, the state only ever grows in a private network, right? Because when you delete a record, you're not actually deleting it. You're just creating another record that says this old thing

has been deleted. And you do it in a way that you can't link the 2. So data proliferates much more rapidly on a private network than a public network. And there's a really great solution for this right now other than basically you, you do shouting, you have state epochs where, let's say, I don't know, like maybe a GB terabytes of states per epoch. And whenever you're performing state transitions, you're specifying the epoch of your

note. And so this leaks a little bit of information because if you're modifying a really old note, people know you're modifying a really old note. But it's kind of the best we can do right now without having, without requiring nodes to consume enormous, enormous amounts of data. You know, there's obviously, OK, so there's sharding you could do like the full Etherium foundation sharding desire, but that's, I mean, that's

challenging. I'd prefer if somebody else does it, the prefer if Etherium does it. But right now, yeah, it's a bit, it's a bit beyond us to build that all out from scratch. Course. So kind of like, yeah, no, I hear that. I think kind of like not not building everything is often good advice. Sorry, can I be annoying and

interrupt another thing? So I just realized sharding doesn't work for us because if you have just one giant database, even do Shard it up. If I want to prove that my note exists in that database or prove it doesn't exist, I need to create a medical proof which requires knowledge of the entire data set. And that's the problem. You need to be able to do inclusion and non inclusion proofs of the subsets of your data.

And that requires what like what I call Charlie, like splitting, splitting your stake into ebooks and revealing a small amount of information about about your notes, the age of your notes as a result. There are a couple of competing privacy based chains. So kind of if you look at systems like Alio on Armada or ZK Singh's privacy layer, how do you mentally categorize them with respect to Aztec? Privacy is a hot narrative right now. And so, and it's also a very poorly defined word.

And So what people say, what they mean when they say privacy varies. And so obviously I have my own biases here. I don't and I don't want to throw like, I don't want to throw shape around things like the model. We'll see about like about them. I think that they have a very ambitious goal in mind. They're really they're the ones that use FHE to fully like to create like a fully encrypted Ethereum. There are certain challenges with FHE that are yet to be

satisfactorily solved. Otherwise we've used it. So one of them is so if with FHE you can so OK with ZKI can prove anything about my data. With FHE you, I can give you my encrypted data and you can run a program on that data and you don't know what's going on. You can't do that with CK. So it's much more powerful in that context. However, it has 22 very big flaws that need to be resolved. One of them is the data is also encrypted.

And so if you want to just take a regular EVM and make it all encrypt all the data, then use FHE, then the problem is who owns those decryption keys? You need a basically you need a multi part computation network to hold that, to hold part like shit like partial decryption keys for your state. If you have that MPC network, then you can also use that MPC network to do 0 knowledge proving in via secret sharing. This is what TESAO do. You get very similar outcomes

both, both ways. The whole like who holds the decryption keys? How do you do key rotation make that secure is very challenging. And, and we'll, we'll, we'll see, we'll see how they, how they, how they execute on that. I do. I do hope they are successful. I think that right now any privacy solutions that offer genuine privacy, like it would be good to start if any of them were successful. You have things like Zika sync. What they're doing is very different.

I would not call what they're doing privacy by any like meaningful standard. What the way that they get privacy is that you run so so you run an L3 and people send transactions to you and you don't broadcast anything about that. L 3. So so the way that you get your transactions is not through a public network. It's through private

information, private messages. And then when you make your roll up proof, you basically discard all of the information around the the data in your in your roll up and then you put that roll up proof on Shane. Is that private? Yes, it's the same with a private server. It's private. It's not a great way of creating a composable ecosystem. Like the thing about the thing that I think is most valuable at privacy is composable privacy. The idea is you can write a private smart contract.

I can write a private smart contract and these things can talk to each other, they can, they can call each other and that's like we don't have to share any information with with like with each other. Our users don't have to share any information. It all just works out-of-the-box on a public network, you start getting into some very, very

naive trust assumptions. If you want composable privacy on a network like Zika Sync is building where everything is run by 1 server and that one entity sees everything and nobody else does, it's a huge amount of trust you're placing in that person. But it is useful for certain use cases. It's useful for enterprise. It could be useful for gaming. It's useful for where the trust assumptions are very low. But yeah.

And then you have other other teams like Alio and Mina that are basically doing the ZK route that we are there. It's it's it's an execution play about whether it can this stuff can be made performant enough, easy to use, whether you can create the right abstraction layers. And right now no one's really cracked that problem. And I, I, I can't claim that Aztecs cracked it. We're not even launched yet. I hope we will, but nobody has

yet. I I'm convinced as a matter of faith that's privacy is useful, that is needed. That's if if you make it easy enough, it people will. People will build on it. Not because users care about privacy as a feature, but because it's a required property for a lot of valuable applications. It's a question about building a building a technological base layer that's competent enough to provide the developer user

experience that people require. Aztec is an L2 on top of Ethereum and kind of the decentralized world has shifted since you decommissioned the last version of Aztec. How do you think about the benefits of being L2 on top of Ethereum rather than say a stand alone L1? I mean you already have the decentralized sequences set, you could just be an L1 and kind of like not pay for living on top of Ethereum. No, it could. But then there are other problems with that.

Specifically, privacy doesn't matter if you don't have any value you want to make keep private. Nobody cares how many magic beans you have. They care about how many U.S. dollars you have or your property or like who you are. And so you have a very big chicken and an egg problem if you're running as an L1, Whereas how do you get value with your ecosystem? Because it's completely, we knew it's up from scratch.

Like obviously you can do bridges, but bridging is still a fairly complicated process with an unpleasant user experience. And ultimately, yeah, it's, it's we, we thought the costs, the risks would be too great. And also we did gain a lot from building a software Ethereum. Like we don't have to re roll our own consensus network from scratch. There is a slightly lower maintenance overheads to our software because of that. I was hoping at the start they'll be much lower than they are.

But yeah, we've had to build a lot ourselves. Etherium is still the canonical source of assets on Chen. If you want to issue an asset, OK, you can do Solana and things like that. But but if it's if it's a chunky asset with a lot of value in it, you put it on Etherium.

And we wanted to be able to make it so you could very trustlessly bring your assets into asset from Etherium because just in the same way that Etherium is the canonical source of assets, our goal for Aztec is to make Aztec the canonical source of

credentials. Effectively, if you have a token or an attestation that says something about you or what you've done or what you want to do, the natural place to issue that is on Aztec, where it's encrypted by default and you can selectively disclose parts like that, that that credential to either people or to smart contracts. And yeah, we felt we felt Ethereum was the right place to do it because it's where the money is and privacy is not

useful without money. More generally, we do think that bridging like creating a very, making it very easy to get transactions into an out of a stick from any other network for us is extremely important. We don't want to just be tied to Etherium because there's a very unique value proposition for

Aztec that no other L2 faces. It's, it's not a secret that most L twos are somewhat parasitic to their host networks because the L2 wants its own set of liquidity, its own tokens so that you can build applications on the L2 and that liquidity comes to the cost of taking it out of the L1. With Aztec it's very different because there is unique value in bridging not tokens, but information between Aztec and

other networks. For example, imagine you're building some kind of trading marketplace on slot, but you need a level of compliance, maybe the assets you need to know that people are not on a central system Iranian. Maybe you need, you need to understand if someone's American or not things like that, some basic compliance.

Well, So what you can do is you could print, you could send a request into Aztec where that request will check some encrypted credentials on that, on that person and the request responds with either true or false, like yes, like flying or no, they're not Solana. That application Solana has gained something of value from interacting with Aztec and the Solana network has not lost any tokens. Effectively you get a privacy shield for free at well for a

very low cost. And that's, that's the direction we want Aztec travel in, in the in the future. We want it to be the, the, the universal privacy layer for all

of blockchain. And we want to execute on that in a very positive some way where the canonical method of interaction with Aztec from other networks is not you bridge assets, assets and Aztec and then they stay there is you bridge identity information in into and out of Aztec or maybe you put tokens into Aztec so that you can create so that you can perform private interactions with them. But then very quickly they they go out back into the parent

network. We think that's a much more kind of a positive sum way of interacting with the ecosystem where everybody wins. I 100% concur on the message passing use case. So kind of like if you were to kind of use it as a an identity layer. 100% agree with

everything you said. If you look at how assets are actually issued in the Ethereum ecosystem today, I know that kind of like back in the day we talked about assets natively being minted on Ethereum main net and then kind of being bridged into L twos and and then kind of things happen on L twos. They get rolled up and then kind of like you bridge out of the L2 onto main net. Again, what we effectively is see is that kind of like acids are born on L twos, they live on

L twos and they die on L twos. And you know, ideally they're happy on L twos, but kind of they don't. And kind of like for anything that is natively minted on an L2, the L1 doesn't actually give you any secure security guarantees whatsoever, right? So kind of like all the, all the security you inherit from being an L2, you only inherit for for bridged assets from main net, right? And I think to to some extent, we've seen that play out

differently. When when you say that you don't get any security from the L1, I think this is largely because these L TS are centralized. And so you you have this kind of the weakest, the weakest point of failure is some some something in the Lt. like a multi sequel or something. It's a bit different for Aztec where you know, you have user, you have, you have sequences sticking on on a 3ML1 to be a

block producer. And once a block is being produced and it's and it and you've updated your state route, then you're, you're, you are very much relying on Etherium's consensus to define what the canonical version of Aztec is. And so I do slightly disagree with the idea that you don't inherit anything from any security from Etherium. I mean we are targeting to be a stage 2 roll up on launch where that kind of that is kind of the points.

But say, say I kind of deploy some sort of token on Aztec directly, right? I can't force exit to a theorem, right? I can't but that that asset that kind of like Ethereum knows nothing about. So the way we do it is we, we call that an escape hatch, but basically for a certain fixed amount of time for every block production epoch, anybody can send a lot of transactions. It's not just a sequence, it's basically a free full. The idea is we don't intend for this to be used, but it can be

used. If you're getting sensitive for some reason, you can use that window to make your own asset transactions to exit. If for some reason there's something catastrophic failure States and like no one's producing blocks, then you could use that to produce your own blocks and get out of Aztec. So no, you can force exit onto onto Ethereum. But can I force exit an acid that was not minted on Ethereum? It wasn't minted on Ethereum OH. It's minted on Aztec, yeah. Yeah, Yeah.

OK. In that case, in that case, yeah, if you invented on Aztec, then you can't force exit. Yeah, because it's like an exit. So I get, I get what you're saying that the the security guarantees you get a kind of it's still it's a combination of Aztec and Ethereum where like the weakest gap like seriously holds. And the way that users behave is all kind of the way that, and when I say users, I kind of mean application developers kind of is assets get natively minted on L twos all the time now.

So kind of like if you look at the values that kind of get transferred on L twos, kind of the minority of them have actually been bridged in from L1. The the majority of them are natively L2 assets and then you have no security guarantees. But the, but the majority of value is not on L twos is in LL twos. Most LTS don't really have product market fit. And so most of what's going on is, is synthetic, it's liquidity farming, it's incentive based. It's basically nonsense.

And so I don't think it sets a very useful precedent for, for, for a network that has the useful economic activity on it. You're right that OK, yes. So, So what happens in LTS is you get these synthetic new coins that get produced and yeah, it's, it's all on L twos. Does it matter? I mean, do you need ironclad security for, for a mean coin? No, So, so I don't see this as a problem. I think that for for us, it's fairly clear, I think how things

are going to play out. If you have and an asset that requires identity checks, regulated checks, it's going to it's going to turn off on a stick as a native asset. Is that secure? Yes, because we, we're fully decentralized. We have a very willing, we're going to have an enormous amount of stake backing the, the network. The more economic activity the network generates, the higher the fees, the more incentive there is to put more stake onto the network.

So I'm not worried at all about its security. What I what I don't want to see happen is that Aztec starts becoming like very parasitic to Ethereum. Yeah, I, I, I hear that. I and I think that's commendable. Because I think that the value proposition really is with bridging information.

I think that's ideally the only time an Aztec is natively mitted on Aztec is if you can't put it anywhere else because it requires privacy checks, composable privacy checks that you get on Aztec. I, I don't see Aztec as being a very popular home for like relations to move on trading because it's going to be more expensive and slower than fully

transparent networks. So I do think that there's, there's always going to be, I mean, obviously there'll be some of it. You can't stop it, it'll happen. I don't see that as being a particularly dominant use case on Aztec unless we've completely failed to execute on any of our privacy. Unless all of my thoughts about privacy I was wrong, then that's the only way that world will happen. Maybe let's zoom all the way out to kind of like pass all the crypto stuff.

If you kind of look at the world right now, kind of we're dealing with declining expectations of privacy and kind of like you see that in in in the UK, you also see it in Europe. So kind of like chat control or something that only recently failed. How do you see that shift? And do you think kind of that level of cryptographic privacy can play some sort of role in reversing it?

Yeah, it's a tricky 1. I noticed 2 trends which utterly confound me because they seem to be, they seem to be at work, like they seem to be mutually incompatible. Which is that Western societies are becoming more and more distrustful of their governments and like less confidence in their ability to execute on implementing effective state policy. Yet at the same time seem to be more and more willing to give those government's powers and control over over their private data.

Part of this is a lack is, is like, how do I put this? Privacy is not a mainstream narrative and people don't think very much about it. I don't think this means necessarily people don't care about privacy. They don't care about government overreach. It's just that they that it's not part of the kind of the Canon of, of, of ideas that they they consider important or

contentious. To give an example about this right, the UK has recently passed a very unpleasant surveillance bill called the online Safety Act extensively to protect children. But in reality is I would argue is a a massive curtailment of of free speech online. This is mean people don't care about government leverage. They don't care about privacy. Well, maybe, maybe not because at the same time, the UK government is trying to introduce identity cards, which is met with overwhelming

opposite popular opposition. People hate that because identity cards are more they're more familiar with that as part of the that like the the concept of ideas they have right. They think identity cards they're familiar with to Teltro instances using those to restrict people's movements exchange of ideas, information and they don't like it.

They're not familiar with how governments use online surveillance laws to repress free speech or limits free exchange of ideas or make their personal is more secure and more likely to be leaked. This will change in time. I think that's what's going to happen is more and more oppressive, so the decision is going to get passed and it's going to be abused and manipulated more and more and eventually we might see some kind of backlash.

I think that there's always my hopes here when it comes to these things that lies with America. I don't think whilst you're getting some annoying age restriction laws at the state level, they're not the same as chat control, for example, where it's just a very, very clear power grab by the state bureaucracy.

I, I think it basically America will always be basically demonstrating what's what like the the alternative of if you don't have controls over over speech, eventually it'll just become a very compelling differential. I think, I hope. But but I mean just to push back here. So kind of in some way the US, a nation that is most advanced in surveilling their own subjects and it's also currently a state where you can lose your visa for kind of being have holding a non majority opinion, right?

So kind of like it is very kind of anti free speech in some sense. No, I'm not going to hold America as a bastion of liberal values anymore. For sure like it that there is this there is an element of capricious state policy. I think you've also seen in America the degradation of the rule of law. We've even seen that with crypto, right where it under the guy against the regime, crypto was based as a criminalized crypto without passing legislation to do so.

And then under the Trump regime, it's all it's a free for all. However, I do think that part of America's strength lies in its decentralization, as in you don't have a particularly strong unitary authority that can exert massive amounts of controlling the people's lives like you do in most European states.

I know Germany is slightly different with this federal structure, but most European states are unitary entities where the government says, hey, we're going to surveil you like and and and look at them create an unwarranted financial surveillance regime and there's something you can do about it. And if you think that we're, and if you complain, we're going to

just call you a child molester. This, this is hard to do in America because you have state governments that's generally have political incentives to push back against the federal government when it comes to things like online surveillance. It's actually the state governments that are the ones pushing it to, to perform age checks and other content. It's a very mixed landscape. But as a, as a core cultural value, America does value free speech.

Regardless of what the rules say, the laws say they value free speech. You'll see that getting eroded for people in out groups, immigrants, people on visas. But I don't think you'll ever see a world where American, the American people as a culture will will say, yes, we were willing to take we we're willing to curtail free speech to, to, to gain safety. That's not going to happen.

Whereas I think in Europe and in the UK that is that is currently a debate that's happening and you have very powerful factions pushing for less acceptance of free speech and more acceptance of governments oversight over what people are saying. And I think that that is very, very concerning. Cool. Thank you for coming on again, Zach. I, I, I hope, I hope you're right. I mean, I, I share your pessimism with respect to Europe.

I don't share your optimism on on the other side of of the Atlantic, but yeah, your word and God's ear. Thank you. Just just to be clear, I mean, I'm not based in the UK, North America, and I wouldn't say I'm optimistic on America. It's just that I think that it's, it's more likely to preserve like it's not moving in the right direction. It's just moving in the wrong direction at a much slower pace than the rest of the world, if that makes any sense. I'm not sure I call that

optimism. Cool. Thank you, Zach. Thanks a lot.