Anna Rose (00:00:05):
Welcome to zero knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online.

Anna Rose (00:00:27):
In this week's episode, I check in with the folks at Aztec. Aztec is a ZK based privacy, L2 project. The team has a track record of delivering some of the most important ZK research and implementations. One big highlight here would be the original Plonk paper. In this interview. I chat with Joe and Charlie from the team we talk about Aztec connect and how this relates to ZK money. We talk about how the team has evolved, what future projects they're working on, such as the DSL Noir and Aztec 3. We also talk about what stopped the recently planned launch at the very last minute, we do kind of a quick postmortem on that and what's next for the project. But before we kick off, I just wanna remind you to check out the ZK jobs board. If you're looking to work in ZK professionally, this is a great place for you to find your next gig. You can find job postings from some of the top teams working in ZK. Also, if you are a team looking to recruit, this would be a great place for you to let technical people know that you're looking to hire. I've added the link in the show notes. Now, Tanya, from the ZK podcast team will be sharing a little bit about this week's sponsor.

Tanya (00:01:31):
Today's episode is sponsored by Aleo. Aleo is a new layer, one blockchain that achieves a programmability of Ethereum privacy of Zcash and the scalability of a rollup. If you're interested in building private applications, then check out Aleo's programming language called Leo, which enables non cryptographers to harness the power of ZKPs to deploy decentralized exchanges, hidden information games, regulated stable coins, and more visit leo-lang.org to start building that's leo-lang.org. You can also participate in Aleo's incentivize Testnet three by downloading and running a Snark OS node. No signup is necessary to participate. For questions, join their discord at aleo.org/discord. So thanks again Aleo. Now here is Anna's interview with Aztec.

Anna Rose (00:02:20):
Today. I'm here in person with Joe and Charlie from Aztec. We're gonna be talking about Aztec, the trusted setup they did, ZK money and Aztec connect. Welcome to the show, both of you.

Joe (00:02:31):
Thanks for having us.

Charlie (00:02:32):
Great to be here.

Anna Rose (00:02:33):
I am very excited to hear about the latest on the project. Quick disclosure. The ZK validator is a small investor in the project as well. Joe, you've been on, this is your second time on, and I think last time we were talking primarily about ZK money. Uh we'll I'll add a link to that in the show notes, but maybe do you wanna just let people know a little bit about yourself?

Joe (00:02:55):
Yeah, so normally my role is kind of focused on product, helping take, everything that Zach and the crypto team build and Charlie and the engineering team build, making it into something that people can click on and play with. but more recently it's kind of more encompassing fundraising regulation, a lot more boring things, but, they're also very important. So yeah. Do do a lot of, different hats here at Aztec.

Anna Rose (00:03:22):
Would you say you work on product?

Joe (00:03:24):
Yeah, technically that's my, my full title. Okay. But, yeah, at the moment it's been a few other things have crept into that remit so as it is in a, in a, in a fast growing company.

Anna Rose (00:03:35):
Cool. And Charlie, this is the first time we meet. Tell me a little bit about what you do at Aztec.

Charlie (00:03:39):
Yeah, well, I'm the, lead engineer here at Aztec and I've been here about three years so far, and I've been involved in almost everything since the trusted setup, but, I define a lot of like the, tech stack that we use and the process, and I've just been very heavily, involved in engineering, Aztec 2, and, a new product that will be launching, Aztec Connect.

Anna Rose (00:04:06):
Very cool. So you just mentioned the trusted setup years ago. I did. I think now we're talking two years ago, I did a series on trusted setups and I think we had Tom who was at Aztec at the time on the show talking about ignition. That was the name, right?

Charlie (00:04:22):
Yeah. We could Aztec Ignition,

Anna Rose (00:04:24):
Aztec Ignition. And so that, that episode will link in the show notes. That was, you know, a multi interview episode. I interviewed a number of people doing trusted setups. I remember being really impressed with the Aztec Ignition ceremony and actually later doing, I, I helped Kobi do the Plumo ceremony. And like, that was one of the ones we were like really looking at as like a guide. Tell me a little bit about what it was like to build it?

Charlie (00:04:49):
it was fun to build it. it was the first thing that I was that I was actually doing, when I joined Aztec, I think our trusted setup was they're all quite different. Yeah. Like people have these different algorithms and our ours just was this process of, like doing a huge numbers of, elliptic points scaler multiplication, like a hundred million of them, I think. And, it was done sequentially by, I think over 173 people around the world. so the actual like effort of like, process of doing this eliptic curve scalar multiplication was fairly simple. So what I, that was kind of already done, I just needed to make it extremely performant, like parallelize it over many cores it was about six gigabytes of data that needed to be shifted from a participant to participant. So I built a coordination server, just a centralized thing that basically, and, and these Docker images, which meant that there was a very low, like barrier to entry to run it. It's like if you had Docker, you could just run this thing and it would connect to this server. It would put you in the queue. And like when your turn came around, it would just stream the data down, perform these, elliptic curve, scale applications and sort of stream the data back up again, ready for the next candidate to pick it up. and we visualized this all on like a pretty globe that I think is still, still visible.

Anna Rose (00:06:11):
Yeah. I remember that. was it a headache? Like, was it, I mean, this was your first project, maybe actually Joe is a, like more on the coordination side. Was it like, was it a fun activity? Was it something that brought your team together? Or would you say it was also kind of like a burden, like trusted setups kind of get, I think it kind of, you know, a bad wrap.

Joe (00:06:31):
Yeah. I think it was, it was, there's a lot of coordination between kind of, people we wanted to run it who were not members of the public, but had specific requirements. so like the, like they wanted to run it at certain times or something because they were an institution. so that was definitely a headache. I remember Tom spent a lot of time kind of coordinating that, but I think the one thing that saved us compared to some of the more recent trusted setups is you could run this very quickly. I remember Charlie, rented out an AWS machine and I think had the record of what five minutes or something for, for running the whole ceremony. Yes. So yeah, the coordination wasn't that bad, cuz we could kind of chunk the day into like hour slots and get quite a lot of people, doing this. So it was, there was a lot of kind of updates for people to see the graph evolving, see who was doing it. Whereas some of the more recent trusted setups have been like eight hour affairs and it's

Anna Rose (00:07:28):
Or longer,

Joe (00:07:29):
Very painful, cuz you're just like, oh wait, someone's still running the same thing two days later. And like, I think that did help us a little bit because a failed participant wasn't that much of an issue. Cause we had this coordination server, someone else could just jump back in. And we, we got a lot of participants, I think at the time it was after Zcash it was the largest trusted setup that had been done. and most of the, I think Plonk, implementations still use the CRS was output from that. It's now kind of a public good that anyone can use, which is I think a pretty cool legacy.

Anna Rose (00:08:02):
Cool. And that's CRS common reference string. Yes. This is the thing that sort of unlocks a SNARK. This is the thing that you need to start a system. is that the wrong way to say it?

Joe (00:08:14):
I'll take a stab and then Charlie can correct me, but I, I view it as kind of maybe

