Nillion Network: Humanity's First Blind Computer

All right. GM, everybody. Welcome to what's going to be another great DevNTell. Today on the show, we're going to have Steph and Miguel from Nillion Network. They're going to be teaching us all about it. So Nillion Network is the world's first blind computation protocol. And you might have seen quite a bit about it on your timeline, like I have. And what we're going to be learning today is what it's all about and how we can start building with it. So before we get into that, let's hear a brief word from our sponsors. Today's episode of DevNTell is brought to you by Consensus 2024 by CoinDesk. Consensus is the largest and most established global hub for all things crypto, blockchain, and Web3. Get your $299 developer pass today to connect with the industry's largest concentration of blockchain builders. Learn directly from top chains and protocols as well as join the IRL EasyA Hackathon. Use the link in the description below to grab your ticket today. And for the first 30 people to register, you can save 20% with the code DEVDAO. That's D-E-V-D-A-O. Now, back to today's episode. Hey, hey! GM, GM. Welcome to the show, Miguel and Steph. It is an absolute pleasure to have both of you on.

Thank you so much, Narb.

Thanks! Excited to be here.

Excited to have you both! So I guess before we get into the content here, do you want to give a brief introduction about both yourselves, just in case people who are watching the show are meeting you for the first time?

Okay, so maybe I can go first. So my name is Miguel, and I'm co-founder and Chief Scientific Officer at Nillion. And essentially my background is at the intersection between technology, so telecom engineering, as well as mathematics.

And I'm Steph Orpilla. I lead developer relations at Nillion. My background is in engineering, but I'm super excited to be part of a company that's building ways to make cryptography so much easier for developers like me.

Excellent, excellent. And I guess, in terms of the name Nillion, does it have a meaning per se? I guess what's the brief history around how it all came to be?

I guess the bottom idea is to use the word 'nil', which in Latin means kind of 'nothing,' to kind of illustrate the fact that when you're computing on our network, nothing is really exposed or leaked or shown.

Excellent. And I've seen quite a bit of people with blindfold PFPs. Is that kind of like a Nillion cultural thing going on or what's the history behind that?

Yeah, every Friday our head of marketing, Charlie, does a stream where he adds blindfolds to people's PFPs to make them into Blind Warriors. And that's kind of a nod to our blind computation.

Awesome. And this is all done livestream?

Yeah, it's done one-by-one. Everything is completely unique, done by hand by Charlie. It's actually going on right now.

Oh wow, the dedication! That's amazing. Awesome. Well, I mean, let's get right into the content, just in case people want to hop on that livestream after the fact to get those blindfolds on. But yeah, please take it away.

Thank you very much. So I'll start sharing the screen. I would like to talk to you guys about essentially a couple of cool things that we're working on at Nillion. One is around AI, and the other one is what we call the Orchestration Layer.

So essentially, private machine learning is at the intersection of AI and cryptography. But you may ask yourselves, why have I chosen this intersection? I mean, cryptography is intersecting many other sectors. Why this one in particular?

Well, the reason is because AI is, you know, we're in the middle of this AI revolution, which is about to transform everything around us. And also because one of the key milestones in this revolution is the creation of personalized AI.

And what I mean by that is that you will have a digital clone of yourself, which will know everything that you know and will kind of empower you on the positive side, you know, your mental skills and your productivity will raise up. But on the not-so-positive side, this AI will have access to all the information that you have. You know, all the emails that you've sent, all the messages that you have exchanged, even what you say and what you talked about because it will be listening.

It will know your thoughts, your hopes, your dreams because it will be your confidant, your therapist, your friend. It will also have access to your fears and, you know, it will know your strengths and your limitations and your weaknesses as well. So as you may think, as you may realize, this is a lot of power to have because it could essentially break your relationships, you know, with other people because it will intermediate them. It could essentially destroy your career if it wanted. It could essentially destroy you as a person.

And the problem is trust, because this will be run by a company, and nowhere in history has a company had so much power over a certain individual. And so this is very troublesome. This is very scary. And that's why we think that privacy has to come in hand with AI. It is a must, and it's going to elevate the need for privacy-enhancing technologies to a center position on stage that it has never occupied before. It's going to become part of mission-critical infrastructure.

So that's why we think it's really cool right now to develop and, you know, to be a developer working at the intersection between those two trends and why we think it's very cool to work on private ML. So what is the status of private machine learning?

It's hard to summarize it in one slide. Here I'm focusing more on kind of private inference problems and mostly on Multi-Party Computation protocols. But more or less the idea is that all across the board, we've made a lot of progress. Only a few years ago we were dealing with very simple machine learning models managing just a few thousand parameters, and now we're dealing with more complex architectures like transformer architectures working with billions of parameters.

