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

Transcript

Welcome to Epicenter, the show which talks about the technologies, projects, and people driving decentralization and the blockchain revolution. I'm Fred Anst, and today I'm speaking with um Zack Williamson. You're not going to launch this thing without decentralization, right? Kind of like you want a decentralized sequencer and and provers. >> We're not doing this out of some moral crusade. We're doing we're decentralized because we need to be. We can't be centralized. We'd have to build in a back door and we don't want to build in a back door. Back doors are really bad. you you want to use things that are battle tested as much as you can, right? Building novel things kind of means um having to build new systems. Um but trying to possibly fall back on proven systems. There's no such thing. There is

no fallback. We are the first. AIC will be the fallback for future generations of private cryptography. Once we hit beta, we will be much more comfortable making claims about its security. We'll be much more comfortable with people putting large amounts of funds in. Um, but until then it's it's going to be a risky protocol. >> I'm Fria Anst and today I'm speaking with um Zack Williamson, co-founder and CEO of Aztec, a um 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 rebuilt from scratch. Um, the new Aztec promises fully private smart contracts, not just private balances, but private logic, computation, identity, while still remaining compatible with Ethereum's public ecosystem. Um, 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 one of Ethereum's earliest projects into a powerful ecosystem for open userowned finance.

Nosis is also the team behind products that had become core to my business and that of so many others like Safe and Cow Swap. At the center is Nosis Chain. It's a low fee layer 1 with zero 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 this is governed by Nosis Dow, a communityrun 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 in web 3 or you're just curious about what financial freedom can look like, start exploring at Nosis.io. out.

>> Zack, 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 Epicenter when Aztec was still running its earlier version. Tell us what's happened since. >> Yeah, so back then I think we were we were on Aztec Connect um which was a uh continuation of the world's first fully private rollup. Uh so it was a layer network where you could send private transactions uh and use our network effectively as an anonymous proxy into Ethereum DeFi. So you could talk to something like a unis swap or an ave contract and have the Aztec smart

contract act as your proxy. Then the result of that defy interaction 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. uh something we call uh turboplunk um was a was a was an extension of the original plunk paper that we put out in 2019 but that was a clinic 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 along was create a private smart contract ecosystem. So one where uh instead of just doing transfers or talking to DeFi, you know, you have a

sharing complete smart contract language where you can write your own state your own state transition functions and uh describe the logic of whatever protocol you desired but with private data as a first class primitive. Uh so yeah that's what we just that's what we decided to build I think shortly after um our first um 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 had I think it was 60,000 multi-active users.

It was it was uh was and growing quite rapidly. The the the challenge was that connect was built from scratch with the latest technology we had at our disposal. Um you no one had really built a fully private roller before. So we were figuring out a lot from the first time and in hindsight we made a lot of architectural mis missteps that we wanted to correct there really we didn't really have a viable path to iteratively upgrading Aztec connect to add programmability into it everything changed um you know the semantics of um 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 iterate as to connect unfortunately >> tell me about the moment that you guys realized 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 have some sort of so so tell me how that went down.

>> Yeah, I still feel like p of guilt whenever I talk to somebody and they say, "Hey, I use SAS to connect." I'm like, "I am so sorry. >> I use that connect." So sir um it was tricky you know it started with um we had some internal conversations basically there was there was this inciting incident where we made some research breakthroughs that made the full programmable version possible and it was it was an evolutionary process um you know a lot of our resources were spent maintaining this no software we didn't really have the ability to really launch this what we were calling Aztec free project uh you know some there were some people we were having discussions people were like hey like maybe we need to kill Then that started turning into internally like quite quite a quite an active discussion and yeah like

eventually it was um ended up just me and me me and Jonah in the coffee shop having a very long conversation um about about the future about what we wanted to do. We we we came to an agreement that yeah we need to there's no way that we can serve both ASA connectic 3. One needs to go and and it should be a connect but it was it was a it was a tough conversation. Which one of these kids do you think we should kind of put up for adoption sort of? Yeah. >> Yeah. You know, everyone says they love their children equally, but maybe deep down >> like one of them is asex don't want to acknowledge. Um and then we're like, "Yeah, okay. One one of our kids needs to die." Um prepare the sacrificial altar.