Anna Rose (00:08:20):
Unlock sounds more like you're revealing that.

Joe (00:08:23):
Yeah. I think you feed it in, in order to kind of, obscure all the gates in your program. So for each gate in your program, you need a point from the, the common reference string. and that's kind of how we use it in, in Plonk. And the assumption there is that if that point was generated in a trusted setup, then there's no other way for you to kind of back out what happened, or how, how that point was generated. So it can be used in the program to gain privacy

Anna Rose (00:08:54):
Would be like, and that was the, that was the piece that used to be called the toxic waste, right?

Charlie (00:08:59):
There's this secret number, which is basically the combination of all the randomness of all 173 participants. and that is called the toxic waste. And I think nobody knows what that is because if you assume that one participant was honest and threw away their part of the randomness, then it's impossible to know what it is. And that randomness is then used to a, as the, multiplier for these elliptic curve points. so there's, they all have this sort of same relationship to one another in terms of how they've been exponential, but you don't know by how far, and then you can use those elliptic curve points, within the, the mathematics of the, of the proving system to, to, to do the, to make a SNARK basically work.

Anna Rose (00:09:45):
I did do that episode a year ago, but I can tell like I am actually rusty, cause I have a question that I feel I probably already asked before at some point, but the common reference string, is that, is that actually secret or is that viewable?

Charlie (00:10:00):
No, it, it, it, that is, public information. Okay. And it is, a, a set of a hundred, about a hundred million elliptic curve points, on a particular elliptic curve.

Anna Rose (00:10:13):
But why like how could that be public? And yet somehow it's still securing the SNARKs privacy. Like it's keeping the SNARK like if you know that, why are you not able then to discover how the SNARK works or like undermine it,

Charlie (00:10:28):
There's this, this elliptic curve, multiplication that we do, you can take an elliptic curve point and there's a sequence of operations. So if you want to sort of, exponetiate it by 10, say you go through the sequence and you end up with a resulting elliptic curve point, but you can't back out the fact that it was exponential by 10. 10 in this case, is the toxic waste that I'm talking about. So we have all of these elliptic curve points that sort of have these relationships to one another in the way that 2, 4, 6, 8, 16 have a relationship to one another. But you just don't know by like the, what magnitude scaler value by which they've been exponentiated.

Anna Rose (00:11:08):
Oh, okay.

Charlie (00:11:08):
Because every one of the 173 participants did it by their own random number and then took, I took your result. Exponentioated it, passed it on to Joe. He took it exponentiated it, wow. By a random number. So good luck trying to figure out what the combination of all those random numbers is interesting, but the, yeah, the, that sort of relationship 2, 4, 6, 8, 16 continues to exist.

Anna Rose (00:11:31):
Cool. I feel like every time I talk about trusted setups, I get a little bit closer to understanding what's actually happening under the hood. Nice. okay. So I wanna keep going on kind of learning a bit about your role at Aztec. And so you worked on the trusted setup, but like nowadays, you know yeah. What kind of role do you take in the org?

Charlie (00:11:53):
So after the ignition ceremony, I was then, I sort of started working on, the actual circuits themselves for, for what is currently our production Aztec 2 is, is it sometimes referred to system? and yeah, I mean, I sort of, just laid the, sort of the, the foundation, the architectural foundation of that system and wrote some of the initial circuits. And then as the rest of the team became free, after moving on from our original Aztec 1, everybody else sort of started contributing and we've taken that onto the current live system as the zk.money.

Joe (00:12:32):
Yeah. I mean, I think Charlie's probably underselling himself a bit there. Charlie's really responsible for everything from, past the cryptography, as soon as that's been put into kind of a workable, cryptography, production piece of software, Charlie and, the rest of the engineering team, takes that and kind of builds it into kind of a, a usable kind of engineering piece of software. that's everything from our client SDK, which kind of acts a bit like a full node in the browser to our, our roll up software, which actually aggregates thousands of transactions together and posts them to, Ethereum. and yet as a result, post launch, we're actually moving Charlie up to CTO. he's been with us for three years now and I think his previous work has secured all of the, circuits of people are using. So we think it's a, it's a worthy title, to give him, to help bring Aztec to the next level as we scale towards kind of decentralization.

Anna Rose (00:13:33):
Very cool. I wanna talk a little bit more about the structure of Aztec. So you'd sort of mentioned this like research side and engineering side. How do they work together?

Joe (00:13:43):
I mean, we have a, we have a cryptography library called, Barretenberg, which I think is kind of the, the main interface between the two. And I think that's where engineering and crypto meet. It's probably one of the most interesting roles we're actually hiring for Aztec is people in that library because you kind of have to have a, a maths knowledge, but also, I hope the cryptography team won't mind me saying this, but sometimes cryptographers don't write the nicest code, so kind of being able to kind of, take crypto cryptography, put it into code and then make it production ready. is I think the interface and, Charlie can talk a bit more about how, how the team's structured around that.

Charlie (00:14:24):
yeah, so I think Joe's yeah, described it quite well as there's this, this interface between the cryptographers and, and the sort of the larger engineering team, which, who sort of operated a higher level. Like I, myself, for example, are not a, a cryptographer I'm sort of like trying to, learn as much as possible as they go along. And, you know, it's a slow process cause it's quite complicated, but, yeah, I mean, our cryptographers, they're largely working on, you know, proving system related things. And then I guess where we sort of meet in the middle is the circuits themselves because writing the SNARK circuits, we currently write that all in, C++, using like sort of a custom standard library, you know, our representation of a bool, our representation of an integer and normal engineers can understand those concepts.

Charlie (00:15:13):
the cryptographers kind of build these little components, these little boolean and int components, they work in the proving system. And so that normal engineers can then start building circuits. There's still some sort of nuance to, writing circuits. you need to get your head into a certain sort of way of thinking, like certain things don't exist at the moment, like easy branching logic, if statements, things like that need to be done in sort of clever ways, but it's definitely things that engineers can pick up. I mean, I picked it up and I sort of wrote the initial circuit. So it's, it's, that's kind of like the meeting point. And then of course taking that and actually turning that into a real viable functioning product that works in the real world is just a whole nother sort of leap like the theoreticals and sort of like getting something theoretically sort of working and like a little green tick in a test is like one thing, but being able to make that operate at scale, reliably and stably as a, as a whole nother thing.

Anna Rose (00:16:09):
Wow. This actually makes me a bit more curious Charlie, to your background before that, like, what were you doing that sort of led you to this role?

Charlie (00:16:16):
well, I've just always been a huge computer geek. Like I, I started programming when I was about 10 years old and I just sort of fell in love with it immediately. and yeah, you know, I sort of, I originally wanted to be a, a games developer, you know, as that sort of formative gaming time back in the nineties where games like doom and things were coming out, that industry exploded into like, you know, hundreds of thousands of people like size teams night that kind of put me off a little bit. I didn't really, I, I liked the idea of the small team creating something big. and I went through various sort of big companies, you know, I worked Toshiba, Betfair Bloomberg, and then I, I didn't like the big companies. So I moved to the startup space. I worked for a couple of small startups, and in 2016, I, I got into, into crypto like so many did, like, and sort of thought, wow, you know, the, the flavor of this is much like those sort of formative gaming is back where you've got constrained environments and you're sort of changing the world, at the same time by sort of building them and, and small teams of people can really make a difference.

