Could The Blockchain Use A Smart Contract Best Practices Certification Board?
As it stands now, the burgeoning blockchain ecosystem is a bit like the Wild West. The technology has been around long enough for plenty of developers and startups to begin experimenting with the blockchain, but not long enough for many legal precedents to have been set, or all the practical kinks worked out. There is no central authority for developers to turn to regarding best practices which could be considered equal parts good and bad.
The ideals of blockchain and decentralization basically go hand in hand. Through the blockchain’s touted reliance on an immutable, transparent public ledger, developers are able to create self-executing programs (referred to as smart contracts) that no one has the ability to interfere with or shut down. The concept of smart contract technology is one of the biggest innovations and selling points of Ethereum and is a natural draw for those seeking to cut out the middle-man of business oriented affairs. The problem is that developers are also left free to make unforeseen mistakes.
Without oversight, errors may be more likely to occur. What’s worse is coders could be making the same mistakes as others without knowing it, due to a lack of communication, or well-publicized guidance from a trusted source. This can be particularly damaging when writing smart contracts. When the cost of failure on the blockchain could potentially be very high (especially in regard to anything of monetary value) it’s best to write software that fails gracefully or at least fails loudly. The last thing a developer wants is for a piece of self-executing code silently running wild.
One potential solution to this type of problem is for entities of an industry to join together and create standard regulations for themselves. This is correlative to the idea behind the nonprofit organization the Better Business Bureau (BBB). If there was some sort of certification board that issued a “stamp of approval” or certificate to show that developers followed industry standard best practices, that developer’s program or product would carry the trusted weight of the approving organization. A BBB for smart contracts, Dapps, or even ICOs would likely have to be private or from a nonprofit to succeed. With blockchain developers’ general dislike of authority, the best type of certification board would be a DAO-style commission. A decentralized autonomous organization that audits and certifies code would be the most in line with blockchain ideals, but certainly sounds ‘easier said than done.’
Governance issues aside, the main problem in securing smart contract code is that there isn’t a current exhaustive, definitive industry standards list for developing on the blockchain. There are some best practices out there, but they’re spread across the ecosystem and need to be sought out and compiled. While centralization and the blockchain don’t play well together, it would be simpler if best coding practices were pooled in an easily accessible, reputable manner. As it stands, there are only a few entities attempting to fill this gap.
Ethereum and complex blockchain programs are new and highly experimental. Therefore, you should expect constant changes in the security landscape, as new bugs and security risks are discovered, and new best practices are developed. Following the security practices in this document is therefore only the beginning of the security work you will need to do as a smart contract developer.
Smart contract programming requires a different engineering mindset than you may be used to. The cost of failure can be high, and change can be difficult, making it in some ways more similar to hardware programming or financial services programming than web or mobile development. It is therefore not enough to defend against known vulnerabilities.
To paraphrase: you’ll have to program in such a way that you’re prepared to handle any unknown issues that may arise. How can someone prepare for the unknown? The smart devs learn from their mistakes, but the truly wise devs learn from the mistakes of others. This type of philosophy is what may have inspired Zeppelin to create their open framework for smart contracts.
Zeppelin aims to create a standard for secure blockchain applications. As a product, Zeppelin “is an open framework of reusable and secure smart contracts in the Solidity language.” Through their work of creating their own and auditing the smart contracts of others, they’ve come to find what works best and what doesn’t. While they offer up reusable, secure smart contracts for use, they don’t provide any serious guarantees. Their disclaimer reads:
Zeppelin is meant to provide secure, tested and community-audited code, but please use common sense when doing anything that deals with real money! We take no responsibility for your implementation decisions and any security problem you might experience.
Even if some sort of certification board were to form, and its “stamp of approval” were trusted, it would likely be unable to fully guarantee that a piece of code is airtight. If a “certified” smart contract were to fail from an undiscovered bug, would there be any type of insurance policy in place? There are still many logistical considerations to work through.
The problem is most companies are too busy trying to concentrate on their own products, and business concerns, to spend serious time worrying about everyone else. While the concept of a safe code certificate isn’t necessary, it would certainly streamline the smart contract creation process, as well as strengthen security. More importantly, having a trusted certificate could bring about greater confidence with blockchain-based tech in general.
Engendering confidence in blockchain technology is paramount to making its widespread adoption possible. A lack of trust is impeding Ethereum’s expansion into industries that are primed for disruption. When people see The DAO lock away money in a smart contract, then watch as an exploit in the code causes money to be siphoned away without the means to stop it, they get nervous. The DAO had to be dismantled and Ethereum had to hard fork, entirely because of a flaw in how a smart contract was written. Someone wrote insecure code, and the entire blockchain ecosystem has suffered for it. Full automation could be a scary concept to some, and if trust in the surrounding ecosystem is low, mainstream adoption or growth could be a slow, uphill battle. It’s time to start thinking about how to bring trust and security into the blockchain in a big way.