1

Profiling Gas Leaks in Solidity Smart ContractsGerardo Canfora, Andrea Di Sorbo, Sonia Laudanna, Anna Vacca, Corrado A. Visaggio

Abstract—Nowadays, more and more applications are developed for running on a distributed ledger technology, namely dApps. Thebusiness logic of dApps is usually implemented within smart contracts developed through Solidity, a programming language for writingsmart contracts on different blockchain platforms, including the popular Ethereum. In Ethereum, the smart contracts run on the machinesof miners and the gas corresponds to the execution fee compensating such computing resources. However, the deployment andexecution costs of a smart contract depend on the implementation choices done by developers. Unappropriated design choices couldlead to higher gas consumption than necessary. In this paper, we (i) identify a set of 19 Solidity code smells affecting the deploymentand transaction costs of a smart contract, and (ii) assess the relevance of such smells through a survey involving 34 participants.On top of these smells, we propose GasMet, a suite of metrics for statically evaluating the code quality of a smart contract fromthe gas consumption perspective. An experiment involving 2,186 smart contracts demonstrates that the proposed metrics have directassociations with deployment costs. The metrics in our suite can be used for more easily identifying source code segments that needoptimizations.

Index Terms—Software Engineering for Blockchain Technologies, Smart Contracts Optimization, Code Quality, Software Metrics,Empirical Study

F

1 INTRODUCTION

Blockchain emerged as the enabling technology [34] forimplementing transactions of electronic cash, namely cryp-tocurrency, without the brokerage of a financial institution.Thanks to the versatility of this technology, it is now in-creasingly adopted in several contexts, with different pur-poses far beyond crypto-currencies. Indeed, blockchain isimpacting a variety of business sectors; at illustrative aim,some recent applications using blockchain concern1: sharingof sensitive data, electronic voting, cross-border payments,personal identity security, goods authenticity and traceabil-ity, real estate processing. The global blockchain technologymarket size is expected to reach USD 57,641.3 million by2025 [1]. This forecast entails that in the next years we willwitness a significant spreading of decentralized applications(dApps from here on), i.e., computer applications which runon a distributed ledger technology (DLT).

The business logic of dApps is usually implementedwithin smart contracts, i.e., fully-fledged programs thatrun on blockchain. Ethereum is one of the most popularblockchain platforms [9] and provides an environment tocode and run smart contracts [44]. In this environment,smart contracts are typically developed through the Solidityobject-oriented language, before being compiled into byte-codes that can be executed by the Ethereum Virtual Machine(EVM).

As each underlying technology imposes its peculiaritiesand characteristics to applications that run on top of it,also blockchain introduces critical aspects affecting smartcontract development. For instance, the immutability of

• G. Canfora, A. Di Sorbo, S. Laudanna, A. Vacca and C. A. Visaggio arewith the Department of Engineering, University of Sannio, Benevento,Italy.E-mail: {canfora, disorbo, slaudanna, avacca, visaggio}@unisannio.it

1. See https://builtin.com/blockchain/blockchain-applications

blockchain complicates smart contract maintenance activ-ities, as, once deployed, they can hardly be patched [16].For this reason, it is crucial ensuring that a smart contractis bug-free and well designed before deploying it to theblockchain [8]. Besides, since smart contracts run on ablockchain infrastructure, a key factor is the cost of execu-tion due to the mining of the blocks participating in thechain. On the Ethereum platform, the gas (in Ether) corre-sponds to the execution fee compensating for such comput-ing resources. Pragmatically speaking, gas corresponds toreal money; unoptimized smart contracts can lead to unnec-essary gas leaks and, thus, to money losses [32]. Moreover,when the users produce a high number of transactions, if thedApp is not properly designed, the execution costs could benot sustainable by the business model of the DecentralizedApplication Organization (DAO) which manages it.

The choices done by developers, such as the types ofdata structures used, the number of cycles, the kind of in-structions, the types of variables used, where and how theyare initialized or valued, may affect the gas consumptionof a smart contract. Although recent research [32] outlineddesign patterns and guidelines for the development of moreoptimized smart contracts from the gas consumption per-spective, programming resources and development environ-ments that can help developers more easily identifying codeunits that need to be optimized are still lacking. This is alsoconfirmed by the survey conducted by Zou et al. [47], inwhich the majority of interviewed smart contract developersfeel that optimizing gas is painful, especially in complexapplications, and it would be important to have tools thatallow optimizing smart contract source code rather thanbytecode. Indeed, to estimate gas consumption, a typicalworkflow consists of deploying the smart contract withina simulated DLT running on private workstation or local

arX

iv:2

008.

0544

9v2

[cs

.SE

] 1

5 D

ec 2

020

servers and obtaining an estimation of the cost2. If the costis too high, the smart contract is modified, deployed againon the local simulated DLT, and the new cost is evaluated.This process is repeated till the result is satisfying.

To fill this gap, the goal of our work is to provide atool for helping developers more easily identifying codeunits that may be optimized for achieving gas savings. Inparticular, developers communities have identified Soliditycost smells, which are code anti-patterns that negativelyaffect deployment and transaction costs of a smart contract.Such cost smells are not gathered into a unique catalog,but they are dispersed within different books, reports, andweb forums. In this paper, we collect a set of 19 cost smellsand, through a survey involving 34 among smart contractdevelopers and researchers, assess the perceived relevanceof the collected cost smells. On top of these smells, wedefine a suite of code metrics, namely GASMET (standingfor Gas Metrics), for statically evaluating the code qualityof smart contracts, from the gas consumption perspective.The metrics in our suite can help developers capturingthe occurrences of the identified cost smells within smartcontracts’ source code. Through an experiment involving2,186 real-world smart contracts, we obtain empirical evi-dence about the relationships existing between the definedmetrics and gas consumption required by the deploymentof a smart contract. The advantage brought by GasMet isthat the developers can more easily localize the segmentsof their code that need optimization, while coding, withoutdeploying or running it on a DLT, simulated or real.

The original contribution of this paper includes:• a collection of cost smells, i.e., patterns of code that entail a

higher cost of smart contract deployment and execution;• the results of a survey involving real smart contract develop-

ers on the perceived relevance of each defined cost smell;• GasMet, a suite of metrics for identifying the occurrences of

the defined cost smells; and• an empirical study for identifying the GasMet metrics that

most correlate with deployment costs.In the literature, researchers proposed tools for (i) infer-

ring upper bounds of gas consumption in terms of sizesof the input parameters of the functions, the contract state,and blockchain data [2], [3], and (ii) automatically identify-ing gas-related vulnerabilities [19]. Our suite of metrics (i)provides information that is complementary to the one pro-vided by the aforementioned tools, and (ii) aims at support-ing developers in timely identifying potential inefficienciesin the smart contracts/functions implementations that couldlead to higher gas consumption when deploying smartcontracts. In particular, our metrics do not take into accountfunction inputs, as previous experiments demonstrated thatonly a small percentage of smart contracts (i.e., about 10%)do not follow the Ethereum safety recommendations3 andtheir gas consumption depends on the size of data stored,the size of functions inputs, or the blockchain state [3].

Paper structure. The paper proceeds as follows. Section 2highlights the novelty of our findings with respect to theexisting literature. Section 3 details the identified cost smells,

2. https://ethereum.stackexchange.com/questions/27452/how-to-estimate-gas-cost

3. https://github.com/ethereum/wiki/wiki/Safety

