How do misclassifications of subcontract types, like libraries labeled as contracts, affect Solidity smart contract security and management?
We recently conducted an insightful interview with NTU researchers Sun Kairan and Prof. Liu Yang. Our discussion centered on the substantial reliance on external subcontracts in Solidity smart contracts and the complexities this reliance introduces to smart contract security and development. Their empirical study, "Demystifying the Composition and Code Reuse in Solidity Smart Contracts," published at ESEC/FSE 2023, provides valuable insights into prevalent development patterns and the security implications of code reuse in this domain. Stay tuned for key takeaways and expert perspectives on enhancing the security and efficiency of smart contract development.
Scantist: Could you provide a brief overview of your study on Solidity smart contracts and the main objectives you aimed to achieve?
Kairan: Our study investigates the composition and code reuse practices in Solidity smart contracts to understand how these practices influence development efficiency and security. By examining over 350,000 contracts, we aimed to identify common patterns and quantify the reliance on external components. This empirical analysis helps in revealing the extent to which developers depend on third-party packages and the risks associated with such dependencies. Our objectives include providing insights into the development practices, identifying frequent development patterns, and offering recommendations to improve security and efficiency in smart contract development. The study’s findings can guide developers and auditors in making informed decisions about subcontract use and management.
Scantist: What are the common approaches to introducing subcontracts into smart contracts, and what sources are typically used?
Kairan: In our study, we identified three primary approaches to introducing subcontracts into Solidity smart contracts: importing, cloning, and self-developing. Importing involves using external libraries or packages, commonly from NPM or URLs such as GitHub repositories. Cloning refers to copying code directly from other sources without an import statement. Lastly, self-developing entails creating custom subcontracts from scratch. Among these, cloning is the most prevalent, especially from NPM packages, which highlights a significant reliance on existing solutions to reduce development time and effort. However, this also introduces potential security risks and challenges in managing these dependencies effectively. Understanding these approaches helps in assessing the security and efficiency implications in smart contract development.
Scantist: What is the significance of these approaches and how they impact smart contract development?
Kairan: The choice of approach for introducing subcontracts significantly impacts the development process and security of smart contracts. Importing subcontracts from reputable sources can streamline development and leverage well-tested code, enhancing reliability and reducing the risk of introducing bugs. However, it also requires careful dependency management to ensure security vulnerabilities are not introduced. Cloning, while quick and easy, can lead to challenges in tracking updates and managing versions, potentially leaving contracts exposed to known vulnerabilities. Self-developed subcontracts offer the highest level of control and customization but require substantial development effort and expertise. Overall, these approaches influence the balance between development efficiency, security, and maintainability of smart contracts.
Scantist: What are the main characteristics of self-developed subcontracts in Solidity smart contracts?
Kairan: Self-developed subcontracts in Solidity smart contracts often exhibit a high degree of code reuse, particularly at the function level. Our analysis revealed that approximately 50% of self-developed subcontracts contain less than 10% unique functions. This indicates that developers frequently reuse code blocks to maintain consistency and reduce development time. Commonly reused functions include getters, setters, constructors, and those related to token operations like minting and transferring. These subcontracts are typically customized to meet specific project requirements, highlighting areas where tailored development practices and tooling can be beneficial. Understanding these characteristics can help in developing tools and best practices to support efficient and secure contract development.
Scantist: How does code reuse in self-developed subcontracts inform development practices and tooling?
Kairan: The high level of code reuse in self-developed subcontracts suggests that developers often rely on existing code blocks to streamline development. This practice can inform the creation of development tools that automate repetitive tasks, such as generating standard functions or templates for common operations. By recognizing patterns in code reuse, developers can create libraries or frameworks that encapsulate frequently used functionalities, improving efficiency and reducing the likelihood of errors. Additionally, tailored tooling can support customization efforts, ensuring that unique requirements are met while maintaining consistency. This approach not only enhances development efficiency but also contributes to better code quality and security by promoting the use of well-tested and reliable code blocks.
Scantist: What did your analysis reveal about the characteristics and common applications of external subcontracts?
Kairan: Our analysis showed that external subcontracts are a significant component of Solidity smart contracts, with over 80% of subcontracts being sourced externally. These external subcontracts are primarily interfaces and libraries, which are used to ensure consistency and adherence to standards. Common applications of these external subcontracts include implementing token standards like ERC20 and ERC721, as well as providing utility functions for safe mathematical operations and access control. We also observed an inconsistency in the use of subcontract types, such as libraries being misclassified as contracts, which can complicate code management. These findings underscore the need for standardized practices in using external components to enhance maintainability and security.
Scantist: How can these findings guide better contract development and third-party package management?
Kairan: The findings from our study highlight the importance of standardized practices in using external components for smart contract development. To improve contract development, developers should adopt standardized package managers tailored for Solidity to manage dependencies effectively. This includes documenting the origins and versions of external subcontracts to ensure traceability and facilitate vulnerability management. Regular auditing of third-party packages is crucial to identify and mitigate potential security risks. Furthermore, promoting the use of well-established and audited packages can enhance the overall security and reliability of smart contracts. By implementing these practices, developers can better manage external dependencies and reduce the risk of introducing vulnerabilities.
Scantist: What are the commonly used development patterns in smart contract development, and how did you identify them?
Kairan: We identified 61 frequently reused development patterns in smart contract development through frequent itemset mining and empirical analysis of over 350,000 contracts. These patterns primarily involve token creation, proxy contracts, and token swaps. For example, a significant portion of these patterns are related to the implementation of ERC20 and ERC721 token standards, which are essential for creating fungible and non-fungible tokens, respectively. Other common patterns include safe mathematical operations and access control mechanisms. Identifying these patterns helps in understanding common practices and areas with high standardization, providing valuable insights for developing secure and efficient smart contracts.
Scantist: What are the implications of these development patterns for smart contract security and efficiency?
Kairan: The identification of common development patterns has significant implications for both the security and efficiency of smart contracts. By standardizing frequently used patterns, developers can ensure that best practices are followed, reducing the likelihood of introducing errors or vulnerabilities. These patterns also facilitate code reuse, enhancing development efficiency and consistency across projects. However, reliance on common patterns can pose risks if vulnerabilities are discovered in these widely used components. Continuous monitoring and auditing of these patterns are essential to maintain security. Overall, the use of well-established patterns contributes to more robust and reliable smart contracts, provided that security considerations are adequately addressed.
Scantist: Based on your findings, what recommendations do you have for developers and auditors to improve smart contract development practices?
Kairan: Based on our findings, we recommend several practices for developers and auditors to enhance smart contract development. Developers should adopt specialized package managers for Solidity to manage dependencies more effectively, document the origins and versions of external subcontracts, and use standardized and audited packages. Auditors should establish a knowledge-based vulnerability database to streamline the audit process and focus on regularly auditing popular third-party packages. Additionally, both developers and auditors should promote best practices in coding and security, such as adhering to established standards and conducting thorough testing. By implementing these recommendations, the security and efficiency of smart contract development can be significantly improved.