>> Okay. Maybe maybe let's move into kind of like more cheery um territory. So um 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 call it Aztec now. We're releasing you and it's not ASC anymore and it is alive. It's on public test net. It's fully decentralized. Um you can deploy contracts to it today. Uh send transactions to it. Um I think it's is it playground. Network I believe. Uh and we are currently going through a audit process. um and you know doing some lastm minute uh adaptations to it uh to get it ready for mainet which should be happening early next year. It's exciting,

>> very alive and kicking, you know, like now now now we're the main focus internally is basically focus on the DevX. We we launched the test net earlier this year. Uh and you know we we 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 one where a mandate now we need to make it good uh easy to use for use and develop for. Um so that's still a work in progress but by the time we we hit um hit our launch next year that should be all um squared away. >> Fantastic. Um 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 um I think maybe it's easiest if we

kind of walk through them one by one. So kind of the first I noted down as kind of um decision to kind of have a hybrid public and private execution situation. Tell us about that. >> Sure. Yeah. Well, that that came out of again like I think Aztec connect was was was existentially important for us because this came out of Ast connect like a learning that we were like we realized okay so with private state the way currently is at least if you don't have FH you don't have a launched NPC like like tao stuff which we do have but not yet like protocol level at the protocol level uh all all private data is encrypted and you need to use a UTXO based states model uh to do that like like bitcoin where instead of having an account where you have a regular 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 uh 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 network database and you can see it change uh and therefore you can see the transaction growth. >> You also need the entire state, right? because kind of like if 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 um history of the state in order to kind of arrive at

>> you do but but in an accountbased model you still in this in the state tree you do you do have like a state a variable state tree will have your balance f might be tricky but >> and so when a transaction changes it you can see that and that's not okay if you're private um so instead we have a you know we have the model that that really use Zcash 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 of destroyed notes uh and the records have created notes.

You use different decryption algorithms for them. So you can't so that an observer can't link the two. So if I destroy two of my notes create two new notes, maybe one of those owned by you, one of them is owned by me. uh nobody the only thing an observer can see if they look at the network is that um two nodes were created two notes were destroyed but they don't know what they are and they don't know how they're linked therefore it's private however the problem there is well if it's private if it's encrypted how do you do global state as in uh you know take unis swap as a smart contract if you have an amm liquidity pool well you need to know what's in the liquidity pool so that uh you can perform your liquidity calculations um and like a an or token

which has a total supply how do update that if everything's owned by somebody um who holds holds a decryption key, you can do it via NBC. You can do it uh which is very challenging. Um 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 Aztec to make an AMM is well you make the AMM fully public. So you can see the 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 uh of the participants. So, I could put some USDC into an AMM uh take out some ETH and people can see what's the prices, but they don't they can't they don't know it

was me. 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 um you've not been cheated you've not been manipulated but you can sorry I'm rambling here a little bit bit of monologue uh you know with advanced embassy shared state primary like tata which is present on Aztec you can create fully private contracts if you desire it uh it's just right now um the the infra to handle that is less built out um 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 um allow my besties to kind of trade on sort of thing. >> The code for private contracts does not have to be published. Um if you you need the code if you're going to send a transaction uh but uh it's not published by default. So if you want you can just um share that um code with a selected group of people have a white list so that you can basically have this completely isolated suite of smart contracts within the ass network that nobody else knows about. Can't remember if I don't think we've actually added it as a primitive yet 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 an encryption 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 the public and private functions. So a canonical token contract is 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 group of people if you really wanted to. >> Okay. walk me through um I mean so at the face of it's it's kind of like it sounds very sensible um but kind of as an engineer it sounds tremendously complicated um to kind of construct something like this walk us through kind of the challenges um and uh the solutions that you found to them.

>> Oh so many challenges. >> Yeah. uh 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. Uh the goal is that for a you know any web 3 engineer to be able to to write into play smart contracts you don't need to know cryptography or weird weird complicated semantics around around primacy. I mean I guess the the very first problem was just technological as in if you have private transactions then each transaction itself is a zonal proof and so how do you make that proof? um because you know normally if you look at things like the the Ezeki paper and and early attempts at creating private transactions they they're very unintuitive to a developer or engineer.

Um the idea is there is that instead of having a instead of having code that modifies state uh you have state that um is attach that comes attached with some code which defines how that state variable is created or destroyed. is that how we used to that's how it used to work. And it's like it's 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 circus for and actually go okay 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? Um so we had to we had to come up with some very novel cryptography to even pull this off. Uh 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 zon proofs that need to be recursively composed together. you need to had like to handle um large amounts of data transfer between these zonal proofs effectively you know you call algebraic circuits that you're trying to pretend are iterative programs and and and creating a zk proving technology that can handle that is was very very challenging but that was just the first that's just step one then on top of that you know we needed to come up with an API 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 and you'll see on a second you need to interpret those inputs according to some API so that