Charlie (00:17:20):
And, that's when I sort of knew I wanted to get into crypto, I sort of started working on personal crypto projects, client libraries and the like, and eventually I discovered Aztec. and I'm very glad I did

Anna Rose (00:17:32):
So cool.

Joe (00:17:33):
I think we found, well, you found us in the dark depths of Reddit.

Charlie (00:17:36):
I think, I think I discovered, I discovered as I can reddit. I think I originally sent an email, got no response. I think it just got lost in the ether. Yeah. But I was not, put off and I, I tried again a few months later and yeah, it all worked out,

Anna Rose (00:17:49):
But I mean, working with Aztec is not just kind of blockchains zero knowledge, what was the connection there? Like, do you feel like it's not really just, yeah. It's not straight up crypto what's how what's, how does ZK add to that?

Charlie (00:18:04):
Well, I think the privacy aspect of what we're doing sort of sits like deep. Like with me, ideologic like personally, you know, I, I I'm big on protecting user data and privacy and things like that. I think we're in a bit of a dark time of, of users, having their data mined and, and being controlled by their data. And, I think it's really important that we, you know, we protect what we have by having, effectively private forms of cash and, and things like this. And also, I think there's just huge business gains to be had for this, for, for parts of the world that are economically developing, et cetera.

Joe (00:18:40):
I was just gonna say, I think, on privacy, like mine, and Charlie's kind of not differences, but how, how we view what can be built with Aztec most emphasized by kind of ZK money and Charlie's interpretation, which is a command line interface, which he built around our SDK. So very kind of, very kind of like hacker and, maybe taking you back to those, those doom days. but yeah, it's, I think it just shows that, that there's a lot of different flavors to kind of privacy and what can be built on the network and, a scale of privacy as well. which people will find their kind of, their level on

Anna Rose (00:19:19):
You just mentioned ZK money. And actually, I mean, I think I am very curious about like what that connection is between like ZK money and Aztech connect. So yeah. Tell, tell me, well, actually, maybe let's start with introducing ZK money.

Joe (00:19:32):
Yeah. So ZK money is our kind of example, application of what can be built on top of Aztec. we first, ship the first version of it actually for Aztec 1. it was very clunky, enabled confidential payments, and it, its goal was to show what's possible with the Aztec SDK. It got a massive kind of upgrade and revamp in, in March, 2021, which is, I think what I spoke about on, on the last episode, enabling these fully private payments, for cheaper than a normal Ethereum transaction, really showing kind of that, privacy was no longer a, a UX, burden and what we've done, kind of with the new version of ZK money, which is kind of coming out with the Aztec connect launch, as we've upgraded it, to have all the new functionality of the Aztec SDK that's been added by Aztec connect. So you can think of ZK money as kind of a showcase of what's possible to build with our SDK. now that the Aztec connect functionality has been added to it. and as a reminder of Aztec Connect, it's a kind of set of tools to enable people to, interact with layer one DeFi contracts completely privately from inside Aztec and with 10 to 30 times gas savings, for a process called DeFi batching.

Anna Rose (00:20:54):
So the rollup, I mean the ZK money is still going to be ZK money. Yeah. Aztec so, yeah, that didn't, I thought Aztec Connect was kind of taking it over Aztec Connect is the suite of tools, which actually allows you to do stuff on the kind of main chain across to the L2.

Joe (00:21:10):
Correct, yeah. So we have kind of a, a solidity contract interface, which is Aztec connect bridge interface, which enables the roll up contract to talk to any DeFi protocol. It effectively models. the DeFi protocol was a asynchronous token swap. So you take two tokens, put them in, and sometime later you get two tokens back, and you can model most of defi like that. Wow. which is kind of cool. and then we have the Aztec SDK, which enables you to construct zero knowledge proofs to interact with these, kind of contracts. So the way you do that is you have shielded funds on Aztec. And instead of sending them to another user like you could do kind of with the original SDK, you can now send them to, what's called a bridge ID. and a bridge id is kind of this encoded set of instructions, which tells the roll up contract, which layer 1 smart contract to call and with kind of what funds and if that proof is valid, it could have come from anyone inside Aztec. and it's kind of how we get privacy. And then I guess the really cool part is you can actually batch these together. So if we all do the same transaction, we can be bundled together in a giant kind of aggregated roll up proof, and we all share the gas costs. So we can kind of do the same Uniswap, transaction for a 10th for the price or a hundred for the price, depending on how many people are in the batch.

Anna Rose (00:22:35):
Does the batching in this case contribute at all to privacy?

Joe (00:22:39):
No, it's actually, just gas savings. The batching, the, the privacy set is kind of quite hard to define, but our, our best effort at the moment is, the set of depositors that a given public kind of, bridge interaction could have come from plus the set of bridge interactions, which also brought that asset in. So if you think about kind of, I'll try again, but if you think,

Anna Rose (00:23:06):
If you think about, you're making a bit of a confused face here.

Joe (00:23:09):
Yeah. If you think about Eth, as a privacy set, there's kind of deposits into the system from L1, and let's say we have a hundred of those. so in a simple system, the privacy set will be a hundred users kind of for a given asset, but with Aztec Connect, Eth can come into the system through two ways, one for a deposit. And secondly, through a bridge default bridge interaction, for Aztec connect so you could swap on Uniswap, you could kind of,

Anna Rose (00:23:36):
Oh yeah. Always. I see what you're saying. Okay. Cuz there is just the deposit swell. There's like people just using it in sort of its vanilla file.

Joe (00:23:43):
So this, this privacy set actually can grow like pretty, exponentially because there's multiple ways now for, kind of Eth to get into the system. And, we're excited about that growing,

Anna Rose (00:23:55):
Can you though go in through the DeFi way and then out in the vanilla way? Not really. Right. Doesn't the contract sort of cause both actions,

Joe (00:24:04):
you can deposit, DeFi interactions, and then exit with those funds. So it's kind of fully composable, but you can't, you have to start with funds in Aztec. So either, either via kind of a deposit, or we're working on, various on and off ramps, to kind of have other ways to get funds into Aztec from centralized exchanges.

Anna Rose (00:24:27):
Cool. Oh wow. Like potentially directly there. Yeah. The reason I was asking if the batching had anything to do with privacy was that I know, you know, I think also last year we had a, we did a, something called ZK sessions, focused on privacy and DeFi and Zach had talked about like a way to make a private dex using batching. And that was when you said that term, I thought, oh, maybe it was related, but in the like, if you're like, what you just kind of suggested is like, you're actually gonna do the DeFi in the roll up in private.

Joe (00:25:02):
So, so actually the, the, the DeFi stays public in Aztec connect.

