Part three in a series about blockchain early adoption risks. Read the first article here and the second article here.
Aficionados of cutting-edge technology can tell you that newly launched technologies are so named for a reason. Even the best developers and QA teams can’t substitute for years of consumer use and feedback in new technology development. As blockchain-enabled applications make their way into the mainstream, the first users of the technology will likely run into some of the same types of problems that plague most early adopters.
In a traditional application development, extensive testing and screenings are done before a product’s release. Even after the product is completed, targeted and limited releases give developers opportunities to discover software defects while minimizing the risk to the end users. For example, Apple allows individuals to submit applications to the App Store. These individuals can be anybody, resulting in a very broad spectrum of skills and experiences. For that reason, multiple layers of screening are implemented starting with a licensing scheme that requires a user to provide both information and a payment to become an official developer. Then, during development, the Apple Software Development Kit (SDK) provides libraries to prevent low-level error-prone coding, all done in an IDE with an intelligent code analyzer. Finally, before the applications can launch, they are subjected to comprehensive reviews of content, security, hardware compatibility, copyright, and privacy.
None of these protections exist for blockchain application development today. Right now, there are an unlimited number of ideas about how to leverage blockchain which, in many scenarios, include moving valuable information onto the blockchain. This pattern is especially true in parts of world where governance is weak or completely lacking. So, problem solvers are trying to respond to the need by rapidly bringing a unified blockchain solution into the market.
In the “purest” decentralized application on public blockchain, no authority will audit the application for vulnerabilities and there is little control over the onboarding process. As soon as a contract is published, everyone will be able to see and interact with it. These two deficiencies are further compounded by the fact that blockchain technology is still in its early stages and some of the practices that work for traditional web and mobile applications do not carry over. First, there is no copyright protection in public blockchain apps, so developers are deterred from sharing source code for fear of people making clones of their project. Secondly, because blockchain gives people anonymity, it motivates hackers to conceal their exploits and strike at a much later time, rendering the usual bug bounty and penetration testing programs less effective. Thirdly, people do not like to interact with applications if they can’t see the original source code, which results in developers revealing the application logic to the public after release. This makes it a great place for hackers to poke around. And finally, the probability of discovering software bugs increases with more users, user diversity, and experienced developers, all of which are lacking right now. A professor who teaches the cryptocurrency class at Stanford once mentioned that in one of their assignments where they intentionally give buggy code to their students to find, occasionally graders would receive new bugs that they did not even account for when designing the problem.
Private blockchain is immune to many of those problems. Developers are screened and hired, and the security testing procedures carry over from before. The system is distributed and works off consensus protocol making the ledger resilient against intermittent node failures and compromised nodes. Perhaps, what has gotten worse now is that institutions will use the same piece of software and software bugs leading rogue developers to become the common mode of failure.
There are several ideas to mitigate some of these problems.
In private blockchain, the backup and code review process will need to be done much more rigorously. Every party in the consortium providing the blockchain service should independently assess the application’s security and sit on a code review board for any commits to the software.
Personnel who have access to nodes and nodes status should be monitored using behavioral-based technology to detect potential rogue activities.

• In public blockchain, better IDE with code analysis functionalities can help discover hard to detect vulnerabilities.
• Developers can set limit within contract logic to slowly ramp up users to prevent damage caused by latent vulnerabilities.
• Users should employ behavioral analytics technology to monitor themselves, as well as people they interact with, on the blockchain and to look for exploitive individuals so as not to engage with them.

Developers should actively monitor user activities to look for both suspicious and abnormal patterns that could be an indicator of gaming the system. In our next, and final, article we’ll talk about how to build trust within the blockchain infrastructure.