your protocol level circuits can figure out what to do. Um we need to undertake to to figure out how our state trees worked. You know even that was non-trivial. Um how do you do events in an encrypted way? How do you do state sharing efficiently? So if I you know technologies like Zcash um I think they've made improvements recently but back in the day same with a connect in order to sync to the network you need to download every single piece of encrypted state and try to decrypt it yourself to see you owned it. That doesn't scale. So how do you how do you create a world where I can send you a note where that note doesn't necessarily represent tokens. It represents arbitrary state in the smart contract and you know that this has happened and you can decrypt that information without having to

sanction the entire network. Uh again like that that's that's an open problem. Um it's until we have much more advanced FHE solutions there's always a trade-off there in terms of um uh privacy. So so figuring out where where to go on that trade-off was very challenging. >> Yeah. Just the start of it. you know, then there's how do you uh 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 uh in the public domain. We had to figure out a lot of that ourselves you know eventually we even realized for our particular needs we needed to build in a very small data availability network into our layer 2 in order to secure certain library 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 um is that not only kind of uh did did you not want to make compromises in the privacy realm um you also told me back kind of like when I last had you on you're not going to launch this thing without decentralization right kind of like you want a decentralized sequencer and and provers even if you kind of look at L2B Even the non- enrypted edus 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're doing we're decentralized because we need to be the same reason why if you take the internet and HTTPS you know where now all all requests to to to a website to it 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 overregulated um uh company in existence. um you know because everyone every every government agency we go to them going hello I would like all your information please and thank you please encrypt it all the same reason for Aztec we can't be centralized not without we'd have to build in a back door and we don't want to build in a back door back doors are really bad so we need to be decentralized uh where it is a genuine

distributed network made up of thousands of different participants um that that are all collaboratively participating in this network and so we're one of the few networks that genuinely has an incentive to to decentralize most layer 2's decentralization is actually corrosive to interests because if you're an EVM um either a ZK1 or an optimistic one, your unique value proposition is price and throughput and latency. Basically, cheap transactions, lots of them instantly settle. I I would I would kind of I would contest that I think so kind of in kind of because in the failure case um that kind of kind of like someone god forbid compromise the one multisc that you kind of use to kind of govern uh

URL2 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 for a minute, if you look into traditional web two traditional software, how often do companies invest in their security like not not very 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 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 model is being AWS. >> Yeah. Yeah. Um how decentralized are you if all your decentralized knowers are running on AWS? This is a genuine thing we discovering and wrestling with. But yeah like you know if you're ZKL2 decentralizing makes your costs go up right your transaction latency increases your the throughput like the network throughput decreases the GPS load goes down. And so there's very low desire 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 protocol to select sequences is somewhat novel. You know, there wasn't anything off the shelf that we could take. And you'd think you'd do that wouldn't be figured out by now. You know, you got you have a

bunch of L people who want to produce blocks on an L2. They're staking on L1. You know, how how are they selected? You do that, get sorted, but it's not. Uh well, it 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. Um which again, it's a bit surprising. We couldn't use anything completely out of the box. to do it ourselves. The the most interesting one for us was a unique characteristic of Aztec which is that ASIC transactions an individual user transaction contains within it a zero knowledge proof right you have your your transaction data which describes what you want to do which will it'll be encrypted but that's it's fundamentally it's 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 rollup blocks we effectively swallow that proof data right if if you're making a a proof of a AIC block you are inside your ZPA circuit you're verifying ing all of the individual transaction proofs, which means when you publish the block, you don't need the proofs anymore, but you need the proofs to make the block to 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 and that's expensive. And we're 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, you have a statistic secret between block producers and block provers, right? The block producers are making the block. if they're not publishing the the user

transaction data onto L1, you need to guarantee their data exists for about 20 minutes so that a block prover can still make that block. Um, and so we're like, ah, oh god, we need a we need a DA layer to make this happen. Like, we need a 20-minute DA layer. Um, it's not the most impressive thing in the world. Um, it uses some basic economic consensus, but we had to build that out to to make our LT a reality. And that was an interesting detour we weren't expecting. Um 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 two notches so um imagine um I'm an entrepreneur building on Aztec um so what choices do I have to make

