Protocol Berg v2: Jaya Klara Brekke - The Forest Protecting the Public Good: Nym for Libp2p privacy

after the great presentation earlier. Um but yeah, this is uh this is kind of round two of a talk that um Max and I half like almost gave two years ago um at the previous protocolberg. Um I ended up breaking my ankle just before the talk so didn't make it. Um, Max had some screen issues, so a lot of things kind of like didn't quite work out. Um, but we're very happy to be back with a kind of update on the work that we've done in the meantime.

Um, so, uh, this talk is going to focus on limb nim for lib P2P. Um and what we did back two years ago was uh work um with the nice crew at Chainsafe um on a proof of concept for um NIM and li LIP P2P for the Ethereum Lighthouse consensus client. Um two years have passed. Uh we were very busy building uh VPN in the meantime, the Nimvpn, which we're also, you know, very keen for everybody to try out. Um but uh we are now back on the work um with integrating NIM into lib P2P and this time with a different use case namely for Celestia um and the data availability layer.

So this is uh what we're working on at the moment. Um, we're going to do kind of a little bit of a kind of conceptual thing in the beginning and then we're going to, you know, hopefully get kind of a little bit more hands-on for those of you who want to get um involved because this is after all a workshop rather than um a full-blown talk. Um, yeah. So, what we kind of would like to start off with um uh yeah, so this is this is the overview. Um, here are some download links.

I'll share this again a little bit later. Um, but for those of you who are kind of keen to get started, um, feel free to jump right in. Um, but to start off with a kind of conceptual background, and this was like a piece that I'd fleshed out a couple years ago in a little bit more detail. This year, I'm going to keep it a bit short because I would like for us to get to the practical stuff. Also I'm giving a talk at 4 pm this afternoon that's going to go a little bit more into the kind of philosophical aspects but um a bit of background on kind of uh you know NIM.

So NIM is you know we build privacy software at NIM. Um and uh you know there's been a lot of kind of like work on the topic of privacy uh both um on the technical side but also on the kind of mimemetic and uh narrative side. Um and there's you know what we're noticing is that privacy is still kind of backed into this mimemetic corner. Um, it's still very much kind of this thing where whenever you try and get people to use privacy software, you almost have to like threaten them into using it and say how big and bad, you know, all the kind of potential uh baddies out there are and therefore you need to protect your privacy and you need to use all this very complicated software. Um, and we're kind of hoping to kind of start moving out of that space a little bit.

Um so you know conceptually you know let's say there is this you know idea of like okay so either you're kind of uh when people think about privacy or think about surveillance they think kind of you know you're either in like total surveillance and there's this you know kind of desert metaphor um or there's complete privacy which is this kind of threatening uh void almost of information or lack of information. Um, and there's also this aspect of of privacy mimemetdics that tends to kind of retreat back into the indivi individual and the individual protecting themselves and the individual as a kind of like unit. So, we want to like loosen up a little bit these these categories. Um, and work more with this idea of the forest as a metaphor for uh privacy. Um, and you know, the reason why the forest is interesting is because it's not so much of a kind of eitheror.

When you walk through a forest, you get this kind of these dapples of sunlight. There's some shade. there's various grades of shade. Um, and also it kind of opens up for this idea of like privacy as actually as as a design space. Um, you know, there's been people that have kind of worked on this a little bit before.

So, our friends at Darkfy um have worked, you know, a lot on mimemetics. Um, and this idea that, uh, you know, privacy is not just kind of or the dark is not just the absence of light. It has its own qualities. Um, I think what we're trying to kind of do is expand even beyond this idea of privacy equating the dark. Um, and positioning privacy not so much as a threat but as an an attractive design space.

Um, and kind of to think this through a little bit more in in practical terms, you know, cryptography is, you know, very widespread um, across the world. It just, you know, had doesn't have necessarily always such good marketing, let's say. Um, but there is, you know, this design space is an important space. is literally the lock the locks, the windows, um the doors, the you know the the the building blocks of the digital space um in quite important ways. Um so you know a little bit of a kind of beginning of mapping out privacy primitives.

It would be great to get a little bit of input on that. Um one of the privacy primitives that we're be going to be focusing on in this talk is um the concept of unlinkability which might not be so as familiar as the other ones that are listed here. um that is what you know the NIM mixet really offers in the lib P2P context. So we're going to go into that um in a little bit more detail. Um I also listed web 3 privacy now here.

