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.
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.