Computer Science Review 50 (2023) 100575

Contents lists available at ScienceDirect

Computer Science Review

journal homepage: www.elsevier.com/locate/cosrev

Review article

Understanding blockchain: Definitions, architecture, design, and

system comparison
∗
Mohammad Hossein Tabatabaei , Roman Vitenberg, Narasimha Raghavan Veeraragavan
Department of Informatics, University of Oslo, Oslo, Norway

article info a b s t r a c t

Article history: The explosive advent of the blockchain technology has led to hundreds of blockchain systems in the
Received 12 December 2022 industry, thousands of academic papers published over the last few years, and an even larger number
Received in revised form 13 July 2023 of new initiatives and projects. Despite the emerging consolidation efforts, the area remains highly
Accepted 24 July 2023
turbulent without systematization, educational materials, or cross-system comparative analysis.
Available online 16 August 2023
In this paper, we provide a systematic and comprehensive study of four popular yet widely different
Keywords: blockchain systems: Bitcoin, Ethereum, Hyperledger Fabric, and IOTA. The study is presented as a
Blockchain system cross-system comparison, which is organized by clearly identified aspects: definitions, roles of the
Distributed ledger technology participants, entities, and the characteristics and design of each of the commonly used layers in the
Bitcoin cross-system blockchain architecture. Our exploration goes deeper compared to what is currently
Ethereum available in academic surveys and tutorials. For example, we provide the first extensive coverage of
Hyperledger Fabric the storage layer in Ethereum and the most comprehensive explanation of the consensus protocol
IOTA
in IOTA. The exposition is due to the consolidation of fragmented information gathered from white
and yellow papers, academic publications, blogs, developer documentation, communication with the
developers, as well as additional analysis gleaned from the source code. We hope that this survey will
help the readers gain in-depth understanding of the design principles behind blockchain systems and
contribute towards systematization of the area.
© 2023 Elsevier Inc. All rights reserved.

Contents

1. Introduction......................................................................................................................................................................................................................... 2
1.1. Contributions .......................................................................................................................................................................................................... 2
1.2. Roadmap ................................................................................................................................................................................................................. 3
2. Understanding blockchain: Definitions and concepts.................................................................................................................................................... 3
2.1. Reflection on various blockchain definitions...................................................................................................................................................... 3
2.2. Blockchain types .................................................................................................................................................................................................... 4
2.3. Participants and their roles .................................................................................................................................................................................. 4
2.4. Architecture ............................................................................................................................................................................................................ 5
3. Understanding blockchain systems: overview and entities .......................................................................................................................................... 5
3.1. Bitcoin ..................................................................................................................................................................................................................... 6
3.2. Ethereum ................................................................................................................................................................................................................ 6
3.3. Hyperledger Fabric ................................................................................................................................................................................................ 6
3.4. IOTA ......................................................................................................................................................................................................................... 7
4. Understanding blockchain systems layer by layer ......................................................................................................................................................... 7
4.1. Hardware layer....................................................................................................................................................................................................... 7
4.2. Data storage layer.................................................................................................................................................................................................. 8
4.2.1. State tracking approach......................................................................................................................................................................... 8
4.2.2. Organization of blockchain storage...................................................................................................................................................... 10
4.2.3. The block structure in Bitcoin, Ethereum, and Fabric ....................................................................................................................... 10
4.2.4. Structure of transactions and their grouping in a block ................................................................................................................... 10

∗ Corresponding author.
E-mail addresses: [email protected] (M.H. Tabatabaei), [email protected] (R. Vitenberg), [email protected] (N.R. Veeraragavan).

https://doi.org/10.1016/j.cosrev.2023.100575
1574-0137/© 2023 Elsevier Inc. All rights reserved.
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

4.2.5. On-disk storage ...................................................................................................................................................................................... 11

4.2.6. On the use of trees in Bitcoin and Ethereum..................................................................................................................................... 12
4.2.7. In-memory storage................................................................................................................................................................................. 13
4.2.8. Data retention......................................................................................................................................................................................... 13
4.3. Communication layer ............................................................................................................................................................................................ 14
4.4. Data manipulation layer ....................................................................................................................................................................................... 16
4.4.1. Updating blockchain in Bitcoin ............................................................................................................................................................ 16
4.4.2. Updating blockchain in Ethereum........................................................................................................................................................ 18
4.4.3. Updating blockchain in Hyperledger Fabric........................................................................................................................................ 19
4.4.4. Updating blockchain in IOTA ................................................................................................................................................................ 20
4.4.5. Defense against DoS attacks ................................................................................................................................................................. 23
4.4.6. Querying blockchain .............................................................................................................................................................................. 24
4.5. Contract layer ......................................................................................................................................................................................................... 24
5. Related work ....................................................................................................................................................................................................................... 25
6. Conclusions.......................................................................................................................................................................................................................... 27
Declaration of competing interest.................................................................................................................................................................................... 27
Data availability .................................................................................................................................................................................................................. 27
Acknowledgments .............................................................................................................................................................................................................. 27
References ........................................................................................................................................................................................................................... 28

However, most of the published surveys are focusing on one

1. Introduction system (such as Bitcoin [19,20]), a particular class of blockchain
(e.g., DAG-based [21]), or an individual aspect of blockchain (such
Since Bitcoin inception and deployment back in 2009, it has as proof-of-X or defense mechanisms against security attacks of
been creating waves of discussions and debates about its success a specific type). In-depth comparisons across systems of different
as the first widely popular cryptocurrency effort. Bitcoin did away type are exceedingly rare, and so are standardization initiatives
with a broker entity and showed that it is fundamentally possible or attempts to establish general taxonomies. Thus, despite the
to have a working cooperative economic model in practice where consolidation efforts, the area remains highly turbulent without
the technology does all the mediation. systematization. Accordingly, there are no textbooks or compre-
In 2014–2016, there occurred an explosive extension in the hensive educational materials, except for Bitcoin itself [22].
range of applications, with everybody talking about the Blockchain Today, the only way to gain in-depth technical understanding
Paradigm underlying the technology that enables cooperative eco- of the design behind almost any blockchain system is to read
nomic models and cooperative storage and management of agree- typically outdated white and yellow papers followed by perusing
ments. According to [1], the annual revenue of blockchain-based the continuously updated technical documentation, followed by
enterprise applications worldwide will reach $19.9 billion by scanning hundreds of blog posts by the developers and conflicting
2025, up from about $2.5 billion in 2016. forum posts by the users and finally, by studying the source
Declared intention of future use of blockchain in coopera- code.
tive healthcare provision is making global news [2]. Coopera-
tive energy markets based on microgrids are viewing blockchain 1.1. Contributions
as a major technological enabler [3]. Blockchain is becoming a
common element in solutions for decentralized digital identity Our main contribution is the first systematic and compre-
(DID) [4], certificate storage [5], land registries [6], and sup- hensive comparative study of blockchain design across different
ply chains [7]. Microsoft declares ‘‘blockchain’’ as one of the systems. While many existing works provide a focused cross-
key ‘‘must win’’ technologies for their Azure platform and busi- system comparison on a particular aspect, we aim to provide a
ness [8]. Similarly, IBM unveils a new ambitious blockchain ser- comparative design insight that goes far beyond the information
vice and strategy [9]. A long row of major enterprises such as that is currently available in the literature. The comparison is per-
Accenture, Cisco, Citibank, Facebook, Disney Studios, Goldman formed across four blockchain systems representative of different
Sachs, and HSBC have publicly declared their investment in the blockchain strands (i.e., Bitcoin, Ethereum, Hyperledger Fabric,
technology with the intent of exploring the potential for ex- and IOTA) with divergence in the design priorities, architectural
ploitation, which has resulted in an establishment of industrial elements, performance, and even roles of the participants and
blockchain associations such as Diem [10]. Governments in North basic definitions. While IOTA is not as popular as the other three,
America, Europe, and Asia are advancing blockchain-related strat- it is the most commonly used DAG-based system and it was
egy and legislation, reflecting their significant interest towards ranked at the fourth place [23] by the market cap in 2017.
the advent and utilization of the technology [11–16]. Blockchain First, we present generic roles of the participants in blockchain
has become one of the hottest topics at many societal, industrial, along with the significance of each role and explain how the enti-
and academic conferences. ties (i.e., computing devices of different categories) in a blockchain
The above has resulted in hundreds of blockchain systems in system of each type map to these roles. We introduce a generic
the industry, thousands of academic papers published over the layered architecture that applies to all blockchain systems re-
last few years, and an even larger number of new initiatives and gardless of the type. The study of the four systems is organized
projects. Following this explosive development, the area currently across these layers so that the design of each layer is considered
remains tumultuous, without commonly accepted terminology separately from the rest. This methodology allows us to conduct
and with occasionally diverging concepts and ideas. For exam- a comprehensive cross-system comparison. The comparison is
ple, we list five different definitions of the term ‘‘blockchain’’ in organized by clearly identified aspects: definitions, roles, entities,
Section 2.1, all being used in the literature and in description of and the characteristics and design of each of the layers. We
actual systems. also contrast the performance of the four systems based on the
Emerging surveys such as [17,18] among all have made an previously published information and explain the reasons for the
important first step towards orderly understanding of the area. differences.
2
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

Our exploration goes deeper compared to what is currently not imply any specific data structure, it covers such a general-
available in academic surveys and tutorials. For example, we pro- ization. On the other hand, the term of ‘‘blockchain’’ becomes a
vide the first extensive coverage of the storage layer in Ethereum misnomer in that case. In absence of more refined terminology
and the most comprehensive explanation of the consensus pro- today, ‘‘blockchain’’ is used in the literature to refer to a chain of
tocol in IOTA. The exposition is due to the consolidation of frag- blocks or generalized DLTs.
mented information about popular systems from blogs, developer To add to the confusion, some systems in this domain do
documentation, and studying the source code. not maintain a distributed ledger at all. For example, Corda [25]
Our main emphasis is on the education and pedagogical ex- allows participating computing devices to agree upon and main-
position that lends itself to courses and tutorials. While such tain shared knowledge in a non-trusted environment typical for
descriptions exist for Bitcoin, no such materials are available for blockchain. However, each piece of information is only shared
Ethereum and IOTA to the best of our knowledge. A more fine- within a subset of computing devices to which the information
grained summary of our contribution along with the comparison pertains. Yet, the term of ‘‘blockchain’’ is sometimes used to
with existing surveys is available in Section 5. collectively refer to all systems in the domain including Corda.
Our study focuses on the design of the systems themselves We have been able to identify the following definitions in the
rather than on application mechanisms developed atop them. In literature:
particular, we do not cover hybrid storage systems that com-
bine on-chain and off-chain elements. Besides, the scope does Definition 1. Blockchain is a system that uses the data structure
not include functional features such as sharding that are still in of Bitcoin but extends the functionality. This definition is used by,
development and that are not supported by the current versions e.g., Bitcoin spin-offs that were created either due to hard forks
of the blockchain systems. or as an extension of the limited scripting functionality of Bitcoin.
This definition is not limited, however, just to cryptocurrency
1.2. Roadmap systems; it can be utilized for a large spectrum of business logic
by customizing the blockchain modules and protocols.
In Section 2, we first contrast various blockchain definitions
and reflect on the discrepancies in the commonly used termi- Definition 2. Blockchain is a system that maintains a chain of
nology. Then, we introduce a list of roles of the participants blocks. This definition allows for generalization of Definition 1:
and a layered blockchain architecture that are both applicable it allows data structures other than those used in Bitcoin. For
to all blockchain systems regardless of the type. In Section 3, example, Ethereum and Hyperledger match this definition.
we present an overview of the four systems, discuss the enti-
ties in each, and explain how they map to the generic roles. Definition 3. Blockchain is a system that maintains a ledger of
In Section 4, we provide a layer-by-layer comparison between all transactions. The ledger does not need to be stored as a chain
the four systems while covering a variety of design aspects and of blocks, however. IOTA is an example of a system that follows
characteristics. In Section 5, we contrast our work with other this definition.
state-of-the-art surveys. Finally, we present our conclusions in
Section 6. Definition 4. Blockchain is a system with distributed non-
trusting parties collaborating without a trusted intermediary. This
2. Understanding blockchain: Definitions and concepts definition rather refers to the main beneficial property of the
paradigm. It was originally advocated by Corda [25].
In this section, we review and reflect upon central definitions
and concepts of blockchain technologies. Definition 5. Blockchain is a system that provides support for
smart contracts. Many blogs and popular science articles (such
as [26]) regard blockchain as a way of replacing paper-based con-
2.1. Reflection on various blockchain definitions
tracts and human intermediaries with smart contracts, without
considering how such contracts are implemented.
The term of ‘‘blockchain’’ generally refers to a paradigm for
maintaining information in a distributed system that is charac- The first three definitions above are sorted by generality, from
terized by a number of properties. Since there is no specification the most concrete to the most general. While they refer to the
or established standards in 2023 yet, different concretizations of way the system is built, the last two definitions are about the
this general definition have been adopted in the literature and way the system is used.
existing popular blockchain-based systems. It is important to distinguish between definition of blockchain
Distributed Ledger Technologies (DLTs, in short) is a well- and its characterization. While the definition has not been uni-
defined term: it refers to a system that records a ledger of versally agreed upon, the fundamental properties have been ex-
transactions or a history of changes to the system state. The tensively explored in the prior literature. For example, blockchain
ledger is usually hard to tamper with, which is a boon for security, data is immutable: new data can be added but already included
yet it also makes it hard to perform desirable changes, e.g., to data cannot be deleted or modified. Blockchain additionally pro-
prune the history or compact the ledger. vides tamper-resilience, i.e., protection of blockchain data against
While people tend to equate blockchain with DLTs, both nar- any unwanted modification. Since immutability and tamper-
rower and broader meanings of ‘‘blockchain’’ are in use. Literally, resilience are explained and discussed in a large body of liter-
blockchain means ‘‘a chain of blocks’’, which implies a specific ature [27], we do not cover them in this paper.
data structure for the ledger implementation. A chain of blocks In the absence of proper definition, a blockchain is sometimes
precludes any parallelism between the transactions, however, compared to a distributed tamper-resilient database with im-
which has a negative impact on the performance. Some ledger mutable data. It is important to observe that a blockchain differs
implementations use more a complex data structure such as from such a database in two fundamental ways. First, a database
braids [24] or a directed acyclic graph (DAG) in IOTA, which allow is an organized collection of data representing the current system
some degree of parallelism by retaining concurrently proposed state. The main functionality of a database is to allow efficient
competing blocks and merging them. Since the term of DLT does data retrieval, fusion, and aggregation triggered by user queries.
3
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

In contrast, most blockchain implementations represent a ledger vices [28,29] without any coordinated management of the system
in which a history of transactions (or, more generally, of changes structure, organization of computing devices, or network connec-
to the system state) is recorded. For example, there is simply no tions. On the other hand, consortium blockchain systems such as
concept of a user balance in Bitcoin! While Ethereum keeps track Hyperledger Fabric are smaller proprietary deployments where
of a contract state, it only provides limited means to retrieve the consortium may decide to partially manage all of the above.
and process state data, as explicitly defined by the contract. We observe, however, that even consortium blockchain does
It does not support abstractions of a flexible query language, not lend itself to complete management. In other words, all
data view, schema, join, etc. Besides, Ethereum records a history blockchain systems are self-organizing, though the extent of self-
of all changes to the state, which results in blockchain space organization varies across the systems. The scale and extent of
being more expensive and the storage less efficient compared management significantly affects design priorities and imple-
to a database. As a result, only specific data elements (such as mentation components as we explain in the rest of this survey.
short transactions or indices) are stored on a blockchain. Many Consortium systems are access-restricted by nature. Large-scale
blockchain systems combine blockchain with offchain storage decentralized systems are not query-access-restricted, though
(databases or dedicated file systems). they may be update-access-restricted.
Secondly, the trust model is radically different as observed Unfortunately, the above complexity is not reflected in the
in [25]. The database servers typically trust each other, even in currently existing terminology. All blockchain systems are coarsely
federated databases, in the sense that they do not expect attacks divided into two categories in the existing literature. The first
from within the system. The main security focus is on making category is referred to as public or open or permissionless while
it difficult to compromise a server in the first place. To this the second category is called private or closed or permissioned.
end, database systems defend against malicious clients by using The exact meaning of these six terms and differences between
firewalls, strict access control, and many other methods. The sit- them are not precisely defined to the best of our knowledge.
uation is fundamentally different in the blockchain environment:
the interests of participating computing devices are inherently 2.3. Participants and their roles
misaligned so that they need to verify information received from
each other and run a consensus to agree on changes to the data. Since the models and implementations significantly differ in
While being able to agree on changes and progress in absence of various blockchain systems, we need to identify common funda-
a trusted administrator is a powerful abstraction, it bears a cost mental elements in order to perform a systematic comparison.
tag in terms of performance. If there are no misaligned interests Two such unifying elements are the roles of participating comput-
between the participants and attacks from within the system are ing devices and the conceptual layered architecture. We discuss
unlikely, there is little point in using blockchain technologies. these two elements in Sections 2.3 and 2.4, respectively. They ap-
ply to all blockchain systems studied in the rest of the paper, and
2.2. Blockchain types they will likely generalize to many other blockchain approaches
as well.
The two most important characterizations are the constraints As commonly accepted in descriptions of distributed archi-
on which participants are allowed to propose updates to the tectures, roles refer to the functional responsibilities. The same
blockchain1 and which participants are allowed to read blockchain computing device may play a single or multiple roles in the
data. In Bitcoin, any computing device may propose updates to system. The roles in a blockchain system are presented in Fig. 1.
the ledger or read it. This is also the case for the public deploy- Creators of Transactions: Different entities implementing a
ments of Ethereum and IOTA. In Hyperledger Fabric, only au- blockchain application can create transactions and inject them
thorized computing devices are allowed either. However, mixed into the system by relaying them to the proposers.
models are also possible: In Ripple, every computing device has Proposers and Acceptors: A central functionality of a
read access while only authorized computing devices can propose blockchain system is to validate injected transactions and decide
updates. We call these characterizations update-access-restricted which transactions will be appended to the blockchain and in
and query-access-restricted, respectively. We refer to a system that what order. This is the main responsibility of computing devices
is update-access-restricted or query-access-restricted as access- acting as acceptors. To this end, they need to run a distributed
restricted. Obviously, systems that are access-restricted require consensus protocol. However, all consensus solutions have an
computing device authorization. inherent limitation when it comes to scalability: they do not work
Usually, the identities are also handled differently in sys- very well if there are too many acceptors or too many concurrent
tems that are access-restricted. Namely, such systems typically transactions to be considered. This also makes consensus pro-
use real computing device identities while systems that are not tocols susceptible to denial-of-service (DoS) attacks: an attacker
access-restricted commonly use public keys for identification. In can bombard a blockchain system with invalid transactions, effec-
principle, however, systems that are not access-restricted can still tively stalling consensus progress. To improve the scalability and
use real identities, if such identities can be verified and if the resilience to DoS, most blockchain systems introduce the role of
transparency of participation is more important than privacy. It a proposer. Proposers act as intermediaries between creators of
is also not unimaginable for access-restricted systems to employ transactions and acceptors. They may reduce the rate of concur-
public keys or pseudonyms, though it may require the authoriza- rent proposals by (a) verifying and pre-authorizing them locally
tion or authentication component to operate under different trust and filtering out invalid or non-authorized transactions, (b) intro-
and security assumptions compared to the blockchain system ducing explicit rate control, and (c) batching multiple transactions
itself. into a block. The exact distribution of responsibilities between the
There exists another related dimension for classifying block- acceptor and proposer roles depends on a specific blockchain sys-
chain systems, namely decentralization. Large-scale decentralized tem but the conceptual separation applies to most systems. Since
blockchain systems, such as Bitcoin, Ethereum, and IOTA, may blockchain systems do not assume that all computing devices
have up to hundreds of thousands participating computing de- are trustworthy, they may need to incentivize the blockchain
participants to perform their roles correctly, without deviations.
1 Throughout this paper, by updating the blockchain we mean appending Additionally, proposers and acceptors contribute to making the
new data. Other types of updates are impossible due to data immutability. blockchain tamperproof, together with data recorders.
4
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

Fig. 1. Roles of the participating computing devices and the relations between these roles.

Data recorders: These entities record the additions to the

blockchain accepted by the acceptors, which results in storing the
entire blockchain. Along with proposers and acceptors, they con-
tribute to data security by making the data tamperproof through
the use of cryptographic primitives.
Query issuers: They issue queries of different types over the
current blockchain data.
Query responders: Some of the computing devices playing
the role of data recorders have an additional responsibility of
responding to the queries from query issuers based on the stored
blockchain data. The need for and the exact role of query respon-
ders is further detailed in Section 4.4.6.

2.4. Architecture

