Best Practices for Smart Contracts Security

With the constantly changing scenarios in the security landscape, blockchain remains a promising technology, which has created an immense buzz over the years. The smart contract is at the core of every blockchain, making blockchain technology applications in healthcare, IoT, supply chain, digital identity, business process management, and many sectors. Together, blockchain and smart contracts revolutionize efficient transaction storage, services and workflows that work even among distrusting participants and without a trusted authority. Although the progress toward improvising blockchain technology focusing on the smart contract has been more significant, there is a lack of reviewing the smart contracts’ security.

As an innovative technology, smart contracts have been applied in various business areas, such as digital asset exchange, supply chains, crowdfunding, and intellectual property. At the same time, many security issues in smart contracts have been reported confining substantial financial losses. These security issues pose new challenges to security research because smart contracts’ execution environment is based on the decentralized, immutable nature of blockchain. As a result, numerous solutions are emerging to detect and address security vulnerabilities. It is necessary to identify and rectify the emerging smart contract security concerns on a global scale.

As security remains one of the significant concerns regarding smart contracts, a minute error in the smart contract coding can result in financial losses. Therefore, when writing a smart contract, security should always be the developer’s top priority.

Most networks recommend security best practices for developers to increase smart contract safety and performance. However, if you want to ensure the highest level of possible protection, consider reading this article. The article aims to focus on the best possible practices corresponding to different blockchain platforms in context to smart contract security.

This article will help you know some of the following essential questions related to smart contract security.

• What are Smart Contracts?
• Which factors reduce the security of smart contracts?
• What are the best practices for securing smart contracts with different blockchain platforms?
• How do the security tools and design patterns impact the security of smart contracts?

What are Smart Contracts?

Smart contracts are computer programs that execute the transactions automatically when predefined conditions are met. They run on blockchain to enforce an agreement between the parties involved in the transaction. Their adoption in different sectors like healthcare, supply chain, finance has led to the strong demand for verification and validation techniques.

The terms of the smart contract agreement are written directly into the code. Hence, smart contracts can securely and efficiently transfer the funds or information between the participants without any need for mutual trust. The involvement of regulators and intermediaries is no longer necessary. Therefore, a smart contract needs to be highly secure with no bugs, loopholes or vulnerabilities hidden in its programming codes. As smart contracts are at the core of every blockchain, smart contracts exhibit the following characteristics.

• Distributed: Smart contracts can be validated by every participant in the network, similar to the regular transactions on a blockchain.
• Immutable: By design, smart contracts cannot be changed or tampered with once they are released.
• Transparency: All the terms and conditions of the agreement in smart contracts remain visible to network participants.
• Cost efficiency: Smart contracts remove the necessity for additional validation of the agreement and the extra expenses.
• Accuracy: The terms of the agreement are written in the form of code, and smart contracts follow these terms and conditions without any exceptions.
• Trust: Smart Contracts are triggered only on meeting specified conditions. Hence, there are no risks of fraudulent activities.

Which factors reduce the security of smart contracts?

Security is the most crucial aspect of smart contracts. Understanding a particular blockchain network’s weakest spots can help developers make their contracts less susceptible to different vulnerabilities and malicious attacks. There are many responsible factors like programming errors, protocol bugs, compiler errors, and various attacks on the network when securing smart contracts. Besides these, the following are some of the factors that affect the security of smart contracts.

• Virtual Machines
  These are the multiple sources of critical errors and security issues. For example, the Ethereum Virtual Machine (EVM) is vulnerable to numerous errors, right from access control issues to immutable defects caused by programming errors in the contract code.
• Source Code
  Nowadays, various blockchain platforms support smart contracts like Ethereum, Hyperledger, EOS, Stellar, and Tezos. These platforms use different programming languages, tokens, and consensus algorithms. Their differences result in the occurrence of various security issues and vulnerabilities. Some blockchain networks have already experienced significant losses due to hidden smart contract vulnerabilities or mistakes in a smart contract’s source code.Some of them have their programming languages for developing smart contracts. For example, Ethereum uses Solidity language. It is similar to Javascript and C++, making it easy for existing software developers to write solidity code. Despite using various programming languages, bugs and vulnerabilities in the source code are the main reasons behind smart contracts’ security issues.Although Ethereum is a widely adopted platform, some of its past vulnerabilities have led to millions of tokens being lost. In 2016, the network even had to perform a hard fork to revert damage due to a DAO hack. The reentrancy vulnerability exploited by hackers led to a financial loss of around 50 million dollars.The following table shows the types of security issues for different blockchain platforms like Ethereum, EOS and Tezos, with their consequences.

