Private State, Public Network: The Tradeoffs Behind Privacy

Transcript

All right. Hello everybody. Good afternoon and thank you for taking your time out of DevCon to uh attend this talk. So uh I'm Zach. I am the co-founder of Aztec. We are a privacy preserving programmable fully decentralized layer 2. Um, and I'm um I I'm I'm one second. Um, so I'm here to talk about um some of the trade-offs and the challenges that that come with actually building a uh a private blockchain. Um, and what privacy even means. um what are the trade-offs to get it and how privacy is very much in tension with um the decentralization

properties that um we normally enjoy from blockchains and how to square those two circles. So before I do that though um I have I am going to do a minor bit of shilling because what I'm talking about is is a very abstracted ideas about privacy about decentralization but uh I've also been working for many years on making this a practical reality and today we are launching a very big upgrade for the Aztec network called Tierra um which uh massively hardens uh Aztec makes it much more secure uh large parts of the protocol are formally verified and we have um much faster finality and uh some which I'll be talking about in a bit

some novel applications that actually use some of the concepts I'm talking about here to create new types of utility that we don't see on public distributed networks until now. Um case in point uh ZK money. So this is privacy and practice using some of the concepts I'm going to be talking about. Um, that QR code, the first person that scans that and puts it into the ZK Money app will get a nice surprise. So, that QR code is disappearing in three, two, one, okay, so what is privacy? Everybody talks about it. We're all here because we are either curious or we care about it to some some degree, but it's a very nebulous and vague term uh that means a

lot of things to lots of different people. So let's try to disambiguate. Uh there are three core um properties that one one associates with privacy in a blockchain environment. You have user privacy which means that observers do not know who you are when you are transacting on chain. Um uh including things like your address. Uh you are completely anonymous. You have data privacy which means that the the information that you're modifying on that on the on the network is not visible. It's encrypted. So that would be if you're hiding uh balance transfers when um when when trading around a token. And finally, you have contract privacy, which means that you don't observers do not know what smart contracts you are calling. They don't

know the code that you're executing on chain. And if you combine all the three of these properties, then you have what I would call complete privacy, which means that an observer, they don't know who you are. They don't know who you're transacting with. they don't know the the the smart contract that you're interacting with and they cannot see any information um that you're updating or modifying. Uh and that's yeah complete privacy. I also want to just you know let's let's refresh what the core blockchain properties are that that that we all care about that makes blockchains so um unique and uniquely valuable. Uh you have obviously permissionlessness. Uh I um anybody can use the network. Um anybody can deploy a smart contract. You

have censorship resistance which means you know nobody there is no privileged entity that can stop you from sending a valid transaction. It cannot be to you. And then you have livveness. So valid transactions they need to be if if it's a valid transaction it should be able to be included and finalized. Um these properties are in tension with privacy. Uh unfortunately it's just a reality. Um because if you're building a privacy protocol, particularly one where you have programmability, feature-rich privacy, so you have encrypted information, you're using zero knowledge proofs to perform state updates and state transitions. Um, you know, you need to be able to distinguish in your protocol to some degree or in the

applications running on your protocol, you need to be able to distinguish honest actors and malicious actors so that the participation of honest actors does not help and assist malicious actors um uh to perform crime, to steal money. uh otherwise um you know if you do uh create a compelling and valuable privacy protocol that that doesn't make this distinction then you'll just end up funding North Korea's nuclear weapons program and then everybody will hate you. Uh but this is this poses a massive problems because even the way I've phrased it like what's a bad actor?

That's a that's a very subjective call um and decision. Who who gets to decide? Um and there are trade-offs here. You know, if you have some kind of permissioned access um to prevent bad actors from operating on your network, then you've sacrificed some degree of permissionlessness. If you have gatekeepers that can prevent bad actors from transacting, that can prevent North Korea from from uh you know using your anonymity set uh then then you've undermine censorship resistance. And if you have third party operators that are required for transactions to be executed because you need them to audit or or validate or test your transactions, then you sacrifice livveness. Um so achieving a decentralized privacy protocol is actually extremely challenging like one

