New developers often don’t know how to set up a framework for smart contract development to make the process as efficient and secure as possible.
For developing Solidity smart contracts, we In HashEx, use Hardhat, and for our internal needs, we have created a pre-configured project with the most useful development projects connected to it and set up according to the developers’ needs.
By using boilerplate you can get ready-for-use software out of the box, immediately starting the development of the project.
A prepared README can help with the usage of preset plug-ins:
README also includes instructions on contract testing and deployment. It also describes testing if there’s a need to create a fork of a public network.
To start using the initial repository, you have to clone this repository and install the packages it requires. This can be done using the following commands:
After that, you have to familiarize yourself with the README.md, create a config.js file following the example of the config.example.js file, then insert API keys as well as private keys (this file is located in .gitignore so it won’t be uploaded to GitHub).
After that, you can attempt compilation of the project and launch the tests.
You can also try to run different plugins and make sure that they function properly.
When all this is finished, you can start developing the project.
The repository contains many useful plugins.
This plugin assists with writing tests and contract testing. It allows finding the spots within the contract that are not covered by tests and because of that, can potentially contain an error or a vulnerability.
This plugin helps with keeping the repository in a presentable condition, including its visual aspect. The main goal is to achieve a quality code style.
It’s recommended to run this plugin every time before the commit or deployment.
This plugin assists with writing the documentation for the contract. The documentation written in a specific way (NatSpec) within the contract files, will be converted into a presentable .md file so that anyone attempting to figure out exactly how the contract works, could do it using said documentation.
This plugin serves for checking the code’s Security, Style Guide, and Best Practices. It suggests changes that have to be made for the code to follow the commonly used rules of contract writing.
This plugin specializes in finding potential vulnerabilities within the code, using static analysis. Vulnerabilities such as reentrancy, non-secure external calls, etc. can be discovered with this plugin.
This plugin is used for fuzzing/property-based contract testing. It requires writing specific contracts that will be tested. Examples can be found in the repository in the /contracts/echidna-test folder.
The point of this type of testing is to attempt to break the in-contract invariants, that are supposed to always be run. This is how the contract is checked.
It attempts to apply random actions by calling functions in random order with random arguments.
This type of testing isn’t a universal cure, it only assists with testing. There have been cases of a contract passing Echidna testing without a vulnerability being discovered. This happens because not every possible combination is tried, but a specific subcollection.