But there is a price you always pay when you work with privacy in terms of performance. So just to give you an idea, Sigma, which is kind of the best-in-class currently at private inference of LLMs, it takes to work with a model of 1.4 billion parameters, it takes around 10 seconds to generate one token, which is one word that you see on your screen. So this is like at least 10 times slower than plaintext inference. There's a lag. There is a difference. There is a price that needs to be paid.

So one could ask ourselves like, what is next after this? We are really excited to be exploiting or kind of taking advantage of a very famous technique from digital signal processing which is called the Discrete Wavelet Transform (DWT) to unlock and empower the applications around private machine learning. In particular, we're tackling the most difficult problem, which is dealing with the non-linearities, with the activation functions. Those are really hard to handle in machine learning, in private inference of machine learning or private training.

And the way to go, the way we apply it, is by expressing those as a lookup table which will be very large, but then we apply the DWT, which has a lot of compression capabilities to actually reduce the size of that lookup table so it becomes manageable. And that is kind of the main idea with this technique. It has never been applied to cryptography, so we're really excited to do that. And DWT allows you to work like mathematical lenses or microscopes, and that's what you see essentially on this picture, how a complex function can be summarized into a smaller representation that is amenable to computation.

Without getting too much into those details, though, and zooming out again to the big picture, there is this difference between what cryptography can achieve today and what LLMs running in plaintext can achieve. That's what I mentioned before. And it's also clear that with the billions of dollars that are being invested on the field, LLMs are like on a trajectory that is going to be probably superlinear, it's going to be even maybe exponential in terms of increasing their performance and their ability to, you know, become smarter and more intelligent.

So the question is, what happens to cryptography? Will it lag behind? Will it be left behind, or will it be able to catch up? I think this is a very important question because it actually kind of touches on whether it makes sense to work on this or not. And it better be that the answer is yes, because as I said before, our whole society is depending on our ability to provide privacy to LLMs and AI in general. I think that the answer is yes, and to explain it, let me make use of a little bit of management theory.

So there are four stages in which you can kind of manage a person or an employee, ranging from supervision to delegation. Supervision is when you have a very junior employee and you have to be like constantly helping them out, like breaking down the work into pieces, planning, double-checking the results, providing them with feedback. This may sound familiar to you, because this is exactly where we sit nowadays with LLMs. We are supervising LLMs. We're doing this heavy work with them.

But this is not going to be the same forever. As they become more powerful and intelligent and autonomous, they're going to transition through the other stages all the way to delegation. Delegation, what it means is that you define the boundaries and you give the playground to the LLM and it then does whatever it pleases within those boundaries. For example, I give you all my health records, I give you all my financials, I give you access to my agenda, and I want you, please, to take care of my health for the rest of my life.

I want you to research the best doctors, the best techniques. I want you to care about running tests to see if I'm going to be developing some cancer or some type of illness. I want to be protected and given care of by you. The flip side, of course, is that I have to give the LLM all that information. But that's kind of how delegation will work with personalized AI working in boundaries. The interesting thing and the opportunity for privacy-enhancing technologies is that as we move towards more autonomy, the privacy requirement on the one hand is going to be more important because we're going to be sharing more sensitive data with LLMs and AIs in general.

But on the other hand, the speed requirement will be more lax. And that's because the type of interaction will transition from that supervision where it requires very quick responses to delegation, which is kind of like: okay, I'm giving you this task and take your time. I want the correct answer. That's more important to me than just to be constantly on top of you and giving you feedback. So this is the perfect storm for privacy-enhancing technologies because it's providing the space for not-so-performant solutions to actually be useful and helpful, and also because privacy is going to become so much important.

And we're already seeing this transition, for example, with LLM agents. Here you have some of the main design patterns, and what they do, the idea here is that you give the LLM a little bit more time and it does some more processing and then it provides you with an answer. And that answer is typically better than the one you would obtain with just a one-shot type of interaction. For example, it's been measured in benchmarks that GPT-3.5 working with agents is as performant as GPT-4. So that gives you an example. And that gives you already the trend is going towards coaching. We're in supervision so we're already transitioning towards coaching.

So let me talk a little bit then about privacy-enhancing technologies (PETs) and what this is. If you're coming from a blockchain background, it almost seems like cryptography is a synonym of Zero-Knowledge Proofs (ZKPs). Just because ZKPs have been so helpful and powerful in the blockchain space. But there is more. There are more things beyond ZKP.

