Blockchain is an immutable database shared by the participants of a distributed network (sai2019assessing)
. The main application of blockchain, thus far, has been cryptocurrencies such as Bitcoin and Ethereum. These blockchain-based cryptocurrencies are estimated to have a market capitalization of over 200 Million USD(sai2019privacy).
Given the monetary value associated with smart contract transactions, quality assessment and evaluation (kelly2006context) becomes vital but, even in traditional software systems, such quality assessment techniques can be quite informal (ali2018architecture). Although some argue for instant feedback regarding the quality control (buckley2013jittac), another approach is to apply well-established software metrics. Software metrics have conventionally been used to determine the quality, maintainability, and testability of programs (fenton2014software), and many programming-paradigm specific software metrics have been proposed (chidamber1994metrics; ryder2005software; ryder2004software). As Solidity adheres to the OO programming paradigm, the metrics proposed by (chidamber1994metrics) have been identified as potentially useful (tonelli2018smart; hegedus2019towards). These metrics may help the developers produce improved quality contracts that are easier to test and maintain.
Despite the syntactical and conceptual similarities between Solidity and conventional OO programming languages, they vary significantly. The immutability imposed on smart contracts by the target blockchain platform is the prime differentiating factor. Another significant difference is the cost of execution, where each byte code-level operation in Ethereum carries a dynamically calculated fee influenced by market forces within the network. Other differences include the functional limitations of Solidity. For example, the inability to return an array from a function (SolidityDocumentation; sergey2017concurrent). Developers have found several workarounds to these limitations. For example, where inheritance is favoured over composition (stover).
These differences may warrant a recalibration of existing OO metrics when applied to smart contracts. In this study, we aim to evaluate two such OO metrics empirically. Given the assertion in (stover), that Solidity may favor inheritance over composition, we restrict our focus to the inheritance-based metrics proposed by (chidamber1994metrics). This early research aims to provide preliminary evidence towards answering the following research question:
Does moving from traditional OO programming contexts to Solidity contracts impact inheritance-based practice, as measured by inheritance-based metrics?
In conventional software systems, a high degree of inheritance is often linked with greater complexity, resulting in more faults (cartwright1998empirical). It has been argued that misuse of such functionality should also be investigated (amann2018systematic). However, as functional and economic constraints limit the complexity of smart contracts, the codebase remains relatively simple. We anticipate that this relative simplicity of code might mitigate the potential complexity introduced by inheritance and may result in greater use. Additionally, as inheritance favours code reuse, we believe that developers will favour inheritance more in smart contracts than in traditional OO programs. We address this hypothesis through an empirical analysis.
The paper makes the following contributions:
We present an illustrative case study, as a motivating example, suggesting increased use of inheritance in Solidity smart contracts.
We present a small empirical study that captures inheritance-metric data for prominent smart contracts on Ethereum.
We present a comparison between inheritance in smart contracts and traditional systems based on our provisional findings (Section 5).
2. Software Metrics and Smart Contracts
Software metrics are commonly used for cost estimation, quality assessment, reliability testing, security evaluation, and complexity measurement (fenton2014software). Research suggests that such metrics should be employed in the evaluation of smart contracts owing to the financial value of the transactions they mediate (tonelli2018smart; hegedus2019towards). The paper by (pinna2019massive)
analyzed 10000 smart contracts and reported that the software code metrics such as line of code had lower values on average with high variances when compared with standard software. However, the research in specific metrics for smart contracts is in the early stages(porru2017blockchain; destefanis2018smart; tonelli2018smart; ghassemi2018reverse; 8327564). Due to the preliminary nature of our work in this area, we restrict our focus to the inheritance-based metrics proposed by (chidamber1994metrics).
In OO programming, inheritance is a technique by which one class or object can reuse code from another class or object (johnson1988designing). Due to the significance of inheritance in OO programming, its implication on cost, quality, and maintainability have been thoroughly examined (subramanyam2003empirical; daly1996evaluating; prechelt2003controlled; unger1998impact; singh2011investigation). A high degree of inheritance is often linked with greater complexity (cartwright1998empirical), which translates to more faults and higher costs. This adverse impact has led to the paradigm of ”Composition over Inheritance”(gamma1995design), but it is still widely used (knoernschild2002java). Thus, it becomes crucial to capture and measure different aspects of inheritance to work towards minimizing adverse effects. In this study, we restrict our investigation to the inheritance metrics proposed by (chidamber1994metrics):
Depth of Inheritance Tree (DIT) calculates the maximum length of a path from a class to the root class. (chidamber1994metrics) suggests that “if the depth of Inheritance tree has more than five steps, the code is too complex”.
Number of Children (NOC) indicates the number of immediate subclasses that depend on a class in the class structure. A large number of children classes are considered favorable due to greater code reuse.
3. Smart Contracts and Inheritance
Smart contracts were created in the early 1990s (bonneau2015sok; szabo1997idea) to specify an enforceable agreement for a transaction. Smart contracts are programs that can be correctly executed by a network without an external trusted authority (bartoletti2017empirical).
Solidity supports multiple inheritance. It follows the guidelines of the Python language and uses C3 Linearization (dannen2017introducing), which forces a specific order in the inheritance of classes.
Every byte code level operation in Ethereum carries an execution weight for every execution cycle. This weighted number is known as gas in the Ethereum ecosystem (wood2014ethereum). Each unit of gas has a variable price, driven by demand on the network, and developers tend to design smart contracts that can minimize the cost associated with execution. Inheritance in Solidity plays a significant role in reducing the gas cost associated with deployment and execution. Additionally, the use of inheritance as ’aggregation’ is not a language feature of Solidity. One workaround to implementing aggregation is through inter contract communication between separately deployed contract addresses (”internal transactions”) which results in an additional cost for execution (stack).
To demonstrate the impact of inheritance on the cost, we deployed two toy smart contracts on the Ethereum Testnet (iyer2018ethereum) and measure gas consumption. The first toy example illustrated in Listing 1 exploits inheritance for implementation and the second, functionally identical example (Listing LABEL:fig:code2), does not.