Optimizing smart contracts on ethereum

HANOI UNIVERSITY OF SCIENCE AND TECHNOLOGY

MASTER THESIS IN DATA
SCIENCE AND ARTIFICIAL
INTELLIGENCE
Optimizing smart contracts on
Ethereum
NGUYEN QUANG THANG


Supervisor: Dr. Do Ba Lam —————————————Institution:

School of Information and Communication Technology

HANOI, 04/2022



Declaration of Authorship and Topic
Sentences
Personal Information
• Full name: Nguyen Quang Thang

• Email:

• Class: Data Science
• Tel: 098 669 1647

• Program: Full-time program

• This thesis is performed at: School of Information and Communication

Tech-nology
• This thesis is performed: from 10/04/2021 to 10/04/2022

Goals of the Thesis
• Proposing optimizing rules on smart contract source codes using Solidity
lan-guage.
• Developing a tool named GasSaver, an automatic tool for detecting the
wasting-gas Solidity source codes and suggesting solutions.
• Conducting experiments and evaluating GasSaver.

Main Tasks of the Thesis
• Study on the blockchain, smart contract, and optimizing smart contract
gas fee on Ethereum
• Collect and analyze the typical wasting gas issues on Solidity smart contract
3


• Present seven rules for reducing the gas fee on the smart contract.
• Develop a tool name GasSaver, which implements the seven rules above
to automatically detect the wasting-gas Solidity source codes and suggest
solu-tions for these issues.
• Implement experiments and evaluation GasSaver efficiency.
• Conclude and outline future developments

Declaration of Authorship
I - Nguyen Quang Thang - hereby warrant that the work and presentation in this
thesis are performed by myself under the supervision of Dr. Do Ba Lam.
All results presented in this thesis are truthful and are not copied from any other
works.

Attestation of the Supervisor on the Fulfillment of the
Requirements for the Thesis:
................................................................................
.................................................................................
.................................................................................
.................................................................................

Hanoi, 10th Apr 2022
Author

Supervisor

Dr. Do Ba Lam

Nguyen Quang Thang

4


Acknowledgements
I want to acknowledge and give my warmest thanks to my supervisor, Dr. Do Ba
Lam. He is an excellent blockchain researcher, gave me the golden opportunity
to do this research on optimizing gas fees on the smart contract, which also
helped me do a lot of research, and I came to know about so many new things.
Not only that, he is very kind and friendly and inspired me a lot in my research
career path.
I would also like to give a special thanks to my girlfriend Nguyen Thi Tham and
my family for their mental support during my thesis writing process. Moreover, in
the absence of my friends, Tong Van Vinh, Hong Ngoc, Xuan Thu, and Thanh
Dat, I could hardly melt away all the tension from my work. I also thank Thanks

for always accompanying me through ups and downs.

5


Abstract
Currently, the number of smart contracts using Solidity language in Ethereum is
increasing at a breakneck speed. In this context, optimizing gas fees in smart
contracts becomes necessary to save costs for both developers and users who interact directly with these contracts. To optimize gas, developers typically need to
have deep knowledge of blockchain and programming languages, making it a significant challenge for new programmers. This thesis, we introduce GasSaver – an
open-source tool that analyzes Solidity-based contracts and suggests modifications
to reduce transaction fees. Our tool, which relies on seven rules for identifying nonoptimized codes, shows that 6,333 in a total of 10,245 top most interactive
contracts on Ethereum contain at least one optimization problem and the problems
are more than 30,000. Hence, the use of this tool can reduce a considerable cost
for the deployment and interaction of smart contracts.

Author

Nguyen Quang Thang

6


Table of Contents
Declaration of Authorship and Topic Sentences
Acknowledgement

3
5

Abstract

6

Lists of Figures

9

Lists of Tables

10

Lists of Listing

11

1 Background and related work

15