So what I would like to give you now here is kind of a mind framework for deciding when to work with three important PETs: one is ZKP, the other one is FHE (Fully Homomorphic Encryption), and the other one is Multi-Party Computation (MPC). Starting with ZKP, one of the main characteristics here is that the prover is running the computation in plaintext. So that's the most important element to take into account. So if you want to use it for privacy purposes, then this implicitly means that the secrets must be coming from the prover themselves.

So that's what happens, for example, with private transactions on a blockchain. You have a prover and then essentially that prover is the one contributing with a transaction and hiding the values in the transaction. There's another way or another path for applications in ZKP which are around verifiability. The idea here is to remove the need for consensus and to be able to delegate computation to one node, but then to demand from this node to prove to the rest that they have properly run those computations. And this is the example of ZK rollups and is also the example of verifiable ML. But that prover is going to be running those computations in plaintext.

Now there's limitations then around ZKP. You cannot store information in ZKP. You cannot run computations without seeing them. What you are demanding if you want to be doing this is for a different model, the one provided by FHE and MPC. In FHE case, you will have input coming from one client and then all the computations are performed in encrypted form so that they can be delegated over to a server. This is a big difference compared to ZKP because in ZKP the prover is doing the computation in plaintext, in FHE the server is doing the computations in encrypted form. And if you want to expand this to more than one party so that you have inputs coming from different sources, then you're talking about MPC, which is a sort of extension to this FHE flavor.

To complicate things a little bit more, it turns out that MPC actually can be made from different flavors and one of these flavors is FHE. Other flavors are linear secret sharing schemes (LSSS) and another one is garbled circuits. There are more, but these are kind of the main important ones. So the question might be like: which one is the best? Like, which one is going to win across the board and is going to replace the other ones? Which one should I focus my efforts on learning and being familiar with?

It's not easy to answer this question, because the trade-off space is very complex. Talking about performance, it turns out that the three ways of building MPC have different performance bottlenecks. For example, linear secret sharing is round complexity, for garbled circuits it's bandwidth, and for FHE it's computational complexity. But the trade-off space is even more complex than that, because if you go to cost then you will have the question: should I be running with one node for the computations or two nodes or many nodes? Who runs those nodes, who pays for them? Should I be doing preprocessing or not? Should I be using ZKPs, for example, to make sure that the inputs are within certain ranges of values? Should I be using like specialized hardware?

If you go to maturity and you have like several frameworks in front of you, then the questions will be around the due diligence for those frameworks like: is this an active community? Is there documentation that I can rely on? Are there interesting channels that I can go to for help? Has there been any production-ready or production-touching product built on this software? You know, the typical questions. Around security you also have a lot of deciding to do, like: what are the basic cryptographic assumptions behind the security for this framework, for this library? Is it quantum-safe, for example? Does it just protect against the privacy of the inputs or does it also guarantee to a certain extent that the outputs of the computation are correct? So that's passive versus active security. And also can I compose these protocols in this library with other protocols? That's not trivial, that's not always the case.

And functionally speaking, you also have like a lot of decision making to do because not all of the PETs solve the same problem. They are complementary functionally speaking. So which is the one that you should be using, or which ones? It could be more than one. So which one is the best? The answer is really all of them, like, can I keep them all? This is the main thinking that brought us to the concept of the Orchestration Layer. Like, we wanted to provide developers with enough range of choice so that you guys could tackle any given problem and even combine different techniques to kind of come up with solutions that meet the requirements, be it in terms of security, performance, cost, maintainability, whatnot. So choice is the name of the game.

And that's why we are building towards this architecture. It's a modular architecture that instead of focusing on one PET is kind of encompassing several ones. It's acknowledging the fact also that PETs is a very active area of research, so we're not prescribing and closing on a predetermined number of PETs and then implementing them and that's about it. But rather we're building an architecture that is flexible enough to be able to accommodate new PETs as they are developed and invented. So that we are already acknowledging that in the future there will be more innovation coming in, there will be more changes. So the essence of this kind of approach is to have this orchestration layer sitting on top of the different PETs. So PETs could be ZKP flavors, could it be MPC flavors and so on. And this orchestration layer is going to allow you to interoperate between the different PETs in terms of data.

So it's going to enable, for example, to switch from a ciphertext in FHE to a linear secret sharing in MPC, or interoperate in terms of program representations, which is the way in which you represent the computations that you want to run, or also in more general terms, in terms of the protocols themselves. And there is a cost to switching, so that needs to be factored in. But the idea is that this orchestration layer is catering for those transformations to happen. Then of course you have a compiler, you have the typical libraries, there's a lot to say on the library front because there will be libraries according to different domains, as you would expect from any programming language. And then on top of that, we have the Nada language, which is our programming language on top of which developers will just develop their applications. The name of the game is abstraction. The end goal is to try and provide different levels of abstraction for developers to work in.

