An empirical analysis of source code metrics and smart contract resource consumption

A smart contract (SC) is a programme stored in the Ethereum blockchain by a contract‐creation transaction. SC developers deploy an instance of the SC and attempt to execute it in exchange for a fee, paid in Ethereum coins (Ether). If the computation needed for their execution turns out to be larger than the effort proposed by the developer (i.e., the gasLimit ), their client instantiation will not be completed successfully. In this paper, we examine SCs from 11 Ethereum blockchain‐oriented software projects hosted on GitHub.com, and we evaluate the resources needed for their deployment (i.e., the gasUsed ). For each of these contracts, we also extract a suite of object‐oriented metrics, to evaluate their structural characteristics. Our results show a statistically significant correlation between some of the object‐oriented (OO) metrics and the resources consumed on the Ethereum blockchain network when deploying SCs. This result has a direct impact on how Ethereum developers engage with a SC: evaluating its structural characteristics, they will be able to produce a better estimate of the resources needed to deploy it. Other results show specific source code metrics to be prioritised based on application domains when the projects are clustered based on common themes

Untriviality of Trivial Packages

Nowadays, developing software would be unthinkable without the use of third-party packages. Although such code reuse helps to achieve rapid continuous delivery of software to end-users, blindly reusing code has its pitfalls. Prior work investigated the rationale for using packages of small size, known as trivial packages, that implement simple functionality. This prior work showed that, although these trivial packages are simple, they are popular and prevalent in the \npm ecosystem. This popularity and prevalence of trivial packages piqued our interest in questioning; first, the `triviality' of these packages and, second, the impact of using these packages on the quality of the client software applications. To better understand the `triviality' of trivial packages and their impact, in this thesis we report on two large scale empirical studies. In both studies, we mine a large set of JavaScript applications that use trivial \npm packages. In the first study, we evaluate the `triviality' of these packages from two complementary points of view: based on application usage and ecosystem usage. Our result shows that trivial packages are being used in important JavaScript files, by the means of their `centrality', in software applications. Additionally, by analyzing all external package API calls in these JavaScript files, we find that a high percentage of these API calls are attributed to trivial packages. Therefore, these packages play a significant role in JavaScript files. Furthermore, in the package dependency network, we observe that 16.8% packages are trivial and in some cases removing a trivial package can break approximately 30% of the packages in the ecosystem. In the second study, we started by understanding the circumstances which incorporate trivial packages in software applications. We analyze and classify commits that introduce trivial packages into software applications. We notice that developers resort to trivial packages while performing a wild range of development tasks that are mostly related to `Building' and `Refactoring'. We empirically evaluate the bugginess of the files and applications that use trivial packages. Our result shows that JavaScript files and applications that use trivial packages tend to have a higher percentage of bug-fixing commits than files and applications that do not depend on trivial packages. Overall, the findings of our thesis indicate that although smaller in size and complexity, trivial packages are highly depended on packages. These packages may be trivial by the means of size, their utility in software applications suggests that their role is not so trivial

Studying and Leveraging API Usage Patterns

Software projects make use of libraries extensively. Libraries have intended API surfaces—sets of exposed library interfaces that library developers expect clients to use. However, in practice, clients only use small fractions of intended API surfaces of libraries. Clients also use libraries in unexpected ways sometimes. Understanding usage patterns of library APIs by clients is beneficial to both client and library developers—targeting issues such as version upgrades, breaking changes and software bloating. We have implemented a tool to study both static and dynamic interactions between clients, the libraries they use, and those libraries’ direct dependencies. We use this tool to carry out a detailed study of API usage patterns on 90 clients and 11 libraries. We present a classification framework for developers to classify API uses. We then describe two additional developer-focussed applications of the data that our tool produces: a secondary visualization tool VizAPI, as well as the concept of library fission. Conceivably, VizAPI can allow client and library developers to answer the following queries about the interaction of their code and the libraries they depend on: Will my client code be affected by breaking changes in library APIs? Which APIs in my library’s source code are commonly used by clients? The concept of library fission, by which we mean the splitting of libraries into sub-modules, is based on the usage patterns that we observe. This can potentially help library developers release backward compatible versions of their libraries. It could also help client developers isolate breaking changes and reduce the likelihood of vulnerabilities and version conflicts that may be introduced through direct or transitive dependencies