that differ from building on a more um standard rollup like base or arbitrum >> yes 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, you do have to learn a different programming language and a different technical stack. We figured the the semantics around private state on a blockchain are sufficiently distinct 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. Uh it's it's called Noah. Um uh and it's it's basically it's heavily inspired by

Rust. So if you know Rust um 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 uh certain um yeah, custom uh well, as I said, semantics keywords that you'll have to learn in terms of, you know, how this how status uh how to how to create the state storage slots, how to how to how to manipulate them when it particularly when it comes to private stuff. But um you know, our docs are constantly improving. Uh I think hopefully by the time that this is broadcast um there'll be our latest docs will be we're going through a documentation revamp. So hopefully that'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 um to send transactions to. That node has a API that you can uh interact with. Um you know you can write contracts uh and there's contracts. You define an API that your node uses to get data and you can connect this all to you can communicate all of this with a JavaScript wrapper if you want. um so that you can write a web application. So 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. Um and then you know these functions can call other functions and you can events you can you know do do all the similar stuff you you expect from a contract ecosystem. There's just a few more a few more keywords that you have to think about because of the public private thing. >> Okay. 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 LT gas. We call it a feed juice, you know. Yeah. You know, um we have 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. Um so that I'm I'm not put up uh 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 or kind of like the trade-offs you kind of make for this.

>> So yeah, I'm I'm also I'm also exhysist so I can relate uh hopefully over the years I've become better at certain programming I used when I code for tech. >> What do you mean I can't do this in Python? Can do everything in Python. Yeah. >> Yeah. Well, in my case, Fortran. Oh my god. That's >> You don't look old enough for this. Okay. >> Uh 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 um are varied, but generally they will um 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 want to create an

application that's based around information asymmetries. You want an application where you're interacting with somebody a third party like a counterparty and your counterparty knows 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 some of the low hanging fruit for that is games. To give an example, the original breakout NFT from 2018, I think was CryptoKitties, uh, which was all about, you know, you have these cats and you can breed them. You can combine other cats to create new cats with different traits. And back then, what they relied on was code obiscation. Basically, they didn't publish their source code. Uh, and so, um, it was hard to figure out ahead of time what how to breed cats to get the optimal desired traits. Nowadays, that won't work. um that kind of stuff gets

instantly reverse engineered because the overall skill level is much higher. Um but you could use privacy to actually make sure that you couldn't you can you can use things like randow and some randomness um to to basically make it so that only at the conclusion of your transaction will 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 build on top of this? Oh, but we can we can write we can we can we can breed private cryptog goodies. This is fantastic.

>> You did not say most press sorry this is this going to solve all society's problems? Absolutely. Y it's relevance. Um and and this will be this will be demand for that kind of thing on chain. um the most useful. >> 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, right? Kind of like if you look at kind of like these 80s arcade games kind of like they're tiny. Um so kind of running them uh in this kind of environment kind of I I totally see where you're coming from. more more useful stuff would be um for web three native utility um would be some basic identity protocols to protect against civil to make to for civil resistance basically um proof of uniqueness uh so

that you could do things like uh airdrops that can't be you know farmed by somebody pretending to be a thousand different people or if you want to do a uh 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 DAO but you want to use quadratic voting where the more tokens you have like the less the marginal like voting power of your additional tokens. Um there you again you need civilizations. You need to ensure that one voter like that can only vote once um instead of pretending to be 100 different people with smaller balances 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 ZK passport then that can be expanded to do finance

status exists in in in regulated spaces. So if you need to prove somebody's not on a sanctions list for example or maybe you need to prove transaction limit so that somebody is not transacted like above a certain threshold um in a time period uh or you need to know that somebody's resident in a certain country things like that where you can basically add in um identity credentials to build out DeFi protocols that interact with assets that are all originating in the real world and again I think this is also one of the reasons why um the one of the original use cases for NFTs didn't take off NFTs originally people were like Why aren't these useful?

Tickets, you know, uh because ticket master is is uh charges very high fees. Ticket technicians tak why can't I get rid of them? Well, because uh one of the reasons is that to make that work, you need to link an identity to cryptocurrency accounts. In a transparent world, if you have identity protocols, that's no longer such a challenging thing to I 100% concur that that would be incredibly useful and kind of like barring kind of like all uh potential attributes of your uh 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, um typically proving um

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 how do you get around that? >> Well, a couple of things here. First of all, um there's very there 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, fair drops. Then there's basically I think the more the more mainstream your use case, the more unnecessarily uh overregulated it becomes to be fair like you know these regulations were not drafted by people that knew about zero knowledge proofs.

