Self-Admitted Technical Debt in Ethereum Smart Contracts: A Large-Scale Exploratory Study
Pourquoi ce travail est dans la base
Une base qui oublie comment elle a trouvé un travail ne peut pas être vérifiée. Voici les voies qui ont admis celui-ci.
Notice bibliographique
Résumé
Programmable blockchain platforms such as Ethereum offer unique benefits to application development, including a decentralized infrastructure, tamper-proof transactions, and auditability. These benefits enable new types of applications that can bring competitive advantage to several business segments. Nonetheless, the pressure of time-to-market combined with relatively immature development technologies (e.g., the Solidity programming language), lack of high-quality training resources, and an unclear roadmap for Ethereum creates a context that favors the introduction of technical debt (e.g., code hacks, workarounds, and suboptimal implementations) into application code. In this paper, we study self-admitted technical debt (SATD) in smart contracts. SATD refers to technical debt that is explicitly acknowledged in the source code by developers via code comments. We extract 726 k real-world contracts from Ethereum and apply both quantitative and qualitative methods in order to (i) determine SATD prevalence, (ii) understand the relationship between code cloning and SATD prevalence, and (iii) uncover the different categories of SATD. Our findings reveal that, while SATD is not a widespread phenomenon (1.5% of real-world contracts contain SATD), SATD does occur in extremely relevant contracts (e.g., multi-million contracts). We also observed a strong connection between SATD prevalence and code cloning activities, leading us to conclude that the former cannot be reliably studied without taking the latter into consideration. Finally, we produced a taxonomy for SATD that consists of 6 major and 26 minor categories. We note that several minor categories are bound to the domain of blockchain and smart contracts, including gas-inefficient implementations and Solidity-induced workarounds. Based on our results, we derive a set of practical recommendations for contract developers and introduce open research questions to guide future research on the topic.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,000 | 0,000 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,001 | 0,002 |
| Études des sciences et des technologies | 0,000 | 0,000 |
| Communication savante | 0,000 | 0,000 |
| Science ouverte | 0,001 | 0,000 |
| Intégrité de la recherche | 0,000 | 0,001 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,000 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle