Yulia Khalniyazova of Anoma @ ZK Hack Meetup in Berlin, 24 Apr 2025

Transcript

[Music] Thank you. Uh my name is Helia. I work on ADMA. I'm going to tell you about heaven. Uh this is the most important part you need to remember. It's going to be about heaven. Um it's going to be very high level. So like not zk level like not pre-ompile level and no arithmetic operations but we're going to talk about what you can do with zk and other stuff privacy preserving technologies. So here's a little bit of context. Um we're going be talking about

protocols protocols that can be used to develop applications on top of and at the same time they're distributed systems. So blockchains right so examples are Ethereum Salana and stuff like that. So these are the protocols. When I talk about protocols, this is the protocols. So if we zoom in a little bit these protocols, we'll see that most of them are transaction centric. What it means is that kind of works like this. So there is a user user submits a transaction then goes through ordering execution blah blah. Then it settles on the blockchain and then you know someone might say transactions don't grow on trees but apparently they do. So we have like a garden of transactions, transaction centric delights. And um now

we would like to add maybe some privacy. So privacy for for settled transactions, transactions that are on the blockchain and just you know just exist. So we would like to add some data privacy meaning that we want to hide the user. We want to hide the data the user submits and application privacy because we have applications right? Uh so what applications the user is actually using. And now you ask, you're probably wondering how do we do that? Well, we use ZK for data privacy and for application privacy, we use more ZK. So, a lot of ZK, right? But here are some problems with this. And these are problems I encourage you to work on.

First of all, ZK is slow, which is not new, but uh it's a bigger problem for protocols uh like I described because we are building applications and how do we make applications more private with ZK? We basically make them circuits. So ZK directly limits the complexity of the application you can have on your privacy preserving chain, right? So the faster ZK is, the more functionality we can have and we at the same time we kind of want to use ZKVMs because uh we have a lot of applications and writing custom circuits for each one might be a bit like annoying from the tool chain perspective. But ZVMs are even slower.

So everything is super slow. We need to make everything faster. Recompiles are very cool. But there are more problems. What if we don't want to commit to a single proven system? So like yes, Business might be cool, but what if we want more? What if we want to use uh I don't know G 16 for example? Could be right. And so we kind of want to write applications as circuits, but at the same time we don't really want to kind of specify the field size, the commitment schemes we use. we want them to kind of like adapt to what we're building and this does not really exist right now. So there are uh just a bunch of proven systems that anyone can use and they all have different features.

But to have a proven system that has uh two features that no proven system combined before you have to build your own one which is like not ideal right so ideally you would like to um kind of write an application in lowlevel agnostic way and then just uh you know use whatever is a pro system that uh helps with a particular case. So if we do all of this, we imagine that we did all of this, we kind of get into the heaven. Now transactions are powered with ZK and they're super private. They still grow on trees, but they're, you know, like very shielded, very private.

Everything is cool. And so the next question in our heaven is what we do with these transactions. So I'm a user and someone sent me something uh using this system. How do I know about that? Uh it's a difficult question because everything is encrypted. So the only way I can do that is to try decrypt everything. You can imagine it's kind of expensive to do, right? So one approach to deal with that is to ask someone who can help but um they will learn something from it. Right? So one of the approaches that uh you can use is FMD fuzzy message detection. It's uh a system that allows detecting

transactions without decryting them. And so basically this is not exactly optimization like in general it's more like delegating the work to someone else and ideally we would do better. How do we do that is a question for you. So I encourage you to work on that as well. And uh we can also think about how to prevent detection servers doing some bad things. I also encourage you to do that. And once you do that, we'll have shielded state synchronization powered by FMD or someone else, some horse uh that brings transactions from the trees to the user and uh possibly not back because we have a train. And after that, we already kind of figured out how to

deal with transactions. But the thing is that users don't really think in terms of transactions. So it's not like I'm like I really want this like um you know, op code 61. Uh, no. I I'm like I I want some Bitcoin. And this is an intent. I mean, let's be honest here. I want some Bitcoin. I wouldn't mind. Like, if you want, I can give you an address. You can send me some. Uh, but this is my intent. This is super simple. So, you probably heard about intents. If not, I'll explain to you what it is. You want something, this is intent. Luckily, we don't have to formally explain what it is. That would be a bit more complicated. So users think in terms of intents and transaction centric protocols do not exactly help with that.

So there are bunch of things that make it difficult because transactioncentric protocols are not designed to work with intents. So what could we do to make it better? We could have an intentric protocol that kind of helps to deal with all of these issues and the user can get back to their intents, right? And so everyone is happy. Well, a kind of everyone. I guess someone is not happy in this picture, but you know, don't care about that. How do intentric protocols work? So, there is a solver. Solver receives intents from users and solvers matches them into transactions. Here is a problem. Solver sees intents. So we are

kind of trying to build something very private, very you know veiled and uh very cool with intense and like heaven next level. So this the next level. Well, we'll see after that or maybe not. We're not there yet. So you know, one step at a time. So solver sees intense, right? Uh and we would like to fix that. Um, so we don't want the solver to see intent. So we kind of put a veil on the intents and also add the blindfold just in case. So kind of that's what we want.

