Versioned Analysis of Software Quality Indicators and Self-admitted Technical Debt in Ethereum Smart Contracts with Ethstractor

TL;DR

The paper tackles the challenge of assessing smart-contract security across version histories in the Ethereum ecosystem by introducing Ethstractor, a tool that builds a versioned dataset from blockchain deployment metadata. It links contract versions through deployer and creation transactions, proxy patterns, and Etherscan data to enable longitudinal analyses of security and maintenance. The authors find that traditional code metrics poorly predict vulnerabilities and that vulnerabilities tend not to improve in newer contract versions, while self-admitted technical debt is rarely removed (only 6.49% of contracts with debt see removal). This work provides a new dataset and methodology for evaluating contract evolution and highlights the need for vulnerability-focused indicators beyond standard code metrics, with practical implications for security auditing and contract maintenance.

Abstract

The rise of decentralized applications (dApps) has made smart contracts imperative components of blockchain technology. As many smart contracts process financial transactions, their security is paramount. Moreover, the immutability of blockchains makes vulnerabilities in smart contracts particularly challenging because it requires deploying a new version of the contract at a different address, incurring substantial fees paid in Ether. This paper proposes Ethstractor, the first smart contract collection tool for gathering a dataset of versioned smart contracts. The collected dataset is then used to evaluate the reliability of code metrics as indicators of vulnerabilities in smart contracts. Our findings indicate that code metrics are ineffective in signalling the presence of vulnerabilities. Furthermore, we investigate whether vulnerabilities in newer versions of smart contracts are mitigated and identify that the number of vulnerabilities remains consistent over time. Finally, we examine the removal of self-admitted technical debt in contracts and uncover that most of the introduced debt has never been subsequently removed.

Figures (1)

• Figure 1: Architecture diagram showing the setup of the Ethstractor deployment. Blue lines signify interactions between Ethstractor and Etherscan; red lines are used for interactions between the Sanctuary dataset and Ethstractor; green lines show the reading of Etherscan API keys; and black lines show the writing to the output versioned dataset.