What are the best practices for securing smart contracts on different blockchain platforms?

Most of the blockchain platforms have numerous security issues that hackers can exploit. Yet, it is possible to solve these issues at the stage of smart contract development. The best way to overcome these issues is by undertaking the best practices with no possibility of introducing any vulnerabilities or unexpected events.

It is essential to follow the best practices for writing secure smart contracts in different platforms and programming languages.

Best Practices for handling Solidity Smart Contracts Security

• Handling the funds
  There are multiple options to handle and collect the funds throughout the development of a crowdsale smart contract. Here are some ways to manage the funds.In contract: During the crowdsale, the funds are kept in a contract. These funds are transferred to the developer’s address after the crowdsale gets over.
  Forwarding: It is another way to transfer the funds to a multisig wallet instead of storing them temporarily in a contract. So, funds are kept in an intermediate multisig contract with a time lock facility to maintain the funds in an immovable state till the end of the crowdsale.

• Make use of Fallback Functions and Race Conditions
  It is preferred to call the fallback functions when no functions match and has accessibility to 2300 gas when called from .send() or .transfer(). Logging an event in a fallback function can help you to get ether from .send() or .transfer().
  Calling external contracts may often take over the control flow and make changes to data. This type of bug can lead to DAO collapse.

• Make a proper use of assert( ), require ( ) and revert ( ) functions
  It is essential to understand the correct usage of assert, require and revert functions. In general, assert and require functions are helpful to check for conditions and throw an exception if conditions are not met. To be more precise, use the assert function to test for internal errors and check invariants. On the other hand, the require() function ensures whether the valid conditions like inputs or state variables are met. Require() functions can be used to validate return values from calls to external contracts.

• Label the functions and state variables
  Marking the visibility makes it easy to catch incorrect assumptions about who can call the particular function or access the specific variable. The functions are specified as external, internal, public, or private. Understanding their differences will help you to use them correctly for a particular purpose. The external functions are usually called on receiving large arrays of data. The public functions are called internally or through messages to generate an automatic getter function. On the other hand, internal functions and state variables are accessed internally. Private functions and state variables remain visible for the defined contract.

• Use events to track the contract activity

Monitoring the smart contracts with events is one way to secure them. It is possible to track all the contract transactions, but the message calls are not recorded in the blockchain. Therefore, only input parameters remain visible and not the actual changes made into the state. Hence, events can help trigger the functions in the user interface.Consider a sample code given below.

contract Charity {
     mapping(address => uint) balances;
     function donate() payable public {
          balances[msg.sender] += msg.value;
     }
}
contract Game {
    function buyCoins() payable public {
        // 5% goes to charity
        charity.donate.value(msg.value / 20)();
    }
}

Here, a Game contract will make an internal call to Charity.donate().An event is a correct way to log something that happened in the contract. Earlier events remain in the blockchain with the other contract data and they become available for future audit perspectives. Here is an improvement to the example shown above, using events to provide a history of Charity’s donations. This transaction does not appear in Charity’s external transaction list but remains visible in the internal transactions.

• Use modifiers only for checks

The code represented in a modifier gets executed before the function body. Therefore, any modifications in the state or external calls break the check-effects-interaction design pattern. The developers cannot notice such statements as the code for a modifier is far from function declaration. Consider the following example, where an external call in modifier results in a reentrancy

