Smart Contracts Software Metrics: a First Study

© 2018 The Author(s).Smart contracts (SC) are software codes which reside and run over a blockchain. The code can be written in different languages with the common purpose of implementing various kinds of transactions onto the hosting blockchain, They are ruled by the blockchain infrastructure and work in order to satisfy conditions typical of traditional contracts. The software code must satisfy constrains strongly context dependent which are quite different from traditional software code. In particular, since the bytecode is uploaded in the hosting blockchain, size, computational resources, interaction between different parts of software are all limited and even if the specific software languages implement more or less the same constructs of traditional languages there is not the same freedom as in normal software development. SC software is expected to reflect these constrains on SC software metrics which should display metric values characteristic of the domain and different from more traditional software metrics. We tested this hypothesis on the code of more than twelve thousands SC written in Solidity and uploaded on the Ethereum blockchain. We downloaded the SC from a public repository and computed the statistics of a set of software metrics related to SC and compared them to the metrics extracted from more traditional software projects. Our results show that generally Smart Contracts metrics have ranges more restricted than the corresponding metrics in traditional software systems. Some of the stylized facts, like power law in the tail of the distribution of some metrics, are only approximate but the lines of code follow a log normal distribution which reminds of the same behavior already found in traditional software systems.Submitted Versio

How do you propose your code changes? Empirical analysis of affect metrics of pull requests on GitHub

Software engineering methodologies rely on version control systems such as git to store source code artifacts and manage changes to the codebase. Pull requests include chunks of source code, history of changes, log messages around a proposed change of the mainstream codebase, and much discussion on whether to integrate such changes or not. A better understanding of what contributes to a pull request fate and latency will allow us to build predictive models of what is going to happen and when. Several factors can influence the acceptance of pull requests, many of which are related to the individual aspects of software developers. In this study, we aim to understand how the affect (e.g., sentiment, discrete emotions, and valence-arousal-dominance dimensions) expressed in the discussion of pull request issues influence the acceptance of pull requests. We conducted a mining study of large git software repositories and analyzed more than 150,000 issues with more than 1,000,000 comments in them. We built a model to understand whether the affect and the politeness have an impact on the chance of issues and pull requests to be merged - i.e., the code which fixes the issue is integrated in the codebase. We built two logistic classifiers, one without affect metrics and one with them. By comparing the two classifiers, we show that the affect metrics improve the prediction performance. Our results show that valence (expressed in comments received and posted by a reporter) and joy expressed in the comments written by a reporter are linked to a higher likelihood of issues to be merged. On the contrary, sadness, anger, and arousal expressed in the comments written by a reporter, and anger, arousal, and dominance expressed in the comments received by a reporter, are linked to a lower likelihood of a pull request to be merged

Taxonomic insights into ethereum smart contracts by linking application categories to security vulnerabilities

The expansion of smart contracts on the Ethereum blockchain has created a diverse ecosystem of decentralized applications. This growth, however, poses challenges in classifying and securing these contracts. Existing research often separately addresses either classification or vulnerability detection, without a comprehensive analysis of how contract types are related to security risks. Our study addresses this gap by developing a taxonomy of smart contracts and examining the potential vulnerabilities associated with each category. We use the Latent Dirichlet Allocation (LDA) model to analyze a dataset of over 100,040 Ethereum smart contracts, which is notably larger than those used in previous studies. Our analysis categorizes these contracts into eleven groups, with five primary categories: Notary, Token, Game, Financial, and Blockchain interaction. This categorization sheds light on the various functions and applications of smart contracts in today's blockchain environment. In response to the growing need for better security in smart contract development, we also investigate the link between these categories and common vulnerabilities. Our results identify specific vulnerabilities associated with different contract types, providing valuable insights for developers and auditors. This relationship between contract categories and vulnerabilities is a new contribution to the field, as it has not been thoroughly explored in previous research. Our findings offer a detailed taxonomy of smart contracts and practical recommendations for enhancing security. By understanding how contract categories correlate with vulnerabilities, developers can implement more effective security measures, and auditors can better prioritize their reviews. This study advances both academic knowledge of smart contracts and practical strategies for securing decentralized applications on the Ethereum platform

Mycotoxin production in liquid culture and on plants infected with Alternaria spp. isolated from rocket and cabbage.

Fungi belonging to the genus Alternaria are common pathogens of fruit and vegetables with some species able to produce secondary metabolites dangerous to human health. Twenty-eight Alternaria isolates from rocket and cabbage were investigated for their mycotoxin production. Five different Alternaria toxins were extracted from synthetic liquid media and from plant material (cabbage, cultivated rocket, cauliflower). A modified Czapek-Dox medium was used for the in vitro assay. Under these conditions, more than 80% of the isolates showed the ability to produce at least one mycotoxin, generally with higher levels for tenuazonic acid. However, the same isolates analyzed in vivo seemed to lose their ability to produce tenuazonic acid. For the other mycotoxins; alternariol, alternariol monomethyl ether, altenuene and tentoxin a good correlation between in vitro and in vivo production was observed. In vitro assay is a useful tool to predict the possible mycotoxin contamination under field and greenhouse conditions

DAI: A Dependencies Analyzer and Installer for Solidity Smart Contracts

The growing importance of Decentralized Applications (dApps) in areas such as the Internet of Things (IoT), Cybersecurity, and Finance is playing a crucial role in advancing software maintenance, security, and data sharing. Understanding the complex architecture and components of dApps is essential to harness their full benefits. This often involves the challenging task of identifying and retrieving key components during the dApp compilation process, particularly when dealing with multiple external dependencies. A case in point is the variety of versions in the OpenZeppelin libraries, where finding compatible elements can be a laborious process. In response to this challenge, we introduce DAI (Dependency Analyser and Installer), a novel tool that automates the identification of compatible external dependency versions for specific smart contracts. This tool significantly simplifies the compilation process for dApps that incorporate external modules, making it more efficient for developers and researchers. We evaluated DAI on 57 real-world dApps, achieving success in determining the right dependency match for 50 cases. However, the inability to compile the remaining 7 dApps due to missing files and artifacts highlights the ongoing complexities in dApp development