See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/344406010

An Evaluation of Gas Consumption Prediction on Ethereum based on

Transaction History Summarization

Conference Paper · September 2020

DOI: 10.1109/BRAINS49436.2020.9223288

CITATIONS READS
0 89

1 author:

Sarah Bouraga
University of Namur
13 PUBLICATIONS   36 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Sarah Bouraga on 28 September 2020.

The user has requested enhancement of the downloaded file.

An Evaluation of Gas Consumption Prediction on
Ethereum based on Transaction History
Summarization
Sarah Bouraga
Business Administration Department
University of Namur
Namur, Belgium
sarah.bouraga@unamur.be

Abstract
The author uses data about transactions on Ethereum as sources for
studying the relationship between the historic of transactions for a given
address and the amount of gas consumed for a transaction. The author
combines data about transactions, and blocks to predict the gas usage
for a transaction. Specifically, how much gas will be consumed for the
next transaction, given the initiator’s transaction history. The results
demonstrate the value of considering the transaction history for gas usage
predictions.
Keywords: Blockchain, Ethereum, Gas Consumption, Prediction, Re-
gression

1 Introduction
Since Ethereum was launched in 2015, it has become the world’s leading pro-
grammable blockchain, allowing anyone to write Smart Contracts and Decen-
tralized Applications (DApps), on top of the possibility to transfer ether (ETH),
Ethereum’s own cryptocurrency. On Ethereum, the execution of a transaction
requires some computational resources (called Gas) which the initiator of the
transaction has to pay for. She sets (i) the amount she is willing to pay per
unit of gas (i.e., the GasPrice), and (ii) the maximum units of gas she is willing
to pay for (i.e., the GasLimit); and she pays in advance the amount GasPrice
× GasLimit. If the transaction does not exceed the amount of gas set by the
initiator, then the latter will get back the (GasPrice × GasLimit) − Gas Cost;
while the Gas Cost is paid to the miner. Otherwise, the amount is lost.
The goals and corresponding contributions of this paper are twofold. Firstly,
transaction history summarization is used to predict the amount of gas used by

1
transaction for a given address. Secondly, drawing on previous works [1, 2]
the author aims to discover whether features in the history of transactions on
Ethereum can be as good predictors as the ones on the Bitcoin blockchain.
Being able to predict gas consumption has two main practical implications.
It can help the initiator of a transaction set the GasLimit, and hence set the
GasPrice. Also, a gas consumption prediction can help the network identify
fraudulent activity.
The rest of the paper is structured as follows. Section 2 proposes a literature
review. Section 3 presents the research methodology. Finally, Section 4 and
Section 5 discusses the results and concludes the paper respectively.

2 Background
Building on Bitcoin, Ethereum [3] offers a platform with a built-in Turing-
complete programming language which anyone can use to write Smart Contracts
and DApps. A risk when dealing with Turing-complete programming languages
is the problem of the infinite loop in code. Ethereum mitigates that risk with
the concept of Gas. Each transaction must contain, among other elements:
the Startgas (or GasLimit) and the GasPrice. The Startgas is the maximum
number of computational steps of code execution the sender is willing to pay
for; while the GasPrice is the price per computational step. Both are set by
the sender. If the transaction execution consumes more gas than was originally
paid for, then the execution stops. Thus, one will not encounter the infinite
loop problem because the transaction will run out of gas eventually.
The present article draws mainly on [1] and [2], where the summarization of
transaction history is used for the classification of Bitcoin addresses.
On the Ethereum blockchain, researchers conducted studies about smart
contracts and about the gas used on the blockchain. Here, the author does not
analyse the code of smart contracts to identify flaws or other vulnerability issues
as in [4–7]; but rather, analyses the effects of the execution of smart contracts.
Also, the purpose here is not the analysis nor the handling of Denial-of-Service,
as it is the case in [8,9]. Finally, this work proposes an analysis of the transaction
history summarization to predict gas consumption - something that, as far as
the author knows, has not been carried out - instead of using the structure of
the smart contract code as it is the case in [10].

3 Methodology
3.1 Data Collection and Feature Engineering
The author used Python scripts Ethereum-ETL to retrieve 101002 blocks and
their corresponding transactions, features, and contracts. She also retrieved the
conversion rate from ETH to USD from etherchain.org. Building on [1] and [2],
the author constructed two categories of features, Basic and Extra Statistics
(Table 1).

2
 Table 1: Basic and Extra Statistics
Features Description
fT X Frequency, i.e. the number of all transac-
tions per day
rrec Ratio of received transactions to all trans-
actions
rrec ET H Ratio of received transfer transactions to
all transactions
rsent ET H Ratio of sent transfer transactions to all
transactions
rcontract Ratio of contract creation transactions to
all transactions
µgas pc Mean value of the GasPrice all transac-
tions
σgas pc Standard deviation value of the GasPrice
µstartgas Mean value of the StartGas all transactions
σstartgas Standard deviation value of the StartGas
all transactions
µgas used Mean value of the gas used in all transac-
tions
σgas used Standard deviation value of the gas used
in all transactions
lif etime Duration between the first and the last
transaction
gasspent Total gas spent
ET Hspent Total spent in Ether
ET Hreceived Total received in Ether
U SDspent Total spent in USD
U SDreceived Total received in USD
NT X Number of transactions
Nsent Total number of sent transactions
Nreceived Total number of received transactions
Ncall Total number of call function transactions
Ncontract Total number of smart contract creation
transactions