I don't think ML is in the audience right now but I think they have done some work on um mapping out the privacy primitives as well. And I think kind of that as a shared uh let's say um a shared piece that's like done across you know those of us you know in this space that are working on privacy technology is quite important to start to showcase this really as a as a design space. Um yeah so I think I might leave it there. Um so in short what we're going to do here is um really focus on uh NIM in the case study of NIM in lib PTP for Celestia specifically. um and uh also what uh unlinkability is um and more specifically what unlinkability kind of the challenges that unlinkability poses in a P2P context because it kind of creates some you know interesting um dynamics.

Yep. Okay. So now to the technical side we're going to Yeah. I'll do a brief overview of lib PTP for everyone that's here so everyone's on the same page then go over Nim and then kind of we can look at how smashing those two things together brings out some interesting stuff. So lip itself um basically yeah modular set of protocols specs libraries that easily enable people to develop peer-to-peer network stuff.

So it kind of it sprung out of IPFS. it was originally their networking stack that they then abstracted out because um there's no reason for everyone to recreate and maintain their own networking stack, right? You might just want to do something like build filecoin or the lighthouse client or run celestia on it, mina substrate. There's loads of stuff that uses lip, right? And basically it's just a set of standardized interfaces uh addressing schemes gets rid of all of the like gnarly development stuff that maybe you as an app developer don't really want to do.

And there's a really good essay on the Zcash blog actually um that kind of goes into like the reality of inheriting someone else's networking stack. So Zcash originally just like forked Bitcoin and because of that then had to kind of like go with the design decisions that were built into Bitcoin that then were kind of increasingly no longer um advantageous for Zcash to have. And you know they kind of go into it in this piece where I think at one point they ended up with like their connection logic was like a hundreds of lines long C++ you know kind of strct and it was just uh kind of very increasingly difficult to maintain and like pick apart right um so what is Nim and why does it exist um it's a decentralized incentivized mixet so you will be these kind of like three attributes on the side here right we have kind of the top one and the bottom one kind of formed together to create the kind of anonymity feature that comes from it. Right? So it's an overlay network basically like traffic is rooted through uh multiple nodes.

So no one on like no particular node ever has like a full path of like full picture of where anything's going right. Um so this is your kind of like I think everyone here will probably be familiar with this. This is similar thing to what to does, right? You're just unlinking your origin and your destination or your sender and your receiver from any observer who is running part of that network, right? Uh the two aspects that the mixnet adds on top of this.

So the anonymity basically is you add timing obiscation. So basically like you reorder packets as they move through the mixet at each hop. Uh the mixet also involves five hops instead of three. Um and traffic moves through the next sorry traffic moves through the mixet unlike tour where you basically just like set up kind of like a circuit. So you start streaming all of your traffic through those three nodes.

Um with the mixet we actually break everything down into packets and I will kind of go into that a bit later. So this is where your timing offuscation comes in which is like preventing your traffic analysis attacks and stuff like this. And then on top of this or into this essentially you have we have this concept we're talking about the noise generating mixnet right so noise in the form of cover traffic. So traffic that looks um is encrypted and is the same size as sphinx packet as like normal traffic that you're kind of constantly sending into the network and that you're slotting your real packets into. Right?

So it's um kind of creating this constant constant level essentially of kind of entropy in the system which makes it for an observer very difficult to then pick apart. So this is like a very high level flow of basically you have a client on one side you're having a client on the other. For the purposes of this talk let's imagine that both of these are peers in the li P2P network. Maybe they want to do gossip sub or something. um cover traffic with real packets kind of mixed into it all encrypted in the same format which is the sphinx format and they're all the same size so they're all padded uh leave your computer at a constant rate which is defined by a plus on process um and then basically your traffic will go through five hops into an entry gateway it would then go through three mix nodes and the mix nodes is where you as the name kind of suggests right you get the mixing happening which is basically imagine it kind of like um every time you pass a message, every time you pass a packet to a mix node, imagine you kind of like hold that for a variable length amount of time.

You shuffle those packets like a deck of cards and you send them out in a different order than you got them. And then it goes from an exit gateway and to another client. So that's like a super high overview. We're now going to dig into the ah sorry I skipped forward on my own slides. So right, if I want to send a message from client to client, I will basically write my message into the payload of of a couple of sphinx packets and kind of send them through this flow.

