Smart Contract Patterns and Anti-Patterns

Note: This section is a work in progress and will be expanded in future updates.

In smart contract development, understanding and implementing security patterns is as crucial as recognizing and avoiding anti-patterns. This section dives into some secure design patterns essential for robust smart contract creation and highlights common anti-patterns to steer clear of.

Secure Design Patterns

Secure design patterns are best practices that help mitigate common vulnerabilities in smart contracts. Some key patterns include:

  • Reentrancy Guards: To prevent reentrancy attacks, contracts can use reentrancy guards. These are mechanisms that lock the state during a function call to ensure that no external calls can intervene and exploit the contract’s state.
  • Check-Effects-Interactions: This pattern recommends ordering transactions in a way that checks are done first, followed by state changes (effects), and external interactions last. This sequence minimizes the risk of reentrancy and other unexpected behaviors.
  • ABI Decode With Selector: This involves techniques for decoding function call data and revert errors effectively, enhancing the contract’s ability to interact with and understand external calls and messages.
  • Advanced Error Handling: Writing code that can intercept and react appropriately to errors thrown by other contracts is crucial for resilience and security.
  • Assembly for Optimization: Using short, useful assembly tricks can help save gas and compensate for Solidity’s limitations, optimizing the contract’s performance and reducing the risk of some attacks. It can also introduce risks.
  • Basic Proxies: Implementing contracts with upgradeable logic using proxy patterns, which allow for updating the contract’s functionality without changing the deployed contract.
  • Bitmap Nonces: Efficiently tracking the state of frequent, consumable operations identifiable by unique nonces, using bitmap data structures for optimized performance.
  • Commit + Reveal: A two-step process that partially obscures on-chain actions, protecting them from front-running or back-running.
  • Avoiding ERC20 (In)Compatibility Issues: Understanding how to work with both compliant and non-compliant ERC20 tokens, which are more common than expected, is crucial.
  • ERC20 (EIP-2612) Permit: Implementing an efficient process to perform an ERC20 approve and transfer in a single transaction.
  • Eth_call Tricks: Utilizing eth_call for complex on-chain data queries and simulations can provide zero deployment cost solutions for intricate contract queries.
  • Explicit Storage Buckets: Ensuring non-overlapping, safe storage in upgradeable contracts to prevent storage collisions and potential vulnerabilities.
  • Factory Proofs: Demonstrating on-chain that a contract was deployed by a trusted deployer to establish authenticity and trust.
  • Merkle Proofs: Employing storage-efficient methods to prove membership to large sets, optimizing contract efficiency and security.
  • Multicall: Allowing users to perform multiple operations on a contract in a single transaction, enhancing user experience and contract interaction efficiency.
  • NFT Receive Hooks: Using ERC721/ERC1155 transfer callbacks to optimize the user interaction process, eliminating the need for prior allowances.

Common Anti-Patterns and Their Avoidance

Anti-patterns are common mistakes in smart contract development that can lead to security vulnerabilities or inefficiencies. These are a primary area of concern.

NOTE: This section is far from complete and will be expanded upon in the future.

  • Unchecked External Calls: External calls can be risky if not handled correctly. It’s crucial to check the return value of external calls and handle errors appropriately.
  • Unchecked Return Values: Return values from external calls should be checked to ensure that they are valid and expected. Ignoring return values can lead to unexpected behaviors.
  • Caller Account Type Exclusion: Determining whether the caller is a Smart Contract is possible in most cases but excluding Smart Contracts account callers is more problematic. This is because at deployment a contracts constructor can make an external call, while there is no code actually stored with the account, and with tx.origin == msg.sender.

Incorporating secure design patterns and avoiding anti-patterns is fundamental in smart contract development. By leveraging these practices, developers can create more secure, efficient, and robust contracts. This holistic approach to security, combining proactive design strategies with a keen awareness of potential pitfalls, is vital for the ongoing success and trustworthiness of smart contract applications in the blockchain ecosystem.