Aztec vs StarkWare

Transcript

Excuse me. All right. Hello everyone. We are about to get started. Uh to quickly introduce myself, I'm Jake. I'm one of the product marketing managers uh for Noir, and I'm very excited to start this uh debate. Our goal initially was to have a very formalized Oxford style debate. Um, but as you'll see, we'll make some slight adjustments to it. Uh, we will still begin with uh some opening statements from uh each of these lovely people. With us, we have uh Joe Andrews, one of the co-founders of Aztec, and we

have Maya Dotan, one of the product managers uh from Starkware. So, with that, I'll let you guys introduce yourselves and take some opening. Uh yeah, thanks uh for being here. I think this is our third official Noiron. Um there was a zero, so off by one error. Um for Noon. Um yeah, I'm one of the co-founders of Aztec. We've been kind of working on uh privacy tech for the last, you know, seven odd years. Um Noah's been around for kind of four years. So it's amazing to see where it's got to um and so many different people using it. I think kind of yeah my side of kind of what I'm going to be arguing for today is just around maybe some education on why privacy needs to be by default. Um and I

was kind of thinking about this this morning and there's there's three kind of main reasons um that we think of why uh you need privacy by default. Um the first one is kind of around secrets. Um, this is not going to be technical, so but like if we just do an example of of a secret, um, if I tell everyone here that I'm Joe, uh, I was born in 1991 and I'm 34, I can't take that back, right? That's that's something I've shared with you privately. Um, it's private information I've shared with you, but I I can't remake that private for this room. And public blockchains are kind of the same sort of thing. like if you have a balance on a wallet um you can't suddenly encrypt that. Uh so there's

this kind of you know uh issue that we have where secrets are no longer secret when you share them. Um and so the first kind of reason that you have to have a a system that's private by default is just yeah it's around secrets and um not being able to re-encrypt a secret. Uh so that's kind of the first reason why for Aztec and Noir everything starts as being private. The second reason um is mostly around anonymity sets. Um absolute privacy is not that useful. If I kind of came here to this debate and kind of in protest just sat here in silence uh like privacy by default, I'd probably lose and like it wouldn't be very exciting for anyone

uh in the audience. So whenever you interact with people, you have to reveal some privacy. Um sorry, you have to give up some privacy. Some people call that selective disclosure. Um but every time you do that there's like a little trace that's attached to your digital identity. um and the group of people that that trace could have come from uh is very you know if it's small then you actually you you have no privacy right if I do an example and say um I'm the only person I'm also born in England when I share that secret you can kind of look at the stage and be like it doesn't matter like that there were initially three people the person who revealed all those secrets is Joe um and so the

privacy set really matters um for when you're kind of revealing secrets. And so if you're private by default, it doesn't mean you have a large privacy set, but it's just it's optimizing to try and get the largest privacy set. If you have kind of you know app specific privacy the the privacy of kind of a single app um you know it can be linked across multiple apps and with stat with with statistical analysis you can quite easily you know normally see through it and we saw that on kind of uh Ethereum with various kind of like privacy tools and mixers like many kind of chain analysis tools could actually just link them together um and so could exchanges so it's it's not the strongest form of privacy and the third one And I think

like I think we'd all agree on is just around um what does privacy by default actually actually mean. It's not the network being private. It's that privacy has to be at the source. Um and that really means client side proving. Um so if you think about kind of WhatsApp and Telegram or well not Telegram actually that's very not private uh signal. Um when you send messages on those platforms it's encrypted at source. Um, and so the network actually like it shouldn't matter. The privacy by default comes from privacy on the client side.

Um, and so yeah, we've been working like many people here on on trying to get proof systems that work in in the browser. And that's the best way to get privacy by default. Um, kind of the three main reasons we advocate for it with Noah and Aztec. So that's yeah, my opening statement. Okay. Um, so hi, I'm Maya. I'm a PM for all things proving and privacy related at Starkware. So Starkware is a proving focused company. Uh we've been around for I think also seven maybe eight years now. Um I haven't been there all that time but uh so and the premise that Starware was founded on is that uh proving is useful