contract Registry {
address owner;
function isVoter(address _addr) external returns(bool {)
{ // Code
      }
}
contract Election {
Registry registry;
   modifier isEligible(address _addr{
   require(registry.isVoter(_addr));
   _;
}
function vote() isEligible(msg.sender) public{
// Code
    }
}

Here, the Registry contract is prone to cause a reentrancy attack by calling Election.vote() inside isVoter(). The modifiers help replace duplicate condition checks in multiple functions like isOwner() or make use of require or revert inside the function. It will ensure the readability and auditability of smart contract codes.

• Prevent rounding the integer division
  When integer division occurs, it rounds down to the nearest value of an integer. If more accuracy is required, it is better to use a multiplier or store the numerator and denominator values. These stored values can help in calculating the result of the numerator /denominator in off-chain mode.

• Tradeoffs between interfaces and abstract contracts
  The interfaces and abstract contracts are effective in providing a customizable and re-usable approach for smart contracts. Although interfaces resemble abstract contracts, they lack in some functions, cannot access storage or inherit other interfaces. They help design the contracts before implementation. When a contract inherits from the abstract contract, it must implement all the other functions by overriding it.

Best practices for Ethereum Smart Contracts Security

Ethereum is the most widely used platform. While developing smart contracts on Ethereum, it is essential to follow the best practices for smart contract security.

• Mark untrusted contracts
  It is essential to specify your variables, methods, and contract interfaces during any interaction with external contracts. It applies to the functions which call external contracts.
• Prevent state changes after external calls
  While using raw calls or contract calls, there is a possibility that malicious code may get executed. Although the external contract is not malicious, the malicious code may undergo execution by any contract it calls. The malicious code can hijack the control flow and result in causing vulnerabilities due to reentrancy. Therefore, while making a call to an untrusted external contract, prevent the state changes right after the call. This pattern is known as the check-effects-interaction pattern.
• Error-Handling in External calls
  The low-level call methods in solidity, which work on raw addresses, never throw an exception but return to a false value when an exception is encountered. On the contrary, the contract calls result in propagating a throw automatically on discovering any throw function like doSomething(). So, when you prefer to choose low-level call methods, ensure to handle the possibility of call failure by monitoring the return value.
• Prefer pull over push for external calls
  The external calls are prone to accidental failure. It is generally applicable in payments, where the users can withdraw or pull the funds automatically instead of pushing funds. It also minimizes the issues associated with the gas limit.
  It is better to isolate each external call into its transaction, which the call recipient initiates.

• Avoid using delegatecall functions to untrusted code

The delegatecall helps to call the functions from other contracts if they are related to the caller contract. So, the callee can change the state of the calling address. This step is highly insecure and may lead to the destruction of the contract and loss of balance.
Code example:

contract Destructor
     {
function doWork() external
{
selfdestruct(0);
     }
}
contract Worker
{
       function doWork(address _internalWorker) public
       {
             // unsafe
             _internalWorker.delegatecall(bytes4(keccak256("doWork()")));
       }
}

When Worker.doWork() is called with the address of deployed destructor contract in terms of argument, the worker contract undergoes self-destruction. Hence, it is necessary to delegate the execution only to trusted contracts and not to a user-supplied address for enabling secure transactions.

• Manage the function code: conditions, actions and interactions
  A good practice to ensure smart contracts’ security comes up with a better structure of all functions. It involves checking all pre-conditions, making changes to the states, and dealing with other smart contracts. The following example adopts the pattern of conditions, actions and interactions, which improves the security level by resolving significant problems.

Best practices for EOS Smart Contracts Security

The smart contracts written on the EOS platform need to monitor the steps on the mainnet. If the testing stage is not thoroughly performed, fatal bugs may lead to disastrous effects on the entire network. While working on EOS platforms, it is crucial to consider and implement the following practices for smart contract security.

• Authorization Analysis

The statement require_auth(account) should be used only for the actions you need to follow for an authorized account. The require_auth(_self) is used to allow the contract owner to execute the transactions. The following sample code allows anyone to call the action. To solve this problem, make use of the require_auth(from) statement for authorizing the payer for the call.

void token::transfer( account_name from, account_name to, asset quantity)
{
auto sym = quantity.symbol.name();
require_recipient( from );
require_recipient( to );
auto payer = has_auth( to ) ? to : from;
sub_balance( from, quantity );
add_balance( to, quantity, payer );
}

• Evaluate the Numerical overflow

While performing arithmetic operations, the values may overflow if boundary conditions are incorrectly checked. It results in the loss of users’ assets. In the sample code given below, uint64_t specifying user balance causes an overflow on multiplying the values. It is better to avoid voiding the use of uint64_t in denoting the balance and performing arithmetic operations. Ensure that you make the correct use of asset structure in EOS for any actions to balance the existing overflow conditions.

void transfer(symbol_name symbol, account_name from, account_names to, uint64_t balance) {
require_auth(from);
account fromaccount;
eosio_assert(is_balance_within_range(balance), "invalid balance");
eosio_assert(balance > 0, "must transfer positive balance");   uint64_t amount = balance * 4; //Multiplication overflow
}

• Use assumptions fully in the contract
  While executing the contracts, some assumptions are made, which need assertions. The use of eosio_assert looks over the prior conditions to be met and avoids the failure chances. The following example shows an assert statement creating an assumption that the roll_under integer value is greater than 2 and less than 96. If this assumption is not verified, it can turn into disastrous consequences.void assert_roll_under(const uint8_t& roll_under) {eosio_assert(roll_under >= 2 && roll_under <= 96,
  “roll under overflow, must be greater than 2 and less than 96”);
  }

• Generating true random numbers
  Generation of true random numbers for the EOS Blockchain could be risky if it is imperfectly done. It can result in adverse outcomes. Some of the services like Oracle.it shares the random numbers from external sources, but they are costly with a single point of failure. Blockchain contextual variables like bloc stamp, block numbers, etc., are widely used to create random numbers in Ethereum smart contracts.The code given below shows the generation of updated random numbers from 1 to 100. Here, seed 1 represents the hours seed, while seed 2 is an individual seed. EOSBetCasino and Dappub manage the generator by adopting a dice game between player and developer for a reference check.
• Set the Limit Transfer rate
  It is necessary to set the limiting value of the transfer rate while withdrawing to prevent excessive losses. It is a prime step of the mainnet launch. It is also advisable to make use of the bug bounty program to ensure security against possible vulnerabilities.
• Make use of killswitch

Using killswitch can help you to freeze the contract immediately after encountering a bug. The implementation involves the flag in the muti_idex table. This flag is set when you use an action called by the owner of the contract. After that, each public work is checked to ensure that the flag is set to frozen or not. The example given below shows the use of a killswitch to get rid of the bug.

struct st_frozen {
uint64_t frozen;
};
typedef singleton tb_frozen;
tb_frozen _frozen;
uint64_t getFreezeFlag() {
st_frozen frozen_st{.frozen = 0};
return _frozen.get_or_create(_self, frozen_st);
}
void setFreezeFlag(const uint64_t& pFrozen) {
st_frozen frozen_st = getFreezeFlag();
frozen_st.frozen = pFrozen;
_frozen.set(frozen_st, _self);
}
// public Action
void freeze() {
require_auth(_self);
setFreezeFlag(1);
}
// public Action
void unfreeze() {
require_auth(_self);
setFreezeFlag(0);
}
// any public action
void action(...) {
eosio_assert(getFreezeFlag().frozen == 1, "Contract is frozen!");
}

Best Practices for Tezos Smart Contracts Security

The smart contracts in the tezos platform are unique in terms of features and accuracy. Tezos supports verification which ensures the correctness of smart contract codes, making them more secure and reliable. Some of the significant benefits of Tezos smart contacts include:

• A specialized set of tools to create business-oriented DApps.
• Ability to analyze smart contract code.
• No need to depend on any compilers for translating the program into unreadable bytecode.

Despite these accurate features, adopting some of the following best practices for tezos smart contracts can mitigate the security vulnerabilities.

• Adding owners to smart contracts

There are some cases where the addition of simple authorization and access control mechanisms is necessary. It is generally crucial for simple systems and quick prototyping functions. The following sample code shows how to provide specific access to the owners over particular functions.

type action is AddOwner of (address)
// An unordered collections of owner accounts
type store is record
owners: set(address);
end

type return is list(operation) * store
// Function that checks if an account is an owner
// Must be integrated into functions that can only be used by an owner
function isOwner (const addressOwner : address; var store : store) : bool is store.owners contains addressOwner;
// Function that add an owner to the unordered collections of owners in the storage
function addOwner (const newOwnerAddress : address; var store : store) : return is
block {
const newOwners : set(address) = Set.add(newOwnerAddress, store.owners)
} with ((nil : list (operation)), store with record [owners = newOwners;]);
function main (const action: action; var store: store): return is
block {
skip
} with case action of
AddOwner(n) -> addOwner(n, store)
end;

• Addition of role-based access control
  Adding role-based access control is necessary to enable different levels of authorization. A role represents an abstract name for consent required to access a specific set of resources or entry-points. The role that you need to define is added as a union type annotation. Managing big_map helps to understand and hold the list of accounts with the specific roles.

• Prevent refunding to a list of contracts
  The multiple transfers to untrusted addresses are vulnerable to DoS attacks. It is better to ensure that the contract’s execution is malicious free especially during the transfer of funds. As an alternative, you can also transfer the funds simultaneously by making the users ready to pull the funds.
• Prevent batch operations
  The batch operations need to be avoided when the users can efficiently increase the size of the batch. It is so because it can result in DoS attacks. When a malicious user spams the contract with small transactions, the contract becomes useless.
• Prevent the storage and transfer of unsafe private data
  The overall data on the blockchain is public. Hence, it is of prime importance to secure with hash or encryption for any confidential information. The storage and transfer of unprotected data may lead to various security issues.
• Ensure that a message remains un-repetitive
  The absence of some unique parameters leads to repeatable transactions. The repeated nature of transactions is vulnerable to reentrancy or replay attacks like double-spending funds. It is essential to ensure that the message remains unique and non-repeated while executing functions in the smart contracts.

How do security tools and design patterns impact the security of smart contracts?

Security patterns and tools are the safety measures to mitigate damage and assure a reliable contract execution. Some of them are stated below.

1. Check-effects Interaction Pattern

The Checks-Effects-Interaction pattern is a basic guideline while coding any smart contract. This pattern helps to know how to build up a function. It describes how the function code should be structured by avoiding side effects and undesired execution issues. It specifies a particular order of functions like checking all preconditions, making changes to the contract state and eventually interact with other contracts. Due to these functionalities, it is termed as a “Check-Effects-Interaction” pattern.

In this pattern, you need to validate all arguments and find out the errors when arguments are not applicable with expected input. Later, you can alter the states of smart contracts along with eventual interaction with other smart contracts. Interaction with other smart contracts should always be the final step in your function as it is associated with handing over the control to another contract. When handing over the control to another contract, you need to ensure that the current contract has completed its functionality and remains independent for execution on another contract.

Problem: When the control is handed over to another contract, the called contract re-enters and tries to manipulate its state and hijack the control flow with malicious code.

Solution: Follow a proper functional code sequence, where interaction with external contracts should be the last step. It reduces the probability of attacking through malicious code.

2. Circuit Breaker Pattern

This pattern is well-known by the term emergency stop due to its capability of stopping operational execution in smart contracts. It is possible to manually trigger the circuit breaker with the trusted parties like contract admin or programmable sets to meet specific conditions. This pattern is highly used when bugs are detected.

Problem: On detecting a major bug or security issue, there is no option to stop the execution as deployed contracts are automatically executed on the Ethereum network.

Solution: Incorporating a circuit breaker functionality into contracts so that only authenticated parties can trigger them to disable the sensitive functions.

3. Speed Bumps Pattern

Speed bumps are generally applied during the occurrence of malicious events. They provide the necessary time for smart contract owners to act accordingly. In DAO cases, speed bumps are useless as no recovery actions are possible. Hence, speed bumps are helpful in combination with circuit breakers that block the contract except for the withdrawal function. So, the users can easily withdraw the funds before the malicious action. For example, a large number of customers withdraw their funds simultaneously due to concerns about bank solvency. In such cases, banks counteract with some delaying, halting or limiting the functions of withdrawals.

Problem: The overall execution of sensitive tasks at once by multiple parties results in the contract’s downfall.

Solution: Extend the completion period of sensitive tasks to take consequent actions against fraudulent activities.

4. Rate Limit Pattern

This pattern helps regulate how frequently a function is called one after the other in a specified time interval. With this pattern, it is possible to limit the contract’s withdrawal execution rate by preventing quick drainage of funds. Limiting the number of issued tokens overtime at the contract level can be another effective way to use a rate-limiting pattern.

Problem: A collective rush of requests on a specific task is complex and can obstruct the contract’s operational performance.

Solution: Regulation of the effective limiting patterns while executing the tasks in the stipulated duration avoids obstruction.

5. Mutex Pattern

This pattern represents mutual exclusion, which is a synchronization mechanism for restricting concurrent access to resources. After reentrancy attacks, adopting mutex patterns can protect the smart contracts against recursive function calls from external contracts.

Problem: The Re-entrancy attacks can manipulate the state of a contract and restrict the control flow.

Solution: Using a mutex pattern restricts an external call from re-entering its caller function again.

6. Balance Limit Pattern

While coding the smart contracts, it is better to manage the amount of money at risk. It is generally possible by limiting the overall balance available in the contract. This pattern keeps tracking the contract balance and rejects the payment when it exceeds the predefined limit.

Problem: High risk is involved in the contract platform due to the detection of bugs in code or unknown security issues.

Solution: Set the limitation for the maximum amount of funds at risk held within the contract.

Smart Contracts Security Tools

Here are some of the security tools, which can reduce the possibilities of errors in smart contracts execution.

•  Oyente
  It is used for the analysis of Ethereum code to detect common vulnerabilities based on symbolic execution. It makes use of two inputs – bytecode and global state. Its main components include CGF builder, Explorer, CoreAnalysis and Validator. CGF builder is used for creating a control flow graph; explorer executes the contracts, CoreAnalysis detects the issues in the output received from explorer while validator eliminates false positives to make OYENTE reports.
• SmartInspect
  SmartInspect is a tool used to analyze the deployed smart contract using decompilation techniques for remotely deployed contracts. It is achieved without using API for accumulating raw data.

• GasTap
  GasTap tool is responsible for calculating the upper bond necessary for the amount of gas for smart contracts to prevent out of gas vulnerability. It exploits available tools in a pipeline that takes a smart contract and determines the required gas upper limit for its functions.
•  Securify
  It is a completely automated online static analysis tool for smart contracts to provide a security report based on vulnerability patterns. It decompiles bytecode, extracts semantic data, and checks the security patterns in a domain-specific language. It involves a set of compliance, violation and warning for examining the behavior of smart contracts.
•  SmartCheck
  It is a static analyzing tool used to translate solidity source code to XML format. It also detects the problematic patterns with the help of Xpath queries. Solidity code issues are confined and categorized to security, functional, operational and development stages.
• Gasper
  Gas is a unit used for execution fees which the sender of transactions or smart contracts needs to pay for every operation. To be more precise, gas represents the fee to reward miners for code execution. Gasper is a tool used to find out the overcharged representative patterns like dead code, opaque predicates and costly operations in a loop.
•  Vandal
  It is a static security analysis framework for smart contracts for translating smart contract bytecodes to logic relations. The analysis pipeline includes a bytecode scraper, a disassembler, a decompiler, and an extractor. It makes use of declarative language in the form of a datalog engine for finding security vulnerabilities like reentrancy, destroyable contract, unsecured balance and unchecked transfer.
• Solgraph
  It is a visualization security tool used to generate a DOT graph for maintaining secured control flow of solidity contract. Its significant role is to detect and highlight possible security vulnerabilities.
•  Ethereum graph debugger
  It is an EVM debugging tool used to display or represent the overall program control flow in graphical analysis.

Smart contracts serve to be a well-known solution with numerous benefits in terms of trust, precision, and cost-efficiency compared to traditional legal contracts. Like other programs, smart contracts are prone to various hidden vulnerabilities and code errors that ultimately hampers their security. When it comes to smart contracts security, there are multiple factors like the type of blockchain network you work with, the programming language and platform you use and the kind of testing you perform before releasing the final version. During these stages, it is advisable to adopt and implement the best possible practices for ensuring smart contract security to a greater extent.

Are you trying to figure out and follow the best practices for smart contract security for your blockchain solution? Reach our team of professional blockchain developers to help you improvise smart contracts’ security on any platform to meet your tech-needs.