So the idea, you know, when people were drafting here like um proof of age laws uh you know, god knows when, 1950s, right? Like the idea that you could prove your age without seeing like I I I as a 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 advocacy work that we're doing. I I do think that legislators, politicians are they are actually oddly like becoming more aware of zero knowledge proofs um and and that this will change. I do think there's plenty of regulations that are actually very amendable to zero knowledge proofs already. Things like um using ZK passport um in particular passport proofs because um e passports already a thing there's already um

precedent that for them to be used in things like passport gates that um there's already a wellestablished understanding that these are very strong credentials. You also have a lot of precedent from the document signing world where digital signatures on documents can be as good as the real thing. And so you can start you can kind of combine these precedence to make claims that some of these onchain like some of these zkbased identity solutions are good enough. Um obviously >> yeah I mean if docuine 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 um 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, and I think I

mean different jurisdictions will progress at different speeds. You know, for example, the US is already in in the process of passing several crypto regulations, the Genius Acts. Um there's the Crypto Markets Act. It's got a fancy name. I can't remember for what it is. Europe will be much slower to to be very blunt. We're not really like um >> we always are slow. >> If you want to do some advanced enterprise privacy stuff, we're not talking with EU people right now because Europe will be very slow. Nevertheless, there is value 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 uh conservatism under the Biden administration. My country among them there were many voices advocating for what could be done and the value that

could be generated. Um and and now these countries will pay like will deal with the consequences of inaction. The the economic center of gravity of crypto will be America. Um and that's just the way it is. te tell me about the performance tradeoffs for programmable privacy. So um is kind of like what's the bottleneck right now for performance? Is it is it the proving or what kind of constrains me? >> Um proving is is proving is is more of a user experience bottleneck than a performance bottleneck because your user makes the proof and then they send it to the network. But the like when it comes to transaction throughput, the amount of time it takes for the user to make

through doesn't really matter because you can um you have large numbers of people making proofs at the same time. For network throughput, um right now we are targeting uh for our very first release um on the Ethereum mainet, we're targeting a whopping 2TPS uh which does not sound like much. However, if you look at the um throughput of existing L2s and how much they're being used, uh 2TPS is uh actually quite more than it's fine. Um and over the next 12 months post launch we'll be scaling that up to 100 TPS. Um some of the bottlenecks are well there's a lot to prove in a roll up in Ezeki because um we have something I didn't even mention until now. Um we have a a public virtual machine a ZKVM. So for

all the all the public things that you're doing like public functions, public transfers, they're all proved via ZKVM. That's that's proven server side. You know 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 band throughput because every user transaction is accompanied by zeros proof and so in your peer-to-peer network um to get that transaction into meool, right? need to propagate this information and uh your peer-to-peer network throughput will be substantially lower than the bandwidth of of your node operators and so the the zon proof size there actually is quite important uh 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 work that needs to be >> to four kilobytes yeah um it's not it's not a hard problem it's just timeconuming so we haven't done it yet um uh the uh using multi multi-polin B basically instead of committing to one polomial like one commitment per polinomial you just have one commitment for lots of polinomials and then there's just generally our node software because we built everything from scratch um you know because we have 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 um which handles you know state privacy syncing state retrieval zing uh we wrote this all all of our ner software in Typescript so we could rapidly prototype but this is not a performant language so

there's there's huge amounts of engineering work to do um to to improve our performance like to get from TTBS to 100T TPS most of it is just pure engineering um taking something which is brand smacking new 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 um 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 battle tested as much as you can, right? Kind of. And I understand that kind of like sometimes um entering building novel things kind of means um having to build new systems. Um but trying to possibly fall back on proven systems. There's no such thing. >> There is back. We are the first AIC will be the fallback for future generations of private cryptography. There is nothing else. Uh so we didn't have that option. If you are building your own cryptography, uh there's dangers there.

Um the typical canonical business of don't roll your own crypto is targeted towards software engineers that don't understand cryptography. Um they're not like so so okay 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 you need proofs of soundness. You need proof of completeness. You need proofs of zero 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 but nothing nothing weaker than that and then you need to once okay so then then you have the theory down then you need to 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 does it will 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 base our security proof around are actually not known to be true we do not know that there is logorithm 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 Ethereum early next year. What that is going to be is we're calling it the Aztec Alpha. Uh because we will not be under any illusions that this will be secure. We will have done our best efforts. Um we would have gone bey gone