1.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Ethereum and smart contracts . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Ethereum
blockchain . . . . . . . . . . . . . . . . . . . . . . .
1.2.2
Smart contracts on Ethereum . . . . . . . . . . . . . . . . . . .
1.2.3
Ethereum Virtual Machine (EVM) . . . . . . . . . . . . . . . .
1.2.4
Gas and payment . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.5 Solidity - a high-level language for developing smart contracts
1.3 Related
work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Bytecode
related work . . . . . . . . . . . . . . . . . . . . . .
1.3.2 High-level
language related work . . . . . . . . . . . . . . . .
1.3.3
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Gas-inefficient Programming Patterns

15
17
17
18
19
20
21
23
23
26
26
27

2.1 Data
Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Pattern
1: Members Arrangement in Struct (MAS) . . . . . .
2.1.2 Pattern 2: Data Location
and Function Visibility (DLFV) . .

2.1.3 Pattern 3: Constant State
Variables (CSV) . . . . . . . . . . .
2.1.4
Pattern 4: Immutable State Variables (ISV) . . . . . . . . . . .
2.2 Logic
Relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1
Pattern 5: Operator Reduction in Expression (ORE) . . . . . .
2.2.2 Pattern
6: Repeated Computation in Loop (RCL) . . . . . . .
2.2.3 Pattern
7: Loop Combination (LC) . . . . . . . . . . . . . . .
2.3 Sumnary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Implementation

27
27
29
31
32
34
34
35
37
38
39

3.1 System
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 Rule Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40
3.2.1 Members
Arrangements in Struct . . . . . . . . . . . . . . . . 40
7


3.2.2 Data Location and Function Visibility . . . . . . . . . . . . . .
3.2.3 Constant
State Variables . . . . . . . . . . . . . . . . . . . . .
3.2.4 Immutable State Variables . . . . . . . . . . . . . . . . . . . .
3.2.5 Operator Reduction in
Expression . . . . . . . . . . . . . . . .
3.2.6 Repeated Computation
in Loop . . . . . . . . . . . . . . . . .
3.2.7 Loop Combination . . . . . . . . . . . . . . . . . . . . . . . . .
4 Experiments and Evaluations

42
43
43
44
44
46
48

4.0.1
4.0.2
4.0.3
4.0.4
References

48
49
49
51
56

Optimization Findings . . . . . . . . . . . . . . . . . . . . . . .
Execution
Time . . . . . . . . . . . . . . . . . . . . . . . . . .
Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8


List of Figures
1

Opensea - the most prominent digital marketplace for crypto collectibles and non-fungible tokens [1] . . . . . . . . . . . . . . . . . .
1.1 Blockchain model networks . . . . . . . . . . . . . . . . . . . . . . . .

13
15

1.2 Ethereum state machine mechanism . . . . . . . . . . . . . . . . . . .
3.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17
39

3.2 The example output of GasSaver with Members Arrangements in
Struct issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 The example output of GasSaver with Data Location and Function
Visibility issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 The example output of GasSaver with Constant State Variables issue
3.5 The example output of GasSaver with Immutable State Variables issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6 The example output of GasSaver with Operator Reduction in Expression issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7 The example output of GasSaver with Repeated Computation in Loop
issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8 The example output of GasSaver with Loop Combination issue . .
4.1 Distribution of Violations on the First Dataset . . . . . . . . . . . . .
4.2
4.3
4.4
4.5
4.6

Distribution of Violations on the Second Dataset . . . . . . . . . . . .
Time Executions on the First Dataset . . . . . . . . . . . . . . . . . .
Time Executions on the Second Dataset . . . . . . . . . . . . . . . . .
Violations on the First Dataset of GasSaver and Tamara’s tool . . . .
Time comparison of GasSaver and Tamara’s tool . . . . . . . . . . .

9

42
43
44
45

46
46
47
49
50
50
51
52
52


List of Tables
1.1 EVM operation gas
1.2 EVM operation gas
2.1 Costs of deployment
2.2
2.3
2.4
2.5
2.6
2.7
2.8
4.1