The design of blockchain systems is based on a layered archi-

tecture, which we show in Fig. 2.
Hardware Layer: This is the bottommost layer of a blockchain
system. While most blockchain systems can be deployed with-
out any specialized hardware, hardware can make the computa-
tion (e.g., of cryptographic hashes) more efficient, provide extra
security of the storage and computing environment, etc.
Fig. 2. Layers of a blockchain system.
Data Storage Layer: This is the most important part of a
blockchain system when it comes to storing data, keeping it safe
from modifications, and making it traceable. This layer is also
responsible for providing availability and durability of data. All strength of security and privacy guarantees, including the ability
of these features depend on the data items used in this layer, the to withstand or mitigate DoS attacks.
method of storing the data, and the structure of the storage. Contract Layer: Blockchain systems provide the ability of
Communication Layer: Any blockchain system needs a mech- defining contracts for creating and enforcing the rules among the
anism for disseminating the transactions and blocks between participants of the network. Different blockchain systems may
the participants. This is especially important for large-scale per- use various methods for developing the contracts based on their
missionless blockchain systems. The granularity of dissemina- application domain. This layer deals with invoking and executing
tion, protocol of communication, ordering guarantees, privacy transactions within the contract, as well as programming lan-
and security guarantees, and propagation time are related to this guages (which may be Turing-complete or not) and execution
layer. All computing devices participating in a deployment of a environments.
blockchain system can be divided into two categories according Application Layer: This is an abstraction of the application
to their involvement in the dissemination: core nodes consti- built atop a blockchain system. While its specific design is outside
tuting the blockchain network and ‘‘client’’ computing devices. the scope of a blockchain system, it defines the requirements that
Core nodes cooperate based on a common protocol to maintain a blockchain system needs to satisfy.
blockchain data. In contrast, client computing devices do not play
an active role in the dissemination. Instead, they get specific 3. Understanding blockchain systems: overview and entities
blockchain data of interest from core nodes.
Data Manipulation Layer: The main responsibilities of the While pursuing the question of in-depth understanding of
data manipulation layer include updating the blockchain and of- blockchain, we opt to illustrate the range of possibilities by ana-
fering a search functionality for blockchain data. Since an update lyzing four blockchain systems with significantly different prop-
must be a coordinated decision in a decentralized environment erties and implementations. In this work, Bitcoin Core, Ethereum
with a lack of trust between individual participants, the con- 1.0, Hyperledger Fabric v.2.0, and IOTA IRI v.1.5 are compared
sensus protocol plays a central role in all blockchain systems. to each other in terms of blockchain entities and features and
Consensus protocols vary across blockchain systems [30], though mechanisms of each architecture layer. The blockchain field is
the two most common categories are probabilistic Nakamoto known for dynamic developments, with relatively short update
consensus and BFT. Design choices of the data manipulation layer cycles. However, Bitcoin does not undergo significant changes at
can affect different parameters related to performance and the this point so that we expect all Bitcoin-related descriptions to
5
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

Table 1
Mapping roles to the entities of different blockchain systems.
Blockchain system Transaction creator Proposer Acceptor Recorder Query responder Query issuer
Bitcoin Nodes Miners Full nodes Full nodes Dedicated services on Everyonea
top of full nodes
Ethereum Nodes Miners Full nodes Full nodes Dedicated services on Everyone
top of full nodes
Hyperledger Fabric Application clients Application clients, Orderers & peers Peers Application-dependent Application
endorsers & orderers clients
IOTA Clients Nodes Nodes Nodes & Dedicated services on Everyone
permanodes top of nodes &
permanodes
a
Everyone means any networked device.

remain valid in the future. Ethereum has declared its intent to DoS attacks by the miners. It is therefore needed to moderate the
release a new version with several significant changes, including number of proposers and rate of concurrent proposals. The entire
a transition from PoW to PoS. However, no studies of the new Bitcoin system must attain a balance with respect to the proposal
version have been published ahead of the release so that we rate: a high rate will hamper scalability while a low rate will
base our survey on the current operational version. While Hyper- limit progress and transaction throughput. Furthermore, Bitcoin
ledger Fabric continues to be under active development, the new must achieve that moderation through distributed mechanisms,
versions introduce new features and performance optimizations, without a centralized moderating entity. In order to keep the
switch to a different default consensus implementation, and mod- rate down, Bitcoin introduces a Proof-of-work (PoW) mechanism:
ify the chaincode features and structure. They do not radically When forming a block, a miner needs to solve a cryptopuzzle by
change the fundamental design of each layer, which we discuss performing a heavy computation and showing the proof of it, in
in our survey. Finally, IOTA IRI is currently the best documented order for the block to be accepted by other full nodes.
version of IOTA that is presented in the white paper [31]. For the Bitcoin system, there are dedicated services which act
Table 1 maps the blockchain roles to the entities of differ- as query responders: they provide information for any computing
ent blockchain implementations. In the following, we explain device on the Internet even if the device is not on the Bitcoin
the functionality of each entity and the interactions happening network. However, these services can only handle fixed basic
between the entities.
query types so that they are not as semantics-rich as specialized
databases. Additional information about queries in blockchain
3.1. Bitcoin
systems is given in Section 4.4.
In the Bitcoin deployment, neither update access nor query
access is restricted. Bitcoin participants are called Bitcoin nodes 3.2. Ethereum
in the Bitcoin terminology. They are split into two categories: full
and lightweight. Some roles are only performed by full nodes, The entities in the Ethereum system and the interactions be-
which act as both block acceptors and recorders of the whole tween them are similar to those in Bitcoin. However, Ethereum
blockchain. Upon receiving a newly broadcast block from the introduces a number of additional underlying concepts and mech-
network, they verify it using the previously stored data and po- anisms not present in Bitcoin. The most central of those concepts
tentially append it to the blockchain. Additionally, full nodes bear is that of gas: since transactions in Ethereum can be Turing-
higher responsibility w.r.t. dissemination in the Bitcoin network complete programs, it is impossible to predict how much of
as we explain in Section 4.3. A subset of full nodes is designated computational and storage resources a transaction will consume.
as miners that continuously attempt to create and propose new It is only feasible to monitor resource consumption at runtime
blocks. and abort the transaction if it exceeds the permitted budget.
Lightweight nodes are also called simplified payment veri- Ethereum manages budgets for executable units such as transac-
fication (SPV) [32] nodes. SPV nodes neither store the entire tions, blocks, smart contracts, etc. These budgets are measured
blockchain nor participate in the decision of accepting new blocks. in gas and paid for by the creators of transactions. Ethereum
They can however, use the SPV method to verify that a block assigns gas cost to resources (operations and storage units). When
header is valid and that a given transaction is included into a transaction executes an operation, Ethereum deducts the cost
the blockchain. To this end, they can retrieve block headers and of that operation from the budget. In Section 4, we consider
specific secure hashes from a full node and employ a Merkle veri- additional concepts and mechanisms in the context of each layer
fication algorithm. Merkle verification is explained in Section 4.2. and cover them in detail.
Both full and lightweight nodes are able to create transactions,
thereby playing the role of a transaction creator. This effectively
means that the separation between the entities is more blurred in 3.3. Hyperledger Fabric
Bitcoin (and similarly in Ethereum) compared to say, Hyperledger
Fabric and IOTA. In particular, both terms of ‘‘lightweight node’’ As Hyperledger Fabric is designed for use in private blockchain
and ‘‘lightweight client’’ are used in Bitcoin to refer to the same systems, it does not have the concept of miners. Furthermore,
entities. its entities and their responsibilities are completely different
Transactions are propagated to the miners that play the role compared to Bitcoin and Ethereum. There are three types of
of proposers. As common for large-scale deployments, the Bitcoin entities in Fabric: application clients, peers, and orderers. Clients
network cannot sustain every miner making a proposal at an arbi- are computing devices that constitute the application running
trary point in time because of the scalability barrier and potential atop blockchain and play the role of transaction creators. They
6
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

are external to Fabric and they connect to participants in the throughput of the consensus protocol that is used to update the
Fabric network. The peers are authenticated and authorized par- ledger. Bundles cannot be used to this end because they can-
ticipants in the Fabric network that constitute the core of the pri- not combine unrelated transactions. Interestingly, IOTA achieves
vate blockchain network. The orderers are dedicated computing higher throughput compared to Bitcoin and Ethereum by orga-
devices provided by the Fabric deployment. nizing bundles in a directed acyclic graph (DAG) as opposed to
The flow in Fabric is as follows: Clients send every proposed organizing blocks in a chain. We provide a detailed discussion
transaction to the endorsing peers (also called endorsers), which in the context of the storage and data manipulation layers in
are a subset of all peers determined by the endorsement policy. Sections 4.2 and 4.4.
More precisely, the endorsement policy defines the smallest set The roles and responsibilities in the IOTA deployment are
of endorsers that need to endorse a transaction in order for it shared by three main entities: (a) clients (b) nodes and (c) per-
to be valid [33]. The endorsers typically come from different manodes. Clients are external to the IOTA network. They connect
organizations within the consortium that deploys an application. to IOTA nodes via the HTTP API and interact with the network
Endorsers are responsible for simulating the transaction with- through the nodes. A client is responsible for creating transactions
out updating the blockchain and verifying if the update causes a and forwarding them to a node.
conflict with the current state or with the policy. If an endorser Nodes are interconnected together to form the core of the
approves the transaction, it identifies the set of data read and IOTA network. After having received a transaction from a client, a
updated by the transaction, which is called a read–write (or R–W) node needs to validate it. If the transaction passes the validation,
set. Then, the endorser sends the R–W set back to the client, along the node will create a bundle as we discuss later, in Section 4.4.4.
with the endorser’s signature. If transaction approvals obtained To prevent spamming and DoS attacks, nodes have to solve low-
by the client are insufficient according to the endorsement policy, complexity cryptopuzzles in order to propose bundles. Having
the flow effectively terminates. Otherwise, the client submits the performed the low-complexity PoW, the node attaches the bun-
endorsed transaction and the R–W set to the ordering service. dle to the local copy of the ledger called the Tangle [31] and
Ordering service consists of orderers which are responsible propagates the bundle to the network. Nodes run a consensus
for receiving the endorsed transactions and their R–W sets from protocol to synchronize their copies of the Tangle.
different clients, ordering them, and forming a block. The orderers Note that unlike Bitcoin and Ethereum, nodes do not create
run a consensus protocol to achieve ordering of transactions. competing proposals for updating the ledger. Accordingly, there
Once produced by the consensus protocol, a block is disseminated is no concept of mining in IOTA. Since nodes do not need to
to all of the peers in the system. Peers validate the block’s trans- perform any significant computation, they are not rewarded for
actions by checking whether the R–W sets still match the current
participation in the system either. Nodes are also able to answer
state of the blockchain. Finally, the peers add successfully verified
limited queries about the Tangle but this is not their primary
blocks to the blockchain and update the state.
purpose.
All peers store blocks, thereby playing the role of data record-
Permanodes are dedicated nodes, many of which are provided
ers. There is no equivalent of Bitcoin and Ethereum lightweight
by the IOTA Foundation itself. Similarly to nodes, they store a
nodes in Fabric. Orderers may be configured to store blocks as
copy of the Tangle. However, they are external entities to the
well.
IOTA network: they do not receive bundles from the clients or
In the above flow, the role of acceptors is distributed between
participate in the consensus protocol. Instead, they receive Tangle
endorsing peers in the first phase, orderers in the second phase,
updates from nodes. Their main purpose is to support complex
and all peers in the third phase. For example, the peers may reject
queries. To this end they store Tangle information in a special
the block produced by the orderers, if it is malformed or if it
database, as explained in detail in Section 4.2.
causes an inconsistency.
In summary, clients play the role of transaction creators and
Since the deployment scale of private blockchains such as
proposers. Nodes play the role of acceptors (validating the trans-
Fabric is typically smaller compared to a public blockchain such
actions in the bundle), recorders (storing the bundles in the
as Bitcoin, the significance of having a proposer role is reduced ac-
cordingly, see Section 2.3. However measures towards improving local ledger), and query responders (supporting services with
scalability are still taken: Endorsers perform pre-authorization simple queries). Permanodes play the role of recorders and query
of transactions, clients themselves may abort the flow if the responders; yet they support richer queries compared to nodes.
approvals are insufficient as per the endorsement policy, while
orderers batch transactions and form blocks. 4. Understanding blockchain systems layer by layer
Regarding query issuers and responders, application clients
issue queries in Fabric, while the peers which keep the state As we discussed in Section 2.4, blockchain systems are cate-
respond to those queries. gorized into six different layers: hardware, data storage, commu-
nication, data manipulation, contract, and application. We now
3.4. IOTA analyze the features and implementation of each layer in the four
selected blockchain systems.
Similar to Bitcoin and Ethereum, IOTA is a permissionless
blockchain system. IOTA organizes transactions into bundles in- 4.1. Hardware layer
stead of blocks. The main difference is that a bundle groups
related transactions together; a single transaction in a bundle While blockchain implementations are primarily software-
cannot be understood or performed independently of other trans- based, hardware components are used for two purposes: im-
actions in the bundle. For example, IOTA differentiates between proved efficiency and enhanced security. In particular, implemen-
input transactions that may combine funds from multiple input tations of open blockchain systems such as Bitcoin, Ethereum, and
addresses together and output transactions that may split a sum IOTA, are resource-bound: there is a hardware resource that lim-
into multiple output addresses. A bundle commonly contains its the ability of a single proposer to propose numerous changes
related input and output transactions, as well as transactions of to the blockchain at a fast rate. The exact resource varies across
other types. More details are given in Section 4.2. the systems, however. On the other hand, this is not required in
The main purpose of grouping transactions in a block in permissioned blockchain because of a tight membership control.
Bitcoin, Ethereum, and Hyperledger Fabric is to improve the Table 2 highlights related aspects for the analyzed systems.
7
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

Table 2
Hardware layer of different blockchain systems.
Features Bitcoin Ethereum Hyperledger Fabric IOTA
Limiting resource Processor Memory bandwidth Application-dependent Processor & network
bandwidth
Cryptopuzzle solving ASIC GPU No cryptopuzzles Proprietary processor
device (being phased out)
Additional hardware for Hardware-based trusted Hardware-based Application-dependent No additional hardware
security (Research execution environment trusted execution
initiatives) (e.g. Intel SGX processor) environment

As mentioned in Section 3, miners in Bitcoin require to per- A major focus of the blockchain technology is to provide
form costly and time consuming computations in order to create tamperproof storage in absence of trust in individual participants.
a valid block. They need to solve a cryptopuzzle by exhaustively In view of this, a number of initiatives such as Teechain [39]
going over the solution space and calculating a hash value for have tried to enhance the security of Bitcoin and Ethereum by
each potential solution, which results in a massive amount of taking advantage of the hardware-based Trusted Execution En-
®
hash computations. Therefore, the Bitcoin technology is strongly vironment (TEE) technology, such as Intel SGX processor [40].
dependent on the processing power of the miners. Nowadays, TEE is designed to create a more secure computation environ-
the most common hardware for the purpose of mining bitcoins ment for the processor by isolating and protecting the running
are ASIC processors [22]. They are designed specifically for the application against unauthorized access or tamper by the host
purpose of computing Bitcoin hashes in an optimized way. machine. While the use of TEE still requires the trust in the
In contrast to Bitcoin, Ethereum follows ASIC-resistant ap- TEE manufacturer, it mitigates potential attacks by individual
proach in its hardware layer. The goal of choosing such an ap- blockchain participants.
proach is coming up with a puzzle that reduces the gap between
the most cost-effective customized hardware and what most 4.2. Data storage layer
general-purpose computers can do, so that it would be economi-
cal for individual users to mine with the computers they already The purpose of the storage layer is to record all transactions
have [22]. To achieve this goal, Ethereum uses a different PoW in a distributed ledger and provide support for their efficient
algorithm compared to Bitcoin, called ethash [34]. The ethash verification. While simple transactions merely transfer financial
algorithm needs 64 sequential page fetches from the memory tokens, general transactions represent transitions in the global
to generate a single hash and compare it with the cryptopuzzle system state. It is important to keep track of the state, e.g., in
target. Since ethash is bound by the speed of memory access order to perform verification of transactions. While it is possible
rather than computation, speeding up the processor computation to reconstruct the most updated state by starting from the initial
by ASICs does not help in a significant way. Furthermore, since an state and replaying all transactions recorded in the ledger, this
expensive top performing computer only has moderate improve- would be a time-consuming and inefficient process, especially
ment in the speed of memory access compared to commodity since the ledger size is continuously growing. As a result, all
hardware, vertical scaling does not have a strong effect on the blockchain systems store explicit information about the current
efficiency of mining in Ethereum. Hence, utilizing GPU processors, state in addition to the transactions. However, the systems differ
which can solve cryptopuzzles faster than CPUs [35], is more cost- in terms of what state-related information they store and in terms
effective for mining in Ethereum. This has an additional effect that of how they organize it. Additionally, the storage layer provides
cryptopuzzles in Ethereum can be less computationally intensive. support for verification of transactions issued by the clients and
On the other hand, the power consumption of GPU is higher for computation on the state in the ledger.
compared to ASIC so that the net effect on power consumption The rest of the storage layer description covers state track-
in Ethereum is not clear. ing approach, general organization of blockchain storage, the
The design of cryptopuzzles in both Bitcoin and Ethereum block structure, structure of transactions and their grouping in
facilitates parallel computation, which increases the risk of min- blocks, on-disk storage, the use of trees in Bitcoin and Ethereum,
ing power centralization in the hands of powerful players. While in-memory storage, and data retention. Table 3 presents a com-
ethash limits the potential of vertical scaling for mining, horizon- parison of salient storage design aspects across the four systems.
tal scaling is widely used in both systems.
As there is no concept of mining in Hyperledger Fabric, it 4.2.1. State tracking approach
does not need specialized hardware components to boost the So far, all blockchain systems have been employing one of
efficiency, unless required by a specific application. While IOTA the two principal approaches for tracking system state. Bitcoin
does not use blocks and does not employ the concept of mining employs the unspent transactional output (UTXO) approach while
or monetary rewards, it still uses a less computationally intensive Ethereum falls under the arbitrary state approach. IOTA follows
version of cryptopuzzles in order to prevent denial-of-service the UTXO approach with a minor modification, as we explain
attacks. Therefore, IOTA is also dependent on the computation below. Fabric does not track state by default but the application
power of participating nodes. Since resource-limited IoT devices developer can devise and plug in any desired implementation
is the main focus of IOTA implementations [36], IOTA has devel- with some restrictions. The two approaches differ by generality,
oped a proprietary low-energy processor called JINN [37]. The compactness of transactions, simplicity and efficiency of storage
main purpose is to expedite the computation of relevant cryp- organization, ease of parallelizing transaction processing, as well
tographic primitives, though currently the computation is typi- as transaction linkability, i.e. that ease at which a transaction can
cally done in software. Besides computation power, bandwidth be linked to an individual user.
is another critical resource in IOTA since IoT devices are also In the UTXO approach, a transaction transfers currency to-
bandwidth-limited [38]. kens by consuming a number of input tokens and producing a
8
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

Table 3
Data storage layer of different blockchain systems.
Features Bitcoin Ethereum Hyperledger Fabric IOTA
State tracking approach UTXO Account-based Application-dependent UTXO
Higher-level structure Sequence of blocks with Sequence of blocks with Sequence of blocks with DAG of transaction
transactions transactions transactions bundles with edges
signifying approvals
Maximum block/bundle size 1 MB block fixed by the Block’s gas limit Configurable block size Unlimited bundle size
protocol determined by miners as per application
Ledger Block data as multiple Block data as multiple Block data as multiple Tangle stored in a
storage files of limited size each files of limited size each files of configured size RocksDB database
On-disk storage
Index Block index in a LevelDB – Block index in a LevelDB –
database database
State- UTXO set in a LevelDB Each vertex of tries Worldstate in a LevelDB Balance info stored in
related database (state, storage, receipts, or CouchDB database RocksDB database
storage txs) in a LevelDB
database
Extra Each block file has a All block data (block – Snapshot data as a file
storage corresponding undo file header and transaction
elements to support data) in a LevelDB
reorganization/fork database
In-memory storage Block index database, Cache of Merkle Patricia Application-dependent; Tangle Accelerator
UTXO cache, & Merkle tries vertices peer cache (proxy cache for IOTA
trees of transactions nodes)
Data retention No retention policy State tree pruning No retention for ledger; Snapshot purges the
application-dependent database
for the state

