About two and a half years ago, I published an article here titled "How to create the most decentralized blockchain". Today, I present a better idea: instead of trying to do the impossible, let's look at why we want blockchain to be as decentralized as possible in the first place and let's try to achieve the same properties in other ways.
The previous article as well as this one is talking about one specific kind of decentralization, namely political decentralization of a consensus process. In simpler terms, we care about the following question: how many parties produce most (more than 50%) of the blocks? This number is important because it shows us how many parties it takes to collude to attack the network.
The goal of this article is to investigate ways to make this potential collusion powerless, so that colluding parties wouldn't be able to perform any meaningful attack, except to stop their services altogether. If we are successful, then it won't matter as much if 1 party or 4 is producing all the blocks. That will make accepting the fact that 2-4 parties are producing more than 50% of the blocks in most blockchains, a lot easier to take in.
Why do we need a decentralized consensus process
Before tackling our goal, we need to understand what attacks can colluding majority of block producers perform. My personal experience shows that the following myth is not too uncommon: "once you have more than 50% of mining power in a blockchain, you gain control of the network". The implication of this thought is that all security guarantees of a blockchain are gone once some party exercises control of its majority power, which would imply that attacker can steal money, etc.
Thankfully, the reality is much more generous. Protocols can ensure many security guarantees using cryptography, which make the remaining guarantees that decentralization of consensus process has to ensure, not that large. Actually, the main reason we need a consensus process is to determine what transactions happen and in what order. Consensus participants have no power to include invalid transactions into their blocks because every other protocol party would reject such blocks.
So, when we get down to it, the consensus process performs one very specific function: it determines what transactions to execute and in what order. This gives us a very clear view of the set of attacks that consensus participants can perform:
- They can selectively choose which transactions to include and which not (censorship)
- They can manipulate the order of transactions.
2.1. History revision attacks
2.2. Live transaction order manipulation (e.g.: front running)
As you can see the second category is further divided into two sub-categories. It is divided based on whether an attack tries to manipulate the order of transactions, which have already been recorded in blocks, or if it tries to select the order of transactions as they are getting included in blocks. In the former case, the particular attack is often called a "history revision" attack, because the attacker basically has to rewrite the history of a blockchain in order to perform it. This allows an attacker to double-spend: he can create one version of a chain where he sends some coins to one party, then create a new one where he sends the same coins to some other party, and then make the second one the canonical one, leaving the first receiver without the coins he seemingly received.
That, which I called "live transaction order manipulation" is basically block producers ordering transactions in the blocks they produce in a way that benefits them or their friends (this happens during block production and contrary to 2.1 does not require history revision). Front-running is the best example of that, where a block producer would observe the orders that users submit in a DeFi application, and make use of that information, by placing his orders first, so that it could profit from the subsequent user orders.
Tackling history revision attacks
History revision attacks actually already have a solution, which some of the protocols use. In the context of blockchains, these are finalizing protocols. Those protocols have a rule that says that once a block receives some number of confirmations (blocks building on it, or, alternatively, signatures from consensus participants) it becomes irreversible. At that point reversing transactions in that block becomes impossible. So in order, to protect from double-spends users only need to wait for block finalization, at which point they can be sure that the coins they receive are really theirs and won't be spent again.
For completeness, it needs to be mentioned that finalizing protocols do not come without a price - they sacrifice what's in distributed computing literature is called liveness. In the context of blockchains, we can understand liveness to be, the ability for a blockchain to continue (to be extended), even in case of faults, and in the context of finalizing protocols, it could be understood as an ability of a blockchain network to finalize blocks. Finalizing protocols cannot ensure that blocks will be finalized in case a certain threshold of block producers are malicious.
The alternative to finalizing blockchain is liveness-favoring blockchains. Bitcoin is one of those. They try to ensure maximum availability: that blockchain could be used in case of all kinds of faults (like network partitions or malicious consensus participants).
The goal of this article is to present a model where a network is safe from collusion of consensus participants even if the majority of them collude, and this goal is strictly concerned with security (security from history revision attacks in this case), whereas availability, which liveness-favoring protocols ensure is more of a usability concern. Therefore, we focus on finalizing protocols as a solution to the history revision attacks.
Tackling censorship and front-running
Consensus participants produce blocks and have the power to determine which user transactions are included in them and therefore it is possible for them to censor user transactions. Unlike history revision attacks, colluding majority of consensus participants is not enough to perform this attack. That's because it is enough for a single block producer to accept a transaction in its block, for a transaction to appear in the blockchain. So a single honest block producer would seemingly be enough to prevent censorship. However, the majority of consensus participants have the ability to censor other consensus participants. This looks like majority of block producers not building on blocks of minority of block producers. So the colluding majority could simply choose to censor blocks, which contain transactions that they want to censor. The blockchain, although more slowly (because some blocks would be missed), but would continue and the users would be censored. Blockchains have different methods for dealing with block producers missing blocks, therefore it is in theory even possible for new (potentially dishonest) block producers to replace the honest block producers without anyone noticing.
So what do we do about that?
I want to stress the difference between the two types of censorship that could happen this way. One is selective censorship where block producers would censor specific users or specific transactions. The other is censoring all transactions. The latter is for all intents and purposes equivalent to block producers stopping their work (although they could still be producing blocks it is just that they would be empty). From the user perspective, it would be equivalent to liveness failure, which we talked about in the previous section. Either way, it is obvious that the second type of censorship would be impossible not to notice for everyone. It represents an attack on the whole network. Once something like that happens users of a decentralized blockchain would have to take action off-chain to remedy it. Namely, they could create a new fork of a blockchain and continue with new, honest block producers. So by performing this attack colluding majority would basically be telling the users, which make their work profitable to create their own chain.
Obviously, selective censorship, where only some specific transactions or users would be censored is more dangerous. The network would be nowhere as near to creating a new fork as fast as they would if all transactions would be censored. The majority of users might not care as much about a minority being censored, in order to go through all the trouble of starting to use a new chain. Because of this, even if a new fork would be created, the market value of tokens there would be uncertain.
So how can selective censorship be prevented? By simply not allowing block producers to distinguish transactions. If block producers are not able to tell, which transaction does what and which transaction belongs to which user, they will not be able to select which transactions to censor. In a case where all transactions are indistinguishable, the only remaining option for a block producer intending to censor a particular transaction or user would be to censor all transactions. Which as we previously pointed out, is not as dangerous.
This reveals a rarely mentioned advantage of privacy-oriented coins (Monero, ZCash). They are actually a lot more secure against censorship and colluding majority of consensus participants. The same could potentially be true about privacy-oriented smart contract platforms (depending on how much privacy they can offer). However, privacy-preserving smart contracts is in some ways a more complex issue and there are not a lot of those yet. I hope to cover the situation with privacy-preserving smart contracts in later articles.
Tackling front running
We have one type of attack that majority of consensus participants could do remaining and that is choosing transaction order by BPs in their blocks in a way that profits them. As was already mentioned, front running is the best-known example of that.
When it comes to preventing this problem, privacy could help as well. If a block producer does not know which transaction does what then he won't be able to choose the order of transactions that fits him. However, there are more issues in this case. Applications, where this attack is possible, are usually applications with a global public state, where everyone (including block producers) can participate. Therefore, hiding information transactions carry might not be possible. This is different from simple cryptocurrencies, where we can decentralize information (hide it from the public) about transactions because transactions spend independent coins (this is partly why private cryptocurrencies are possible). Said in another way, front-running, and similar problems are mostly relevant to DeFi applications and they require smart contracts. As we already implied, privacy in smart contracts is an issue yet to have a sure solution. Most smart contracts don't have it at all.
But the situation is not hopeless. There are projects focusing on privacy in smart contracts and I think we can expect a lot of progress to be made in that area in the coming years. The topic of privacy in smart contracts is worth another article, so I won't start it here, but I hope to have convinced you that privacy-oriented smart contracts, as well as cryptocurrencies, are very important not just for our privacy but for our security against censorship and other kinds of abuse by majority of consensus participants.
Summary
We have looked at the dangers of centralization of the consensus process in public blockchains and discovered that they can be put into three categories: 1) history revision attacks, 2) censorship, and 3) live transaction order manipulation (front running).
To solve history revision attacks we can use finalizing consensus protocols. These protocols stop if majority of consensus participants become malicious.
To solve selective censorship, privacy techniques could be used to make transactions indistinguishable from one another. Censorship by majority of consensus participants would still be possible by censoring all transactions and all honest consensus participants, but this is, for all intents and purposes, equivalent to protocol process halting.
To solve front-running, we can use privacy as well. Privacy in these cases is harder to achieve, but it is a direction worthy of research.
If we were able to prevent front-running (be it through privacy of transactions or through other means), then we would have a method to make decentralized applications where the only way a colluding majority of consensus participants could attack the network would be to stop their services altogether. Attacks on individual parties would be prevented, and every attack from consensus participants would be made obvious to all. As a result, the problem which we do not seem to be able to prevent, namely the tendency towards centralization of the consensus process (how many consensus participants it takes to collude in order to attack the network), would not matter as much.
Conclusion
The title of this post says: "secure decentralized applications on a centralized blockchain". I hope to have convinced you that applications using finalizing blockchains and privacy techniques can be secure from the collusion of consensus participants.
But how can applications running on a centralized blockchain be called decentralized? The answer I would offer is that, even though consensus process that determines consensus on data might be centralized, the process for determining how to derive meaningful information from that data can still be decentralized. For example, if information is encrypted before being submitted to the blockchain, the public network will only know some data blob that represents the information. The possession of the actual information will be decentralized (only those that have a decryption key will be able to have the information). This is a different kind of information, but still very meaningful security-wise.
Separation of information from data, I think is a key to achieving a lot of desirable features for blockchain applications and DAOs. This post covers only one aspect. My previous post covers another way to apply the same principle and what it can achieve (without using privacy techniques): Albedo: How to Decentralize Blockchains using ƒractally. But I don't think it is the end of a list and I will probably write more about this in the future.
Dear @sim31, we need your help!
The Hivebuzz proposal already got important support from the community. However, it lost its funding a few days ago and only needs a few more HP to get funded again.
May we ask you to support it so our team can continue its work this year?
You can do it on Peakd, ecency,
https://peakd.com/me/proposals/199
Your support would be really helpful and you could make a difference.
Thank you!