cost overview . . . . . . . . . . . . . . . . . . . 22
refund overview . . . . . . . . . . . . . . . . . . 23
and function call in Listing 2.1 . . . . . . . . 29

Costs of deployment and function Call in Listing 2.2 . . . . . . . . .
Costs of deployment and function call in Listing 2.3 . . . . . . . . .

The difference
in assembly code in Listing 2.3 . . . . . . . . . . . .
Costs of deployment and function call in Listing 2.4 . . . . . . . . .
Costs of deployment and function call in Listing 2.5 . . . . . . . . .
Costs of deployment
and function call in Listing 2.6 . . . . . . . .
Costs of deployment and function call in Listing 2.7 . . . . . . . . .
Costs of deployment
and function call in SAC Contract . . . . . . .

10

31
32
32
34
35
36
38
54


List of Listings
2.1
2.2
2.3
2.4
2.5
2.6
2.7

3.1
4.1
4.2

An example of Members Arrangement in A Struct issue . . . . . . .
An example of Data Location and Function Visibility issue . . . . .
An example of Constant State Variable issue . . . . . . . . . . . . . .
An example of Immutable State Variable issue . . . . . . . . . . . . .
An example of Operator Reduction in Expression issue . . . . . . . .
An example of Repeated Computation in Loop issue . . . . . . . . .
An example of Loop Fusion issue . . . . . . . . . . . . . . . . . . . .
Check Members Arrangements in Struct approach . . . . . . . . . . .
A Sample Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Optimized Contract . . . . . . . . . . . . . . . . . . . . . . . . . .

11

28
30
31
33
34
36
37
41
53
53


Introduction

In recent years, blockchain has been raised as one of the promising technolo-gies
that can make considerable changes to the operations of companies, organizations, and governments over the world [2]. An important factor contributing to
the success of blockchain is smart contracts that represent complex agreements
through codes and provide automated execution flow without the intervention of
any third party. The Uniswap protocol is a suite of persistent, non-upgradable smart
contracts that together create an automated market maker. This protocol fa-cilitates
a peer-to-peer market for making and swapping ERC-20 tokens on the Ethereum
blockchain. Users can easily exchange tokens with each other quickly, anytime,
anywhere. Uniswap is the most prominent place for exchanging assets in the
Ethereum network, with over 831 billion USD trading volume and over 88 million
exchanging transactions. OpenSea is another example of using the smart contract
in blockchain networks. OpenSea is the world’s first and largest digital marketplace
for crypto-collectibles and non-fungible tokens (NFTs), with over 2.4 million sold
items, and the volume is around 4.9 billion USD in January 2022. With the ability to
represent complex agreements through codes and provide auto-mated execution
flow without the intervention of any third party, smart contracts are used in a wide
range of fields, including finance, arts, games, etc.
Any developer can easily create a smart contract and publish it to a target network
after paying a fee for them. Next, users can call the smart contract to execute its
functions once they have a balance covering the transaction fee for the network. As
of January 2022, 458,939 smart contracts have been created on Ethereum with a
total fee of 293,770.336 USD [3]. Opensea – Wyvernexchange, one of the top
contracts by usage, reached 72,480 transactions on February 12th, 2022, with a
total gas of 13.43 billion, which equals $1.5 million [4] at that time. These num-bers
show that the costs of deploying and calling smart contracts are huge if these
contracts are not optimized in advance. On the other hand, these expenditures will
continue to increase according to the rapid introduction of new contracts and the
proliferation of existing contracts. Therefore optimizing gas used in smart contracts
on Ethereum is essential.
Gas optimization can be performed through two main steps, i.e., (i) detect inefficient codes and (ii) fix these codes. The first step mentions parsing the source

code of smart contracts based on the knowledge of analyzers to identify the position of inefficient codes. Next, we change these inefficient codes without changing
12


Figure 1: Opensea - the most prominent digital marketplace for crypto
collectibles and non-fungible tokens [1]
the logic of the programs to fix these issues. To obtain this goal, developers can
select two main approaches. Firstly, they need in-depth study languages to develop smart contracts on Ethereum, such as Solidity, Vyper, etc..., and optimize
the smart contracts by themselves. Secondly, they can rely on third parties for
optimizing smart contracts and using suggested results. However, there are two
main issues with existing approaches. Firstly, it takes a long time for developers
to study and have deep knowledge about smart contracts language on
Ethereum, especially with newbies. The reason is that optimizing gas
consumption in smart contracts is entirely different from optimizing source code
in traditional program-ming languages such as Python, Java, C, etc... In
addition, developers can not proactively optimize smart contracts if they do not
have enough experience. Even with experienced developers, it still takes time
to optimize smart contracts, espe-cially big-sized smart contracts. Secondly, if
they choose third parties to optimize gas used in smart contracts, they must pay
a considerable fee for these parties; in some cases, this fee can be greater than
the wasted money from the smart con-tracts. Furthermore, the vulnerability of
leaking the source code of smart contracts before release may occur.
To address the challenges above, we first comprehensively research Solidity – the
most popular language used in developing smart contracts and then present the
rules describing the wasted codes and how to fix them without changing the logic of
smart contracts. Next, we develop an automatic gas optimizer for detecting and
suggesting solutions for Solidity-based smart contracts before developers publish
13

them on Ethereum. Generally, we make contributions as follows:
• Although many people research gas-saving on smart contracts, their
works typically are on bytecode contracts. Therefore, it is challenging for
devel-opers to fix contracts when problems are found because developers
typically use high-level language to develop smart contracts. So, based on
the exist-ing related research, we extended three rules and introduced
four novel rules to detect gas-wasting codes on smart contract source
codes (Solidity source codes). Then we state the solution to optimize
these inefficient codes without changing the logic.
• We developed a tool named GasSaver, an automatic tool for detecting the
wasting-gas source codes and suggesting solutions on Solidity-based
smart contracts. The source code and experiment datasets are published
on Github at GasSaver.
• We apply GasSaver to 10,245 verified contracts in the top 15,000 smart
con-tracts ranked by the number of caller addresses on Ethereum and find
out over 30,000 issues, in which 6,333 smart contracts contain wasted
codes. The results have demonstrated the efficiency of GasSaver.
The remainder of this thesis is organized as follows. In Chapter 1, we discuss the
backgound and related work. Chapter 2 presents inefficient programming patterns
and solutions for each problem. Next, Chapter 3 illustrates the design of GasSaver
through detailed implementation. Chapter 4 discusses evaluation of GasSaver.

14


Chapter 1
Background and related work
This chapter will introduce the related knowledge and technologies to clarify my
thesis. I will present the overview of blockchain in Section 1.1, then especially
on Ethereum blockchain, smart contract knowledge on Ethereum and Soliditythe most popular programming language used to develop smart contracts on

Ethereum at Section 1.2

1.1 Blockchain
A blockchain is a public database that is updated and shared across many
comput-ers in a network. “Block” refers to data and states stored in consecutive
groups known as “blocks”. “Chain” refers to the fact that each block
cryptographically references its parent. In other words, blocks get chained
together. The data in a block cannot change without changing all subsequent
blocks, which would require the consensus of the entire network.
Figure 1.1 briefly describes blockchain. When a new block is created, it is linked
to the previous block via the previous ’s block hash. When the data in Block 1 is
changed, it causes the hash of Block 1 is changed, and the consequence is Block
2 cannot link to Block 1. So, to change the data in the blockchain at a block,
they must change all data after the changed block. Because of the difficulty when
a new block is created, changing data in the blockchain is impossible in the real
world.
Block 1

Block 2

Block 3

Block 4

Previous: 000

Previous: 1AB

Previous: 4A9