Right? Now each packet is actually rooted on its own as well. So this is another key distinction from tour, right? With tour, you set up a circuit and you're just streaming through that. But all of our packets are actually rooted independently as well and then reassembled on the other side.

Now, that's great for privacy, right? Like that's great for, okay, I really want to send um whatever the message of your like packet payloads is. I want to make sure that that is um hopefully impossible for someone to like tell that like these two clients are communicating with each other, right? But um and this is kind of like the main focus really on the tension between having unlinkability as like a privacy attribute in a peer-to-peer system will come in later because um even though that's absolutely great for privately sending messages between two peers, it's kind of very weird for upstream applications or it is unusual for kind of upstream apps, right, that are kind of just using the NIM network as a transport layer, right? Just sending it through this client instead of, for instance, using like an HTTP client.

Um, and you're expecting stuff like handshaking and streams and, you know, the mixet is kind of it's kind of like a very slow UDP. So, you don't get like message ordering. You have to do all of this stuff on the other end. Um, differs in that you do have guaranteed message delivery. So yeah, basically let's dig into kind of how this works on a like a nitty-gritty level and then uh some of the quirks that come out of this.

So if we look at this first hub now, right, which is um also by the way if anyone because it's like a quite a cozy setting, if anyone has questions, just like put your hand up and we can go through it like as and when um just yeah stick your hand up and shout if you have any questions. Um so this first up, right? So what actually happens when like I as the client I have an app that is going to use nim and I actually want to send a message to someone else right so this is I'm really glad it's a really big screen um so on the left hand side you've got your local machine right by and this is like very generic um this is partially kind of like this is a little bit of a modification of what I have in our docs but like um the QR code was up there before or it's just nim.comdocs so this thing on on your on the left hand side which your local machine right you can imagine the application logic here is like um something that is running uh an app that's using gossip subub and it's using like the nim transport to actually like communicate between pairs right so there's two things that are constantly happening whenever you have a nim client that's connected to the network right at the top you have this um oh actually let's go through it in order shall we so originally what you do is you create this uh like a long-lasting relationship with a gateway that you use as your like first hop into the network, right? The entry gateway.

And this actually partially defines your NIM address itself because the network is um the network kind of handles rooting for you, which will also come up later because it's a bit weird compared to what most lippy things expect. But you basically like so you just do excuse me diffy helman create a websocket um connection to this gateway right and then you're doing two things you're you have two streams of uh traffic that are consistently being sent whenever your client is online right um between the client and the gateway that it's talking to. And one of them is like just sending cover traffic. So you're basically just sending like empty sphinx packets at a consistent rate, right? So from the perspective of an observer, if we kind of kick back here, right?

These like this cover traffic that's going here will be moving at a consistent rate. So you can't necessarily try and detect any like bursts of traffic, which then immediately kind of reduces the ability of traffic analysis to go, oh, okay, well that client is obviously talking to someone at this point, right? you're kind of removing that um that metadata from any kind of analysis that can happen, right? And one of these streams, that's all it does. It just continuously sends cover traffic, which is not very interesting um for actually using it, which is where we get to the second one.

So, this is where you know your application, you I don't know, you send a subscribe message to a particular gossip sub um topic. Completely lost the word there. And what actually happens then is your application logic will then essentially put this in a queue and the queue will um your client will constantly be checking right okay oh suddenly there's something in this queue for me to send there's some bytes for me to packetize write to the payload of a sphinx packet and send through the mixnet and what will happen as is kind of demonstrated here is that these kind of like real packets will be slotted in at exactly the same rate. So basically, you're just kind of like consistently sending cover traffic on a heartbeat. And as soon as you have real packets to send or real data to write to a payload of the Sphinx packets because they're the same thing, then you just kind of slot those in there, right?

