Hashing It Out
Hashing It Out

Episode 117 · 2 months ago

Network infrastructure Pt. 2

ABOUT THIS EPISODE

Hashing It Out is continuing its series on blockchain infrastructure with the Network layer.

In this episode, Corey, Dee and Jessie talk to Assistant Professor of electrical and computer engineering at Carnegie Mellon University, Giulia Fanti & member of the Vac research development group at Status, Hanno Cornelius about privacy and security in the network layer.

We didn't really introduce ourselves, should we? They know who I am, they know me. Welcome to the hashing it out podcast, where we talked to the tech innovators behind blockchain infrastructure and decentralized networks. Your hosts are Dr Corey Petty, currently doing research at status and waiting for other people to keep up. there. Definitely the cat. Sound like that standard, like Jesse Santiago, a former electrical engineer now working on decentralized storage at status. Okay, I caught I caught a little bit of it, and with a deep voice and the deep questions, Dee Ferguson, I got a question and that's how I always like to start. More questions, by the way, and I'm the hashing it out show runner, Christian no Gara, whoa okay, sorry, Corey, continue, continue. That's a shameful this is part two of our episode on the network layer, with guests Julia Fonte and clear. At least it became clear from both of their conversations that there's quite a bit going on before you get to the part about blockchains that most people think about, which is like consensus and everything after that. So we're like this, this, this whole series is about everything before that, basically, or this this part of the series, is the part of the UH technology that is required to build these networks. That happens before most of the stuff everyone thinks about and there's quite a bit of implications on how you do that, like security, how much how much resources? Your note takes, all kinds of things, and I thought that was it's interesting to hear from both people that it became quite clear like, Oh yeah, there's quite a bit going on that like you have to take into consideration when you're trying to build these networks. That happens really, really early, and this like technology stack at all. Um. I mean my takeaway from Julie, the interview with Julia was it was it's just so surprisingly little that is thought goes in, like you kind of open your statement with Corey, like surprisingly little thought is in the layers that were kind of like trying to discover more about the hardware layer and the network layer, and I don't think that most people even developing on this tech are you thinking that? Low on the stack? They're just like, oh, the Internet is working, then I guess my thing is gonna work. Right. They don't. I don't think anybody's thinking on that, that layer when they're developing these these technologies. So it's crazy to me that we're trying to develop open systems on closed systems. I don't know that it seems like backwards. Any sense. is any sense? There are, there are plenty of people that do think about this and care about it. It's just not very hyped up. Like there's no value aggregation in the pure, pure network layer, right so, like no one's talking about that, but it has so many drastic complications on where the value actually is, where people are building applications and all this other stuff that like change the way they build things or what they can do with the things that they build. Um based on the good over decisions people make in the very, very beginning of building the network, right so, like if you look at ethereum as an example, they made a bunch of choices that then made the ethereum network and now there's certain things you can't do because of those choices early, early, early on, and I think only until recently with like the ethereum merge and with the birth of other networks outside of Bitcoin ethereum that are trying to kind of take attention away building, doing different things. They've learned from a lot of those lessons and they think more about kind of how to do this based on is it gonna influence how well this network works later on when it grows and it's successful? Do you think it will influence a Jesse? Jesse is reading something else. Yes, he's not locked in right now. What I what I remember from the Julia Conversation is she works on Dandelion Right. That is that is true. But the problem with that is that that's part of the second episode. So we're given the card away before the horse. This. That's how we do. You just give it all away. Yeah, we give it away. Um, I guess my my strongest takeaway, and maybe I hope this isn't in the second part, was like when I asked her straight...