3
3.2 Prediction Models
The author used Skikit-Learn Python library [11] for the application of various
prediction models. After splitting the dataset into a train set and a test set,
the author first trained several models (Ordinary Least Squares (OLS), Ridge,
Bayesian Ridge, Lasso, and Stochastic Gradient Descent Linear Regressions,
Linear Support Vector Regression, and Decision Tree Regressor) with the de-
fault hyperparameters, using a 5-fold cross-validation on the train set. Using
R-Squared (R2 ) as the performance measure, which indicates how well the se-
lected independent variables explain the variability in the dependent variable,
the author selected and fine-tuned the best models (OLS and Lasso) using a
GridSearch [11]. At the end, with a R2 = 0,729373, the Lasso model performs
best and gives the following equation:

gasused = 14382 − 944 ∗ rrec − 1, 55e−11 ∗ rrec ET H

− 776 ∗ rsent ET H + 81 ∗ rcontract (1)
+ 9310952 ∗ µgasU sed − 48 ∗ NT X

4 Evaluation and Discussion

Equation 1 shows that in order to predict gas consumption, one has to analyze,
in priority, the average gas consumed by the sender (µgas used ). On the other
hand, the more an account engages in transactions transferring ether (rrec ET H
and rsent ET H ), the less that account is predicted to consume gas in a trans-
action; and the more an account actively uses Ethereum (NT X ), the less it is
predicted to consume gas. This could be explained by the learning experience
of an account.
In this article, the author showed that transaction history summarization
constitutes a good enough predictor for gas consumption. Also, she highlighted
that out of the 22 features, only 6 seem to be useful to explain the gas consumed
by a transaction (for the Lasso Regression), contrary to [1] and [2].
Being able to predict gas consumption has practical implications. It can help
the initiator set an appropriate GasLimit, preventing transactions from running
out of gas. Also, it can help the network identify abnormal activity. For a given
transaction, if the gas consumed differs greatly from the expected amount, the
transaction could be suspect.
This work suffers from two main limitations. The author did not extract a
great amount of blocks - in the overall scheme of things. Also, she might not
have tested enough hyperparameters, features or even enough models.

5 Conclusion
On Ethereum, peers can transfer ETH, write Smart Contracts and DApps. An
important concept is the concept of Gas, the number of computational steps
necessary to execute the transaction. In this paper, the author demonstrates

4
the predictive power of transaction summarization to forecast the gas consumed
for each transaction. Future work will consist of addressing the limitations
mentioned in Section 4.

References
[1] K. Toyoda, T. Ohtsuki, and P. T. Mathiopoulos, “Multi-class bitcoin-
enabled service identification based on transaction history summarization,”
in 2018 IEEE International Conference on Internet of Things (iThings)
and IEEE Green Computing and Communications (GreenCom) and IEEE
Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data
(SmartData). IEEE, 2018, pp. 1153–1160.
[2] Y.-J. Lin, P.-W. Wu, C.-H. Hsu, I.-P. Tu, and S.-w. Liao, “An evaluation of
bitcoin address classification based on transaction history summarization,”
in 2019 IEEE International Conference on Blockchain and Cryptocurrency
(ICBC). IEEE, 2019, pp. 302–310.

[3] V. Buterin et al., “A next-generation smart contract and decentralized

application platform,” white paper, vol. 3, p. 37, 2014.
[4] S. Tikhomirov, E. Voskresenskaya, I. Ivanitskiy, R. Takhaviev,
E. Marchenko, and Y. Alexandrov, “Smartcheck: Static analysis of
ethereum smart contracts,” in Proceedings of the 1st International Work-
shop on Emerging Trends in Software Engineering for Blockchain, 2018,
pp. 9–16.
[5] L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making smart
contracts smarter,” in Proceedings of the 2016 ACM SIGSAC conference
on computer and communications security, 2016, pp. 254–269.
[6] N. Grech, M. Kong, A. Jurisevic, L. Brent, B. Scholz, and Y. Smaragdakis,
“Madmax: Surviving out-of-gas conditions in ethereum smart contracts,”
Proceedings of the ACM on Programming Languages, vol. 2, no. OOPSLA,
p. 116, 2018.

[7] T. Hukkinen, J. Mattila, K. Smolander, T. Seppala, and T. Goodden,

“Skimping on gas–reducing ethereum transaction costs in a blockchain elec-
tricity market application,” in Proceedings of the 52nd Hawaii International
Conference on System Sciences, 2019.
[8] F. Zhang, E. Cecchetti, K. Croman, A. Juels, and E. Shi, “Town crier: An
authenticated data feed for smart contracts,” in Proceedings of the 2016
aCM sIGSAC conference on computer and communications security, 2016,
pp. 270–282.

5
 [9] T. Chen, X. Li, Y. Wang, J. Chen, Z. Li, X. Luo, M. H. Au, and X. Zhang,
“An adaptive gas cost mechanism for ethereum to defend against under-
priced dos attacks,” in International Conference on Information Security
Practice and Experience. Springer, 2017, pp. 3–24.
[10] M. Marescotti, M. Blicha, A. E. Hyvärinen, S. Asadi, and N. Sharygina,
“Computing exact worst-case gas consumption for smart contracts,” in
International Symposium on Leveraging Applications of Formal Methods.
Springer, 2018, pp. 450–465.
[11] F. Pedregosa, G. Varoquaux, A. Gramfort, V. Michel, B. Thirion, O. Grisel,
M. Blondel, P. Prettenhofer, R. Weiss, V. Dubourg, J. Vanderplas, A. Pas-
sos, D. Cournapeau, M. Brucher, M. Perrot, and E. Duchesnay, “Scikit-
learn: Machine learning in Python,” Journal of Machine Learning Re-
search, vol. 12, pp. 2825–2830, 2011.

View publication stats