How to create the most decentralized blockchain

0
158

Using blockchains to decentralize a blockchain

Photo by Clint Adair on Unsplash

Decentralization is one of the main selling points of blockchain technology. Everyone knows it’s important. However, everyone is also starting to learn that blockchains end up being not that decentralized in practice. As will be described in the next section, decentralization is still very much an issue worth trying to solve.

This got me thinking and made me come up with this crazy idea. I call it crazy because it’s an idea I wouldn’t even dare considering at first because of it’s dependence on other chains and their block producers. However, this dependence is also what makes it so decentralized. So, on second thought, I decided to write this article, in order to see what other people think about it.

This is a novel consensus protocol idea. The word “most” in the title is not just naive marketing trick. The way block producers would be selected, would ensure that a blockchain running this protocol would in most cases be the most decentralized blockchain in existence. In fact, that’s where dependence on other blockchains comes from. This chain would use decentralization of other chains to decentralize itself.

Next, I will present a rationale for the idea, as well as a description of an example consensus process and difficulties with realization.

Motivation

It is not a secret that current blockchain projects are not as decentralized as we would like them to be. If you follow blockchain projects closely, you should have seen numerous articles about centralization issues plaguing Bitcoin and Ethereum.

As far as I know, there is no technology which would have completely solved it in a way that would be satisfiable to everyone. It’s mostly either susceptible to mining pools which centralize power into a couple of block producers or voting cartels and vote-buying besides general centralization of stake in PoS like systems or it’s not totally permissionless (Ripple, Stellar).

Even in Nano, which does not provide any incentive to gain more power as a validating node (and hence no reason for the power to centralize), at the time of this writing, 6 validating nodes achieve 50% of the power.

From this, we can come to a conclusion.

Too many people think that blockchain is some magical technology which makes up a decentralized network. In truth, this technology only enables decentralization. Meaning, it allows cryptocurrency to work in a decentralized manner. But it does not provide any guarantees that it will work like that. Bitcoin (at least in theory) could be run just as effectively (forgetting all the security requirements that we ask of it) with only 1 miner.

So, it’s actually, some external factors that determine actual decentralization. Technology, itself does nothing to ensure it. That’s why it’s a mistake to assume that if it’s a blockchain — it’s decentralized.

I think that most people already understand that, nevertheless I feel it is important to stress this as motivation for the idea.

As blockchain enthusiasts are touting decentralization as the main selling point of blockchain technology, it’s worth investigating ways in which we could achieve the maximum decentralization possible.

And that’s what this article is about. If the idea presented here is valid, it would enable blockchain which could be at least as decentralized as all of the most popular blockchains combined!

Using multiple Pareto distributions

The inspiration for the idea I’m about to present came from Daniel Larimer’s article on decentralization in spite of Pareto principle. Specifically the idea to use multiple independent Pareto distributions to achieve decentralization.

Pareto distribution is a probability distribution, which you can very often find wherever there is some limited valuable resource distributed among entities. 80% of it tends to be distributed among only 20% of participants. This concept is relevant for blockchain technology, because as Dan noted, work in proof of work systems and stake in proof of stake systems tend to be distributed according to this principle as well.

So what Dan suggests, is that multiple metrics should be used to select a list of BPs that will produce blocks in a DPOS like manner. Whereas traditional DPOS uses only stake weighted voting to determine active BPs, here, besides stake, other resources and metrics would be used, like different PoW algorithms, stake-time weighted voting, etc… Fixed number of BPs would be selected using each of those methods.

The idea is that, since we cannot prevent centralization of any single resource, because of Pareto principle, we ought to use multiple types of resources (or metrics) and hope that they provide sufficient levels of decentralization if combined. As long as the sets dominating entities in each of those Pareto distributions don’t overlap too much, this might be achieved.

Limitations

In the kind of system just described, security and decentralization of the network would be determined by the number of entities that would dedicate their resources towards improving their standings in at least one of the metrics. Also, the less money would go into this process the easier it would be for any single entity to start dominating and gain more than 50% of the power. This is how it works in traditional blockchains. Consequently, this means that overall security of the network is limited by its popularity — how many people will want to participate in its consensus process and how much resources they are willing and able to put in.

One could say, that it all comes down to how much money goes into a consensus process. Someone with a lot of money could equally well invest in mining as well as stake of some coin. As a result, he could expand his power across different resources and nevertheless centralize block production. Sure, different resources would have different properties, and it would be hard for one entity to be capable of controlling all of them equally well. Nevertheless, it all comes down to money eventually. So one could argue that it’s not as much that many different kinds of Pareto distributions are needed, but the total amount of wealth invested in them has to be as high as possible.