...up, like these things are never a private secure and she's like no, you just gotta live with that fact. And I think, like it's not wrong. And like I always like to think of like I try to go back and I tried to like hopping the time machine in my mind, and it's like mail was probably a risk one day, like a long time ago. You give somebody an envelope and you're like please, get this to the person I love, please, and they're like yeah, and they're like we're okay, man, we're gonna do our best and like and you're also like and don't open it and he'll give it to the wrong person and that's why they used to seal it with wax. Right. Yeah, I know, but you can definitely melt wax and then read and then you know what I'm saying. Like it's just funny that the very second something like leaves, there's trust and hope that is involved, and it doesn't matter what system you're on. That's just human stuff. You have cipher and then you're like, you know, encrypt the message. That's what. That's what, like most of the conversation, I think, with Hannah was, was like there's always crazy tradeoffs with building peer to peer networks and it's really hard to get all the points or like, I guess, even just balance all the things you actually want in terms of performance and privacy and security and scalability. I guess it falls under performance, but like you have to try to do all these various knobs you can turn and, depending on what you're trying to do, with the network you it's it's still even like hard to turn on the knobs correctly such that you get a network that gives you everything you never want. There's gonna be trade offs. How do you like messaging to like many, many notes, like how do you have a like a uh, like in Matrix? Right, Matrix Chat Messaging Service, whatever. Can can you have like a thousand people in like a chat room? Yeah, that's okay. Well, you're you're leveraging federated servers. So it's not like it's Peter Pier is just kind of distributed. It's it's federated, is the technic term for it. So it's a it's a most of what Waku is, which is what was an engineer for, is a suite of different messaging protocols so that you can set up peer to peer networks with kind of the bells and whistles that you want and not the ones you don't want. So it's it's like it's a stack of different protocols that work in different contexts based on the type of peer to peer network you'd like to build. In the last ten years, more than one billion dollars worth of CRYPTO has been lost or stolen specifically because of port key management. Scams and hackers are new sponsor. The ZENDO crypto wallet is a game changer, bringing wallet security to a whole new level. Check out zend go and you'll find an on chain crypto wallet with no private keybone her ability, leveraging advanced cryptography called MPC, which until now had only been available to multibillion dollar institutions. And don't forget that Zen go has legendary in APP seven live support with real humans. Zen Go is a secure web three wallet and your crypto N F T S and assets are fully recoverable using a biometric recovery kit. Get started at Zendgo DOT com, slash T B P pod and use the code T B P pod to get twenty dollars back on your first purchase of two hundred dollars or more. That's Z N G O dot com, slash T B P P o d. that's code T B P pod for twenty dollars back on your first purchase of two hundred dollars or more. Terms and conditions apply. C Site for details. Part two of this episode focuses on privacy and security in the network layer. You mentioned Um that a lot of your study focus was on privacy within these networks and that it's a difficult problem to solve. If you have more centralized infrastructure, you have the ability to censor and monitors all the notes of the network and maybe keep them from misbehaving in ways like that. Another potential trade off with that type of infrastructure is also privacy. So the person who's routing all these messages or the central hub for these messages ends up being able to see what all of them are in some circumstances. Uh. How how is privacy difficult in these peer to peer networks and what are the current methods for trying to solve that or make it or make it more improved? Yeah, so privacy in peer to peer networks is kind of a subtle question. Um. So let me first explain how an attacker could potentially compromise your privacy in a peer to peer network. So, Um, today, in many peer to peer networks, in blockchains, Um, the way that transactions are broadcasted. It...

...is through a process Um that has different names. That can be called flooding or diffusion, but the idea is basically that the transaction is going to spread like a ripple in a pond. Okay, so if I create a transaction, if I go to the coffee shop, I create a transaction, I'm going to pass that transaction to my peers or my neighbors in this network and they're going to pass it to their neighbors and so forth. And so this transaction starts basically propagating over over the underlying network. And the thing to keep in mind if you if we go back to this ripple analogy, Um, is that if you, if you look at the ripples on a pond, you can kind of figure out where the center was, where, like where the initial uh pebble dropped, for example, because of the symmetry of how how ripples are structured. Similarly, in appeer to peer network, if you UM launch or create a transaction and start broadcasting it, if an adversary is observing you at from different vantage points in the network, they can sometimes figure out which Ip address originated the transaction. Uh, and this can be a privacy concern because that would allow the adversary to link your public key, which is contained in the transaction message, to your Ip address Um, which is your your network identifier. Um, and Ip addresses UH IP addresses are not sufficient to link you to a to a specific person, but they can in many cases be used to identify your location and in some cases they can be used to link a user to uh to their human identity. So this is kind of a subtle attack that is possible. Um, is mathematically possible and they're been some practical papers that showed that this can be done in practice to to varying degrees of success. Um. So this is one of the main privacy risks that come in current peer to peer networks, in blockchain networks Um. In terms of solutions to this problem, there's been a few different approaches. One approach is to use basically anonymization services like tour Um that would allow you to connect to the peer to peer network from somebody else's basically somebody else's Ip address. This is generally effective but can be attacked if, if your attacker manages to somehow control the exit nodes and tour Um and can link your h your cryptocurrency transaction to your Ip address. Another approach that we've looked at in our group is to change the routing protocols in peer to peer networks Um. So, like we worked on a protocol called Dandelion that tries to change the way that transactions are propagated over the peer to peer networks. So instead of spreading like a ripple, which we said was symmetric and it's easy to identify the the center of a ripple, instead we propagated asymmetrically. So like it, it propagates over a line in some random direction and then after a certain number of hops on the network, then it starts propagating like like a ripple. Um. And so we did some theoretical analysis showing that this Dandelion Protocol has better privacy properties than just spreading symmetrically, like like what's done today. Um. In general, there have been efforts in various block chains to try to address the privacy concerns, Um, that that stem from the peer to peer network. Um. But it is legitimately, I think it a pretty problem. Yeah, it feels like most of the research that I've looked at completely ignores the peer to peer layer. Um. There has been quite a bit of work in some of the underlying protocols with with some of the peer to peer work, like noise and ways in which you can make more secure handshakes, but the gossip layer and how you propagate the message and the underlying d h t s that are involved and how you do no discovery are like. It doesn't seem like there's a tremendous amount of innovation when compared to the effort going into shielding transactions with zero knowledge, like Z cash and the myriad of other like the zero knowledge roll ups, things like that. So I'm very curious to see what level of innovation is being worked on at a lower layer, because that's where a good portion of the identify information exists, through attaching and a transaction to an IP address and and or, for if...