while Section 4 illustrates our study on the relevance ofthe identified cost smells and discusses the related results.Section 5 introduces the GasMet suite, while Section 6 dealswith the validation of the suite and the results of ourcorrelation analysis with gas consumption. Threats to ourstudy’s validity are commented in Section 7 and, finally,Section 8 concludes the paper.

2 RELATED WORK

In this Section, we discuss the related literature that hasbeen mainly devoted to studying (i) software metrics forBlockchain-Oriented Software (BOS in the remainder of thepaper), (ii) issues related to weaknesses in smart contractssource code, and (iii) evaluation of gas consumption.

2.1 BOS software metricsOrtu et al. [36] provided a statistical characterisation ofBOS. The authors inspected and compared 5 C++ opensource Blockchain-Oriented and 5 Traditional Java softwaresystems, to discover strength differences between the twocategories of projects, and particularly in the statistical dis-tribution of 10 software metrics. Even if there are similaritiesbetween the statistical distributions for Traditional soft-ware and Blockchain software, the distribution of AverageCyclomatic and Ration Comment To Code metrics detectsignificant differences, whereas the Number of Statementsmetric reveals meaningful differences on the double Paretodistribution.

Hegedus [24] used OO metrics for estimating proper-ties of the smart contracts written in Solidity. Based onthe results, the author found that smart contract programsare short, not excessively complex and with no many orno comments. Furthermore, it would be useful for smartcontracts to have an external library and dependency man-agement mechanisms because many libraries have similarfunctionalities.

Tonelli et al. [42] investigated the differences betweenthe software metrics measured on Smart contracts (SC) andmetrics extracted from traditional software systems. Theauthors built their dataset form the Etherscan collection4,taking the Smart Contracts bytecode, the Application BinaryInterface (ABI), and the Smart Contract source code (writtenin Solidity) for each sample. The authors implemented acode parser to extract the software metrics for each smartcontract considered. They have computed: the total linesof code to a specific blockchain address, the number ofsmart contracts inside a single address code, blank lines,the comment lines, the number of static calls to events,the number of modifiers, the number of functions, num-ber of payable functions, the cyclomatic complexity as thesimplest McCabe definition, the number of mappings toaddresses for the dataset considered. Based on the results,smart contract lines of code is the metric that is closest atthe statistical distribution of the corresponding metric intraditional software system.

Gencer et al. [18] proposed a measurement frameworkfor two of the dominant cryptocurrencies, Bitcoin andEthereum. They estimated the network resources of nodes

4. https://etherscan.io/

2

and the interconnection among them, the protocol require-ments influencing the operation of nodes, and the robust-ness of the two systems against attacks to analyze the depthof decentralization. They found that neither Bitcoin norEthereum has rigorously better properties than the other.

Other papers have computed more specific metricstailored for specific application domains, such as health-care [46], and model the real-time predictive delivery per-formance in supply chain management [33].

With respect to these metrics, the ones of the suiteproposed in this paper aim at evaluating Solidity code’spatterns that deteriorate the performance of the smart con-tract’s deployment.

2.2 Weaknesses on Smart Contract’s source code

A part of literature on BOS concerns the analysis anddetection of different types of weaknesses affecting the codeof a smart contract.

Ye et al. [45] realized a comparison of the state-of-artbug detection tools and executed experiments to find theiradvantages and disadvantages.

By analyzing the literature, Demir et al. [15] identifiedthe vulnerabilities that developers must fix when writingsmart contracts. In addition, they analyzed applications thatseek these vulnerabilities and provided an overview of howthey are used and which they cover. In their analysis, theyidentified issues related to smart contracts and provideda discussion about the problems, the challenges and thetechniques of the available technology in this area.

Peng et al. [37] proposed SIF, a framework useful forSolidity contract monitoring, instrumenting, and code gen-eration. SIF is able to detect bugs, analyze, optimize andgenerate code to support developers and testers. This frame-work has been tested on real smart contracts deployed onthe Ethereum platform.

Tikhomirov et al. [41] propose a classification of problemsthat may occur in smart contract code. Subsequently, theyimplemented a static analysis tool that can identify them,called Smartcheck. The tool converts Solidity source codeinto an XML-based intermediate representation and com-pares it with XPath models. The tool has been tested on alarge set of real smart contracts.

Kalra et al. [17] presented ZEUS, a framework to checkthe correctness and confirm the fairness of smart contracts.By correctness, they mean using secure programming prac-tices, instead fairness indicates compliance with high-levelbusiness logic. ZEUS simultaneously uses abstract interpre-tation, the symbolic model checking and the horn clausesto speedily check the security of smart contracts. Zeus hasbeen tested on over 22,000 smart contracts and it has shownthat around 94.6% of them are vulnerable.

In our study, we focus on the cost smells which, at the bestknowledge of the authors, is a novel area of investigation inthe literature regarding BOS.

2.3 Gas Cost Evaluation

Literature studying the relationship between the smart con-tract’s code and the cost of its deployment and executionhas yet a small number of contributions.

Baird et al. [5] explore of the economics of smart con-tracts. There is a disparity that continues to increase betweenthe actual costs of executing smart contracts and the compu-tational costs. This occurs because the gas cost-model of theEthereum Virtual Machine (EVM) instruction-set is poorlyimplemented. To resolve this problem momentarily, theEthereum community increases the cost of gas periodically.In their study, the authors showed a new gas cost modelthat fixes the principal irregularity of the current Ethereumgas cost model. Their new cost model blocks the ongoinginflation of execution time per unit of gas.

Chen et al. [9] proposed an analysis to show that manysmart contracts have dependencies on the cost of gas andcould be replaced by more efficient bytecodes to save gas.For this goal, they implement GASPER to automaticallydiscover gas-costly programming patterns from the byte-code of smart contracts. Their analysis focuses on deadcodes, Opaque Predicates, Expensive Operations in a Loopin relation to the gas cost using bytecode; our metrics extractinformation from a smart contract but at a higher level thanbytecode, i.e. at source code level.

More recently, Albert et al. [2], [3] proposed methods andtools for automatically inferring gas upper bounds for smartcontract functions, while Grech et al. [19] presented a staticanalysis tool for detecting gas-focused vulnerabilities insmart contracts. Instead, Marchesi et al. [32] have identifieda set of 24 design patterns that influence gas consumption inthe execution of Ethereum smart contract. After classifyingthese design patterns into 5 categories (external transaction,storage, saving space, operations and miscellaneous), foreach pattern, they describe the problem and a possiblesolution. We can observe similarities between the cost smellsand patterns identified by Marchesi et al.. In particular,based on the descriptions provided, 14 cost smells identifiedin our study are similar to patterns presented in priorwork. However, differently from this previous study, we (i)validated the relevance of the identified cost smells througha survey involving real smart contract developers, and (ii)defined a suite of metrics for more easily identifying thecode smells that can negatively impact gas consumption.

In a different effort, Chen et al. [8] defined 20 types ofcontract defects, by analyzing posts on Ethereum StackEx-change5. Among the defects identified, there are functionsand data types that can increase gas consumption. As in ourstudy, to validate the elicited contract defects, they conduct asurvey with practitioners and evaluate the diffusion of suchdefects in 587 real world smart contracts. However, whileprevious work mainly focuses on characterizing differenttypes of defects and only suggests the implementation ofpractical tools for practitioners, our study has a specialfocus on bad coding practices that can negatively affectgas consumption, also providing developers with a concretesuite of metrics for more easily evaluating smart contractcode quality from the gas consumption perspective.

3 ELICITATION OF COST SMELLS

We identified a set of cost smells, by inspecting specializedforums and books dealing with the development of Solidity

5. https://ethereum.stackexchange.com/

3