for scaling. So at first we were not very focused on the privacy aspect of things and I think that uh we have shown a very strong use case for scaling and we are the the team that m maintains tarkn net which uh is a very performant uh layer 2 zk roll up over over ethereum and the word zk here is uh kind of uh charged but but um we have recently been focusing more and more on privacy use cases and specifically client side applications. Um so our new provers 2 uh startnet 2 uh is much faster and we aim to release a very very uh fast and

usable I want to say uh client side version. We have an alpha out but it's supposed to be better by about 50x hopefully over the next year. Um and we also are going to make STO ZK. So Stark uh provers are typically not ZK by default uh as opposed to snark. So um it takes some more work but we know what we have to do to make it uh work. It's not that much work. So it's on our road map hopefully by the end of the year if not by the beginning of next next year. Um, we really at Stark want to focus on privacy apps that are usable to the end user and this I think has several

different uh things to focus on. The first one is I want to say that end users typically do not understand privacy and do not understand security and they shouldn't they it should be something that's taken care of for users and it should be by default in the sense that even if the network is not private by default which it should be probably uh but even if the network is not the applications facing the user should be and hopefully all information should be retained on client side, proven on client side. So at least when it gets to blockchain, it's anonymized to uh in the sense that beyond some statistical

analysis that's of hope hopefully obiscated by large privacy sets. Uh then not much is leaked. Privacy is you know is not well defined. There's your knowledge privacy, there's differential privacy, there's statistical privacy, there's all these senses of privacy. And of course, users shouldn't be able it should shouldn't have to differentiate between them. They should just know that people can't steal their private information. Um this the same goes for security. So people by default assume that you their money would just not get stolen. um and they don't think about the case that it that the system they're using using is not secure. This is true

both for blockchain system and for for regular systems like you know KYC and all these systems that just leak information all the time um banking data. So um and the second thing I want to say about this is that we believe strongly that most users in the world want a combination of privacy by default with compliance by default. So we are focusing very much on uh generating uh libraries for users and when I say users I mean applications uh to develop privacy by default and compliance included by default to comply with laws

that match the regulation of their choice uh easily. So because uh we we we want to bring and on board previously uh like sectors that previously have been skeptical about blockchains and we want to make that transition very smooth for them and for them not to have to worry about some uh regulatory entity somewhere in the world coming up and saying that like they're in trouble or that even like they're questioning what they're doing. We just want to like and we believe that end users care about this.

They don't really care like unless they're trying to lend money, they just want things to work and they want to never think about things that can go wrong. Yeah, I fully agree with that. I think um like in the kind of identity space like that there's a lot of kind of I guess FUD in the web two world of like what people put up with in terms of giving their ID out and there's a tension around kind of the types of proving systems we have today um and like web 2 cryptography like it's fine to kind of be like hey we can we can do a Poseidon hash or we can do this like know like a very small schnore signature and we can make it zk We kind of had that like three four years ago and we

didn't get adoption like quite frankly like to to get adoption in the real world you you have to do exactly that you have to go and meet web 2 where it is and I think the ZK passport team is maybe here later but they're verifying like RSA 4096 signatures with like a SHA 512 hash like it's so horrible like in terms of like what you need to do in a proving system and so yeah I think that users don't care about that right but you need to have an underlying tech stack that lets them do that client side and um you know on on their devices.

Otherwise, you're just offloading the same passport data to a server and you haven't really solved anything compared to taking a picture of your ID and and giving it to on Fido um to to leak it to someone in two years. So yeah, I think it's there's still problems, but um I agree with kind of like users not wanting to make the choices about their privacy. And I think yeah, that's why we go for kind of privacy by by default. I'd love to hear more about like the the kind of client side um uh stuff. Should we should we go there or do you have some questions? Yeah. Yeah. Yeah. No, we can go on the client side. I mean, it sounds like there's a lot of agreement.

