Building Blocks of Decentralization
Scott, Will
Much of our time online continues to be spent in centralized silos. A wide range of projects continue to chip away at building decentralized alternatives, but it's fair to say that decentralized platforms continue to play catch up. This talk looks at a few of the key problems underlying many schemes for decentralization, and reflect on how different projects are tackling them and what remains challenging. In particular decentralized platforms grapple not only with how to efficiently scale, how to balance resiliency and capacity, how to name and discover content and users, but also have to consider privacy and security. In 2020 we've seen increased adoption of both federated (matrix, activity pub) and decentralized (ssb, ipfs, cryptocurrencies-writ-large) platforms. Lots of decentralized engineering has been happening this year. The Interplanetary Filesystem restructured its DHT to get content discovery times below 5 seconds. Matrix grew to more than 2,500 federated servers, and got a contract with the German education system. Planetary.social extended the Secure Scuttlebutt gossip protocol to mobile. The crypto-currency community has settled on some strategies for parallel computation to address scaling pains, and are continuing to work on building systems for decentralized governance and organizations. On the flip side, there remain plenty of big questions these systems are hitting. You can't just keep scaling a DHT without the overhead of connection setups and metadata overwhelming performance. Consistency remains computationally expensive at scale, and decentralization of power and wealth are not solvable with engineering alone.
 The internet has this funding myth that it's a very central decentralized thing. But if you look at the actual usage today, much goes through a few centralized commercial entities like Google or Amazon or Facebook. There are many single points for authorities or other interested parties to throttle or send their access to content. A speaker will scot who is a recovering academic who has worked on distributed systems and security among other things, things that the internet should not have these central points of control and wants to tell us about the building blocks of decentralization that will allow us to build another internet that is less centralized and more resilient to central attacks. Have fun with the talk. Great. Thank you. Yeah. So I'm really happy to be talking today and it's been great to see so many people at RC3 even if just through my screen. In reflecting on this talk, I think there's a couple of messages and the primary one for me has actually been really hopeful. But when I think about what we have with decentralization and what's getting built, the trajectory actually looks promising in a lot of ways. And I think the second message is that when we think about the technical building blocks for decentralized systems, we really are at the very beginning that there's a lot left to do and there's a lot of work ahead of us. So I want to start with a story. And that story is a story of community and of building new systems. And the first step and the first question is how do you build that community? How do you find that community? And I think the answer that we have is things like this event. And this is one that maybe we don't have all the systems of discovery. And there's a whole talk here that maybe we don't have time for, which is how do you find the people who share similar interests? And the place where we can start to think about decentralized technologies is instead that you've got this community and you want to sustain it. And we actually have a bunch of decentralized tools and a really rich ecosystem to do that. So we can find our community and we can talk with federated systems like Mastodon, we can have video chats with Jitsi, we can host our own files, store our own data, we can collaborate on software projects by running GitLab. And so when you think about decentralized systems to help a community be self-sustaining and independent, we have a set of fundamentals that do this well. And what we're doing is not developing new things, but it's reducing the barrier of entry. And so when you think about the sorts of things that are happening today is you're finding things like instead of having to find someone to run a server and run a complex thing like GitLab, you have new systems like Radical that can make that easy. So people just run a piece of software and they don't need to worry about the complexity of deployment. So we're reducing the barrier of entry, but we already have a set of building blocks that allow a community to do this. Right. So you've got your community. You've around an idea, around an ideology, and you can build software and you can start to make this idea grow. And so when you think about that, the next step is how do you make services, how do you make ways for that idea to get to more people? And once that stops being a thing that you can just self-post that you would run on your own servers, we have building blocks now. We have underlying systems and design patterns for how do you take your service and allow it to scale while maintaining independence. And these are somewhat less developed. I think we'll go through this in a little bit, but the user bases are maybe one or two orders of magnitude smaller than the previous ones. You can have files go on a decentralized CDN like IPFS or a number of others. You can use distributed database abstractions, be they a gun or a star or a hyper swarm or others that will allow messages to get passed in a decentralized way and allow for some amount of synchronization and collaboration so that a service can go out to millions of users without needing to fall back to centralized technologies like Google or Microsoft or Facebook or et cetera. And so you can, I think, not only have things that support your community but can then reach other communities. And so we're sort of following the trajectory. This is less developed. And then we can go to the next step that's even less developed. And this is now not only touching a virtual service but starting to interact with the real world. Because when we think about the successful technologies that are the Google's or the Facebook's of the world, they're not purely digital. They go into our real lives. And this is a part that's still very much in development, which is cryptocurrencies are a whole thing, but the thing that's maybe interesting is they help us bridge into the real world financial system. And so our services still maintain independence while being able to touch that aspect. And likewise, the promise of the Dow or of decentralized autonomous organizations is that you can maintain decentralization while interacting with real legislative, political, et cetera systems. And so the thought is rather than having some core owner who has to have power, you can encode beforehand a contract of how this organization will work based on the principles and have that power remain decentralized in that there's not a single person that the existing real world regulation systems see as the source of all of this accumulated power and go african and are able to then influence or manipulate apart from what the community wants. And so this takes the form of these evolving and developing systems like oracles, how you have something that exists in a decentralized way and have it be able to interact with existing real world systems. And the answer ends up involving both advances in cryptography and in sort of thinking about how you find hooks that you can make these bonds of interaction. So what I want to go through in the rest of this talk is start with a grounding on a set of things that I would consider decentralized systems to give us a sense of scale and help ground us. And then I'm going to abstract one layer to talk about the underlying models and technological systems that are common to a lot of them. And then talk about sort of two ways to think about the limits there. One is as these things grow, what are the emerging pain points that we see that we know of that are in terms of the existing technologies are running into pain points. And then the other one is the more model properties. So these already are failing us in some ways. And so how do we think about whether there are alternatives that do not have those same properties are these things that we can bolt on or do better with in the current systems and how do we do that? So in terms of existing systems and where we are, BitTorrent remains probably one of the largest decentralized systems in a sense. There are 3 million, 4 million active users out there on any given day, which starts to reach meaningful percentages of the global population that are actively using BitTorrent. We can think about one other aspect of BitTorrent that's sort of interesting, which is you've got a lot of users. But then you've also got this sort of metadata layer of finding new torrents. And that finding new torrents core that needs to exist to allow you to discover the peers that you are in, in your specific federated instance of BitTorrent, comprises of something on the order of 400 open torrent trackers that will maintain metadata. Also, the Academia DHT, which is a distributed hash table that is made up by more normal peers that store metadata. And there's roughly 4 million torrents that are contained in that distributed hash table of metadata about who is participating in which torrent. Another federated system that's had a great year is Mastodon as a exemplar of activity pub protocol and the Fediverse more generally has on the order of 3 million users. The activity pub Fediverse more generally is something like 50 different projects. There are on the order of 5,000 activity pub servers. There this fall, I guess, there's been measurement from the community data science collective academic group looking at activity on Mastodon specifically. They find something like 70,000 tooting users who collectively to roughly 30,000 times per day. And this sort of measured activity versus total users is not an unexpected ratio on pretty much any social network you would expect that the majority of people there are consuming or not posting public content. More broadly, when we think about federated things, there's a lot of even foundational internet technology like email that is federated still. There are on the order of 6 million email servers. That's a different IP addresses running the SMTP protocol. There are a bunch of WordPress servers as well that federate through comments and ping backs and so forth. JITSI reported this year that they have on the order of 20 million users of their primary service infrastructure. They didn't say how many independent installations there are because that's much harder to measure. And Matrix had a great year and has grown to 2.5 million users and has at least 11,000 independent instances. Moving again on this graph towards external impact IPFS past 2 million users this year, they have a DHT using the same Kedemli protocol as BitTorrent. But they self-select a smaller core of active nodes to participate in that DHT as a way to try and provide better latency and availability guarantees in it. And so their DHT is composed of somewhere in the 5,000, 10,000 DHT nodes. Of those 2 million users, somewhere around 20% or 100,000 are running sort of a desktop instance where they're staying on and are not being accessed through a web browser. And then participating in the DHT, one finds something on the order of 20 million different pieces of content that are being stored in IPFS. And in a given day, something like 8 million that are being retrieved through that DHT or being fined at about who had some. ServerSketlebutt is a offline first decentralized network. It's got a order of 10,000 users. And it uses public servers as a mechanism for storing and forwarding when users are offline. And it has on the order of 100 of those. Previously, I mentioned Earth Star that uses a similar partial replication. And this network is really going further on the decentralization and meant for small independent collectives than many of the others. And then finally, Bitcoin has only about a million active addresses or accounts and about 11,000 nodes that are running the full Bitcoin protocol. And this is not a dissimilar ratio to what you'll find on all of the other projects of this type. And so again, you've got this fairly large gap between users and servers or the sort of the elevated nodes that are doing more of the work in coordination. Part of that we can see in the Bitmark case is that in order to validate and run the full protocol, you need to have all the historic data, which is up to about 300 gigabytes in this case. So the cost of running this full node is non-trivial. It's not something you can run on a phone or even really on a local desktop necessarily. So from these, we can then say what are the commonalities that a bunch of these systems share? And I want to start by, I included in that, you might notice a lot of federated systems. And we can think of federation as this partial decentralization perhaps, that we've gone from a central Facebook or Google where there's one entity to these federated systems, Matrix, Jetsie, et cetera, et cetera, where there's a lot of instances of a server, but the server is distinct from the client. And we can then, there is this distinction to be drawn of, well, okay, there are things like BitTorrent perhaps, although BitTorrent has, again, a tracker that's sort of like the server that's separate from the clients, although the tracker is getting phased out to the DHT. And so the point is, and this is, I think, why I think of federation as a lot of the part is that what federation is doing in some sense is it's externalizing the heterogeneity of resources, which is you've got some nodes that are more powerful, that are going to be always on, that have bandwidth. And in a federated system, we sort of explicitly run a different software on them that indicates that, that is, this is the server software. And in systems that we think of more traditionally as true peer-to-peer, within the software, there end up being heuristics that try and do the same thing, that try and guess should this node take on more of the coordination work. Because one of the things that all of these networks want to do is make efficient use of resources, and those resources are not evenly distributed. Some nodes have more disk space, have more bandwidth, have better availability. And your system is going to perform better if you're able to take advantage of that. And so we can, and I think, you know, I don't know if I think of this as cheating, but you can think of these as two different problems, which is, there's one problem, which is how good of heuristics can I have to self-select nodes into being servers versus clients? And then how do I make decentralized protocols? And those are somewhat different. And as a result, you can say, do I need to figure out how to have good heuristics? Or do I just start with Federation, which seems to be getting us a couple orders of magnitude more users and more success? And then I can make packaging and make auto-selection of client and server, and opting into those positions be a thing that happens independently of that, or happens later as a different problem to self. The other thing that you can counter is that you think of message passing and how your communication model will happen purely in terms of a single node. And this is, you know, the natural thing that you end up with when you do that and you go on the full sort of, I'm a node and there are other nodes like me, but let's take the view of a single user or single node, is you end up with something that looks like gossip. This is what SecureSkettlebutt uses in a sense or is based on initially. And the basic concept here is I get a message and I want to then send it out to everyone else I'm connected to so that messages sort of disseminate through the mesh, through the decentralized mesh. And we have a bunch of optimizations on that initial concept. So things like I will then send out an identifier of the message to see if the person I'm going to send it to has already gotten it and then if they have, I'm not going to send it so that I don't waste the full bandwidth of sending that message over every edge. But one of the things that's true when you start there is there's no concept of the structure of the network itself, right? Because you're sort of considering a node in isolation, what you don't have is any ability to then pull back from there to look at the full network and start to say useful things about that. And so one of the things that is tough to say is will a message get to its recipient, how quickly will it get to its recipient? Because these are all questions that aren't about the single node but are about the structure and the connectivity of the network more broadly. And so it becomes hard to mesh this sort of communication with things like when should I form additional communications or additional connections? Who should I remember? And questions about how you maintain a strong network topology. And I think one of the things that we maybe need to be thinking about is how do you combine those two together so that you can have better guarantees and better understanding of the actual dynamic properties of these decentralized networks? Because we end up with very few properties that we can say useful things about in this sort of system of message passing by itself in isolation. To give a sense of a somewhat more concrete building block that ends up being the other one that we could use, that's distributed hash tables. And so a distributed hash table, which many of you have probably seen at least in passing, is that we've got a bunch of data and we've got a bunch of computers or participants in our network. And we're going to come up with some identifier, maybe a hash of both participants and content. And we're going to put them in the same name tag. So it's the same hash, right? And then the different nodes, the different computers will store the content that is close to them. So I'm a person at position three. I'm going to store all of the content that hashes to four, five, six until there's some other node. So I get some section of the space of content based on where I hash to. And then when I want to find content, I find the node that I know about that is closest to that content. And I ask them, and if they know someone closer, they'll forward me on to that person. And so I end up finding the node that is responsible for that content. And this has an algorithm. There's a few different implementations and dashes are in wide use. One of the nice things is that it's an abstraction that, you know, from outside you can sort of think of it as a centralized database that I can put stuff into it and I can get stuff out of it and I don't have to think about the dynamics within. And it has this nice property that it sort of grows as you have more users. You can expect the users to each bring data, but the data per user isn't necessarily growing. And so it's, you know, efficiently keeping data across all the different users. The other building block that we have here is coming up with consensus. How do a set of decentralized nodes agree on something? This is what we pioneered or, you know, this is what cryptocurrency really is relying on is you have a bunch of nodes that want to all agree on something. But that's, you know, a much more general problem. We've had this problem and have a set of systems for it in centralized systems for a while. And it turns out that's more efficient. But when you think of what the problem for consensus is in those cases, they've actually been able to get away with a weaker threat. So Paxos, Raft, these are protocols for consensus that work within a threat model of fail stop. And what that means is nodes that are broken may not respond. They may delay, they may freeze, they may crash. And despite some threshold of nodes failing or crashing or not responding, the system guarantees that the other nodes that are still working will agree on an outcome. But in a decentralized world, that ends up not being quite enough. That what you want is a stronger notion of what a bad node looks like. And so that's what gets called BFT, Byzantine fault tolerance. And that is tolerant of Byzantine nodes, Byzantine nodes being nodes that can act maliciously so they can send arbitrary messages. So it's not that they just fail to send a message, it's that they send a message indicating a different thing than they should have. And so Bitcoin came along, did proof of work. In proof of work, you are using sort of the scarce resource of computation. So how many times you can hash something as sort of a race that gets used to as long as the majority of the network is all following this protocol. And if someone is trying to do malicious things, they don't have enough power unless they are the majority to mess that up. And that's switched now, I think, because of environmental concerns and so forth, to proof of stake primarily. And proof of stake is instead of using computation as that scarce resource, it's using how much of the existing resource you have as that. And so there's a whole theory in here about things like if you already have a bunch of it, you don't want to lose it and so you're more likely to not do something malicious. But in both of these cases, these are not systems that lead towards additional decentralization. And one of the things that I think is at the heart here of a lot of the problems for decentralized systems is this question of symbols and identity, which is within the system itself, we don't really have any firm notion of identity. So who is a user? What is some entity or some collection of users acting on behalf of one user or are they multiple users? We can't meaningfully enforce that. When you think about how you enforce it, even for centralized systems like the Facebook or Google, they go to governments and they go to this, like, I'm going to identify you as a citizen or a person with some driver's license. And if you don't have that external authority, that stops making sense as a way to appeal to authority. And so instead, a lot of effort goes into trying to think about incentives and trying to make the system not make it worthwhile to appear as multiple users when you are in fact only one. But the flip side of that is that the incentive actually incentivizes centralization because it ends up meaning that it is better to be a single large entity than many small entities. And so that means that if it's better to be the single large entity, that single large entity becomes more and more powerful over time. So that was a set of building blocks. Let's go through limitations on these building blocks. So DHTs are something that we have. And they do grow with users. However, so as you get more users, you can have more content and the load and burden on each user and the DHT does not increase. However, there's a set of applications that you just can't really do with our current understanding of DHTs. So if I want to do web search and put identifiers for all of the web or for really many millions of identifiers, suddenly that's a lot of load that I would be needing out of each user on the DHT. So we can do something like a few million torrents total based on that user base. But are you going to be able to store hundreds of millions of items, all of the individual files and make those individually addressable? That suddenly becomes really hard. And so this is a question of naming and thinking about what is an identifier that I want to be able to search for or look up? What are the things that I'm putting as the entry points for lookups? The other one is an interesting or limit here in terms of scale that these things don't sort of fully scale is that a lot of the applications that we want are interactive in nature. So we want to be able to look up something and get a response in an interactive way that is compatible with web browsing or some sort of I'm there as a user. DHTs take something on, you know, asymptotically log in lookups to find content. So I find the node I'm connected to that's closest to it. They tell me someone who's even closer as a DHT grows that goes from two or three people that I need to talk to, to three or five. And if each of those is taking, you know, 100 milliseconds, that starts growing quite a bit to a point where even though it is log in, which is great, it's more than constant and it stops being competitive with our centralized systems. The second limit is gossip. As a gossip network grows larger, we start to really find ourselves in a situation where we don't expect messages to necessarily end up going all the way across it. And so we stop being able to say things about like, you know, I'm in a local neighborhood, but I can't necessarily find a friend through the network because it becomes way too expensive for all messages to go to the whole message, the whole network. And so there is something about network structure and about how you think about things beyond gossip that we need in order to scale those networks. And the final one is an infrastructural one, which is that there continue to not be real world incentives that are pushing the infrastructure that we have to support decentralized technologies. So it's still true, as it has been for decades, that a normal user's upload bandwidth is about half of their download bandwidth. This is true. This is a broadband fixed line one, but it's also true for mobile. But likewise, when you think about like latency between end users, when I think about a centralized system, the latency for me to get there keeps going down because they keep building edges closer to more of their users. And so on average, they actually end up getting closer to their users and lower latency. But when you look at, and this is a rape Atlas probe, you know, 2015 or 2010 till now, the latency doesn't actually go down much. Like it goes down and this is a bunch of nodes trying to get into Europe. And the latency from Russia goes down a little bit, but India is staying about the same. And we don't have money that's getting invested into the links that are getting translated for traffic between two different end users because that's not something that there's money that is incentivizing. And so until we figure out a way to solve that, we're going to end up with a very sort of static latency and bandwidth profile. Okay, I'm going to, I think running into question time, but I will finish with the more meta properties rather than the scaling limits that we need to think about. The first is coming up with a much stronger model of metadata exposure and privacy. We have end-to-end encryption. We're able to protect the contents, but we don't typically protect either the size or communication patterns of who's talking to whom. And without servers and intermediaries, I think basically all of these decentralized systems, less so federated, but even there, end user IP addresses and the identity of where they are and what they're connecting as ends up being something that is used for the disintermediation. And as such, there's no real guarantee about how private you are or who could learn that you're participating or who you're talking with. And so coming up with models where we get some limits on the retention, so being able to say things like, you know, at some point after you have stopped talking, the system will not continue to hold onto your IP address or who you've talked to, your communication patterns is important and is not part of any of these models. And so I'll end with two things that I go back to when thinking about this. The first is a paper on the impossibility of fully centralization and permissionless, and this is on blockchains, but persists, persistential consensus, which basically is the impossibility result that I brought up earlier when talking about how in order to disincentivize symbols, we move towards, we move towards encouraging centralization. And I think this is a framing question, which is the incentive to decentralize is actually an incentive that happens in a larger picture. It's not the system itself, but it's the entities around your system that are the incentive to not have centralization, right? It's the government, it's the regulations, and it's the other dynamics that are why you would want to not be centralized, and we don't have that in our model. And likewise, the tech policy perspective is saying essentially there are these very powerful existing entities that will attempt to identify the points of power and regulate them. And that ends up being why we need this decentralization in some sense is to prevent being co-opted by existing systems of power. That's where we find the motivation for decentralization. So I will end there. I guess we have maybe a couple of minutes. Third questions. You're muted for me. Yes, thank you. We have a few questions from the audience. First is, what do you think is the future for decentralized social media? Does there have to be a major event for decentralized social media to gain more traction? It's a good question, right? So social media is an interesting and problematic beast in its own way, right? Which is this is something that we haven't really traditionally had in the same way. And so one of the questions maybe to step back is what do you actually want? I think the part of social media that is you and your communities and your friends, I think we already can do and will continue to see more localized things because they give us the same experience. Figuring out how you broadcast a celebrity or these sort of more large-scale zeitgeist ideas is where we are much less developed. And so part of that less developed also means that there's more potential for further technological development to make that more possible. So I'm optimistic that we get there, but I think that's further off. Okay. And another question related to that, but probably more into direction of user experience, can we abstract decentralization to ease the use for the average user? Yeah. I mean, and there's a couple of things there, right? Which is we are certainly have libraries and patterns that other developers can build better user experiences on. I think we're seeing also that there are easier to use sort of end user compatible systems that are views into decentralized networks. So be that the things like manyverse or planetary, which are mobile apps that came out this year for secure Scuttlebutt or Radical and these just sort of desktop apps that provide Git or other types of decentralized network views that don't require setup or work. We're getting better user interfaces. And we're having building blocks that are not themselves particularly visible or require configuration. And a more technical question that just came in. What do you think of the trade-offs made by single hop DHTs and their huge local routing tables? Right. So this is an interesting question. And it's where a bunch of thought is being put right now. And so one of the things you could say, right, is in the same way that a federated system is externalizing this disjoint resource or resource heterogeneity between sort of highly available nodes that might make up your DHT and the sort of end user more transient nodes that are querying it. You could have a DHT that tries to self-organize to take advantage of even more heterogeneity. So you find nodes that are more powerful and you have multiple players or a hierarchical DHT where some DHT nodes forward queries into a smaller center that's more powerful. And you end up with something where you probably can get rid of some of these log-n style latency things to make them be able to scale more at the expense of something that starts to look like more centralization. That there end up being a smaller number of nodes in the center that if they do go down or if they decide to send their things, they actually can have really, they end up with a lot of power in the system, which is starting to be scary. So there's a trade off there. And next question, given the popularity of Cademlia, have probabilistic models won the decentralized architecture or are they better suited to decentralization? That's a good question. I think Cademlia, I don't know if it won just because it's probabilistic. I think it has something to do with, it's fairly simple to conceive of. We often say these distributed systems are really hard to reason about. And in some sense, that's like this, I've done one thing and I'm out of ideas. One thing that I took away at least from that set of building blocks that I presented was there were only three or four things that are underlying all of these things. We really have not looked through a lot of this design space. And so I am not at all unconvinced that trying something radically different, we can find other models of decentralization that are more performant and that have different properties and we just haven't explored enough. So I think that's a no. Okay. And the last question until now, do you think decentralized writable storage like IPFS is threatened by toxic data sets like Libgen? Okay. So there's an assumption that Libgen is a toxic data set. But beyond that, I mean, I think there's a very reasonable story for any of these systems for how you sanitize them or make them compatible with external power structures. And so in an IPFS like thing, users are opting into pinning or storing data as notes. So it's only either you've decided to pin data in order to make it reavailable to others. And so there are, as a node, if you get a DMCA complaint or you get a complaint that something is illegal, you can blacklist it. You can say, I'm not going to pin or reserve that data. And so there's a way for each individual user in the system as they get complaints to not make that data reavailable and limit their liability. So you'll get, as there's different regulatory environments, people will be able to comply with their own regulatory environments. And so I think that is probably enough. And the bigger question is, OK, does that cause the software to be seen in the same light as BitTorrent? And that's, I think, a more philosophical question and is as much a perception and finding good uses that you can counter things with as anything else. OK. Thank you. That was a question. Thank you for the interesting talk and for being here answering the audience questions. Thank you. But this is 씨가.
 The internet has this funding myth that it's a very central decentralized thing.  But if you look at the actual usage today, much goes through a few centralized commercial  entities like Google or Amazon or Facebook.  There are many single points for authorities or other interested parties to throttle or  send their access to content.  A speaker will scot who is a recovering academic who has worked on distributed systems and  security among other things, things that the internet should not have these central points  of control and wants to tell us about the building blocks of decentralization that  will allow us to build another internet that is less centralized and more resilient to  central attacks.  Have fun with the talk.  Great.  Thank you.  Yeah.  So I'm really happy to be talking today and it's been great to see so many people at  RC3 even if just through my screen.  In reflecting on this talk, I think there's a couple of messages and the primary one for  me has actually been really hopeful.  But when I think about what we have with decentralization and what's getting built, the trajectory actually  looks promising in a lot of ways.  And I think the second message is that when we think about the technical building blocks  for decentralized systems, we really are at the very beginning that there's a lot left  to do and there's a lot of work ahead of us.  So I want to start with a story.  And that story is a story of community and of building new systems.  And the first step and the first question is how do you build that community?  How do you find that community?  And I think the answer that we have is things like this event.  And this is one that maybe we don't have all the systems of discovery.  And there's a whole talk here that maybe we don't have time for, which is how do you  find the people who share similar interests?  And the place where we can start to think about decentralized technologies is instead  that you've got this community and you want to sustain it.  And we actually have a bunch of decentralized tools and a really rich ecosystem to do that.  So we can find our community and we can talk with federated systems like Mastodon, we can  have video chats with Jitsi, we can host our own files, store our own data, we can collaborate  on software projects by running GitLab.  And so when you think about decentralized systems to help a community be self-sustaining and  independent, we have a set of fundamentals that do this well.  And what we're doing is not developing new things, but it's reducing the barrier of entry.  And so when you think about the sorts of things that are happening today is you're finding  things like instead of having to find someone to run a server and run a complex thing like  GitLab, you have new systems like Radical that can make that easy.  So people just run a piece of software and they don't need to worry about the complexity  of deployment.  So we're reducing the barrier of entry, but we already have a set of building blocks that  allow a community to do this.  Right.  So you've got your community.  You've around an idea, around an ideology, and you can build software and you can start  to make this idea grow.  And so when you think about that, the next step is how do you make services, how do you  make ways for that idea to get to more people?  And once that stops being a thing that you can just self-post that you would run on your  own servers, we have building blocks now.  We have underlying systems and design patterns for how do you take your service and allow  it to scale while maintaining independence.  And these are somewhat less developed.  I think we'll go through this in a little bit, but the user bases are maybe one or two orders  of magnitude smaller than the previous ones.  You can have files go on a decentralized CDN like IPFS or a number of others.  You can use distributed database abstractions, be they a gun or a star or a hyper swarm  or others that will allow messages to get passed in a decentralized way and allow for  some amount of synchronization and collaboration so that a service can go out to millions of  users without needing to fall back to centralized technologies like Google or Microsoft or Facebook  or et cetera.  And so you can, I think, not only have things that support your community but can then reach  other communities.  And so we're sort of following the trajectory.  This is less developed.  And then we can go to the next step that's even less developed.  And this is now not only touching a virtual service but starting to interact with the  real world.  Because when we think about the successful technologies that are the Google's or the  Facebook's of the world, they're not purely digital.  They go into our real lives.  And this is a part that's still very much in development, which is cryptocurrencies  are a whole thing, but the thing that's maybe interesting is they help us bridge into the  real world financial system.  And so our services still maintain independence while being able to touch that aspect.  And likewise, the promise of the Dow or of decentralized autonomous organizations is  that you can maintain decentralization while interacting with real legislative, political,  et cetera systems.  And so the thought is rather than having some core owner who has to have power, you can  encode beforehand a contract of how this organization will work based on the principles  and have that power remain decentralized in that there's not a single person that the  existing real world regulation systems see as the source of all of this accumulated power  and go african and are able to then influence or manipulate apart from what the community  wants.  And so this takes the form of these evolving and developing systems like oracles, how you  have something that exists in a decentralized way and have it be able to interact with existing  real world systems.  And the answer ends up involving both advances in cryptography and in sort of thinking about  how you find hooks that you can make these bonds of interaction.  So what I want to go through in the rest of this talk is start with a grounding on a set  of things that I would consider decentralized systems to give us a sense of scale and help  ground us.  And then I'm going to abstract one layer to talk about the underlying models and technological  systems that are common to a lot of them.  And then talk about sort of two ways to think about the limits there.  One is as these things grow, what are the emerging pain points that we see that we know  of that are in terms of the existing technologies are running into pain points.  And then the other one is the more model properties.  So these already are failing us in some ways.  And so how do we think about whether there are alternatives that do not have those same  properties are these things that we can bolt on or do better with in the current systems  and how do we do that?  So in terms of existing systems and where we are, BitTorrent remains probably one of  the largest decentralized systems in a sense.  There are 3 million, 4 million active users out there on any given day, which starts to  reach meaningful percentages of the global population that are actively using BitTorrent.  We can think about one other aspect of BitTorrent that's sort of interesting, which is you've  got a lot of users.  But then you've also got this sort of metadata layer of finding new torrents.  And that finding new torrents core that needs to exist to allow you to discover the peers  that you are in, in your specific federated instance of BitTorrent, comprises of something  on the order of 400 open torrent trackers that will maintain metadata.  Also, the Academia DHT, which is a distributed hash table that is made up by more normal peers  that store metadata.  And there's roughly 4 million torrents that are contained in that distributed hash table  of metadata about who is participating in which torrent.  Another federated system that's had a great year is Mastodon as a exemplar of activity  pub protocol and the Fediverse more generally has on the order of 3 million users.  The activity pub Fediverse more generally is something like 50 different projects.  There are on the order of 5,000 activity pub servers.  There this fall, I guess, there's been measurement from the community data science collective  academic group looking at activity on Mastodon specifically.  They find something like 70,000 tooting users who collectively to roughly 30,000 times per  day.  And this sort of measured activity versus total users is not an unexpected ratio on  pretty much any social network you would expect that the majority of people there are consuming  or not posting public content.  More broadly, when we think about federated things, there's a lot of even foundational  internet technology like email that is federated still.  There are on the order of 6 million email servers.  That's a different IP addresses running the SMTP protocol.  There are a bunch of WordPress servers as well that federate through comments and ping  backs and so forth.  JITSI reported this year that they have on the order of 20 million users of their primary  service infrastructure.  They didn't say how many independent installations there are because that's much harder to measure.  And Matrix had a great year and has grown to 2.5 million users and has at least 11,000  independent instances.  Moving again on this graph towards external impact IPFS past 2 million users this year,  they have a DHT using the same Kedemli protocol as BitTorrent.  But they self-select a smaller core of active nodes to participate in that DHT as a way  to try and provide better latency and availability guarantees in it.  And so their DHT is composed of somewhere in the 5,000, 10,000 DHT nodes.  Of those 2 million users, somewhere around 20% or 100,000 are running sort of a desktop  instance where they're staying on and are not being accessed through a web browser.  And then participating in the DHT, one finds something on the order of 20 million different  pieces of content that are being stored in IPFS.  And in a given day, something like 8 million that are being retrieved through that DHT  or being fined at about who had some.  ServerSketlebutt is a offline first decentralized network.  It's got a order of 10,000 users.  And it uses public servers as a mechanism for storing and forwarding when users are offline.  And it has on the order of 100 of those.  Previously, I mentioned Earth Star that uses a similar partial replication.  And this network is really going further on the decentralization and meant for small  independent collectives than many of the others.  And then finally, Bitcoin has only about a million active addresses or accounts and about  11,000 nodes that are running the full Bitcoin protocol.  And this is not a dissimilar ratio to what you'll find on all of the other projects of  this type.  And so again, you've got this fairly large gap between users and servers or the sort  of the elevated nodes that are doing more of the work in coordination.  Part of that we can see in the Bitmark case is that in order to validate and run the full  protocol, you need to have all the historic data, which is up to about 300 gigabytes in  this case.  So the cost of running this full node is non-trivial.  It's not something you can run on a phone or even really on a local desktop necessarily.  So from these, we can then say what are the commonalities that a bunch of these systems  share?  And I want to start by, I included in that, you might notice a lot of federated systems.  And we can think of federation as this partial decentralization perhaps, that we've gone  from a central Facebook or Google where there's one entity to these federated systems, Matrix,  Jetsie, et cetera, et cetera, where there's a lot of instances of a server, but the server  is distinct from the client.  And we can then, there is this distinction to be drawn of, well, okay, there are things  like BitTorrent perhaps, although BitTorrent has, again, a tracker that's sort of like  the server that's separate from the clients, although the tracker is getting phased out  to the DHT.  And so the point is, and this is, I think, why I think of federation as a lot of the  part is that what federation is doing in some sense is it's externalizing the heterogeneity  of resources, which is you've got some nodes that are more powerful, that are going to  be always on, that have bandwidth.  And in a federated system, we sort of explicitly run a different software on them that indicates  that, that is, this is the server software.  And in systems that we think of more traditionally as true peer-to-peer, within the software,  there end up being heuristics that try and do the same thing, that try and guess should  this node take on more of the coordination work.  Because one of the things that all of these networks want to do is make efficient use  of resources, and those resources are not evenly distributed.  Some nodes have more disk space, have more bandwidth, have better availability.  And your system is going to perform better if you're able to take advantage of that.  And so we can, and I think, you know, I don't know if I think of this as cheating, but you  can think of these as two different problems, which is, there's one problem, which is how  good of heuristics can I have to self-select nodes into being servers versus clients?  And then how do I make decentralized protocols?  And those are somewhat different.  And as a result, you can say, do I need to figure out how to have good heuristics?  Or do I just start with Federation, which seems to be getting us a couple orders of  magnitude more users and more success?  And then I can make packaging and make auto-selection of client and server, and opting into those  positions be a thing that happens independently of that, or happens later as a different  problem to self.  The other thing that you can counter is that you think of message passing and how your  communication model will happen purely in terms of a single node.  And this is, you know, the natural thing that you end up with when you do that and you go  on the full sort of, I'm a node and there are other nodes like me, but let's take the  view of a single user or single node, is you end up with something that looks like gossip.  This is what SecureSkettlebutt uses in a sense or is based on initially.  And the basic concept here is I get a message and I want to then send it out to everyone  else I'm connected to so that messages sort of disseminate through the mesh, through the  decentralized mesh.  And we have a bunch of optimizations on that initial concept.  So things like I will then send out an identifier of the message to see if the person I'm going  to send it to has already gotten it and then if they have, I'm not going to send it so  that I don't waste the full bandwidth of sending that message over every edge.  But one of the things that's true when you start there is there's no concept of the structure  of the network itself, right?  Because you're sort of considering a node in isolation, what you don't have is any ability  to then pull back from there to look at the full network and start to say useful things  about that.  And so one of the things that is tough to say is will a message get to its recipient,  how quickly will it get to its recipient?  Because these are all questions that aren't about the single node but are about the structure  and the connectivity of the network more broadly.  And so it becomes hard to mesh this sort of communication with things like when should  I form additional communications or additional connections?  Who should I remember?  And questions about how you maintain a strong network topology.  And I think one of the things that we maybe need to be thinking about is how do you combine  those two together so that you can have better guarantees and better understanding of the  actual dynamic properties of these decentralized networks?  Because we end up with very few properties that we can say useful things about in this  sort of system of message passing by itself in isolation.  To give a sense of a somewhat more concrete building block that ends up being the other  one that we could use, that's distributed hash tables.  And so a distributed hash table, which many of you have probably seen at least in passing,  is that we've got a bunch of data and we've got a bunch of computers or participants in  our network.  And we're going to come up with some identifier, maybe a hash of both participants and content.  And we're going to put them in the same name tag.  So it's the same hash, right?  And then the different nodes, the different computers will store the content that is close  to them.  So I'm a person at position three.  I'm going to store all of the content that hashes to four, five, six until there's some  other node.  So I get some section of the space of content based on where I hash to.  And then when I want to find content, I find the node that I know about that is closest  to that content.  And I ask them, and if they know someone closer, they'll forward me on to that person.  And so I end up finding the node that is responsible for that content.  And this has an algorithm.  There's a few different implementations and dashes are in wide use.  One of the nice things is that it's an abstraction that, you know, from outside you can sort  of think of it as a centralized database that I can put stuff into it and I can get stuff  out of it and I don't have to think about the dynamics within.  And it has this nice property that it sort of grows as you have more users.  You can expect the users to each bring data, but the data per user isn't necessarily growing.  And so it's, you know, efficiently keeping data across all the different users.  The other building block that we have here is coming up with consensus.  How do a set of decentralized nodes agree on something?  This is what we pioneered or, you know, this is what cryptocurrency really is relying  on is you have a bunch of nodes that want to all agree on something.  But that's, you know, a much more general problem.  We've had this problem and have a set of systems for it in centralized systems for a while.  And it turns out that's more efficient.  But when you think of what the problem for consensus is in those cases, they've actually  been able to get away with a weaker threat.  So Paxos, Raft, these are protocols for consensus that work within a threat model of fail stop.  And what that means is nodes that are broken may not respond.  They may delay, they may freeze, they may crash.  And despite some threshold of nodes failing or crashing or not responding, the system  guarantees that the other nodes that are still working will agree on an outcome.  But in a decentralized world, that ends up not being quite enough.  That what you want is a stronger notion of what a bad node looks like.  And so that's what gets called BFT, Byzantine fault tolerance.  And that is tolerant of Byzantine nodes, Byzantine nodes being nodes that can act maliciously  so they can send arbitrary messages.  So it's not that they just fail to send a message, it's that they send a message indicating  a different thing than they should have.  And so Bitcoin came along, did proof of work.  In proof of work, you are using sort of the scarce resource of computation.  So how many times you can hash something as sort of a race that gets used to as long as  the majority of the network is all following this protocol.  And if someone is trying to do malicious things, they don't have enough power unless they are  the majority to mess that up.  And that's switched now, I think, because of environmental concerns and so forth, to  proof of stake primarily.  And proof of stake is instead of using computation as that scarce resource, it's using how much  of the existing resource you have as that.  And so there's a whole theory in here about things like if you already have a bunch of  it, you don't want to lose it and so you're more likely to not do something malicious.  But in both of these cases, these are not systems that lead towards additional decentralization.  And one of the things that I think is at the heart here of a lot of the problems for decentralized  systems is this question of symbols and identity, which is within the system itself, we don't  really have any firm notion of identity.  So who is a user?  What is some entity or some collection of users acting on behalf of one user or are they multiple  users?  We can't meaningfully enforce that.  When you think about how you enforce it, even for centralized systems like the Facebook  or Google, they go to governments and they go to this, like, I'm going to identify you  as a citizen or a person with some driver's license.  And if you don't have that external authority, that stops making sense as a way to appeal  to authority.  And so instead, a lot of effort goes into trying to think about incentives and trying  to make the system not make it worthwhile to appear as multiple users when you are in  fact only one.  But the flip side of that is that the incentive actually incentivizes centralization because  it ends up meaning that it is better to be a single large entity than many small entities.  And so that means that if it's better to be the single large entity, that single large  entity becomes more and more powerful over time.  So that was a set of building blocks.  Let's go through limitations on these building blocks.  So DHTs are something that we have.  And they do grow with users.  However, so as you get more users, you can have more content and the load and burden  on each user and the DHT does not increase.  However, there's a set of applications that you just can't really do with our current  understanding of DHTs.  So if I want to do web search and put identifiers for all of the web or for really many millions  of identifiers, suddenly that's a lot of load that I would be needing out of each user on  the DHT.  So we can do something like a few million torrents total based on that user base.  But are you going to be able to store hundreds of millions of items, all of the individual  files and make those individually addressable?  That suddenly becomes really hard.  And so this is a question of naming and thinking about what is an identifier that I want to  be able to search for or look up?  What are the things that I'm putting as the entry points for lookups?  The other one is an interesting or limit here in terms of scale that these things don't  sort of fully scale is that a lot of the applications that we want are interactive in nature.  So we want to be able to look up something and get a response in an interactive way that  is compatible with web browsing or some sort of I'm there as a user.  DHTs take something on, you know, asymptotically log in lookups to find content.  So I find the node I'm connected to that's closest to it.  They tell me someone who's even closer as a DHT grows that goes from two or three people  that I need to talk to, to three or five.  And if each of those is taking, you know, 100 milliseconds, that starts growing quite  a bit to a point where even though it is log in, which is great, it's more than constant  and it stops being competitive with our centralized systems.  The second limit is gossip.  As a gossip network grows larger, we start to really find ourselves in a situation where  we don't expect messages to necessarily end up going all the way across it.  And so we stop being able to say things about like, you know, I'm in a local neighborhood,  but I can't necessarily find a friend through the network because it becomes way too expensive  for all messages to go to the whole message, the whole network.  And so there is something about network structure and about how you think about things beyond  gossip that we need in order to scale those networks.  And the final one is an infrastructural one, which is that there continue to not be real  world incentives that are pushing the infrastructure that we have to support decentralized technologies.  So it's still true, as it has been for decades, that a normal user's upload bandwidth is about  half of their download bandwidth.  This is true.  This is a broadband fixed line one, but it's also true for mobile.  But likewise, when you think about like latency between end users, when I think about a centralized  system, the latency for me to get there keeps going down because they keep building edges  closer to more of their users.  And so on average, they actually end up getting closer to their users and lower latency.  But when you look at, and this is a rape Atlas probe, you know, 2015 or 2010 till now, the  latency doesn't actually go down much.  Like it goes down and this is a bunch of nodes trying to get into Europe.  And the latency from Russia goes down a little bit, but India is staying about the same.  And we don't have money that's getting invested into the links that are getting translated  for traffic between two different end users because that's not something that there's  money that is incentivizing.  And so until we figure out a way to solve that, we're going to end up with a very sort  of static latency and bandwidth profile.  Okay, I'm going to, I think running into question time, but I will finish with the more meta  properties rather than the scaling limits that we need to think about.  The first is coming up with a much stronger model of metadata exposure and privacy.  We have end-to-end encryption.  We're able to protect the contents, but we don't typically protect either the size or  communication patterns of who's talking to whom.  And without servers and intermediaries, I think basically all of these decentralized  systems, less so federated, but even there, end user IP addresses and the identity of  where they are and what they're connecting as ends up being something that is used for  the disintermediation.  And as such, there's no real guarantee about how private you are or who could learn that  you're participating or who you're talking with.  And so coming up with models where we get some limits on the retention, so being able  to say things like, you know, at some point after you have stopped talking, the system  will not continue to hold onto your IP address or who you've talked to, your communication  patterns is important and is not part of any of these models.  And so I'll end with two things that I go back to when thinking about this.  The first is a paper on the impossibility of fully centralization and permissionless,  and this is on blockchains, but persists, persistential consensus, which basically is  the impossibility result that I brought up earlier when talking about how in order to  disincentivize symbols, we move towards, we move towards encouraging centralization.  And I think this is a framing question, which is the incentive to decentralize is actually  an incentive that happens in a larger picture.  It's not the system itself, but it's the entities around your system that are the incentive  to not have centralization, right?  It's the government, it's the regulations, and it's the other dynamics that are why  you would want to not be centralized, and we don't have that in our model.  And likewise, the tech policy perspective is saying essentially there are these very  powerful existing entities that will attempt to identify the points of power and regulate  them.  And that ends up being why we need this decentralization in some sense is to prevent being co-opted  by existing systems of power.  That's where we find the motivation for decentralization.  So I will end there.  I guess we have maybe a couple of minutes.  Third questions.  You're muted for me.  Yes, thank you.  We have a few questions from the audience.  First is, what do you think is the future for decentralized social media?  Does there have to be a major event for decentralized social media to gain more traction?  It's a good question, right?  So social media is an interesting and problematic beast in its own way, right?  Which is this is something that we haven't really traditionally had in the same way.  And so one of the questions maybe to step back is what do you actually want?  I think the part of social media that is you and your communities and your friends, I think  we already can do and will continue to see more localized things because they give us  the same experience.  Figuring out how you broadcast a celebrity or these sort of more large-scale zeitgeist  ideas is where we are much less developed.  And so part of that less developed also means that there's more potential for further technological  development to make that more possible.  So I'm optimistic that we get there, but I think that's further off.  Okay.  And another question related to that, but probably more into direction of user experience,  can we abstract decentralization to ease the use for the average user?  Yeah.  I mean, and there's a couple of things there, right?  Which is we are certainly have libraries and patterns that other developers can build better  user experiences on.  I think we're seeing also that there are easier to use sort of end user compatible systems  that are views into decentralized networks.  So be that the things like manyverse or planetary, which are mobile apps that came out this year  for secure Scuttlebutt or Radical and these just sort of desktop apps that provide Git  or other types of decentralized network views that don't require setup or work.  We're getting better user interfaces.  And we're having building blocks that are not themselves particularly visible or require  configuration.  And a more technical question that just came in.  What do you think of the trade-offs made by single hop DHTs and their huge local routing  tables?  Right.  So this is an interesting question.  And it's where a bunch of thought is being put right now.  And so one of the things you could say, right, is in the same way that a federated system  is externalizing this disjoint resource or resource heterogeneity between sort of highly  available nodes that might make up your DHT and the sort of end user more transient nodes  that are querying it.  You could have a DHT that tries to self-organize to take advantage of even more heterogeneity.  So you find nodes that are more powerful and you have multiple players or a hierarchical  DHT where some DHT nodes forward queries into a smaller center that's more powerful.  And you end up with something where you probably can get rid of some of these log-n style latency  things to make them be able to scale more at the expense of something that starts to  look like more centralization.  That there end up being a smaller number of nodes in the center that if they do go down  or if they decide to send their things, they actually can have really, they end up with  a lot of power in the system, which is starting to be scary.  So there's a trade off there.  And next question, given the popularity of Cademlia, have probabilistic models won the  decentralized architecture or are they better suited to decentralization?  That's a good question.  I think Cademlia, I don't know if it won just because it's probabilistic.  I think it has something to do with, it's fairly simple to conceive of.  We often say these distributed systems are really hard to reason about.  And in some sense, that's like this, I've done one thing and I'm out of ideas.  One thing that I took away at least from that set of building blocks that I presented was  there were only three or four things that are underlying all of these things.  We really have not looked through a lot of this design space.  And so I am not at all unconvinced that trying something radically different, we can find  other models of decentralization that are more performant and that have different properties  and we just haven't explored enough.  So I think that's a no.  Okay.  And the last question until now, do you think decentralized writable storage like IPFS is  threatened by toxic data sets like Libgen?  Okay.  So there's an assumption that Libgen is a toxic data set.  But beyond that, I mean, I think there's a very reasonable story for any of these systems  for how you sanitize them or make them compatible with external power structures.  And so in an IPFS like thing, users are opting into pinning or storing data as notes.  So it's only either you've decided to pin data in order to make it reavailable to others.  And so there are, as a node, if you get a DMCA complaint or you get a complaint that  something is illegal, you can blacklist it.  You can say, I'm not going to pin or reserve that data.  And so there's a way for each individual user in the system as they get complaints to not  make that data reavailable and limit their liability.  So you'll get, as there's different regulatory environments, people will be able to comply  with their own regulatory environments.  And so I think that is probably enough.  And the bigger question is, OK, does that cause the software to be seen in the same  light as BitTorrent?  And that's, I think, a more philosophical question and is as much a perception and finding  good uses that you can counter things with as anything else.  OK.  Thank you.  That was a question.  Thank you for the interesting talk and for being here answering the audience questions.  Thank you.  But this is 씨가.
rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_0_59.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_60_179.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_180_227.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_228_275.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_276_323.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_324_371.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_372_647.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_648_755.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_756_863.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_864_1127.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_1128_1247.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_1248_1355.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_1356_1403.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_1404_1619.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_1620_1787.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_1788_1847.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_1848_4163.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_4164_7223.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_7224_13379.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_13380_13727.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_13728_15203.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_15204_15251.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_15252_15407.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_15408_15503.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_15504_17159.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_17160_18551.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_18552_19679.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_19680_20219.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_20220_22667.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_22668_23099.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_23100_24023.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_24024_24647.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_24648_24875.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_24876_25127.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_25128_25847.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_25848_26291.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_26292_28607.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_28608_29123.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_29124_30599.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_30600_34091.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_34092_36719.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_36720_38471.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_38472_38579.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_38580_40955.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_40956_45263.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_45264_47771.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_47772_49379.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_49380_51959.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_51960_62651.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_62652_62843.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_62844_63107.png rc3-csh-11400-eng-deu-Building_Blocks_of_Decentralization_hd_63108_63608.png
The internet has this funding myth that it's a very central decentralized thing. But if you look at the actual usage today, much goes through a few centralized commercial entities like Google or Amazon or Facebook. There are many single points for authorities or other interested parties to throttle or send their access to content. A speaker will scot who is a recovering academic who has worked on distributed systems and security among other things, things that the internet should not have these central points of control and wants to tell us about the building blocks of decentralization that will allow us to build another internet that is less centralized and more resilient to central attacks. Have fun with the talk. Great. Thank you. Yeah. So I'm really happy to be talking today and it's been great to see so many people at RC3 even if just through my screen. In reflecting on this talk, I think there's a couple of messages and the primary one for me has actually been really hopeful. But when I think about what we have with decentralization and what's getting built, the trajectory actually looks promising in a lot of ways. And I think the second message is that when we think about the technical building blocks for decentralized systems, we really are at the very beginning that there's a lot left to do and there's a lot of work ahead of us. So I want to start with a story. And that story is a story of community and of building new systems. And the first step and the first question is how do you build that community? How do you find that community? And I think the answer that we have is things like this event. And this is one that maybe we don't have all the systems of discovery. And there's a whole talk here that maybe we don't have time for, which is how do you find the people who share similar interests? And the place where we can start to think about decentralized technologies is instead that you've got this community and you want to sustain it. And we actually have a bunch of decentralized tools and a really rich ecosystem to do that. So we can find our community and we can talk with federated systems like Mastodon, we can have video chats with Jitsi, we can host our own files, store our own data, we can collaborate on software projects by running GitLab. And so when you think about decentralized systems to help a community be self-sustaining and independent, we have a set of fundamentals that do this well. And what we're doing is not developing new things, but it's reducing the barrier of entry. And so when you think about the sorts of things that are happening today is you're finding things like instead of having to find someone to run a server and run a complex thing like GitLab, you have new systems like Radical that can make that easy. So people just run a piece of software and they don't need to worry about the complexity of deployment. So we're reducing the barrier of entry, but we already have a set of building blocks that allow a community to do this. Right. So you've got your community. You've around an idea, around an ideology, and you can build software and you can start to make this idea grow. And so when you think about that, the next step is how do you make services, how do you make ways for that idea to get to more people? And once that stops being a thing that you can just self-post that you would run on your own servers, we have building blocks now. We have underlying systems and design patterns for how do you take your service and allow it to scale while maintaining independence. And these are somewhat less developed. I think we'll go through this in a little bit, but the user bases are maybe one or two orders of magnitude smaller than the previous ones. You can have files go on a decentralized CDN like IPFS or a number of others. You can use distributed database abstractions, be they a gun or a star or a hyper swarm or others that will allow messages to get passed in a decentralized way and allow for some amount of synchronization and collaboration so that a service can go out to millions of users without needing to fall back to centralized technologies like Google or Microsoft or Facebook or et cetera. And so you can, I think, not only have things that support your community but can then reach other communities. And so we're sort of following the trajectory. This is less developed. And then we can go to the next step that's even less developed. And this is now not only touching a virtual service but starting to interact with the real world. Because when we think about the successful technologies that are the Google's or the Facebook's of the world, they're not purely digital. They go into our real lives. And this is a part that's still very much in development, which is cryptocurrencies are a whole thing, but the thing that's maybe interesting is they help us bridge into the real world financial system. And so our services still maintain independence while being able to touch that aspect. And likewise, the promise of the Dow or of decentralized autonomous organizations is that you can maintain decentralization while interacting with real legislative, political, et cetera systems. And so the thought is rather than having some core owner who has to have power, you can encode beforehand a contract of how this organization will work based on the principles and have that power remain decentralized in that there's not a single person that the existing real world regulation systems see as the source of all of this accumulated power and go african and are able to then influence or manipulate apart from what the community wants. And so this takes the form of these evolving and developing systems like oracles, how you have something that exists in a decentralized way and have it be able to interact with existing real world systems. And the answer ends up involving both advances in cryptography and in sort of thinking about how you find hooks that you can make these bonds of interaction. So what I want to go through in the rest of this talk is start with a grounding on a set of things that I would consider decentralized systems to give us a sense of scale and help ground us. And then I'm going to abstract one layer to talk about the underlying models and technological systems that are common to a lot of them. And then talk about sort of two ways to think about the limits there. One is as these things grow, what are the emerging pain points that we see that we know of that are in terms of the existing technologies are running into pain points. And then the other one is the more model properties. So these already are failing us in some ways. And so how do we think about whether there are alternatives that do not have those same properties are these things that we can bolt on or do better with in the current systems and how do we do that? So in terms of existing systems and where we are, BitTorrent remains probably one of the largest decentralized systems in a sense. There are 3 million, 4 million active users out there on any given day, which starts to reach meaningful percentages of the global population that are actively using BitTorrent. We can think about one other aspect of BitTorrent that's sort of interesting, which is you've got a lot of users. But then you've also got this sort of metadata layer of finding new torrents. And that finding new torrents core that needs to exist to allow you to discover the peers that you are in, in your specific federated instance of BitTorrent, comprises of something on the order of 400 open torrent trackers that will maintain metadata. Also, the Academia DHT, which is a distributed hash table that is made up by more normal peers that store metadata. And there's roughly 4 million torrents that are contained in that distributed hash table of metadata about who is participating in which torrent. Another federated system that's had a great year is Mastodon as a exemplar of activity pub protocol and the Fediverse more generally has on the order of 3 million users. The activity pub Fediverse more generally is something like 50 different projects. There are on the order of 5,000 activity pub servers. There this fall, I guess, there's been measurement from the community data science collective academic group looking at activity on Mastodon specifically. They find something like 70,000 tooting users who collectively to roughly 30,000 times per day. And this sort of measured activity versus total users is not an unexpected ratio on pretty much any social network you would expect that the majority of people there are consuming or not posting public content. More broadly, when we think about federated things, there's a lot of even foundational internet technology like email that is federated still. There are on the order of 6 million email servers. That's a different IP addresses running the SMTP protocol. There are a bunch of WordPress servers as well that federate through comments and ping backs and so forth. JITSI reported this year that they have on the order of 20 million users of their primary service infrastructure. They didn't say how many independent installations there are because that's much harder to measure. And Matrix had a great year and has grown to 2.5 million users and has at least 11,000 independent instances. Moving again on this graph towards external impact IPFS past 2 million users this year, they have a DHT using the same Kedemli protocol as BitTorrent. But they self-select a smaller core of active nodes to participate in that DHT as a way to try and provide better latency and availability guarantees in it. And so their DHT is composed of somewhere in the 5,000, 10,000 DHT nodes. Of those 2 million users, somewhere around 20% or 100,000 are running sort of a desktop instance where they're staying on and are not being accessed through a web browser. And then participating in the DHT, one finds something on the order of 20 million different pieces of content that are being stored in IPFS. And in a given day, something like 8 million that are being retrieved through that DHT or being fined at about who had some. ServerSketlebutt is a offline first decentralized network. It's got a order of 10,000 users. And it uses public servers as a mechanism for storing and forwarding when users are offline. And it has on the order of 100 of those. Previously, I mentioned Earth Star that uses a similar partial replication. And this network is really going further on the decentralization and meant for small independent collectives than many of the others. And then finally, Bitcoin has only about a million active addresses or accounts and about 11,000 nodes that are running the full Bitcoin protocol. And this is not a dissimilar ratio to what you'll find on all of the other projects of this type. And so again, you've got this fairly large gap between users and servers or the sort of the elevated nodes that are doing more of the work in coordination. Part of that we can see in the Bitmark case is that in order to validate and run the full protocol, you need to have all the historic data, which is up to about 300 gigabytes in this case. So the cost of running this full node is non-trivial. It's not something you can run on a phone or even really on a local desktop necessarily. So from these, we can then say what are the commonalities that a bunch of these systems share? And I want to start by, I included in that, you might notice a lot of federated systems. And we can think of federation as this partial decentralization perhaps, that we've gone from a central Facebook or Google where there's one entity to these federated systems, Matrix, Jetsie, et cetera, et cetera, where there's a lot of instances of a server, but the server is distinct from the client. And we can then, there is this distinction to be drawn of, well, okay, there are things like BitTorrent perhaps, although BitTorrent has, again, a tracker that's sort of like the server that's separate from the clients, although the tracker is getting phased out to the DHT. And so the point is, and this is, I think, why I think of federation as a lot of the part is that what federation is doing in some sense is it's externalizing the heterogeneity of resources, which is you've got some nodes that are more powerful, that are going to be always on, that have bandwidth. And in a federated system, we sort of explicitly run a different software on them that indicates that, that is, this is the server software. And in systems that we think of more traditionally as true peer-to-peer, within the software, there end up being heuristics that try and do the same thing, that try and guess should this node take on more of the coordination work. Because one of the things that all of these networks want to do is make efficient use of resources, and those resources are not evenly distributed. Some nodes have more disk space, have more bandwidth, have better availability. And your system is going to perform better if you're able to take advantage of that. And so we can, and I think, you know, I don't know if I think of this as cheating, but you can think of these as two different problems, which is, there's one problem, which is how good of heuristics can I have to self-select nodes into being servers versus clients? And then how do I make decentralized protocols? And those are somewhat different. And as a result, you can say, do I need to figure out how to have good heuristics? Or do I just start with Federation, which seems to be getting us a couple orders of magnitude more users and more success? And then I can make packaging and make auto-selection of client and server, and opting into those positions be a thing that happens independently of that, or happens later as a different problem to self. The other thing that you can counter is that you think of message passing and how your communication model will happen purely in terms of a single node. And this is, you know, the natural thing that you end up with when you do that and you go on the full sort of, I'm a node and there are other nodes like me, but let's take the view of a single user or single node, is you end up with something that looks like gossip. This is what SecureSkettlebutt uses in a sense or is based on initially. And the basic concept here is I get a message and I want to then send it out to everyone else I'm connected to so that messages sort of disseminate through the mesh, through the decentralized mesh. And we have a bunch of optimizations on that initial concept. So things like I will then send out an identifier of the message to see if the person I'm going to send it to has already gotten it and then if they have, I'm not going to send it so that I don't waste the full bandwidth of sending that message over every edge. But one of the things that's true when you start there is there's no concept of the structure of the network itself, right? Because you're sort of considering a node in isolation, what you don't have is any ability to then pull back from there to look at the full network and start to say useful things about that. And so one of the things that is tough to say is will a message get to its recipient, how quickly will it get to its recipient? Because these are all questions that aren't about the single node but are about the structure and the connectivity of the network more broadly. And so it becomes hard to mesh this sort of communication with things like when should I form additional communications or additional connections? Who should I remember? And questions about how you maintain a strong network topology. And I think one of the things that we maybe need to be thinking about is how do you combine those two together so that you can have better guarantees and better understanding of the actual dynamic properties of these decentralized networks? Because we end up with very few properties that we can say useful things about in this sort of system of message passing by itself in isolation. To give a sense of a somewhat more concrete building block that ends up being the other one that we could use, that's distributed hash tables. And so a distributed hash table, which many of you have probably seen at least in passing, is that we've got a bunch of data and we've got a bunch of computers or participants in our network. And we're going to come up with some identifier, maybe a hash of both participants and content. And we're going to put them in the same name tag. So it's the same hash, right? And then the different nodes, the different computers will store the content that is close to them. So I'm a person at position three. I'm going to store all of the content that hashes to four, five, six until there's some other node. So I get some section of the space of content based on where I hash to. And then when I want to find content, I find the node that I know about that is closest to that content. And I ask them, and if they know someone closer, they'll forward me on to that person. And so I end up finding the node that is responsible for that content. And this has an algorithm. There's a few different implementations and dashes are in wide use. One of the nice things is that it's an abstraction that, you know, from outside you can sort of think of it as a centralized database that I can put stuff into it and I can get stuff out of it and I don't have to think about the dynamics within. And it has this nice property that it sort of grows as you have more users. You can expect the users to each bring data, but the data per user isn't necessarily growing. And so it's, you know, efficiently keeping data across all the different users. The other building block that we have here is coming up with consensus. How do a set of decentralized nodes agree on something? This is what we pioneered or, you know, this is what cryptocurrency really is relying on is you have a bunch of nodes that want to all agree on something. But that's, you know, a much more general problem. We've had this problem and have a set of systems for it in centralized systems for a while. And it turns out that's more efficient. But when you think of what the problem for consensus is in those cases, they've actually been able to get away with a weaker threat. So Paxos, Raft, these are protocols for consensus that work within a threat model of fail stop. And what that means is nodes that are broken may not respond. They may delay, they may freeze, they may crash. And despite some threshold of nodes failing or crashing or not responding, the system guarantees that the other nodes that are still working will agree on an outcome. But in a decentralized world, that ends up not being quite enough. That what you want is a stronger notion of what a bad node looks like. And so that's what gets called BFT, Byzantine fault tolerance. And that is tolerant of Byzantine nodes, Byzantine nodes being nodes that can act maliciously so they can send arbitrary messages. So it's not that they just fail to send a message, it's that they send a message indicating a different thing than they should have. And so Bitcoin came along, did proof of work. In proof of work, you are using sort of the scarce resource of computation. So how many times you can hash something as sort of a race that gets used to as long as the majority of the network is all following this protocol. And if someone is trying to do malicious things, they don't have enough power unless they are the majority to mess that up. And that's switched now, I think, because of environmental concerns and so forth, to proof of stake primarily. And proof of stake is instead of using computation as that scarce resource, it's using how much of the existing resource you have as that. And so there's a whole theory in here about things like if you already have a bunch of it, you don't want to lose it and so you're more likely to not do something malicious. But in both of these cases, these are not systems that lead towards additional decentralization. And one of the things that I think is at the heart here of a lot of the problems for decentralized systems is this question of symbols and identity, which is within the system itself, we don't really have any firm notion of identity. So who is a user? What is some entity or some collection of users acting on behalf of one user or are they multiple users? We can't meaningfully enforce that. When you think about how you enforce it, even for centralized systems like the Facebook or Google, they go to governments and they go to this, like, I'm going to identify you as a citizen or a person with some driver's license. And if you don't have that external authority, that stops making sense as a way to appeal to authority. And so instead, a lot of effort goes into trying to think about incentives and trying to make the system not make it worthwhile to appear as multiple users when you are in fact only one. But the flip side of that is that the incentive actually incentivizes centralization because it ends up meaning that it is better to be a single large entity than many small entities. And so that means that if it's better to be the single large entity, that single large entity becomes more and more powerful over time. So that was a set of building blocks. Let's go through limitations on these building blocks. So DHTs are something that we have. And they do grow with users. However, so as you get more users, you can have more content and the load and burden on each user and the DHT does not increase. However, there's a set of applications that you just can't really do with our current understanding of DHTs. So if I want to do web search and put identifiers for all of the web or for really many millions of identifiers, suddenly that's a lot of load that I would be needing out of each user on the DHT. So we can do something like a few million torrents total based on that user base. But are you going to be able to store hundreds of millions of items, all of the individual files and make those individually addressable? That suddenly becomes really hard. And so this is a question of naming and thinking about what is an identifier that I want to be able to search for or look up? What are the things that I'm putting as the entry points for lookups? The other one is an interesting or limit here in terms of scale that these things don't sort of fully scale is that a lot of the applications that we want are interactive in nature. So we want to be able to look up something and get a response in an interactive way that is compatible with web browsing or some sort of I'm there as a user. DHTs take something on, you know, asymptotically log in lookups to find content. So I find the node I'm connected to that's closest to it. They tell me someone who's even closer as a DHT grows that goes from two or three people that I need to talk to, to three or five. And if each of those is taking, you know, 100 milliseconds, that starts growing quite a bit to a point where even though it is log in, which is great, it's more than constant and it stops being competitive with our centralized systems. The second limit is gossip. As a gossip network grows larger, we start to really find ourselves in a situation where we don't expect messages to necessarily end up going all the way across it. And so we stop being able to say things about like, you know, I'm in a local neighborhood, but I can't necessarily find a friend through the network because it becomes way too expensive for all messages to go to the whole message, the whole network. And so there is something about network structure and about how you think about things beyond gossip that we need in order to scale those networks. And the final one is an infrastructural one, which is that there continue to not be real world incentives that are pushing the infrastructure that we have to support decentralized technologies. So it's still true, as it has been for decades, that a normal user's upload bandwidth is about half of their download bandwidth. This is true. This is a broadband fixed line one, but it's also true for mobile. But likewise, when you think about like latency between end users, when I think about a centralized system, the latency for me to get there keeps going down because they keep building edges closer to more of their users. And so on average, they actually end up getting closer to their users and lower latency. But when you look at, and this is a rape Atlas probe, you know, 2015 or 2010 till now, the latency doesn't actually go down much. Like it goes down and this is a bunch of nodes trying to get into Europe. And the latency from Russia goes down a little bit, but India is staying about the same. And we don't have money that's getting invested into the links that are getting translated for traffic between two different end users because that's not something that there's money that is incentivizing. And so until we figure out a way to solve that, we're going to end up with a very sort of static latency and bandwidth profile. Okay, I'm going to, I think running into question time, but I will finish with the more meta properties rather than the scaling limits that we need to think about. The first is coming up with a much stronger model of metadata exposure and privacy. We have end-to-end encryption. We're able to protect the contents, but we don't typically protect either the size or communication patterns of who's talking to whom. And without servers and intermediaries, I think basically all of these decentralized systems, less so federated, but even there, end user IP addresses and the identity of where they are and what they're connecting as ends up being something that is used for the disintermediation. And as such, there's no real guarantee about how private you are or who could learn that you're participating or who you're talking with. And so coming up with models where we get some limits on the retention, so being able to say things like, you know, at some point after you have stopped talking, the system will not continue to hold onto your IP address or who you've talked to, your communication patterns is important and is not part of any of these models. And so I'll end with two things that I go back to when thinking about this. The first is a paper on the impossibility of fully centralization and permissionless, and this is on blockchains, but persists, persistential consensus, which basically is the impossibility result that I brought up earlier when talking about how in order to disincentivize symbols, we move towards, we move towards encouraging centralization. And I think this is a framing question, which is the incentive to decentralize is actually an incentive that happens in a larger picture. It's not the system itself, but it's the entities around your system that are the incentive to not have centralization, right? It's the government, it's the regulations, and it's the other dynamics that are why you would want to not be centralized, and we don't have that in our model. And likewise, the tech policy perspective is saying essentially there are these very powerful existing entities that will attempt to identify the points of power and regulate them. And that ends up being why we need this decentralization in some sense is to prevent being co-opted by existing systems of power. That's where we find the motivation for decentralization. So I will end there. I guess we have maybe a couple of minutes. Third questions. You're muted for me. Yes, thank you. We have a few questions from the audience. First is, what do you think is the future for decentralized social media? Does there have to be a major event for decentralized social media to gain more traction? It's a good question, right? So social media is an interesting and problematic beast in its own way, right? Which is this is something that we haven't really traditionally had in the same way. And so one of the questions maybe to step back is what do you actually want? I think the part of social media that is you and your communities and your friends, I think we already can do and will continue to see more localized things because they give us the same experience. Figuring out how you broadcast a celebrity or these sort of more large-scale zeitgeist ideas is where we are much less developed. And so part of that less developed also means that there's more potential for further technological development to make that more possible. So I'm optimistic that we get there, but I think that's further off. Okay. And another question related to that, but probably more into direction of user experience, can we abstract decentralization to ease the use for the average user? Yeah. I mean, and there's a couple of things there, right? Which is we are certainly have libraries and patterns that other developers can build better user experiences on. I think we're seeing also that there are easier to use sort of end user compatible systems that are views into decentralized networks. So be that the things like manyverse or planetary, which are mobile apps that came out this year for secure Scuttlebutt or Radical and these just sort of desktop apps that provide Git or other types of decentralized network views that don't require setup or work. We're getting better user interfaces. And we're having building blocks that are not themselves particularly visible or require configuration. And a more technical question that just came in. What do you think of the trade-offs made by single hop DHTs and their huge local routing tables? Right. So this is an interesting question. And it's where a bunch of thought is being put right now. And so one of the things you could say, right, is in the same way that a federated system is externalizing this disjoint resource or resource heterogeneity between sort of highly available nodes that might make up your DHT and the sort of end user more transient nodes that are querying it. You could have a DHT that tries to self-organize to take advantage of even more heterogeneity. So you find nodes that are more powerful and you have multiple players or a hierarchical DHT where some DHT nodes forward queries into a smaller center that's more powerful. And you end up with something where you probably can get rid of some of these log-n style latency things to make them be able to scale more at the expense of something that starts to look like more centralization. That there end up being a smaller number of nodes in the center that if they do go down or if they decide to send their things, they actually can have really, they end up with a lot of power in the system, which is starting to be scary. So there's a trade off there. And next question, given the popularity of Cademlia, have probabilistic models won the decentralized architecture or are they better suited to decentralization? That's a good question. I think Cademlia, I don't know if it won just because it's probabilistic. I think it has something to do with, it's fairly simple to conceive of. We often say these distributed systems are really hard to reason about. And in some sense, that's like this, I've done one thing and I'm out of ideas. One thing that I took away at least from that set of building blocks that I presented was there were only three or four things that are underlying all of these things. We really have not looked through a lot of this design space. And so I am not at all unconvinced that trying something radically different, we can find other models of decentralization that are more performant and that have different properties and we just haven't explored enough. So I think that's a no. Okay. And the last question until now, do you think decentralized writable storage like IPFS is threatened by toxic data sets like Libgen? Okay. So there's an assumption that Libgen is a toxic data set. But beyond that, I mean, I think there's a very reasonable story for any of these systems for how you sanitize them or make them compatible with external power structures. And so in an IPFS like thing, users are opting into pinning or storing data as notes. So it's only either you've decided to pin data in order to make it reavailable to others. And so there are, as a node, if you get a DMCA complaint or you get a complaint that something is illegal, you can blacklist it. You can say, I'm not going to pin or reserve that data. And so there's a way for each individual user in the system as they get complaints to not make that data reavailable and limit their liability. So you'll get, as there's different regulatory environments, people will be able to comply with their own regulatory environments. And so I think that is probably enough. And the bigger question is, OK, does that cause the software to be seen in the same light as BitTorrent? And that's, I think, a more philosophical question and is as much a perception and finding good uses that you can counter things with as anything else. OK. Thank you. That was a question. Thank you for the interesting talk and for being here answering the audience questions. Thank you. But this is 씨가.
and security among other things, things that the find our community and we can talk with federated think, not only have things that support your organizations is that you can maintain a contract of how this organization will work remain decentralized in that there's not a single that I would consider decentralized systems to of 3 million users. The activity pub Fediverse past 2 million users this year, they have a DHT nodes that are doing more of the work in one entity to these federated systems, Matrix, end up with something that looks like gossip. which many of you have probably seen at least in we've got a bunch of computers or participants in identifier, maybe a hash of both participants and responsible for that content. And this has an algorithm. There's a few different set of decentralized nodes agree on something? what cryptocurrency really is relying on is you a set of systems for it in centralized systems been able to get away with a weaker threat. So lot of the problems for decentralized systems is the flip side of that is that the incentive there's a set of applications that you just can't fixed line one, but it's also true for mobile. there keeps going down because they keep building time, but I will finish with the more meta properties rather than the scaling limits that we And without servers and intermediaries, I think talking, the system will not continue to hold the points of power and regulate them. And that the motivation for decentralization. So I will have to be a major event for decentralized social be able to scale more at the expense of something often say these distributed systems are really any of these systems for how you sanitize them or