So just imagine this like consistent queue at a consistent rate of packets that from the outside look the exactly the same, right? Now we get to the kind of mixing part of all of this. This is so this is kind of as it travels through the mixnet infrastructure itself and you get these you get the mixing aspects there which prevent you from kind of like following streams of traffic and you get the timing offiscation which because most of the um because most surveillance techniques really are like relying upon probabilistic deanmization. As soon as you start adding in like variable delays and timing obiscation then it becomes even if you can go oh okay well we think those two clients might be talking to each other within this period of time following the packets themselves actually becomes like um impossible so what does this look like I hope everyone's like likes mermaid flow diagrams because there's quite a lot of them in here um so yeah basically right your that's the entry gateway okay the client has sent it a bunch of packets It's what does it do? It gets some sphinx packets in.

It does two things. It will decrypt the outer layer of the sphinx packet, right? So you can think of the way that we encrypt everything. We multiply encrypt everything according to its root. So similar to onion um onion encryption, right?

Goes to a hop, peel off the outside layer um because that node can decrypt it. uh does a bit of uh checks some message authentication codes just to double check that like okay this isn't like a spam packet that someone's been kind of like throwing into the network and then your gateway will not have this timing delay right so that it will just immediately kind of uh first in first out decrypt the outside layer go okay this needs to go there check that the MAC is valid and send it on so mix nodes basically do the same thing apart from the fact that they actually hold those packets for like a variable amount of So you're breaking the first in first out kind of traffic flow that would allow you to even if you were like okay I think I can guess that that packet is there and that packet is going somewhere and I can follow it and try and tell um this then becomes impossible right and this happens um between mix node layer 1, layer two and layer three. The layers themselves in the mixet are not particularly important here. Like basically we have like a stratified um topology. And what that basically means is that like once an hour uh where you are so like which hop you are in the mixet if you're running a mix node will change.

And the reason we do this is basically to make it a lot more difficult for anyone who's just going to then try and like not quite civil attack but just like spam the network with like okay cool I'm going to set up like 400 mix nodes um and I will try and make like a single path through it right and we have a bunch of other stuff in terms of uh stopping kind of civil attacks with like a reputation system but that's maybe going a bit too far off the be off the track um this Yeah. Okay. Um just to repeat that for the recording as well. Had a question about throughput and latency too. So um yeah, latency is something that does is is something that you have to take um you have to be aware of for your like upstream apps as well.

And this is actually like one of the points later on that I have. But basically like you know um just looking at a ping example for instance. So like the lip p2p like you know ping protocol just little heartbeat to check that a client's there. Um sometimes you are looking at a ping of like a second and a half two seconds right so you are adding like quite a considerable amount of latency to it. And yeah, this process this kind of which you can basically think of as like the defined rate that both of these streams are being sent at because that is defined then it's this there's a balancing act to be made there between do you send loads and loads and loads of empty packets and then be basically like computationally that's more expensive because you're still like root encrypting these packets, Um and in the case of the VPN product which is built on top of the network you're paying for them so you would like drain your bandwidth quite quickly versus having a higher throughput itself.

Um at the moment the throughput is definitely good enough for like let's say peerto-peer gossip hub and stuff. One of the ways that it starts to one of the places that like it starts to get a little bit um a little bit heavy in terms of like back pressure is maybe if you're trying to uh sync a light node or something like this, right? So we did some work with Zcash which is like you're then because you have to set up like multiple kind of streams, you either have to run loads of limb clients or stuff just becomes like quite a lot slower. This is something that we're currently working on in like looking at in R&D of like maybe kind of um increasing the size of blocks or using something like this to kind of to get past but yeah like at the moment your throughput is somewhat restrained. Um the number will come the actual number will come back to me later in the talk and I'll remember it.

Uh okay. Yeah. Okay. Great. So final hop.

So all of your packets, they've gone through this process of being decrypted, checked, held for a variable length amount of time, passed to another mix node, and then all of your packets have to essentially reagregate because this is by packet by packet, right? So like if you send 10 packets with the payload inside it, they will go through different mix nodes each one of them, right? So they all have to then be reaggregated um at the exit gateway. So the exit gateway, it gets all of these packets. It unwraps another layer and it goes, okay, great.

I can actually finally now deliver this to the client who app can then do something with this traffic that has kind of um been sent to it. And this is basically like the same thing has happened with the um with your connection to your entry gateway, but in reverse. Um, so I don't think we need to like go too deep into it, but now we get back to unlinkability, but also usability, right? Because it's like, well, how do you reply? How do you reply without doxing the person like doxing yourself?