...you look at like data distribution or like distributed data plays, like I P fs, who's storing what information or painting what information on their node, basically like housing certain types of content and then going after them via the DOS attacks or whatever. Yeah, absolutely, I think I think you're right. Um, for for many years there's basically no attention being paid to the peer to peer network. Um, and I think one thing that a lot of people don't realize is that even if, even if your blockchain is protecting the data in your transaction, for example using zero knowledge proofs, there's still something being leaked. There's something can be leaked at the peer to peer layer, Um, and it's I think it's important to understand what that link is and whether you're okay with that level of privacy leakage. Um. So, yeah, in the last couple of years there has been more attention being paid to this problem, but I think at the end of the day, one of the big challenges is that these networks are open, which means that, you know, an adversary can add as many notes as they want to the peer to peer network. There's nothing fundamentally preventing them from doing that, and that makes it difficult to propose solutions that are going to be water tight. Um. Yeah, like I haven't seen anything yet that that is completely resistant, too, to all the types of adversarial manipulation that that are possible in principle. Um. So you're building, say you're building a blockchain network from scratching and try to get launched, what kind of, I guess, give and take do you make when it comes to building that networking layer? Like, how private is private? How like, in order to make it usable, how would you try to make some, I guess, sacrifices to to have a network that's operable for at scale. Mhm Um, yeah, there's a lot of layers to that question. Um, I think what a lot of projects have done. Um, at least for a while, a lot of projects were basically using the same networking stack that bitcoin was using. And, you know, I don't know what the developers were thinking internally, but my guests would be that it was from a convenient standpoint, um, like there's a there's a working networking stack that uh, that is reliable and has been used for a major cryptocurrency. Um, there was no, there was not a compelling enough reason to like roll something from scratch. and to some extent that Um, that's the sense in which I think prior product jets have prioritized usability. Uh. It's like usability for for the developers who are like ease of implementation for developers who have to maintain this thing uh and make sure that it's robust resilient to uh, peer turn notes coming in, coming in and dropping out and so forth. So in that sense, uh, you know, I think there can be a lot of practical benefits to just taking taking networking stacks that already exists. Um, for those projects that do want to prioritize privacy. There have been efforts to build cryptographic techniques into the peer to peer layer, into the peer to peer network, in order to provide privacy, and these have been Um. These provide strong privacy guarantees, but they're also like fairly, fairly complex implementation projects. A few, a few blockchains have implemented dandelion, the work that I mentioned earlier, and I would say that's like a it's like an intermediate privacy level. So like on the one if, on the one hand, you have a fully private network, uh, and on the other hand you have the current flooding mechanism that I mentioned. The Dandelion is somewhere in between. It's not um it's not going to protect against every attack, but it gives you some basic protection against like blanket adversaries who are just trying to de anonymize as many notes as they can. So yeah, but I guess the short answer to your question is that there's really a lot of knobs to turn when you're designing a peer to peer network, or any network Um, and I think designing it in such a way that your network remains robust and resilient is kind of delicate and that typically takes priority over things like privacy. MM HMM. So it's never and you just have to understand that if you're if you're using the network. Yeah, for the...

