Table of Contents
Fetching ...

Charting The Evolution of Solidity Error Handling

Charalambos Mitropoulos, Maria Kechagia, Chrysostomos Maschas, Sotiris Ioannidis, Federica Sarro, Dimitris Mitropoulos

TL;DR

This paper investigates how Solidity error-handling features are used and how they evolve across versions and real-world contracts. It introduces SolBench, a data collection and analysis platform, to study 283K open-source Solidity contracts and 1.7M unique sources, linking usage patterns to compiler changes and documentation evolution. Key findings show a dominant reliance on require, rising adoption of try-catch after its introduction, and substantial EH misuses driven by external calls and input validation, all suggesting the need for better documentation and tooling. The work provides actionable recommendations, including enhanced examples, systematic version updates, and data-flow analyses to improve the reliability and security of smart contracts.

Abstract

The usage of error handling in Solidity smart contracts is vital because smart contracts perform transactions that should be verified. Transactions that are not carefully handled, may lead to program crashes and vulnerabilities, implying financial loss and legal consequences. While Solidity designers attempt to constantly update the language with new features, including error-handling (EH) features, it is necessary for developers to promptly absorb how to use them. We conduct a large-scale empirical study on 283K unique open-source smart contracts to identify patterns regarding the usage of Solidity EH features over time. Overall, the usage of most EH features is limited. However, we observe an upward trend (> 60%) in the usage of a Solidity-tailored EH feature, i.e., require. This indicates that designers of modern programming languages may consider making error handling more tailored to the purposes of each language. Our analysis on 102 versions of the Solidity documentation indicates the volatile nature of Solidity, as the language changes frequently, i.e., there are changes on EH features once or twice a year. Such frequent releases may confuse smart contract developers, discouraging them to carefully read the Solidity documentation, and correctly adopt EH features. Furthermore, our findings reveal that nearly 70% of the examined smart contracts are exposed to potential failures due to missing error handing, e.g., unchecked external calls. Therefore, the use of EH features should be further supported via a more informative documentation containing (1) representative and meaningful examples and (2) details about the impact of potential EH misuses.

Charting The Evolution of Solidity Error Handling

TL;DR

This paper investigates how Solidity error-handling features are used and how they evolve across versions and real-world contracts. It introduces SolBench, a data collection and analysis platform, to study 283K open-source Solidity contracts and 1.7M unique sources, linking usage patterns to compiler changes and documentation evolution. Key findings show a dominant reliance on require, rising adoption of try-catch after its introduction, and substantial EH misuses driven by external calls and input validation, all suggesting the need for better documentation and tooling. The work provides actionable recommendations, including enhanced examples, systematic version updates, and data-flow analyses to improve the reliability and security of smart contracts.

Abstract

The usage of error handling in Solidity smart contracts is vital because smart contracts perform transactions that should be verified. Transactions that are not carefully handled, may lead to program crashes and vulnerabilities, implying financial loss and legal consequences. While Solidity designers attempt to constantly update the language with new features, including error-handling (EH) features, it is necessary for developers to promptly absorb how to use them. We conduct a large-scale empirical study on 283K unique open-source smart contracts to identify patterns regarding the usage of Solidity EH features over time. Overall, the usage of most EH features is limited. However, we observe an upward trend (> 60%) in the usage of a Solidity-tailored EH feature, i.e., require. This indicates that designers of modern programming languages may consider making error handling more tailored to the purposes of each language. Our analysis on 102 versions of the Solidity documentation indicates the volatile nature of Solidity, as the language changes frequently, i.e., there are changes on EH features once or twice a year. Such frequent releases may confuse smart contract developers, discouraging them to carefully read the Solidity documentation, and correctly adopt EH features. Furthermore, our findings reveal that nearly 70% of the examined smart contracts are exposed to potential failures due to missing error handing, e.g., unchecked external calls. Therefore, the use of EH features should be further supported via a more informative documentation containing (1) representative and meaningful examples and (2) details about the impact of potential EH misuses.
Paper Structure (18 sections, 6 figures, 6 tables)

This paper contains 18 sections, 6 figures, 6 tables.

Figures (6)

  • Figure 1: Overview of SolBench.
  • Figure 2: The abstract syntax of the heuristic rules that represent the usages of the different error-handling (EH) features, according to the Solidity documentation (v0.8.19).
  • Figure 3: RQ2. Timeline of the Solidity releases. Each line corresponds to a Solidity release. A red line involves a release that incorporates changes in error handling.
  • Figure 4: RQ3. Error-handling (EH) usage across Solidity versions.
  • Figure 5: RQ3. Error-handling (EH) usage across years.
  • ...and 1 more figures