Quantifying Decentralization - Balaji Srinivasan | Silicon Valley Ethereum Meetup

Let's get started. So our first speaker is Balaji Srinivasan. Balaji is the founder and CEO of 21Co. He's also partner. Partner. The recent Horowitz. And I have to say I had the great pleasure of teaching our crypto class. Sorry, our cryptocurrency class with Balaji, who actually helped a great deal with the lab for the class. So, Balaji, looking forward to your talk. Thank you. Okay, does that work? All right, great. Okay, so today what I'm going to talk to you guys about is basically this idea of quantifying decentralization. So just by show of hands, which of you guys were at the Blockstack Summit in July? Okay, only a smattering. Okay, so that's good. So some of this will be, you know, overlapping with that, but there's also a fair amount of new content. And so, you know, Dan was kind enough to intro me. That's me in a suit. Only picture ever taken. And so basically, I'm actually a Stanford lifer. You know, almost 20 years ago I was an undergrad moving into one of these dorms, and Now I'm running 21Co. And what we're going to talk about today are basically three things. So most of it is going to be about the motivation behind a simple metric for quantifying decentralization. And at the end, I've got funding for anybody who's a developer who wants to build a decentralized dashboard. We've got a great domain name, decentralized.com. and so if anybody actually wants to code that, I can provide some funding. And, you know, basically you can implement some of the ideas in here to make a real time dashboard across coins to look at these decentralization metrics. And third, we've got a new token, and it's not an ico. You can just go and sign up for it@socialtoken.com and basically the idea is this also partially redresses some of the issues that I bring up in point one. Okay, so further ado, basically, when we think about decentralization, this is something that everybody talks about endlessly. In fact, it's something where, you know, everyone's going to say it's important and in fact is the most important property of blockchains as opposed to traditional databases. But in order to say that something is more or less decentralized, you need to have a quantitative metric. So just to establish that, you know, everyone agrees that decentralization is important, here's Satoshi's launch of Bitcoin. Actually it's like maybe about a month or so afterwards. But, you know, in the second sentence he says, you know, the unique selling point of Bitcoin, the attribute is it's completely decentralized, right? Nick Szabo says, you know, it's what allows Bitcoin to an army of computers. Vitalik was right here, said, you know, it's viewed as a blockchain's entire raison d', etre, but one of the words is perhaps defined the most poorly. And Adam Ludwin, who's a chain CEO, says with a very related thing on censorship resistance, that decentralized apps are not only better, they're arguably the only solution for a certain kind of application. So everybody kind of agrees that this concept of decentralization is important and that it's a key feature that distinguishes blockchains from centralized databases. And so the thing is that it'd be really useful to have even an imperfect measure with which to quantify decentralization. As I'll show later in the talk, imperfect measures of performance have allowed us to improve programming languages. Imperfect measures of what is a hot dog or not a hot dog have allowed us to develop apps like in Silicon Valley and in fact the entire field of machine learning, you know, featurization is an imperfect quantification of something. The thing is that if you can quantify something, even if imperfectly, once you can measure it, you can say, okay, this improvement or that improvement, increase the value of this function, and then you can actually plug that into an optimization algorithm. You know, many of you guys here, you know, if you're Stanford students, you've taken convex optimization, but basically optimization requires a so called loss function, something that actually measures the property of something. So if you want to design an optimally decentralized system, you need to actually have some kind of quantification of what decentralization is. Okay? This is kind of motivation. People think it's important and that if you could quantify it, it would unlock a whole body of mathematical tools that you could then apply to the situation, which would hold even if that quantification was imperfect. Okay, so to get there, to get to a quantification, we're going to just introduce a few concepts. So first is this idea of the so called Lorenz curve. Now this is something you've probably heard about maybe from economics, Lorentz curve or the Gini coefficient of, um, it's used by economists to measure inequality. And the idea is that inequality of money and centralization of power are actually similar sorts of ideas, right? So let's just review these two, two ideas, right? So with the Lorentz curve, basically it goes from the concept of perfect equality where everybody has exactly the same amount of something. Let's say it's Ethereum or Ethereum mining capability or you know, commits to a code base. If everybody was exactly equal and they all had, you know, one Bitcoin, all, you know, 7 billion people, which is not actually possible, then you'd have a perfect equality like this, where it just, it just basically be a straight line. Whereas if you had total inequality, only one person has everything and everybody else has nothing. Okay, and so this is this concept of the Lorentz curve, which is basically this, this, you know, this graph. And the Gini coefficient is essentially a measure of how concentrated the Lorentz curve is. It's zero when you're completely equal and it's one when you're completely unequal. And these are kind of two examples along that continuum. And so that's concept number one. Now concept number two is that we can take a decentralized system, break it up into subsystems, and measure Lorenz and G coefficients for each one. Now, I want to be absolutely clear. The subsystems I'm about to show, these are for illustrative purposes only. I don't argue that they are the only ways you can decompose these things. And the Data is from July 2017. We'll do an update of this. Actually, I've got some funding for somebody who wants to make a real time dashboard of it. So with those two caveats, let's take a look at these decentralized subsystems. The basic idea is that you can take a public blockchain and you can enumerate a set of essential subsystems. For example, again, just for illustrative purposes, let's say that we say there's these six essential subsystems, right? So mining, you know, that is to say the distribution of block rewards across miners, the different clients and you know, how they're distributed in production across, you know, nodes that, you know, you can actually see, you know, what percentage of share is owned by different code bases, developers. And so within, let's say the most popular repository, Bitcoin Core or Geth, what is the distribution of commits, exchanges? And you could see kind of what the distribution of volume is. Is it all focused in one exchange or is it spread out nodes by country and then ownership by addresses, Right? These are just examples of subsystems. And then for each of these, what we can do is we can calculate Lorenz curves and Gini coefficients, right? So you know, if we take the last 24 hours of Bitcoin mining, it's actually fairly spread out and a bunch of different folks have earned some. And so this actually has a relatively low Gini coefficient. It wasn't actually that that centralized at the time that we measured this. Client decentralization. Most bitcoin clients are running Bitcoin core. There's some that are running, you know, ABC or you know, Bitcoin Unlimited or what have you. Developer centralization. So by commits to core, basically the idea is, you know, okay, how many commits to the first developer have the second most commits or the commits by the second most contributing developer and so on. That's actually fairly concentrated, not as much as clients. We can also do this for exchanges and for nodes and for owners. So we can say, okay, you know, across exchanges, what is the distribution and share of 24 hour daily volume across countries, how many nodes are in each country, the US and China and what have you. And across owners, how much is held per address? Given that we impose some threshold, and that's actually important given that most people in the world have 0 BTC or 0 Ethereum, unless you impose a threshold, this is just going to trivially be 0.99 and I'll return to that point later. But given a threshold, you know, what does that owner decentralization look like? We can calculate these curves also for Ethereum, right? So you know, mining Decentralization Ethereum again, just over a 24 hour period. Client decentralization dev decentralization. So there's a lot of the top two people in Geth have actually contributed a very large percentage of the code. Exchange decentralization again, volume across exchanges, no decentralization across countries and owner decentralization. So this gives some sense of, given this choice of subsystems, this choice of metrics, how centralized they are. And the idea here is that we could take a maximum over these and say a decentralized system is only as decentralized as its least decentralized subsystem. And the reason for this, just to understand is there's like a decentralization bottleneck, right? If everything else is decentralized, but you have one component that's centralized, the system is centralized because you can then go and grab that bottleneck. So as an example, if we just take a table like this, it doesn't matter in this particular circumstance that, you know, Bitcoin was highly decentralized in terms of block over the past point for hours, if you could just compromise a particular client, then this is the most centralized row in that table. That is to say, the number one client is the most centralized component, again by this measure. And the other metrics wouldn't matter as much because if one portion is centralized, the whole thing is centralized. Now, one can object to the Gini coefficient because it doesn't really give mechanistic insight into what you have to compromise. So we have a modification of it that we call the minimum Nakamoto coefficient. And the idea here is basically to go back to the Lorenz curve and say, okay, what if we do something that's a little bit more intuitive and we say, okay, how many entities do we need to compromise to get to 51%? So we call it the Nakamoto coefficient, you know, motivated by the concept of the 51% attack in Bitcoin mining. And of course, you know, in any given subsystem, you might need to compromise more or less than 51% to compromise that, that subsystem. But the idea here is that we can again go back to each of these graphs. We can say, okay, you know, The Nakamo coefficient is 4. In order to compromise Bitcoin mining, you need to take the top four miners and compromise them to get 51%. But you only need to compromise one client in order to get more than 51% of nodes. But you have to compromise five devs to get more than 51% of commits and so on. Right? And 51% is an arbitrary number outside the context of mining. You could change that threshold. But this starts to give a sense of how many entities you need to compromise in order to get past 51%. And we can do this across exchanges and nodes and owners. And we can also do this for Ethereum, right? And we can say, okay, you know, two miners in this 24 hour period, you know, mined most, you know, more than 51% of the Ethereum. And again, in this particular 24 hour period. And when we do all this and we tote it all up, we can look at these tables across Bitcoin and Ethereum and we can start to see, okay, you know, holders, at least by, you know, this metric, are actually relatively decentralized, but, you know, the clients are actually fairly centralized in the sense that the most popular client has a very large market share across nodes. Now, all these things are subject to change over time. I'd like to get a real time dashboard together. So, you know, if you measure this today, it may be slightly different and what have you, but the general concept here of using benchmarks to identify A decentralization bottleneck is, I think, a useful and valuable one. Now, there's obvious objections, and I want to try to head some of those off at a pass, right? So first, the choice of subsystems matters a great deal. Second, you might not consider all substance systems important. And third, very important question is these kinds of measurements mean anything? Do they actually relate to concrete attacks or is just, you know, kind of fooling around and so just kind of enumerating those, you know, to discuss those obvious objections. So, for example, one point that Vitalik brought up is if you measure Geth versus Parity versus Swarm, those are actually, you know, especially Geth and parity are like, you know, independent code bases, completely independent code bases. Whereas if you look at the top Bitcoin clients, well, you know, Bitcoin Unlimited and, you know, ABC and so on are basically forks of the Bitcoin core code base. They're not full, clean reimplementations like BTCD or what have you. It turns out the most popular clients in the Bitcoin ecosystem are forks, right? So you can argue that those aren't actually truly independent code bases. And because of that, then, you know, it's more likely there's going to be a shared bug across these. There's going to be a shared bug across Geth and parity, right? Okay. So you want to define your subsystems carefully and you can modify the metrics that I chose. That's why I said they're illustrative. They're not, you know, meant to be definitive. Just to show the general idea. The second objection you might make is you could say certain subsystems just don't matter to you. Right? So, for example, Satoshi, you know, famously back in 2010, he said, you know, I don't believe a second compatible implementation of Bitcoin will ever be a good idea. Right? So he would say it doesn't matter. Dev centralization, client centralization doesn't matter. But he does care about the 51% attack, at least at that time. And then third is subsystems you'd want them to map to attacks. So basically, if you had a 25% compromise of mining, that might be more Serious than a 25% compromise of accounts, because you could execute, for example, a selfish mining attack if that attack is feasible. And so one way to respond to all of these collectively is if you enumerate hypothesized attack types, then you can choose your subsystems accordingly and then measure the decentralization of each one by something like the Nakamoto coefficient. So for example, let's say that you are looking at the news and maybe Country X might nationalize or even acquire mining companies. In that case, you'd want to measure the hash rate across countries and make sure your system was robust to an attempted Chinese action nationalization of mining. Another example is if you expect the attack that you're looking at is there's a bug in one client's code base, you'd want to have market share across nodes spread out such that you know, if there's something like the remote crash bugs in BU and Bitcoin Core or the parity multisig bug, the entire ecosystem wouldn't be affected by one client. And just to be clear, everybody who's working on these projects, they're awesome engineers and what have you, I'm saying nothing negative about them, simply that maybe not having all eggs in one basket may be a good idea if you suspect this might be an issue for the ecosystem. Third example. So if anybody remembers, in 1996 Phil Zimmerman was prosecuted for rolling out PGP. So if only one developer is doing all the commits for an important client, well, there is a history and there's a precedent for government prosecution or what have you of that individual. So having that spread out could be good if you think this is going to be attacking an attack. Fourth example, one that's not even theoretical. So you know, a country shuts down exchanges. So in this case, you know, like the Chinese shutdown of btcc, you know, K Coin and Huobi, you'd want to have volume measured across countries and make sure no one country has, you know, too much of the volume, such that if that country shuts it down, it can still operate in other countries, right? Fifth example. So if you've got nodes that are running on AWS or Google Cloud and they suddenly decide those nodes violate your acceptable use policy, you don't want to crash the network, right? So you want to make sure that you've got unique server entities that are serving them. And in some cases, for example, people will dial up hundreds of nodes on AWS or Google Cloud, but that doesn't really fully add to the node count. In the same way, it might be able to process traffic, but it's not independent control because it could all get shut down at the same time. So actually having independent IPs independent control is very important if you believe this attack is a potential one. And then last, just as an example, if you have a very, very unequal distribution of digital currency, at some point there may be a political attack where those without digital currency vote or support seizure from those who have it. So, you know, many examples of this in history, but a very recent one is in Venezuela. People voted to redistribute land, and that really backfired. NPR has lots of articles on this. Everybody does at this point. So that's an example of how, if you believe this is a potential attack in the future, you'd want to actually maximize decentralization in terms of ownership across individuals. And again, these are not, you know, just to show you some screenshots, if you've got mining centralization, then China banning Bitcoin executives from leaving the country, that's a feasible attack. If you've got client centralization, then, you know, the Bitcoin core or the BU or the parity multisig attacks would be bad. If you've got dev centralization like this Zimmerman, you know, prosecution of Phil Zimmerman, then you don't want to have only one dev who has the knowledge to modify the code base, exchange centralization. If it was all centralized in China, we would be in big trouble. Fortunately, it's not. There's Japan and there's the US and others. This guy got his account just shut down randomly by Google. So you really would not want Google or Amazon to be able to flip a switch and be able to turn off all nodes. And as an example of how holder centralization could be troublesome, the IRS actually imposed a threshold and said anybody over $20,000, they want investigate. If they've done that much business on Coinbase, they're trying to just get a list of everybody, right? And so if that list was millions and millions of people, then there'd be more of a political outcry against, you know, this. This sort of thing. So essentially, this is how you can think about decentralization, providing resistance. Different kinds of attacks lead to different subsystems and measures. And for each of them, you can calculate like a Nakamoto coefficient. And you can say, okay, in the event this attack happens, what is the impact on the Nakamoto coefficient? How. How much more centralized does it become if that attack happens? And how can we allocate resources to prevent that from happening? So, two more points, and then I'll quickly finish up. One thing I want to, you know, talk about is that even imperfect quantification can lead to useful results. I don't argue that this is the final metric or what have you, but if you guys saw Silicon Valley, you know, the show Hot Dog or not Hot Dog is actually a very sophisticated machine learning application. You Wouldn't believe it, right? And, you know, so there's a great medium post on how they designed it. But one of the things just to keep in mind, if you guys have ever done any machine learning, is no one feature determines what a hot dog is. You know, when you're doing supervised learning or anything like that, it's all these imperfect kinds of heuristics. But collectively, they start to bring this fuzzy kind of object, this notion, into being. A combination can give useful results. Similarly, if you've seen this Benchmarks game, this is actually, you know, it's very carefully phrased, this website. It doesn't say which programming language is the fastest, just like we don't say which blockchain is the most decentralized. It says which programming language is the fastest on this toy benchmark. And in the same way, which blockchain is most decentralized on this benchmark? That's kind of the thing I'd like to drive towards where we acknowledge benchmarks are flawed. But a collection of benchmarks can potentially give useful results and help us think about things. Finally, I would say, you know, decentralization cannot be, in my view, achieved through one coin alone. Every group of, you know, coin developers, token developers, has a different thesis on what kinds of attacks they consider reasonable or probable. And so, you know, strength in numbers and a lack of monoculture, I think would be good. So that's one of the good things about this current ICO and token and coin mania is we're getting many, many different kinds of approaches, each of which hopefully is robust in different ways to different types of attacks and decentralization. So, just to summary. So we propose a simple metric of decentralization. It tracks with our intuitive notions. Given a list of subsystems, you can start with attacks, get subsystems that correspond to those tacks, and then measure the Nakamoto coefficient for each one. And once you've got this, you can start putting in dashboards and objective functions. So just in terms of what's next, we're doing two things. So if any of you guys want to come up afterwards, we'd be happy to fund a dev to do something@decentralized.com, that URL doesn't resolve right now, but we have it. And so we'd like to get something like this Benchmarks game with Lorenz and Genie and Nakamoto coefficients for many different coins and subsystems. And each person, just like the Benchmarks game, can check off the metrics that they think of as the most important, and they can Use that to argue with somebody on Twitter or Reddit, which is what we all love to do. And so this, I think, will be fun, because it's something which at least starts to quantify this thing that all of us know is important. And I'm not saying this is the final way of doing it, but I do think that it starts to move us in the right direction. The second thing we're doing is if you go to socialtoken.com, we do have a new kind of token. It's non ico. In fact, part of the goal with this is that rather than people giving us capital for tokens, they would give us labor for tokens. And many, many more people can, you know, go to a website and click some buttons than can afford to invest thousands of of dollars and a new coin. So if this works, you know, it would be highly decentralized by at least one measure, which is the number of holders. And that would protect us against a political attack where too many people don't have digital currency and they get mad at the people who do. I don't argue that it protects us against a mining attack. I don't argue that it protects us against a node attack or what have you, but I do think that a multitude of different approaches to protecting against attacks and decentralization is valuable, and this hopefully can contribute to. To that. So you can check that out@socialtoken.com if you want and just go and go and sign up. So that's it, you know, thank you and happy to take questions when, you know, for a few minutes, and then maybe we do the panel afterwards. Yeah. Yeah. So we have time for a few questions. Joseph, do you want to get up, come up here and get set up? Yes, please. It seems like anything that has a really long tail is going to have a myotino coefficient, but that doesn't necessarily seem like it's not decentralized. Yeah, so actually, Bella, do you want to repeat the question? Yeah. So he said anything that has a really long tail is going to have a high Gini coefficient, but it doesn't mean that it's not decentralized. I would agree with that. And that's actually why we think this Nakamoto coefficient starts to get to a better idea of what it is, because basically, the Nakamo coefficient is more intuitive. You can say it's a number of entities you need to compromise to control 51% of that subsystem. That's like something you can get your head around. It's like okay, we need to control four miners in order to control 51% of hash rate, or we need to control 72 people in order to have more than 50% of Ethereum. Right. That kind of thing. And that's, I think, easier to reason about. Yes, sir, in the background. Let's take one from the other side. Hey, thank you for doing this research. Super important. I've seen a similar kind of analysis in brain research. It might be useful to look into. If you crack open dead people's heads and look at their neural topology, turns out that people are on a bell curve. Neurotypicals have average many column lengths. And then if you have unusually short, like hyperconnected clusters in your brain, then you're more autistic. And then if you have like more stronger global connections but weaker local connections, then you're more dyslexic. And so they take these things like they form a metric between different points in the brain and then they have a threshold like you have, but they move the threshold from 0 to 1 and then record how many of the connections are sort of the paths are less than that threshold or more. And how does that grow? And so if you get like a really convex or concave. Anyway, I just want to share that I thought that would be new direction in cryptocurrency research. If anybody wants to really make a sacrifice for Ethereum, I'm happy to crack it open and take a look. No, but actually also, my dear, thank you. Thank you. Yeah. How does the idea of decentralization reconcile a gel with the idea of capitalism? Basically in capitalism, for example, if you have two nodes, they're identical, they'll eventually get owned by a single entity because the marginal cost of ownership and operation is lowest into a single entity, basically. So how does decentralization work with capital? Well, I, I think we're actually, you know, on the cusp of something which is step in which we can organized humans. Right. Like so, you know, Ethereum, you know, is not something that Vitalik is actually CEO of. Right. Like it's something that is a decentralized organization where anybody can enter and take like almost equivalent of an equity stake and then work to make it better. And there's no direct command and control sort of hierarchy. And yet folks have made money on it. A lot of, a lot of money. So, you know, that preserves some of the aspects of capitalism in the sense of folks can collaborate to, you know, put food on the table, but it is not as command and control. So, you know, I'd say economics is Going to take a BE a V2 over the next few years. Yeah. Hey, one more. Why don't we take one more question? Yeah, please. Oh, I can be loud too. So my question really is around when you talk about decentralization and you introduce the social token, for example, which is really introducing it to a broader amount of people. But is there actually an aspect of the self selection that would actually ends up with the steel being centralized around those who would have access or know about or participate in it in the first place? And what is the impact of that initial connection between those aspects? That's a good question. So in general, I think lots of technologies start with the 1% and then they get to the 10% and then the middle class and then they get to the 99% and so on. So cell phones are a great example. In the 80s that was just a province of super rich guys on Wall Street. And you know, today we've got billions of cell phones and you know, folks in India and Africa and so on. Actually I saw a stat recently that more than 50% of the world now has a cell phone. And so the thinking is this is, I'm not saying it's a final step, but this is the next step, I think, in starting to get a much larger cross section of folks involved in digital currency. And then, you know, from that, hopefully we can build from that base and get it even more mainstream over time. It's very cool. Thank you. Apologies. It's fantastic.