ConsenSys Diligence Smart Contract Best Practices

Development recommendations in this repository are organized into six distinct categories to help you navigate security best practices:

• General: Guiding principles for the development process.
• Precautions: Principles to prevent attacks or mitigate damage in worst-case scenarios.
• Solidity-specific: Tips and quirks specifically for building smart contracts in Solidity.
• Token-specific: Recommendations for implementing or interacting with tokens.
• Documentation: Guidelines for documenting smart contracts and surrounding processes.
• Deprecated: Vulnerabilities that are largely considered obsolete in modern development environments.

Force-feeding refers to methods used to send Ether to a contract that bypass the standard Solidity receive() and fallback() execution flow. Even if these functions contain revert(), the following methods can still force Ether into the contract:

1. Selfdestruct: Calling the SELFDESTRUCT opcode sends funds to a target address at the EVM level, bypassing all Solidity-level logic.
2. Pre-calculated Deployments: Attackers can calculate the address of a contract before it is deployed and send funds to that address in advance.
3. Block Rewards and Coinbase: Miners can set the target address of block rewards to a specific contract address (the coinbase), adding funds via the EVM-level reward mechanism.

Block stuffing is a network-level DoS attack where an attacker submits multiple computationally intensive transactions with high gas prices. This consumes the entire Block Gas Limit, preventing other transactions (including those to specific contracts) from being included in the block.

This attack is typically used to block time-sensitive actions, such as preventing a user from interacting with a contract before a timer expires. Contracts that rely on specific timing for payouts or state changes are particularly vulnerable if the potential reward for the attacker outweighs the cost of stuffing the blocks.

When developing for Ethereum, be aware of these core blockchain properties and potential security pitfalls:

• External Contract Calls: Be extremely careful with calls to external contracts, as they can execute malicious code and alter your contract's control flow.
• Public Visibility: All public functions can be called maliciously and in any order. Additionally, all private data in smart contracts is viewable by anyone on the blockchain.
• Gas Constraints: Always account for gas costs and the block gas limit during development.
• Timestamp Imprecision: Timestamps are not perfectly precise; miners can influence the execution time of a transaction within a margin of several seconds.
• Randomness Limitations: Generating true randomness is non-trivial on a blockchain; most common approaches to random number generation are susceptible to being 'gamed' by participants.

Reentrancy occurs when an external call allows a caller to re-enter the contract and execute logic before the initial function execution completes. To prevent this, follow the Checks-Effects-Interactions pattern: always update the contract's internal state (e.g., zeroing out balances) before making an external call.

// SECURE
mapping (address => uint) private userBalances;

function withdrawBalance() public {
    uint amountToWithdraw = userBalances[msg.sender];
    userBalances[msg.sender] = 0; // Update state BEFORE the external call
    (bool success, ) = msg.sender.call.value(amountToWithdraw)("");
    require(success);
}

When transferring Ether, choose the method based on your security requirements:

• transfer() or send(): Use these to prevent reentrancy. They provide a fixed gas stipend (2,300 gas), which is enough for logging an event but not for complex logic. transfer() is generally preferred over send().
• call.value()(): This forwards all remaining gas to the recipient. It is highly flexible but extremely dangerous as it makes the contract vulnerable to reentrancy attacks.

Recommendation: Use a push and pull mechanism. Use send() or transfer() for pushing payments to known, trusted addresses, and use call.value()() for the pull part where users initiate their own withdrawals.