Previous: 872

Hash: 1AB

Hash: 4C9

Hash: 872

Hash: 29D

Figure 1.1: Blockchain model networks
15


Blockchain consists of four main definitions: “block”, “node”, “concensus mechanism”, and “minners”.
Block: Every blockchain includes linked blocks together. Each block includes
transactions and other properties such as before block hash, timestamp, nonce,
etc. The block’s hash represents the block and is used to link with a new block
to ensure the immutable data and the scalability of blockchain networks. New
blocks are broadcast to the nodes in the network, checked, and verified, thus
updating the state of the blockchain for everyone.
Node: Decentralization is one of the most significant advantages of blockchain. No
one or organization can own the blockchain. Every computer must agree upon
each new block and the chain in the blockchain network. These computers are
known as “nodes”. Nodes ensure everyone interacting with the blockchain has the
same data. Nodes can be any device, as long as they can maintain the copy of
the blockchain and keep the network active. With many nodes in the blockchain,
the network will not have the problem if it contains some broken nodes,
increasing the availability of blockchain networks.
Consensus mechanism: To accomplish the distributed agreement, blockchains need

a consensus mechanism. A consensus mechanism is a fault-tolerant mechanism
used in computer and blockchain systems to achieve the necessary agreement on
a single data value or a single state of the network among distributed processes
or multi-agent systems. So, people can not arbitrarily add data to the
blockchain, make the data in all nodes consistent, and difficultly fake data. For
example, Ethereum currently uses a proof-of-work consensus mechanism. This
means that anyone who wants to add new blocks to the chain must solve a
complex puzzle that requires a lot of computing power. Solving the puzzle
”proves” that you have done the ”work” using computational resources. Doing
this is known as mining. Mining is typically brute force trial and error, but
successfully adding a block is rewarded in ETH.
Minner: Minners do work depending on the consensus mechanism to have the
chance of creating a new block in the current chain. In each blockchain network,
many miners take part in creating a new block, ensure no person or organization
can manipulate the network, and increase the trust in the blockchain. After processing the works depending on the consensus mechanism and pass, miners can
add a block to the chain. If the malicious want to change blockchain data, they must
be permitted to add a block in the chain from the modified block to now. This
condition is impossible because the consensus mechanism prevents everybody
from manipulating the network. So, changing data in the blockchain is challeng-ing.
After the mining is successful, all nodes in the network will approve the change,
and miners will reward for this mining.
The combination of public information and consensus mechanism makes the integrity and trust of the user. Therefore, blockchain seems that the technology
cre-ates absolute trust between users without the parties.
16


1.2 Ethereum and smart contracts
1.2.1 Ethereum blockchain
The Ethereum blockchain is essentially a transaction-based state machine. In

com-puter science, a state machine refers to something that will read a series of
inputs and, based on those inputs, will transition to a new state.
With Ethereum’s state machine, the genesis state is analogous to a blank slate
before any transactions have happened on the network. When transactions are
ex-ecuted, this genesis state transitions into some final state. At any point in
time, this final state represents the current state of Ethereum.

Figure 1.2: Ethereum state machine mechanism
The state of Ethereum has millions of transactions. These transactions are
grouped into“blocks”. A block contains a series of transactions, and each block
is chained together with its previous block. A transaction must be valid to cause
a transition from one state to the next. For a transaction to be considered valid,
it must go through a validation process known as mining. Mining is when a
group of nodes expends their computation resources to create a block of valid
transactions. Any node on the network that declares itself as a miner can
attempt to create and validate a block. Many miners from around the world try to
create and validate blocks simultaneously. Each miner provides a mathematical
“proof” when submit-ting a block to the blockchain, and this proof acts as a
guarantee: if the proof exists, the block must be valid. For a block to be added
to the main blockchain, the miner must prove it faster than any competitor
miner. The process of validat-ing each block by having a miner provide a
mathematical proof is known as a “proof of work”. A miner who validates a new
block is rewarded with a certain amount of value for doing this work. The
Ethereum blockchain uses an intrinsic digital token called “Ether”. Every time a
miner proves a block, new Ether tokens are generated and awarded.
The Ethereum blockchain tracks the state of every account, and all state transitions on the Ethereum blockchain are transfers of value and information
between accounts. There are two types of accounts:
• Externally Owned Accounts (EOAs), which are controlled by private keys
• Contract Accounts, which are controlled by their contract code and can
only be “activated” by an EOA