Privacy is great to be able to add. Of course, we also need the option for things to exist in public. Otherwise, we're sitting silent in a room like Joe said. But Maya, did you want to say something? Yeah. So, I think client side proving is useful for privacy both in the sense like the classical sense that everybody thinks about like ZK passport, ZK applications on client side for privacy. This is a clear path for privacy, but I feel like there's also a lot of proving applications for privacy on the client side that don't have to do necessarily with the CK property, but like with approving property. So imagine like so a a huge huge huge security risk in the world today is IoT devices,

right? So and basically they manu manufactured in China. You don't know where they're sending information. They're super hackable. There's no standards that are even like remotely viable in any other context. And they control your home. They control your car. They control like your cameras. Like basically they leak all all things that you hold intimate and private. And you can just not have that happen if you use client side proofing for instance. You can have a very very simple circuit on an IoT device that just proves that it's communicating with a single IP address and it's yours. Yeah. Is this you saying that Starknet will start selling Philips Hugh smart bulbs? No. So Starknet is not developing client side

applications. Stark is a network and people are working to use both the technology which is open source and hopefully also the the network but uh the blockchain but we are very very excited to see the vision that Starket and Starkware were founded on that proving is a means to return power to the end user. I think yeah like I I actually moved into a new flat and the the old owner left like a a doorbell from some m I'd never heard of and I was like this is literally taking a picture of me every day and where's it going? So I think that's a great a great analogy. I think one one thing that um like I said noon like um how do you how do you think

about kind of like writing applications for privacy versus applications that have public state? Because one of the main reasons we kind of like had to build noir all those years ago is we were writing circuits in C++. It was impossible to debug. Zach, I don't know if he's here still, was the only one who could do it. and and um uh we basically it just became like a huge bottleneck and so Noir came out about because it was like hey if we could build this you know front-end language that you know more people could pick up and was familiar and it was kind of backend agnostic we we could get um uh more people into into the space which I think we we started to see which is great but is the kind of plan then for these like

applications to have them written in Cairo or or that's just for starknet uh itself like how how do you think about how you would like actually execute on this because I know we've got like a no verifier for starknet is that orthogonal or yeah how do you think about that so okay there's a few questions entangled there so uh cairo is the language that starknet is built on uh the the the chain of events is we have a prover we had the stone prover the startnet one prover on top of that we had the the chairovm which compiles to cairo machine code chasm and that is super easy to prove. So, and Cairo is a high level language that's designed to compile down

to kasm code. So um so the entire flow is that a user can write in high level uh hopefully rustlike syntax and it compiles automatically and you don't even have to think about it and you get code that's provable and it's proven and everything works and this works perfect for starknet uh because smart contracts it's also a smart contract language and with Sierra you also have completeness which is super important in the blockchain context. Um so kind of the entire flow for having a provable blockchain and blockchain language works really good with Cairo. Um however at the first iteration with stone um things

were not good enough to prove things on the client side even small programs it was very very difficult to use stone. Um and when we approach uh the next iteration of proving on our end with stew uh the new prover [Music] so starknet will to to remain consistent and backwards compatible everything will remain in Cairo but we'll release a client side variant of Cairo which the name is not final the Kakarot team is also working on this with us currently the name is Kairo M for M31 um or in Menfield uh it will be a Cairo like language. It will have very similar

syntax to Cairo zero. It will compile to a new Cairo virtual machine which is much lighter with entirely new errors. So now we have errors for two Cairo the big Cairo for startnet. So Starknet has proven this too. Uh but we'll have new errors that are already written uh for the small variant of Cairo and that will be super fast for client applications and the hope is to put a verifier for this language on top of startnet. So people will be able to just write code in in this k cairo variant uh prove their applications client side uh hopefully by that time to will also be zk and then you can just have the onchain part if you want onchain part to

your program h in cairo on the big cairo on starknet and everything works. Additionally, as you said, you can already today write noir code, autocompile a Cairo smart contract and verifier for your noir program and just deploy it on startnet as a smart contract and you can basically just prove a new and verify onchain in startnet super cheap. Um, and we're very happy with this. The the SDK is called Gaga if anyone look wants to take a look at this. And um we're very happy about this both because we really like no it's a nice language and people really like it and we like having the option to use tarks snarks on starknet