Because most of the time you are going to want to actually be sending a message to someone so they can do something with it and get back to you, right? And this is where our anonymous reply scheme comes in. So we basically have um the anonymous reply system that we use which is kind of the key for unlinkability over time, right? Because the concept of linkability between two peers is predicated on the fact that you communicate with each other more than once, right? It's this idea that like, okay, cool.

Well, if I'm like always sending uh if we imagine that this is like I don't know like an HTTP server or something, right? And it's like, well, if you're always if the same person is always sending a request to that server at like I don't know 9:00 in the morning, then even if you don't know what the actual contents of um even if you don't know what the contents of the payload are or you don't know where it's coming from, you still start to build up like some pattern where you're like, "Okay, cool. there is someone who is like starting to do this at a particular time every day. Maybe they live in a time zone where like that's when you kind of wake up and turn your computer on. Like all of these kind of like small which sounds really inconsequential, but when you start combining those like bits of data that are like aggregated in these enormous data sets, they can actually become like quite powerful tools of DN.

So I've just like we've gone through this whole dance. There is a message, there is a payload that's got to this client. It's worked out what to do with it and it now wants to send a reply. We use Serbs which are single-use reply box. And what these basically are is the client, the sending client will essentially send like uh like a pre-addressed set of letters back to itself, right?

Along with those messages that it's sending out. And the receiver of that request, so our client on the right hand side, um then basically has this pre-ress set of letters that it can't see the address of, but it can write to the payload to because the headers, so the routting information is premputed, then the receiver never actually knows the address that it's like writing a response to, right? Because we have this kind of multiple encry because we have everything multiply encrypted. um all it can see is the first hop back into the mixet from its perspective which is its own gateway. So nothing is being leaked there in terms of um in terms of actually being able to reply like properly to people.

The flow of this again is yeah so your sender the one on the left hand side with its messages it will create a bunch of like precomputed uh sphinx packet headers and it will send those along with the messages that it's wanting to send anyway right so the kind of the HTTP request payload it'll come with all of these premputed uh headers these pre-addressed letters kind of along with it'll travel through the mixtap And you know in this situation that's kind of outlined here then maybe your client on the right hand side actually goes oh well you know I wanted to write I don't know 200 bytes of data but I only have enough sphinx packets to write 150 bytes of data. Um what do I do now? And what actually happens then is you then use one of these precomputed packets to send it back through the mixet with a request for more subs that are then sent back through the mixet. And then you have enough you have enough space you have enough like space in your envelopes. You have enough like payload space to probably write the response that you want to give back and then it travels all the way back.

Right? So there's also a balance here as well to be had between like how many swings packets you send with every message with every request right um because that costs you time and energy because you have to you know you have to go through the cryptographic operations of like actually like root encrypting these headers. Um, but if you don't send enough, then you also have this kind of you have an additional like full round trip through the mixet worth of latency, right? And timeouts are um a very present thing when you're using the mixet and trying to kind of integrate it into existing software as we'll see a little bit later. Okay, so that was Liby2P, that was the mix net and now we'll talk about um what putting them together kind of gives us, right?

So the transport itself is basically centers around this kind of like abstract like connection object in a way that a lot of the work is trying to like emulate more traditional connections so that the upstream apps that are actually consuming and using this transport don't really have to think about the mixet as much as possible. Right? Um there's a couple of quirks of why this isn't completely seamless right now but there is stuff that we can do for that as well. and the two kind of like key features with regards to anonymity and unlinkability that we've added right so you can kind of think of them usually I talk about like the network level and the app level but the app level in this case is the behavior part of whatever uh li2p stuff you're running right so if the transport is um basically how you send bytes between people then the behavior is what bytes you send and to You can kind of think of it like that. So on the networking level, like I said, we had anonymous replies with subs.

Um what this means in the peer-to-peer context is your you will have a listener. you'll have like there will be some address maybe it's a boot node or something like this that um and that address will have been shared with you either through a broadcast mechanism like a distributed hash table or like uh out of band right what it means is that like your dialers so the person on so the person on the left hand side we can think of as the dialer and this guy's the receiver um like the the receivers's address NIM address has to be brought broadcast somehow. So there's a way of rooting traffic to them. But and this is one of the key differences like usually in a peer-to-peer context you kind of as soon as your dialer talks to your listener then they both have this like symmetric view of who they're actually talking to, right? But as soon as you you have anonymous replies in here, then you are kind of creating somewhat of a knowledge asymmetry where the listener gets valid responses and does something with them, but it doesn't build up an idea of like who it's talking to in terms of who is dialing it.