beyond all reasonable attempts to to to secure this network um with our internal external audits. But there but you know any software engineer will tell you it's not possible to write secure code. Um it's just not it needs to be battle tested. There will be bugs. The bug will be found hopefully by white hats um because of our generous bug bounty. 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 don't put any money. You're not prepared to lose. And we were 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. Uh we're going to need to not have any serious or critical bug reports for 3

months. We're going to need to have something like 99% network uptime for 3 months. And once we pass these criteria, then we will consider the network to be in beta. And once we hit beta, we will be much more comfortable making claims about its security. We'll be much more comfortable with people putting large amounts of funds in. Um 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 um a little bit earlier kind of the bandwidth issue with kind of submitting um the proofs as well as kind of the um generating um the proofs. Um h how much do you worry about 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 a large variety of use cases. We are targeting 12 second latency. So we're not producing blocks every 12 seconds, but because of our proof of state network um 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 um where at that point um that is a lying they'll get they'll get slashed and so there's a few there'll be a few million dollars of um value backing that claim. Is that good

enough for everything? No. Um 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 um like livveness sensor resistance guarantees. And uh there's no market for security. Uh it's not like you can choose to pay less if you don't care so much. And so the solution to this in my opinion is the um uh the L3 thesis application specific thesis. something that we are post-launch we will be aggressively building out uh via the Aztec stack.

Basically um imagine a scenario where you can write an AX smart contract and it's it's all the same as as a regular ASX smart contract but when you when you go to deploy it you're not deploying to the ASC network. You're deploying it to a rollup that's hosted locally or hosted on in in AWS. But basically it's a network where there's only one sequencer. It's not decentralized. There's no data availability guarantees. You just trust a sequencer. Um uh and in that kind of model you can get very far uh 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 trees but everything else is fully parallelizable so you can make

locks very quickly uh and this this L3 component will be very very valuable for low low value high throughput use cases things like microp payments things like gaming. That's that's how we plan to solve the problem. >> Okay, that that also kind of solves your two transactions per second dilemma to some extent. Um, how do you think about state growth and storage in a world of encrypted data? >> Yeah, it's challenging. Uh, you got to start this. Basically, the state tree only ever grows in a private network, right? Um, 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. Um, and you do it in a way that you can't link the two. So data proliferates much more rapidly on a private network than a public network. And uh, there's a really great solution for this right now other than basically you you do sharding you have state epochs where let's say I don't know like maybe a gigabyte terabyte um, of state per epoch and whenever you're performing state transitions you're specifying the epoch of your note. And so this um leaks a little bit of information because if you're modifying a really old note, people know you're modifying a really old net. Uh but um 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 okay so there's sharding uh you could do like the full Ethereum Foundation sharding desire uh but that's uh I mean that's challenging. I'd prefer it if somebody else does it. I prefer if Ethereum does it. Um but right now um yeah it's bit it's a bit beyond us to build that all out from scratch. >> Cool. So kind of like um 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 sorry I just realized shing doesn't work for us because um if you have just one giant database even if you 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 Merkel proof >> um which requires knowledge of the

entire data set and that's the problem. uh you need to be able to do inclusion and non-inclusion proofs over subsets of your data and that requires what like what I call charting like splitting splitting your state into epoch 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 um chains so kind of if you look at systems like alio or namada or zkync'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. Uh 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 too like I don't want to throw shade um around things like the model we we'll see about like about them. I think that they have a very ambitious goal uh in mind. they I feel they they're the ones that use FHE to fully like to create like a fully encrypted Ethereum. Um there are certain challenges with FHE uh that are yet to be satisfactoriily solved. Uh otherwise we use it. Um so one of them is uh so if with FHE uh you can so okay with ZK I 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. Um you can't do that with ZK. So it's much more powerful in that context. However, it has two two very big claws that need to be resolved. One of them is the data is all still encrypted. And so if you want to just take a regular EVM uh and make it all encrypt all the data and then use FHE then the problem is who owns those decryption keys uh you need a basically you need a multi-arty computation network to hold that uh to hold part like sh like partial decryption keys for your state. If you have that MPC network then you can also use that NPC network to do zonol proving in via secret

sharing. Um this is what tets do you get very similar outcomes both both ways. um the whole like who holds the decryption keys um how do you do key rotation to make that secure is very challenging and and we we'll we'll see we'll see how they how they how they execute on that um 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 if if any of them were successful um you have things like ZK 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 an L3 and people trans send transactions to you and you don't broadcast uh