that's actually can be used and is practical very very challenging. So I want to talk about some of the solutions that are that are out there already. What people are trying, what people are doing. The the the most obvious one is just you add back doors. So you you um for let's say you have some kind of private token, you create an auditor key that you give to an auditor that then they can see everything. They know the whole transaction graph. They can use chain analytics and they can flag suspicious transactions, put them report them to the FBI, etc. So obviously, you know, there there are some ideological cons uh considerations here that you may find this offensive um and problematic and and at odds with with the concept of of of of digital money. But regardless of like there are there are going to be use

cases where this kind of system is just completely fine. Uh you know, if you're doing some traditional institutional financial product that's be uh being interacted with by a few by a few uh a few banks, yeah, it's fine. um from a from like a from a um uh from that perspective. But there is a huge security problem with this. This is just not a secure pattern. Um and and and that I think is the the the larger problem to the adoption of these systems is because if you have a view key, well that view key can get leaked. It can get stolen. And if it gets stolen, you don't know it's been stolen. Uh so which means that you have in many ways this this can be even worse than full transparency because you may only be um private from

from the people you don't care about but actual adversaries and hackers and criminals they actually can see what you're doing. Um and because once something goes on a blockchain it stays on a blockchain it means that all your old transactions if that viewing key gets leaked it's game over. So this is pretty bad. Then you have things like privacy calls which I think is a is is has has it has um drawbacks but I think is is is a much better way of doing things and it it works a bit like how cache works in the real world. So uh with tracking serial numbers. So every time you you you cross this public to private boundary um that interaction has an an ID associated with it. And when your when your data when your notes when your tokens they're in this encrypted pool um the the the the notes they track

within them they contain all of the identities that have these these these boundary identities that are contributed information to that note. Um and then what you can do is you can have a third party um it could be an auditor it could be a DO they maintain a naughty list of all of these boundary crossing events that they think are suspicious. They think of criminals they think of North Korea. And when you're transacting in this private pool, in this shielded pool, you need to prove that the sh the boundary identities that um contribute information to your notes, they're not on the naughty list. And if you can't serve that proof, you get deanmized. Um I think this is a much more secure way of doing things because it doesn't rely on centralized third parties that can be compromised and attacked. It means that um you know if the if the naughty list

gets gets controlled by a bad actor they cannot deanonymize your old past transactions but obviously it does sacrifice um permissionlessness to some degree because you can get uh kicked out of this privacy pool. So I want to talk about the case for decentralization here briefly. You know this is not just some kind of cipher punk vibe based thing. There has been there's a huge um shift over the last year um in in the security landscape which which is changing what we consider secure and what's not secure and that's basic it's because entirely because of the absolute avalanche of AI attacks that we are only beginning to see the surface of um that are going to destroy

the internet next year. Um you know the in the the old the old modus operandi was you know why do I want to use blockchains because I don't trust third parties. I don't trust their intentions. their incentives are misaligned with mine. They're going to take my data, my information, they're going to use it against me. Um, you know, I um case case in point, you put your money in a regular bank and they give you like.5% interest and the treasury rate is four to 6%. Um, so you know, you don't trust third parties, but then there's now this much more pressing problem, I think, which is I might trust you, your intentions. I don't trust your security because your your trusted operator system is 100,000 a million lines of slot coded garbage that you've thrown into your into your server that you don't understand that that you don't

understand the attack surface of. And we're living in a world now where there's going to be millions if not billions of highly competent intelligent agents swarming the internet looking for every single possible attack service that can attack that that you can extract value from. Um this is going to break the internet like the marginal cost of attacks is going to zero. What used to require highly highly skilled and high extremely expensive labor to find vulnerabilities and to find the ways of exploiting them and using them to maliciously extract value um this is now based like almost free. Uh now you might think this is a bit of a weird thing for me to be saying because what I'm really saying is that um blockchains, distributed systems that exist in adversarial environments