Anna Rose (00:25:05):
Oh it does. Oh really?

Joe (00:25:06):
So if you think about, we've got all these building blocks on, on layer one, so we've got Uniswap, we've got AAVE, we've got all of these kind of, I guess battle tested, more like institutions now in DeFi that have survived a few kind of market, crashes like, like yesterday and the day before

Anna Rose (00:25:25):
They survived by the time Ms. Harris

Joe (00:25:27):
Hopefully. Yeah. All right. and what Aztec connect enables is kind of, instead of having to move those to, a new execution environment, like Aztec, we actually just keep them where they are and we move the users to Aztec, make the users private, and let them then interact with these public protocols. I think what Zach was maybe talking about previously is it's actually quite hard to make a private Uniswap because, it, it, by definition is the ratio of two public, pools. So it's actually, it's actually quite difficult. So with Aztec connect, we, we took the approach that, giving users privacy a around kind of which user was interacting with a given, protocol. And also what a user's holdings were, was sufficient privacy rather than kind of reinventing the wheel, having to move liquidity to the L2 and kind of rebuild everything from scratch on the L2.

Joe (00:26:24):
and that's definitely been one of the main selling points of, of Aztec connect. there's a lot of protocols that I call them second order protocols, but they, they're not just dependent on their own smart contracts. So something like an Element, even something like a Lido, it can't really move to a traditional L2 as a different execution environment because it relies on something else being on, on L1. So with Lido, you need the deposit contract for the beacon chain, to be able to actually use Lido. And that's not gonna move to an L2, or with element you need kind of balancer and curve and loads of other protocols to actually exist for their protocol to function. So there's this unsolved question with traditional L2s around, kind of breaking composability and liquidity fragmentation that we didn't really wanna have to try and solve. So we, we just made the users private and gave them a way to cheaply and privately access what they already loved on L1.

Anna Rose (00:27:23):
I, this makes me curious, can you use assets on ZK money as collateral in other things, do you have that use case or is that like, is there,

Joe (00:27:35):
Yeah, definitely. Okay. So, so, so all, all an asset is on Aztec and, and all ZK money is just a, like a view port to show you what assets you have on, on Aztec. but let's take a really simple case of, of Eth all ZK Ethers, which is kind of our, our name for assets inside Aztec. it's E that's owned by the Aztec roll up contract. So you send your Eth to the Aztec rollup contract on layer one, and in return you get a claim on that Eth in the form of a UTXO note, cuz Aztec works on UTXOs under the hood and you can do that for any asset. and then to, to go back to the question on, can you use that for collateral? if there's something on L1 that kind of accepts the assets you have as collateral, you can construct a zero knowledge proof that instructs the roll up contract to send it to that L1 smart contract via Aztec connect as a bridge.

Anna Rose (00:28:33):
Wow.

Joe (00:28:34):
So any bridge, any kind of like collateral as possible, to kind of deposit, and that's exactly where we're starting with Aztec connect actually as well. so kind of staking all these kind of low imediacy use cases like lending staking kind of yield use cases. we'll start with just Eth and DAI. We'll be very quickly adding in most ERC 20 tokens, and expanding kind of the, the places you can deposit assets as collateral and earn yield.

Anna Rose (00:29:02):
Wow. That's exciting. This is, I mean, do you feel like Aztec Connect is the piece that makes, I mean, it sounds like it's, it's the thing that really opens up ZK money to be much more usable than what it is right now, which is like, it, it, I mean, actually, yeah, this is a question. How do people use ZK money without it?

Joe (00:29:21):
Yes, it's a great question actually. So two ways, so you can either use it for just paying, friends, DAO contributors, just paying people privately on chain. most people do that with DAI, cuz it's dollar stable, or you can use it a bit like a mixer at the moment and withdraw your funds, back to L1. and then you have a form of privacy on L1 to go and interact with the protocol. You don't get gas savings and what Aztec Connect enables is kind of all of the things that people used to leave to go and do. They can now stay in Aztech and access them for ZK money. So it's just a much better kind of user experience. you don't have to keep track of multiple wallets on chain to work out. Hey, did I withdraw to this address previously? You just do everything from inside Aztec and you have this privacy by default.

Anna Rose (00:30:18):
Do you, I mean, I, I wonder how much can you see as the engineers building this of the activity inside since it's private, I'm almost like curious what behavior like, I guess you have, I guess you haven't seen as tech connect behavior yet, cuz it's not launched as we're recording it, but even in just kind of generally like it, it maybe in Testnet or whatever, like how much can you see into what is actually happening inside?

Joe (00:30:45):
Yeah. I can take a stab on at the on chain and then maybe Charlie can talk a bit more about, SDKs and kind of what's technically possible for people to decipher. So on-chain, because DeFi protocols that we're interacting with the public, we, can see which DeFi protocol, a given set of transactions is trying to interact with, cuz you're gonna see it on Etherscan and you can also see, the total amount, that a group of users want to send to that protocol. But what you can't see is what users on Aztec that came from what their total balance is on Aztec. but you can see kind of the public, kind of transaction that results from the correct verification of our ZK roll up, on Ethereum. So another way of thinking about it is kind of the Aztec roll up contracts like this puppet and if people like pull the strings in a certain way with, a, a zero knowledge proof, then it will make a transaction with a DeFi protocol. So if you look to Etherscan, you just see this roll up contract, interacting with various protocols instead of users interacting. so you can still see some stuff, but you can't see who, which is the, I guess, the big breakthrough

Anna Rose (00:32:07):
And what can people see under the, like in ZK money or what can you see actually as engineers or like somebody who's observing what's going on?

Charlie (00:32:16):
Well, the, the SDK, what we call the SDK runs on the front end, like, on the, on the back end we receive, these joint split proofs from every user, which is generated inside that SDK, which runs in the client's browser. and we don't see, I mean, this is the same as ZK money right now. We don't see, we don't see anything like the values that come through are encrypted. We can see an IP address sent this proof, but we don't know, the values, or, or, or who's sent that proof. Like we can't identify them within the system, the SDK, which runs in the client while that only has a view of specifically, your account nodes. It, it downloads actually all of the data that's, that's taken place. It downloads, there are these things that we currently call viewing keys. There are these encrypted pieces of information for every single node in the system, but they're, they're encrypted. And we actually at the moment have to do a brute force decryption over all of those to find out which ones, yours are belong to you. so you, you can only see what obviously you're allowed to see. Um,

Anna Rose (00:33:21):
Yeah. Can you see volume or would you calculate volume more from the bridge part? Like, do you know how much activity is happening?

Charlie (00:33:29):
Yes. Well we can see sort of transaction throughput. So, you know, we can see how many proofs were being sent. We can see, we have graphs, these pretty little graphs where we can see, oh gosh, it was a really busy few hours or a really busy day, or it's a bit quieter now, but, it is quite mysterious to have a system running in which, you know, you've got a bunch of people using it and you don't really have any insight as to actually what they're doing. It's quite different. Anything that obviously I've, I've worked on before.

