CESC2017 - Balaji Srinivasan - Quantifying Decentralization

So I've got a very kind of simple talk today which is about a metric for actually quantifying decentralization. And the reason this is important is that many different kinds of attacks on digital currencies and blockchains and so on are in the form of, hey, how many folks do we need in order to compromise this, in order to centralize it on this dimension or that dimension? Can we centralize money and do a 51% attack? Can we knock down exchanges? Can we corrupt nodes and launch Sybil attacks and so on? And I've got a simple, imperfect, but interesting and universal measure of how decentralized the system is. And you can use it to identify decentralization bottlenecks. And just as motivation for this. The reason this is important is until you have a quantitative measure, even an imperfect one, you can't say whether one system is more or less decentralized than another. And you certainly can't say this is the optimal level of decentralization given SC scarce resources. So a metric is the first step towards trying to make our conversation around decentralization and blockchains a little more scientific. Okay, with that as motivation, here's my background. I'm 21, CEO and partner at Andreessen Harwood, so you might have heard of us. And so, as I mentioned, today we're going to talk about a simple metric for quantifying decentralization. I've got funding for a decentralization dashboard. Actually, I got a couple engineers working on this. When this is live, we'll have it up@decentralized.com, which is a pretty good, good URL. And we've got also a new token which is optimizing on at least one dimension of decentralization, which is ownership, coming out@socialtoken.com, but most of it's going to be about this first bit. So when we talk about quantifying decentralization, everybody agrees that decentralization is important and that typically the more decentralized system is, the more censorship resistant it is. But to say that it's more or less, you need to have a quantitative metric just to level set and emphasize how important decentralization is. When Satoshi introduced Bitcoin in the second sentence, one of the key selling points was it's completely decentralized. And igsabo decentralization is what allows bitcoin to substitute an army and vitalik on decentralization viewed as a blockchain's entire raison d'. Etre. Adam Ludwin of Chain Basically, it's pretty clear that most of the folks in the space talk about decentralization as if it is the sine qua non of what makes blockchains blockchains. So it would be great if we had some quantitative measures of this incredibly important thing.

Thing.