TABLE 1The list of the identified Cost Smells along with the rationale explaining the relationship with the gas consumption.

Id Cost Smell Description Ref.

CS1 Duplicate writes Modifying a variable’s value several times could require much gas. To save gas, developersshould overwrite variables outside cycles as much as possible. [11]

CS2 Abundance ofpublic members

The order of the functions influences the gas consumption. Since the order of the functions isbased on the method ID, this implies that the subsequent ordering can consume additionalgas. Depending on the VM transaction, each position will have an additional gas fee. Sinceall public members participate in the sorting, reducing public members could save gas.

[10]

CS3 Scarcity of exter-nal functions

Storing the input parameters in memory costs gas. For all public functions, the inputparameters are copied to memory automatically. If a function is only called externally, itshould be explicitly marked as external, in a way that these parameters are not storedinto memory but are read from call data directly. This can save gas when the function inputparameters are huge.

[22]

CS4Inefficient initial-ization of vari-ables

An uninitialized variable is automatically set with its default value (e.g., a uint256 variable,when not initialized, it is assumed to have the default value 0). When declaring a variable,explicitly setting it with its default value is useless and wastes gas.

[23]

CS5 Inefficient use oflibraries

When a public function of a library is called, the bytecode of that function is not made partof a client contract. Thus, complex logic should be put in libraries for keeping the contractsize small.

[23]

CS6 Inefficient use ofinternal functions

From inside a smart contract, calls to internal functions are cheaper than calls to publicfunctions. A call to a public function implies that all the parameters are copied intomemory and passed to that function. Conversely, a call to an internal function does notentail copying such parameters into memory again.. For this reason the use of internalfunctions is preferable whenever possible, especially when the parameters are big.

[23]

CS7 Inefficient use ofmemory arrays

Whenever a developer has to make some internal computation in a solidity function withthe help of an array, it may be good to avoid using storage, by employing memory arrays.If the size of the array is exactly known, fixed size memory arrays can be used to save gas.

[39]

CS8 Inefficient use ofstrings

Using bytes32 is cheaper than using the string type. If the length of the string can belimited to a certain number of bytes, bytes1 to bytes32 data types are preferable whereverpossible.

[6]

CS9 Inefficient use ofreturn values

A simple optimization in Solidity consists of naming the return value of a function. It is notneeded to create a local variable then. [26]

CS10 Inefficient use ofglobal variables

Storing global variables in memory is expensive in terms of gas. Number and size for globalvariables should be minimized. [12]

CS11 Unbounded loops In general, loops should be avoided. If avoiding loops is not possible, it could be beneficialto try to avoid unbounded loops, i.e., loops where the upper limit of iterations is not defined. [43]

CS12 Inefficient use ofdata types

Use bytes32 whenever possible, because it is the most optimized storage type. Forexample, storing a small number in a uint8 variable is not cheaper than storing it intoa uint256 variable, as, for storing, any smaller data is padded with zeros to fill the 32bytes, requiring additional operations from the EVM and additional gas.

[43]

CS13Inefficient use ofindexed parame-ters

The indexed parameters in events have additional gas costs. It is preferable to only use theindexed qualifier for event parameters that should be searchable. [4]

CS14 Inefficient use ofstructs

Since many DApps use storage, it would be useful to reduce archiving costs in order tooptimize gas costs. To do this, using structs is less expensive than using mappings. [7]

CS15 Inefficient use ofmappings

Mappings are cheaper than arrays. It is cheaper to use arrays only when smaller elementsare used, such as uint8 that can be packed together. In other cases, arrays might cost moregas than mappings.

[22]

CS16 Inefficient use ofexternal calls

Every call to an external contract costs a decent amount of gas. For optimizing gas usage,it is better to call one function and have it return all the needed data rather than calling aseparate function for every piece of data.

[22]

CS17 Inefficient use ofbooleans

Booleans (bool) are uint8 which means they use 8 bits of storage even if they can have onlytwo values: True or False. When EVM packs the bools normally it can store only 32 bools inone memory slot.Otherwise, a set of 256 different booleans could be more efficiently packedin a single word by not declaring them as bool but uint256, using one bit for each booleanvalue.

[23]

CS18 Inefficent use ofevents It is cheaper to store data that is not required on-chain in events rather than variables. [23]

CS19 Inefficient use offunctions

In Solidity, it could be preferable using fewer larger functions, rather than implementingmultiple functions, each performing a single small task. Indeed, multiple smaller functionscost more gas and require more bytecode.

[23]

smart contracts. Although exhaustively identifying any pos-sible cost-related defect in smart contracts is not an objectiveof this paper, we relied on multiple sources to spot out somecommon bad practices in smart contract development withSolidity that can negatively impact gas consumption. Inparticular, we (i) leveraged some textbooks [4], highlightinggood practices in smart contracts and decentralized applica-tions development, and (ii) consulted technical blog postsdealing with Solidity and gas optimization tips. Specifi-cally, to mine potential smell-related posts, the keywords(i) “Solidity gas consumption”, (ii) “Solidity gas usage”, (iii)

“Solidity gas optimization”, and (iv) “Solidity gas saving”have been used to perform the Google search. By inspectingthe ten top-ranked retrieved documents for each searchquery, we were able to discover ten blog posts specificallytargeting Solidity coding practices for optimizing gas us-age [6], [7], [10]–[12], [22], [23], [26], [39], [43]. Relying onthe aforementioned information sources, we found that, ingeneral, gas consumption could be negatively affected by:

• inefficient use of data storage;• inefficient implementation of functions.

4

In particular, we identified 19 cost smells (i.e., codingpractices entailing higher gas consumption). Table 1 reportsthe identified cost smells, along with a brief description ofeach smell and a reference to the webpage from which it hasbeen deduced. In particular, the cost smells reported in Table1 could be related to either inefficient use of data storage(i.e., CS1, CS4, CS7, CS8, CS9, CS10, CS11, CS12, CS13, CS14,CS15, CS17, and CS18) or an inefficient implementation offunctions (i.e., CS2, CS3, CS5, CS6, CS16, and CS19).

4 STUDY ON THE RELEVANCE OF COST SMELLS

The goal of this study is to investigate whether the identifiedcost smells (see Section 3) are considered as relevant bydevelopers. To pursue this goal, we pose our first researchquestion:

RQ1: To what extent are the identified cost smells relevant forsmart contract developers?

4.1 Research methodTo address RQ1, we conduct a survey targeting experts inthe development of Solidity smart contracts and blockchainapplications. Relevant guidelines on how to design andcarry out survey studies in software engineering are pro-vided in previous work [27]–[31], [38]. On the one hand,according to such guidelines, we (i) design specific and mea-surable goals, (ii) target subjects able to answer the questionsposed, (iii) group questions into topics, and (iv) when possible,use standardized response formats. On the other hand, we cannot estimate whether the set of subjects involved in oursurvey is a representative subset of the target population,as we have no prior knowledge of such a population.Specifically, the survey is structured in three sections:

• The first section aims at collecting demographic infor-mation about respondents. In particular, this sectioncomprises questions about: (i) the highest educationqualification; (ii) the domain in which respondentswork (e.g., industry, academia, etc.); (iii) their role in theorganization (e.g., developer, project manager); (iv) theyears of experience in software development; (v) morespecifically, the years of experience in smart contractdevelopment, and (vi) the languages used to developsmart contracts.