number of output tokens. For example, suppose Alice has previ- is kept separately for each proprietary deployment. Besides, the
ously received 6 tokens in a single transaction. In this case, the six worldstate in Fabric is further partitioned per channel. The con-
tokens become identifiable transactional outcome (TXO), which figurable nature of Hyperledger allows an application developer
is marked as unspent. Assume Alice later wants to transfer 4 to choose an appropriate approach per partition, based on the
tokens to Bob. She can use the six token UTXO as the input to the application needs.
new transaction. During the transaction execution, the protocol Since the general state may be of an arbitrarily large size, a
will verify that the UTXO has not been spent. Then, three new question of limiting the state size arises. This challenge is miti-
UTXOs will be created: one UTXO with transaction fee will be gated in permissioned blockchains by the ability to have a tighter
transferred to the block creator, one UTXO worth 4 tokens will be control over the behavior of each particular user and application.
transferred to Bob while another UTXO worth two tokens minus In public blockchains, on the other hand, the users need to be
transaction fee will be transferred back to Alice. Additionally, the disincentivized from storing too large of a state. This is achieved
old six token TXO will be marked as spent. In the UTXO approach, in Ethereum through the gas spending mechanisms mentioned in
the system only keeps track of the unspent transactional outputs Section 3.2: the users pay gas not only for transaction execution
because they can be used as input to future transactions. Since but also for state storage, proportionally to the state size.
there is no concept of accounts or wallets at the protocol level, the The per-account state in Ethereum includes the user balance
‘‘burden’’ of maintaining a user’s balance is shifted to the client as well as any additional variables required for general calcula-
side. Wallets maintain a record of all UTXOs associated with a tions. In the above example, a transaction transferring four tokens
user and compute the total sum, which represents the balance. from Alice to Bob would need to check Alice’s balance, decrease
However, this balance is inaccessible to all but the user who owns it, and add the funds to Bob’s balance.
the wallet. A single user may receive many token transfers in the UTXO
The UTXO approach in IOTA slightly differs in that the term approach and may own many unspent TXOs simultaneously. This
of ‘‘address’’ is used to refer to a collection of multiple TXOs means that when limited to applications that transfer currency
because an address can be reused to receive funds in multiple tokens, the blockchain state may grow with the number of trans-
transactions, thus acting as a pseudo-account. The storage system actions over time, whereas in the account-based approach, the
in IOTA keeps track of all transactions that have transferred funds state size only depends on the number of users. In this scenario,
to a given address. Like a TXO, an address can only be used once the account-based approach may require less storage compared
when sending funds such that the entire amount is spent. This to the UTXO approach. Besides, a single UTXO-based transaction
minor difference in IOTA does not have a significant impact on may take many input TXOs and may produce many output TXOs.
the properties of the UTXO approach, which we discuss below. This makes the verification protocol less efficient compared to the
The arbitrary state approach is more general in that it supports simple verification procedure in the account-based approach.
arbitrary state rather than just tokens transferred between the On the other hand, the UTXO approach may allow for better
users. This naturally leads to more complex storage structures parallelization of transaction processing. For example, if Alice
compared to the UTXO approach. In particular, it is common to wants to transfer one UTXO to Bob and another to Carol, the two
keep the state partitioned. For example, each user in Ethereum transfers can be handled in parallel. In contrast, Alice’s balance
has an associated account and the state is partitioned by those would need to be checked sequentially in the account-based
accounts so that the state tracking approach in Ethereum is model, which would require serialization of the two transfers.
commonly referred to as ‘‘account-based’’. Since there exists no The UTXO approach also has an edge when it comes to privacy,
single public deployment of Hyperledger, the state in Hyperledger specifically hiding the link between the user and her transactions
9
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

and balance. In the account-based approach, the system main- 4.2.3. The block structure in Bitcoin, Ethereum, and Fabric
tains the user’s balance and keeps explicit association between The key differences in the block storage structures in Bitcoin,
the transactions and accounts. No such association is maintained Ethereum, and Fabric are mainly due to two important design
in the UTXO approach so that the state cannot be linked to an choices: (a) record keeping model and (b) consensus protocols.
individual user. As the account model requires more storage to represent the
As mentioned in the beginning of this section, Fabric does association between the accounts and the balances, the block
not provide any implementation for state tracking that would be structures for account models are relatively complex compared
included in the installation. The application developer, however, to those for UTXO. As we detail in Section 4.2.5, Ethereum has to
can implement any state tracking approach in Fabric using the keep track of the states and changes associated with each account
key–value store provided to this end. If a financial application in contrast to UTXO-based Bitcoin.
needs to maintain user accounts with corresponding balances, the The block body in all three systems includes a list of transac-
account name can be used as a key while the balance will be tions. In Ethereum, it additionally includes a list of uncles (whose
included in the value. The UTXO model can be implemented in concept is explained in Section 4.4.2).
the key–value store of Fabric as follows [41]. First, every UTXO The block header in all three systems contains the parent block
can be represented as a unique key–value entry in the store. Any hash. This hash is inherent to all blockchain systems that create a
chain of blocks and presents the cornerstone for the immutability
unique identifier created for the UTXO can be used as a key. The
property. The hash is only calculated after the block formation
value will specify (a) the amount of cryptocurrency that the UTXO
has been completed; thus, a hash of the block cannot be included
holds and (b) the reference to the owner of the UTXO, which can
in the block itself. Instead, Bitcoin, Ethereum, and Fabric nodes
be represented in different ways, such as the public key or the
compute the block hash when they receive the block from the
Fabric identity. Any transfer transaction will spend old UTXOs and
network. Fabric nodes, however, additionally store the hash of the
destroy their entries in the store. It will also create new entries,
block data in the block header.
one for each new UTXO. Nonce is another important field in the block header of
blockchain systems that use mining such as Bitcoin, Ethereum,
4.2.2. Organization of blockchain storage and IOTA; it contains a solution for the block cryptopuzzle. In
The storage organization is conceptually similar in Bitcoin, Ethereum, the header additionally includes a hash of the uncle
Ethereum, and Fabric. The transactions are grouped together into list stored in the block body, as explained above. Furthermore,
blocks to improve scalability of the consensus protocol as ex- Ethereum stores the root hash for each of the multiple search
plained in Section 4.4. The blocks are stored in files on disk. To tries in the block header, as we explain in Section 4.2.6.
provide tamper resistance, the individual blocks are linked to Considering the permissioned nature of Hyperledger, the block
each other to form the logical structure of a chain. Since each storage structures in the system include the real identity and
block includes a hash pointer to the previous block in the chain, signatures of the clients, endorsing peers, and the orderer. Such
tampering with one block would affect the hash values in all identities are not present in Bitcoin, Ethereum, and IOTA. Fur-
subsequent blocks in the chain. thermore, invalid transactions may be included as part of the
In addition to the chain of blocks, the storage includes a confirmed block due to the working principles of the consensus
key–value store for keeping auxiliary information, e.g., related protocol of the Hyperledger as explained in Section 4.4. Therefore,
to the system state as explained in Section 4.2.1. An increased there is a filter flag for each stored transaction, which is used to
emphasis on the state storage and state-related operations (such differentiate between valid and invalid transactions in the block.
as search) in Ethereum results in significantly more complex
storage mechanisms compared to Bitcoin. Besides, the balance 4.2.4. Structure of transactions and their grouping in a block
of roles between the chain of blocks and the key–value store The maximum number of transactions that can be grouped
is fundamentally different in Bitcoin and Ethereum because a together is determined by the maximum size of the block. For
key–value store lends itself better to state-related operations. example, in Bitcoin, the maximum size of the block is fixed by
In Bitcoin, search for blocks and even transactions is conducted the protocol at 1MB. The transaction size in Bitcoin varies since a
primarily using the chain of blocks, with the help of a block index UTXO transaction can have multiple inputs and multiple outputs.
Unlike Bitcoin, Ethereum uses the concept of gas to determine
maintained in the key–value store. In Ethereum, on the other
the size of the block. Every transaction in the block has a gas
hand, block headers and transactions are duplicated in the key–
price and the sum of prices for all transactions in a block should
value store, which is the main storage element used in the search.
not exceed the maximum gas limit of the block set by Ethereum
Furthermore, much of the data kept in the key–value store is
miners. In the case of Hyperledger, the maximum block size can
organized in cryptographic search trees (henceforward referred
be configured by the administrator of the network, in accordance
to as cryptographic tries), while Bitcoin only constructs trees in
with the application requirements.
memory and for a different purpose, as we elaborate upon in While not using blocks, IOTA utilizes the concept of bundles.
Section 4.2.6. A bundle is a group of transactions that are tied to each other.
IOTA is different from Bitcoin, Ethereum, and Fabric in three The need for bundles arises because, unlike Bitcoin, transactions
respects: there are no blocks, the structure is different from in IOTA are limited in terms of the maximum allowed number of
the linked list, and the transactions themselves are stored in a inputs and outputs. Since proposing each transaction in a bundle
database rather than a ledger. As opposed to the chain of blocks, requires a separate proof-of-work puzzle (see Section 4.4.5), these
IOTA utilizes a directed acyclic graph (DAG). In essence, the limits translate to the maximum number of inputs and outputs
vertices represent transactions while the edges signify approval of permitted for each puzzle; longer bundles would thus require
the transactions. A new transaction has to verify and approve two more work. Thus, if Alice wants to consolidate funds from multi-
existing transactions in order to be included in the DAG. Accord- ple addresses and transfer those funds to several different users,
ingly, the consensus algorithm significantly differs as we explain she would need to create a bundle with multiple transactions.
in Section 4.4.4. When it comes to storage, DAG storage requires Thus, the entire bundle is issued by the same client. The size of
more space compared to systems that use a chain of blocks. This is the bundle is determined by the input; it is unpredictable and
because there are more vertices in the DAG than blocks in a chain, beyond the system control. Furthermore, IOTA does not have a
and every vertex has non-trivial meta-information attached to it. predefined limit on the number of transactions in the bundle.
10
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

In Hyperledger Fabric, the design of the transaction structure

depends on the application and state tracking approach chosen
for the specific deployment.

4.2.5. On-disk storage

The most important element stored on the disk is the ledger.
Bitcoin, Ethereum, and Hyperledger Fabric store their block data
as multiple files, each of which is limited in size. Although the
file size limit is fixed in Bitcoin and Ethereum, it is configurable
in Hyperledger Fabric [46]. Block files store the blocks appended
to the local copy of the ledger [47].
Bitcoin additionally stores block indexes on the disk to keep
track of the information available in the chain of blocks. These
indexes are stored in a LevelDB (key–value store) database. Sim-
ilar to Bitcoin, Hyperledger Fabric utilizes indexes. By default,
Fabric also stores indexes in LevelDB but it can be replaced by
other databases. The primary purpose of the indexes is to support
search functionalities for blocks and transactions stored in the
file through various keys such as a block number, block hash,
transaction id, and transaction number. The values of the LevelDB
key–value store are corresponding file location pointers to the
Fig. 3. An Ethereum transaction structure. chain of block files [47,48]. When an API call to access blocks and
transactions of the blockchain occurs, these search indexes are
utilized to find the actual data location in the file. On the other
hand, Ethereum relies on a database for keeping track of changes
In the IOTA implementation presented in this survey [42],
and finding data items, so that has no need for indexing the files.
the bundles can be used as a vertex in the DAG as opposed to
State-related storage is another salient on-disk element. Bit-
individual transactions.
coin, Ethereum, and Hyperledger Fabric use a database of key–
Bitcoin transaction structure is described both in the specifi-
value pairs for keeping track of the latest blockchain state. In
cations [43] and textbooks [22] in detail. Its main fields are the
Bitcoin, the UTXO set which stores all unspent outputs is all
list of inputs and the list of outputs common in the UTXO model
as explained in Section 4.2.1. As Ethereum does not follow the information that is required to validate a new transaction without
UTXO model, it has a different transaction structure. As shown the need to traverse the whole blockchain [49]. Bitcoin keeps the
in Fig. 3, the transaction structure in Ethereum includes the UTXO set in a LevelDB storage called chainstate. On the other
following information: hand, Hyperledger Fabric keeps track of the latest values of the
Account nonce (called nonce in Ethereum code [44]): An business assets in its state-related storage called worldstate. The
Ethereum node issuing transactions on behalf of the user main- state-related storage of Hyperledger Fabric is represented on the
tains a counter of the number of transactions sent from the user’s disk as a LevelDB key–value store by default. The keys and values
account. When the transaction is issued, the node sets account of the state-related storage reflect the data model described in
nonce to the current value of the counter. Keeping track of this the application chaincode, as defined by the developer (see Sec-
count over time is important for two reasons: first, it establishes tion 4.5). In Fabric, if the business application requires a complex
sequential order between transactions sending funds from the data model and access pattern, various other databases such as
same account so that the miners or validators will process the CouchDB, GraphDB, and a relational datastore can be used to
transactions in that order. Second, the account nonce prevents represent the worldstate instead of LevelDB. These alternatives
transaction replay attacks by the recipient of funds because a support rich queries and data types [50]. Similarly, Ethereum
repeated transaction with the same nonce will be detected as stores the latest values of all the accounts in a LevelDB database
invalid. as the state-related storage to facilitate calculating the current
Gas price (called gas_price in Ethereum code) is the price of value of any account available in the ledger. For this purpose,
each unit of gas, expressed in Ether. Ethereum constructs the following four tries:
Gas limit (called gas in Ethereum code) is the maximum State trie represents the global state that efficiently stores the
amount of gas that can be consumed by executing this transac- mapping between all the addresses and accounts.
tion. Storage trie is responsible for maintaining the relationship
Recipient (called to in Ethereum code) is the address of the between the account and the corresponding balance. State trie
transfer receiver. is linked to the storage trie.
Amount (called value in Ethereum code) is the value to be Transactions trie represents the transactions that change the
transferred to the recipient. state of the Ethereum.
Payload (called data in Ethereum code): If the transaction is Receipts trie represents the outcome of the successful execu-
meant to be an execution of a contract (the recipient is a contract tion of transactions.
account), the payload field would be a message that identifies the Individual systems additionally maintain auxiliary meta-data
function and argument values of the contract. Otherwise, if the stored on the disk. In Bitcoin, each block file has a corresponding
transaction is for payment (the recipient is a user account), the undo file which contains the information that is necessary to roll
payload field would be empty. back and remove a block from the blockchain in the event of a
Signature values: This field includes components of the signa- reorganization/fork [47]. In Ethereum, in addition to storing block
ture algorithm of the sender. Ethereum transactions use ECDSA data as files, all block data including the block header and the
(Elliptic Curve Digital Signature Algorithm) [45] as their digital block body is stored in a LevelDB database as shown in Fig. 4.
signature for verification. The signature of a transaction confirms Due to the different organization of blockchain storage in IOTA
that the sender has authorized this transaction. as described in Section 4.2.2, Tangle is stored in a database rather
11
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

Fig. 4. On-disk storage of Ethereum consists of the block data and database records.

than in files. Thus, all the information about both transactions and knowledge of the ledger, inquires about the inclusion status of a
balances is kept in the RocksDB database. As an extra element, an particular transaction in a new block. To this end, the node sends
IOTA node keeps snapshot data (explained in Section 4.2.8) in a a verification request including the transaction hash to a full node
file. Each time a new snapshot arrives, it removes all transactions which keeps track of the ledger. The full node first needs to locate
from the Tangle, i.e. RocksDB database, and moves only non-zero the Merkle tree of the block in memory and then, sequentially
balances to a file in order to be used by the new pruned Tangle. scan the leaves of the tree in order to verify the inclusion. While
Thus, similarly to Hyperledger Fabric, IOTA maintains only the a sequential scan is not an efficient operation, its inefficiency does
current balances associated with the addresses. not have a strong impact because the number of transactions in a
block is relatively small. However, once the transaction is found,
4.2.6. On the use of trees in Bitcoin and Ethereum the full node can construct the Merkle proof efficiently [51]. The
Bitcoin and Ethereum use trees to organize data items (trans- Merkle proof includes all vertices on the path from the leaf with
actions and in the case of Ethereum, other data elements related the transaction to the root of the tree, along with the children of
to state tracking) in the context of a given block. The trees are these vertices. The full node can then send the Merkle proof back
cryptographic: every non-leaf vertex stores a secure hash value to the lightweight node. The crucial point is that the lightweight
for each of its child vertices. This way, tampering with a single node can verify the inclusion based on the Merkle proof, without
tree vertex n, or inserting a new vertex n will lead to modification requiring the rest of the vertices in the Merkle tree. The size of
of all the hashes on the path from n to the root of the tree, the Merkle proof is logarithmic with the size of the Merkle tree.
making it easily detectable. Due to this, the hash of the root vertex In addition to constructing Merkle proofs, there are in fact very
becomes a cryptographic fingerprint of the entire tree structure. few operations supported by Bitcoin Merkle trees. Miners benefit
Because of its significance, the hash of every root vertex is kept from being able to efficiently append new leaves with transac-
in the corresponding block of Bitcoin or Ethereum for the sake of tions because new transactions can arrive while mining a block.
verification. Merkle trees allow for efficiently implementing this particular
However, Bitcoin and Ethereum use trees for different pur- type of vertex insertion because a new transaction becomes the
poses, and accordingly, their implementation is quite different. rightmost leaf. Additionally, the trees can be pruned: for example,
Bitcoin uses binary Merkle trees as shown in Fig. 5. For a given if we do not need to verify the inclusion of Transactions 1 and 2 in
block, the tree is constructed as follows: each leaf represents a Fig. 5 any longer because their TXOs have already been spent, we
block transaction. The order of leaves corresponds to the deter- can remove corresponding leaves, along with their hash vertices.
ministic order in which the transactions are listed in the block We do need to keep the vertex with Hash(Hash(TX1)+Hash(TX2)),
body. Each non-leaf vertex is created by computing a secure however, for the purpose of constructing Merkle proofs, as ex-
hash of the concatenation of the two child values. Due to this plained above. On the other hand, vertex search, update, and
construction, the tree is deterministically reproducible from the deletion are neither needed nor efficiently supported.
block body stored on the disk. This is important because Bitcoin This is in a stark contrast with Ethereum, which uses the
constructs Merkle trees in memory on demand. trees for storing the state, in addition to transactions. Unlike
The main purpose of utilizing Merkle trees in Bitcoin is to transaction history which is fixed, the state in Ethereum needs
minimize the amount of bandwidth used for disseminating the to be frequently changed: new accounts are inserted and old
proof that a given transaction is included in a given block. It is accounts are deleted. The state of a particular account needs to be
a typical situation that a Bitcoin lightweight node, without the searched and updated as well, potentially often. Ethereum uses
12
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

This functionality allows for an efficient verification of trans-

