The Big Decentralization Lie

Blockchain projects, particularly those based on permissionless platforms, usually sell themselves as Decentralized Applications (DApps). By this, they imply that power is returned to the user by not relying on a trusted third party. Instead, they distribute control among peers. This may be true for Bitcoin and some other cryptocurrencies, but most application-layer DApps built on smart contracts, are far more centralized than most people realize.

Let’s have a look at hidden sources of centralizations and how many projects are just as centralized as their non-DApp counterparts.

Trusted Smart Contracts

Smart contracts are meant to be self-executing pieces of code deployed on a peer-to-peer network. In theory, once deployed, anyone can interact with a smart contract and no-one can remove, stop or modify it.

In practice, however, this is not true for all contracts. Consider this: smart contracts written for a Turing-complete virtual machine, such as Ethereum, can implement virtually anything, including permission systems and special privileges. Many projects take full advantage of this. It is very common to assign roles to users. A lot of contracts are ownable, meaning they have an owner with special priveledges. Some functions of these contracts can only be executed by a certain authorized account.

There are some valid reasons for this, for example, security. However, it also means that one trusted account has special power over the smart contract. An audit earlier this year of the top 20 ERC-20 tokens (at the time) found that almost half of these tokens were pausable. This means that all transfers can be stopped by the smart contract owner, making the token unusable and essentially worthless.

Let’s think about this for a moment: You are investing in a decentralized asset to get away from traditional banking with their trusted third parties, only to end up depending on a single anonymous account that could kill your investment by pressing a button.

This is not unique to ERC-20 tokens. We have looked at the code of the smart contracts for the (in)famous CryptoKitties collectibles and here is a fact: Some “trusted” accounts can stop trading of your expensive fury friends. Here is the relevant code extract from the KittyAccessControl contract, together with a confidence-inducing comment:

/// @dev Called by any “C-level” role to pause the contract. Used only when
/// a bug or exploit is detected and we need to limit damage.
function pause() external onlyCLevel whenNotPaused {
paused = true;
}
/// @dev Unpauses the smart contract. Can only be called by the CEO, since
/// one reason we may pause the contract is when CFO or COO accounts are
/// compromised.
/// @notice This is public rather than external so it can be called by
/// derived contracts.
function unpause() public onlyCEO whenPaused {
// can’t unpause if contract was upgraded
paused = false;
}

Let’s get this straight, CryptoKitties is an amazing project and we are not doubting the good intentions of the team behind it. However, users should be aware that these type of DApps are not as decentralized as we are led to believe.

Off-chain Modules

Another source of centralization is the off-chain code commonly found in DApps. With current technology, it is close to impossible to provide fully decentralized applications with a decent user interface without resorting to a centralized off-chain module, such as a web interface.

However, the degree of centralization may vary. Plenty of projects use closed-source code, making it almost impossible to restore access to the underlying smart contract without some serious reverse engineering, should the centralized module disappear.

The same is true for data. Many DApps keep some data off-chain, either for privacy and regulatory compliance (GDPR, for example) or because storing large amounts of data cannot be stored on blockchains efficiently ande cheaply. Should the centralized data source disappear, the DApp is rendered useless.

We should, therefore, watch out for these sources of centralization. In cases, where decentralization is a must, we should value projects that use decentralized off-chain storage, such as IPFS, and make their source code public.

Governance

Projects must be led by a team. The way the contributions to the code base are admitted and the way updates are decided on, can speak volumes on the degree of decentralization of a blockchain application. As with anything in life, there are practical trade-offs involved. A certain degree of centralization may be advantageous to get things done. This can be seen with infamous Bitcoin scaling debate. Without entering into the actual debate, most people would agree that more centralization would have settled the matter much earlier. Whether this would be a good thing or a bad thing remains a matter of opinions.

What is quite clear, that “dictatorships” in governance are clearly incompatible with the decentralized application model.

Decentralization is not Everything

It should be clear by now that decentralization involves trade-offs. A certain degree of centralization can help to make a DApp more secure, more efficient, and more usable with current technology. However, users should be made aware of these trade-offs.

At Cryptronics, we have audited many tokens and DApps, and we often see hidden sources of centralization that are not disclosed in the whitepaper or in the technical documentation of a project. We like to point these things out, and are of the opinion that smart contract audits should be made public. A good smart contract audit provides a detailed analysis of the contracts security, but can also be a great tool to ensure users and investors that a DApp is compliant with the whitepaper and does what it is supposed to do.

At Cryptronics, we specialize in auditing decentralized applications and designing reliable and secure blockchain architectures. If you have a blockchain solution and wish to verify security, or require custom design and development for a decentralized application, feel free to contact us.