And so the reason that quantification is important is if any of you here is familiar with optimization theory or the concept of what a loss function is. Until you can actually have a loss function, you can't plug in all the tools of optimization theory, whether that function is convex or non convex, whether the set over which you're optimizing is convex or non convex. You need to at least have a function before you can start approximating things. And what I'm going to propose through this, I'm going to motivate a function and then show you that function which we call the minimum Nakamoto coefficient. Okay, so that's motivation. Let's just introduce a few kind of concepts leading up to this measure. So first is this idea of the Lorenz curve and Gini coefficient, right? So the Lorenz curve, it's used by economists to measure inequality. And typically, inequality is a concern of one political faction and centralization a concern of another. But they're actually quite similar. That is to say, inequality of money and centralization of power are not synonymous, but a lot of the measures are similar. And so let's review these two ideas of the Lorenz curve and Gini coefficient. So if you have a population where everybody has exactly the same amount of money or power, you'd have a uniform distribution. It'd be flat over here. And if you sum it, if you integrate it, if you take the cdf, you have this triangle like this. The more skewed the distribution of money or power or what have you, the more unequal, the more centralized. And so perfect decentralization would be. Everybody has exactly the same amount of power. Perfect centralization is one party has all the power. Okay, so it's kind of interesting you can actually start thinking about this in this sort of systematic way. And a second kind of concept is if we take a decentralized system, we can break it up into subsystems. And all these subsystems, by the way, are for illustration only. I'm not arguing this is the canonical decomposition or anything like that, but it is one way of decomposing things. And then we can kind of go and review, right? So for illustration, there's six subsystems of Bitcoin that I've just chosen here. And you can add or subtract different subsystems according to your threat model. So, for example, with mining, you can look at that as a subsystem and we can analyze its centralization on the base of its block reward. With clients, we can see, okay, of these different code bases that have been kind of deployed among different nodes, what percentages run, let's say, Bitcoin core versus btcc, or rather BTCD and other kinds of clients among a particular code base, how centralized is development? Is it 1000 developers all doing it, or is it just a couple, or is it something in between? With exchanges, how centralized are they by volume? If you take down one exchange, you knock out the entire trading volume of this coin. With nodes, can a country just go and block all of these nodes, or are they spread out between countries? And with ownership, how concentrated is wealth? Is it just that one person owns it, or does everybody own it and a lot of folks have a stake in it? And again, I'm not arguing, arguing each of these are of equal weight or anything like that. I'm just giving an example of how you can take a subsystem, or you can take a public blockchain, decompose it into these decentralized subsystems, and then analyze the centralization of each one. The reason I went with these six, just as illustrative, for illustrative purposes, is each of these has been at one point or another, the subject of a political dispute within the digital currency community over how centralized or decentralized it is. Mining is centralized, development is centralized. You'll always hear these things bandied around. I take no position on that. Just trying to give some measures so we can at least kind of quantify the argument. Okay, so for each of these subsystems, we went ahead and we converted. You know, we calculated the Lorentz curves and Gini coefficients. So here it is for mining and for clients and for developers. So, for example, you know, it's very skewed by clients because one client, you know, bitcoin core, is actually responsible for the vast majority of nodes on the network. That may be a good thing in your mind. You may decide that this is not an important graph and you can just throw it away, but just the measure of it shows it's fairly centralized in terms of how nodes are running it. For exchanges, for nodes and for owners. We also calculated all this stuff, and all this stuff is online. If you Google quantifying decentralization, there's a blog post we did. It's at News Twam Co. You can see that blog post. So we calculated this for Bitcoin and we did the same thing for Ethereum. We looked at the decentralization for mining and for clients and for developers. So for example, for developers we're looking at Geth, the primary reference client. We're asking, okay, how many commits did the first guy make of all the developers versus the second guy versus the third guy? In terms of their rank ordered distribution of commits? We find that the first few folks made actually a fairly high percentage of the number of commits. We also looked at their exchange decentralization and no decentralization and owner decentralization. For Ethereum, this is useful. These kinds of graphs are interesting, but one of the issues is if I say a Gini coefficient of 0.85 or 0.76, it's hard to actually really wrap your heads around what that means. And so we propose something which tracks with that, but it's a little more intuitive, which we call not the Gini coefficient, but the maximum Gini coefficient, which is a decentralized system, is only as decentralized as its least decentralized subsystem, right? So if you take all of these Gini coefficients together and all these Ethereum Gini coefficients together, you can actually say, okay, if I take the maximum of them, that's the subsystem which is the most centralized in both of them. For both Bitcoin and Ethereum, the single most centralized component, at least by this crude measure, which I acknowledge is crude, I acknowledge it's imperfect, but this crude measure is actually clients, where basically you're looking at clients and saying, okay, the top client is actually pretty centralized in the sense of the vast majority of nodes in the network are really just running one client. It's not like web browsers where you've got Firefox and Safari and Chrome and IE all with a reasonable amount of share. It's really mostly just one major client. So this is one way of trying to summarize it. And the utility of this is we can identify, even crudely a postulated decentralization bottleneck. We can say, given scarce resources, we'd like to decentralize this more. And allocating more effort in some other subsystem may not be as valuable if and only if you consider this to be a useful metric. If not, you can throw that away and take your maximum over the remaining columns. Okay, so this is kind of a step forward in the sense of we can start to get our heads around this idea. We take this complex idea of a Bitcoin or Ethereum this decentralized system break into subsystems, measure decentralization coefficients, Gini coefficients across each, and then try to calculate the maximum. But even still. 0.915 Gini. It's not super intuitive. Can we do even better? And we've got, I think something which is a little more intuitive still, which we call the minimum Nakamoto coefficient, right? And the idea here is if we go back to the Lorenz curve, and now we ask something that's a little more like an integer, right? We say, how many people or how many entities do you need to capture in order to capture 51% of the money or the power, right? And so in this case, for example, you know, with 100 people, you need to capture at least 50 people in order to get half the power. Whereas here it's much more skewed and you'd have to capture eight people in order to capture 51% of the power. That captures an intuitive integer kind of measure of how centralized the system is. Here eight people control more than 51%. Here it's like so even that you need to get 50 to get 51%, right? Okay, so if we counted the Nakomoto coefficient for these systems, it's basically like four miners, you'd get to more than 51% of block rewards. One client, you'd get to more than51% of the Bitcoin node code base. In terms of clients, it'd require five developers of Bitcoin Core to get to more than 51% of commits. It would take five exchanges to get to more than 51% of exchange volume. It would take three different countries to get to more than 51% OF nodes. And it would take about four hundred and fifty six holders to get more than 51% of Bitcoin. For large holders of Bitcoin, that's an important thing because if you include everybody in the world, most people in the world have zero. And so then you're going to have like a trivial coefficient of 0.99. So you can decide whether or not you consider that one important. But that's just something where people always ask for it. So I include that measure. We can do the same thing for Ethereum. So at least over this 24 hour snapshot, there were two miners that had the majority of the block reward. This varies actually a great deal with clients. Again, Geth, one client has the majority more than 51% of nodes running it. There's two developers that have more than 51% of geth commits. Again, at the Time of this snapshot, five exchanges have more than 51% of Ethereum volume, four countries had more than 51% of Ethereum nodes, and about 72 holders had more than 50% of Ethereum conditional on them having a certain large amount of Ethereum. Again, otherwise, without that boundary condition, you don't get a very informative thing. And the thing that's interesting about this is we can calculate very similar tables where we ask, okay, for each of these kind of columns over here, how many folks, how many entities do we need to capture in order to capture it? We see that basically clients are the bottleneck in both cases, where if you capture one client code base, you can centralize the network, and other subsystems are less centralized by comparison. And there's obvious objections. This is an imperfect metric, in the same way that if you go and take 1,000 images of cats and label them as 0 or 1, you haven't necessarily captured the essence of a cat. But it's while imperfect, still useful, because you can start training machine learning algorithms in the same way. I would argue that while the choice of subsystem matters a lot, and subsystems, some subsystems may not be important, you can nevertheless deal with that. And let me go into a little more detail here. So obvious objections, right? So first, the metric is sensitive to subsystem definitions, and subsystem definitions must map to attacks to be useful, right? So, for example, over here, what someone could say is, all right, Balaji, if you take the Nakamoto coefficient and you call it the metric, and you say, how many people or clients do I need to compromise it? Well, an Ethereum partisan might argue that the Ethereum clients are actually more decentralized because geth and parity are completely different code bases, whereas the most popular Bitcoin clients are actually typically forks of Bitcoin core. And so actually, Ethereum is more decentralized by the metric. And I say, fine, just redefine the subsystem that way. But at least we're now starting to argue about something quantitative. It's not completely abstract. It's not a religious kind of thing. This is more decentralized versus that it is. This is more decentralized by this measure. And so at least we made some forward progress. Okay, so that's number one. I agree it's sensitive to subsystem definitions, but a subsystem definition is way better than just an ambiguous and abstract thing. Number two, someone may argue, for example, here's Satoshi saying, you know, I don't believe a second compatible implementation of Bitcoin will ever be a good idea. So Bitcoin partisan may argue, you know, having one client is not a bad thing. Fine. Okay, so that's the second kind of thing. If you want to throw out a particular subsystem. Okay. If you don't consider that something that is a centralization bottleneck, if you consider that a necessary evil, go ahead. You may think dev centralization is not an issue, but mining is. Again, at least we can start making this quantitative. You throw out that row of the table. And then third, someone might say, well, you know, if you're saying a nakamoto coefficient is the number of people or entities that you need to get 51% of the welter power, 51% may not be the operative threshold. And so obviously what you can do is respond to that and you can say, yeah, just do a modified nakamoto coefficient, which says, how many people do I need to control 25% or 75%? How many people do I need to control to launch this particular attack against the network? So, for example, here you've got selfish mining this 25% attack. Even given these objections, I still believe that this coefficient moves us in the right direction. Because what you can do is pick attacks that you think likely. And the minimum nakamoto coefficient basically directionally starts to buffer you against those attacks if it's high. So, for example, with mining, if your measure is hash rate across countries and a particular country, let's say China nationalizes or acquires mining, then if your minimum Nakamoto coefficient is like five, well, you just dropped one. One country turned off mining, but the other four, you need to capture those other four to get 51% of mining. So you've decentralized it. Second example, if you take clients and you talk about market share across nodes and there's a bug in one client's code base, like for example, Parity, Bitcoin, Unlimited, Bitcoin, Core, all had significant bugs this year. Again, those engineers are great. I'm not saying any engineers is not good. But those clients did have bugs, and those bugs were user visible. If one client has a bug but your nocom auto coefficient is like 4, well, again, most of the network is unaffected because you need to mess up a bunch of different clients to capture more than 51% of nodes. Third example, so commits across developers. I don't know if people remember this, but 20 years ago, there are the crypto wars v.1, crypto war one that was waged in the US and guys like Phil Zimmerman were prosecuted for PGP. So you do want to have a Nakamoto coefficient on a particular Git repository to be fairly high. So if any one developer goes down, it's not 51% of commits. So you have three, four, five developers who all have knowledge of the code base. So one guy gets knocked down, he gets jailed, he gets prosecuted, and the other four can still carry on. Fourth example, volume across countries. So we just saw this one. You know, China got shut down. We're very lucky that. And not just lucky, you know, happy, you know, fortunate that digital currency exchanges were spread out worldwide, that other exchanges could pick up the slack. And it really didn't. Didn't miss a beat. You know, things have shifted over to Japan and South Korea and other countries. Even though China shut down exchanges, that was very lucky for us that, you know, the Nakmono coefficient could evolve. Fifth, distribution across server entities for nodes. Right. So if Amazon Web Services or Google Cloud shut down nodes, and we've already seen that domains are getting yanked, the Spanish government has shut down 100,000 cat domains. It may be at some point that Amazon or Google Cloud decide that these nodes violate the acceptable use policy. If so, it behooves us to have a Nakamoto coefficient across server entities that's much higher than 2 or 3. So there's a lot of different entities besides Amazon and Google that are running nodes. And finally, distribution across individuals. This one is a little more speculative. But what we don't want is to have something where it's an extreme asymmetry, where there's a political attack by those without digital currency to support seizure from those who have it. Right? And so, like in Venezuela or something like that, we've seen kinds of attacks like that. So this is something where you can argue about how equal the distribution needs to be. But the more equal it is, the less likely there is to be a political attack. So now, given these hypothesized attack types, you can choose your subsystems. If you think a particular row is not that important, just discard that. That's basically the kind of dashboard we're going to set up where you can just check box and uncheck, and you can do it. As an analogy, if anybody remembers or has used the computer language benchmarks game, they know that benchmarks are imperfect. A benchmark does not say a computer language is fast. It says it is fast on this benchmark. In the same way, the Nakamoto coefficient doesn't say this coin or this token is decentralized. It says it is decentralized on this benchmark. That is to say, it has 1,000 different miners who you need to compromise to get to 51%. Hence it's decentralized on this benchmark. So no one benchmark determines that a language is fast, but a combination gives useful results. And the same thing with machine learning. There's no one thing you can say to determine whether something's a hot dog or not, but a conversation, a combination gives useful results. If you guys have seen this. So imperfect quantification can lead to useful results. Finally, I think at least this is a little bit philosophical, but I think decentralization probably won't be accomplished through OneCoin alone. You're going to have different strategies for decentralization and a cross coin strategy where even if one coin is compromised, if the other ones maintain exchange rates, that one may be more robust to attacks. And different people who are founders of different coins and tokens have theses on different kinds of attacks they think of as plausible and they optimize them for robustness to that particular vector. Okay, so just in summary, we propose a simple metric of decentralization, this Nakamoto coefficient. If you want the equations from it, I went relatively equation light, but we've got equations in this blog post called Quantifying Decentralization. It tracks with our intuitive notions. Given a list of subsystems, you can start with attacks, get subsystems, and then measure. And you can put this into dashboards and objective functions. What we're doing next, as I mentioned, we're going to fund a dev to do this decentralized.com, we're already working on this. So you can get a real time dashboard of how centralized or decentralized various coins and tokens are on these benchmarks. And it'll be open source. So if you quibble with a particular benchmark or think you shouldn't have this or that, you can come back and refresh it and you can flip all the settings so that your coin is the most decentralized. Damn it. Just like you can go to the computer language benchmarks game and optimize it so that your language is the fastest. We will allow you to do that, but at least we start quantifying it so it's fastest or more centralized according to what measure. Right. And finally, what we're also doing is we're launching this new token which is hopefully going to be the most decentralized by one measure, which is just sheer number of holders, because it can be gotten without capital you put in labor and hopefully that will give a much more equal Gini coefficient than the alternative. Okay, so that's what we're doing. Open to ideas. You guys can email me if you've got thoughts on this or. Or hate it or love it. What have you. And thank you very much. Anybody has any question. Question.