anything about that L3. So so the way that you get your transactions is not through your public network, it's through private information um private messages and then when you make your rollup proof you basically discard all of the information around the the data in your um in your rollup and then you put that rollup proof on chain. Is that private? Yes, it's the same with a private server as private. It's not a great way of creating a composable ecosystem. Like the thing about the thing that I think is most valuable about privacy is composable privacy. The idea is you can write a private smart contract. I can write a private smart contract. Um and these things can talk to each other. They can they can call each other. And that's um like we don't have to share any information with 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 nice trust assumptions. Um, if you want composable privacy on a network like ZKync is building where everything is run by one server and that one entity sees everything and nobody else does, it's a huge amount of trust you're placing on that person. But it it is useful for certain use cases. It's useful for enterprise. It could be useful for gaming. It's useful where the trust assumptions are very low. But yeah, and then you have um other other teams like um Alio and Mina that are basically doing the ZK route that we are there. It's it's uh it's an execution play um about whe 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 Aztec's cracked it. We're not even launched yet. I hope he will, but nobody has yet. I I'm convinced as a matter of faith that uh privacy is useful, that it's needed, that 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 competitive enough to provide the developer user experience that people require.

>> Aztec is an L2 on top of Ethereum and kind of um the decentralized world has shifted since you decommissioned the last version of Aztec. Um, h how do you think about the benefits of being an L2 on top of Ethereum rather than say a standalone L1? I mean, you already have the decentralized sequencer set. You could just be an L1 and kind of like not pay uh for living on top of Ethereum. No, >> you 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 US dollars you have or your property or like who you are. And so you have a very big chicken and egg problem if you're running as an L1. Whereas how do you get value into your ecosystem? Uh because it's completely new itself from scratch. Like obviously you can do bridges but bridging is still a fairly complicated process with an uppleasant user experience and ultimately yeah it's it's uh we we thought the costs the risks would be too great. Um, and also we did gain a lot from building on top of 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. Um, I was hoping at the start they will be much lower than they are. Uh, but yeah, we've had to build a lot ourselves. Ethereum is still the cononical source of assets on CH. uh you know if you want to issue an asset okay you can do salana 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 Ethereum and we wanted to be able to make it so you could very trustlessly bring your assets into Aztec from Ethereum because just in the same way that Ethereum is the cononical source of assets our goal for Aztec is to make Aztec the colonical source of credentials effectively 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 um that that that credential to either people or to smart contracts and yeah we felt we felt Ethereum is 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 and out of Aztec from any other network for us is extremely important. We don't want to just be tied to Ethereum because there's a very unique value proposition for Aztec that no other L2 faces. It's it's not a secret that most L2s 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 at 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 um trading marketplace on Salana. Um but you need a level of compliance. Um maybe the assets you need to know that people are not on a sanction system on Iranian. Maybe you need you need to understand if someone's American or not, things like that. Some basic compliance. Well, what you can do is you could 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 they're complying or no they're not um Salana that application Salana has gained something of value from interacting with Aztec and the Salana network has not lost any tokens effectively you get a privacy shield for free at well for a very low cost uh and that's that's the direction we want Aztec to 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 into Aztec and then they stay there is you bridge identity information into and out of Aztec or maybe you put tokens into Aztec so that you can create um 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 um yeah 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 um an identity layer. Um what 100% agree with everything you said. If you look at how assets are actually issued in the Ethereum ecosystem um today, I know that kind of like back in the day we talked about um assets natively being minted on Ethereum mainet and then kind of being bridged into L2s

and um uh and then kind of things happen on L2s. they get rolled up and then kind of like you bridge out of the L2 um onto main net. Again, what we effectively see is that kind of like acids are born on L2s, they live on L2s and they die on L2s and you know ideally they're happy on L2s. Um, 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 um you only inherit for uh for bridged

um assets from mainet, 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 LTS are centralized and so you have this kind of the weakest the weakest point of failure is some some something in the L2 like a multisync or something. It's a bit different for Aztec where you know you have user you have you have um sequences um uh staking on on Ethereum L1 uh to be a block producer and once a block has been produced and it's and and you've updated your state route then you're you you are very much relying on Ethereum's consensus to define what the cononical version of AIC is and so I do slightly disagree with the idea that um you don't