um both for the diversity of technology the centralization of ideas and all of this and uh both because we don't want to block users that want to use a different technology from using start um yeah yeah I mean I think like the the point I like if go back to privacy by default. Um, so the way that like Noir works for for those who don't know is that like you have to declare something as public even within the program. And so privacy by default means that like a default noir program like doesn't reveal any information. Um, which is a very different programming model to like the Cairo programming model. Um, and so like how how like is that not a better way to do things and have Noir be proven a back

end to Noir be Stow versus like having another language? Like because it depends what you're trying to do, right? If you're just doing public client side proving, maybe you can do that in any language. Um, but if you if you're trying to hide or disclose secrets, um, like aren't the patterns that like the noir community's been building like the better way to do that? like how do you think about that? I don't know about it's hard to say what's better or worse, but I think clearly there is a demand for noir technology and clearly there's tooling and people want to use it and and it's privacy by default and it works and like we're we're not going to stand in the

way of people who want to adopt a technology that works for them. Um we plan on making two for client side zero knowledge. Um so you then would have also privacy by default. I want to say that when people say privacy by default, you still have to be smart about what you're doing. Like you can leak privacy and everything if everything is sec. It's very easy to leak privacy. So So privacy by default is kind of a scary thing for me. But um yeah, like I don't think anything can be worse by having more options out there.

That's fair. Yeah. Any more questions? Yeah. Um I mean so one more question uh would be when you guys are approaching my uh client side proving what does it actually mean to take the starknet chain and add on this additional piece of client side proving and how does that piece of client side proofing enable privacy? I know it's generally used to uh enable scale uh but Aztec and Starknet both approach the the world of proving from the client side like both require that. So I guess I'm just

curious like what does it mean to take this piece and say I'm going to send all this data or I'm going to let the user handle their own data generate their own proofs and then what is the actual flow for selecting I would now like this to be private or I'd like this to be public. Um okay so again the several components I think to this question. So the flow that we have in mind is that uh you will be able to prove whether you care about privacy or not. You'll be able to run your program locally and you run the prover locally and then you have a proof that you run your program. The proof because to ZK will abstract away uh your inputs. Um I don't know to say whether we'll have

public and private inputs like we haven't had this design talk yet but the the users will be able to abstract away any inputs. Um and I would be doing this as a user of an application not as like a application on behalf of a user necessarily. I can't hear uh would I be doing this uh as a user myself like I want to go and use some D5 protocol. This is an application. M no in my view a user should never have to think about what is private like end users like are like typically end users cannot comprehend the notion of maintaining privacy like and it's not because of lack of intelligence. It's just it the world

that we live in today, people do not think about privacy and they assume that they have it. And if you change their the like the the groundwork like that is under what they use, they they don't know about it. Like so you you can't just assume there will be like oh now it's on on the blockchain so now I have to think about which inputs are private like clearly no the application developer will have to take care of this and hopefully there'll be also regulatory guidelines to what you have to do and Joe is Aztec opposed to this no not at all I I think like the way I think about it is like a user can't be it's not that users don't understand it's that the the enemy is like a

statistical AI AI like machine learning algorithm that is just going to be able to aggregate your data in a way you can't comprehend. And so privacy is not something you lose like in one action. You leak it slowly over time like every cookie thing that you click, every tiny transaction. And it's like each one of them is not necessarily bad because you don't know the effect until 2 years later when someone's like you're Joe. This is your search history. These are all the things you like. it's it's the profile that becomes bad and so users don't know at the kind of point of a leakage like what they're losing and so I think yeah we we agree and like the the whole point of kind of like Aztec is

is you give developers the tooling to build apps that hopefully abstract that from the user users still have to prove it client side but they they're just pressing send transaction and like you're trying to make that send transaction flow as amazing UX as possible and you know that means it has to run in client side devices and iPhones, Androids, and it should be as fast as possible. But that's really a property of the proof system, not kind of like um the language. The language is just trying to help the developer achieve their goal for their for their users.