17


For most users, the primary difference between these is that human users control EOAs because they can control the private keys which control an EOA. On
the other hand, contract accounts are governed by their internal code. A human
user can control them because they are programmed to be controlled by an
EOA with a specific address, owned by whoever holds the private keys that
control that EOA. The popular term “smart contracts” refers to code in a
Contract Account – programs that execute when a transaction is sent to that
account. Users can create new contracts by deploying code to the blockchain.
Contract accounts only operate when instructed by an EOA. So a Contract account
can’t be performing native operations like random number generation or API calls
– it can do these things only if prompted by an EOA. This is because Ethereum
requires nodes to agree on the outcome of computation, which requires a
guarantee of strictly deterministic execution.
Users must pay small transaction fees to the network. This protects the
Ethereum blockchain from frivolous or malicious computational tasks, like DDoS
attacks or infinite loops. The sender of a transaction must pay for each step of
the “pro-gram” they activated, including computation and memory storage.
These fees are paid in amounts of Ethereum’s native value token, “ether”.

1.2.2 Smart contracts on Ethereum
A “smart contract” is simply a program that runs on the Ethereum blockchain.
It’s a collection of code (its functions) and data (its state) that resides at a specific address on the Ethereum blockchain. Smart contracts are a type of
Ethereum account. This means they have a balance and can send transactions
over the net-work. However, they’re not controlled by a user. Instead, they are
deployed to the network and run as programmed. User accounts can then
interact with a smart contract by submitting transactions that execute a function
defined on the smart contract. Smart contracts can define rules, like a regular
contract, and automati-cally enforce them via the code. Smart contracts cannot

be deleted by default, and their interactions are irreversible.
Smart contract on Ethereum contains advantages below:
• Zero downtime: Once the smart contract is deployed and on the blockchain,
the network as a whole will always be able to serve clients looking to in-teract
with the contract. Malicious actors, therefore, cannot launch denial-of-service
attacks targeted toward individual smart contracts.

• Resistance to censorship: No single entity on the network can block users
from submitting transactions, deploying smart contracts, or reading data
from the blockchain.
• Complete data integrity: Data stored on the blockchain is immutable and
indisputable, thanks to cryptographic primitives. As a result, malicious actors
18


cannot forge transactions or other data already made public.
• Trustless computation/verifiable behavior: Smart contracts can be analyzed
and are guaranteed to execute in predictable ways, without the need to trust
a central authority. This is not true in traditional models; for example, we
must trust that financial institutions will not misuse our financial data,
tamper with records, or get hacked when using online banking systems.
Anyone can write a smart contract and deploy it to the network. You just need to
learn how to code in a smart contract language and have enough ETH to de-ploy
your contract. Deploying a smart contract is technically a transaction, so you need
to pay your gas in the same way you need to pay gas for a simple ETH transfer. On
the Ethereum blockchain, contracts are typically written in high-level languages
such as Solidity and then compiled into bytecode to be uploaded on the blockchain.
Contracts live on the blockchain in an Ethereum-specific binary format called
Ethereum Virtual Machine (EVM) bytecode. Any user can then call the smart
contract to execute its code, again for a fee paid to the network. Thus, developers

can arbitrarily build and deploy complex user-facing apps and services such as
marketplaces, financial instruments, games, etc.