actions of block n: when applied on the state of block n − 1,
these transactions, if valid, will update the state to that of block
n. To implement this functionality in a space-efficient fashion,
Ethereum uses an interesting variation of the copy-on-write tech-
nique, as illustrated in Fig. 6. While the transaction and receipt
tries are strictly separate for each block, the state and storage
tries can be partially shared across the blocks. In the illustration,
the key for the state record of Account 1 in Block 1 hashes to
value b10a5. The record is placed in Leaf 1, which is the leftmost
child of the branch vertex. Similarly, the key for the state record
of Account 2 in Block 1 hashes to value b1d14 and it is placed
Fig. 5. Bitcoin’s transaction Merkle tree.
in Leaf 2A. The state of Account 1 has not been modified by the
transactions of Block 2. Therefore, the branch vertex in Block 2
points to the same record of Leaf 1 as the branch vertex in Block
1. On the other hand, the state of Account 2 has been modified by
Merkle Patricia trie, which provides logarithmic complexity for
the transactions of Block 2. Since the path to the state of Account
search, insertion, update, and deletion, in addition to efficient
2 is the hash of the account address i.e., b1d14, Ethereum creates
construction of Merkle proofs. Similarly to the Merkle tree, data
a new record called Leaf 2B in the same path under the branch
items are stored in the leaves. However, Merkle Patricia trie is vertex in Block 2 to update the balance. Due to the creation of a
a prefix tree that uses hashing mechanisms to produce a key new leaf record, Ethereum also creates new branch and state root
string that determines the path of the data item within the tree. vertices in Block 2. Note that by starting from the old root vertex
Normally, prefix trees create a new tree level for each character in in Block 1, we can still find the old state of Account 2.
the key: the first character will determine the branch at the root, Storage tries are updated in a similar way. As a result, the state
the second character will determine the branch at the next level, and storage tries are only partially updated due to the transac-
and so on. However, Merkle Patricia trie is a compact radix tree: if tions in every new block. In reality, the changes in the state and
there are two vertices with keys ‘‘abcd’’ and ‘‘abef’’ respectively, storage tries of each Ethereum block are fairly small [52], which
an intermediate vertex with the key ‘‘ab’’ will be created. This makes the copy-on-write technique described above particularly
vertex will have two direct children corresponding to ‘‘abcd’’ and effective.
‘‘abef’’, without any additional intermediate levels. In Ethereum,
the key is encoded as a hexadecimal value so that each vertex has 4.2.7. In-memory storage
at most 16 children. Bitcoin creates Merkle trees in memory on demand, when a
The key string that determines the path is produced differently need arises (see Section 4.2.6). As mentioned in Section 4.2.6, the
for each trie type. For the state trie, each leaf corresponds to an trees are deterministically reproducible in memory from transac-
account in Ethereum. The key string is derived from the hash tions stored on disk. Furthermore, in Bitcoin, the entire LevelDB
of the account address, while the value of the leaf includes the database of block indexes is loaded into memory on startup to
balance and the root hash for the storage trie of the account. For achieve a better performance of finding the blocks [47]. UTXO
the storage trie, each leaf represents an Ethereum contract’s data. cache is another critical data structure maintained in Bitcoin
The key string is derived from the hash of the Ethereum contract’s memory [53]. As the UTXO set stored in LevelDB is accessed
address, while the values reflect the data model described in frequently during block validation, the access time becomes a
the Ethereum smart contract. An updated state of an Ethereum major bottleneck. Therefore, during the block validation, the re-
account is retrievable by traversing the storage trie vertices in the quired unspent coins are pulled from LevelDB into an in-memory
LevelDB database. cache. Since the size of the entire UTXO set exceeds 8 GB, cache
As shown in Fig. 4, each vertex of every Ethereum Merkle management is required.
Patricia trie is stored as a separate record in the LevelDB storage. In Ethereum, different node implementations such as Geth
The key for the record is derived from the hash of the trie vertex maintain an in-memory cache of configurable size, designated
and stored in the parent vertex record. Since the hash for the root for vertices of various tries. In the context of Hyperledger Fabric,
vertex is stored in the block header, it is used as the starting point when using a state database, read delays during endorsement and
for finding other trie vertices in the database, which allows for an validation phases have historically been a performance bottle-
efficient traversal of the entire trie. neck. With Fabric v2.0 [54], a new peer cache replaces many of
Fig. 4 provides an illustration for the storage organization on the expensive lookups with fast local cache reads, and the cache
disk in Ethereum. Header and body for Block 2 are stored in size can be configurable. Moreover, what is stored in the memory
both Block 2 data file(s) and in the database. The header contains storage of Hyperledger Fabric depends on the implementation of
root hashes for the state, receipt, and transaction tries. Each root the application. Finally, IOTA uses Tangle Accelerator [55], which
hash is a key for the corresponding root vertex record in the is an intermediate caching proxy server between the client and
database. From the root record of the state trie, we can reach the IOTA node to speed up the attachment process of a bundle to
branch vertex record, which points to Leaves 1 and 2B, each of tangle.
which corresponding to a different account. The record of Account
2B points to the root of the storage trie for that account. The 4.2.8. Data retention
pointers between the vertices of the storage trie in the database Data retention is performed differently in each of the repre-
are presented in a similar way. sentative blockchain systems. The ledger in Bitcoin grows more
Another interesting functionality of Ethereum is that it con- slowly compared to Ethereum and IOTA because Bitcoin stores
tinues maintaining correct tries for old blocks, not just for the less data per-block compared to Ethereum and because new
most recent block. For example, we can query the value of an blocks are appended less frequently compared to ledger changes
account or the value of a variable (maintained by a smart con- in Ethereum or IOTA. As a result, Bitcoin is less in need for
tract) in a past block, even if those values have later been updated. ledger pruning mechanisms. For the time being, Bitcoin does not
13
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

Fig. 6. Constructing tries across multiple blocks in Ethereum.

have any data retention policy and keeps all of its transactions the transaction history and the addresses with zero balances and
forever. As a consequence, the storage on Bitcoin full nodes can creates the list of addresses with a non-zero balance to reduce
potentially grow large in size over time, which may become an the Tangle size [56]. This in turn speeds up the time required to
even bigger issue if Bitcoin manages to overcome its scalability do synchronization among nodes. Another advantage is that the
barrier and raise the average rate of transactions. snapshot can indirectly improve the throughput of transactions
Similar to Bitcoin, Ethereum keeps its transactions forever in in IOTA by increasing the speed of computing the balance for
the ledger. However, Ethereum has a state trie pruning mecha- the accounts. Considering the nature of permanodes (refer to
nism [52] for obsolete states. This mechanism tracks when trie Section 3.4), the snapshot process does not have any impact on
vertices are no longer referenced by the state trie (for example, their storage.
the Leaf2A vertex in Fig. 6 has dropped out of the state trie in
Block 2), and at that point places the dropped vertices on a death
4.3. Communication layer
row in the database. From this point, after 5000 new blocks have
been appended, the vertex will be permanently deleted from the
database. Essentially, Ethereum stores the trie vertices that are Comparison between the communication layer features of the
part of the current state or part of the recent history [52] (up to surveyed blockchain systems is shown in Table 4. Only full nodes
5000 recent blocks). are part of the blockchain network in Bitcoin; they receive all
Similar to Bitcoin and Ethereum, transactions on the ledger blocks and transactions by running the dissemination protocol.
will never be deleted in Hyperledger Fabric. However, data from Lightweight nodes connect to the full node of their choice. Unlike
the worldstate database can be deleted if an application de- full nodes, lightweight nodes only receive a subset of trans-
veloper defines the procedure of pruning obsolete data in the actions, filtered for them by the full nodes to which they are
implementation. connected [57]. Furthermore, lightweight nodes rely on full nodes
IOTA provides snapshots regularly in order to reduce the size for propagating transactions to the network. In terms of receiving
of storage needed by nodes. The snapshot process removes all blocks, lightweight nodes download only the block headers from
14
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

Table 4
Communication layer of different blockchain systems.
Features Bitcoin Ethereum Hyperledger Fabric IOTA
Granularity of Whole network Whole network Per channel Whole network
dissemination
Entities forming the Full nodes Full nodes Orderers and peers Nodes
network
Communication protocol Inventory push-gossiped Blocks or block hashes leader pulls blocks from Push-flooding
& blocks pulled by full push-gossiped & block orderers & push-gossips
nodes headers and bodies to peers
pulled
Mean time to receive a About 12.6 s About 109 ms Application-dependent No studies conducted
block
Ordering guarantees No guarantees No guarantees Totally ordered No guarantees
broadcast
Privacy & security No guarantees Proprietary deployment Authenticated channels Authenticated and
guarantees can enable encrypted & encrypted messages,
authenticated messages partial anonymity
Initial peer discovery Through a set of DNS Through a set of Anchor peering & Manual conn. through a
seeds or direct conn. to bootnodes or direct channel membership node list
a known full node conn. to a known full
node
Geo-proximity in the 135 ms (avg.) 171 ms (avg.) Depends on consortium No studies conducted
network peer-to-peer latency peer-to-peer latency network topology

the full nodes. Ethereum is absolutely identical to Bitcoin in The study of [61] shows that 95% of the blocks are propagated
terms of network formation and the division between full and through the Ethereum network within 211 ms (the average time
lightweight nodes. Fabric and IOTA are also quite similar in this of a block propagation delay is stated to be 109 ms). An experi-
regard: peers constitute the peer-to-peer network in Fabric while ment in [60] estimates that it takes only 3 or 4 hops to broadcast
clients connect to the peers which selectively relay transactions a new block to the entire Ethereum network. This small world of
and blocks from and to the clients. In IOTA, clients connect to the an Ethereum network compared to the Bitcoin network can be
network of IOTA nodes, the latter relaying bundles from and to the reason for the lower block propagation time in Ethereum.
the clients. Peers in Hyperledger Fabric use both push and pull methods
In order to manage the granularity of dissemination, Hyper- in the communication protocol [62]. In the case of block dissem-
ledger Fabric is using the concept of channels. Transactions sub- ination, a leader is selected from the peers. The leader becomes
mitted and propagated in a channel are isolated from the other responsible for pulling blocks from the orderers and then initiat-
channels. The channels are independent of each other in terms ing a push-gossip protocol to propagate the blocks to the peers:
of the order, delivery, and processing of the transactions. On Each peer broadcasts the blocks to a random set of neighbors
the other hand, transactions in Bitcoin, Ethereum and IOTA are in the channel. In addition to push-gossiping, each peer is also
propagated through the whole network. responsible for selecting a number of random peers regularly
Next, we consider the communication protocol and propagation and attempting to pull the missing blocks from them. The design
time for each of the four systems. In Bitcoin, each full node sends choice to use a leader for initiating push-gossip is motivated by
inventory messages (inv) [58] periodically to advertise its knowl-
the need to reduce the load of sending blocks from the orderers
edge of transactions or blocks to the neighbors in the network.
to the network. Orderers in Hyperledger Fabric also enforce basic
This advertisement contains the hash value of the transactions
access control for channels, restricting who can read and write
or blocks as their identifiers, which is much shorter than the
data to the channels, and who can configure them [63]. In Fabric,
actual transaction or block. Then, each neighbor that receives the
the propagation time is dependent on application characteristics,
advertisement checks if it mentions knowledge of transactions or
especially on the transactions type and network size.
blocks the neighbor has not seen before. In this case, the neighbor
In IOTA, the transactions are flooded throughout the network
requests the missing transactions or blocks from the sender via
similarly to Ethereum. On the other hand, since no studies have
the getData message [58].
Experiments in [59] indicate that it takes about 40 s for a new been conducted for the propagation time in IOTA, it can be
block to propagate to 95% of the Bitcoin network (the mean time considered an interesting subject for future research.
to receive a block for a full node is 12.6 s). This time includes Regarding the ordering guarantees, Hyperledger Fabric is the
the transmission time (for inv message, getData message, and only system among the blockchain systems covered in this sur-
delivery), as well as the verification time. The propagation time is vey which supports total-order broadcasting [64] within each
likely to be even shorter for the transactions compared to blocks. communication channel. This guarantee ensures that different en-
In Ethereum, a miner that creates a block or another full dorsers and orderers receive transactions from each given client
node that receives a new block from the network use the same ordered in the same way relatively to the transactions from other
propagation protocol. Namely, the full node considers a set√S of clients. The relative order of transactions is important because of
its neighbors and picks a random subset S ′ ⊂ S of size |S ′ | = |S |. the effects that the transactions may have on each other.
Then, the full node forwards the entire block to full nodes in S ′ To support privacy and security guarantees, transferred trans-
while only sending a hash of the block to full nodes in S \S ′ . The actions between the Ethereum nodes are encrypted and authen-
neighbors receiving the hash of a new block request the block ticated [65], which makes the Ethereum communication layer
header via a GetHeader message [60] from either the sender or more secure compared to Bitcoin. Furthermore, Whisper [66], a
any of their neighbors that possess the block. Finally, after getting configurable messaging protocol, which can be enabled in propri-
the new block header, the Ethereum full node requests the block etary Ethereum deployments, provides the benefit of hiding the
body in a way similar to requesting the header. location of sender and receiver in the network, if such privacy
15
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

Table 5
Data manipulation layer of different blockchain systems.
Features Bitcoin Ethereum Hyperledger Fabric IOTA
Consensus protocol Chain convergence Chain convergence Configurable consensus DAG convergence using
using longest-chain using GHOST protocol module (Raft is the tip selection algorithm
rule default)
Mining difficulty About 10 min to mine About 12–15 s to mine No mining No mining
a block a block
Throughput (tps) 3–7 About 15 Configuration- About 50
dependent
Mining power Above 99% Below 97% No mining No mining
utilization
Transaction Probabilistic based on Probabilistic based on Deterministic, after Probabilistic based on
confirmation the number of blocks the number of blocks committing on the confirmation
peers confidence
Mitigating DoS attacks PoW PoW + Gas price Permissioned PoW
authentication
Rich search No No SQL-like query No
functionality

requirements arise. Whisper can achieve this benefit by using section is dedicated to the update protocol in the four systems
onion routing and other techniques common in the Tor [67] net- considered. For each system, we also discuss the security and
work. Hyperledger Fabric utilizes the authenticated channels to performance properties. Table 5 shows the differences in the
provide the privacy and security of the network. IOTA has also in- features of the representative blockchain systems in the data
troduced the functionality of issuing and accessing encrypted data manipulation layer.
streams by implementing the Masked Authenticated Messaging Querying the blockchain is conceptually much simpler than
(MAM) protocol [68] as a second layer communication protocol updating it because it does not require coordination across the
to improve the privacy and security of the communication layer. participants in the blockchain network and because the scalability
Geographical proximity between participants in the blockchain and security constraints are not nearly as severe. However, the
network is one of the parameters that have effect on the block differences in blockchain types and stored data (see Section 4.2)
propagation time throughout the network. Measurements in [65] lead to different query models.
indicate that Bitcoin exhibits a higher degree of clustering com- Finally, security plays a very important role in the design of the
pared to Ethereum, i.e., it has many more groups of full nodes that data manipulation layer. Yet, different blockchain systems exhibit
are geographically close to each other. The measurements also differences in the security assumptions and tolerated threats
show that an estimated peer-to-peer latency between Ethereum so that there exist no easily identifiable baseline to compare
full nodes is 26.7% higher on average compared to Bitcoin. The blockchain systems against. For example, the issues of branching
main reason for this higher clustering degree is that many Bit- and concentration of computing power in the hands of a sin-
coin full nodes are running in data centers. This research claims gle participant (or a group of colluding participants) is a major
that 56% of Bitcoin full nodes belong to autonomous systems consideration for Bitcoin and Ethereum. However, it is a non-
that provide dedicated hosting services whilst the percentage for issue for Hyperledger Fabric which does not use PoW and where
the branching is impossible due to the consensus protocol being
Ethereum full nodes is 28%. On the other hand, in permissioned
deterministic. The security model behind IOTA has only been
blockchains such as Hyperledger Fabric, geographical proximity
partially explored and defined. Accordingly, we discuss security
between peers depends on the consortium network topology. To
aspects of each system separately in the context of presenting
the best of our knowledge, geographical proximity between IOTA
the consensus protocol. However, all blockchain systems must
nodes has not been studied yet.
be resilient to denial-of-service (DoS) attacks, which is why we
include a focused discussion comparing the defense mechanisms
4.4. Data manipulation layer
to DoS attacks in all four systems.

Data manipulation in blockchain primarily consists of two 4.4.1. Updating blockchain in Bitcoin
operations: updating the state of the blockchain and querying it. The mechanism of updating the blockchain in Bitcoin has
Since the transactions stored in the blockchain are immutable, been presented in other survey works (see Section 5) and in a
the only update operation allowed is adding a new transaction to textbook [22]. In this section, we provide an extended description
the ledger, which additionally results in performing bookkeep- written in a pedagogical way. While containing limited novelty by
ing needed to keep track of the updated state. While the goal itself, this description serves as a basis for comparison with the
is simple, the update process is quite complex because it re- more novel descriptions of updating the blockchain in the other
quires running a consensus protocol across the participants in the three systems, presented in the later sections.
blockchain network. The blockchain type and even design goals The general flow of updating the blockchain can be found in
vary across the systems, which results in significant variations in Section 3.1. What is especially interesting about the blockchain
the flavor of consensus protocols used [30,69]. This is the reason update solution in open blockchain such as Bitcoin is that it is
why blockchain systems exhibit significant variations in their fully self-moderated: the nodes are fully autonomous. They do
performance and in security assumptions and threats they can not have to follow the complex protocol but do so because they
withstand. Besides, the performance is affected by deployment are given a combination of incentives and protective mechanisms.
characteristics, such as the blockchain network, transaction rate, For example, the consensus protocol is very sensitive to the rate
duration of transaction execution, and the distribution of mining of proposals: too many and the protocol stops to scale; too few
power in systems that use mining. Accordingly, most of this and the system does not make any progress.
16
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

The PoW mechanism prevents the miners from issuing pro-

posals at too high of a rate. The rate is regulated by the complex-
ity of the cryptopuzzle, called mining complexity. Bitcoin adjusts
the mining complexity every 2016 blocks so as to keep the
average interval between consecutive block proposals limited to
10 min. To be precise, every miner in Bitcoin adjusts its own
mining complexity independently based on its local copy of the
chain. However, since the adjustment is based on the height of
a block and not on the data in the chain, every miner performs
the same adjustment after the same block number, which ensures
fairness of mining.
In order to keep the rate up, Bitcoin incentivizes miners to
Fig. 7. Bitcoin chooses the main chain based on the longest chain rule. Any
spend their resources on solving cryptopuzzles. Specifically, it valid block outside the main chain will be ignored and called a stale block.
introduces two incentive mechanisms: (a) a block creation re-
ward that is given to a miner whose block has been successfully
included into the chain, and (b) a transaction inclusion fee that
a transaction creator may voluntarily pay to the miner that in-
resolving conflicts between competing branches [32]. This rule
cludes the transaction into the proposed block. The block creation
stipulates that the longest branch wins and becomes part of the
reward is regulated by Bitcoin similarly to the mining complex-
main chain for building the subsequent block upon. The rationale
ity. It is halved every 210 000 blocks. Taking into account the
for this rule is that the longest chain corresponds to the biggest
average 10 min interval between consecutive blocks, the reward
amount of work on the cryptographic puzzles; by including this
is expected to become zero before 2140. Currently, the block
branch and discarding shorter branches, we are wasting the least
creation reward plays a more important role than a transaction
amount of work. Eventually, the local copies converge to the same
inclusion fee but as the reward gets smaller, the transaction global state.
inclusion fee will start playing an increasingly more important In the example of Fig. 7, Block 3 points to Block 2a as its
role. Every block includes a single transaction assigning block predecessor while ignoring Block 2b. This may happen because
creation reward to the proposer; this is the only mechanism the miner creating Block 3 received 2a before 2b. In this case,
by which Bitcoin injects new funds into circulation. In order to Block 2b is discarded according to the longest chain rule despite
increase the chance of receiving block creation reward, a group being valid and verified. It is called a stale (sometimes called
of miners can organize themselves into a mining pool. Then, all orphan) block [72].
members of the pool work together to mine each block, and the It should be noticed that because the convergence of the local
revenue of mining a block is shared among them. copies is only eventual, this complicates the reasoning about the
In Bitcoin, there is no entity in the system that knows the blockchain state. A full node may attempt to infer information
precise state of the updated global chain. Every full node is trying about the global state based on the local copy, without any
to approximate the updated knowledge of the global chain by consultation with other full nodes. The most common case of
maintaining a local copy of it (ledger and UTXO information as inference is when a full node tries to establish whether a given
explained in Section 4.2); the full node may update the local transaction has been included in the blockchain. The inference
copy upon receiving a new block proposal. As different Bitcoin is correct with a certain probability, which never reaches 100%:
miners may create and propagate different valid block proposals A transaction A may be included in a block and added to the
in parallel, the local ledger copies on different full nodes may local copy, but at a later time, a different branch may become the
temporarily diverge. In the example of Fig. 7, Block 2a and Block longest and win the race, in which case A will not be included
2b are both valid and created in parallel as successors to Block in the chain. However, the more subsequent blocks are added
1. This situation when different blocks are referring to the same to the local copy after the block BA containing A, the longer the
predecessor block is called a fork in the blockchain. In addition to branch in the local copy becomes, which reduces the probability
the accidental fork creation which happens because of concurrent that a competing branch not including BA will become longer yet.
block proposals, there are also intentional forks. Whenever the In Fig. 7, transaction A (TX A) and transaction B (TX B) are included
blockchain protocol is updated (for example when the block size in Block 2a and Block 2b respectively. The inclusion probability
is changed) on a subset of nodes, it can result into two types of of transaction A in the main chain is increased by creating Block
fork: hard and soft. In the hard fork situation, the nodes with 3 upon Block 2a, while, the chance of inclusion in the chain for
updated protocol cannot interoperate with the nodes running the transaction B is reduced since it is not included in the longer
old version of the protocol at all. A hard fork can lead to creation chain. A more precise calculation of probabilities for the finality of
of a new cryptocurrency. For example, Bitcoin Cash [70] has been transaction inclusion can be found, e.g., in [73]. Bitcoin full nodes
created as a hard fork of Bitcoin, and is now completely indepen- use this reasoning to provide a confirmation about the inclusion
dent of Bitcoin. On the other hand, soft forks support backward of transactions: after 6 subsequent blocks are included into the
compatibility. It means that transactions from nodes running the local copy, the full node considers the probability high enough to
old protocol are accepted by the nodes running the new one, send a confirmation to the user. For example, a transaction may
but transactions created by the new protocol addresses are not transfer a fee in bitcoins to a service provider.
accepted by the old nodes. Segregated Witness (SegWit) [71] is However, a malicious miner that owns more than 50% of the
an example of a soft fork. SegWit is created as a protocol upgrade network mining power, may overcome the network by mining,
of Bitcoin to improve block capacity and prevent the transaction producing valid blocks, and building longest chains faster than
malleability (changing a transaction after signing it) problem by the rest of the network. In particular, it gains the ability to
introducing a new transaction structure. tamper with the data and subvert the blockchain. This situation is
In the case of accidental fork creation, the miners have to called a 51% attack. The miner performing the attack can exploit
decide which of the branches will be included in the main chain the situation in different ways, such as ignoring some specific
and which branch will be discarded. In order to reach a consensus transactions or depriving the competing miners from receiving
on the included branch, Bitcoin has the longest chain rule for block creation rewards. It can also define a new policy and impose
17
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