...for the project I've seen, that's the case. I think it can be, but it's it's with all of these with every knob you turn, if you go full tilt private, there's a bunch of trade offs you have to you have to take and so Um, which increases a lot of different um difficulties with running the network in terms of scalability. So, if you like, one of these things that we haven't discussed yet is just even message complexity. So if you go full flood like, say, the difference between perfectly routed centralized architecture, where I send a message to a server, it sends it to the person I want to send it to, there's some one, basically one hop or the exact peer to peer, like direct communication, which just I talked directly that person. You don't have this Um message being delivered to a bunch of different nodes that have to process it and remove resentence, on and so forth. So like flooding, which is this thing where, like, I send it to one person, they send it to everyone they know. They send it to everyone they know. You end up with this a lot of dope location of messages being processed across the entire network and everything in between, and so flooding in some circumstances allows you to kind of D anonymize who sent a message, because if the message looks the same from every note, you don't really know who sent it in the first place. But you have this trade off of a bunch more messages being propagated across the network, which makes it more difficult for the network to scale to more and more and more nodes or more and more and more messages, because at some point a given piece of hardware can't process that many messages in a timeframe. And so, like what she says, there's a lot of knobs to turn, and so what you're looking to do is figure out what your needs are for the network and then make something that's appropriate for that network. And in some cases, if your needs are incredibly private, you may end up fundamentally limiting the scale of that network can go to. Is that a reasonable thing to say, Julia? Yeah, in general, the trade off with like more the trade off with privacies typically, Um Yeah, utility, uh, so, latency, for example, overhead, Um yeah, message complexity, like you said. Yeah. So I think your characterization is just keep spot on, but that's typically the tradeoff that ends up appearing. Ideally, like what would be, Um, a good balance between some level of privacy? I guess, I guess, maybe I'll go in this direction of the question. What projects have you seen that are are ones that implement adequate privacy in the space? Sorry, actually, could I circle back to the question? I think one interesting thing about what you mentioned is that, Um, like maybe if you care more about privacy, maybe you might think that, uh, you don't want to pass messages to everybody in the network. But this starts having in really interesting interplay with the consensus protocols that you're running, which is at a higher layer. Um, but actually, like the consensus protocol, for example, in a lot of in a lot of cryptocurrencies require all of the miners to get access to a particular transaction and in theory you're not supposed to know, like. Okay, in practice maybe we do, but at least in principle, if you're if you don't know who the miners are, there you can't really do anything except broadcast the transaction to everyone. Um. So I think I think there's some really interesting open research questions around trying to understand what what is the interplay between designing a network that is both effective in the sense that it it satisfies the communication needs of the of then blockchain system as a whole Um, while also accounting for other desired properties, like privacy, like security, and that has not been the case. So typically the network is designed kind of in isolation. It's not designed with the consensus mechanism in mind. That actually makes a lot of sense and something that I don't think people pay much attention to. Like if the message propagation takes longer than what your block time is supposed to be for blockchains, then you've basically ruined the ability for your network to operate because, like, adding a bunch of latency at the networking layer is going to impact the time in which you can come to consensus, because everyone needs to get messages or propagate messages out once they say, for instance, I found a block for a bitcoin right that whole block uh space argument was founded on the effort it's going to take to propagate a block once found and the disadvantage that geographically far people from that propagation will have in trying to find the next block. Right, and so they wanted to keep the blocks, the blocks to very small. So what you're...

...propagating is something very small so that you minimize that time that someone has when they've received the new block and are able to start processing on top of that one to find the next one, so that we don't have these like unfair games where people can find a block, distribute it and then find a new block faster than other people can get the previous one to start working on the new one and so like. There's those are additional trade offs when you start talking about a blockchain network, when you're thinking about a consensus mechanism and its requirements as well. So if you start adding a bunch of privacy features at the networking layer, you may end up ruining the desired consistent mechanism and the layers above or or a bunch of other things that fall on top of it. Yeah, that's that's absolutely right. That's a great point Um, and this is partially why, like, just increasing the block size isn't isn't going to solve the throughput problems in bitcoin because it has security implications the network takes. When it takes longer to propagate a block, Um, like you said, increases potential for forking, which has has security implications down the line. So if you want to satisfy a particular security level, Um, you need to take into account the latency and the throughput of your underlying network. And we did. We did some work a couple of years back on trying to design consensus protocols that are kind of tailored to the capabilities of your network. Um. But I think what I haven't seen so much is is the reverse, which is networking protocols that are taking more into account the or like co designing the networking protocol with the with the consensus layer. Can you guys mentioned something and I just need some clarity. Can you like add privacy features in at different layers? So then would they make the most sense to like added in as late as possible? Like so it's a it's tempting to think that and that is actually the technique or the approach that has been taken in practice. So, like Um, a lot of the zero knowledge proofs Um, like other other privacy techniques, have mostly been added that the consensus layer. So they'll they'll like cryptographically protect the content of a transaction. Um. But I think one thing that a lot of people maybe don't realize is that even if you do that, you're still leaking. Um, you can still leak information from the network layer. Maybe not as much, but there's there's still something. How has your focus on privacy, um given you, like what color glasses are you? Do you wear when you look at the solutions like that, when, like it's like the purpose of implementing digital currencies using block technology is, in my opinion, an Athema to like a privacy focus. Okay, how do you how do you see the decisions that they've made when you know something like that? Yeah, I think, Um, part of the challenge is that there is a very pervasive view among regulators. I think that building in privacy capabilities into these technologies is is going to be extremely complex and it's going to prevent them from being able to do their jobs. Um. And so I think, yeah, it's a it's a little it's concerning from a privacy standpoint to think of one organization having access to that level of detail in terms of financial transactions and so I think it's a a good opportunity for privacy researchers and privacy advocates to to propose solutions that are technically feasible while still, Um, while still permitting some level of oversight. Right, like there are m l regulations that need to be that need to be respected. Um. So can can we propose solutions that both provide compliance while still offering the end users of these systems at some level of privacy? Because if we if that doesn't happen, and basically the discussion around these cbdcs is progressing very quickly, Um, and they've been deployed in a number of countries already. So if we don't have that discussion, there's a very real risk that these systems may end up being quite centralized and exposing a lot of this data to, uh, to like one organization within the government. So it's a little alarming, but I think it's a it's a good opportunity to try to do something as technologists and try to propose alternative solutions. How does that work, where the best privacy solution is the one that the government doesn't actually want for...