So have you looked at applying this model to some of the ancillary technologies like smart wallets? Because it seems like you went directly after centralization obviously of the Bitcoin client code. But what about attacks like what happens at Coinbase earlier this summer, which is really a fairly simple vulnerability in the smart wallet implementation which led to a lot of cost?

Oh yeah. So one thing I want to be absolutely clear about is I'm not going after Bitcoin core. I'm not going after Ethereum or anything like that. I'm just trying to propose a metric. And so the thing that you're talking about I think would be measured by looking at exchanges. If you had a gross concentration of trading volume in one exchange, that would be bad because if that exchange was hacked or it had issues or it was shut down by regulators or what have you, then we would be in trouble. So, you know, this is not signaling out any one client, it's not signaling out any one coin or anything like that. It's just to propose a system for how we might start quantifying this thing. Any other question?

Very interesting talk. And actually I have a question. How can you prevent cheat? If I know your metrics, as a developer, I can commit from different accounts, as an owner, I can send my money to different accounts. Exchanges cheated. We have a talk yesterday and so on. How can you prevent cheating in your metrics?

That's a great question. And I think the answer is going to be if you have cheating in metrics and people are at least thinking of them as important. And so I would argue that an imperfect metric which is somewhat gamed, that we might have to modify and make more robust is better than none at all. As an example, with Google's page rank, right. Backlinks to a website are a very useful metric for ranking. It does get gamed, but doesn't mean that the metric is not useful. You just have to adapt the system over time to deal with various gaming attacks.

Thanks.

One more question. Yeah, so it seems like you're building a Metacritic almost for exchanges and stuff like that. The question that I had was more around what direct impact does decentralization have on a token? Yeah, so the thing is that I think here is, if you want to know my fundamental motivation, it's this. It's the optimization motivation. So for anybody here who's into math or engineering, the theory of optimization has been absolutely critical for huge amounts of machine learning over the last 10, 15 years. And so what I wanted to do is get a metric that the community could start working on, and even if imperfect, we could modify it, we could robustify it, et cetera. So that's a primary motivation. Regarding tokens, I think a good chunk of tokens, if successful, will probably eventually migrate to their own dedicated chains, sort of like how you deploy on Heroku. And then if you. If the scale gets enough, you'll move to AWS or even your own dedicated data center. I think folks will deploy to an ERC20 token. And if the scale becomes too much, we'll see plasma and other kinds of things. Very promising. But it may turn out that you might want to move to a dedicated blockchain. So I kind of look at coins and tokens as being a little bit on a continuum. We'll see what happens in the future. Thank you. Thank you, Balaji. Great.