Dapp updates
One of the main ideas behind decentralized applications is that the way they work cannot be altered. Once they have been deployed, they should be almost impossible to take down.
However, there is consent that updates and upgrades to applications can be absolutely necessary. Bugs or security issues are discovered, feature upgrades required. There can also be changes in the underlying/connected levels of the techstack the dapps run on that will require changes in order to keep the dapps working. But on blockchains this can not be easily done as they are immutable. If a smart contract is deployed then it is out there, and can’t be changed beyond what was coded in to be changed from the start.
Because it is required nonetheless, we can observe that pretty much every major dapp has at least some part of it controlled by a person or company — a single centralized entity. This can be someone having some sort of administrator access. It can (and often does) also mean that the majority of the code is actually run by this centralized entity, while only some parts, often related to ownership of assets, is actually realized through smart contracts in a decentralized fashion.
For example, the ‘decentralized Exchange’ (DEX) Etherdelta has its order book on a centralized server. CryptoKitties from the popular Game exist as Tokens on the chain — but the images of the Kitties are stored on Google cloud services, and could be changed at will by the company who created it. Compound Finance, a popular Decentralized Finance (DeFi) dapp (storing over 100m$ in assets in its code), while based on the trustless ledger Ethereum, has a centralized admin access.
A more detailed look at this last example, Compound, reveals its code has been audited by multiple external auditors, and is up to highest standards. However, the centralized weak link ‘administrator access’ is still there: Because all cTokens use the same administrator, if the administrator key is compromised, all assets deposited in Compound can be trivially drained. (1)
So Ethereum itself is a permissionless and trustless (i.e. there is no central party one has to trust to use it) decentralized ledger. The smart contract code deployed on it cannot be changed. So while all these components are fairly decentralized — whoever has access to the admin address can change the smart contract address it points to. This is a centralized weak link, that to some degree defeats the purpose of dapps and DeFi — which is not having to trust a single entity. The Hack of Bancor for 23 million$ worth of digital assets through this route shows that this is not just a purely theoretical risk.(2)
Further research shows that there are other techniques to deploy a new contract at a different address and render the old contract useless (and through that achieve upgradeability). The most common techniques for creating upgradeable smart contracts on Ethereum are: (3)
- Master-Slave contracts
- Eternal Storage contracts
- Upgradable Storage Proxy Contracts
- Delegate Call
- Unstructured Upgradable Storage Proxy Contracts
A smart contract based ownership of a dapp is possible, and provides a decentralized alternative. However, it comes down to the permission system implemented by the smart contract.
Why do Compound and other successful dapps, built by talented developers, don’t go that route after all? Probably because having to build upgrade functions on application level is additional workload already, even with centralized admin access. Adding another layer of complexity and workload is likely asking too much from dapp developers, especially since governance of dapps is not a trivial topic, as will be briefly explained later.
Upgrades of the smart contract platform
All dapps have a base layer, a smart contract platform, based on a distributed ledger. In addition to the dapps themselves this needs to be upgraded too, just like any operating system. The leading (by number of developers, dapps, and users) smart contract platform Ethereum does this through planned forks.
The Istanbul hard fork for example broke close to 5,000 Aragon (A governance dapp) smart contracts alone. The Aragon developers offered a migration path, so the effects on users were limited. However, as with dapp upgrades, the burden here is on the dapp developers again. Jorge Izquierdo, Co-founder of Aragon puts it like this:
I deeply believe it is not our fault but the implications of bad protocol design. We are not Ethereum’s only users and we understand the importance of the changes even if it breaks our stuff. This has just confirmed our belief that relying exclusively on Ethereum poses a considerable platform risk that we should hedge against by having Aragon available in multiple chains. It’s important to have a chain governed by the Aragon community as it will only have our best interests at heart. (4)
So, in essence — the smart contract platform can and will be upgraded, and dapps can, if necessary, be updated accordingly. Unfortunately, because there is no proper upgrade process, it is on the developers again to migrate and update their smart contracts. Similar to updating the dapps themselves this is a lot of manual development work. Ethereum and other popular smart contract platforms leave the burden of dapp updates and governance to the dapp developers unfortunately — resulting in dapps with many centralized weak links, as initially covered.
Governance of decentralized applications
Blockchain itself is a very specific decentralized governance system. It allows for a large network of computers to continuously agree on certain things every few seconds such as the balance of tokens, and a set of programs and their internal states. So it makes sense for the dapps running on these blockchains to have a governance system too — for real decentralization it is even a requirement since updates and changes are usually required at some point.
But if dapp developers want to go beyond a dapp with centralized admin access, and create a true dapp, they also have to think about governance. Who can decide, for instance, when and what upgrades to the dapp will be implemented and enabled? This is adding another layer of complexity to their dapp though. It seems that the burden of choosing and implementing the right governance and administration/upgrade being on the developer’s shoulders is not ideal, and many small dapp development teams simply cannot handle it, in addition to regular development and the effort already required for update and maintenance. At least that is the impression that few applications actually picking a smart contract-based ownership and a governance system for their dapp give. The vast majority take the faster and simpler route: centralized admin access with no governance and upgradeability through for example Master-Slave contracts.
While dapp governance is not implemented in the base layer on Ethereum and similar Smart contract Platforms, there are quite a few dapps available for it that other dapps can use for governance purposes. Popular examples are Aragon, Daostack and Govblock.
In absence of a central entity, the decision-making process for dapp updates and development will have to be formalized at some point to make sure stakeholders have appropriate influence and voting power in them. What exactly that means in each individual case, and how it can best be implemented is still not clear. Just going by the number of tokens representing voting power, there is risk of a central entity gaining control over the majority of the tokens on the market, making governance obsolete. Concepts like quadratic voting, giving smaller stakeholders more power may help there. Or developing a score, so that active users of a dapp accrue governance power without holding any token. But Dapp governance is a relatively new and complex topic. Therefore, a lot of research, development and experimenting is still required. So far best practice approach seems to be to kickstart development with a centralized team for years — all successful dapp projects, even with DAO in the name (such as MakerDAO) are heavily relying on a central organisation for now. Only once a certain level of functionality, userbase, network effect and community are established, a really slow transformation to decentralized governance through a DAO can be started. (5) Usually there are still many centralized pieces in this puzzle at this point, many governance vote results have to be carried out by a centralized and trusted team.
Are there dapps on Bitcoin / Lightning Network?
In contrary to Ethereum, Bitcoin is not a smart contract platform. There are still applications that use lightning networks payment channels claiming to be dapps, although they have many centralized components usually, as the smart contracts running on it are just simple if-then functions in one-to-one channels. The rest of the application is centralized, there is no governance and no way to implement it in a trustless way. In addition, the lightning network faces other challenges. These include users requiring to run full nodes, both sides of a channel having to be online to transfer payments, funds have to be deposited upfront, and inherent incentives for a centralized hub-and-spoke system to develop. (6)
Sources:
1) https://medium.com/@ameensol/what-you-should-know-before-putting-half-a-million-dai-in-compound-fafdb2645f77–25.11.2019
2) https://hackernoon.com/how-to-make-smart-contracts-upgradable-2612e771d5a2–25.11.2019
3) https://medium.com/hackernoon/strengthening-the-weakest-link-in-smart-contract-security- onlyowner-c390d0e452b4–25.11.2019
4) https://blog.aragon.one/aragon-chain/ — 25.11.2019
5) https://blog.kyber.network/kyberdao-voting-experiment-1-31738860cf6c — 25.11.2019
6) https://medium.com/crypto-punks/lightning-network-ux-centralization-b517037b92ec — 25.11.2019