...its people? Mum, I think please. Oh sorry, I was like. I'll tell you how it works. Go ahead, sorry, my my question. My answer is not gonna be as a ticulate as you. I mean, I think to some extent there is a desire among there is a desire to provide some level of privacy, at least, at the very least. They're giving lip service to to this, and I think that a number of people who are trying to deploy the cbdcs actually do care or do think that privacy is important, um, but just aren't it's not clear right now, Um, how feasible it is to deploy these technologies. So I would like to think, I would like to think that there are people on the inside, as it were, who are trying to push for privacy conscious designs, Um, and we've seen some evidence of that in terms of like the white papers that are coming out from central banks on these currencies that at least allude to privacy enhancing technologies, even if the pilot itself maybe isn't using the full range of capabilities that it could. Um. So I'm hopeful that that discussion will continue to evolve and and that Um, yeah, and that we'll see that we'll see solutions that actually are providing some meaningful level of privacy Um, but I think it's still very, very new. It remains to be seen. Have you heard about draft kings marketplace? It's the place to snag the latest digital collectibles across sports, entertainment and culture. Draft Kings has really their first ever N F T fantasy game, rainmakers football. It's the only n F T fantasy game licensed by the NFL P a. Now you can collect the hottest player card N F T s while playing free for millions in prizes. Right now, everyone can get their first full roster starter pack for free, and playing is simple. Buy Cell Bid and win player card N F T s of the biggest names in the game through regular drops and auctions on draft kings marketplace. Craft lineups have athletes from your n f t collection and earn points for touchdowns, receptions and more. Just like daily fantasy football, build your N F t franchise and enter free rainmakers football contest all season long to compete for millions in prizes. Download the draft kings daily fantasy APP now and sign up with Promo Code Bitcoin. Click the rainmaker's tile and opt in to get your first full roster starter pack for Free, plus play for millions and prizes all football season and build the ultimate n f t fantasy franchise with rainmakers football. That's Promo Code. Bitcoin build play when only at draftkings. Contest entries dependent on type and number of N F T S helped. Eligibility restrictions apply, void where prohibited. See draftkings dot com for details. You mentioned the the benefits of of why peer peer networks are used across Um, blockchain networks or distributed networks, or whatever you want to call them Um. But there's there's subtle different there's subtle difficulties. You mentioned that it's difficult to design protocols that work efficiently. What are these trade offs that that exists when switching over to peer pure architecture, and why is that difficulty, which then leads to these centralizing forces when people take shortcuts? Right, okay, so one thing that you need to do if you want to create an open access network is Um. Bis need to know where to connect. Right Um. If you are I'll stand just a random note, and you want to participate in this particular protocol, in the particular network. Um, where do you start? Right Um, and oftentimes the shortcaster people do take that is to either heartcoat or have some list of notes somewhere which then serves as the kind of like bootstrap notes of the entry notes Um to the network. There are various way surrounders, but there's the bootstrapping problem. Is a is a major challenge. Um. What else is it is difficult. Um. How do you create a network that's really scalable if you're gonna say, Um, we want a pe to peer network to be able to grow and grow indefinitely, because we want it to be permission less, um, so that as many people as possible you can grow. How do design protocols in such a way that a new pier joining the network does not add to the total um resource requirement on the existing piers of the network? I would say that is, in a sense, the holy grail of scalability in popeer networks is designing...