All of this to say, that total amount invested into a consensus process might still be a main determining factor for the level of decentralization, regardless of how many metrics are used for this process. Either way, I would argue that an ideal solution would use both methods in order to maximize decentralization.

Using existing Pareto distributions

What if we could find a set of metrics which would cover a variety of resources and together would have more weight (more money invested) than any other blockchain in existence?

Seems too good to be true, but the solution is quite simple: Use the Pareto distributions that other blockchains have already created.

All the blockchains created throughout the years have produced many consensus protocols and Pareto distributions. If we combined them this should provide with enough variety as well as weight (amount invested into consensus process) — both of the qualities that we seek. Furthermore, combination of decentralization of all of these chains would inevitably produce something more decentralized than any of the constituent blockchains.

How could this look like?

The simplest (and might be the only viable) way to make use of all of these existing Pareto distributions in other blockchains is to make the top block producers of those blockchains produce on our blockchain.

Say, we select 10 of the most popular blockchains. Uniqueness of the consensus protocol, decentralization of its current Pareto distribution and the total weight behind it, should all be taken into account when making the selection. Then decide on the amount of block slots in a round that would be given to BPs of each chain. Bigger the amount — bigger dependence on this particular chain.

Every day or so BP schedule would be constructed using block production data from the previous days in the constituent chains. That would basically determine which BP will fill in which slot in the round. This construction algorithm would be deterministic. Meaning every node which has the same historical data from other chains will produce the same block schedule. But it will also be subjective, in a sense that each node will have to use their own means to get historical data from other chains. Ideally each node would run a full node of every constituent chain. That’s probably too much to ask for, so it’s probably more likely that they would use external APIs for those blockchains. But as long as there are multiple sources of truth (multiple APIs), I don’t think that would be a deal-breaker.

Then, it’s just a matter BPs producing blocks, according to the block schedule, in a DPOS-like manner.

If we select 10 blockchains, give each an equal amount of slots on our chain and BP schedule algorithm selects 4 unique BPs from each of the chains to produce in these slots. Then we already get 40 unique BPs each having roughly equal power. How much power exactly depends on BP schedule construction algorithm and power distribution on each chain. But that’s already more decentralization than on any other blockchain that I’m aware of. Plus, the cost of a 51% attack on this chain would be way higher than on any other chain.

In addition, if at any time in the future some new blockchain is created which is able to outcompete our chain in terms of decentralization, this new chain could always be included into our network. Thus making use of this new technology to decentralize further and keep the title of the most decentralized blockchain.

The block producer participation issue

Sounds perfect. Except I have yet to address one critical and obvious requirement for this to work: it would need cooperation from BPs of existing chains. Why would they produce blocks on this new chain?

The simple answer is of course — block rewards. Assuming they are sufficient, it doesn’t seem to me like they would have anything to lose by participating. It would likely require additional hardware and setup to support another chain, but that shouldn’t be too hard if they are already in this business. Especially, if it would provide them with an additional source of income.

But even then, we can’t expect for every BP of every chain to produce on ours. Especially in the beginning, there would very likely be a lot of missed blocks.

One way to mitigate this issue, would be to require every BP to register on-chain before the rounds with the new BP schedule start. Then a modified BP schedule could be created which would take into account missing BPs. Registration should require a certain amount of coins to be locked up, in order to prevent fake registrations or BPs registering and then not producing blocks. This locked amount would be returned once blocks from this BP are accepted (became irreversible) by the network.

Conclusion

Existing blockchains are not as decentralized as we would like. One of the possible solutions is to use many independent Pareto distributions in a consensus process in hopes that together they would provide sufficient decentralization. However, there are some limitations to how much decentralization this could achieve if these Pareto distributions are created specifically for a single blockchain.

I’m proposing here that, using existing Pareto distributions created by other blockchains and combining them could in principle provide more decentralization and security than any other blockchain in existence and it’s a path worth investigating further.

I’m sure there are a lot of potential issues with this idea I have yet to address. The purpose of this article is to get feedback and spark discussion. The most interesting question is of course — do you think BPs of other chains would be willing to participate? Let me know if you have any thoughts regarding this or any other issues in the comments.


How to create the most decentralized blockchain was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.