• The second section gathers the developers’ perceivedrelevance about the identified Solidity code smells thatmay affect gas consumption. Each smell is presented torespondents through a brief description of the problem,outlining its effects on gas usage and the optimizationsto mitigate or avoid such effects. For each smell, weask to provide a relevance score on a 5-level Likertscale [35] (in which 1 corresponds to strongly disagreeand 5 corresponds to strongly agree). Finally, for eachquestion, the respondents could provide an optionalopen comment.

• The final section asks questions about the general per-ceived usefulness of a suite of metrics for more easilyidentifying the identified cost smells while coding, i.e.,(i) whether respondents perceive the availability of sucha suite of metrics useful, and (ii) whether they would bewilling to adopt it during smart contract development.

Finally, we ask to provide free comments about possibleSolidity code smells that were not considered in ourstudy.

To recruit participants, we posted a link to thequestionnaire on Reddit channels related to Ethereumand Solidity development, namely solidity, dapps,cryptodevs, ethdev, and ethereum. Along with thelink to the online survey, we added a short message ex-plaining its purpose, the estimated duration (20 min.), andour will to only use the collected data in aggregated,anonymized form. Besides, we sent the invitation for thequestionnaire completion to our contacts who are workingor study blockchain-related topics in companies or aca-demic institutions. Furthermore, we invited practitionerswho regularly contribute to smart contract-related projectson GitHub.

We summarize the responses obtained in our survey inthe form of diverging stacked bar charts, also discussing theopen comments reported by the respondents.

4.2 Results

Our survey on cost smells relevance has been kept openfor one month. During this period we were able to collectresponses from 34 different respondents. Out of the 34respondents, 12 own a Bachelor’s degree, 12 a Master’sdegree, and 6 a Ph.D. 14 respondents have less than 5 yearsof development experience, 10 between 5 and 10 years, and10 more than 10 years. Concerning smart contract develop-ment, 12 respondents have less than a year of experience,16 between 1 and 3 years, and 6 more than 3 years. Mostof the participants (33) in our survey declare to developsmart contracts using Solidity, while just one respondentdevelops smart contracts with Kotlin. About 80% of surveyrespondents (27) are smart contract developers, besides3 blockchain researchers, 2 teachers at blockchain-relatedcourses, one participant involved in smart contract testing,and one product owner.

In Figure 1 the diverging stacked bar charts summarizethe perceived relevance of the 19 identified cost smells.The three percentages reported in the graph indicate theproportion of disagreements, neutral responses, and agree-ments, respectively. As illustrated in Figure 1, the majorityof interviewed developers agree or strongly agree on mostof the identified cost smells. In particular, about four-fifths ofthe participants in our study agree or strongly agree on ninesmells (i.e., CS3, CS6, CS7, CS8, CS10, CS11, CS13, CS14, andCS16), about three-fifths of them agree or strongly agree onfive smells (i.e., CS1, CS9, CS12, CS15, and CS18), and foronly two smells (i.e., CS2 and CS17) we observe that lessthan 50% of respondents agreed. However, in these lattertwo cases (i.e., CS2 and CS17), developers mainly tend toassume a neutral position (35% and 44% of respondents,respectively), rather than disagreeing. Indeed, concerningCS2, surveyed developers acknowledge that public mem-bers influence gas consumption, “though this is not the lo-cation where devs should worry too much about optimization”.According to their opinions (i) the cost/benefit of reducingpublic members could be not so high (e.g., “The effects on gascosts due to function selector I would imagine are secondary toother savings I’d imagine”), and (ii) the optimization should be

5

Fig. 1. Perceived relevance of the 19 cost smells.

performed at Ethereum or compiler level (e.g., “This should befixed at the Ethereum or Solidity compiler level.”). Similarly, forCS17, although “bit-fiddling-concepts are an amazing source forgas saving tactics”, survey respondents feel that these tacticssignificantly hamper code readability (e.g., “I don’t think it isworth saving gas if it impacts that much the code readability”)and “the benefit in terms of gas consumption should be carefullyevaluated”. However, for ensuring both code readability andgas savings, they recommend that this kind of optimizationshould be handled at compiler level rather than source codelevel (e.g., “If this is of concern, the compiler should handle it”).

For all identified smells, less than one-third of the par-ticipants disagree or strongly disagree. In the cases in whichwe observe higher percentages of disagreements, surveyparticipants are mostly concerned about code readabilityand believe that eventual optimization should be performedat the compiler level, rather than directly in the sourcecode. As reported in previous work [47], it is often hardto optimize gas without reducing code readability, as moreefficient code basically requires fewer instructions. This isthe case of CS4, in which, even if the developers are awarethat avoiding initializing a variable to its default valuewould be an easy strategy for gas optimization, they alsoargue about the negative effects on code readability (e.g., “Itsaves gas but also degrades readability”). Indeed, according tosome of the participants in our survey, explicitly initializingvariables is always a good practice, otherwise “it is difficultduring a review to know if the intent for the variable was tobe initialized to the default value, or if the variable is missingthe initialization”. Other participants suggest “adding a smallcomment to document the default value” initialization, to saveboth gas and code readability. For the same reason, someof the developers involved in our study believe that defaultvalue variable initialization could be optimized at a levellower than source code (e.g., “Statically initialising a variable

to its default value should be caught by the compiler and reducedto a no-op”).

Comments of a similar sort are received for CS9, whererespondents recommend balancing “the readability and thegas consumption”, as the “benefit is minimal compared to read-ability”. Indeed, they believe that the few “cost saved doesnot justify the decrease in code readability”, as named returnvalues “are frequently the source of vulnerabilities”. Thus, sincenamed return values help in “reducing the size of a contract,although of a small factor”, their usage is “an optimisation thecompiler should do”. Beyond code readability, developers ar-gue that some optimizations could increase error-proneness.This is what happens for CS1. More specifically, the surveyrespondents think that “it’s a waste of gas to increment astorage variable in a loop”. However, they report that theoptimization reduces code quality as it is “more error-prone”(e.g., “. . . If the dev changes later the number of loop iteration, hemight forget to change the increase of count, which can lead to abug/vulnerability”), and they also highlight that the situationwhere the “variable won’t be used” inside the loop “is notcommon in developing’s logic”.

Instead, according to the interviewed developers, codereadability is just one of the concerns related to CS5 andderiving from the adoption of libraries (e.g., “This has itsplace but can also reduce readability”; “what is not in the contractcode is not transparent on the blockchain”). Indeed, libraries can“cause all sorts of issues” and they are rarely used “becauseof the difficulty of managing their deployment”. In addition,survey participants also highlight that the use of librariesfor saving gas mainly depends on the application’s context.Indeed, while using libraries could be a good strategy to re-duce the deployment cost, it can also increase the executioncost (e.g., “With a library, you reduce the gas cost of deployment,but you increase the gas cost of executing the contract”; “Callsto an external library (payed with each call) may become more

6

Fig. 2. Survey responses on perceived usefulness of a suite of metrics for identifying cost smells

expensive than the deployment costs (payed once)”). Finally,the comments about CS19 indicate a general reluctance ofdevelopers to adopt coding practices that would reducemodularization (“This discourages good coding practices of mod-ularisation and small, well-contained functions”). In particular,the subjects in our study consider security and readability“more important than gas usage in most cases” and keepingthe business logic clear is important “for transparency andverification reasons” (e.g., “Devs should aim to create smallfunctions with a clear purpose, rather than complex functionsdifficult to review and to test. This is another case where the gassaving does not justify the decrease in code readeability imho”).

