Since the conditions of a smart contract agreement are written directly into the code, a smart contract securely transfers funds or data between parties.
For this to work, a smart contract has to be 100 per cent secure and accurate.
Writing a smart contract is just as difficult as building an aircraft control system: there are several risks and weak spots that developers usually forget about. In this post, we share with you expert tips on creating secure smart contracts.
Avoid known pitfalls
Be aware of the well-known security issues. There are several online resources to know about common issues, like Ethernaut CTF, Capture the Ether, or Not so smart contracts. Read the warnings sections in the Solidity documentation which will let you know about the non-obvious behaviour of the language.
Dependencies
Utilize well-tested libraries. Import code from well-tested libraries to minimize the possibility that you write buggy code. If you wish to build an ERC20 contract, use OpenZeppelin. Make use of a dependency manager; refrain from copy-pasting code. When you’re relying on an external source, then you should keep it up-to-date with the original source.
Testing and verification
Writing extensive unit tests is advisable. A thorough test suite is important to creating high-quality software. Check for common security issues that a smart contract developer will help you rectify:
- Review your contracts using Slither which has 40+ built-in tools to detect common vulnerabilities. Run it on all check-ins with new code and make sure it gets a clean report (or use triage mode for silencing specific issues).
- Review your contracts using Crytic which can check for 50 issues that Slither can not. Crytic helps developers stay on top of each other as well, by quickly surfacing security issues in Pull Requests on GitHub.
Solidity
Favour Solidity 0.5 over 0.4 and 0.6. In our view, Solidity 0.5 is more secure and has better built-in practices when compared to the other two. Solidity 0.6 has been considered very unstable for production and requires time to mature. Utilize a stable release to compile, and the latest release to check for warnings. Ensure your code does not have reported issues with the latest compiler version.
Anyway, Solidity owns a fast release cycle and a history of compiler bugs, therefore the latest version is not recommended for deployment. Avoid using inline assembly since it requires EVM expertise. Don’t write EVM code when you haven’t mastered the yellow paper yet.
Consider special features of your contract
- Is your smart contract upgradeable? Check your upgradeability code for flaws using slither-check-upgradeability or Crytic.
- Does your contract seem to conform to ERCs? Review them with the slither-check-erc tool which will identify deviations from 6 common specifications in an instant.
- Do you have any unit test in Truffle? Enhance them with slither-prop. This will automatically generate a wide range of security properties for features of ERC20 based on your particular code.
- Do you integrate with third-party tokens? Check Ethereum’s token integration checklist before you reply to external contracts.
Document important security properties and utilize automated test generators for evaluating them
- Documenting security properties for your code is tough at first, but it’s the top significant activity to achieve a great result.
- Write customer checks and properties using Slither’s Python API, Echidna, and Manticore.
- Run property tests all commits using Crytic which is capable of consuming and evaluating security property tests so every member of the team will know that they pass on GitHub. Failing tests will block commits.
Deployment Guidelines
Once you have developed and deployed the smart contract, ensure:
- Monitoring your contract, watching the logs, and being ready to react in the event of a contract or wallet compromise.
- Adding your contact information to blockchain-security contacts; third parties will contact you in case any security flaw is found.
- Securing the wallets of privileged users. Follow these best practices if you store keys in hardware wallets.
- Having a response to the incident plan. Think that your smart contract may be compromised. Even if your contract doesn’t contain any bugs, attackers will take control of the contract owner’s keys.
Final Thoughts
Finally, be mindful of issues that cannot be easily found by automated tools:
- Lack of privacy: everyone else can view your transactions while they are queued in the pool
- Front running transactions
- Cryptographic operations
- Risky interactions with external Defi components
Follow the aforementioned high-level recommendations from leading organizations to build more secure smart contracts.