At the basic level we have the black box. That's when you have the leanest and lowest-touch integration with our platform. You just provide your protocol as your privacy-enhancing technology as a black box, just as an API. And so developers can choose between different APIs and interact with them but they have to do kind of the plumbing to connect between one API and the other one. Expert switching is when we go one level up and now the different PETs, they become first-class citizens of our Nada language, which means that within the language you can refer to one PET or to the other PET and do the switching between of them in a seamless way. But this still requires a lot of knowledge from you as a developer because you have to understand all this complex trade-off space.

So the idea is to start simplifying that in the next layer, which is smart switching, and to start grouping some of the flavors, some of the PETs, and creating an abstraction for that group. For example, instead of working with the different flavors of FHE, you would be provided an abstraction of an integer data type for FHE or a bit or a fixed-point rational. And under the hood, the compiler would be switching between different flavors, for example, TFHE or CKKS, depending on the application, like making the best choices on your behalf so that you don't need to worry about that. And so it is through this grouping technique that we will eventually end up with this more intelligent compiler, which is years away from now. It's a very complex task, but the idea here is that you have enough interactions automated so that it feels as if it was a normal and standard development environment. And all you need to care about is just coding and maybe just give a few directions as to what matters to you.

As you can imagine, this is a very ambitious project. We haven't built it all at all, so we have just a few elements and Steph will talk a little bit about that. But the idea is that we need help to build this. So I would like to urge you guys to come and help us build this. You know, if you're a cryptographer you can help us build the PETs, also build the connectors between the different PETs, which are nothing but cryptographic protocols themselves. But also if you are kind of standard developers and you're experts in a given domain, like machine learning or image processing or graph algorithms, you can also help definitely in creating those libraries. And even if you're just interested in the final endgame, which is programming, there are things for you to do.

You don't have to wait for the whole thing to be built. This is like conducting an orchestra of instruments and you don't need to have like a full orchestra to play beautiful music. You can start playing with a few instruments. And so you can from today onwards you can already start, you know, working with us and working with our SDK in order to create beautiful programs. I think this is the perfect segue into what Steph has to say, so Steph, over to you.

Awesome. Thanks Miguel. Hopefully that inspired all of you to want to build, I know I'm excited. So I just wanted to share Nillion's docs. This is how you can start building the easiest: go to docs.nillion.com. You can read about 'what is Nillion' and all of our different ideas. But the thing that I really want you to do is go to the developer quickstart. This is how you can start building on Nillion really quickly. So you'll install the SDK and tools, set up a developer environment, run a local Nillion network, and then you can start writing your first Nada programs. So this will walk you through how to write tiny secret addition, which is just a one-party addition program. But from there you can build pretty much anything with the different tools. So you'll connect with the Nillion client and you can store different Nada programs, secrets, and then start to compute on those programs from blind apps.

So I know a lot of folks in Developer DAO are very familiar with Scaffold-ETH, I know I am. So we have a scaffold-nillion repo. This uses Scaffold-ETH 2.0, which is that dApp toolkit everyone's familiar with, but it's a Nillion wrapper around it so that you can easily connect to our network and start building blind computation apps. So after you go through either the Python quickstart or the JavaScript quickstart, I encourage you to check out our builder bounties. So we want to reward anyone building on Nillion. From our docs you can come all the way down to builder bounties, it's under the 'Build' section. So go from Build to builder bounties. And you can see that we've actually just launched a builder bounty today. So you can be rewarded for learning and building.

This is a bounty to use one of our three tiny demo libraries: either TinyBid, TinyBio or TinyBin to create a blind computation app on Nillion. So you can look at some of the different things that we've already done and then turn that into your blind app. I always find that the easiest way for me to learn a new protocol or learn about something is by building, and so if you're that type of learner too, I encourage you to check out our bounties. Otherwise just come to our docs and start learning about the Nada language and everything you can do on the network. You can see some of the projects that have been created already. These are seven different projects that were created at Scaling Ethereum last month. That was our latest hackathon and they span across use cases in AI, healthcare, different really cool consumer apps, even something on decentralized identity. So these are all really great examples of the types you can do with Nada programs and blind computation apps on our network.

I think that's pretty much everything for me, so maybe we could take some questions if there are any.