it onto the network. As an example, the exact amount of block reinforces these claims. Even if a selfish mining attack succeeds
creation reward is configurable and subject to an agreed policy. in the short term, it may lower the value of Bitcoin, which further
An attacker will be able to increase the block creation reward in reduces the benefits of the attack compared to honest mining.
hope that the attacker will be mining most blocks and ripping
the benefits of a higher reward. Furthermore, the attacker that 4.4.2. Updating blockchain in Ethereum
owns more than 50% of the network mining power can perform Conceptually, the protocol of updating the blockchain in
a double-spending attack, that is to transfer the same virtual coin Ethereum is similar to that of Bitcoin: Both systems are per-
in two different transactions. For example, an attacker creates one missionless and use mining. Both systems use the same entities
transaction to send some bitcoins to a recipient in exchange for a that play the same roles, e.g., the miners propose new blocks of
service or product. This transaction is included in Block 2b, which transactions. In both systems the full nodes maintain local copies
is appended to the blockchain. Let us denote the predecessor of of the ledger which eventually converge but may temporarily
Block 2b as Block 1 (see Fig. 7). After receiving the service or diverge.
product from the recipient of the transaction, the attacker creates At the same time, the two systems exhibit significant dif-
another transaction that sends the same bitcoins to a different ferences related to the design goals and choices, and deploy-
address of his own. The powerful attacker quickly creates and ment characteristics, as we elaborate below. These differences
mines Block 2a with the new transaction, and then creates and affect both performance metrics (such as transaction throughput,
mines Block 3 as a successor of Block 2a, in order to ensure that transaction confirmation time and chain convergence speed, and
Block 2a is included in the longest branch, and that Block 2b energy consumption) as well as system security and the risk of
becomes stale. As a result, the attacker gets the service or product centralization.
without paying any bitcoins for it. With respect to design goals, Ethereum supports general trans-
The probability of a 51% attack being successful depends on actions written in a Turing-complete programming language.
a number of factors [74], above all those contributing to the This means that the execution of transactions themselves is
presence of forks. The situation illustrated in Fig. 7 is undesirable more resource- and time-consuming in Ethereum compared to
from the security point of view. This is because Block 2b does Bitcoin. This leads to reduced throughput and increased energy
not contribute to securing the main chain so that the attacker consumption. Since executing transactions is unlikely to be as
requires less mining power to subvert the chain. To capture this computationally intensive as solving cryptopuzzles, the effect is
point, [75] has introduced the metric of mining power utilization, likely to be less pronounced compared to that of PoW. However,
which is defined as the ratio between the mining power that it has never been analyzed. Another interesting aspect of Turing-
secures the main chain and the total mining power. Mining power complete transactions is that it becomes absolutely essential to
wasted on work that does not appear on the blockchain accounts limit a block. However, unlike in Bitcoin, it does not make sense to
for the difference. The higher the mining power utilization, the express the limit in bytes because the block size is no longer the
more mining power an attacker must have in order to subvert main limiting factor. Instead, the limit is specified in the amount
the chain. of computation required, which is expressed in the maximum
The argument of mining power utilization is the main reason amount of Ethereum gas consumed. Of course, the limit on the
against reducing the complexity of PoW in Bitcoin. Even though amount of computation also indirectly restricts the length of
such a reduction may improve the throughput of transactions and transactions and their number in a block and thereby, the block
reduce transaction confirmation time (that is the time required size. In September 2019, the average block gas limit was around
for a transaction to reach a certain probability threshold for being 10,000,000 units [80], which translated to the average block size
included in the chain), it will lead to significant forking and of between 20 to 30 kilobytes [81], based on the transaction rate
reduced security [74,76]. and transaction computational requirements in Ethereum at that
The subject of block size is a hotly debated topic in Bitcoin point in time.
where no common view has been reached. Original Bitcoin design Another difference in design goals is that Ethereum supports
by Satoshi Nakamoto has introduced a limit on the maximum more complex state storage (see Section 4.2.1), which results in
block size; this limit still applies. A bigger block size would bigger state storage sizes compared to Bitcoin. While this has an
allow more transactions to be included in the block, thereby impact on most performance metrics, the exact effect has never
improving the throughput of transactions. On the other hand, been scientifically studied.
a bigger block would potentially increase the block propagation Regarding design choices, Ethereum uses a somewhat different
time (see Section 4.3), which may give an advantage to the miner conflict resolution rule and a block reward model, as well as
of the current block who can start mining the next block earlier less complex cryptopuzzles. Besides, a higher number of subse-
before it is disseminated to other miners. This may potentially quent blocks is required for transaction confirmation in Ethereum
increase the centralization in the Bitcoin network. However, the compared to Bitcoin. We now consider these in detail.
exact effect of the latter is very difficult to capture and analyze For conflict resolution, Ethereum is using a modified version of
without deployment, which contributes to the controversy; some Greedy Heaviest Observed Subtree (GHOST) protocol [74] instead
believe that a limit on the block size is artificial and can be relaxed of the longest-chain rule. This fact is mentioned in [82] without
or even eliminated. comparing the original version of the GHOST protocol with the
An attack strategy called selfish mining [77] was proposed version used in Ethereum. We believe that our analysis below
to show that even with less than half of the network’s mining provides the first complete comparison in the literature.
power, misusing of the Bitcoin’s longest chain rule is possible. The The first point of departure in all versions of the GHOST
principal claim of this work is that a selfish mining pool with 1/3 protocol compared to Bitcoin is that the miner producing a block
mining power of the network can still defeat the honest mining is incentivized to reference a limited number of stale blocks,
protocol, and the revenue of a selfish pool rises superlinearly as in addition to the previous block. In Ethereum, the miner can
the pool size grows. However, some researches such as [78,79] specifically reference up to two stale blocks from the header
refute selfish mining strategy’s assumptions and benefits, and of the newly generated block, as shown in Fig. 8. The miner is
claim that there is no advantage for a selfish miner to follow incentivized to do so by increased block creation reward for each
the attack strategy instead of the honest one. Selfish mining has referenced stale block. A stale block that is not included in the
not been observed in the Bitcoin network in practice which main chain but referenced by a main chain’s block is called uncle
18
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

time is shorter compared to Bitcoin’s, Ethereum transactions are

confirmed faster.
Table 6 presents a summary of the discussion in this section,
with a particular emphasis on how each design difference in
Ethereum compared to Bitcoin affects a variety of performance
and security metrics. The comparison is based on the conceptual
differences rather than empirical measurements. For example, the
fact that transactions in Ethereum are Turing-complete programs
may make them much more computationally intensive compared
to simpler transactions in Bitcoin, resulting in worse throughput,
higher energy consumption, and increased confirmation time. It
does not mean, however, that actual Ethereum transactions are
more computationally intensive in practice because the users may
be unwilling to exploit the capabilities provided by Ethereum and
pay the higher gas price of such transactions. The ‘‘unknown’’
Fig. 8. Ethereum chooses the main chain based on the GHOST protocol. Uncle entries signify research gaps: they indicate that it is difficult to
blocks are considered when choosing the main chain (the heaviest chain rule) assess the impact without further analysis and that the volume of
and their miners are rewarded in Ethereum.
studies analyzing the effect of the corresponding design element
on a particular metric is limited.
Finally, the characteristics of the main Ethereum deployment,
or ommer block in Ethereum. In the example of Fig. 8, Blocks 2b namely the Ethereum network, distribution of the mining power
and 2d are uncle blocks for the new block. The uncle block’s miner across the miners, and the rate and computational requirements
is also compensated, so that the miner’s effort of producing the of transactions have a non-trivial impact on the performance
block does not go unrewarded. and security metrics. An empirical study of various metrics in
Secondly, both the original GHOST protocol and the version Ethereum is available in [65]. Such a study can only evaluate the
used in Ethereum consider the uncle blocks and merge the amount actual performance of the system as a whole; it cannot evaluate
of work that has been done for each block in different branches in the effect of each design element separately from the rest of
order to choose the main chain. For example, in Fig. 8, the main the system. This work shows, e.g., that the mining power uti-
chain is chosen based on the GHOST protocol, and the result is lization in Ethereum is 97% compared to 99% in Bitcoin. Besides,
different from the longest chain rule. The algorithm starts from the throughput in Ethereum is 15 transactions per second [86]
Block 0 and at each fork, chooses the block leading to the heaviest compared to 7 transactions per second in Bitcoin [87].
subtree. In the given example, the subtree of Block 1a contains 4
blocks, while the subtree of Block 1b (prior to the inclusion of 4.4.3. Updating blockchain in Hyperledger Fabric
the new block) consists of 5 blocks. Assuming that each block The consensus protocol in Hyperledger Fabric is fundamentally
has the same cryptopuzzle complexity, Block 1b will be chosen. different from those in Bitcoin and Ethereum. First, the entities
According to the same rule, Blocks 2c and 3b are included in the are different as explained in Section 3.3. Second, Fabric provides
main chain. Then, a miner that wants to propose a new block, will the ability to partition a consortium network into independent
choose Block 3b as the predecessor. channels so that each channel can execute a consensus proto-
The original GHOST protocol additionally considers transac- col in parallel and independently of other channels. In a sense,
tions in uncle blocks when computing the blockchain state. This there is a separate ledger maintained for each channel. Besides,
element is not present in Ethereum. only authorized peers can participate in the consensus for each
Since the stale blocks are adding to the weight of the main channel, as determined by the consortium policies and related
chain, forks are less affecting mining power utilization in Ethereum channel configuration. Third, the consensus protocol in Fabric
compared to Bitcoin [83], which makes the main chain more is deterministic unlike Bitcoin and Ethereum where there could
secure and reduces the risk of centralization. As a consequence, temporarily be divergent branches of the ledger that eventu-
Ethereum can afford shorter block creation time, which results in ally and probabilistically converge. In Fabric, there cannot be
a higher number of forks but also better decentralization, trans- divergent branches and the transaction becomes final and 100%
action throughput, and confirmation time [74,76]. Specifically, confirmed relatively fast.
the average time to solve a cryptopuzzle is 12–15 s in Ethereum A different class of consensus protocols leads to a remark-
compared to 10 min in Bitcoin [84]. able contrast in performance characteristics. As discussed in
Regarding the confirmation time, an Ethereum full node con- Sections 4.4.1 and 4.4.2, Bitcoin and Ethereum can achieve throu-
firms inclusion of a transaction after 12 subsequent blocks are ghput of 3–7 and 12–15 transactions per second respectively
included into the local copy of the blockchain [85], in contrast when updating the ledger. On the other hand, [88] has shown that
to 6 blocks in Bitcoin. The probability of a transaction inclusion the throughput in Hyperledger Fabric can reach many thousands
being final has not been analyzed as thoroughly for Ethereum as of transactions per second with specific optimizations in place,
it has been for Bitcoin. However, as the Ethereum’s block creation as we discuss in the later part of this section. While providing

Table 6
How differences from Bitcoin affect various performance and security metrics in Ethereum.
Factor Throughput Confirmation time Energy consumption Decentralization and Mining power utilization
General transactions Worsens Worsens Worsens Worsens
Complex storage Worsens Worsens Worsens Unknown
Considering uncles Unknown Unknown Unknown Improves
Less complex cryptopuzzles Improves Improves Improves Worsens
Deployment characteristics Unknown Unknown Unknown Unknown

19
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

a high transaction rate, the deterministic consensus protocol in validation phase. In other words, the validation phase becomes
Fabric does not scale well w.r.t. the number of peers in any single the bottleneck. Furthermore, when the transaction arrival rate is
channel. At the same time, the probabilistic consensus protocols lower than the saturation threshold, the increase in block size
of Bitcoin and Ethereum can handle the scale of many thousands leads to the increase in the block creation time in the orderer
of full nodes, which is beyond the reach for Fabric [30]. phase which in turn impacts the transaction latency. Additionally,
Ledger update in Fabric is performed in three phases called when the arrival rate is 50 tps, the increase in the block size from
proposal, ordering, and validation [63]. In the proposal phase, 10 to 100 causes transaction latency increase by a factor of five
clients send every transaction proposal to the endorsers (see from 242 ms to 1250 ms. On the other hand, it has also been
Section 3.3), which are responsible for simulating the transaction demonstrated that when the transaction arrival rate is higher
without updating the database. The endorsement policy specifies than the saturation threshold, the increase in block size leads to
which endorsers a transaction is sent to for approval, and how decreased transaction latency and enhanced throughput. This is
many endorsements are needed for a transaction. For example, a due to the fact that the time taken to validate and commit one
policy can specify that m signatures out of n endorsers are enough large block is shorter than the time taken to validate and commit
for a given transaction to proceed to the ordering phase. many small blocks.
During the ordering phase, the orderer service runs a con- Additionally, it is demonstrated in [95] that heterogeneity
sensus protocol and decides on the order in which concurrent in the resources of peers and networks of organizations leads
endorsed transactions will be executed and added to the ledger. to performance degradation. Furthermore, this work shows that
Hyperledger Fabric uses pluggable modules for the ordering ser- increasing the number of channels, using fewer endorsers, and
vice which allows for significant configurability. Currently, the performing bulk read/write operations contribute to better thro-
Raft [63] implementation based on the Raft protocol [89] is the ughput and reduced latency in Fabric.
recommended option due to being easier to set up and manage Moreover, common system optimization techniques are used
compared to the alternatives [63]. However, PBFT [90], Apache in [88] to achieve end-to-end transaction throughput of around
Kafka [91], BFT-SMaRt [92], SBFT [93], and other implementations 20,000 transactions per second. Examples of these techniques
can also be used as the orderer service for Hyperledger Fabric. include separation of concerns (separating metadata from data
The choice of the implementation and specific consensus protocol while creating blocks in the ordering service), using parallelism
may significantly affect the throughput of adding transactions to and caching during the transaction validation, and replacing the
the ledger. database of worldstate with lightweight in-memory data struc-
Additionally, the resilience of the entire ledger update pro- ture such as hashtable. One of the key assumptions in [88] to-
cedure is mainly inherited through the fault-tolerant guarantees wards achieving high throughput is that the incoming transaction
offered by the chosen ordering protocol. The two most popular workload is contention-free. When there is a high contention and
families of protocols for implementing ordering are Paxos and a large number of incoming transactions compete for a small
View-stamped replication [94]. Both protocols tolerate crash fail- set of hot keys in the worldstate, the throughput drops down
ures when the number of faulty processes is below n/2, where n significantly as discussed in [96].
is the total number of participants. To tolerate byzantine failures, The authors of [96] propose changes to the transaction flow
ordering protocols such as BFT-SMaRt [92] or PBFT [90] can be in Hyperledger Fabric to handle both high and low contention
employed [69]. These protocols work when the number of faulty transaction workloads. They show that the achieved transaction
participants is below n/3. throughput (3000 transactions per second) is significantly better
Then, in the validation phase, the orderer service sends the than in Fabric and [88] when the workload exhibits high con-
block containing ordered transactions to the peers, and the peers tention. One of the key design ideas in [96] is to separate the
validate the correctness of transactions. Transactions success- dependent and independent sets of transactions in the block and
fully validated and committed at this stage are never revoked, process both sets concurrently during the validation phase. To
which means that their inclusion into the chain is final and realize this idea, a transaction dependency analyzer is introduced,
deterministic. whose goal is to isolate the transactions that are having overlap
It is interesting to observe that in Bitcoin and Ethereum, the on the keys of their R–W sets with transactions that do not
block proposer (miner) broadcasts the blocks only after verifying have any overlaps. As a consequence, the knowledge regarding
that all transactions in the block are valid. In contrast, the block the subset of transactions that can be processed concurrently is
proposer (orderer) in Fabric does not validate transactions while gained. The dependent transactions are marked invalid in the
the blocks are created in phase two. Transaction validation only R–W set validation and will be re-executed on the latest version
happens at the proposal (first) phase by the endorsers and at of the worldstate. The independent set of transactions that are
the validation (third) phase of the consensus protocol. While marked valid can be successfully committed concurrently.
this makes the protocol susceptible to denial-service of attacks
by polluting the blocks with invalid transactions, the permis- 4.4.4. Updating blockchain in IOTA
sioned access allows Fabric to make an assumption that there While the consensus protocol in IOTA is probabilistic, it is
is no significant incentive for the entities participating in the different from the protocols in Bitcoin and Ethereum in many
consensus protocol to launch a deliberate security attack. The respects. Neither the concept of miner nor the chain of blocks
design decision to offload the transaction validation task from exist in the IOTA network. As it is explained in Section 4.2, IOTA
the block proposer confers performance benefits in terms of utilizes a specially crafted DAG called Tangle instead of a chain of
higher throughput at the cost of ledger potentially storing invalid blocks. In a Tangle, vertices represent bundles (or transactions)
transactions. The study of [95] shows a number of interesting while the edges signify approval of the bundles (see Fig. 9). A
performance characteristics of the Hyperledger Fabric as follows. Tangle starts with a genesis bundle and grows as new bundles
First, there is a saturation point for throughput at around 140 are added. Each new bundle is supposed to validate and approve
transactions per second (tps). When the transaction arrival rate two bundles already included in the Tangle, though there are
reaches the saturation point, the commit latency of blocks is exceptional cases when only one bundle is validated and ap-
increased from 100 ms to tens of seconds. The raise in the latency proved, instead of two. Similar to the ledger in Bitcoin and
is due to the increased number of ordered transactions waiting Ethereum, each node participating in the IOTA network main-
in the queue for the peers to validate their correctness in the tains its own copy of the Tangle and synchronizes it with other
20
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

Fig. 9. Every node has its own copy of the Tangle; copies might be diverging.

nodes; these copies may be temporarily diverging. Fig. 9 illus- the DAG. In such cases, only a single tip is selected and approved
trates a situation where participating nodes 2 and 3 have a by the new bundle. However, such cases are fairly uncommon in
partial knowledge of the Tangle while node 1 possesses combined practice because the deployment involves many nodes and the
knowledge. rate of producing concurrent bundles is high.
In IOTA, every node x that wants to issue a transfer of funds Validation: First, x validates the integrity of every bundle on
has to perform the following sequence of actions: the two selected paths. If any structurally invalid transaction
Bundle creation: x creates a bundle including all input and or bundle is found, it is excluded from the Tangle. Secondly,
output transactions that together constitute the transfer (see x validates that the two paths contain no conflicting bundles
Section 4.2.4). For example, node 1 creates bundle O in Fig. 9. that lead to double-spending. To detect possible double-spending
Weight assignment: x decides on an integer weight w for or prevent spending a larger sum than what is available in an
the bundle. A bigger weight results in a probabilistically faster account, x needs to keep values of all addresses in all the verified
confirmation for the bundle (as we explain below) at the expense bundles on the two selected paths. If any of the values turns nega-
of a more significant computational effort for x. tive, then we know that the paths include conflicting transactions
Cryptopuzzle solution: x needs to solve a cryptopuzzle for but we do not necessarily learn which transactions are conflicting.
each of the bundle’s transactions. The difficulty of the cryptopuz- If the validation fails because of any of the above two issues,
zle is proportional to w selected by x. It is however, significantly the tip selection algorithm is invoked again to find a different
lower compared to Bitcoin and Ethereum because in the latter, pair of tips and paths. Then, the validation is performed for the
the cryptopuzzles regulate proposal creation rate while in IOTA new pair of paths. This happens repeatedly until a valid pair is
they only prevent DoS attacks. found. Some additional optimizations are implemented in case
Tip selection: x selects two tips to approve where the tip is of structurally invalid bundles, which we do not cover in our
a bundle already included in the Tangle but not yet approved by description.
any other bundle. For examples, bundles G, H, I, and N are tips In Fig. 9, no bundle violates structural integrity but bundles
in Fig. 9. To this end, x runs a tip selection algorithm [31] twice, D and D′ are conflicting. In this case, node 1 selects a new pair
once for each tip. We describe the tip selection algorithm in detail of tips as shown in Fig. 10. The new pair of paths passes the
below. In addition to the tip itself, the algorithm selects a path validation so that the algorithm stops.
from the genesis bundle to the tip. Bundle propagation: x propagates the new bundle along with
In exceptional cases, only one tip exists in the local copy of the the id of the two selected tips using the communication layer. In-
DAG maintained by x when x creates a new bundle. For example, terestingly, a proof of neither correct tip selection nor performed
when node 3 created bundle K , only a single tip J was available in validation is supplied in the message. When a node other than
21
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

