In our previous blog, we discussed the technical challenges blockchain must overcome to become mainstream. We addressed the challenge of scalability in particular, and how trying to solve scalability often results in less decentralization. Given that there are many solutions in development to deal with this challenge, we believe scalability will cease to be an issue in the coming years. But what about non-technical challenges?
This is the first part of our second issue in the Blockchain challenges series.
In order to make blockchain use cases truly valuable, we need a completely new way of thinking. Just switching from a classical platform to a blockchain platform is never useful. Yet, this is exactly what many companies are doing. Blame the hype or a lack of understanding of the technology. We see, for instance, claims like “this coffee supply chain is now completely reliable due the immutability of blockchain.”
However, a blockchain is not immutable, it’s at best tamper-resistant and not every blockchain is tamper-resistant to begin with. The extent to which a blockchain is tamper-resistant depends on the amount of nodes and how the blockchain is governed. Even if we were to assume the used blockchain is highly tamper-resistant it still doesn’t mean the data is reliable, because most use cases, including the coffee example, require external data and this data could be tampered with before it’s stored on the ledger. In other words, supply chains are not automatically reliable simply because they use a blockchain.
Furthermore, when developing code on a blockchain, there are other security issues that are not apparent with a traditional database. That’s why it’s so important to build your blockchain with developers who have the appropriate level of know-how. This brings us to three non-technical challenges we will discuss in this part of our series: governance, dealing with off-chain data and the talent shortage.
Governance
When talking about governance in a blockchain blog, people often assume we are discussing consensus algorithms. While those are certainly interesting and important, they are just a small part of governance as a whole. We discussed governance briefly in the previous article, with the bitcoin inflation bug.
The bitcoin inflation bug is an example of off-chain governance, where only a few core developers were even aware of the problem and were taking decisions for the entire ecosystem. This approach was not decentralized, but was essential for the survival of the bitcoin platform since we can’t publicly discuss such important bugs in hopes that a developer will solve them before a hacker takes advantage of the problem. Even outside the platform, there are important governance questions. For instance, ethereum as a platform is very decentralized, but the smart contracts (blockchain applications) being built on it are generally not. Most applications built on ethereum use a so-called “proxy contract structure,” which basically means that the front end communicates with a registry contract. This registry contract keeps track of an address which contains the logic of the applications. This address can be updated and so can the resulting logic. In most cases, only the application developers can update the address. As a result, about 90% of applications written on ethereum (and other platforms for that matter) are extremely centralized. To go back to the coffee supply chain example, let's say that the company behind this blockchain claims at least 10% of their profit goes to farmers in an effort to fight poverty. This 10% is directly programmed into the blockchain. If the company uses such a proxy contract structure, there is nothing that prevents them from updating this later to 5% or even 0%.
Some people claim that one shouldn’t use proxy contracts. However, we believe proxy contracts can be very useful when done right. The world around us is always changing and so is our justice system - albeit slowly. So, having a smart contract that can never be updated wouldn’t be very realistic or useful. Even if we could theoretically do it, it’s very hard to think of all the requirements beforehand and then program it without any bugs or security flaws. Having a proxy contract that allows you to update logic is very useful, but how we manage this proxy contract is a bigger challenge that merits discussion.
The main idea behind blockchain is distributed trust. In practice, this means blockchain applications should not rely on a central authority to maintain and change the logic of the app at any moment. Having a proxy contract structure, where only a single party is able to update the logic is no different and, in fact, worse than current applications.
To solve this problem, we can use decentralized autonomous organizations (DAOs). With a DAO, there is no central party that can update the logic. Instead, multiple parties or even all participants in the application should vote on whether to update the logic or not. This sounds easy on paper. In practice, it’s more difficult. We have already seen several DAO experiments in the industry fail due to voting thresholds not being met. Requiring a majority vote of all users generally doesn’t work. Finding the right balance, where a smart contract application is still considered decentralized enough so the blockchain aspect is actually useful without it becoming inactive due to a lack of voter participation, is a big challenge and a huge experiment that is still unfolding in the blockchain space.
External data
Another non-technical challenge blockchain enthusiasts need to address is how to deal with external data. As we discussed in the coffee example above, just because a supply chain uses blockchain doesn’t make the data more reliable. The company can post unreliable information on the blockchain about how great and fair their coffee is. The blockchain itself is not able to verify whether the published data is correct. That does not mean blockchain can’t be useful in this example. If we use a reliable identity solution within the blockchain, we can determine which party claims certain things. If something doesn’t check out, we can use the public record on the blockchain to pinpoint who was to blame more reliably. Having the entire supply chain on the same platform would help in gaining a more complete picture of the reliability of the coffee. This would be interesting for conscious consumers. Sadly, we rarely see blockchain solutions with these nuances. In fact, there are many malicious parties popping up that use blockchain to scam people. Just like blockchain has the potential to make certain systems more reliable and trustworthy, it can also be used to give a false sense of security and reliability. In short, a blockchain is only as reliable as the data it contains.
Contact
Contact us to learn more about the possibilities of Blockchain in your organisation.
Upcoming
Next week, we'll continue our journey into to non-technical challenges with single point of failures and lack of talent.
Stay tuned to learn more about some of the other challenges faced by blockchain projects and possible solutions.