Figure 2 reports, again in the form of diverging stackedbar charts, the results about (i) the perceived usefulness of asuite of metrics for more easily identifying the enumeratedsmells, and (ii) the willingness of respondents to use it ifavailable. 30 out of 34 respondents (88%) agreed or stronglyagreed about the usefulness of a suite of metrics capturinggas consumption information, and 28 participants (82%) in-dicated that they would use it in the smart contract develop-ment process. However, as highlighted by one of the surveyparticipants the “problem of metrics is that they may becomequickly outdated when the compiler changes the way it generatesbytecode”, and optimizing code for gas consumption at thebytecode level would be of broader applicability. However,since smart contract developers desire to optimize sourcecode rather than bytecode [47], software metrics can allowthem to directly identify the portions of source code thatwould have room for efficiency improvement.

RQ1 Summary: Smart contract developers generally agreeor strongly agree about the identified cost smells. However,they point out that some optimizations may negatively impactcode readability. The vast majority of respondents are in favorof adopting a suite of source code metrics for more easilyidentifying cost smells.

5 THE GASMET SUITE

Relying on the cost smells reported in Table 1, we definea suite of metrics, called GasMet metrics, able to captureinformation related to each smell. In particular, we definethe following metrics:

• Assignments within Cycles (ACI): it computes theassignments and/or variable updates occurring withincycles. As specified by the CS1 smell, higher values ofthis metric could be related to a higher gas consump-tion.

• Public Members (PM): it enumerates the functionsdefined as public members. As specified by the CS2smell, higher values of this metric could be related tohigher gas consumption.

• External Functions (EF): it enumerates the functionsdefined as external. As specified by the CS3 smell,higher values of this metric could be related to lowergas consumption.

• Assignments to default values (AZ): it computes theassignments to default values during variable defini-tions. It is worth to notice that we limit to considersuch assignments only in the case of variable definitionstatements, as in other cases it can happen that anassignment to a default value could be used to resetthe value of the variable. As specified by the CS4 smell,higher values of this metric could be related to a highergas consumption.

• Library Imports (LI): it estimates the usage of exter-nal libraries. Given the number of import statements,Simport, and the contract’s lines of code, LOC:

LI =Simport

LOC

As specified by the CS5 smell, higher values of thismetric could be related to a lower gas consumption.

• Internal Functions (IFF): it computes the ratio of inter-nal functions on the total number of defined functions.Given the number of internal functions, Finternal, andthe number of overall functions, Fall, defined in thecontract:

IFF =Finternal

Fall

As specified by the CS6 smell, higher values of thismetric could be related to a lower gas consumption.

• Uses of Memory Arrays (UMA): it computes the ratioof memory arrays on the total amount of defined ar-rays within the contracts. Given the number of arraysdefined as memory, Amemory , and the total amount ofdefined arrays, Aall:

UMA =Amemory

Aall

As specified by the CS7 smell, higher values of thismetric could be related to a lower gas consumption.

• Strings and Bytes (SB): it computes the occurrences ofstring variables with respect to the occurrences of bytes.Given the number of string variables, Vstring , and thenumber of bytes variables, Vbytes:

SB =VstringVbytes

7

As specified by the CS8 smell, higher values of thismetric could be related to a higher gas consumption.

• Functions Returning Local Variables (RLV): it com-putes the ratio of functions returning local variableson the total number of functions. Given the number offunctions returning local variables, Flocal, and the over-all number of functions, Fall, defined in the contract:

RLV =Flocal

Fall

As specified by the CS9 smell, higher values of thismetric could be related to a higher gas consumption.

• Global Variables (GV): it computes the number ofglobal variables. As specified by the CS10 smell, highervalues of this metric could be related to a higher gasconsumption.

• Number of Loops (NLF6): it computes the number ofloops inside the contracts. As specified by the CS11smell, higher values of this metric could be related toa higher gas consumption.

• Number of non-32-bytes variables (NU): it computesthe ratio of non-32-bytes type variables on the totalnumber of variables. As specified by the CS12 smell,higher values of this metric could be related to a highergas consumption.

• Indexed Parameters (IP): it computes the number of pa-rameters declared as indexed within events. As specifiedby the CS13 smell, higher values of this metric could berelated to a higher gas consumption.

• Number of Mappings (NM): it computes the occur-rences of mapping with respect to occurrences of in-stance variables. As specified by the CS14 smell, highervalues of this metric could be related to a higher gasconsumption.

• Mappings and Arrays (MA): it computes the ratio ofmappings with respect to the sum of mappings andarrays defined in the contract. Given the occurrencesof mappings, Nmappings and the occurrences of arrays,Narrays:

MA =Nmappings

(Nmappings +Narrays)

As specified by the CS15 smell, higher values of thismetric could be related to a lower gas consumption.

• External Calls (EC): it computes the ratio of calls to ex-ternal functions (i.e., not defined in the contract) on thetotal number of function calls. Given the occurrencesof calls to external functions, Cexternal, and the totalnumber of calls within the contract, Call:

EC =Cexternal

Call

As specified by the CS16 smell, higher values of thismetric could be related to a higher gas consumption.

• Boolean Variables (BV): it computes the ratio of booleanvariables on the number of total variables. Given thenumber of variables of the boolean type, Vbool, thenumber of overall variables, Vall:

BV =VboolVall

6. the ’f’ letter is added in order to avoid omonymity with ne ’NL’metric of the Chidamber and Kemerer metric Suite

As specified by the CS17 smell, higher values of thismetric could be related to a higher gas consumption.

• Number of Events (NE): it computes the number ofevents. As specified by the CS18 smell, higher values ofthis metric could be related to a lower gas consumption.

• Defined Functions (DF): it computes the number of thefunctions with respect to the overall lines of code. Giventhe number of overall defined functions, Fall, and theamount of lines of code, LOC:

DF =Fall

LOC

As specified by the CS19 smell, higher values of thismetric could be related to higher gas consumption.

The defined metrics could help in statically measuringthe code quality of smart contracts, from the gas consump-tion perspective. In particular, they could represent a guidefor developers for improving this facet of smart contract’squality, as very localized changes might be required toimprove the values of the specific metrics. For example, toachieve lower values of the ACI metric (and, consequently,save gas cost), it is sufficient to reduce the number ofvariable updates occurring within cycles. We implementeda prototype Java tool able to parse Solidity smart contractsand automatically compute the metrics in the GasMet suite.In particular, for properly parsing smart contracts writtenthrough both older and newer versions of the Solidity lan-guage, the tool uses a generated parser based on a modifiedversion of an existing antlr4 grammar7.

6 STUDY ON THE RELATIONS BETWEEN GASMETMETRICS AND DEPLOYMENT COSTS

The goal of this second study is to more-in-depth investigatethe relationships between the individual metrics in theGASMET suite and smart contracts’ deployment costs. Morespecifically, this investigation aims at assessing whetherour suite can capture gas-related information by analyzingsmart contracts’ source code. To pursue this goal, we poseour second research question:

RQ2: To which extent does the GasMet suite correlate withgas consumption?

6.1 Context selection and data extraction

For this study, we built a dataset of 2,186 Solidity smartcontracts, randomly selected from a repository [40] encom-passing 47,037 smart contracts. In particular, all the smartcontracts present in such repository have been actuallydeployed on the Ethereum blockchain and their source codehas been validated by Etherscan. The number of samples inour dataset was defined for guaranteeing high representa-tiveness of the whole data collection, fixing the confidencelevel at 0.95 and the confidence interval smaller than 3.For each selected smart contract, we extracted the valuesof the GasMet metrics, by using the parser we developed(see Section 5).

Table 2 groups the smart contracts considered in our dataset according to the number of lines of source code (SLOC).

7. https://github.com/solidityj/solidity-antlr4

8

