Today, there’s a gold rush to build the winning blockchain and the decentralized applications (dapps) on top.
Though it may seem counterintuitive, these blockchain protocols should be centralized at first — and only decentralized over time. This avoids the diminished development productivity and greater security risks of premature decentralization. Going even further, the dapps that live on these blockchains, should only be minimally decentralized.
The Sin of Centralization at Bancor
This topic recently came up when Jackson Palmer — the creator of everyone’s favorite Shiba Inu cryptocurrency, Dogecoin — critiqued the Bancor project for having the ability to freeze customer funds, in the midst of a hack that stole millions. A Bancor wallet used to upgrade their Ethereum dapp’s smart contracts was compromised — and the Bancor team exercised their smart contract’s administrative privileges to protect the remaining funds.
While Palmer correctly points out the hypocrisy of extolling decentralization in a centralized smart contract , it is nonetheless poor engineering advice to decentralize projects too early. Centralized controls — like carefully curated stakers in a Proof of Stake protocol or super admin privileges in a dapp — protect users and increase the speed of iteration.
Palmer’s tweet also points to a common, flawed mindset in cryptocurrency engineering communities: that decentralization is good and centralization is bad. Instead, decentralization has some key advantages that come with tremendous engineering costs (aka, a Decentralization Premium). Good engineering teams tradeoff these benefits given the needs of their use case and community. The internet, after all, started centralized before it was decentralized (and more recently, centralized again).
Assessing Decentralization
Today, decentralization comes with profound costs in development productivity, security, and system throughput. Decentralized development is almost universally less productive for developers.
Upgrading can be hard and feature development interminable. Various states of system ownership must be taken into account, to prevent stakeholders with antagonistic interest from gaming the system. When changes need to be made, it requires a broad discussion and buy in from the community, risking dissension in the community.
By comparison, trusting a few parties early on, lets you focus on the core parts of the system, while quickly making changes when appropriate.
Decentralization in blockchain protocols
When decentralization is the ultimate goal, as it is for many blockchain protocols, there needs to be a careful process to get there, rather than an expectation that it must be accomplished on day one. The early internet started centralized relative to where it is even today.
In a perfect world, this means long testnet periods with substantial usage and hefty bug bounties. In the actual world we live in, it means premature mainnet launches, with hard forks, upgrades, and admin controls to get things right. These changes often require centralization and early superuser privileges.
If decentralization is critical for your use case, you should often start with a centralized system — and have a pathway to decentralization. For a staking protocol, it might mean having the first stakers be candidates you’ve carefully selected. Centralization gives you some training wheels while you identify potential failure states.
To get to a decentralized world, Blockstack lays out a “Path to Decentralization” from their current centralized system — rather than creating a fully decentralized, and potentially insecure system, on day one.
There is, of course, a non-engineering reason for decentralization first: you may be doing something that the legal system hasn’t caught up to and regulators treat decentralized projects differently than their centralized brethren. Or your team is so exceptional or your protocol so simple that it can developed with minimal risk that it will have issues.
Decentralization in Decentralized Apps
Today, decentralized app (dapp) developers share many of the same philosophies as blockchain protocol developers, even though they develop on two widely different parts of the stack. It’s akin to having TCP/IP protocol developers share the same mindset as that for Ruby on Rails developers building consumer apps.
In reality, the two layers have different use cases and needs. Over time, it’s likely that what a dapp user and a blockchain protocol user wants will diverge even more. What’s right at the protocol layer will be daft at the application layer.
As such, many decentralized apps (dapps) should in fact be centralized. The underlying blockchain — say, Ethereum or EOS — provides some critical decentralization guarantees such as anti-censorship, broad availability, and uptime. The dapp, therefore, should concentrate on providing key features that users value.
For example, CryptoKitties, one of the more successful decentralized applications, has admin privileges that allow their team to pause contract functionality at will. Just because their team can block your app, doesn’t mean there are still not benefits to preventing most other parties from interfering with your ability to trade.
In other instances, the dapp may need to be decentralized over time, but should be centralized to ensure rapid development at the start. For example, a multi-sig administrator might be able to pause functionality for a period — with expiry of that capability at a preset time (this is one safety technique used by the dYdX team, as they launched their margin trading protocol).
Given that we’re still reasoning about potential dapp failure states, adding these centralized components — as Bancor did — is crucial.
In a recent Solidity security talk, I pointed out that decentralized app developers only have finite time to get contract secure, but an attacker has infinite time to find bugs. In such a world, there are huge benefits to instituting safety mechanisms like a circuit breaker controlled by the creators of the application — especially in the first version of your application.
Conclusion
Building robust, secure decentralized systems has been a rallying cry for the cryptocurrency community. Over time, it promises global systems of ownership that democratize financial services access and codify well understood and global financial rules.
To get there, we shouldn’t apply decentralization blindly, especially when it impedes us — however counterintuitively — from getting even sooner to a decentralized world.