Charting The Evolution of Solidity Error Handling
February 05, 2024 Β· Declared Dead Β· π arXiv.org
"No code URL or promise found in abstract"
Evidence collected by the PWNC Scanner
Authors
Charalambos Mitropoulos, Maria Kechagia, Chrysostomos Maschas, Sotiris Ioannidis, Federica Sarro, Dimitris Mitropoulos
arXiv ID
2402.03186
Category
cs.SE: Software Engineering
Citations
4
Venue
arXiv.org
Last Checked
4 months ago
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.
Community Contributions
Found the code? Know the venue? Think something is wrong? Let us know!
π Similar Papers
In the same crypt β Software Engineering
R.I.P.
π»
Ghosted
R.I.P.
π»
Ghosted
Microservices: yesterday, today, and tomorrow
π
π
The Cartographer
A Survey of Machine Learning for Big Code and Naturalness
R.I.P.
π»
Ghosted
An Overview on Smart Contracts: Challenges, Advances and Platforms
R.I.P.
π»
Ghosted
Slither: A Static Analysis Framework For Smart Contracts
R.I.P.
π»
Ghosted
ContractFuzzer: Fuzzing Smart Contracts for Vulnerability Detection
Died the same way β π» Ghosted
R.I.P.
π»
Ghosted
Federated Learning: Strategies for Improving Communication Efficiency
R.I.P.
π»
Ghosted
In-Datacenter Performance Analysis of a Tensor Processing Unit
R.I.P.
π»
Ghosted
Deep Convolutional Neural Networks for Computer-Aided Detection: CNN Architectures, Dataset Characteristics and Transfer Learning
R.I.P.
π»
Ghosted