And um so that happens with anonymous replies. On the liptt level itself, we've had to kind of emulate something like this. So usually nodes have a like a long lived single identity over time which is usually just like a public key. Um and in certain frameworks like noise and stuff like this this is used for like message authentication. But if you kind of, you know, again looking at this and looking at like the linkability over time, then even though you might not know the IP address of like the person that's dialing you, if it's a consistent peer ID over time, then you start building up a pattern of information about them, right?

And that's somewhat it doesn't completely negate the point but it's another vector of like being able to create patterns from data that you observe on the network. So what we have done for this is actually every time you make a connection with a pier you actually regenerate a new pier ID. So you kind of like you um and then when you combine these two things basically you could have boot nodes or in the case of Celestia data availability nodes right full nodes where they get a request for um hey can I have these fragments of a block to verify that they're right right and um it could be two people talking to them a 100 times or one person talking to them 200 times there's no way of actually telling um how many people or like how many different peers or like that are actually run by the same kind of entity um are actually being talked to. So yeah and what does the transport do in very standard way with low PCB transport is used for the creation of a swarm multipplexing and everything is handled by that and we have also had to h have to have had to add the uh a nim specific kind of address format right so on a very high level Yeah. I thought they were there.

Here we go. They're actually here. Um, so yeah. So like Okay. Yeah, exactly.

So why is that actually like practically important as opposed to just being like a kind of an abstract privacy ideal? There's a whole kind of set of attacks that are particular to peer-to-peer systems, right? where you're actually the the peer-to-peer system itself is kind of like assuming or relying on the fact that you start building up this kind of larger view of the network around you, right? And because all nodes are not created equal in these peer-to-peer things, you know, based on their functionality, maybe it's we're talking about boot nodes or in the case of Celestia, we're talking about full nodes that are um should I like briefly outline data availability sampling just so everyone's on the same page or like is everyone kind of okay with that the concept of it? Okay.

All right. Sick. Um, so yeah, the basically like all like knowledge attacks in peer-to-peer systems, right? There might be Eclipse attacks, selective disclosure attacks, all of this kind of stuff is based on the idea that for whatever reason, um, Gy is a full node. I'm requesting, hey, could I have these like fragments of blocks because I want to verify that these things actually exist, right?

And if you're able to um if you're able to build up a pattern or at least identify who that request is coming from, that's when as a malicious full node, you might be able to make the decision that like actually um I'm actually going to give you like an incorrect view of the network. Oh no. So the swarm is um the swarm is basically just the name for like the uh abstraction that uh lib P2P uses and that's kind of like in your code that is basically the combination of your like transport. So, you know, what transport protocols you want to talk plus the behaviors that you want to talk and by behavior um you know, you might just be running something that like only wants to speak gossip up or something like this or just ping or you know, you might be running a node that runs like the identify protocol because you're just helping other nodes identify themselves, right? And that's kind of think of the swarm as just like a that's that's the abstraction that kind of handles all of that, right?

And uh it's basically the thing that you're like your business logic so to speak of your app is kind of piping traffic in and out of. Yeah, I suppose basically yeah the kind of the quirks of this right um is that you are creating like I've already said this like asymmetric peer knowledge between people right which is somewhat different to how peer-to-p peer networking kind of usually works and there are some pros of this right so knowledge attacks the idea that like as I get a request test because I can tell who the request is coming from. I can alter the information that I give them. So I could give them um an incorrect um or I could I could say okay well I know that like there are these certain fragments of a block that do exist so I'll just give people that and then they won't be able to tell that actually I lied about having like a full copy of a block. Or if you're thinking about networking in the case of like a distributed hash table, then you know um GI is a malicious boot node and I could go oh hey like who who else is in the network?

What's going on? and she could give me a an incorrect view of the rest of the network, which means that then basically I'm only rooting my information through peers that she actually runs or all of these kind of like knowledge based attacks rely on kind of rely on the fact unless you're just like trying to sew chaos. If you're actually trying to do something directed and especially kind of like set up the situation for more activebased deonymization attacks, you kind of have to like get people to use your infrastructure first, right? So that you can start trying to find patterns in the data that moves through it. And by adding the kind of attribute of unlinkability to the bitto-sp network using the NIM transport, you protect against this because the ability to actually identify individuals over time is precluded.

