The phrases “smart contract” and “blockchain” go hand in hand since the latter provides a new way to conduct transactions. Digital representations of real-world agreements or contracts are known as “smart contracts,” and they may be programmed to do specific tasks when certain conditions are met. Solidity is one of the most extensively used programming languages for building smart contracts on the blockchain.
As with any other software, though, there are inherent risks associated with the use of Solidity. Security flaws in Solidity contracts can result in serious losses for businesses and individuals. In this article, we will take a look at some of the best practices that should be followed when creating Solidity contracts in order to mitigate the risk of security vulnerabilities.
Use a Secure Development Environment
One of the most important steps that you can take to ensure the security of your Solidity contracts is to use a secure development environment. This means using a software development kit (SDK) that has been specifically designed for creating Solidity contracts and that is known to be secure.
Make proper use of these functions.
The convenience functions assert and require can be used to check for conditions and throw an exception if the condition is not met.
The assert function should only be used to test for internal errors, and to check invariants.
The require function should be used to ensure valid conditions, such as inputs, or contract state variables are met, or to validate return values from calls to external contracts.
Following this paradigm allows formal analysis tools to verify that the invalid opcode can never be reached: meaning no invariants in the code are violated and that the code is formally verified.
pragma solidity ^0.4.24;
contract Assert {
function assert(bool condition, string message) public { if (!condition) throw; msg = "Assertion failed: " + msg + " " + condition; } }Use a Trusted Library
Another important step is to use a trusted library for your Solidity contracts. A library is a collection of code that is shared by multiple developers and that is known to be reliable. When using a library, it is important to make sure that it has
Reentrancy Attack
It is common for the code in a modifier to be performed before the body of the function, thus any state changes or external calls to other functions will break the pattern. It’s possible that the developer may miss these statements entirely, especially if the modifier code is located distant from the function declaration. The reentrancy attack, for example, may be triggered by an external call in modifier:
contract Reentry { address public owner; function Reentry() { owner = msg.sender; } function() { if (msg.sender != owner) { throw; } } }
Beware rounding with integer division
All integer division rounds down to the nearest integer. If you need more precision, consider using a multiplier, or store both the numerator and denominator.
abstract contracts and interfaces
Abstract contracts provide a higher-level interface to contracts on the blockchain, while interfaces provide a lower-level, more specific way to interact with contracts. Abstract contracts are more flexible, while interfaces are more efficient.
An abstract contract, on the other hand, has fewer limits, such as a lack of storage or inheritance from other interfaces. Even so, interfaces come in handy when it comes to creating contracts before they are put into action. If a contract inherits from an abstract contract, it must override any non-implemented functions or it will be abstract as well. This is vital to keep in mind.
Stating the visibility of variables and functions in your code.
Make it clear which functions and state variables are accessible. There are four types of functions: external, public, internal, and private. Please be aware of the variations between them, such as the fact that external may suffice instead of public. External variables cannot be used with state variables. It will be simpler to identify false assumptions about who may call the function or access the variable if the visibility is clearly labeled.
A particular compiler version may be used to lock pragmas.
That which has been tested the most should be used for deployment of contracts. For example, the newest compiler may contain problems that have not yet been detected. Locking the pragma prevents this from happening. You may also use the pragma to specify what compiler version the original authors intended.
Use events to keep tabs on the progress of a contract.
After the contract has been launched, it may be good to keep tabs on its progress. One approach is to examine all of the contract’s transactions, however this may be inadequate since message calls between contracts are not logged on the blockchain. In addition, just the input parameters are shown, not the actual state changes. Event-based triggers may also be utilized in user interfaces.
using tx.origin
tx.origin is not a valid authorization parameter, When a method in another contract calls your contract (for example, if the user has money), your contract will allow the transaction since your address is in tx.origin. This is how it works:
Manipulation of the timestamp
Be mindful that a miner may change the block’s timestamp.
A miner may utilize a timestamp to seed a random number within 15 seconds of the block being verified, enabling them to precompute a number that is more favorable to their chances in the lottery before the block is even confirmed. The usage of timestamps in this circumstance is a bad idea since they are not random.
Don’t use the block.number as a timestamp in your code
The block.number property and the average block time may be used to estimate a time delta, however this is not future-proof since block timings might vary (for example, due to fork reorganizations or the difficulty bomb). The 15-second rule provides a more accurate time estimate for a transaction that spans many days.
Multiple inheritance
Understanding how the compiler builds the inheritance graph is critical when using multiple inheritance in Solidity.
An inheritance tree will be created by linearizing right-to-left inherited values once a contract has been deployed (parents will be listed from the most derived to the base-like values).
For type safety, use the interface type instead of the address.
An interface or contract type should be sent as an argument to a function that accepts a contract address. The compiler will give extra type safety assurances if the function is invoked elsewhere in the source code.