TABLE 2Lines of source code of the analyzed contracts

# of source code lines #instance %instanceSLOC <50 462 21.1

50 ≤ SLOC < 100 800 36.6100 ≤ SLOC < 500 794 36.3

SLOC ≥ 500 130 5.9

It is worth noticing that about 73% of the analyzed contractshave a size expressed in lines of source code between 50and 500, while only a limited number of them (i.e., about6%) exhibit higher values of SLOC.

To collect data on gas consumption, we used the built-in smart contract compilation. The compilation processfor smart contracts involves the Truffle suite [21] and theEthereum client Ganache [20] where it gets deployed. Truf-fle Suite is a collection of tools for the development andtesting of Ethereum blockchain based software. It containsTruffle which is the most popular development and testingframework using the Ethereum Virtual Machine (EVM). Thecompilation and deployment pipeline of Ethereum smartcontract, that we used, is as follows:

1) setting up an Ethereum development environment: we cre-ate a Truffle project, read smart contracts from dataset,create a deployment script that deploys and initializesthe state of deployed contracts on blockchain specifiedin the project config file, and

2) collect data regarding gas consumption: Ganache is a localtest blockchain included in the above mentioned TruffleSuite. The gas consumption, on local blockchain, iscomputed by: gasCost * gasPrice. gasPrice represents theprice to pay per gas unit to deploy the contracts underTruffle project and was set, in our experimentation, tothe value of 1 Wei (1 Ether = 1018 Wei). gasCost isthe maximum number of gas unit the EVM can use toprocess the contract deployment transaction.

Replication package. All the analyzed contracts sourcecode (.sol files), as well as the metrics’ results, are madepublicly available in our replication package8.

6.2 Analysis method

For answering RQ2, we considered the values of GasMetmetrics computed on the smart contracts in our datasetand the related values of gas consumption collected bydeploying such smart contracts (see in Section 6.1). Morespecifically, to evaluate if significant relationships can befound between (i) each of the GasMet metrics and the gasconsumption, and (ii) each pair of GasMet indicators, weused the Spearman rank correlation coefficient [14], fixingthe p-value ≤ 0.05 and adopting the Holm’s p-value cor-rection procedure [25] to deal with multiple comparisons.We interpret the strength of the correlation as (i) small for0.10 ≤ |ρ| ≤ 0.29, (ii) medium for 0.30 ≤ |ρ| ≤ 0.49,and (iii) large for |ρ| ≥ 0.50, as recommended by Cohen’sstandard [13].

6.3 Results

Figure 3 reports the results of the Spearman correlationbetween each pairs of the metrics in the GasMet suite andbetween the GasMet metrics and gas consumption. It isworth noticing that in Figure 3 we do not consider the LImetric, as, when computing this metric on the instances inour dataset, all zero values have been obtained.

All the results considered in the following discussioncorrespond to an adjusted p-value ≤ 0.05.

Four metrics of the GasMet suite are more stronglylinked to the gas consumption (in accordance with theCohen’s standard), since their correlations with the gas costhave a large effect size, which are: (i) the occurrences ofpublic members (PM, with ρ = 0.65), (ii) the number ofglobal variables (GV, with ρ = 0.75), (iii) the number ofindexed parameters (IP, with ρ = 0.56), and (iv) the numberof events (NE, with ρ = 0.59). Higher PM values correspondto a higher gas consumption since public members are hash-sorted, and the sorting algorithm entails a certain fixedquantity of gas (depending on the EVM transactions) foreach position in the list. Global variables cause an additionalcost due to the storing of information within the smartcontract’s state on the blockchain, so their usage must bereduced and replaced with local variables which are notstored on the blockchain. Similarly, indexed parametersconsume more gas than non-indexed parameters, while, ifproperly used, events could be adopted to store data that isnot required on-chain.

With regards to the metrics that exhibited a mediumeffect size in the correlation with the gas cost, nine shouldbe mentioned: (i) the ratio of internal functions (IFF) withρ = 0.46, (ii) the ratio of external calls (EC) with ρ = 0.45,(iii) the ratio of boolean variables (BV) with ρ = 0.44,(iv) the assignments within cycles (ACI) with ρ = 0.44,(v) the number of loops (NLF) with ρ = 0.40, (vi) theassignments to default values (AZ) with ρ = 0.39, (vii) thenumber of functions returning local variables (RLV) withρ = 0.38, (viii) the number of non-32-bytes variables (NU)with ρ = 0.30, and (ix) the ratio of mappings (MA) withρ = 0.30.

By observing the pairwise correlations between the met-rics, we can discover the developers’ habits in writing smartcontracts that can negatively influence gas consumption.Among the correlations with a large effect size, we can ob-serve (i) the one between the Number of Indexed Parameters(IP) and Number of Events (NE), with ρ = 0.96, and (ii)the one between the Assignment Within Cycles (ACI) andNumber of Loops (NLF), with ρ = 0.93. From these tworelationships it emerges that two bad practices are prettycommon: the first one is the use of indexed parameterswithin the events, while the second one consists of valuingvariables inside the cycles. As previously mentioned, boththe practices lead to an increasing of gas cost, and shouldbe discouraged. The correlation between ACI and AZ, withρ = 0.63, suggests that assignments to default values oftenoccur within the cycles and this trend is also confirmed bythe large correlation between NLF and AZ (ρ = 0.69). Thelarge effect size (ρ = 0.52) of the correlation between the

8. https://github.com/paperSubmition2020/GasmetReplicationPackage

9

Fig. 3. Spearman correlation results among the metrics belonging to the GasMet suite and the gas cost (values with x above is used to indicate thecorrelations that are not statistically significant).

Number of Loops (NLF) and the Mappings and Array (MA)metric also implies that loops are frequently used to iterateover mappings.

Finally, the number of global variables (GV) usuallygrows when higher numbers of (i) public members (i.e., PM,ρ = 0.58), (ii) internal functions (i.e., IFF, ρ = 0.50), (iii)events (i.e., NE, ρ = 0.59), or (iv) indexed parameters (i.e.,IP, ρ = 0.60) are adopted.

RQ2 Summary: Thirteen metrics of the GasMet suite exhibitlarge (PM, GV, IP, NE) or medium (ACI, AZ, IFF, RLV, NLF,NU, MA, EC, BV) correlations with gas consumption requiredby smart contract deployment. The correlations between thepairs of GasMet metrics allow identifying frequent codingpatterns that influence gas consumption.

7 THREATS TO VALIDITY

Threats to construct validity concern the relationship betweentheory and observation. The most important threat thatcould affect our results is related to possible imprecision/in-completeness in identifying cost smells. In particular, suchsmells have been identified by relying on information en-compassed in specialized forums/books focused on thedevelopment of Solidity smart contracts. Thus, some of theidentified smells (and, consequently, the related metrics inour suite) could be related to anecdotal observations. To

partially mitigate this weakness, in our RQ1, we studiedif domain experts (i.e., smart contract developers) perceivesuch smells as relevant. The majority of survey respondentsgenerally agree with the identified smells. However, weasked developers to rate the importance of smells by onlyproviding short descriptions of the problems. To counteractthis issue, such descriptions where accompanied by someexplanatory examples. Indeed, no respondents indicatedpossible misunderstanding in the questions.

Threats to conclusion validity concern the relationship be-tween treatment and outcome. Appropriate, non-parametricstatistical procedures have been adopted to draw our con-clusions concerning RQ2. More specifically, we used theSpearman rank correlation coefficient, to investigate therelationships between the different metrics in the GasMetsuite and the gas cost. To cope with multiple tests, theHolm’s correction procedure has been adopted to adjust p-values.