inherit anything from any security from Ethereum. I mean we we we targeting to be a stage two roll off on launch where that kind of that is kind of the point >> but say say I kind of deploy um some sort of token on Aztec directly right um I can't force exit to Ethereum 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 called it 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 sequencer. It's basically a free fall.

The idea is we don't intend for this to be used, but it can be used if you're getting censored for some reason. You can use that window to make your own Aztec transaction um to exit. Uh if for some reason there's something catastrophic failure state and like no bonds 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 asset that was not minted on Ethereum? >> Oh, it wasn't minted on Ethereum. Oh, >> it's minted on Aztec. >> Yeah. Yeah. Yeah. Okay. In that case in that case. Yeah. If you vented on Aztec, then you can't force exit. Yeah. Because like exit. So I get I get what you're saying that the the security guarantees you get are kind of it's the it's a

combination of Aztec and Ethereum where like the weakest like security holes >> 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 L2s all the time now. So kind of like if you look at the values um that kind of get transferred on L2s 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 major but the majority of value is not on L2s as in LTS 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 um for for for a network that has like useful economic activity on it. You're right that. Okay. Yes. So, so what happens in L2s is you get these synthetic meme coins that get produced and um uh yeah, it's it's all on L2s. Does it matter? I mean, do you need iron inclass security for for for a memecoin? No. Um so so I don't see this as a problem. I think that um for for ASIC, it's fairly clear, I think, how things are going to play out. Um, if you have an asset that requires identity checks, regulated checks, it's going to turn it's going to turn off an ASTIC as a native asset. Is that secure? Yes. Uh, because we we're fully decentralized. We

have a very we're going to have an enormous amount of stake uh 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 it security. What what I don't want to see happen is that ASEX starts becoming like very parasitic to Ethereum. >> Yeah. Uh I I hear that. I and I think that's commendable >> because I think that the value proposition really is with bridging information. Um I think that ideally the only time on ASC is need to be emitted on as Aztec is if you can't put it anywhere else because it requires privacy checks um composable privacy checks that you get on Aztec. I I don't see ASC as being a very popular home for like low latency mcoin 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. Um unless we've completely failed to execute on any of our privacy unless all of my thoughts about privacy is wrong. Uh then then that's the only way that world will happen. Maybe let's zoom all the way out to kind of like past all the crypto stuff. Um, if you kind of look at the world right now kind of we are 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 is something that only recently failed. How do you see that shift and do you think kind of um that level of cryptographic privacy can play some sort of role in reversing it? >> Yeah, it's a tricky one. I noticed two 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 seems to be more and more more willing to give those governments powers and control over over their private data. Part of this is a lack is is like uh how do I put this? Privacy is not a

mainstream narrative. Uh and people don't think very much about it. Um 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 it's not part of the kind of the cannon 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 ostensibly to protect children, but in reality is um I would argue is a a massive contailment of of free speech online. Um does this mean people don't care about government overreach? 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 the like the the concept of ideas they have, right? They think identity cards they're familiar with totalitarian states 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 um or limit free exchange of ideas or make their personal data more secure and more likely to be leaked. This will change in time. I think that what's going to happen is more and more oppressive. The decision is going to get passed and it's going to be abused and manipulated um 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 other 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 um by the uh state bureaucracy. I I think it basically um America will always be basically demonstrating what's what like the the alternative if you don't have controls over over speech. Eventually it'll just become a very compelling differential. I think I hope um >> but I mean just to push back here so kind of um in some way the US are 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 uh 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 there is an element of capricious state policy. Um I think you've also seen in America the um degradation of the rule of law. We've even seen that with crypto, right, where under the Gary Gendler regime, um, crypto was based 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 control over the people's lives like you do in most European states. center of 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 and then and look at them and create an unwarranted financial surveillance regime and there's nothing you can do about it. And if you think that we're uh and if you complain, we're going to just call you um a child molester." Um this this is hard to do in America because you have state governments um that 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 um to to perform age checks and our content, it's a very mixed landscape. But I 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. Um 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 were willing to take a tail 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 government's uh oversight over what people are saying. And I think that that is very very concerning. >> Cool. Thank you for coming on again, Zach. Um, I I I hope um I hope you're right. Um, I mean, I I share your pessimism with respect to Europe. I don't share your optimism um on on the other side of uh of the Atlantic, but uh yeah, you your word and guards the earth.

>> Thank you. Just just to be clear, um I mean I'm norally 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 why I call that optimism. >> Cool. Thank you, Zach. >> Thanks a lot.