...protocols in such a way that that Nupius joining the network Um does not add to the overall resource burden on individual notes. That isn't a big chalet. Um. Security, of course, is a is a massive challenge. Um. Means that most protocols are vulnerable to two notes with militious, malicious intent joining the network Um and not behaving according to protocols. So this could be explicitly hostile behavior, and I know it could pretend to be something else. Or trying to get control of the network is often grouped under civil attacks. They can try and isolate specific notes in the network Um or give certain notes in the network wrong idea of the actual state of the network Um. Is often called eclipse attacks because it is designed to give a specific note or a group of notes to hide the truth of what's happened in the network from those notes so that they can't participate fully. What else? Oh, I think designing from a developer's perspective, designing per protocols provides particular challenge when it comes to maintenance and debugging. Right, I mean the only way to to to really understand what's happening in the network is to simulate the network at scale, which is impossible in many cases because you have to recreate the network Um. So that provides a particular challenge. There's often in pwoper networks a very high churn of users and this creates a lot of noise, and SOP networks have to deal with way more noise Um than normal. Let's call it conventional networks. Um. What else? There's no Um authoritative state of for the network, right. I mean there's only local use of what the state is. And eventually, especially in block to environment, you want to settle on a state that everyone agrees on, but the sticks time Um. So there's always these periods of transition um where appears will have only a partial view of the actual state and the network and you need to design around them. But I would say the most important challenge for US designing protocols Um is two deal with this question of how do you in force, in a sense, notes to do what they should do? How do you how do you Um, I guess incentivized that. I don't want to use the word incentivizing now, but how do you do you incentivize honest pavior in a network? Um, because this is the most vulnerable point. Vulnerable point in networks is the fact that we do rely on Um all notes to follow the rules and there's no central point where we can kind of enforce this Um behavior. I find that interesting, like the whole all the things you just went through are consequences of the layer below consensus. So when we when most people talk about blockchain networks, they're typically talking about Um, the things that are built as a product of consensus. But all of the difficulties, the Um, the scalability issues, the you know, bootstrapping, joining the network, all these things are subject to a layer that's that's completely ignorant of the consensus protocol at hand. This is just a group of a group of computers connecting to each other and passing arbitrary messages to each other, which which corresponds to just chat applications. It's Um distributing data across these things so they can even come to an agreement and begin to perform consensus on something. It's doing the consensus rounds. It's all of these things that are happening at this layer that I think people really neglect when thinking about the difficulties in building blockchain networks. I think it's it's interesting because that's when you think about security and privacy. At this layer, there's a lot of things that come into play as well because, like we talk about the security of Um, a consensus protocol or the privacy of messages being passed around, and once again, people focus on the consensus protocol and not necessarily, like the messages being passed around the network and the burden that has on the people who are participating. Yeah, I agree and I think Um, I don't know if you will agree with me on this, but I think this is the kind of like the neglected talking point when it comes to well blocked chain technology in general. But I also think kind of more positive note that. I mean especially for non technical people, it's it's a little...

...bit easier to wrap your head around the concept Um in terms of decentralization than it is maybe in terms of the cryptographic Um aspects of block gain. I mean, if I speak to people and I try to explain maybe why our block chaine steel with a double spent problem or something, you often get this kind of like glazed overlook and the conflict don't don't really understand where you're going. But if I explain the decentralized aspect of it, it's as if people there's a more immediate grasp of what the advantages they might be. The fact that this seems much more resilient. This seems the fact that there's no central point Um means that the we that collusion is less um possible. You know that and I think that people generally tend to understand that a bit faster. Um, and it also means when we speak about the challenges, I mean in terms of communicating them, Um, getting to an intuitive understanding. Um, it's a little bit easier, which makes no job a little bit easier than that, I think many of your jobs. It's also one of those things, right, it's like if you want to, you want to be, as I don't know, inclusive as possible so that people can run notes in any setting available. So that's that's like browser through a bunch of different programming languages embedded into different applications. Um, just standalone. No, that doesn't do anything. It just sits on a server that's always on on your phone when you're using an application. Like there's all different places you'd like people to be able to connect to a network. But because when you look at each of those different operational environments, are going through a bunch of different technologies. On the on the layer below the overlay, it's Peter Peers and overlay network like that's going to be, you know, five G in or four G or lt, depending on where you are in the world. Um, going through some your your web browser that has to go through the entire disgusting Web Browser Stack that exists today that's constantly changing, Um, depending upon and also depending upon which browser you're actually using, whether it be edge, if you're weird, firefox, chrome, whatever, those are all different, and so like you have to kind of accommodate for all these different people and because of that, you end up with peers in the network that have lived like they're limited in their ability, ability to participate, so that maybe that means that they can only receive messages or they can only make outgoing connections or they're limited in their ability to like process a bunch of transactions at once. And I think Hanad was getting to like trying to come up with the protocols that allow all these people to participate that doesn't make some asymmetric problem throughout the network is really hard. Yes, we're trying to be be, be useful, Um, no matter what the kind of hot ways that you are that you are bring to the able and no matter what the pipe is, Corey that you are that you're using to connect Um. And and this is changing, and I think the reason for this is that we are trying to design mormal to use popre networks. Right Um. It used to be that that most PP networks is a single function and naps, if you go back a little bit further, or or Blockchain, right Um. But what we're trying to design is is something that will be generally useful and be useful to a variety of applications with a variety of different Um kind of profiles in terms of how they use the network. Um. And and for that we also have to look at how people access the network. Um. And they have this Um, I would say. Well, we always speak of the continuum of of possible notes that the network can have, right from the notes that are in extremely restricted environments with very few resources to this very, very strong notes running on them on a virtual service or even even more Um. And we have to design protocols, protocols in such a way that the network is is useful networks with all of these notes without introducing asymmetries. Um, as you've mentioned, that Causes Network detradiation. How does it look like in practical terms? Like, let's say I am in a a developing country, in a city that doesn't have access to, you know, running water or you know, stable electricity, good Internet of any kind. Um. How does it look like if I'm trying to use one of these messaging protocols to, let's say, potentially transact or even just communicate? Um? Does that mean like each like each household might have like a a prepaid smartphone, um that may be able to in awesome sort of APP and and communicate? Okay, yes,...