already that are hardened against adversaries where they are often the first in class for adopting new security standards like formal verification. I'm saying these systems are going to be the safe havens that people flee to when when every when everything in the internet is being attacked, which might sound um a bit odd because a few days ago, Binance got hacked for $5 billion. Um and traditionally blockchains are the ones that are going to get attacked. It's not random things in the internet. It's blockchains. But what's really happening is that blockchains are first in line for something which is going to happen to everything because that blockchain is the low hanging

fruit. Uh they're the easy targets to go after. So blockchains are being attacked first. But what we're going to see next year is everything is going to be attacked. If you have some let's say that you have some like some tiny weird SAS company in Utah that employs five people and in their office they have some server that no one's touched for 15 years that handles company payroll. um you know in the start of 2026 it was not worth anybody's time to seek out that server and find a vulnerability that allows you to get access to it and then you can upload some ransomware um where you demanding $1,000 of Bitcoin uh to um to to release that payroll software so that company can run payroll. That's not worth anybody's time in 2026. It is absolutely going to happen in 2027 because because the the cost of of doing

that has gone to zero. The internet is going to break. the Binance type attacks are going to happen to everything. And so we we the blockchains that survive through this bloodbath, the ones that can actually withstand what's coming, the ones that are hardened, the ones that get formally verified, the ones that are secure, they are going to be safe havens for for people fleeing what is going to become an extraordinarily compromised and damaged internet. Um, this is also why privacy is so important because you want to shove as much as you can into that settlements layer, that secure, formally verified settlements layer. Um, you want to put as much as you can onto it and and rely on trusted operators as little as you can. And here

I'm not I'm talking about even things like possibly even moving web two infrastructure to web 3, you know, like CRUD apps and basic databases. But to do that, well, you do need privacy. uh because um you we're now talking about migrating systems that that use provide you data that use sensitive information that are used to being private. Um you can't throw that stuff on on um uh on base. So yeah, that's uh but but this is why decentralization is also so important because if these networks, these hardened networks, if they're not decentralized, then you haven't solved any problems. You not removed risk. you just migrated it because now you have another um third party big honeypot that can be a targeted attack by AI. So it

needs to be decentralized. Um what I'm really talking about here is the elimination of data custodianship. Um just as Bitcoin and Ethereum became extraordinarily successful they because they invented this category of non-custodial money. The same is going to happen for non-custodial data. Not custodial money was important because it meant that I can build financial products and services that um formally would have required me to be heavily regulated and licensed to be a money transmitter because I would be having to take custody of users funds and with blockchain I don't need to do that. Um I've derisked my my my my operation I could be much smaller and nimble. Same's going to happen for data credentials,

password information, anything around like around GDPR if you're in the in in the EU. um you know proof of address all this stuff that people need to verify and validate people which is going which is which is um risky it's risky because now I need to secure it against this avalanche of AI attacks it's much better to not have that data um at all uh just it lives encrypted on a blockchain but the actual plain text the secret data that that that that is actually valuable it stays with the user never leaves their device that they they maintain control you don't have these centralized sources of data that act as honeyotss um and That de-risking effect allows organizations to build products with smaller teams, act more nimly, more efficient. Everybody wins.

So, what are some of the challenges with private decentralization? I might need to speedrun this because I've not timed this very well. Um, I want to talk a little bit about some of the actual technological challenges of marrying privacy with decentralization. I've already talked about some of the you know the um the more like regulatory sides of um having to distinguish between good and bad actors but there's also really fierce technical challenges too because if I am generate if I'm if I'm using privacy then I have I'm generating proofs locally but the user is generating proofs client side um every transaction is now a zk proof and zk proofs can be very large and in a distributed network that's a problem because the um I need to get that transaction into a peer-to-peer mele