Fig. 10. Choosing a pair of tips happens repeatedly until a valid pair is found.

x receives the bundle from the communication layer, it performs instance, the cumulative weight of A is equal to the sum of
the cheaper integrity validation for that bundle. However, it does weights of bundles A, C , D, E, F , G, H, I, J, D′ , K , L, M, and N. When
not perform an expensive detection of double-spending nor does the random walks determines the next step from the genesis
it traverse any path from the genesis block to the new bundle. bundle, it will make a probabilistic choice between bundles A and
Monitoring of confirmation and reattachment: The valida- B based on their cumulative weights (of 21 and 23 respectively).
tion and tip selection algorithms include a lot of randomness The random walk stops when it reaches one of the tips.
as we discuss below. Because of this randomness, some bundles Based on the above algorithm, it is clear that choosing a
may get confirmed much faster than the others, while some valid bigger weight for a new bundle increases the probability of that
bundles may in fact be never confirmed and be left behind. In view bundle to be selected by the random walk performed during
of this, x needs to monitor the Tangle for signs of confirmation, the tip selection. This ultimately results in probabilistically faster
which we also discuss below. IOTA introduces the concept of confirmation for a bundle with a large weight.
reattachment: node 1 may create a new bundle in the future that Besides, it is obvious that the cumulative weight of a bun-
specifies the very same transfer as bundle O in the illustration, dle incrementally increases as it is getting approved directly or
and inject this new bundle into the Tangle by performing all the indirectly by new bundles added to the Tangle. As a result, the
above steps. In this case, the new bundle will be conflicting with cumulative weight can be used as a metric for confirming bundle
O so that node 1 should only do it if O is not getting confirmed inclusion in the Tangle, similarly to how the number of subse-
for a long period of time. quently added blocks is used as a metric for confirming block
The tip selection algorithm is essentially a weighted random inclusion in Bitcoin and Ethereum. This is important, e.g., when
walk through the Tangle starting from the genesis bundle and a node decides to reattach the bundle. Notably, heavy bundles
moving towards the tips. At each step, the algorithm proceeds tend to gain the weight faster due to the weighted random walk.
from the current bundle to one of the bundles directly approving In some scenarios, this may lead to situations when a bundle is
the current bundle. The probability of choosing a bundle as next never confirmed, thereby rendering the reattachment mechanism
step is proportional to the cumulative weight of that bundle. The essential. However, as the number of users and transactional rate
cumulative weight of each bundle Y is equal to the own weight in the network increase, the probability and speed of confirming
of Y plus the sum of own weights of all bundles that directly any bundle regardless of its weigh grow.
or indirectly approve Y . Fig. 9 illustrates the cumulative weight Apart from the cumulative weight, there exists another metric
of each bundle (denoted as cw inside the bundles) as calculated in IOTA used for monitoring bundle inclusion. The metric is called
by node 1 (the values for nodes 2 and 3 will be different). For confirmation confidence and denoted cc in Fig. 9. The confirmation
22
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

confidence of a bundle is the percentage of the tips which directly paths from the genesis bundle to O that do not traverse D and
or indirectly approve the bundle. In Fig. 9, if we consider the D′ , in which case O may still be selected. Note that if a conflict
Tangle status on node 1 before O is included, the confirmation between D and D′ is later detected by other nodes, it is impossible
confidence of bundle D is %75. This is because among the four for them to establish whether x deliberately neglected validation
tips of G, H, I, and N, the three tips G, H, and I are approving D or simply was unlucky with detection because x selected non-
while N is not. Note, however, that confirmation confidence is not conflicting paths leading to G and N during its random walk. The
always a good indicator of bundle inclusion if the Tangle copies exact quantification of the reduction in confirmation probability
on different nodes are diverging. For example, the confirmation requires a very complex probabilistic analysis, which has not been
confidence for bundle K is %100 on node 3 but this is only because performed in the literature to the best of our understanding.
node 3 does not know about bundles G, H, and I yet. In the context of tip selection, different tips have different
In terms of Tangle security, several attacks and defenses have probability to be reached by the random walk. If x just arbitrarily
been considered in the literature [21,31]. The replay attack [97,98] selects two tips without performing the random walk, this may
performs double-spending by exploiting the reattachment mech- result in reduced probability for the new bundle to be reached
anism: the reattached bundle normally invalidates the original by the random walk performed by other nodes at a later point.
bundle but in the attack, both bundles remain valid, which re- As a result, x will be punished by a higher confirmation time.
sults in double-spending. The attack only works under reuse of On the other hand, x may minimize the confirmation time for its
addresses, which is within the control of the users and which the bundle by performing a deterministic walk which selects a vertex
users should strive to avoid as per IOTA recommendation. In the with the biggest cumulative weight at each step. Eliminating
parasite chain attack [31,99], the attacker aims to replace the cur- the randomness during the walk may exacerbate the problem
rent Tangle with its own subgraph, which the attacker builds in of heavy vertices gaining weight very fast, resulting in a higher
secret while taking steps to ensure that the secret subgraph will number of reattachments. There exist considerations, however,
have sufficiently high cumulative weights. To perform double- that detract from the benefits of such a selfish node strategy, as
spending, the attacker initiates two conflicting transactions. The outlined in [31].
first transaction is injected into the current Tangle while the The consensus algorithm in IOTA is relatively lightweight and
second transaction is included into the secret subgraph. After scalable in the sense that it can sustain a higher rate of adding
the first transaction is confirmed and the attackers receives the new transactions to the storage and confirming them. This im-
services or benefits for the payment, the attacker broadcasts provement eliminates the need in two design elements present in
all bundles in the secret subgraph, which replaces the Tangle. the other three systems we consider: batching transactions into a
This way the attacker gets the second transaction confirmed as block and having long intervals between consecutive blockchain
well. In the splitting attack [31,100], the attackers partitions the updates. As a result of allowing shorter intervals between up-
Tangle by making sure that two subgraphs within the Tangle dates, PoW is much more lightweight in IOTA compared to Bit-
maintain a similar cumulative weight over time, and injecting coin and even Ethereum. While the typical IOTA throughput has
transactions so as to maintain this balance. Such partitioning been reported as 45–50 transactions per second [102], IOTA has
allows the attacker to perform double-spending by placing two mentioned a throughput of above 500 transactions per second
conflicting transactions, one in each subgraph. achieved under a proprietary stress test [103]. These advantages
The author of [31] proposes the following idea to defend do come at a cost. Since discovery of conflicts is probabilistic, it
against the parasite chain and splitting attacks. The probabilistic may take a lot of time until double-spending is discovered. The
choice of the next step in the random walk is governed by Tangle storage requires more space compared to systems that use
parameter α in addition to the cumulative weights of candidate a chain of blocks, as explained in Section 4.2.2. Most importantly,
vertices. A big value of α means that the vertex with a larger the paths produced by the tip selection algorithm become long
cumulative weight wins with a very high probability while a as the Tangle grows, resulting in a very expensive verification
small value of α means that the winning chance for a heavier procedure.
vertex is only slightly higher. This work shows that a large value To address the challenge of scaling the Tangle and the vali-
of α reduces the risk of successful parasite chain and splitting dation algorithm, IOTA employs a snapshot process that prunes
attacks. Unfortunately, larger values of α increase the probability the transaction history (see Section 4.2.8) and shortens valida-
for a bundle to be left behind and never confirmed [99,101]. tion paths by creating a new snapshot bundle that effectively
In [99], the authors propose a detection mechanism for parasite serves as a new genesis bundle. The snapshot process is periodi-
chains, with the idea of using smaller values of α in a normal cally performed by the IOTA Foundation, which goes against the
situation but adaptively increasing the values if a parasite chain blockchain spirit of eliminating the trust in any single entity or
is detected. A different idea advocated in [101] is to modify the organization. The Coordicide project [104] is focused on removal
tip selection algorithm so as to explicitly search for left-behind of coordination and in particular, the need for a snapshot process.
tips and increase the chance of their selection.
Since the tip selection and validation are nontrivial algorithms 4.4.5. Defense against DoS attacks
in IOTA, it is interesting to consider incentives to perform them DoS attacks in Bitcoin, Ethereum and IOTA are mitigated by
for node x that wants to issue a new bundle. This is especially im- the Proof-of-Work mechanism. As discussed in Section 3.1, a PoW
portant because during the bundle propagation phase, x does not algorithm requires solving cryptographic puzzles for creating new
supply any proof of correct tip selection and validation. However, blocks. If a message with a new block or transaction does not
while a node receiving a bundle from x does not perform a ran- contain a valid solution to a cryptopuzzle, the message is rejected
dom walk with validation immediately, it will do so upon creating without further processing, which makes it easier for the system
its own bundle in the future. If x does not perform the validation to filter out spurious messages.
properly and approves two tips from two traversal paths that However, PoW requires a significant amount of energy [105]
are conflicting, this may also negatively affect the probability of and wasted computation performed by legitimate miners. Proof-
confirmation for the new bundle produced by x. In the illustration of-Stake (PoS) protocols were developed as energy-saving alter-
of Fig. 9, if O approves G and N, then the conflict between D and natives to PoW [106]. Instead of solving a cryptopuzzle as in
D′ may be discovered by a later random walk, which will reduce the PoW, a block creator is selected based on its stakes (the
the probability of O to be selected. However, there are multiple number of digital tokens that it holds) in PoS. As there is no heavy
23
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

computation process in PoS, the block creation time is much hash code (i.e. the key) requires searching multiple keys over the
shorter than in PoW, thereby resulting in a higher transaction disk, which is time-consuming [109].
throughput. In order to prevent DoS, a block proposer needs to Due to these reasons, supporting analytical and complex que-
make a deposit to gain the right to make a proposal. Since the ries (querying based on values other than keys) such as fil-
deposit is locked until the next block is selected, this makes it ter, aggregation, and sorting queries on the blockchain systems
more expensive for the miner to create multiple proposals within require some extra considerations and functional components.
a short period of time. Besides, the deposit can be confiscated for The modularity of Hyperledger Fabric and its focus on highly
malicious behaviors such as performing a DoS attack. configurable proprietary deployments allow for modifying the na-
The Ethereum network has developed the Casper protocol [107] tive implementation. Specifically, replacing the default database
in an attempt to ease the transition from the current PoW proto- module of LevelDB with CouchDB allows for supporting more
col to a pure PoS protocol. Ethereum 2.0 will deploy the Casper complex search semantics in an efficient way [50]. For example,
protocol on top of the existing PoW protocol, prior to switching as CouchDB allows storing data in JSON format, it is possible to
to a pure PoS protocol in future releases. So, while blocks are still query by data values, and not just by keys. The tradeoff, however,
going to be mined via PoW in Ethereum 2.0, every fixed interval is that CouchDB requires more disk space for storing the data
(every 50 blocks [108]) is going to be a PoS checkpoint where the compared to LevelDB.
finality of blocks is assessed by a dynamic committee that votes Research proposals of adding an extra query layer to existing
via a BFT protocol. To join the committee, a validator has to make blockchain systems have also emerged. For example, EtherQL [109]
a deposit to gain a voting right proportional to that deposit. supports a set of analytical queries such as aggregation and top-k
An additional vector of attacks for a user in Ethereum is to queries on top of Ethereum. These proposals, however, have not
inject a computationally- or storage-expensive transaction that been implemented in the actual systems as of 2021.
would consume resources on all of the full nodes in the network. The most common way of solving the issue of rich query
The gas budget concept (see Section 3.2) plays an essential role semantics is designating a subset of data recorders as dedicated
in defending against this attack: the attacker itself would need to query responders (see Section 2.3). In practice, query responders
pay a substantial amount of gas in order to launch the attack. maintain a separate database in addition to the blockchain data,
While IOTA is using PoW as well, the cryptopuzzles in IOTA are which allows them to answer richer queries efficiently. Such
much simpler compared to Bitcoin and Ethereum which leads to designated query responders are used in Bitcoin, Ethereum, and
a higher throughput. The reason for choosing a lower-difficulty IOTA. Blockchain.com [110] and etherscan.io [111] are websites
PoW in IOTA is that IOTA uses PoW just as a spam protec- that allow anyone to search for a specific address, transaction, or
block on Bitcoin and Ethereum databases respectively. However,
tion [104]; whereas, in Bitcoin and Ethereum, PoW is additionally
these sites do not provide more advanced search functionalities
used for controlling the rate of block production. On the other
such as looking for transactions with a specific amount of input.
hand, a separate PoW is required for each transaction in a bundle
Some other services store the blockchain in an SQL database
since a bundle may theoretically contain an unlimited number
and provide the ability to issue general SQL queries. Notably,
of transactions. While the current implementation of IOTA is
BlockchainSQL [112] does it for Bitcoin while Anyblock [113] pro-
utilizing a simple PoW mechanism, the IOTA Coordicide [104]
vides such a service for Ethereum and some other blockchain sys-
project has proposed an adaptive rate control mechanism which
tems. IOTA foundation provides a website (explorer.iota.org [114])
intelligently adjusts the difficulty of the PoW per IOTA node
as an external dedicated service for querying IOTA. This website
based on different factors, such as a number of recently-issued
supports basic search functionalities for the IOTA Tangle based
transactions and reputation of the issuer [104].
on keys, such as searching based on a transaction hash, a bundle
Hyperledger Fabric does not have a single main deployment.
hash, or an IOTA address. As an example, searching for an IOTA
Instead, there is a multitude of proprietary deployments, where
address through this website gives information about the balance
each deployment is partitioned by channels (see Section 4.3).
of the address and all transactions related to that address. thetan-
Besides, the system is permissioned and requires authorization gle.org [115] is another external dedicated service for IOTA, which
for joining each channel. These factors significantly mitigate the provides visualization for a number of specific queries.
risk of DoS attacks. However, such designated query responders pose two major
challenges. First, the exact rich query semantics is up to a specific
4.4.6. Querying blockchain implementation; it is not standardized in any way. Secondly and
In Section 4.2, we describe different data items stored by the most importantly, they do not provide the security, dependability,
data recorders of each blockchain system. Any data stored by and availability guarantees commonly attributed to blockchain
the recorders can in principle be locally queried by them. If a systems. This is because they are managed by individual comput-
data recorder acts as a query responder, it can essentially answer ing devices that are fundamentally untrusted in the blockchain
any queries related to the stored data that are initiated by query paradigm. In particular, query responders can decide on an access
issuers. control policy that is not aligned with the access control policy
However, the fact that the data is stored does not necessarily of a particular permissioned or permissionless blockchain sys-
mean that there exist means to query it efficiently. The func- tem. For example, Anyblock.tools provides different query services
tionality of blockchain systems is different compared to general- based on the paid subscription tier of the users.
purpose databases (see Section 2.1). The native implementation of In summary, query responders serve two purposes: (a) to pro-
most blockchain systems only efficiently supports limited queries vide rich query semantics otherwise unavailable in the blockchain
as simple as retrieving a data item by its hash code. The main system and (b) to provide information to computing devices that
reason for the limited support of queries is the limitations in do not belong to the blockchain network.
the default database implementation of the blockchain systems.
For example, levelDB used in Bitcoin, Ethereum, and Hyperledger 4.5. Contract layer
Fabric as a key–value database supports only querying based
on keys. Another reason is the way of utilizing the database The contract layer allows users of the blockchain system to de-
for storing and accessing data. For example, retrieving values in velop programmatic extensions and install them atop blockchain.
Ethereum requires traversing multiple trie structures (see Fig. 4 Smart contracts are similar to distributed objects in nature. A con-
in Section 4.2.5), and accessing values associated with the queried tract implements a collection of procedures, each of which can be
24
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

Table 7
Contract layer of different blockchain systems.
Features Bitcoin Ethereum Hyperledger Fabric IOTA
Type Scripting system Smart contracts Smart contracts packaged into a No support yet (in
chaincode progress)
Programming language Forth-like Several languages, Solidity as Go, Node.js, Java –
the most popular one
Turing completeness No Yes Yes –
Executing computing devices Full nodes Full nodes Specified by endorsement policy –
Execution language Bitcoin script Ethereum Bytecode Programming language-dependent –
Execution environment Script interpreter Ethereum Virtual Machine Docker container –

invoked remotely and executed as a transaction. A contract may A code written in any of these languages needs to be complied to
additionally invoke transactions implemented by other contracts. Ethereum Bytecode in order to run in the EVM environment.
Features of the different blockchain systems in the contract Hyperledger Fabric also has the concept of smart contracts,
layer are shown in Table 7. As Bitcoin was designed with a specific similar to that of Ethereum. However, related smart contracts
defined application in mind, it does not implement a general- can be grouped together and packaged into a chaincode in Fab-
purpose contract layer. Instead, it uses a simple scripting system ric; While smart contracts are governing transactions, chaincode
for its transactions. Each transaction contains an output and an governs how smart contracts are packaged for deployment [121].
input script [22]. When a transaction executes, its inputs are When a chaincode is instantiated on a channel, an endorsement
verified. Let us assume transaction T1 has an input I, which is an policy is defined for it [121]. Therefore, the endorsement policy
output of transaction T0 . In this case, I is verified by executing the applies to all smart contracts defined within the same chain-
output script of T0 followed by an input script of T1 . By combining code in the context of a channel. In Fabric, unlike Bitcoin and
the input script of the new transaction with the output script Ethereum, transactions and smart contracts are only executed by
of the referenced transaction, a full node can validate that the endorsers (see Sections 4.4.3 and 3.3), which create W-R sets. The
new transaction can redeem the previous transaction output. The other peers validating or applying the transaction only process
reason for concatenating the input and output scripts is that the W-R sets instead of executing the code of the transaction. Cur-
output script specifies the verification procedure, whereas the rently, smart contracts of Fabric can be written in Go, Node.js, and
input script contains cryptographically secure information about Java [122], which are all Turing complete languages. Endorsers
the redeeming node (specifically, the public key and a signature of execute the chaincode and its smart contracts in a Docker con-
that public key), which is used as an input to the verification pro- tainer environment corresponding to the contract programming
cedure. Bitcoin provides a default implementation of an output language [122]. Docker container is an isolated sandbox inside
script (called scriptPubKey) and a default implementation of an the endorser whose purpose is to prevent the chaincode from
input script (called scriptSig). This default implementation tests accessing the endorser’s local environment and resources.
if the hash of the provided public key matches the hash in the The IOTA foundation has stated that smart contracts will not
scriptPubKey, and then checks the signature against the public
be a feature of IOTA core [123]. However, there are some projects
key to finally validate the new transaction. Bitcoin full nodes are
such as Qubic protocol [124] which aim to design a contract layer
responsible for validating the transactions by executing Bitcoin
on top of IOTA Tangle in order to deploy smart contracts and
scripts in their script interpreter environment. The programming
other applications on it.
language of Bitcoin scripts resembles Forth [116]. Similar to Forth,
Bitcoin scripts are stack-based and they use reverse-Polish no-
5. Related work
tation (processed from left to right). Since Bitcoin scripts are
not intended for writing general-purpose applications, they are
not Turing-complete [22]. In particular, the language does not All published surveys on blockchain technology can be cate-
support jumps and loops so that malicious users cannot create gorized as surveys on individual aspects or on blockchain as a
code that would waste the power and computing resources of the whole. For the former survey type, [69,125,126], and [127] con-
Bitcoin network. centrate specifically on the consensus mechanisms of blockchain.
Instead of simple scripts, Ethereum utilizes smart contracts, In [128–130], and [131], the focus is on the security analysis.
which can be used for implementing a variety of decentralized Smart contracts are covered in depth in [132,133]. Data manage-
applications. One of the main differences between the Ethereum ment and analysis of blockchain data are investigated in [134,
smart contracts and Bitcoin scripts is that smart contracts are Tur- 135]. Network layer aspects of permissionless blockchains are
ing complete, which is essential for a general-purpose blockchain addressed in [136]. Surveys of [137–140], and [141] review inte-
platform. When a contract procedure is invoked, it is executed on gration of blockchain with other technology, namely with edge
top of the blockchain platform by Ethereum full nodes, using the computing, machine learning, cloud storage, cloud computing,
Ethereum Virtual Machine (EVM) environment. As discussed in and cloud of things respectively. The works of [142–144], and
the storage layer Section 4.2, a smart contract stores its own data. [145] survey on applying blockchain to various application do-
Remote invocations that update the contract state are executed mains such as IoT, healthcare, and smart cities.
under transactional semantics. In contrast, blockchain surveys of the second type provide a
Currently, the most common and supported language for writ- general exposition of blockchain systems. However, the coverage
ing smart contracts is Solidity [117,118]. What makes this lan- significantly varies across specific surveys. As our paper falls
guage popular is that Solidity is object-oriented and high-level, in this category of blockchain surveys, we explore the related
and it provides a rich support for developing contracts. Solidity surveys of this type in greater detail and compare them with our
has similarities to C++, Python, and JavaScript. LLL (a low-level work in the rest of this section (see Table 8).
Lisp-like language) [119] and Vyper (Python-derived) [120] are The study of [19] has been one of the first surveys on blockch-
other popular alternative languages for writing smart contracts. ains as a whole. However, it is limited to the cryptocurrency use
25
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