...so exactly. So what we're trying to do with with work with specifically Um, is we're trying to enumerate those problems. Right. So if you have bad internet connectivity, then one of the things that you will have low band with availability. So we need to design protocols Um that works in low band with environment. Um. You have, of course, a very slower uh CPU. Um. So we need to design protocols that's not a u does not add a lot in terms of processing requirement. Um. And we also need to look at things like intermitted connectivity, so being robust against Um connection dropping all the time. Um. And how we try and do that is we try and expand our protocol suite with protocols that specifically designed to address those issues. Right. So if you have very low band with requirement, you should be able to still subscribe, to receive some messages in the network that you're interested in. Um, but you might not be able to fully participate in a in a true peer to peer manner, in the network crime. But then there's of course a trade off because as soon as you you you lose this this band with requirement, you also, um I've lose some of the privacy and decentralization benefits that you get. But at least we want to give people the option and we want to mitigate or lessen the effects of these trade offs as much as possible. Um. For intimitted connectivity, for example, you need to be able to use Um kind of protocols which you can Um uh, maybe if you want to publish messages to the network or participate in some way that you can have multiple attempts to do that and get some kind of acknowledgement from notes that are actually fully participating the network. Um that, yes, your message has been received or it has been published to the network. Um. So we have designed protocols around these specific issues. Um, and your example. Yes, I mean if if anyone has access to Um, to to a slow old device that can install or run the application in some way, whether it's from a web browser, or mobile browser or whether it's through an APP. Um, they they should be able to connect to the network, even with really slow or intermitted connectivity. Yeah, privacly this. Yes, so privacy, I should have mentioned already when I mentioned the trade offs, right, because privacy is one of the fundamental trade offs that that we have to solve. If you improve, let's say, the scalability in the network and, Um, you get band with requirements way down, may have privacy. There's an extra um dimension to consider, right. Um. So what happens in a peer network, Um, is that, as long as all peers are well connected to all other peers of the network, Um, you can kind of disappear um in the network, in that your messages, maybe that originates from you and that terminated you. So messages that you specifically send and received Um may be obscure because it's simply part of of of the network traffic. Right. But as soon as you do something like explained now, where you are in a sense subscribing to receive only certain messages from the network, where you're asking for acknowledgement to say that you are Um, that your message has been published, but you're not participating in the same way Um is these networks, these notes. Fully participating in the network, you are kind of giving away, Um, both which messages you're interested in receiving and which messages, Um, you are interested in, Um, in publishing. Right. So, then again, there are ways in which we can mitigate this. You can use some kind of anonymization network, mix net Um between you and Um and, let's say, the the fully functioning high band with a renough notes communicating on the pupe network. Um. But then again, you add Um, more latency and more of a bandwidth requirement, right, because those things, Um, uh requires more processing and more bandwidth. Um. Does that make sense? Yeah, so. So if I had like three imaginary levers, security, uh, computation. As a result of increasing the security lever U, then I have, you know,...

...messaging. And if I increase messaging, you know, uh throughput or peers I can connect to, then I increase the computational lever as well. Yeah, so bad with your latency, Um and your privacy or security. But those aren't the synonymous times. But yeah, but yes, so it sounds like it's a real challenge to to provide a decent user experience that's uh, something like a centralized service provides, like in terms of, I don't know, skype or, I don't know. I was going to mention, I don't know why, a o l instant messenger back in the day. But yeah, so how do we get to that point where where you can't really notice the difference as a consumer? Is it hardware gets so good, or is it that we just drop our threshold of what is an adequate minimum for your message? I would say the most work is not in the hardware. Would say it's in the IT's in designing these protocols in a way that makes sense right, and I'm confident that we're getting closer there. Um, and to that point where where people are would call it Um, at least certain applications. Um C bless. I think that would be the word that we would want people to say when they when the use of protocols. Of course Um. This would be the case for certain applications which is easier to get to a point where user experience is acceptable or even good. Um. I think chat applications is a good example of where we can get to that point, because there's sort of traders that we're trying to make. I think is is at a point where they all let at them at a level that is acceptable to people using a chat application. Right. You don't expect, I mean, Um, you know and have the requirements of agd streaming, for example, on a chat application, getting to a point where we can say we decentralize everything, which is, I think, um kind of like a buzzword now, um and or a or a slogan now that people are aiming for. I mean, of course, a proctocal engineer, I would like to see that happening, but I think things, for example, like like video streaming, video calls, those are much more difficult to get right. Right. So what people usually do is, Um, you try and um use to PR networks as a form of of setting up control signaling or distributing control signaling to set up maybe more direct links for the streaming to happen with file down. Thats to happen Um even earlier. Um, but then there's still a point of point connection, Um at the end for these high bandwidth uh kind of applications. On top of that, I would say, like try to build things like it's reasonable to try and build things in such a way that you have context of the environment. You need to operate in so like if you need ridiculous privacy, if if you, if you are Um, operating an environment where you need strong guarantees that other people can't read your messages, then you're much more willing to undergo a little more friction in order to get to that environment. So maybe that means your message rate is dropped because of all of the stuff happening on the back end of the period of peer network to provide those guarantees. But if you just kind of in this, you know group chat about shilling and F T S, you don't really care, and so you're able to choose a specific amount of protocols that they have less security and privacy guarantees so that you can have a fast message rate or lower bandwidth or whatever, right. And the same thing happens if, like, you have, you know, a bandwidth or really, really, really resource restrict to device. Um, you're you're just you're limited in your potential options and you can participate in because you don't have the resources to be in one of those more extreme environments. Um, and the goal is to try and less than that as much as possible. But I think to some certain extent there will always be limitations. Um. In in in that kind of manner speaking, they will always be trade offs. The absolutely right and there's is certainly the approach that we take in in terms of our protocol designs. We want to provide all of the tools necessary, Um, for all of these different, different applications to pick and choose the kind of like security guarantees that they want, Um, the protocols that they need in order to make the application work, Um, and to be very clear in terms of the trade offs that they are making, or would have to make, Um, when they are setting up these kind of environments, and then, at...