where the bandwidth is extremely limited because it's a peer-to-peer mele. Um, Ethereum transactions are a few hundred bytes. If they become 300 kilobytes because of zero knowledge proofs, then that network cannot scale anymore and that's a problem. So, the normal way people do that is with third party aggregators. You take the big proofs, you squish them down into one proof, Bob's your uncle, but now you've introduced another centralized third party into the mix. Um, they now that aggregator now has control over your network um whether it runs or not. And if you have that level of control, it you will be required to exercise it whether you want to or not as the fallout of the Binance attack is going to show us.

There are two solutions to this. The first is you have small proofs. Um this is what Aztec does. It works today. It's great. Um it does use elliptic curves though. So it's not piss quantum. So eventually at some point in the future that needs to change. As for when that that's a very open question. And then you have this idea of memple recursive aggregation where your actual blockchain nodes themselves they take these they when they receive incoming transactions they recursively aggregate the proofs. So two transactions and two proofs come in two transactions and one proof goes out. Problem with that is that that means you need to do this idea of recursive pro proof composition insanely quickly about 20 milliseconds and we can't do that today. Some people claim you can, but not in production. Um, not

with a hardened system, you can't. It will eventually become true, but not today. Okay, last bit. Programmable privacy and why is this important? This is the thing that people don't talk about a lot. Um, at least the challenges of actually like what programmable privacy means and challenges around it because programmability is linked to composability in blockchains. This is what made Ethereum a big deal. Um, the idea that I can write a smart contract that uses other smart contracts written by other people I do not know, I do not trust and and I can just integrate. I don't need to ask permission. It just works. That's what DeFi is. You can have uh I can build a decentralized exchange smart contract that interacts with other

token contracts. And then somebody else can come in and they can build um a smart contract that creates financial derivatives off top of the token emissions from my decentralized exchange. And then I can create options and prediction markets and and all all sorts of wonderful fun things. And this all relies on composability. Um it's a massive um force multiplier because it means that you know multiple people can build off each other in a way that normally you can't do without vertical integration. So if you want privacy in a smart contract environment then you need private composibility. So on the service this sounds pretty basic.

It's like okay I now have private smart contracts with private functions and they need to be able to call each other like in public. I have a token contract. Maybe there's a private transfer and because it's using some kind of regulated Tradfy asset, maybe it's a mortgage or some land certificates, I need to do some kind of identity verification. So, there's an identity smart contract where it does like a passport proof and issues a private entity and I need to do a private call to validate that you have that NFT. Well, um that means that contracts need to call each other's functions permissionlessly and and this implies some really quite horrific terrible things that people don't talk about.

First of all, um it means that your protocol, your blockchain protocol needs to have a private state model. It needs to understand what private state is, how to update it, read it, modify it, and that standard needs to be consistent across all your smart contracts. Um this means that there's state update rules that must be enforced by the protocol. But these but but but smart contract execution private stuff it's a zk snark um which is being generated client side which now means you put a lot of your protocol rules inside the zero knowledge proofs that your clients your users are generating which is ridiculously challenging. It adds a lot of complexity makes things things very challenging to do on potato devices. But if you can do it, it means that you've got an architecture which is much more scalable

because now a lot of the logic that was being executed and verified by your blockchain nodes, by your block producers, that work doesn't have to be done anymore because it's been done by the individual transaction center. And then you have this really nasty problem of constrained note delivery. People don't talk about this and I've got 15 seconds. So I'm going to try. Um, basically if you have composability in a private envir smart contract ecosystem, that means I need to be able to have a smart contract that can perform trigger private transfers uh and and private execution of other smart contracts and then and then execute do something which is conditional on that happening. So the basic example is a deck swap where Alice and Bob they swap um ZK notes against

each other. Um, okay. I'm going to I'm going to get chased off in a second, but I 20 more seconds. The problem here is that to do this in an single atomic transaction, if I'm giving you encrypted information, you need to be able to decrypt it. And vice versa, if I don't give you that decryption key properly, I have now griefed you and the remaining like that that and if if if I gain some kind of benefit from that from this D5 smart contract, then the whole thing is hosted and everything is everything's broken. And this means that um the act of me performing a public private like a of me performing a um a I need to do a secret sharing um uh cryptographic protocol to drive a secret key and then I need to do an a like a symmetric encryption to to to encrypt some some