Threats to internal validity concern factors that can affectour results. The subjects of our analysis in Section 6 aresmall to medium size smart contracts, and this could reducethe likelihood of specific cost smells to be present in agiven smart contract. In particular, such an issue may havehindered the statistical relevance of some tests. To copewith this problem, in the future, we plan to replicate ourexperiments by also considering smart contracts of largersize.

10

Threats to external validity concern the generalization ofthe findings. The set of identified cost smells is surelyincomplete. Further research is needed to more-in-depthexplore broader sets of Solidity coding practices that cannegatively influence gas consumption. Indeed, our workjointly attempts to (i) tackle the problem of cost smellsin Solidity source code, and (ii) conceive approaches tohelp developers more easily identifying them during smartcontract development. With regards to RQ2, our study hasbeen carried out on a data collection comprising 2,186 real-word solidity smart contracts for which Etherscan providesthe source code. The smart contracts in our dataset may benot representative of all smart contracts deployed on theblockchain, and some of the findings may depend on thespecific data we used. For partially alleviating this threat, weselected a statistically significant sample of the 47,037 smartcontracts encompassed by the original Etherscan dataset.However, while this study is only observational, in thefuture we plan to carry out experiments at a larger scaleto verify the generalizability of the obtained results. TheEthereum platform and Solidity are constantly evolving ata fast pace [44] and future optimizations might be appliedin opcodes and/or in the compilation process of Soliditysmart contracts. Clearly, the latter could have effects onthe relationships exhibited by some of the metrics in oursuite and the gas consumption. Furthermore, as our researchis not exhaustive, in the future, additional metrics betteroutlining the code quality of smart contracts (from the gasconsumption perspective) may be identified.

8 CONCLUSION

Although the Blockchain technology has established as theenabling layer for allowing the transactions of electroniccash, namely cryptocurrency, without the brokerage of afinancial institution, it is now increasingly applied to manyother domains. One of the key aspects to govern whendeveloping a distributed application (dApp), i.e. an applica-tion built on the top of a DLT, is the cost of execution that, ifnot properly limited, can easily lead to relevant diseconomy,especially considering the issues related to guaranteeing theservice levels when scaling up the distributed application.The back-end logic of a dApp is defined in smart contractsthat run on blockchain. Currently, to the best of authors’knowledge, there are no tools that can be used while codingto help developers properly identifying the code segmentsthat need optimizations for achieving lower gas consump-tion. Considering that the choices done by the developerwhile writing the smart contracts can affect the deploymentand execution costs, we identified 19 patterns of code thatcan increase (or reduce) the gas consumption, namely costsmells. Through a survey involving real smart contract de-velopers, we demonstrated that the majority of respondentsperceive 15 out of 19 smells as relevant. The vast majority ofrespondents also agree or strongly agree on the usefulnessof a suite of metrics for more easily identifying such costsmells.

On top of the identified smells, we defined a set ofmetrics, namely the GasMet suite, in which each metric triesto capture the occurrences of a cost smell. Through a studyinvolving 2,186 smart contracts, we empirically demonstrate

that a subset of GasMet strongly correlates with the gasconsumption, namely GV, PM, IP, and NE, while associa-tions with medium effect size are observed between a furthersubset of the defined metrics, namely ACI, AZ, IFF, RLV,NLF, NU, MA, EC, and BV, and the deployment cost. Oursuite can be acquired as tool for allowing developers tooptimize smart contracts by easily localizing cost smells andimprove the related code segments. This paper providesseveral contributions to the research community:

• a catalog of cost smells for Solidity programming lan-guage, validated through a survey involving smartcontract developers (see Sections 3 and 4);

• a corresponding measurement suite, namely GasMetfor easily identifying cost smells while coding (seeSection 5);

• a tool that computes the GasMet metrics by staticallyinspecting the Solidity code of smart contracts (seeSection 5); and

• an empirical validation of the GasMet suite, along witha corpus of smart contracts that can be used for furtherexperiments, accessible from our replication package.

Since the cost smells defined in this work are strictlydependent on the Solidity programming language, as fu-ture work, we plan to investigate if more general designpractices, not related to a specific programming language,could be defined to achieve savings in gas consumption.

REFERENCES

[1] “Blockchain Technology Market Size, Share, Trends AnalysisReport By Type, By Component, By Application, By EnterpriseSize, By End Use, By Region And Segment Forecasts, 2019 -2025 ,” https://www.reportlinker.com/p05807295/Blockchain-Technology-Market-Size-Share-Trends-Analysis-Report-By-Type-By-Component-By-Application-By-Enterprise-Size-By-End-Use-By-Region-And-Segment-Forecasts.html?utm source=PRN, 2019, online; accessed 29 February 2020.

[2] E. Albert, J. Correas, P. Gordillo, G. Roman-Dıez, and A. Rubio,“GASOL: gas analysis and optimization for ethereum smart con-tracts,” in Tools and Algorithms for the Construction and Analysis ofSystems - 26th International Conference, TACAS 2020, Held as Partof the European Joint Conferences on Theory and Practice of Software,ETAPS 2020, Dublin, Ireland, April 25-30, 2020, Proceedings, Part II,2020, pp. 118–125.

[3] E. Albert, P. Gordillo, A. Rubio, and I. Sergey, “Running on fumes- preventing out-of-gas vulnerabilities in ethereum smart contractsusing static resource analysis,” in Verification and Evaluation ofComputer and Communication Systems - 13th International Conference,VECoS 2019, Porto, Portugal, October 9, 2019, Proceedings, 2019, pp.63–78.

[4] B. Badr, R. Horrocks, and X. B. Wu, Blockchain By Example: Adeveloper’s guide to creating decentralized applications using Bitcoin,Ethereum, and Hyperledger. Packt Publishing Ltd, 2018.

[5] K. Baird, S. Jeong, Y. Kim, B. Burgstaller, and B. Scholz, “Theeconomics of smart contracts,” arXiv preprint arXiv:1910.11143,2019.

[6] V. A. Bhushan, “Optimizing smart contracts for cost,” https://labs.imaginea.com/optimizing-smart-contracts-for-cost/,2018, online; accessed 21 February 2020.

[7] N. Blitz, “Storing Structs is costing you gas,” https://medium.com/@novablitz/storing-structs-is-costing-you-gas-774da988895e, 2018, online; accessed 21 February 2020.

[8] J. Chen, X. Xia, D. Lo, J. Grundy, X. Luo, and T. Chen, “DefiningSmart Contract Defects on Ethereum,” IEEE Transactions on Soft-ware Engineering, 2020.

[9] T. Chen, X. Li, X. Luo, and X. Zhang, “Under-optimized smartcontracts devour your money,” in 2017 IEEE 24th International Con-ference on Software Analysis, Evolution and Reengineering (SANER).IEEE, 2017, pp. 442–446.

11

[10] Y.-C. Chen, “[Solidity] How does function name affect gasconsumption in smart contract,” https://medium.com/joyso/solidity-how-does-function-name-affect-gas-consumption-in-smart-contract-47d270d8ac92, 2018, online; accessed 21 February2020.

[11] ——, “[Solidity] Optimize Smart Contract Gas Usage,”https://medium.com/joyso/solidity-save-gas-in-smart-contract-3d9f20626ea4, 2018, online; accessed 21 February 2020.

[12] CipherZ, “Optimizing your Solidity contract’s gas usage,”https://medium.com/coinmonks/optimizing-your-solidity-contracts-gas-usage-9d65334db6c7, 2018, online; accessed 21February 2020.