...the same time, trying to mitigate straight ups as much as possible. Um and uh, and and continuously trying to improve on areas where people are running into this kind of bottlenecks because they have a strong requirements and security or a strong requirement on reducing bandwidth, Um, which you mentioned. Just kind of like being some of the other leavers. Well, Um, being pulled in the wrong direction. It's one of those things that's like hard to fathom because but it's necessary for real scale. I mean, I'm not sure you're ever even get to a point where that's true, but minimizing that that additional burden when someone joins the network or Um constraining it to only a few people within the network and not the entire network. Is Right now, like, if you think about just a naive flooding network, every time you add one person you add exponentially more messages being pushed across the network, which means that every person in the entire network now has this process so many more transactions or passages, whatever you want to call them, and and that's clearly not scalable. And that's how, like, the original whisper was created. This is why we burned phones its status and we initially implemented it was because phones were processed, like every time we went to a conference and get every people to use status. We killed everyone's data plane and battery because a bunch of people joined really, really quickly and then everyone just started just processing messages and messages and messages. I didn't know whisper was naive flooding based in terms of communication. Well, that the goal of whisper was to d anonymize Um like Sinder and receiver as much as possible, and you do that by basically like flooding the network. So you don't know where something came from and essentially tried to, I would say, synchronize messages across the networks. It's it's it's flooding. What was the idea was that everyone should be being able to see what the state of the letters message was on the network, and that's great. This this idea of Um always informing all notes around me of everything that I see in the network. Um and yeah, which is basically flat rooted Um. That's not scared. If you don't make a decision on routing, then no one can know what the route is physically. I mean, it's true, and that's a trade off, right, is you disperse a message across the network really fast because everyone sends everything, but every note is a process. Everything, including the same message in times within being the number of notes in the network, because they get it from every single person every time. And so like that's where, like, you start to make more like gossip based networks, where there's rules on how you pass messages around based on, Um, who you're connected to and and what you know they have, or whatever, or whatever. Right, so you can come up with all artary rules to try and minimize the amount of redundancy that any given note get. It's when spreading one message across the entire network, and it's just like infinite ways in which you can try and optimize this type of stuff. I wish there was a sliding scale that was like, I'm a resource restricted user, I don't care about my privacy, you know, so you don't need to throw me in with a bunch of peers so I can hide myself and then, and you know, I have a crappy process. That's literally the goal. I mean that's that's literally what we're trying to build. If I can have a literal sliding scale, I would, I would be happy in my in my vision. You know, full disclosure, we all work at status, so we build these things Um, but it's it's like that's the goal, is to have status nodes, have a user be able to slide their scale and the various dimensions on how they want to operate, and then the you know, the software the node takes care of itself and does and allows them to participate that way exactly. For as the two main I mean these these scales would be divided into two contregrades. So the one is the resource US degree, which is, which is just something that uses generally up a little control over right. They have the resources that they have. Um. And then there's a motivation scale as well, which is I have an application and I care about these properties more than others. Um. And we should be able to provide that on PTOP networks. Um, if we are planning, if we're hoping to see it becomes as widely useful and as widely used as we wanted to be used. Looking forward to it. Yeah, Hannah, is there anything we should have asked you that we didn't? I think we we covered a lot of the interesting things. Of course, it's a lot more in terms of PTOP networks. Always happy to chick. You can find links to Julia Fanti and Hana Cornelius in the show notes. Let's go way to wrap up,.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (128)