Anna Rose (00:33:58):
As a user, do you, do you have the ability to create like a viewing key? Is that what they call it? Like the, the way if they wanted to show that something has happened, can they do that?

Charlie (00:34:09):
You, you can, if you wanted to reveal your, you know, you can obviously share your keys with people. I'm not sure if you'd wanna do that. But if you wanna share your privacy key with someone that can obviously, reveal your balances and your nodes that does not give people the ability to then spend them that's handled separately by something called spending keys. Okay. So you can control, you can control yeah. Who can, who can view and who can spend as two, two separate things.

Anna Rose (00:34:35):
But you call it like privacy key, not private key. It's not, you're not sharing your private key in this, are you?

Charlie (00:34:42):
so, so there's all sorts of terrible terminologies that get conflated with blah blah. When we say privacy key here, it's, it's also, you can be thought of as like, your privacy key has two aspects to it. It has both a public and private key aspect.

Joe (00:34:58):
Yeah. Yeah. It's just not used. So they're both private keys, but the, the use of the private key is, it has a different outcome. So the privacy key is purely used for encryption, and decryption of nodes. It can never spend nodes, and the spending keys can spend nodes. So we separated it. also just because, if you have multiple devices, sharing, spending keys across devices is, is really difficult with like hardware wallets, but something like a privacy key could have like slightly different security assumptions, and could be shared across multiple, kind of devices. It is a different set of trust assumptions basically. and you can also do, kind of more interesting things, like proof of transaction logs. So if you give someone your kind of privacy key, and a set of transactions, it effectively, acts as a compliance log, you can say, okay, in Aztech I only transacted with, these four individuals and I then did these 10 DeFi interactions with myself. So all the funds I have in Aztech, which total 1 Eth came from these events, which is really useful for kind of off ramping to centralized exchanges, or just doing tax returns and

Anna Rose (00:36:17):
Things like that. Yeah. So you were saying though, that you're like now opening it up to have like, you know, centralized exchanges potentially connect directly to the L2 without, I guess, going through kind of Etheredo you have the vision as well to have other L2s connect directly into Aztec?

Joe (00:36:37):
Yeah, it's definitely something that's on the roadmap, but it's, it it's a little bit further away because, what you need is kind of a version of Aztec on the L2 and then...

Anna Rose (00:36:49):
You need EVM pure, like full EVM compatibility on the L2 then.

Joe (00:36:53):
Yeah. And you need to be able to pass messages between them. So if you had kind of Aztec, running as an L2 on Ethereum and then Aztec running on another EVM compatible chain, L2, or kind of other Layer 1, if you had a very good way of pasting messages between them, you could kind of effectively represent all transfers between these two Aztec instances as like a state hash of a Merkel tree. And then on the new environment, you could kind of unwind that and say, okay, well I've destroyed funds, on the kind of economical Aztec L2 instance. Yeah. so I'm gonna be able to create funds on the new kind of Aztec Polygon, or Aztec Optimism. but it's, it's a, it's a bit of work. it

Anna Rose (00:37:42):
Also sounds like that bridge needs to, like, would you almost be sending a snark promising that like something's happened on one side to the other or is that like

Joe (00:37:50):
You, you're just sending a hash and then you kind of would kind of unpack the hash on the other side. So there'd be kind of like two, two roll ups, but it's, I'm definitely oversimplifying. And the kind of security of that messaging bridge is, there's a lot of posts by kind of Vitalik on the security of bridges. And it's just not something we're, we're thinking about, in the immediate term, because, with the current design, we can actually achieve a lot of the scaling kind of benefits of other L2s directly inside Aztec. So there hasn't been a need yet, but if, if one of these environments actually takes off, I think we would, we would strongly start to consider it.

Anna Rose (00:38:27):
There's no, like no one can deploy a smart contract within, as in, within ZK money though. Right?

Joe (00:38:35):
Not yet was it's a misconception actually. So we have programmable circuits and we've had them since we launched, Aztec 2, Charlie just had to write them so we, we have an account circuit and, and well, Charlie and the whole team had to write them. we have an account circuit in a payment circuit in the currently live system. And with Aztec Connect, we spent over a year adding two circuits, a DeFi deposit circuit and a DeFi claim circuit. So these are kind of programs that the Aztec team has written. We've had to kind of use the whole cryptography team to audit these it's, it's a lot of work to kind of write these programs. but we do have programability, we are working though on a way to kind of have general purpose programability where you don't have to be kind of working for Aztec to, write

Joe (00:39:27):
circuits in Aztec. And that's where kind of Noir fits into the puzzle, the, the language. So yeah, we have this, open source project Noir, which is led by Kev. and it's, it's a DSL for, for SNARKs, specifically, Plonk based SNARKs. and it enables you to kind of very easily write, SNARK programs without having to be a cryptographer. And that's kind of what Noir does internally. We also have a project called Aztec three, which kind of enables the roll up to consume Noir circuits. So we kind of, it's like the missing piece to have like a fully programmable, private, smart contract platform running on, on Ethereum as an L2.

Anna Rose (00:40:10):
Cool. When you say like, I, I sort of wanna tease that out of like what you can actually build it, it almost sounds like you're like hard coding or like it's not a platform to just deploy contracts. So when you talk about a smart contract, I'm assuming you're like, you're actually touching the, the actual construction of this roll up.

Joe (00:40:32):
Yeah. I mean, I think at a high level, the current state of things is all the programs that we write or circuit. So we write act on shared state. So that's the main complication is there's one Merkle tree, which has all the data in it. And any program that we deploy into our roll up can modify that state. Okay. So we have to be very, very careful about kind of, what those programs do because they, they could inadvertently, if there's a bug, you could think you are spending funds, but you could delete someone's account or like you could do some pretty serious stuff. So, so we can't open that up to the public, at the moment. So what Noir basically enables is, it wraps those programs in a virtual machine, which kind of enforces some smart contract like semantics. So state variables have owners, you can't destroy state unless you own it, or you have permission to destroy it and you can call other contracts within the system, much like you can on Ethereum. So that's kind of what Aztec 3 and Noir kind of enables, which is missing from the current system.

Anna Rose (00:41:40):
I see. What would it mean for someone to use this? Like when you talk about a, I'm trying to sort of picture an engineer coming based, maybe you can just tell me, like, what could they design, what would they design and how would they actually interact?

Joe (00:41:55):
I think the, the place to start is if, if you imagine Aztec Connect as these programs we've written, we've tried to make a generic interface for all of DeFi. And we think it probably captures 80 to 90% of protocols, but there's probably some protocols where it doesn't, sufficiently kind of capture the needs. so the, the first sort of use case would be just modifying Aztec connect, but doing it in a kind of maybe adding three, asset types in instead of two or adding kind of NFTs or some, some kind of different mechanic by modifying kind of our existing programs. and then from there, you kind of start to think about kind of more interesting use cases like coding up a DAO where, the voting mechanics are private or, the rules that govern the DAO are actually written in an Aztec contract and a hidden, or kind of moving all the way up to kind of ZK games, which is, a bit further in the future, but something that we're super excited, to kind of work on once it's ready.

