Programmable Privacy on Aztec

Aztec Network Talks · September 2025 · 7:34

Noir product manager Savio Sou explains why Aztec built its own custom zero-knowledge domain-specific language and what that enables for builders. He defines programmable privacy, argues privacy must be built in from the start, contrasts the Noir approach with zkVMs, and lists the advantages in performance, composability and developer control.

Speakers

Topics

From Aztec Network Talks, hosted by Aztec Network.

Transcript

[Music] To make privacy programmable, we first have to dial back and kind of understand what do we mean by programmable and not programmable to begin with. What we have traditionally in terms of privacy is what we have pretty siloed and appsp specific privacy to begin with. Think about like encryption and for example your signal messaging app. Yes, things are encrypted but it's very siloed into a specific application that is messaging. If we think about programmable privacy then it's kind of a leap from the app siloed or or the

application specific encryption or application specific privacy that we have and into a stage where we can now do generalpurpose privacy over general purpose um use cases. To begin with the analogy or the at the analogy that I usually go by is think about the old ages of like electronics where yes we can do very fun things. For example, if you want to do a speaker uh we can kind of craft a electronic piece to do well music attenuation or or um music production and getting sound out there with that specific electronic board. But then we kind of evolved from that

electronic stage into the computing stage now where we basically have computers to do general purpose computing over anything including like music production and music stuff as well as all the other things like maybe even controlling your lights controlling well cameras even that we're shooting with. The analogy there then becomes like the wiring or the electronic circuits that we previously had were kind of similar to the encryptions or the eps siloed privacy that we had before with hashing with encryption and now we have computers we have serial knowledge proofs we have FHE we have MPC these are kind of the primitives that en enables us to do general purpose privacy and

that makes privacy programmable for developers hearing about noir the first time. There's surprisingly little that they need to actually know before they can actually code their first line of noir. For me myself, um when I joined the team, I haven't even properly coded for example rust or anything rustl like before yet. It was super easy for me to onboard onto that entire process. The key thing I would say for developers to know would be how kind of zero knowledge proofs work from a high level and how privacy is achieved um at a high level.

By high level I mean there's the basic concept of in zero knowledge proofs that there is the prover and then there's the verifier. These are usually different persons, different entities, different stakeholders to begin with. And when we talk about zero knowledge proofs for privacy, it's usually the provering things to the verifier without revealing for example any or not revealing any or most or the chosen part of the inputs towards what they are proving. And that kind of withhold from revealing is what is how privacy is achieved throughout that process. And basically understanding like the two entities of

provers and verifiers is all they need to know before starting diving into more about noir before playing with noir to begin with. What makes Noir or CKD DSL fundamentally different to CKVMs when it comes to privacy largely boils down to well the fundamental differences between a CKDSL and a CKVM. For noir or CKDSLs, what you're actually doing is basically you code your program, you code your logic at a high level. It then compiles down to well circuits or constraints that proving backends prove with there's

very minimal basically overhead during in that process from your high level code to well the low-level constraints that proving systems um kind of interpret and use in a CKVM approach you are coding your program or your logic in a highle language like Rust like Python whatever the language the ZKVM supports It then actually goes through first the CKVM itself. The CKVM itself is a CK program that is written well according to the CPU architecture or the specific computing architecture that it targets.

So your program or your logic that you coded with is an input to that CKVM and that CKVM then generates a proof or compiles down to further circuits and generates a proof of your program itself. A proof of your execution of the program itself. And so the main difference you can kind of see in this two architecture is that there is always the CKVM program in between what you are trying to do and what it actually gets proved by the proving system where it is basically non-existent in the DSL approach or the noir approach in this case. With that in mind, when we think about how do we do privacy in CK,

privacy in CK always requires client side proving to be achieved by itself. Going back to the prover via kind of separation, the prover would be generating a proof of something they know of something they always have the knowledge of. And for that knowledge to not get leaked for example to the vervia or to the public world then the prover needs to basically do the proving on its own machine on its laptop on its mobile phone etc. And that prover is usually well the users to begin with. So that's you that's me um that are generating our CK proofs on our devices to interact with the app that we want to interact with. Given the

unfortunate constraints or the computing constraints that we usually have on let's say our laptops or even on our mobile phones or maybe we are the lucky ones. There are people that are using perhaps very hardware limited phones, very old models of phones even that might not have a well good computing hardware to begin with. performance is basically an equal sign to UX in that case when it comes to CK apps. With that in mind, then the the very minimal and lean approach of noir gives you kind of the best performance out of the box to generate zero knowledge proofs to begin with and that means exponentially better basically privacy user experience when

it comes to privacy apps. That's something that the CKVM approach could eventually do, but also fundamentally there's always the layer of kind of overhead in between what you want to achieve versus what it actually achieves. And that's today in the foreseeable future is just making things a lot worse when it comes to privacy apps with seeking.