Yeah. And what what you asked about scale, I think so client side is very useful for scale. Um we by the way we we already now have an onstarknet stone verifier and people use that for app chains and threes. Uh so for the way technically we we're thinking about doing it. So there's different levels of of complexity that you can take to to have different kinds of performance, but the easiest thing to do would just be to add a sys call to starknet, which basically invokes this M31 verifier. And so you lose some performance there, but not that much. And the proving end is still very very fast on the user side.

It it's basically recursion, right? Yeah. Uh yeah. Yeah. So like the same is the same flow on Aztec is like we use a lot of recursion like the the proving system is heavily optimized for recursion. Um mostly because uh so there's like the normal noir flow where you know you have a proof and you have public and private inputs and you decide what you reveal that all happens client side. If you want to build like a fully programmable private network with smart contracts you also have to have privacy from the individual smart contracts. So, if smart contract A can see the state of smart contract B, um then all this weird stuff can happen where like a malicious app can like emit your logs and say,

well, I've got I don't know a million a million dollars here. Um and I don't want this app to see it, but you a user doesn't know that, right? And so when when we think about it in kind of the Aztec context, um we we kind of do a similar thing like that that app chain verifier is an app smart contract and we have to do that on the client side as well. And so the proof system that um Zach and the crypto teams built is is heavily optimized for doing that recursive verification uh as quickly as possible. So you can hide um the state of one application from another one but still as a user do everything client side. And so the flows are similar but

uh like I guess a little more complicated because we're we're also trying to hide the state of contracts and and have like a contract framework to get composability. Um yeah. So true. I think with Steu hopefully we'll have to have we we could have something quite similar to what you're describing because you could have basically all of the logics of a transaction run offchain and then just verify a state for a user that can be quite complex like for trading like you can have a D5 platform that most of the logic runs on the client side then maybe some other additional proofs on the operator side then everything is settled to the the L2 and then nothing is

leaked. Uh we we do use recursion heavily also for efficiency at startware. So in sharp uh we use recursion to lower L1 costs for for users when you settle on uh on Ethereum and it will be crucial for Bitcoin as well when we settle on Bitcoin. um hopefully with Opcat, but um yeah, recursion is I think like no no proof system and no company that seriously isn't improving now can ignore recursion. Yeah, got it. Yeah, that's been really helpful so far.

Unfortunately, we're nearing the end of time, but uh would love if you guys would take maybe a minute or two each uh if there's anything you want to close on, anything you want to plug. Um yeah. Um maybe I'll use my my closing statement to to ask a question like what what's needed to um get uh a new backend for noir uh with the storover. Um so we the actually kakarot who is working with us took a look at the compilation of like the option to just like natively compile noir with stew as a back end. It seems rather straightforward from what they said. I didn't look at it personally, so I just don't want to commit to anything, but

they said it shouldn't be just too hard. Just like compile your code. Maybe there's a NRG5 and we can get a get a grant going for another back end. Um I don't know. I guess like yeah, my my conclusion is kind of I think there's a lot of um similar thoughts here like um yeah, for us privacy needs to be by default. you can't unshare a secret and client side proving is kind of uh one of the tools we have to get there. Um we're actually kind of like backend agnostic even in Aztec. We just we use Brendenburg cuz it's the fastest one that works for what we do right now. But you know longterm if someone could build a better one and it works with no we would switch. That's kind of the the the

design choice we've made. But I think we need to see see the benchmarks and um go from there. Yeah. So um I I I'll conclude by saying that we are meant to release the two benchmarks like the big Cairo two benchmarks this week hopefully next week it's at the end of the week now and uh check it out there's a client side version alpha out there uh it still operates over the big Cairo over the big field but it's still far more performant than every other stark system we and also Jolt but uh we haven't compared against Aztec so we should so were you will you benchmark against Bradenburg?

Uh yep, why not? Let's do it. That's a good conclusion. Let the numbers win. Awesome. Well, thank you guys very much. Yeah.