Anna Rose (00:42:56):
How do you interface with Noir. Is it part of Aztecs company that's doing it?

Charlie (00:43:01):
Yeah. We have a, we have a, small crack team of, compiler experts that are currently working specifically on Noir still, it's still sort of in development, the syntax is still being figured out. It's very, rust, like in, in, in its sort of its syntax that there's a specific team working on that. And then, you know, obviously the, the Aztec three team, which has to write all the supporting smart contracts to enable, that full programability, they they're a slightly separate team. Mm. but yeah, that's currently how they're interfacing, but they're still sort of in their research and early prototyping phases.

Anna Rose (00:43:34):
Cool. How does Noir compare to things like Leo or snarky JS like these there's other basically ZK languages. We've done a few sessions actually at ZK hack and ZK sessions where we talked, we had Alex Osdimir do a survey of these different languages. Where does Noir fit in?

Joe (00:43:54):
I guess the reason we, we set out to build kind of a new one when there was already so many is, at the time there wasn't a Plonk specific, kind of DSL, and that's really what Noir is kind of designed to, to enable, some of their kind of, circle and artworks now support Plonk based, kind of, approving systems. but they kind of were originally written for kind of multiple different proving systems and, Noir can support multiple ones, but it's specifically designed for kind of the optimizations around, plan based proving systems. So that's kind of why it exists and we kind of wanted to make it a much, higher level language than some of the existing, SNARK based languages. something like a Circom, doesn't really have like a standard library. You have to kind of implement everything from scratch and really be a cryptographer.

Joe (00:44:52):
So if you want to be doing like a Merkle proof or a range constraint, you'd probably have to write that or maybe use, use one that someone else has written, but it's not supported in the language itself. something like Noir exposes kind of all of Aztecs standard library, through, its programs. So you get kind of the benefit of the Aztec cryptography team. If you are just a small kind of, two person startup building something in Noir, you can rely on kind of our cryptography, and really not have to worry about being a cryptographer, just work on program features and, and what you want to build.

Anna Rose (00:45:29):
How do you think the different languages play out down the line? Will there be will there be ways for these languages to sort of interact with each other? And maybe this is not, that's not like the problem you need to solve, but like, could that happen?

Joe (00:45:43):
I think technically, I mean, I'm a little bit outta my depth here. I mean, I know that one thing that we are working on, with Noir is, enabling kind of you to take a Noir program and compile it to different, kind of backends as we call it. and we have like an intermediate representation, in between kind of the front end of the language, like what you see when you're a developer writing the program, and actually the proving system. So I think kind of, if you can compile down to the same intermediate representation, there'll be a way for you to kind of potentially use different languages in different, settings. but these are all quite experimental at the moment so

Charlie (00:46:29):
It would require a lot of standardization, yeah. From various teams to agree on like what, what you agree to and what you settle on. But

Anna Rose (00:46:38):
I do wanna talk a little bit about Plonk. I mean, Plonk was a creation of the Aztec folks. It was, it was Zach and Ariel. Was there any other authors on the original?

Joe (00:46:48):
Yes. we had, Oana as well who, worked on some of the security proofs, I believe. Cool.

Anna Rose (00:46:54):
I mean, Plonk has been an incredibly powerful concept. I feel like in the ZK space, tell me a little bit about like, yeah. How much more development has happened internally. Like, what is the roadmap for Plonk? I know there's other teams who've also been running with it. Like, how do you kind of interact with that whole thing? And I know neither of you are necessarily the folks that do this directly, but yeah. If you can just speak on behalf of the team.

Joe (00:47:17):
Yeah. I, I think what both mine and Charlie's take here is, is around what, what a different proving system enables. so our current system, is still being, written in turbo Plonk, which is probably two and a half years old. Now I think the, the paper, and we think about it in terms of, how many gates does it kind of take to prove or write a program that, that does kind of a ZK money or aztech connect transaction, and how long does it take to prove that because that's what the end user sees and that's kind of, that's where we work in. It's kind of like, am I waiting 30 seconds or 10 seconds to do a transaction when I generate this actual proof? so at the moment we're still using turbo Plonk, transactions on the client take around 10 seconds and our kind of largest rollups take about seven minutes. we are upgrading to ultra Plonk, in, in summer.

Anna Rose (00:48:17):
I love these names. I mean, turbo plonk.

Charlie (00:48:20):
Correct me if I'm right. if I'm wrong, but like Turbo Plonk made range constraints, particularly cheap. Yes. So if you, if you consider approving time is directly proportional to the number of gates in your circuit, like in Plonk to do a range constraint requires I, is this number, for example, between these two values, required a huge number of gates, Turbo Plonk, reduce that down to just like a handful of gates for a range constraint, thus it reduced approving time and ultra Plonk, makes sort of a similar leap for, for, for certain things like complicated bit wise operations. We can do use many, many less gates to do like right shifts and ends and things like that, like bit wise ands, which makes certain algorithms that exist in the real world, such as SHA256 cheaper. it will enable things like, uh, signatures to be done, like, on curves that are not sort of native SNARK curves. And it's sort of opens up a world of opportunities there because you can do them so much faster.

Anna Rose (00:49:20):
You called it ultra Plonk, but you, I think I had heard Octo Plonk, but that isn't what you said. Was it?

Joe (00:49:26):
Octo Plonk, I think was shelved in favor of a, a slightly better name.

Charlie (00:49:31):
I like Octo.

Joe (00:49:32):
Okta. So, so, so go through the fullest. I think we have standard Plonk, Turbo Plonk, and Ultra Plonk, which ultra the ones, which are kind of immediately being deployed. And then the cryptography team to support, Aztec 3 is working on, something which has been called Mega Plonk, Octo Plonk, but I think is now called Honk! No, so, that is the, kind of the, the, that's the latest of the cutting cutting edge, but, we haven't published, that yet, but it's kind of a work in progress that supports kind of a further increase in, or reduction improving time needed for Aztec 3. because you have kind of these, much more complicated programs you need to run, with Aztec 3 and Noir.

Charlie (00:50:16):
I should add that Honk! has an exclamation market.

Joe (00:50:19):
Yes.

Anna Rose (00:50:19):
Oh my God. That's amazing. But you're so just a question. I had Mary Maller on the show just recently talking about like a lot of the work that she's been doing, and one of them was on lookup tables. Does, does one of those incorporate lookup tables? Does Turbo Plonk do it?

Charlie (00:50:37):
Ultra Plonk has, has lookup tables. Yes. Okay, cool. that is what enables these efficient bit wise operations.

Anna Rose (00:50:45):
Got it. If anyone's curious, I can link to the Mary episode where we explain a little bit deeper what a lookup table is. there's also a part of your stack that we found called Falafel, what is Falafel?

Charlie (00:51:00):
yeah, we have a lot of food related names. Names, Falafel. I think, I dunno who started it. It definitely wasn't me, although I did start them at the middle Eastern trend in some of our services and, like Falafel is the, is the name of what many teams probably called their sequencer or their coordinator. It, it is, it's just the server that we run that the browser like sends proofs to, and it sends you data effectively. It's just like a, sort of an internal code name, but yeah,

