Okay, with that, we'll jump right into our next interview for today, and this is Joe from Aztec. Joe is one of the co-founders of Aztec, and we'll talk about the importance of privacy and its implementation in blockchain. So please join me in welcoming Joe to the stage. Just sharing. OK.
Hello everyone. Good. Joe, I've known you for over six years. And it seems this is our eighth ETH global. Maybe there will be more.
Hmm, and, uh, since then, the only thing you really like is, uh, privacy and Ethereum. So it was very consistent. So my first question is: um, let's just look at why, uh, why do you think privacy is important, and how can we actually make that relevant to cryptocurrency? Yes, that's a good question. I think that question.
I think that , starting from the fact that we look at the world around us today as if we were in London, the financial center of the world, and we're quite used to the privacy that we enjoy, um, in our daily lives: when we pay someone, when we pay for the subway, when we, when we come here. And when you look at it, uh, there's a privacy in everything we do, um. And then you start looking at Ethereum, you go to Ether Scan, and, uh, that privacy just doesn't exist. Um, you can see every historical and future transaction from any blockchain from any blockchain address. You can see their balances.
Um, and this world is pretty scary. So, um, we care a lot about privacy at Aztec, because if we're going to build these new payment systems for the world, um, I think we need to at least do as well as do as well as we did with the traditional, um, banking system banking system . And that was a pretty low bar. In the traditional world, we trust a service provider with service provider with , um, all of our data. This service provider usually sells them to someone, um, but we get some privacy.
So, at Aztec, we care about bringing billions of people to the blockchain and hopefully better privacy, no worse than in the Web II world worse than in the Web II world . This has been our mission for five or six years. We are almost close to its implementation. So, yeah, I'm glad to be here. Perfectly.
One common thing we hear all the time is that there is a misconception that when people hear the word CK they think everything is private, and that is definitely not the case. Could you elaborate on what good intuition is and then digress a little bit into what Aztec is and what you create? Yes, I think this is good marketing for some of the other parts of L II. ZK is usually an abbreviation for Zen proof of knowledge, namely zk-snark. There are two interesting properties of zk- interesting properties of zk- snarks or shares that interest us.
One of them is laconicism. Um, and this is a kind of proof of computation. Um, and you can use this so that instead of Ethereum verifying hundreds of thousands of transactions or 50 million transactions like in the case of Stani, um, you can just have proof that they were executed correctly. And a lot of ZK teams are using this to scale Ethereum and get higher throughput, um, uh, kind of L2. Um, another interesting feature that's been somewhat forgotten that's been somewhat forgotten is the zero- disclosure, um, of these ZK verification systems, and you can use that to encrypt information and hide data.
So in Aztec we use both properties, um, and one of the few aggregates that actually does that, but we use the zero- disclosure property to encrypt the information, um, and hide the resulting transaction state. Um, and we can talk more about this in a second, but at a high level, we're building a privacy-focused L2 on Ethereum. Um, which has a public and private state that can be composed. Um, so let's look at this in more detail. So you use these two properties, but just to confirm, it's not the same as ZKVM.
Is this correct? Yes, that's not true. So if you look at EVM, it 's a great virtual machine, but it has some drawbacks. For example, it doesn't have built-in privacy. So we can't take the EVM and actually use it to provide developers with private states or private function calls.
So, uh, we have a different architecture. Uh, we have what we call a kernel scheme that allows users to execute transactions on their own device, create a proof on their local device, a bit like end-to-end encryption in Signal and messaging apps , but in this case you run arbitrary code on your device and prove its execution. And then that's combined with what we call the Aztec virtual machine, which, um, is just another virtual machine, a little bit like Startnet or Cairo, that has additional features, um, that simplify interacting with private state. So these two together, um, form the Aztec runtime. Hmm, and we came to the conclusion pretty early on that trying to add privacy to EVMs was, um, a stupid idea because they simply weren't designed for it.
Why? Yeah, I think, well, on a fundamental level, for example, if you think about how blockchain works, um, you send a transaction to a public node, um, and in order for other nodes to verify it, all the data has to be public. Hmm, so you can't take this virtual machine and keep the properties of strong consensus, hmm, and still get privacy. Hmm, some people are trying to do it with FHE and other things like that, but that's many years away. So, yes, we had to start from scratch and design a new type of runtime that would allow privacy to be built into these applications.
But we still benefit from Ethereum consensus. So we are something like Ethereum. We inherit all of its security properties. We get the best aspects of what Ethereum offers, but with a different execution environment. So this is very interesting.
Obviously very interesting. Obviously , an important part of being able to scale and maintain decentralization and open source is that everyone can verify that the same information is available same information is available . But if everything is encrypted, how do you get the same guarantees, and more specifically, does anything change in this way when you try to access private information? Because yes, I may not want to disclose how much money I have in my wallet, but what about my interaction with the D5 protocol that resides on Aztec? Does n't he need to know how to read things?
Can he read everything the way he would ? Are there any pitfalls? How do we think about this world? Yes. So, I think there are different mental models when you deal with private state and private execution private execution .
Uh, I think the first thing to touch on is that someone or a group of people must own a private estate and. And by "private" I mean it's encrypted to, uh, a given key, which might be a shared key between many different people, but it belongs to someone, uh. And then you have, for example, public state, which is obviously global and anyone can see it. And usually the transaction flow in Aztec is that there 's a sort of setup phase, uh, where you want to do something that hides information, uh, maybe hides your passport, proves that you have a UK passport inside, the pre-art of the transaction, the private part, and that's kind of a gateway to maybe a more public execution like AMM. So for developers, it's like the best of both worlds.
Some things, like AMM design, only need public state. You need a shared global variable, uh, to exist. Hmm, but the best thing about Aztec is that you can choose what is public and what is private to get the best of both worlds. So, I think the first mental model I would point out is that private property usually has to belong to someone. Hmm, and then I think the other thing that's a little different is when you talk about privacy or private execution, we sometimes call it the launch site.
Hmm, in the traditional blockchain model, you send me a signature that outlines your transaction request, and someone else does the calculations. Hmm, on Ethereum, the calculations are performed by the block constructor. In public L2s, the constructor performs the computation, and someone else proves that it was done correctly. But on Aztec, for the private part, the user performs the calculation and proves that he did it correctly, using ZK-sark. Hmm, and this has the interesting property that you get unlimited runtime.
In a private transaction, you have no concept of gas because if you can create proof, you can do anything you want in that transaction. Um, you can also enter any data you want into this transaction. So you don't have to limit yourself to just the data that resides on the Aztec blockchain. You can enter medical records. You can enter all your bank balances, which were in the form of a signed CSV, run some calculations on them, and then get the result.
So there's a lot of pre- configuration that happens in the private sphere, and then my mental model is that you then do something with it, maybe in the public, um, DeFi sphere. Oh, super interesting. Um, but, I think to effectively decide now whether it's the private or public side of things, you need different primitives, and you had to invent a new programming language called Noir. Um, what's the status of Noir now? And, um, how's the language development going?
Yes, we've been creating Noir for about two or about two or three years now. It started with, um, a grant from the Ethereum Foundation. Um, and so no, this low- or mid-level language is for writing, um, zero- disclosure proofs. Um, and on Aztec, all our contracts are written internally, but written in Noir. Um, but there are some libraries that help you write public or private functions.
So private functions. So , from a developer's perspective, you simply write one contract and mark which functions are private and which are public. So you don't need to think about these two different runtimes when you write code. This is a very seamless, composed developer experience. No, he's in pretty good shape now.
Um, you can already do things like, like I said before, prove that you have a passport. You can read a passport using an NFC chip and then prove that the signature is inside it. This is quite productive. Um, we focused a lot on DevX. Um, so it has exactly the same syntax as Rust.
Um, so if you like Rust, you'll like No. Um, and also, um, just getting started is pretty easy. We have many code spaces on GitHub. Um, if you've ever used codespace, you just click a button and you're taken to, um, a kind of web page that's literally Visual Studio online. Yes, Visual Studio online.
We have a great, hmm, what's his name? Something like an IDE plugin that highlights syntax. He really likes the transition to definition. So it's really easy to get started, um, with Noir. It's in beta beta testing, but it's still undergoing a preliminary audit, um, this year.
Perfectly. Um, a few more things I want to ask before, um ask before, um , we wrap up. Um, you've been a product developer your entire career , and, um, I wonder when we'll see all these things that we'll have to solve, um, in this new paradigm, especially when you introduce an ocean of now public and private data and give people choices. How do you actually make this seamless, and what have you thought about or done so far to make this on-chain experience seamless? Yes, I think it all starts with the developer environment.
So you have the noir code space that I just want to play around with, like a small noir program, but we have the same thing for development on Aztec. So if you want to, um, write test contracts in our Aztec sandbox, there's code space too. So you don't have to spend 3 hours installing the right Docker dependencies or making sure you have the right version of Node to get started. You can just start in the browser. Um, and I know ETH global usually has good wifi, but you don't have to deal with wifi at hackathons because it runs on a remote server.
So I think there are some low-level primitives that just help developers connect, and then when they're kind of in the process and they've decided they want to spend 3 hours, I think there are reasonable defaults so they don't have to reinvent the wheel reinvent the wheel . So we have token standards so you can do basic things like token transfer, and you can build around that ecosystem of pretty good primitives to actually achieve what you wanted instead of reinventing the wheel . So I think initially we focused on a combination of smart defaults and just good devx. We didn't do everything right. So we iterate quite a bit, and we have prizes at the hackathon.
So if you have any feedback, we will take it into account . What about being on-chain from the UX side, uh, just the web experience? So you're saying that people now have to create evidence on their computers. Does this mean I can't do anything because my computer isn't powerful enough powerful enough , or do I need to wait a few minutes to do some kind of confirmation or something basic? How can we simplify this experience?
Yes. So, Noir is kind of like a language that you write your programs in, but what happens under the hood is that you connect to a cryptographic server, and most developers don't need to worry about that , but Noir actually abstracts cryptography away from developers. And what we've been working hard on at Aztec is ensuring that this cryptographic server has sufficient performance. So this technology will not be adopted if there is a noticeable compromise in UX to build the proof UX to build the proof . So we set some pretty ambitious benchmarks for being able to create fairly complex Aztec transactions, like six smart smart contract calls, on a phone in under 30 seconds.
And this is kind of the most difficult DeFi transaction task imaginable. The basic payment should be in less than a couple of seconds. So you get a complete abstraction of the account. You no longer need to deal with Ethereum keys or empty phrases. You can use Touch ID as a signature.
So, we've spent a lot of time "under the hood" building a validation system that can deliver all this performance, and I think developers now just need to build applications that make it useful. Perfectly. Well, um, the last thing I want to ask you about is that the Aztec team made some bold announcements. So, I guess I'm interested in getting an update on where things are headed and what's next on the Aztec roadmap. Yes, that's a good question.
We launched our initial sandbox V 0.1 back in September, and we've been working on it for probably the last 3-4 months. It's getting close to feature completion, so it's been a lot more stable lately, and that's something you can hack, um, at the hackathon today. Yes, there is documentation on our website docs.c.
network. And you can get an idea of all the types of applications you can create, ahem, on Aztec using this sandbox. It's like a GE local node, essentially, but for Aztec. And so, from here, our engineering roadmap is trying to make everything work from start to finish. We have this We have this sandbox environment, but can we actually make it produce complete evidence?
Can we create a full rollout on the testnet? So we're going to head out to our office about a mile from here to try to get this working over the next month or two. And once we get that working, we will start paving the way for a decentralized testnet. For now, we are only focusing on the network side. So, the sequencing infrastructure, the peer-to-peer transaction pool on Aztec.
And then, maybe in the third quarter, we'll have a full-fledged testnet for developers that everyone can experiment with. Perfectly. I mean, Perfectly. I mean, it's very close. Third quarter.
I mean, we're finishing the second quarter in two weeks. Time flies. The pressure is increasing. Yes. Well, Joe, thanks so much for this great conversation and, uh, I can't wait to see the public testnet for FRS in Q3.
Perfectly. Thank you, Kik. I appreciate it. Shake the bacon.
Automatic transcript — names and jargon may be misspelled.