Things To Consider When Writing A Smart Contract
Tips For Writing Smarter Smart Contracts
Blockchains differ greatly from computers in terms of operation, and when writing a smart contract, we constantly need to think of the different possible scenarios where our code could fail. Smart contracts directly deal with funds and even a simple bug can lead to a loss of millions. This puts DeFi projects at a much greater risk than the traditional web2 apps.
And for this very reason, the smart contracts have to undergo several security audits to ensure their maximum safety. That said, there are a few things you can do at your end, to make your contracts more secure. Here are a few tips that’ll help you in writing better smart contracts.
Always Lock The Pragma
They say the latest is the best, but with blockchain, that’s not the case. When you’re writing a smart contract, try and pick an older compiler. Newer versions of the solidity compiler are majorly untested and are error prone. Older versions have had more time in the industry, and so they become the standard.
Newer versions introduce bugs, and also at times underlying architecture problems. And so, it becomes important to lock the compiler version for our code. We should ideally never use floating pragma, or unlocked compiler versions for our contract. When choosing pragma, the best practice is to lock the compiler version.
pragma solidity ^0.8.0;
//Should be written as
pragma solidity 0.8.0;
Properly Document Your Code
This is something that every developer knows of, but with smart contracts it is a lot more significant. Smart contracts have to be sent for audits and the auditors need to go through each and every line of code to understand the contract’s logic.
Good documentation is a must for any code analysis; with smart contracts, we need to be even more clear about the purpose of each and every attribute of our code.
Always Conduct Unit Tests
Think of unit tests as a ritual, they must be conducted for even the smallest of contracts. No matter how redundant it may seem, we must always conduct unit tests. For smart contracts, a 90% test coverage is considered ideal, but it doesn’t hurt if you take it up to 95. After all, you’re only making your contract more secure.
Two of the most popular tools are truffle and hardhat, where both provide a local blockchain network on which you can test your contract.
Prepare Your Contracts For A Failure
Blockchains are new, and highly experimental. Even if your code is flawless, there’s still a chance that there’s an underlying unseen bug that could show up at any moment. We need to prepare ahead of time to prepare ourselves for this scenario.
The importance of a security audit cannot be stressed enough, as it can help identify vulnerabilities like the ones that were exploited in the Inverse Finance hack.
For this, we need to implement a pausing functionality, which halts the contract. Rate limiting, to set a maximum usage and prevent the exploitation of funds. We also need to create an upgrade path for our contract to migrate it to newer, updated code.
Follow The Design Patterns
Design pattern is a general reusable solution to a given coding problem. A lot of solidity code has already been written and the industry now has its own set of best practices. These patterns have been tried and tested over time.
When writing any smart contract, your safest bet is to follow the design principle set by the industry. Reinventing the wheel is definitely no solution, and for this reason you should always try doing some research around the functionality you’re trying to inject and how it has been implemented by the professionals.
The Withdrawal pattern is one famous example where the responsibility of funds is put onto the user.
Minimize Gas Costs
Solidity is built differently, the computations that we take for granted on our systems, are not feasible on a blockchain. Every operation costs gas and our goal is to minimize that cost as much as possible.
There are many tools that can help you in analyzing gas costs. Web3.js provides an inbuilt functionality, remix also is useful in analyzing real-time gas costs. Eth gas reporter is another popular tool which helps us in calculating the gas.
However, there are a few quirks about solidity that you should keep in mind. For instance uint8 costs more gas than uint256. Here’s the link to a comprehensive table of different operations and their gas costs.
Never Store Private Data On Chain
It’s a common mistake to assume that the ‘private’ marked variables are hidden from everyone, sadly that’s not the case. And this is something a lot of developers tend to do when they are new to writing smart contracts.
Blockchain is a public ledger and all the data is visible to everyone. Private simply means that the data is inaccessible to other smart contracts. The only way to hide this data is by encrypting it, but in general it is never a good practice to store important data on the blockchain.
Closing Thoughts
It’s okay to be paranoid if you’re writing a smart contract, and it’s also not wrong to say that writing smart contracts is an art. Your goal always is to create the most secure, efficient and simple smart contracts that just work.
But then again, you can never be sure enough. The key to writing good smart contracts is being responsible and being extra vigilant. Blockchains are very new and immature, and so you should always keep a watch on the latest developments in this space.
Contact Novvr
Get your Dapps secured and tested at Novvr today.
An audit is a security focused code review with aim to identify issues in the code. Our process primarily includes 5 steps to conclude a smart contract audit:
- Read specs/docs
- Run Tests
- Automated Analysis
- Manual Review
- Prepare Report
Here are a few points that you must follow to get your smart contract ready for an audit.
- Add Comments in your code
- Document your functions
- Tests (must), if your tests don’t pass, don’t go for an audit
- Transparent Communication
- Ready to share your time with Auditors
If any of the above points is missing that means your code is not ready for an audit.
Know More about the process.