Anna Rose (00:51:30):
Actually let's talk a little bit about the rollup builds. You mentioned a sequencer, is there, is there a plan to have sort of a decentralized sequencer community at some point? This is sort of, I'm gonna just for the listener, the rollups have sometimes different names, there's committees, sequencers, there's agents there's and like almost every system that bridges between two networks will have names for the thing that does it in your, in your case, it's sequencer

Charlie (00:51:59):
Falafel

Anna Rose (00:52:01):
In your case, it's Falafel, is, is this, is this the agent that also is making a SNARK?

Charlie (00:52:08):
it's coordinating the creation of the SNARK. We actually have, another service that runs behind Falafel called Halumi, and that has

Anna Rose (00:52:15):
Produces

Charlie (00:52:16):
That actually

Anna Rose (00:52:17):
It's the sandwich. Okay.

Charlie (00:52:19):
Amazing. That actually produces the, the, the SNARK itself. That is a service that specifically runs this, highly optimized C++ code cuz. And it runs on huge, great big, machines in AWS at the moment. and that generates the SNARK itself. And, Falafel just asks Halumi to produce that proof and it kind of collects these things together and then it publishes them to mainnet. So you can actually have many, many Halumis, but you can only have one Falafel.

Anna Rose (00:52:45):
Oh, okay. So what many

Charlie (00:52:47):
I, but I would say at the moment, I mean, you specifically asked about decentralization. Of course we want to, as time goes on, we want to decentralize, so there would be many Falafels as well.

Anna Rose (00:52:57):
Very cool. How, how, like who going the Halumi, the, the ones that are making the SNARKs, who are they? Like, what are they team members right now? Like who's the STARK creators?

Charlie (00:53:09):
Well, that's just a piece of software that is running, like in AWS. and it takes, takes quite a huge amount of compute power to produce these things. So it's, it's a large paralleled, uh, system, that basically they, they, they just do jobs. Like there's a whole bunch of jobs that need doing and they pick them up and those jobs are producing proofs.

Anna Rose (00:53:32):
Okay, cool. Hmm. But like anyone could do it, like,

Charlie (00:53:37):
they, they are part of a system as a whole, and in theory, down the line, anyone can run the system as a whole. So it wouldn't be like an, an individual will run a Halumi. You would run Falafel and Halumi together. But really like as time goes on, we want to actually move out of the data center as well. Like, much, much longer term we want, we don't want you to have to be running an expensive machine in a data center. That's not very decentralized either. So ultimately, like some of these services will probably condense down into single little things that people can hopefully run on commodity hardware. Cool. But we are, we are looking like many years down the line for that. I think.

Anna Rose (00:54:14):
What do you think needs to happen kind of in the SNARK world for that? Is, is it the snark that is the constraint here for it being able to run in a small, on a, on a device?

Charlie (00:54:24):
It's it will require, next generation proving systems. Okay. Which has been alluded to we're working on, and just a very large engineering effort, I think.

Anna Rose (00:54:34):
Okay.

Joe (00:54:34):
Yeah. I think it's technically possible today. it's just a lot of engineering and, you would have a, a throughput reduction as, as a result. So our kind of, it's the same kind of SNARKs that we run in the browser, so they already run on commodity hardware. but the gates in the browser, to kind of prove like the inner tiny SNARK is about 65,000 gates. And I think, the largest roll up, what is it close to? 32 million gates.

Charlie (00:55:04):
Yes. 32 million.

Joe (00:55:05):
Yeah. So it's, it's kind of, it's a lot more complicated when you are aggregating lots of transactions together. you could do a smaller roll up and maybe get it to run on, on a macbook pro right now like a two by two rollup. but it's kind of, you would have a throughput sacrifice. So, I think over the next, year or two with some kind of optimizations on the cryptography, and a large engineering effort, it's all feasible. It's just kind of us charting our path towards progressive decentralization. and for now it makes more sense for us to kind of be a bit more centralized so we can update things more quickly.

Anna Rose (00:55:44):
Cool. But going back to that that question about decentralizing, Falafel, Halumi, creating this, this landscape, how, how do you do it? What's the, and maybe what's the timeline?

Joe (00:55:55):
Yeah, I think the, the current plan is, something we call a federated prover and it's a, a model. I think that Mina have pioneered actually. so you have kind of, two roles. Like we have already, a coordinator, which we call Falafel, which basically picks which transactions go in a block. and then you have, a set of workers. Currently, those are all controlled by us on AWS. and we call them Halumi. but those could be decentralized, and you can decentralize both parts. So our timeline to kind of, working towards that end goal, actually looks a bit different though. We, we would take the current system, which is, one entity running Falafel and Halumi and get a few other people to actually run the system as is. So we'd have some kind of, trusted investors, kind of more large institutions to kind of run clones of the current system to give redundancy.

Joe (00:56:54):
And then that gives like a level of decentralization and in the background then would work on, kind of improving, the engineering tech stack, to have a transaction pool, which is missing from the current system. at the moment you have to send, you have to pick your Falafel effectively, you, you don't kind of, have a, a network, like Ethereum does and have like a, a transaction pool. So once we've built a transaction pool, it will enable kind of coordination of these, rollout providers a bit more easily. and that's where kind of token economics can come in, and for decentralization can occur. And I think we're, we're actively starting to work on that over the next year. we don't have a date yet because, putting dates as bad as we we've seen recently with our, our launch. But, it's definitely something that the, the team is, starting to work on post a tech connect. and it's a priority, for the company because we just believe that a fully decentralized privacy network is, is very important. It needs to be censorship resistant.

Anna Rose (00:58:01):
Got it. You just mentioned the launch. I know we wanna talk about that. So we're recording this mid-June there was a launch plan for last week and it kind of, it sounds almost like at sort of the very last minute, there was like a decision not to go ahead, tell us what happened.

Joe (00:58:20):
Yeah. So, I won't go into, we have a public Twitter thread on, I guess the full post mortem. but I think the, the things that went wrong, we kind of ran out of, road for testing, very large rollups on main net. we've done a lot of testing on kind of forked blockchains and the, the Ethereum test nets, and we'd expected those to behave like mainnet, cuz cuz there're testnet. and, and in some cases they're, they're a copy. they actually didn't end up, behaving as anticipated. So what happened on, on launch day? everything had been deployed. We were sending rollups, for and Halumi were working kind of as intended. and we had a final kind of load test that we were, kind of planning on just running to Sanity check that we could construct the largest rollup that we could currently create, which is 896 transactions in a batch. And, when we constructed that, rollup and tried to send it out to the Ethereum mainnet, it wasn't mined, by any of the nodes,

Charlie (00:59:34):
for any of the geth nodes yeah. Would not propagate it because there's this upper limit on the size of the transaction that you can actually send to the network, which is a, I think it's 128 kilobytes.