Table 8
Comparison with state of the art surveys on blockchains as a whole.
Main analyzed aspects of blockchains Our work [19] [20] [146] [147] [148] [149] [150] [151] [21] [152] [153] [17] [18]

Comparison of alternative definitions ✓1 ✗2 ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗

Roles and entities U3 ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ S4 U

Hardware layer B5 , E6 , B, etc. B, etc. ✗ ✗ B, E, ✗ ✗ ✗ ✗ ✗ ✗ ✗ B9 , E10

H7 , I8 etc.

State tracking B, E, B B ✗ ✗ B, E, ✗ ✗ ✗ I11 , etc. ✗ ✗ B, E, B, E,

Data storage layer H, I etc. etc. H, etc.

Disk B, E, ✗ B ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ H12
H, I
Memory B, E, ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗
H, I
Communication layer B, E, B B ✗ ✗ B, E, ✗ ✗ ✗ ✗ ✗ ✗ B, E, etc. B, E,
H, I etc. H, etc.
Consensus B, E, B B, etc. B, E, B, E, B, E, ✗ B, E, E, H, I, etc. ✗ B, E, B, E, B, E, H,
algorithm H, I etc. etc. etc. etc. etc. H, I, etc. etc. etc.
Data manipulation layer
Quantitative B, E, ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ E, H, ✗ ✗ ✗
performance H, I etc.
comparison
DoS prevention B, E, B, etc. B, etc. ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ E, H ✗ B, E
H, I
Querying B, E, ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗
H, I
Contract layer B, E, B B, etc. B, E E, H, B, E ✗ B, E E, H, ✗ B, E, H, B, E, ✗ B, E,
H, I etc. etc. I, etc. etc. H, etc.

1 ✓: Considered,2 ✗: Not considered,3 U: Universal,4 S: System specific,5 B: Bitcoin,6 E: Ethereum,7 H: Fabric,8 I: IOTA,9 B: Briefly mentioned in Bitcoin,10 E: Briefly mentioned in Ethereum,11 I: Briefly mentioned
in IOTA,12 H: Briefly mentioned in Fabric.

case of blockchain. This work reviews research perspectives and and Ethereum, namely of consensus, transaction model, scalabil-
challenges for Bitcoin and other cryptocurrencies. It focuses on ity limits, scripting language, and the reward incentives. These
Bitcoin and presents transactions (including scripts), the consen- ontologies, however, do not survey alternative term definitions
sus protocol, and the communication network as the main tech- in this turbulent area and do not aim to analyze the differences.
nical components. Incentivizing correct behavior in Bitcoin, tran- In contrast to the other related works that concentrate on
sition towards more powerful and energy-efficient customized Bitcoin as a basis for analyzing blockchain design, [151] focuses
hardware, and security issues of cryptocurrencies are the other on aspects unrelated to cryptocurrency. This paper compares
important aspects covered in [19]. Another technical survey on Ethereum, Hyperledger Fabric, and Corda in terms of participation
Bitcoin and cryptocurrencies [20] is similar to [19] in terms of the of peers, consensus, and smart contracts to show the most suit-
goals. Additionally, it includes a tutorial-style introductory part able use cases for each blockchain system. The only other related
and an in-depth overview of more recent existing literature. survey that is not based on Bitcoin is [21] which provides a
The authors of [146] compare Bitcoin with Ethereum and comprehensive analysis of DAG-based blockchain systems. In this
propose a design taxonomy based on this comparison. Discussion recent survey, consensus over DAGs, performance analysis, and
of the architectural design in [146] is structured by topics of de- transaction models are considered based on over 20 DAG-based
centralization, computation, infrastructural configuration, among systems including IOTA.
others. Based on this discussion, the work evaluates consensus The work of [152] proposes a benchmark framework for eval-
protocols and system performance. Bitcoin scripts and Ethereum uating the performance of a variety of blockchain networks, both
smart contracts are also compared as another principal aspect of
public and private. The authors apply the framework to Ethereum,
blockchain in this paper. Similar to [146,147] is another survey
Hyperledger Fabric, and another private blockchain system and
using Ethereum and Bitcoin as a case study to describe the inner
provide both qualitative and quantitative performance analysis.
workings of blockchain in detail. The survey covers blockchain
Additionally, the authors focus on smart contracts and provide
incentive structures, smart contracts, and scalability issues such
a short survey of other blockchain-related mechanisms without
as transaction throughput and latency. The study of [148] pro-
specifically focusing on individual systems.
vides yet another comparison of Bitcoin with Ethereum which
The comprehensive survey of [153] identifies a list of 40 DLT
considers a number of additional aspects: UTXO and account
characteristics that are fundamental for assessing the suitability
model for tracking the states, different hardware used for mining
in Bitcoin and Ethereum, and the differences in the network layer. of DLT designs for applications on DLT. These characteristics
Similarly to [146,147], consensus protocol and scripting language are grouped into 6 categories. Then, based on the introduced
of Bitcoin and Ethereum are also reviewed in [148]. As another characteristics, [153] proposes 24 trade-offs in the DLT design.
work that compares Bitcoin and Ethereum, [154] introduces a Performance is one of the categories analyzed in this survey. As a
quantitative framework to analyze the security and performance consequence, performance characteristics such as block creation
implications of various consensus and network parameters of interval, block size limit, throughput, etc. are explored for Bit-
PoW blockchains. Impact analysis of parameter choices such as coin, Ethereum, Hyperledger Fabric, IOTA, and other blockchains.
block interval, stale block rate, and average block size on the According to the classification of [153], smart contracts are one
network propagation time and the throughput of PoW blockchain of the characteristics mentioned for the flexibility category; thus,
systems is one of the main contributions in [154]. they are discussed in the context of a trade-off with the other
Lack of formalization and standardization in blockchain tech- DLT characteristics in the survey. In addition to the characteristics
nology has prompted a research on ontologies that aim at explored in [153], consensus mechanisms of Bitcoin, Ethereum,
providing a vocabulary of key blockchain terms. A high-level Hyperledger Fabric, and IOTA are briefly introduced, and DoS
ontology for concepts and definitions without technical details prevention solutions of Ethereum and Hyperledger Fabric are
is proposed in [149]. A more technical ontology is introduced explained.
in [150]. Furthermore, this work provides an overview of a num- Data models, network discovery process, and consensus pro-
ber of blockchain components with the main focus on Bitcoin cess across four blockchain platforms including Bitcoin and
26
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

Ethereum are compared in [17]. This work also briefly considers covers incentive-based attacks. Some of the elements pertain-
actors and roles in each of the systems. The excellent recent ing to the data manipulation layer, such as DoS prevention and
tutorial of [18] touches upon a large number of aspects and state- querying blockchain are covered in much greater detail in our
of-the-art mechanisms related to blockchain, including roles, survey compared to related work. When it comes to performance
entities, data model, communication protocols, consensus mecha- comparison, we contrast quantitative and qualitative findings
nisms, smart contracts, and much more. The tutorial mentions the about each individual system produced by the developers and
implementation of as many as seven systems, including Bitcoin, researchers and attempt to place them in a unifying framework.
Ethereum, and Hyperledger. The main goal of [18] is to provide a Regarding the seventh aspect, i.e., coverage of the contract
very broad picture of the state-of-the-art and answer a number of layer, state-of-the-art mostly considers the scripting language of
important high-level questions, while we provide in-depth design Bitcoin and smart contract languages of Ethereum. In comparison,
comparison of the four systems.
we compare different systems by the contract executing comput-
In Table 8, we explain how our survey differs from the afore-
ing devices, programming vs. execution language, and contract
mentioned studies. The rows of the table correspond to seven
execution environment.
major aspects of blockchain: (1) comparison of alternative def-
initions, (2) taxonomy of roles and entities, (3) coverage of the
hardware layer, (4) coverage of the data storage layer including 6. Conclusions
state tracking, on-disk, and in-memory storage, (5) coverage of
the communication layer, (6) coverage of the data manipulation We have presented a comparative study of Bitcoin, Ethereum,
layer at fine granularity including consensus algorithm, quanti- Hyperledger Fabric, and IOTA. The study is organized by roles
tative performance comparison, DoS prevention, and blockchain of the participants, system entities, as well as system layers
querying, and (7) coverage of the contract layer. The coverage of
in a cross-system blockchain architecture: hardware, storage,
aspects 3 to 7 is shown in the table at the granularity of individual
communication, data manipulation, and contract. We have also
systems we consider in our survey.
discussed the performance of the four systems based on the
The first aspect, i.e, the comparison of alternative blockchain
previously published information. The study has emphasized
definitions, has not been considered in the state-of-the-art sur-
the differences in the design goals and principles between the
veys and is one of the contributions of our work. In Section 2.1
we identify five blockchain definitions used in the literature systems. We hope that the study can be used as educational
and existing blockchain-based systems. The second aspect is a material in courses and tutorials. It is our conjecture that this
comprehensive taxonomy of roles and entities. While there are first cross-system comparison will facilitate similar studies in the
works that consider roles and entities in specific systems, the future, and that such studies will collectively contribute towards
only prior cross-system taxonomy is given in [18] to the best of standardization of the area.
our knowledge. We extend this taxonomy to additional roles and
present the implementation of each system in the light of this Declaration of competing interest
taxonomy. Our analysis of roles and entities, given in Section 2.3,
is universal and applicable to all blockchain systems.
The authors declare that they have no known competing finan-
The third aspect for comparison is coverage of the hardware
layer. While a few related works discuss the mining devices of cial interests or personal relationships that could have appeared
Bitcoin or Ethereum, we compare all four systems in terms of to influence the work reported in this paper.
the limiting resources, cryptopuzzle solving device, etc. We also
consider how additional hardware is used for security. Data availability
Fourth, we provide a comprehensive coverage of the data
storage layer in Section 4.2 including state tracking, on-disk and
No data was used for the research described in the article.
in-memory storage. While other surveys have considered the
storage in Bitcoin, in-depth understanding of the storage in Eth-
ereum, Hyperledger Fabric, and IOTA requires reading system Acknowledgments
documentation, blog posts, and even the source code. To the best
of our knowledge, we provide the first in-depth survey coverage This work was supported by the Research Council of Norway
for these systems. through IKTPLUSS Program under Grant 288106 and through
The fifth aspect is coverage of the communication layer. While INTPART Program under Grant 288126. We would like to thank
the basic communication protocol in Bitcoin is explained in a the editor and anonymous reviewers for providing many helpful
few related works, our description in Section 4.3 considers or-
and insightful comments and suggestions towards improving the
dering guarantees, privacy and security, propagation time, initial
manuscript. We are deeply grateful to Robbert van Renesse for
peer discovery, and geographical proximity between network
his continuous support and encouragement to work on this topic
participants in Bitcoin, Ethereum, Hyperledger Fabric, and IOTA.
and for attentively proofreading many of the sections and giving
The sixth aspect of consideration is coverage of the data ma-
valuable feedback. Hein Meling posed questions about the early
nipulation layer. This is possibly the most substantial layer of
blockchain; it is touched upon by almost all the related works versions of this work that contributed to shaping the objectives
but the breadth and depth of coverage varies. Consideration of and structure of the paper. Leander Jehl provided suggestions
the consensus algorithm has received a lot of attention in each for improving the technical descriptions of Ethereum and IOTA.
of the systems, yet cross-system comparisons are rare beyond Several members of the Blockchain Lab at the University of Oslo
the general comparison between permissioned and permission- (Salar Arbabi, Arlindo Da Conceição, Daniel Gerbi Duguma, Thiago
less systems. For example, our survey is the first to provide a Garrent, Andrea Merlina, and Praveensankar Manimaran) pro-
comprehensive comparison between consensus in Bitcoin and vided much appreciated feedback on the manuscript. Finally, we
Ethereum and to contrast the consensus in IOTA with other would like to thank many researchers who encouraged us to con-
systems not based on DAG. In particular, we provide the most tinue working on the manuscript and expressed their potential
complete presentation of the consensus protocol in IOTA that interest in using it as education material in their courses.
27
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

References [29] S. Delgado-Segura, C. Pérez-Solà, J. Herrera-Joancomartí, G. Navarro-

Arribas, J. Borrell, Cryptocurrency networks: A new P2P paradigm, Mob.
[1] Coindesk, State of blockchain- Q4 2017 enterprise blockchain summary, Inf. Syst. (2018) 1–16.
2018, https://s3-us-west-2.amazonaws.com/guizishanren/pdf/Coindesk- [30] M. Vukolić, The quest for scalable blockchain fabric: Proof-of-work vs. BFT
201712-State-of-Blockchain-2018.pdf. replication, in: Open Problems in Network Security, Springer International
[2] A. Rana, Is blockchain the solution for healthcare? - dataconomy, 2017, Publishing, 2016, pp. 112–125.
https://dataconomy.com/2017/03/blockchain-solution-healthcare/. [31] S. Popov, The tangle, 2018.
[3] F. Hasse, A. von Perfall, T. Hillebrand, E. Smole, L. Lay, M. Charlet, [32] S. Nakamoto, Bitcoin: A peer-to-peer electronic cash system, Citeseer,
Blockchain–an opportunity for energy producers and consumers, PwC 2008, http://bitcoin.org/bitcoin.pdf.
Glob. Power Util. (2016) 1–45. [33] Endorsement policies, 2020, https://hyperledger-fabric.readthedocs.io/en/
[4] P. Windley, D. Reed, Sovrin: A protocol and token for self-sovereign release-2.0/developapps/endorsementpolicies.html.
identity and decentralized trust, Whitepaper, the Sovrin Foundation, [34] Ethash, 2018, https://github.com/ethereum/wiki/wiki/Ethash.
2018. [35] Why a GPU mines faster than a CPU, 2013, https://en.bitcoin.it/wiki/Why_
[5] M.M. Lab, What we learned from designing an academic certificates a_GPU_mines_faster_than_a_CPU.
system on the blockchain, 2016, Medium https://medium.com/mit- [36] M. Alshaikhli, T. Elfouly, O. Elharrouss, A. Mohamed, N. Ottakath, Evolu-
media-lab/what-we-learned-from-designing-an-academic-certificates- tion of Internet of Things from blockchain to IOTA: A survey, IEEE Access
system-on-the-blockchain-34ba5874f196. 10 (2021) 844–866.
[6] CoreLedger, Land registry on blockchain, 2020, Medium https://medium. [37] Jinn, 2023, https://iotanodes.org/jinn/. (last Accessed on Jul 2023).
com/coreledger/land-registry-on-blockchain-a0da4dd25ea6. [38] Proof of scarcity and Sybil attacks, 2018, Hello IOTA. https://helloiota.
[7] Blockchain for supply chain - IBM blockchain 2021, 2021, https://www. com/proof-of-scarcity-and-sybil-attacks/.
ibm.com/blockchain/industries/supply-chain. [39] J. Lind, O. Naor, I. Eyal, F. Kelbert, E.G. Sirer, P. Pietzuch, Teechain: A
[8] M. Gray, Ethereum blockchain as a service now on Azure, 2015, secure payment network with asynchronous blockchain access, in: Pro-
https://azure.microsoft.com/en-us/blog/ethereum-blockchain-as-a- ceedings of the 27th ACM Symposium on Operating Systems Principles,
service-now-on-azure/. 2019, pp. 63–79.
[9] P. Rizzo, IBM goes big on blockchain unveiling services suite and strategy, [40] F. McKeen, I. Alexandrovich, A. Berenzon, C.V. Rozas, H. Shafi, V.
2016, CoinDesk https://www.coindesk.com/ibm-goes-big-on-blockchain- Shanbhogue, U.R. Savagaonkar, Innovative instructions and software
unveiling-ambitious-new-service-offerings-and-strategy. model for isolated execution, in: Hasp@ isca, Vol. 10, 2013.
[10] The diem association, 2023, https://www.diem.com/en-us/. (last Accessed [41] E. Androulaki, A. Barger, V. Bortnikov, et al., Hyperledger fabric: A dis-
on Jul 2023). tributed operating system for permissioned blockchains, in: Proceedings
[11] R. Wattenhofer, The Science of the Blockchain, Inverted Forest Publishing, of the 13th EuroSys Conference, 2018, pp. 1–15.
2016. [42] IOTA reference implementation, 2020, https://github.com/iotaledger/iri.
[12] M. Huillet, Dutch ministry develops national blockchain research agenda, [43] Transaction - bitcoin wiki, 2023, https://en.bitcoin.it/wiki/Transaction.
2018, Cointelegraph https://cointelegraph.com/news/dutch-ministry- (last Accessed on Jul 2023).
develops-national-blockchain-research-agenda. [44] Python Implementation of the Ethereum protocol_2023, ethereum,
[13] Blockchain partnership | shaping Europe’s digital future, 2023, https:// 2023, https://github.com/ethereum/py-evm/blob/1af151ab218b905f4fdf7
digital-strategy.ec.europa.eu/en/policies/blockchain-partnership. (last Ac- a285cbe14ebf094a7c4/eth/rlp/transactions.py.
cessed on Jul 2023). [45] H. Mayer, ECDSA security in bitcoin and ethereum: A research survey,
[14] European Blockchain Services Infrastructure (EBSI), CEF Digital, 2023, CoinFaabrik 28 (126) (2016) 50.
https://ec.europa.eu/digital-building-blocks/wikis/display/EBSI/Home. [46] Hyperledger fabric block file manager, 2023, https://github.com/
(last Accessed on Jul 2023). hyperledger/fabric/blob/main/common/ledger/blkstorage/blockfile_mgr.
[15] P. Zhou, Y. Du, B. Li, et al., China blockchain technology and application go. (last Accessed on Jul 2023).
development white paper, in: Ministry of Industry and Information [47] Bitcoin core 0.11 (ch 2): Data storage - bitcoin wiki, 2020, https://en.
Technology of the People’s Republic of China, Ed. China Blockchain bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):_Data_Storage.
Technology and Application, 2016. [48] GitHub fabric storage source code, 2023, https://github.com/hyperledger/
[16] M. Stone, The tiny European country that became a global leader fabric/blob/86f87ebcd8a1819e3832b289f2d94d4a88bb6e05/common/
in digital government, 2016, Forbes https://www.forbes.com/sites/ ledger/blkstorage/fsblkstorage/blockindex.go. (last Accessed on Jul 2023).
delltechnologies/2016/06/14/the-tiny-european-country-that-became-a- [49] S. Delgado-Segura, C. Pérez-Sola, G. Navarro-Arribas, J. Herrera-
global-leader-in-digital-government/. Joancomartí, Analysis of the bitcoin utxo set, in: International Conference
[17] A. Ellervee, R. Matulevicius, N. Mayer, A comprehensive reference model on Financial Cryptography and Data Security, Springer, 2018, pp. 78–91.
for blockchain-based distributed ledger technology, in: ER Forum/Demos, [50] CouchDB as the state database – hyperledger-fabricdocs master doc-
2017, pp. 306–319. umentation, 2023, https://hyperledger-fabric.readthedocs.io/en/release-2.
[18] M. Belotti, N. Božić, G. Pujolle, S. Secci, A vademecum on blockchain 0/couchdb_as_state_database.html. (last Accessed on Jul 2023).
technologies: When, which, and how, IEEE Commun. Surv. Tutor. 21 (4) [51] B. Prahalad, Merkle proofs explained, 2018, Crypto-0-nite, https://
(2019) 3796–3838. medium.com/crypto-0-nite/merkle-proofs-explained-6dd429623dc5.
[19] J. Bonneau, A. Miller, J. Clark, A. Narayanan, J.A. Kroll, E.W. Felten, Sok: [52] V. Buterin, State tree pruning, 2015, https://ethereum.github.io/blog/
Research perspectives and challenges for bitcoin and cryptocurrencies, in: 2015/06/26/state-tree-pruning/.
2015 IEEE Symposium on Security and Privacy, IEEE, 2015, pp. 104–121. [53] Jamesob, Coins: allow Flush without cache drop, Bitcoin Core PR Review
[20] F. Tschorsch, B. Scheuermann, Bitcoin and beyond: A technical survey on Club, 2020, https://bitcoincore.reviews/17487.
decentralized digital currencies, IEEE Commun. Surv. Tutor. 18 (3) (2016) [54] What’s new in Hyperledger Fabric v2.x – hyperledger-fabricdocs mas-
2084–2123. ter documentation, 2023, https://hyperledger-fabric.readthedocs.io/en/
[21] Q. Wang, J. Yu, S. Chen, Y. Xiang, SoK: Diving into DAG-based blockchain release-2.2/whatsnew.html. (last Accessed on Jul 2023).
systems, 2020. [55] Tangle-accelerator, DLTcollab, 2021, https://github.com/DLTcollab/tangle-
[22] A. Narayanan, J. Bonneau, E. Felten, A. Miller, S. Goldfeder, Bitcoin and accelerator.
cryptocurrency technologies: A comprehensive introduction, Princeton [56] R. Rottmann, IOTA snapshot, 2019, https://iota-news.com/iota-snapshot/.
University Press, 2016. [57] A. Gervais, S. Capkun, G.O. Karame, D. Gruber, On the privacy provisions
[23] R. Browne, A Little-Known Digital Currency Surges 90% After Teaming Up of bloom filters in lightweight bitcoin clients, in: Proceedings of the 30th
with Firms Like Microsoft, CNBC, 2017, https://www.cnbc.com/2017/12/ Annual Computer Security Applications Conference, 2014, pp. 326–335.
04/cryptocurrency-iota-rallies-after-launch-of-data-marketplace.html. [58] Bitcoin wiki, 2023, https://en.bitcoin.it/wiki/Protocol_documentation. (last
[24] B. McElrath, Braiding the blockchain, in: Presentation at Scaling Accessed on Jul 2023).
Bitcoin Hong Kong (7 December 2015), 2015, https://scalingbitcoin.org/ [59] C. Decker, R. Wattenhofer, Information propagation in the bitcoin
hongkong2015/presentations/DAY2/2_breaking_the_chain_1_mcelrath. network, in: IEEE P2P Proceedings, 2013, pp. 1–10.
pdf. [60] T. Wang, C. Zhao, Q. Yang, S. Zhang, S.C. Liew, Ethna: Analyzing the
[25] M. Hearn, R.G. Brown, Corda: A distributed ledger, Corda Technical White underlying peer-to-peer network of ethereum blockchain, IEEE Trans.
Paper, 2019. Netw. Sci. Eng. 8 (3) (2021) 2131–2146.
[26] Chainlink, Smart contract platforms, 2023, Chainlink Blog, https://blog. [61] P. Silva, D. Vavricka, J. Barreto, M. Matos, Impact of geo-distribution and
chain.link/smart-contract-platforms/. mining pools on blockchains: A study of ethereum, in: 2020 50th Annual
[27] The reality of blockchain, 2019, Gartner, https://www.gartner.com/ IEEE/IFIP International Conference on Dependable Systems and Networks,
smarterwithgartner/the-reality-of-blockchain. DSN, IEEE, 2020, pp. 245–252.
[28] D. Canellis, Bitcoin has nearly 100,000 nodes, but over 50% run vul- [62] Gossip data dissemination protocol – hyperledger-fabricdocs master doc-
nerable code, 2019, https://thenextweb.com/news/bitcoin-100000-nodes- umentation, 2023, https://hyperledger-fabric.readthedocs.io/en/release-2.
vulnerable-cryptocurrency. 0/gossip.html. (last Accessed on Jul 2023).

