In order to better understand the process of software development of ICOs, for each of the 55 ICO projects selected in step 2 we examined the documentation to find the availability of software project repositories in which the development team stores and manages the software under development. We found that:
We analyzed the 32 Agile ICOs software projects available on Github. In particular, we counted the number of repositories (the folders of the project), the typology of files, and the number of solidity files.
In summary, the 32 Github projects contain a total of 14.199 files. The total number of folders is about 2800. On average, each project contains 5.8 repositories, and the maximum number of repositories per project is 38.
Regarding the contents, source code files represents the most of the files present in ICO software projects. In particular, js
summarizes the number of occurrences of the ten most common file types found in Agile ICO software projects.
To better understand the process underlying the development of Agile ICOs, we have verified for each project the use of specific development frameworks and in particular the use of Truffle
. Truffle is a popular development framework for Ethereum that includes built-in smart contract compilation, linking, deployment, binary management, and automated testing. Truffle is available at https://truffleframework.com
. We found that Truffle is commonly used in Agile ICOs. Nineteen out of 36 projects include the typical Truffle elements.
5.2.1. Smart Contract Code Metrics
In this section, we report the results of the analysis of the smart contracts used to implement the Agile ICOs. In particular, in order to characterize the content of these solidity files (with extension .sol
), we applied a selection of code metrics. We also report the comparison between our results with the results provided by [45
], related to more than 12,000 smart contracts published on the blockchain explorer Etherscan and deployed on the Ethereum blockchain until January 2018.
In our analysis, we examined 502 solidity files found in Agile ICOs github projects, which could be referred directly to the ICO developers. We excluded from our analysis the files copied (or forked
) from other projects (including templates taken from development framework like Openzeppelin
We added to the analysis the 12 smart contracts published only in Etherscan, as described before. In total, we examined 514 smart contract files. For each of them we applied the software metrics defined in Table 3
, that include volume metrics and complexity metrics. In the following, we will use the term contract
to refer to a specific type of object of the Solidity language [44
]. The declaration of an object contract
is similar to the declaration of a class
of object oriented languages. In a contract definition, it is possible declare functions and variables, that can be modified to be private, public, or internal to the contract. A solidity contract can also inherit from other contracts. We considered “function” the declaration, through the keyword function
, of the executable units of code within a contract. We did not considered as functions the definition of function modifiers
. In solidity, a modifier is a short portions of code defined through the keyword modifier
that can be called and incorporated in functions. They can be used to easily change the behavior of functions.
reports the summary of the statistics of the computed volume source code metrics. In the table, we also provide, for each metric, the value of the First Quartile that separates the lowest 25% of values from the highest 75%, and the Third Quartile that separates the lowest 75% of values from the highest 25%. All the reported statistics represent an overview of the distribution of metrics values. All statistical analysis were performed using R. Results show that smart contracts in Agile ICO projects have on average 65.59 lines of code. The maximum number of LOC is 808 and the minimum is 2. For comparison, results of [45
] report that the mean number of LOC is 183.8. We found that smart contracts present in Agile projects are characterized by a lower number of LOC.
The mean and the median value of CPL allows us to state that examined files are well commented. As reported, there is expected about one line of comments every two lines of code.
The examined solidity files declare, on average, only two contracts. This number can be considered low, in relation to the value of 9.2 reported by [45
]. The maximum number of contract declarations is 66 and the minimum is 1.
In total, the mean number of functions (NDF) declared in a contract is about 6.6, the maximum value is 71, and the minimum is zero. Also in this case, the mean number is lower than the results of [45
] (25.9 functions per file). The mean values of NDC and NDF can be considered related to the value of the LOC metric. Solidity files are shorter and consequently less functions and contracts are declared. Contracts having no function declarations can be used to define variables and data structures to be inherited by other contracts. In general, if there is no constructor, the contract will assume the default constructor.
The metric Function Per Contract (FPC) represents the equivalent of the number of method per class in object oriented languages. Considering each contract in the files, we found that, on average, each of them declare 4.3 functions. The maximum number of declared functions per contract is 28 and the minimum is zero. On average, each contract has functions that are long 7.8 lines (AFL). The maximum average length is 172.5. The related distribution is characterized by a high standard deviation.
From these results, we can deduce that the smart contracts of Agile ICOs tend to be short programs, with a limited number of elements (contracts and functions) and with short functions. This favors easier reuse and maintenance of the code, according to [46
In general, the development of the ICO token pass through the implementation of a standard interface called ERC20 (specifications described in https://theethereum.wiki/w/index.php/ERC20TokenStandard
). Given the availability of already implemented ERC20 tokens, the reuse of code is commonly adopted during the creation of new tokens. The high values of standard deviation show that smart contracts are very different from each other; these results are typical of long-tail distributions, whose tails collect the highest values.
For each solidity file, we computed the McCabe cyclomatic complexity [47
], of all the functions implemented in it. The cyclomatic complexity measures the number of linearly independent paths through a function. We used a commercial software. In particular, we computed the cyclomatic metrics using Understand
, by scitools
. Cyclomatic metrics are described in https://scitools.com/support/cyclomatic-complexity/
. Table 5
summarizes the results related to the average, the maximum and the sum of the cyclomatic complexity of all the functions defined in each solidity file belonging to Agile ICO projects. The minimum values of these metrics are equal to zero due to the presence of contracts that do not implement any function.
We found that the average cyclomatic complexity (ACyclo) has a value equal to 1.2. The maximum value of the average cyclomatic complexity is 7.
The maximum cyclomatic complexity (MaxCyclo) is, for each contract, the the maximum value of McCabe cyclomatic complexity among the functions of the contract. Its mean value is 1.83, and its highest value is equal to 17.
Contracts are characterized by a limited sum of the cyclomatic complexity (SumCyclo) computed for each function in their solidity files. The mean value of the sum is 7.97, lower than the value reported by [45
], due to the fact that contracts of Agile ICO projects are shorter in terms of LOC. Values of this metric are characterized by a standard deviation equal to 12.27, and a maximum value equal to 134. These value are typical of long tail distributions.
In the Ethereum platform, each smart contract deployed in the blockchain both the data related to the transactions, and the code that implements the logic to allow the sending of transactions between two or more actors. Therefore, data and logic that compose a smart contract are stored irreversibly. Given the principle of the immutability of the blockchain, once a smart contract gets deployed, its code cannot be changed.
If a developer finds a bug or wants to correct an error, s/he has to develop a new smart contract, deploy it on the blockchain and transfer all the existing data to the new contract. The deployment of a smart contract includes an Ethereum transaction that requires the payment of a fee, which depends on the size of the smart contract. For this reason, the test phase before the deployment is very important and it should be managed appropriately also through the adoption of best practices and specific tools for continuous testing, typical of Agile methodologies.