Joe (00:59:45):
So this is a, it's a valid Ethereum transaction. the, the largest kind of Ethereum transaction by gas limit is close to a megabyte, but certain, client, Ethereum client software, imposes limits on the transaction pool, to help transaction propagation. And, we anticipated that not being an issue, but it, it ended up being an issue. so we decided to delay the launch whilst we worked on a few different solutions. the easiest one is just constraining, the kind of,

Anna Rose (01:00:21):
batch size,

Joe (01:00:22):
I guess, right? The batch size. it only is really an issue for deposits into Aztec, would have to constrain it from around 896 to around 400 transactions, which it does increase costs for users. But, it's actually not too much because you are only amortizing the verification cost of the SNARK. and you've already amortized it by several orders of magnitude at 400 transactions compared to the current system. So it's, it's not too big a deal. and the other kind of option we've been, trying is flash bots. you can actually send large transactions directly to flash bots bypass the Ethereum transaction pool, and kind of get these large transactions, mine by going directly to the miner and you get the added perk that you kind of get MEV protection by doing that. So it's something we're, we're considering as well.

Anna Rose (01:01:16):
Oh, interesting. Tell me a little bit about, about the moment though, when you decided not to do it. Like, were you guys together here? Yeah, we were here, right? Like, cause when you launch updates and upgrades, like it's kind of like a, it's a group effort.

Charlie (01:01:28):
Yeah. I think that basically we had, we, we were obviously fully intending on, testing this on mainnet, but like before launch, but it just so happens that that testing on mainnet came down to like several hours before launch just because we had got delayed for various other reasons during this, during this launch period. so we were just, yeah, we, we had obviously got everything out on mainnet and we, we had, we were together trying to, well together, we worked slightly remote, but we were all communicating very closely generating these deposit proofs that we anticipated could be a problem. Like we, we did, we did anticipate there could be an issue here. We needed to see that this rollup would propagate throughout the network. and it just came down to the line and went when, when it was published. and it didn't go out, as anticipated rather than just continuing to try and like force things through. We just said, we need to take a step back and we need to like, get this working stable before we, set another launch date

Anna Rose (01:02:27):
In a way it sounds kind of lucky. Like I'm glad that you were able to sort of stop it before

Charlie (01:02:33):
Exactly going out can say it went well actually, because you don't want that to that to happen after launch. Right. For sure. Yeah. So our testing did work. It's just unfortunate that it was just so close to the line, but yeah,

Anna Rose (01:02:46):
There, but I'm like when I saw that it wasn't happening, I also was kind of like, I think it's timing wise like much, much better to, to have caught it and to be able to like explore it and not be struggling. I think there's been other examples of networks launching maybe a little bit ahead of when they should have not so much rollups but other things. And it's a lot harder I think, to walk it back once it's out. So I think it's really good that you caught it. What's the next stage then? Like what comes next after that? I mean, I'm sure the launch I'm sure is still planned, but I guess there's going to be, you're evaluating these different options, but in the meantime, are you also then running extra tests?

Charlie (01:03:26):
like, yeah, we have the various teams, a cryptography team engineering team, frontend team. and we've effectively reset this, process whereby we all want a green light before we set like another launch date. so whereas previously we had sort of, greenlighted various things on the assumption that certain things were gonna go well, we've, we're being more strict this time around. so, once we have those green lights from the various teams, then you'll hear more about another launch date.

Anna Rose (01:03:53):
I also wonder, I don't know if this even factors into your decision, but like right now markets are looking really rough. People are kind of like sad and things are kind of unwinding. Like, is it a strange time to launch? Would it be a strange time to launch right now? Like, would it be better? Would it actually affect it at all?

Joe (01:04:11):
I don't think it would affect, the launch. One thing we have considered as part of kind of the, the postmortem though is, kind of with DeFi there's kind of a new type of like denial of service that can happen in adverse market conditions. So yeah, if this were to happen and we kind of had launched and we couldn't suddenly produce rollup blocks, with the launch kind of DeFi bridges. It wouldn't really be an issue because they're not borrowing based bridges, but a lot of the market, kind of drama at the moment is around kind of under collateralized or heavily leveraged kind of, debt positions. and Aztec connect does eventually support debt positions. so I think one thing we're just we're sanity checking is kind of are those kind of good launch bridges. And like when should we put those in place, to ensure that users can always exit from the, the system, and they don't get kind of timed out in kind of highly volatile market periods.

Anna Rose (01:05:19):
So are there other kind of, I don't know, updates or research, anything that folks should look out for kind of in the Aztec world?

Joe (01:05:26):
Yeah. We have an update planned, at some point in, in Q3, Q4, where there's a few things we, we are looking to achieve. the main one is upgrading to ultra Plonk, which enables Ethereum signatures. so currently you have to sign, using a Grumpkin private key, which is, something, a name of the elliptic curve we use,

Anna Rose (01:05:51):
Grumpkin?

Joe (01:05:52):
Yeah.

Anna Rose (01:05:52):
Is it, where does that come? Is that a name?

Joe (01:05:56):
it's like Grumpkin and the, hunting of the SNARK isn't it?

Charlie (01:05:58):
I think was it, was it, not Lord of the rings? Was it, what was that?

Anna Rose (01:06:03):
Alice in wonderland? No.

Charlie (01:06:05):
Game of Thrones was it, they were, they were Grumpkins and there were SNARKs and it was Grumpkins without a P, but they were called Grumpkin because, I think Zach named it Grumpkin and he didn't realize the P shouldn't be there, but it stuck. So now we have Grumpkins.

Joe (01:06:21):
Okay. But yeah, obviously we're upgrading to enable you to have better security basically in Aztec. So you can sign with your traditional Ethereum wallet and around the same time where we're planning on seeing if we can move some data, off chain and it's linked to kind of large transactions actually. and what went wrong with launch, Aztec rollups are quite large. and there's a few kind of parts to that. There's the actual proof, which is tiny. and then there's, on chain data, which is the leaves of the Merkle tree. and we believe that should kind of always stay on chain for the foreseeable future. And unless something like EIP 4844 block transactions comes along. but then it is kind of what we term off chain data, which is viewing keys and stuff where security assumptions are slightly different. it's not a system liveness issue. if you don't have this data, it's more a user can't access their specific funds. so it's still quite serious, but the system can keep functioning. So we are looking at ways of, moving that data to kind of other data availability, layers, around the time of Ultra Plonk. but so it's stay tuned for more on that, cause it has some pretty significant gas cost savings for users.

Anna Rose (01:07:49):
Cool. Well, thanks so much for coming on the show and sharing with us an update about Aztec, ZK, money, Aztec Connect, giving us a little recap on a almost launch and what we can expect soon. but yeah, thanks so much.

Charlie (01:08:05):
Thanks for having me.

Joe (01:08:06):
Yeah. Thanks a lot for having us.

Anna Rose (01:08:07):
I wanna say a big thank you to the podcast producer, Tanya podcast, editor, Henrik, Chris on research and to our listeners. Thanks for listening.