28
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

[63] The ordering service – hyperledger-fabricdocs master documentation, [94] R. van Renesse, N. Schiper, F.B. Schneider, Vive la différence: Paxos vs.
2023, https://hyperledger-fabric.readthedocs.io/en/release-2.0/orderer/ viewstamped replication vs. zab, IEEE Trans. Dependable Secure Comput.
ordering_service.html. (last Accessed on Jul 2023). 12 (4) (2014) 472–484.
[64] Architecture explained – hyperledger-fabricdocs master documentation, [95] P. Thakkar, S. Nathan, B. Viswanathan, Performance benchmarking and
2023, https://hyperledger-fabric.readthedocs.io/en/release-1.3/arch-deep- optimizing hyperledger fabric blockchain platform, in: MASCOTS, IEEE,
dive.html. (last Accessed on Jul 2023). 2018, pp. 264–276.
[65] A.E. Gencer, S. Basu, I. Eyal, R. van Renesse, E.G. Sirer, Decentralization in [96] C. Gorenflo, L. Golab, S. Keshav, XOX fabric: A hybrid approach
bitcoin and ethereum networks, in: International Conference on Financial to blockchain transaction execution, in: International Conference on
Cryptography and Data Security, 2018, pp. 439–457. Blockchain and Cryptocurrency, ICBC, IEEE, 2020, pp. 1–9.
[66] Whisper - ethereum wiki, 2023, GitHub, https://github.com/ethereum/ [97] P. Ryszkiewicz, 2023, GitHub https://github.com/pRizz/iota-transaction-
wiki/wiki/Whisper. (last Accessed on Jul 2023). spammer-webapp. (last Accessed on Jul 2023).
[67] P. Syverson, R. Dingledine, N. Mathewson, Tor: The second generation [98] G. De Roode, I. Ullah, P.J. Havinga, How to break IOTA heart by replay-
onion router, in: Usenix Security, 2004. ing? in: 2018 IEEE Globecom Workshops, GC Wkshps, IEEE, 2018, pp.
[68] I. Latino, MAM protocol: Alternative messaging thanks to the IOTA 1–7.
platform, 2018, Medium, https://medium.com/iotalatinoamerica/ [99] A. Penzkofer, B. Kusmierz, A. Capossele, W. Sanders, O. Saa, Parasite chain
mam-protocol-alternative-messaging-thanks-to-the-iota-platform- detection in the IOTA protocol, 2020, arXiv preprint arXiv:2004.13409.
f92a5ef92ebe. [100] B. Kusmierz, A. Gal, Probability of being left behind and probability of
[69] C. Cachin, M. Vukolić, Blockchain consensus protocols in the wild, 2017. becoming permanent tip in the Tangle v0. 2, IOTA Foundation, 2018.
[70] Bitcoin cash, 2023, https://www.bitcoincash.org/. (last Accessed on Jul [101] G. Bu, Ö. Gürcan, M. Potop-Butucaru, G-IOTA: Fair and confidence
2023). aware tangle, in: IEEE INFOCOM 2019-IEEE Conference on Com-
[71] E. Lombrozo, J. Lau, P. Wuille, Segregated witness (consensus layer), 2015, puter Communications Workshops, INFOCOM WKSHPS, IEEE, 2019,
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki. pp. 644–649.
[72] Orphan block, 2023, https://en.bitcoin.it/wiki/Orphan_Block. (last Ac- [102] In tangle we trust - 10 amazing facts about IOTA, 2017, Steemit,
cessed on Jul 2023). https://steemit.com/iota/@steemhoops99/in-tangle-we-trust-10-
[73] Y. Kawase, S. Kasahara, Priority queueing analysis of transaction- amazing-facts-about-iota-1000000-token-giveaway-faucet.
confirmation time for bitcoin, J. Ind. Manag. Optim. 16 (3) (2020) [103] A primer on IOTA (with presentation), 2017, IOTA Foundation Blog,
1077. http://blog.iota.org/a-primer-on-iota-with-presentation-e0a6eb2cc621.
[104] I.F. Coordicide Team, The coordicide, 2019.
[74] Y. Sompolinsky, A. Zohar, Secure high-rate transaction processing in
bitcoin, in: International Conference on Financial Cryptography and Data [105] A. De Vries, Bitcoin’s growing energy problem, Joule 2 (5) (2018) 801–805.
Security, Springer, 2015, pp. 507–527. [106] C.T. Nguyen, D.T. Hoang, D.N. Nguyen, D. Niyato, H.T. Nguyen, E.
Dutkiewicz, Proof-of-stake consensus mechanisms for future blockchain
[75] I. Eyal, A.E. Gencer, E.G. Sirer, R. van Renesse, Bitcoin-ng: A scal-
networks: Fundamentals, applications and opportunities, 7, IEEE, 2019,
able blockchain protocol, in: 13th {USENIX } Symposium on Networked
[107] V. Buterin, V. Griffith, Casper the friendly finality gadget, 2019, arXiv
Systems Design and Implementation ({NSDI } 16), 2016, pp. 45–59.
preprint arXiv:1710.09437v4.
[76] V. Bagaria, S. Kannan, D. Tse, G. Fanti, P. Viswanath, Prism: Deconstructing
[108] V. Buterin, D. Reijsbergen, S. Leonardos, G. Piliouras, Incentives
the blockchain to approach physical limits, in: Proceedings of the 2019
in ethereum?s hybrid casper protocol, in: 2019 IEEE International
ACM SIGSAC Conference on CCS, 2019, pp. 585–602.
Conference on Blockchain and Cryptocurrency, ICBC, IEEE, 2019,
[77] I. Eyal, E.G. Sirer, Majority is not enough: Bitcoin mining is vulnerable,
pp. 236–244.
Commun. ACM 61 (7) (2018) 95–102.
[109] Y. Li, K. Zheng, Y. Yan, Q. Liu, X. Zhou, EtherQL: A query layer for
[78] C.S. Wright, S. Savanah, The fallacy of the selfish miner in bitcoin: An eco-
blockchain system, in: International Conference on Database Systems for
nomic critique, 2017, https://papers.ssrn.com/sol3/papers.cfm?abstract_
Advanced Applications, Springer, 2017, pp. 556–567.
id=3009466.
[110] Blockchain.com explorer, 2023, https://www.blockchain.com/explorer.
[79] Marlow, Why Selfish miners do not exist and never will, 2018, Medium,
(last Accessed on Jul 2023).
https://medium.com/ProfFaustus/why-selfish-miners-do-not-exist-and-
[111] Ethereum (ETH) blockchain explorer, 2023, Ethereum (ETH) Blockchain
never-will-6d68b5ad571c.
Explorer, http://etherscan.io/. (last Accessed on Jul 2023).
[80] E. Conner, Understanding ethereum gas, blocks and the fee market, 2019,
[112] Bitcoin blockchain SQL query, 2023, http://blockchainsql.io/. (last
Medium, https://medium.com/eric.conner/understanding-ethereum-gas-
Accessed on Jul 2023).
blocks-and-the-fee-market-d5e268bf0a0e.
[113] Anyblock analytics GmbH, 2023, https://github.com/anyblockanalytics.
[81] Ethereum block size chart, 2023, BitInfoCharts, https://bitinfocharts.com/
(last Accessed on Jul 2023).
comparison/ethereum-size.html. (last Accessed on Jul 2023).
[114] IOTA tangle explorer, 2023, https://explorer.iota.org/mainnet. (last
[82] V. Buterin, Ethereum: A next-generation smart contract and decentralized Accessed on Jul 2023).
application platform, 2014, https://ethereum.org/en/whitepaper. [115] IOTA tangle explorer and statistics, 2023, https://thetangle.org/. (last
[83] V. Buterin, EIP 100: Change difficulty adjustment to target mean block Accessed on Jul 2023).
time including uncles, 2016, Ethereum Improvement Proposals, https: [116] L. Brodie, C. Forth Inc, Starting Forth, Prentice-Hall, Inc., 1987.
//eips.ethereum.org/EIPS/eip-100. [117] Y. Hirai, Programming languages that compile into EVM, 2017, Ethereum
[84] V. Gramoli, From blockchain consensus back to byzantine consensus, Wiki, https://eth.wiki/en/concepts/evm/ethereum-virtual-machine-(evm)-
Future Gen. Comput. Syst. (2017) (2017). awesome-list.
[85] I. Weber, V. Gramoli, A. Ponomarev, M. Staples, R. Holz, A.B. Tran, P. [118] Solidity is twice as popular as the next blockchain coding language,
Rimba, On availability for blockchain-based systems, in: 36th Symposium 2019, Medium, https://media.consensys.net/solidity-is-twice-as-popular-
on Reliable Distributed Systems, SRDS, IEEE, 2017, pp. 64–73. as-the-next-blockchain-coding-language-9330af9aeaa3.
[86] A. Hertig, How will ethereum scale?, 2018, https://www.coindesk.com/ [119] LLL introduction, 2023, https://lll-docs.readthedocs.io/en/latest/lll_
information/will-ethereum-scale. introduction.html. (last Accessed on Jul 2023).
[87] K. Croman, C. Decker, I. Eyal, A.E. Gencer, A. Juels, A. Kosba, A. Miller, [120] Vyper documentation, 2023, https://vyper.readthedocs.io/en/latest/. (last
P. Saxena, E. Shi, E.G. Sirer, et al., On scaling decentralized blockchains, Accessed on Jul 2023).
in: International Conference on Financial Cryptography and Data Security, [121] Smart contracts and chaincode – hyperledger-fabricdocs master doc-
2016, pp. 106–125. umentation, 2023, https://hyperledger-fabric.readthedocs.io/en/release-2.
[88] C. Gorenflo, S. Lee, L. Golab, S. Keshav, Fastfabric: Scaling hyperledger 0/smartcontract/smartcontract.html. (last Accessed on Jul 2023).
fabric to 20,000 transactions per second, in: International Conference on [122] Chaincode tutorials – hyperledger-fabricdocs master documentation,
Blockchain and Cryptocurrency, ICBC, IEEE, 2019, pp. 455–463. 2023, https://hyperledger-fabric.readthedocs.io/en/release-2.0/chaincode.
[89] D. Ongaro, J. Ousterhout, In search of an understandable consensus html. (last Accessed on Jul 2023).
algorithm, in: 2014 USENIX ATC, 2014. [123] R. Rottmann, About smart contracts in IOTA, 2018, Medium, https://
[90] M. Castro, B. Liskov, et al., Practical Byzantine fault tolerance, in: OSDI, medium.com/ralf/about-smart-contracts-in-iota-626d2bd3619e.
Vol. 99, no. 1999, 1999, pp. 173–186. [124] IOTA qubic, 2023, https://iota-news.com/about-qubic/. (last Accessed on
[91] N. Garg, Apache Kafka, Packt Publishing Ltd, 2013. Jul 2023).
[92] A. Bessani, J. Sousa, E.E. Alchieri, State machine replication for the masses [125] C. Natoli, J. Yu, V. Gramoli, P. Esteves-Verissimo, Deconstructing
with BFT-SMaRt, in: 2014 44th Annual IEEE/IFIP International Conference blockchains: A comprehensive survey on consensus, membership and
on Dependable Systems and Networks, IEEE, 2014, pp. 355–362. structure, 2019, arXiv preprint arXiv:1908.08316.
[93] G.G. Gueta, I. Abraham, S. Grossman, D. Malkhi, B. Pinkas, M.K. Reiter, D. [126] Y. Xiao, N. Zhang, W. Lou, Y.T. Hou, A survey of distributed consensus
Seredinschi, O. Tamir, A. Tomescu, SBFT: A scalable decentralized trust protocols for blockchain networks, IEEE Commun. Surv. Tutor. 22 (2)
infrastructure for blockchains, 2018, arXiv preprint arXiv:1804.01626. (2020) 1432–1465.

29
M.H. Tabatabaei, R. Vitenberg and N.R. Veeraragavan Computer Science Review 50 (2023) 100575

[127] S. Gupta, J. Hellings, M. Sadoghi, Fault-tolerant distributed transactions [142] L. Lao, Z. Li, S. Hou, B. Xiao, S. Guo, Y. Yang, A survey of IoT applications in
on blockchain, Synth. Lect. Data Manag. 16 (1) (2021) 1–268. blockchain systems: Architecture, consensus, and traffic modeling, ACM
[128] R. Zhang, R. Xue, L. Liu, Security and privacy on blockchain, ACM Comput. Comput. Surv. 53 (1) (2020) 1–32.
Surv. 52 (3) (2019) 1–34. [143] M.S. Ali, M. Vecchio, M. Pincheira, K. Dolui, F. Antonelli, M.H. Rehmani,
[129] T. Salman, M. Zolanvari, A. Erbad, R. Jain, M. Samaka, Security services Applications of blockchains in the Internet of Things: A comprehensive
using blockchains: A state of the art survey, IEEE Commun. Surv. Tutor. survey, IEEE Commun. Surv. Tutor. 21 (2) (2018) 1676–1717.
21 (1) (2018) 858–880. [144] E.J. De Aguiar, B.S. Faiçal, B. Krishnamachari, J. Ueyama, A survey of
[130] M. Saad, J. Spaulding, L. Njilla, C. Kamhoua, S. Shetty, D. Nyang, D. blockchain-based strategies for healthcare, ACM Comput. Surv. 53 (2)
Mohaisen, Exploring the attack surface of blockchain: A comprehensive
(2020) 1–27.
survey, IEEE Commun. Surv. Tutor. 22 (3) (2020) 1977–2008.
[145] J. Xie, H. Tang, T. Huang, F.R. Yu, R. Xie, J. Liu, Y. Liu, A survey
[131] I. Homoliak, S. Venugopalan, D. Reijsbergen, Q. Hum, R. Schumi, P.
of blockchain technology applied to smart cities: Research issues and
Szalachowski, The security reference architecture for blockchains: Toward
challenges, IEEE Commun. Surv. Tutor. 21 (3) (2019) 2794–2830.
a standardized model for studying vulnerabilities, threats, and defenses,
IEEE Commun. Surv. Tutor. 23 (1) (2020) 341–390. [146] X. Xu, I. Weber, M. Staples, L. Zhu, J. Bosch, L. Bass, C. Pautasso, P. Rimba,
[132] M. Bartoletti, L. Pompianu, An empirical analysis of smart contracts: A taxonomy of blockchain-based systems for architecture design, in: 2017
platforms, applications, and design patterns, in: International Conference IEEE International Conference on Software Architecture, ICSA, IEEE, 2017,
on Financial Cryptography and Data Security, Springer, 2017, pp. 494–509. pp. 243–252.
[133] Á.J. Varela-Vaca, A.M.R. Quintero, Smart contract languages: A multivocal [147] J. Kolb, M. AbdelBaky, R.H. Katz, D.E. Culler, Core concepts, challenges,
mapping study, ACM Comput. Surv. 54 (1) (2021) 1–38. and future directions in blockchain: A centralized tutorial, ACM Comput.
[134] J. Eberhardt, S. Tai, On or off the blockchain? Insights on off-chaining Surv. 53 (1) (2020) 1–39.
computation and data, in: European Conference on Service-Oriented and [148] F. Haffke, Technical analysis of established blockchain systems, (Master’s
Cloud Computing, Springer, 2017, pp. 3–15. thesis), TU Munich, 2017.
[135] H.T. Vo, A. Kundu, M.K. Mohania, Research directions in blockchain data [149] J. De Kruijff, H. Weigand, Understanding the blockchain using enterprise
management and analytics, in: EDBT, 2018, pp. 445–448. ontology, in: International Conference on Advanced Information Systems
[136] T. Neudecker, H. Hartenstein, Network layer aspects of permissionless Engineering, Springer, 2017, pp. 29–43.
blockchains, IEEE Commun. Surv. Tutor. 21 (1) (2018) 838–857. [150] P. Tasca, T. Thanabalasingham, C.J. Tessone, Ontology of blockchain
[137] R. Yang, F.R. Yu, P. Si, Z. Yang, Y. Zhang, Integrated blockchain and edge technologies. Principles of identification and classification, 10, 2017,
computing systems: A survey, some research issues and challenges, IEEE [151] M. Valenta, P. Sandner, Comparison of ethereum, hyperledger fabric and
Commun. Surv. Tutor. 21 (2) (2019) 1508–1532.
corda, Vol. 8, Frankfurt School Blockchain Center, 2017.
[138] Y. Liu, F.R. Yu, X. Li, H. Ji, V.C. Leung, Blockchain and machine learning
[152] T.T.A. Dinh, R. Liu, M. Zhang, G. Chen, B.C. Ooi, J. Wang, Untangling
for communications and networking systems, IEEE Commun. Surv. Tutor.
blockchain: A data processing view of blockchain systems, IEEE Trans.
22 (2) (2020) 1392–1431.
Knowl. Data Eng. 30 (7) (2018) 1366–1385.
[139] P. Sharma, R. Jindal, M.D. Borah, Blockchain technology for cloud storage:
A systematic literature review, ACM Comput. Surv. 53 (4) (2020) 1–32. [153] N. Kannengießer, S. Lins, T. Dehling, A. Sunyaev, Trade-offs between
[140] K. Gai, J. Guo, L. Zhu, S. Yu, Blockchain meets cloud computing: A survey, distributed ledger technology characteristics, ACM Comput. Surv. 53 (2)
IEEE Commun. Surv. Tutor. 22 (3) (2020) 2009–2030. (2020) 1–37.
[141] D.C. Nguyen, P.N. Pathirana, M. Ding, A. Seneviratne, Integration of [154] A. Gervais, G.O. Karame, K. Wüst, V. Glykantzis, H. Ritzdorf, S. Capkun,
blockchain and cloud of things: Architecture, applications and challenges, On the security and performance of proof of work blockchains, in:
IEEE Commun. Surv. Tutor. 22 (4) (2020) 2521–2549. Proceedings of the 2016 ACM SIGSAC Conference on CCS, 2016, pp. 3–16.

30