cipher text. That all needs to be defined with inside your smart contracts. It needs to be validated and proven. And this requires you to make some very very uh challenging choices at the protocol level because these the the schemes that you use to perform this note delivery, this encryption um need to be defined at the protocol level. Um and if we had another 10 minutes, I could explain why, but I can't. So, I'm afraid I'm going to have to call it here. Uh but thank you very much for your time and your attention. >> Thank you. Thank you.

Um, I'm pretty sure there's some way you can put the slides up for people to see them, but we do have some questions. See, if I can get the Mia cat uh screen up there, so we don't have a lot of time, but we can try. First one, what's the most practical way of storing encrypted notes on chain? >> What's the most practical way? Well, um, you store a hash, um, uh, normally. So, let's say I have a note. It's got some, uh, you know, for Zcash, it contains a token value. for AIC it's kind of arbitrary data that's smart contract defined um all you need to store on chain really is just some succinct representation of that that you can then like in future transactions expand um that's the easiest way of doing it uh if if the encrypted note was not generated

by its owner so let's say I'm sending you a note well I need to now give you the information somehow and you can do that onchain um which has much more data and it might open you up to harvest now adry data attacks all we need a site channel to communicate that data data. >> All right. Can Aztec's hybrid privacy shield users from AIdriven deanonymization without breaking the UX? >> We're going to find out. >> We'll find out. >> Well, yeah. Basically, um so so even without AI, typically it's been pretty easy to deanmize users because you need to be pretty careful about how you use um like private transactions because you're depositing into a like into an anonymity set and then you're withdrawing. And so there's all sort there's timing attacks. value like you

might be looking at the amount of value that that's being deposited and withdrawn as well and most people don't do this correctly to begin with. So we so we need better software to make people use privacy tech better which AI helps with but then AI also helps dean anonymize people. We'll see where that equilibrium lands. >> Okay, this one has two votes. What's next for Aztec? How's adoption coming along? >> What's next for Aztec? Well, um AICA is next for Aztec. Um uh I'm pretty excited about this latest release because we launched Aztec Alpha in April, but um we did have to disclose a critical security vulnerability that was discovered because um effectively we slightly got uh hammered by AI uh

because uh you know most of the code that we written was human written code by at at April uh and then AI comes along and it is unbelievably sophisticated at finding very very very challenging um to discover bugs and um but but so basically now we're much more hardened. We're much more secure and so now I think I'm much more comfortable with like with with real financial flows going through Aztec. So what we're now doing is we're we're we're scaling up um our like what applications are getting launched. We already have ZK money. Um we're we're going to have anonymous decentralized social media. We're going to have NEO banks. We're going to have private inference payments. We're going to have um we're going to have perpetuals and futures. So it's a very exciting time.

Um and so over the next year basically it's security it's scale it's it's um make Aztec resistant to harvest nicip later attacks from quantum computers. >> Are nodebased privateexes or swaps possible at all? >> Uh yes. Um if you want to make it completely private including price matching you need to introduce some kind of multi-party computation protocol but that is completely possible to do. Okay, this one is funny. Can you show the QR code again?

>> No. >> No. Sorry. Okay. If Aztec uses ECDSA and SNOX today, could current users today get their past data exposed when content comes? >> Not by default. No. We we spent a lot of time um in with ASX architecture to make sure that by default you're immune to harvest now decrypt later attacks from content computers because all that's stored on chain is hashes. Um there are some things you can do that do make you vulnerable to this like um the constrain note delivery thing, but that's that that that that's only required by a minority of applications right now. Um and that's we're going to patch that up um within the next few months.

>> Okay, we have five seconds, so I think we're going to have to end it here. Thank you all so much.