Smart Contract Architecture And Testing Best Practices

Writing secure code for smart contracts starts with the mindset that a developer needs to do more than just write a piece of self-executing code. They need to program with an added awareness of all the things that could potentially go wrong with the code, later on down the road. Simply knowing how to write a smart contract isn’t enough. A developer should be aware of best practices to follow for ensuring adequate security of their code.

Secure code is important because smart contracts run very differently from most programs. Smart contracts don’t traditionally offer simple upgrade paths, especially when it comes to critical components such as code that controls the value in a token contract. Once a smart contract is up and running, changing it becomes complicated and nearly unfeasible.

Unsecure or buggy smart contracts can lead to distrust in the blockchain ecosystem. Thankfully, several interested parties have helped to compile smart contract writing guidelines. Smart contract code isn’t standardized, but these resources are convenient and beneficial for developers: Consensys’ smart contracts best practices, Solidity’s Security Considerations, Zeppelin’s open framework, and Zeppelin’s recently released v1.0.1 open framework consisting of a library for writing secure smart contracts on Ethereum.

Even after a public code audit by Zeppelin, ether.camp’s HackerGold Token (HKG) was found to have a bug serious enough to warrant a reissue of the token. The code audit recommended changes that would have prevented the bug in the HKG token contract. Clearly there is a difference between due diligence and actually correcting flaws in the code.

This shows how integral quality code architecture is in the Ethereum ecosystem. In a blog post on Medium by ICONOMI’s Daniel Zakrisson, he outlines some best practices for smart contract design and testing. He’s hoping to draw more attention to the issue of buggy code and hopefully magnify discussions surrounding industry best practices.

One of the more significant areas Zakrisson covered is verification and validation testing. Verification makes sure that code meets the design specifications and requirements it’s created to do. This can be achieved in different ways, and the testing can be mostly automated. Further code reviews and security audits are crucial in the later stages of verification. After verification testing comes validation testing. Validation is more about putting a product through its paces and making sure it will function how it’s supposed to once it’s deployed. Both verification and validation testing occur during the alpha and beta phases of a project.

Zakrisson also compiled a quick check-list for smart contract developers, regarding architecture and minimum testing standards. If programmers are thinking about writing a smart contract or are actively working on one, this guideline would be of use:

Architecture:

Minimum testing:

This is merely a guideline to add to the growing list of industry standard precautions. The best advice any developer can follow is to do their homework and make sure they’ve exhausted every resource available to them. When the whole ecosystem depends on the reliability of smart contracts, a contract’s code security is paramount.