Yeah, that last part actually is a good segue into a question I have. So there's obviously a lot to digest here and thank you so much for going into the depth you did. So I guess, in terms of what's possible today, maybe could you zoom in on a particular example from one of those awesome projects or something off the top of your head that people can do with Nillion Network today? And then as well as something where Nillion reaches that end-goal state, like what would be possible? Like how would today's blind applications kind of evolve into whatever they would be when that state gets reached?

Sorry about that. Okay, so coming back to our awesome projects, one that I really loved was something called PrivyCal. So this builder created a calendar app where you don't have to see anyone else's calendar to figure out whether time slots that you both are available overlap. All you know is your own calendar and then if there's a slot that overlaps with your data, you can block that slot. This makes use of Multi-Party blind computation, because two people would each have their own time slots but not be able to see someone else's unless there was an overlap. So this is an example of a real app that was built just last month using Nillion. And then I think Miguel can speak more to what we want people to build eventually in the AI space.

Yeah, essentially there is some lower hanging fruit that you can approach nowadays or right now, which is around simpler machine learning models like linear regression, you know, forest or random trees, like for example prediction models. We're working now with time series predictions. You know, those are like the ones on the left on the slide that I put about the different machine learning models. But also kind of easy convolutional networks as another example where you can work with images and do for example stuff like predicting whether scans of a lung will have cancer or not. But then as you move to the right, we definitely want to enter into the terrain of LLMs. And that's now looking more into the future. So one basic application there is running private inference on an LLM. And the idea here is that both the model weights as well as the prompts, the user prompts, are protected.

And that has advantages to both parties: the owner of the model, they have the advantage that now they don't have to become an expert and actually operate that model, which it costs a lot of money in terms of operational expenses and also requires a lot of expertise in terms of protecting those model weights and having an SLA always up and so on. And on the other hand it protects the user against the threat that I was mentioning at the beginning in my presentation, which is the necessity or the need to actually share your prompt with the LLM. And that prompt will contain personal information, so you don't want to be doing that. So it is like a win-win for both parties, actually, not just for users but also for company and for model owners.

Yeah, I was actually going to touch on that point after the fact of user data privacy, just because we know how messy things are when it does come to user data. So it's really nice to hear that one of the end goals is to ensure the user's privacy and I mean, whether or not people will notice or not, basically any app you use today and in the future people are going to be harvesting your data one way or another. In fact I saw a tweet yesterday about a user consent in Slack or something like that mentioning a model, which was interesting to see. So yeah, whether you realize it or not you're leaving a bunch of data exhaust as you traverse the internet. So it's very promising to hear Nillion is working on solutions to combat that, as well as kind of bring AI and crypto closer together, which is awesome to hear. I guess you did mention briefly that you are I believe hiring. What is the best way for folks to reach out to you if they are interested in helping build out Nillion and yeah, just how can they get rolling on that?

I'm sending you a link that you can post. This is our workable job listings, so people can apply directly here, or they can ping one of us on Discord or on Twitter to learn more if they want to know about a specific role.

Excellent, and I just posted that in the chat. That's awesome. And then I guess in your recommendation, the best place for people to start tinkering with Nillion if they want to start hacking over the weekend would be those quick docs and the bounties as well you mentioned, correct?

Yep. So start with the docs, go through one of the two quickstarts depending on if you're more of a Python developer or JavaScript developer. And know that we're always available on Discord, and we also have a pretty active GitHub discussions forum where people are doing show-and-tell of things they've built and also asking questions, reporting bugs, all of that kind of thing.

Excellent. You heard it here folks, what better way to spend your weekend, or at least part of it, than hacking away with Nillion? So those docs will be posted in the YouTube description shortly after we conclude here, but of course you can also find them on Nillion's website if you are eager to get going right away. But unfortunately that brings us to time here. Miguel, Steph, I really, really appreciate you coming on the show today, sharing Nillion Network with the Developer DAO network and yeah, really excited to see what people come up with and see the network evolve as time goes on, because that intersection of AI and crypto I think is going to be more prevalent as time goes on, whether people realize it or not.

Great, thanks so much for having us here, Narb.

My pleasure! And before everybody leaves, I just want to share, sorry for blocking your face there, Steph, the QR code for people to scan to claim your NFT for being an attendee here on DevNTell today. So what you want to do is scan this QR code, fill out the form, and you'll be airdropped an attendee NFT on the Base network within a couple of days for attending DevNTell live. So you'll have an hour and a half from now to be able to claim that before the form closes, so definitely get on that. And with that, just want to wish everybody a very happy Friday, happy weekend, and we'll catch you back here next week for another episode of DevNTell. All right, all, have a good one!

Thank you!

Thank you! Bye!