We want private solving. Uh there are some approaches you can try. So there is a T solver. So like a box you put intense in there and then it somehow outputs transactions, right? Also shielded. And there is also like MPC solver that like you know it's very unclear how it would work, what it would receive and all of that. So um these approaches kind of could work in theory but practically speaking nobody works on that because nobody cares about intense right now. So I encourage you to care about intents. Um so you can see the the diagram is a bit like disintegrated in the middle because what do I draw there? I don't know. So what we really want is something like this.

Uh so so we kind of send shielded intents to the solver. Then there's some magic happens and then we have sh transactions output and you know what to do with this uh to be encouraged to work on this of course and once uh we solve this problem we get to the heaven of valid intents where the users submit intents that go through private solving then produce transactions that are zk powered they go through ordering execution settlement they uh get to the trees and from there shielded state sync allows the users to uh discover uh what they actually got as a result because you know not everything in life is about intent. Someone can send you something

like bitcoins uh just for free because you gave a cool talk hack can happen. So um this diagram roughly represents what we are trying to build at anoa. Uh so now you know uh hopefully and um that is actually kind of it. So um to reach the heaven of failed intents we need to do what? We need the K abstraction layers that abstract the specifics of the proven systems uh from the application developer. We need more shoulder state sync techniques that kind of make it uh you know more efficient. We need more private solving techniques that exist and we would like to have more privacy preserved applications on top of our

protocol to reach the heaven of failed intents and there are cure codes that are colorcoded and the yellow one leads to our research form where you can talk to us about all these problems. You can also follow me somewhere where you will find me except life that is not legal. Um so if you have questions I would be happy to answer them. Yes. Do you already have an approach to private kind of so you know there is a very simple approach to solve any problem

related to privacy. You take tea, you put everything in it and you kind of start gaslighting yourself that it's fine. Uh so initially when we looked into these approaches um it seemed okay but then we did something with TE's specifically we did ch state sync with TE's and it turns out that TE's are not exactly ready to be used right now. Uh so another approach would be to use NPCs NPCs are also very difficult to use because if you want to make something more complex it becomes extremely expensive. So like imagine you have a bunch of users with a bunch of intents. What does it mean? Does it mean that you have a bunch of MPC agents? Can you imagine how much complexity it will

introduce? Um, so these are the two main approaches that uh we could see. Um, I considered other approaches like FH coax and stuff they do not work directly. Uh maybe there is some technique that just uses a clever combination of all but we're not aware of that. And that is why I encourage you to work on that with us possibly. Yes. When you say TE's are not ready, is that a security thing that they leak information like? There are many things. Uh so yeah security is a problem because um so you use like internal keys in the tea to protect everything from everything and there are

attacks that leak them and they're hardware attacks which means that you cannot fix them yourself and so you're kind of dependent on the hardware uh producer and this takes ages and they will always exist. So this is a big problem and especially now when they're just not fixed, right? So there are also other issues like TE's are not very popular and therefore they're not very accessible. So uh if you want to use them on uh remote servers uh rented from somewhere, you do not have access to low-level instructions that are used sometimes to fix some issues. Um, another issue is that you do not have um tools to use TE's like there are VM based TE's that kind of the idea is that you just load your code in this tea and

it works. Well, it doesn't work because you need to write like a tiny kernel for it. So, you know, it's like a little bit more complexity than just use your legacy code. And so, it's a little bit like complicated right now. I guess a lot of these issues will be fixed uh over time, but I don't think the the fact that you depend on the hardware uh company will ever go away. So there will always be bugs and there will always be bugs that depend on the hardware producer basically. Yes, I'm curious about Well, you can create one. there is no cure code because this is something that

um you know becomes more of a problem for us right now and I don't think we're going to work on that to be honest because I I don't even know how to like address this uh I mean I it just seems like it takes a bit more resources than like three people kind of like trying to make something work using ZK MPC FH everything uh to build the heaven so you know that's your I I can tell you what app I use to create cur codes just to make the job easier. Just a Python cure code library.

Pretty simple to use. Yes. So, um yes, question is my favorite. Oh, thank you. Thank you. I do have a question. Yes. Very basic and what do they stand for? Oh, right. Right. Right. So is a trusted execution environment. It's just a hardware tool that kind of does protected computations. It's protected with a key issued by the hardware company like Intel, AMD or whatever. And MPC is multi-party computations. So basically the idea is that uh they're a bunch of people uh knowing something and they perform computations on what they know uh computing together the result of something without seeing what the other

people have. So this is uh the two things. Solver like MPC circuit or uh well when you talk about like circuit what do you mean or like um application circuit or solver like computational complexity because solvers do not run circuits. I mean they they create proofs and they verify proofs but they do not have like circuits attached to them. So what specific? Yeah it's very complicated. So

generally like it's so complicated you can all cannot solve it in the general case uh because it's like you know a bit of outside of NP world. Uh so um solvers would be very hardworking entities that are designed to work with a singleish problem at once. Um all I can say right now is that it's like going to be complicated. So ju just to imagine, right? Um imagine we have like a very simple um exchange, right? So I produce a lot of intents like I want to exchange my Bitcoin for Ethereum that I received from you, of course. And then uh you produce a bunch of intents like that.

And so the solver sees all of them and they have to go through them like match them together because they're also not so you know like trivial. They're not just like I want this for that. It's like there is an exchange rate. There are maybe some other conditions that are related. So um yeah it's going to be expensive very expensive. Yeah. We kind of like take all the costs and put them on solvers. So this is how it works roughly. So, I guess there are no other questions. We're good. Thank you so much. Thank you.