However, there's some kind of open questions about what this brings up, right? Because, you know, um does it affect the I suppose PET penis of the system, right? Are you is the creation of this kind of dialer listener hierarchy or people who are willing to kind of broadcast their address to be used for whatever boot nodes data availability something or something. Um does that kind of affect the pizza Venus and how does it so do that? Um distributed hashts then become kind of interesting.

Usually people use hashts for both discovering other peers finding out who is around them and also actually being able to then route their traffic to them. we would only really use a distributed hasht for like peer discovery because the nim client does its own routting and you're kind of just adding in this like extra complexity to birectional interactions or maybe even stopping some of them. Um, so these are kind of open quirks and questions that come up and are some of them will be probably like mitigatable, but this is the kind of from this proof of concept of like having an unlinkable peer-to-peer transport um that's come up kind of in our in our work. Yes. And one of the kind of pros of how we've done this or like one of the pros of lip anyway is that by doing this you're actually you don't like fragment the network at all.

Right? So um because lip has this concept of circuit relays. It basically means that you can have like a pair that will you know um maybe it speaks both TCP and NIM and I as a N I as a NIM pair want to speak to the TCP pair. it will kind of like take that packet for me and then forward it on. And the nice thing about this is kind of going back to the um the dappled sunlight metaphor that was being used before.

Then what you're actually allowing for is you're not saying okay well like actually to make this work we need to have the entire network like move wholesale or split in half um to kind of exist in this uh in in the kind of privacy context. you can just slowly start kind of like adding nodes to it and those kind of you know darker patches of uh can get of shade can get bigger uh but it can still interact uh outside of itself and um interact with I suppose like clear net is the way to think about it so um yes on the functional side on the devx side I am devril after all uh adding a transport basically means that like most devs don't really have to think about it you don't have to know about how the mix net works and because peer-to-peer traffic is already uh async then timing delays no streaming and stuff kind of is a bit nicer than comparative uh comparative like stream based applications. That said, timeouts are um are still a bit of a problem, right? because you can't by adding in all of this additional latency on the networking level then you are adding a bunch of latency that even though it might not preclude the technical side of stuff so like handshakes and all of this um a lot of your upstream software has assumptions about internet connectivity and the speed of light and how that then relates to something like a reputation system. So um in the Lighthouse consensus client then one of the ways that it builds up not just a map of who's around it but actually then adds a reputation score to those people right is based on pings.

So it just is like okay I'm just pinging all of the peers around me and based on the return you know the latency of the full path that you know you send a ping and you get a pong then you can go okay cool well they're they're more they're more responsive they're more reactive they're like set up in a way that's um they have good connectivity right and as soon as you start like adding in you know if you had like a bunch of Lighthouse consensus clients that were using the mixet even if they were using like via the circuit relays were able to kind of uh talk to other Lighthouse clients, they would seem from the perspective from the assumptions of that code that actually like oh well their reputation must be low their connectivity must actually be like a bit a bit sketchy right which is not necessarily the case. Um now consensus especially like Ethereum consensus is a very tight turnaround on a lot of that and that's kind of I suppose like adding this in in on on hard mode. Um we will see it's to be seen whether this will become an issue with Celestia nodes and ultimately like most timeout stuff is just like is a mitigatable problem but I wanted to bring this slide up because um I suppose to get across the idea that like actually like privacy even if you kind of whack the privacy layer into something like a transport which most of the time developers won't have to think about um it's not like a silver bullet. you can't just whack everything through it and nothing else changes kind of upstream of it and yes so future dev um so at the moment this is being done in Rust we're also going to do it in go and um I'm trying to look as well into like decreasing the session linkability um between these connections you know like through the through the pier even though you can't retain linkability between different connections because you regenerate the peer ID Um, I'm also looking into how you would maybe decrease that within a connection session itself. So if anyone thinks about this stuff, go for it.

Oh no. Oh, okay. That's all right. Um, yes. And then the next step will be making a version of the Cadmia DHT that um allows you to peer discovery over the mix.