1.2.3 Ethereum Virtual Machine (EVM)
The analogy of a ’distributed ledger’ is often used to describe blockchains like
Bitcoin, which enable a decentralized currency using fundamental cryptography
tools. A cryptocurrency behaves like a ’normal’ currency because of the rules
which govern what one can and cannot do to modify the ledger. For example, a
Bitcoin address cannot spend more Bitcoin than it has previously received. These
rules underpin all transactions on Bitcoin and many other blockchains.
While Ethereum has its native cryptocurrency (Ether) that follows almost exactly
the same intuitive rules, it also enables a much more powerful function: smart
contracts. For this more complex feature, a more sophisticated analogy is
required. Instead of a distributed ledger, Ethereum is a distributed state
machine. Ethereum’s state is a large data structure that holds all accounts and
balances and a machine state, which can change from block to block according
to a pre-defined set of rules and execute arbitrary machine code. The EVM
defines the specific rules of changing state from block to block.
In computer science, computer engineering, and programming language implementations, a stack machine is a computer processor or a virtual machine in which the
primary interaction is moving short-lived temporary values to and from a push-down
stack. In the case of a hardware processor, a hardware stack is used. The use of a
stack significantly reduces the required number of processor registers. Stack
machines extend push-down automaton with additional load/store operations or
multiple stacks and hence are Turing-complete.
19


The EVM is a Turing complete virtual machine, as defined earlier. The only limitation the EVM has that a typical Turing complete machine does not is that the
EVM is intrinsically bound by gas. Thus, the total amount of computation that
can be done is intrinsically limited by the amount of gas provided. The EVM

executes as a stack machine with a depth of 1024 items. Each item is a 256-bit
word, chosen for ease of use with 256-bit cryptography (such as Keccak-256
hashes or secp256k1 signatures). The EVM maintains a transient memory (as a
word-addressed byte array) during execution, which does not persist between
trans-actions. Contracts, however, do contain a Merkle Patricia storage trie (as
a word-addressable word array) associated with the account in question and
part of the global state. Compiled smart contract bytecode executes several
EVM opcodes, which perform standard stack operations like XOR, AND, ADD,
SUB, etc. In ad-dition, the EVM also implements some blockchain-specific stack
operations, such as ADDRESS, BALANCE, BLOCKHASH, etc.

1.2.4 Gas and payment
Gas refers to the unit that measures the computational effort required to execute
specific operations on the Ethereum network. Since each Ethereum transaction requires computational resources to execute, each transaction requires a fee. Gas
refers to the fee required to conduct a transaction on Ethereum successfully. Gas is
the unit used to measure the fees required for a particular computation. Gas
price is the amount of Ether you are willing to spend on every unit of gas and is
18

measured in “gwei”. “Wei” is the smallest unit of Ether, where 10 Wei rep-resents
1 Ether. One gwei is 1,000,000,000 Wei. With every transaction, a sender sets a
gas limit and gas price. The gas price and gas limit represent the maximum amount of Wei that the sender is willing to pay for executing a transaction. For example, the sender sets the gas limit to
50,000 and a gas price to

20 gwei. This implies that the sender is willing to spend at most 50,000 x 20
gwei = 1,000,000,000,000,000 Wei = 0.001 Ether to execute that transaction. The
gas limit represents the maximum gas the sender is willing to spend money on.
They’re good to go if they have enough Ether in their account balance to cover this
maximum. The sender is refunded for any unused gas at the end of the transaction, exchanged at the original rate. If the sender does not provide the necessary
gas to execute the transaction, the transaction runs “out of gas” and is considered

invalid. In this case, the transaction processing aborts, and any state changes that
occurred are reversed, such that we end up back at the state of Ethereum before
the transaction. Additionally, a record of the failed transaction shows what was
attempted and where it failed. Since the machine expended effort to run the calculations before running out of gas, logically, none of the gas is refunded to the
sender. Typically, the higher the gas price the sender is willing to pay, the greater
the value the miner derives from the transaction. Thus, the more likely miners
20