[13] J. Cohen, “Statistical power analysis for the behavioral sciencessecond edition,” Lawrence Erlbaum Associates, Publishers, 1988.

[14] W. W. Daniel, “Spearman rank correlation coefficient,” Appliednonparametric statistics, 2nd ed. PWS-Kent, Boston, pp. 358–365, 1990.

[15] M. Demir, M. Alalfi, O. Turetken, and A. Ferworn, “Security smellsin smart contracts,” in 2019 IEEE 19th International Conference onSoftware Quality, Reliability and Security Companion (QRS-C). IEEE,2019, pp. 442–449.

[16] G. Destefanis, M. Marchesi, M. Ortu, R. Tonelli, A. Bracciali, andR. Hierons, “Smart contracts vulnerabilities: a call for blockchainsoftware engineering?” in 2018 International Workshop on BlockchainOriented Software Engineering (IWBOSE). IEEE, 2018, pp. 19–25.

[17] M. Dhawan, “Analyzing safety of smart contracts,” in Proceedingsof the Conference: Network and Distributed System Security Sympo-sium, San Diego, CA, USA, 2017, pp. 16–17.

[18] A. E. Gencer, S. Basu, I. Eyal, R. Van Renesse, and E. G. Sirer, “De-centralization in bitcoin and ethereum networks,” in InternationalConference on Financial Cryptography and Data Security. Springer,2018, pp. 439–457.

[19] N. Grech, M. Kong, A. Jurisevic, L. Brent, B. Scholz, and Y. Smarag-dakis, “Madmax: surviving out-of-gas conditions in ethereumsmart contracts,” Proc. ACM Program. Lang., vol. 2, no. OOPSLA,pp. 116:1–116:27, 2018.

[20] T. B. Group, “ganache,” https://www.trufflesuite.com/ganache,2019, online; accessed 1 November 2019.

[21] ——, “truffle,” https://www.trufflesuite.com/, 2019, online; ac-cessed 1 November 2019.

[22] M. Gupta, “Solidity gas optimization tips,” https://mudit.blog/solidity-gas-optimization-tips/, 2018, online; accessed 21 Febru-ary 2020.

[23] ——, “Solidity tips and tricks to save gas and reduce byte-code size,” https://blog.polymath.network/solidity-tips-and-tricks-to-save-gas-and-reduce-bytecode-size-c44580b218e6, 2019,online; accessed 21 February 2020.

[24] P. Hegedus, “Towards analyzing the complexity landscape ofsolidity based ethereum smart contracts,” Technologies, vol. 7, no. 1,p. 6, 2019.

[25] S. Holm, “A simple sequentially rejective multiple test procedure,”Scandinavian journal of statistics, pp. 65–70, 1979.

[26] K. Jelski, “Three tips for optimizing gas,” http://blockbites.io/bites/bite2.html, 2019, online; accessed 21 February 2020.

[27] B. A. Kitchenham and S. L. Pfleeger, “Principles of survey researchpart 2: designing a survey,” ACM SIGSOFT Software EngineeringNotes, vol. 27, no. 1, pp. 18–20, 2002.

[28] ——, “Principles of survey research: part 3: constructing a surveyinstrument,” ACM SIGSOFT Software Engineering Notes, vol. 27,no. 2, pp. 20–24, 2002.

[29] ——, “Principles of survey research part 4: questionnaire evalua-tion,” ACM SIGSOFT Software Engineering Notes, vol. 27, no. 3, pp.20–23, 2002.

[30] ——, “Principles of survey research: part 5: populations andsamples,” ACM SIGSOFT Software Engineering Notes, vol. 27, no. 5,pp. 17–20, 2002.

[31] ——, “Principles of survey research part 6: data analysis,” ACMSIGSOFT Software Engineering Notes, vol. 28, no. 2, pp. 24–27, 2003.

[32] L. Marchesi, M. Marchesi, G. Destefanis, G. Barabino, andD. Tigano, “Design Patterns for Gas Optimization in Ethereum,”in 2020 IEEE International Workshop on Blockchain Oriented SoftwareEngineering (IWBOSE). IEEE, 2020, pp. 9–15.

[33] M. H. Meng and Y. Qian, “A blockchain aided metric for predic-tive delivery performance in supply chain management,” in 2018IEEE International Conference on Service Operations and Logistics, andInformatics (SOLI). IEEE, 2018, pp. 285–290.

[34] S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,”https://bitcoin.org/bitcoin.pdf, 2008, online; accessed 29 Febru-ary 2020.

[35] A. N. Oppenheim, Questionnaire design, interviewing and attitudemeasurement. Bloomsbury Publishing, 2000.

[36] M. Ortu, M. Orru, and G. Destefanis, “On comparing softwarequality metrics of traditional vs blockchain-oriented software: Anempirical study,” in 2019 IEEE International Workshop on BlockchainOriented Software Engineering (IWBOSE). IEEE, 2019, pp. 32–37.

[37] C. Peng and A. Rajan, “Sif: A framework for solidity code instru-mentation and analysis,” arXiv preprint arXiv:1905.01659, 2019.

[38] S. L. Pfleeger and B. A. Kitchenham, “Principles of survey re-search: part 1: turning lemons into lemonade,” ACM SIGSOFTSoftware Engineering Notes, vol. 26, no. 6, pp. 16–18, 2001.

[39] D. Szego, “Solidity gas optimization - memory arrays,”http://danielszego.blogspot.com/2018/01/solidity-gas-optimization-memory-arrays.html, 2018, online; accessed 21February 2020.

[40] thec00n, “etherscan verified contracts,” https://github.com/thec00n/etherscan verified contracts, 2018, online; accessed 21October 2019.

[41] S. Tikhomirov, E. Voskresenskaya, I. Ivanitskiy, R. Takhaviev,E. Marchenko, and Y. Alexandrov, “Smartcheck: Static analysis ofethereum smart contracts,” in Proceedings of the 1st InternationalWorkshop on Emerging Trends in Software Engineering for Blockchain,2018, pp. 9–16.

[42] R. Tonelli, G. Destefanis, M. Marchesi, and M. Ortu, “Smartcontracts software metrics: a first study,” arXiv preprintarXiv:1802.01517, 2018.

[43] B. Skvorc, “Audits beyond code: optimizing gas,” https://audithor.io/audits-beyond-code-optimizing-gas/, 2018, online;accessed 21 February 2020.

[44] M. Wohrer and U. Zdun, “Smart contracts: security patterns in theethereum ecosystem and solidity,” in 2018 International Workshopon Blockchain Oriented Software Engineering, IWBOSE@SANER 2018,Campobasso, Italy, March 20, 2018, 2018, pp. 2–8.

[45] J. Ye, M. Ma, T. Peng, Y. Peng, and Y. Xue, “Towards automatedgeneration of bug benchmark for smart contracts,” in 2019 IEEEInternational Conference on Software Testing, Verification and Valida-tion Workshops (ICSTW). IEEE, 2019, pp. 184–187.

[46] P. Zhang, M. A. Walker, J. White, D. C. Schmidt, and G. Lenz,“Metrics for assessing blockchain-based healthcare decentralizedapps,” in 2017 IEEE 19th International Conference on e-Health Net-working, Applications and Services (Healthcom). IEEE, 2017, pp. 1–4.

[47] W. Zou, D. Lo, P. S. Kochhar, X.-B. D. Le, X. Xia, Y. Feng, Z. Chen,and B. Xu, “Smart Contract Development: Challenges and Oppor-tunities,” IEEE Transactions on Software Engineering, 2019.

12