So, the kind of chat demo code, which is actually still running on my laptop because I decided to be a massochist and do a demo on conference Wi-Fi today. Um, which we can all play with afterwards or like after I finish talking. Um yeah, basically like the next thing would be allowing for peer discovery um over the mixnet as well and like working out how that will work with a distributed h table like cadmia and I'm hoping it will be relatively easy because we're just using it for discovery. routting is done by the mixet clients themselves and then there's some so some kind of pre some kind of early summer R&D which we will also hopefully be having um bit of a devet for in the coming months is uh some work we're doing on what we call the Lewis protocol and that is basically a set of protocol changes to allow us to build a lot of concurrency assumptions into the clients into like the actual client itself. All right.

So, which will remove the like massively reduce the complexity of the code that you as a developer have to you like work with if you want to build with our SDK, right? Um, and what this also gives us is plug is like we're following on from David Field's Turbo Tunnel paper which is this idea of like having a pluggable transport. So really like pulling apart or like having a set of different potential transports that your client can use for its initial connection to the mixer, right? Like at the moment it's just a websocket and websockets in some places are uh both easy to spot and easy to sensor or people don't like you making websockets, right? So it's this idea of like kind of abstracting away the actual type of connection you make from the functionality of the client itself.

Um, yeah. So, that's the kind of future dev stuff. Now, these are the links. So, if people want to try out and join the gossip sub chat that currently has four people connected, um, and is working on conference Wi-Fi, which I'm quite happy about because I was up until 2 o'clock in the morning fixing it. Um, you can join there.

There's instructions on the readme um and the repo and there is a subsection which is called protocolberg workshop chat which basically like gives you the command that you have to run uh to do that and now if there are any other questions or anything then we can do those otherwise whoever wants to like um have a go at using the P2P gossip subub over the mixnet chat um can and ask questions. Uh oh, sorry. Yeah, I got rid of the QR code, didn't I? There we go. Yeah.

And so the like the key um Yep. Um yes. So yeah, we we do we have a TypeScript we have a TypeScript SDK as well. um which um needs is maybe like a little less feature fall than our Rust SDK. Um also I don't I mostly focus on the rest SDK.

So I'm like I'm com I'm comfy to work with that yet. You said it, not me. Um so yeah, I kind of skip past that one. Um yeah, I mean one of the like the kind of the protocol changes that we're also talking about um are you know it we're focusing on it for sensitive resistance but like um actually having the ability to like choose which transport you're using based on the environment you're using does also open it up for like more ex more environments as well because some environments much like browsers for for like a good reason don't really want your process like randomly opening websocket connections outside of the browser window, right? because it kind of somewhat is a bit of a sketchy security model.

Um but yeah, going back to the lighthouse stuff then we so there's kind of there's there's actually the difference between that and the Celestia data availability sampling is maybe interesting to draw the distinction for here because with creating like unlinkable data availability sampling what you're basically doing is you're preluding the ability for a node to go okay well I kind of can roughly identify who you are, so I'm going to give you false information, right? Um, for whatever like economic reason that node might do it, which is like, you know, they didn't properly store and actually have the data available, but they don't want everyone to know that. Um, and they're because they're whatever saving on money, right, by running a smaller uh server. Whereas in the case of the Lighthouse client stuff, actually, it's a censorship resistant one. So there was a study where basically from running a set of client from running a set of consensus clients um you could like fairly trivially start linking the IP address with the public key of an Ethereum validator, right?

And the the problem there or like the problem that that opened up was that then you're basically then able to because you can tell who is going to be the next block producer, you could then uh dodos them. So you could essentially kind of like smush or and you could you could do them to the extent that like any of their requests outside would time out which would then preclude them from actually generating the block. So you could actually slowly over time basically like form the validator set that you wanted over time or you could push out validators that you like didn't like for whatever reason. Um, so that was that's kind of like a different uh the the different kind of attack there which is really like based on the linkability of your IP address with your public key which is kind of um a similar you know like that's what we were already talking about with like these two core unlinkability attributes on the network level and the P2P level. Any more questions?

Um also yeah going to be around all weekend and also at the web three privacy now hackathon. So if anyone has other questions then come to them then just come say hi. Also is anyone trying out the uh the chat? Is anyone joined or no? Is compiling Rust on conference Wi-Fi like too much to ask for everyone?

Which is fair dudes.