Bringing an Open Music Protocol into The Real World: Onboarding Millions

Today it's gonna be another version of my like pro crypto style of talks which is we speed run absolutely about a lot of concepts try to get as much as possible, hold your seat and put your belt on and let's go together. So the motivation and goals for this talk are mainly see which are the basic common questions that we have about FHE, what is even FHE, which I will get shortly into now, see where we can apply it, where we have been able to apply it, and see what limitations and alternatives and conclusions about those we have been able to apply it and see what limitations and alternatives and conclusions about those we have so fine-found so FHE why how and what basically the easiest way to map that in your brain is we are able to compute among other privates other people's private data and so the results are always encrypted, meaning whatever we get out of the computational result, only us can know the answer to. The why this is useful, I mean, you can sort of see this as like an untrusted TEE somehow. So imagine if instead of TEEs being in hardware, they were just an encrypted thing that we all work and run on the top of math. There's like a lot less security assumptions that then we need to have.

And how we do that? Well, we are based on lots of different primitives, but I would say the most important one is lattices, for example. But this is likely for other like more advanced or mathematical talks, so I've tried to abstract basically everything that is related to this core math. What can we build? So one of the first really small explorations that we did was, can we actually make Photoshop, which can be a software as a service, but run on an FH server.

So basically, my picture is private, and the server doesn't know anything about my picture, and I will tell the server, I want to do these edits, the server will perform those without knowing anything about the image, and will return me the image encrypted later. So only I can decrypt it. So far, server doesn't learn anything, doesn't know anything at all, but I got my picture edited. And this is basically what we did with Mario here. We can go, like, further.

So we created some kind of frog crypto shitty game, I would say. We thought, what if we could do more with our frogs? And so one of the things that we decided is, well, let's make them fight. So now you have an arena which runs on a server that is basically performing all of the FHE stuff. And so you can put your frogs there, they fight, and you just know what was the outcome of the fight.

But you don't learn the strategy of the rivals, you don't learn absolutely anything at all, which can be fun, can be useless, I'm not really sure, but up for you to judge. The two most important reasons we learned is that it's a big pain to write these things, like the Photoshop was okay because it was a negative of an image, then we got into the Pokemon kind of thing, and it started to be like, it's taking me time to write this. And the more you want to do like the much harder it becomes so writing boolean circuits by hand was not gonna work the second thing was we found a way to actually crack this thing up uh which i will go through in a minute so in terms of speed and it being uh terribly slow when you want to start doing more elaborated things, there's a really, really, really nice talk by Neil Emert, which you can fetch on YouTube in the Ingon Yama channel. He basically cracked a way to do really, really, really fast entities. And summarizing it a lot, entity is the core operation of FHE, which is embedded into bootstrapping.

So the general idea that I want you to get from there is we can perform like 65 million 1024 point entities in one second. So if we can adapt our problems to look on this way, well, it looks promising that we will get some significant performance in order to do more things. The second thing is, what do we want to build now? And so forwarding that, there's some ideas that we have discussed. Of course, this is not like we are committed to do that, but it's just ideas that have flourished from this exploration.

We can do private social trust graphs, meaning I can basically say how much do I trust people in a completely private graph that no one can see, and we can make queries to this graph about any other person, and we will know how much we can trust them based on how much we trust our peers. No one learns absolutely anything about our relations, but we get useful information out of it. The second one could be we do private web search at civilization scale. So imagine we can do these private information retrieval protocols and we get Google's index database, we perform an encrypted search, and we get encrypted results out of it. So we are just bringing completely private, no incognito mode stuff, web searching for anyone to be used.

Questions and conclusions? It was really cool. FHE is slow, and it will be like that maybe for some time, but it's really powerful. One of the things we worry is, well, there's maybe primitives that are more powerful than that. And if we know those exist, should we focus on FHE?

Because maybe we can just focus on the next thing and like get even more benefits and more powerful primitives. Is MPC enough? Like are we overkilling with the problems and the solutions that we overengineered here? And how much can we optimize this? How can we move forward, like I would say this is like the classical type of stuff that I think we got some insights and that we have further questions on.

So that was the end of the speedrun, I hope you are still there, so please if you have any questions. Thank you. Questions, raise your hand. Hi, thanks. Just a question.

You say that it's slow. So what are the most factors that make it that slow? So there's a lot of trade-offs that you can take here, basically. But the main idea is you're working over lattices and therefore you are accumulating some error and the more operations you perform on a ciphertext the more you need to like clean the error out such that it doesn't eat up the useful information mainly just to give you some kind of idea now if you want to perform a byte addition in consumer level hardware we are at around like four seconds maybe or something like that so terribly slow for a lot of things but there's a lot of subtleties and details that you can definitely optimize for to get the problem like much much better it's one question there have you tried using 4080 super for your computations? Because they have the new chips?

Yeah, so I would say, like, of course hardware will be the bottleneck, but we are at the point that we need to make this a hardware problem and not a purely theoretical problem. So that's why I showed basically HAIR, which is an FHE compiler made by Google. So one of the goals is we have this bootstrapping operation, right? And we want to have as less sequential bootstrapping operations as possible, because until I don't do one, I cannot do the next one. So this is like cool research topics and cool ways in which we can try to optimize our programs such that the final Representation that we get allows us to just throw this thing into a ton of Like graphic cards, let's say and get a significant speed boost Whoa Any more questions?

Have you tried optimistic bootstrapping? So there's a... I mean, we've checked them all so far. Following this line, the last thing that I've seen that got my attention significantly is going back to circuit bootstrapping again, mainly because they have figured out a way to see everything as a graph problem and remove all of the dependencies among the graph, so that the bootstrapping, like you can do all bootstrappings in parallel, essentially. So you can throw this to a GPU at the beginning, and you've got it all solved.

This is the theory. Then you need to implement it, and there's constants, and they are massive, and you run into issues. But I would say we have looked at them all. Maybe this is what personally I'm the most interested in.