# A Generalised Logical Layered Architecture for Blockchain Technology

Jared Newell*, Quazi Mamun*, Sabih ur Rehman* and Md Zahidul Islam*
*School of Computing, Mathematics and Engineering, Charles Sturt University, Australia

###### Abstract

Precision, validity, reliability, timeliness, availability, and granularity
are the desired characteristics for data and information systems. However due
to the desired trait of data mutability, information systems have inherently
lacked the ability to enforce data integrity without governance. A resolution
to this challenge has emerged in the shape of blockchain architecture, which
ensures immutability of stored information, whilst remaining in an online
state. Blockchain technology achieves this through the serial attachment of
set-sized parcels of data called blocks. Links (liken to a chain) between
these blocks are implemented using a cryptographic seal created using
mathematical functions on the data inside the blocks. Practical
implementations of blockchain vary by different components, concepts, and
terminologies. Researchers proposed various architectural models using
different layers to implement blockchain technologies. In this paper, we
investigated those layered architectures for different use cases. We
identified essential layers and components for a generalised blockchain
architecture. We present a novel three-tiered storage model for the purpose of
logically defining and categorising blockchain as a storage technology. We
envision that this generalised model will be used as a guide when referencing
and building any blockchain storage solution.

_K_ eywords Blockchain $\cdot$ Bitcoin $\cdot$ Internet of Things (IoT)
$\cdot$ Proof of Work (PoW) $\cdot$ Smart Contracts $\cdot$ Ethereum

##  1 Introduction

Throughout the history of civilisation, record keeping has been necessary to
maintain the integrity of transactions and covenants between parties,
governmental structures, and autonomous civilisations [1]. The oldest existing
immutable record storage, known as the cuneiform clay tablets, dates from
around 3500 BC. It contains mostly debt contracts and administrative accounts,
and demonstrates some of the earliest methods for immutable storage. Immutable
storage has continued to function, mostly in the form of paper, until only
recently when there has been a significant decline in its use within society.
With the diminishing cost of digital storage, and expanding capabilities of
geographically distributed ‘cloud’ storage platforms, immutability of
information has become one of the most challenging problems [2]. In addition
to the immutability of data and information, other essential and desirable
qualities of data and information need to be maintained. These include
accuracy or precision, legitimacy or validation, reliability and consistency,
timeliness and relevance, availability or accessibility. Consistency and
integrity of the information are maintained through the use of access control
mechanisms, policies, authorisation by both administrative and technical
controls [3]. In implementing the qualities mentioned above, information
systems have relied on quasi-immutable storage solutions known as offline or
cold storage, in which information is copied at a specific point in time. A
criticism of offline storage is that it lacks the ability to readily audit the
stored information. Moreover, computer storage from its inception has been
unable to maintain integrity without governance, with the possible exception
of punched card storage [4]. The onus of record integrity and accuracy is left
to the custodian of the information at times of conflict which is the main
criticism of read-write computer storage [5]. A solution to this problem is
the blockchain technology. Blockchain is a software technology that uses
traditional online digital media and cryptography to ensure the integrity of
the information being stored. This is done by transforming online digital
storage into a write once, read many (WORM) storage technology, and thus it
introduces immutability for the information being stored on it. Blockchain can
maintain integrity without governance, and this is what makes this online
storage technology unique in its design. However, it lacks a unified
definition of what blockchain is and how it is to be used when including it in
a solution. There are no standards for the core components, generalised
architecture, and associated components of a blockchain. Defining blockchain’s
essential components will help to build a universal classification and can
identify blockchain as an immutable storage technology that introduces the
ability to form compatibility between designs. In doing so, in this paper we
studied different use cases of blockchain, identified the different layered
architectures used in those use cases. We also identified different components
of the blockchains in different use cases. We then associated the essential
components to the identified layers of a generalised blockchain architecture.

Figure 1: The logical layered structure of blockchain implementation.

This paper begins with an investigation of the origins of blockchain and its
supporting technologies in section 2. Section 3 continues with the
identification of the generalised mechanisms behind the workings of a
blockchain. Section 4 examines the functionalities of the blockchain
technology. In section 5, we investigated different architectures used to
implement blockchain for different use cases. In doing so, the use cases were
categorised by industry, field or technology, and we identified the logical
layers used in each group for blockchain implementation. In section 6 we
define and categorise the blockchain technologies using our three-tiered
model, starting with the core blockchain components of the storage layer, and
the associated blockchain components of the organisation layer and the data
type layer. The paper further examines some future considerations related to
the classification of blockchain and the function of the storage layer model
in section 7. Finally, we conclude by highlighting the contributions of the
blockchain storage model to the identification and categorisation of the
blockchain core technologies and its associated technologies to aid in the
architecture of future immutable storage solutions in section 8.

Figure 2: The Bitcoin Blockchain Network - Two clients executing a
transaction.

##  2 The Beginning

The first use case of blockchain technology can be identified as the use case
of a cryptocurrency called Bitcoin. In 2009, Satoshi Nakamoto released a
functional solution for a decentralised digital currency; a suite of software
technologies that included transaction processing and storage replication
protocols, conflict resolution in the network and controls for a new digital
currency [6]. A novel technology called blockchain was included in this suite
of software, presented in the storage layer of figure 1, and was fundamental
to the success of the digital currency or cryptocurrency called Bitcoin.
Satoshi Nakamoto expanded on some of the previous attempts to develop a
digital currency – these included Hashcash, Bit Gold and X-Cash (executable
cash), with some of the previously mentioned being proposed ten years earlier,
in [7], and B-Money only a few months before the release of Bitcoin. Satoshi
Nakamoto’s solution included the currency’s ledger of account, which is
responsible for tracking each piece of cryptocurrency throughout its
lifecycle. This ledger is stored on a blockchain, existing in the organisation
layer in figure 1 and is then distributed, as copies, throughout its network.
The ownership of Bitcoin within the ledger is determined by a private key,
which matches an associated public key on the blockchain, described in [8].
This process is represented by the transaction displayed on the left of figure
2. This keypair is mathematically linked using keypair cryptography, described
in [9], to the owner’s virtual wallet, using elliptic curve cryptography [10].
The wallet exists as a software or hardware solution and produces an address
used to transact. All transactions are valid once they are recorded on the
blockchain.

The Bitcoin blockchain design is described as linking data blocks, with the
data being transaction updates to the ledger. The key attributes of Bitcoins
blockchain are presented in figure 4, located in the storage layer of figure
1. This novel approach to storage formed the first known, practical online
immutable storage technology. Within this architecture, a binary Merkle tree
of hashes, visualised in figure 3, represents all the transactions processed
and included in the data location of the block, presented in figure 4. The
Merkle tree is used to verify that a recorded transaction remains unchanged,
as it is only possible for a single hash to represent a single piece of data
[11]. The root hash at the top of the tree, and other header parameters, is
used to build the mathematical seal. This, in turn, is used in the seal of the
next block in the blockchain, displayed in the lower half of figure 4.

Figure 3: Transaction validation using a binary Merkle tree.

The Bitcoin blockchain routines are executed using a support network of
computers or nodes, which provide the storage for the blockchain, the
replication of the blockchain blocks, and the verification of the ledger –
displayed within the cloud in figure 2. One of the nodes in the network will
add the next block to the chain – this requires generating a sealing hash as a
mathematical proof. This hash must meet specific requirements, controlled by
the adjusting difficulty parameter at the top of figure 4 and because of this,
it takes a significant number of attempts, resources and time to complete.
This process is known as mining in Bitcoin. A visual representation of a block
being added into a Bitcoin blockchain is presented at the bottom of figure 4.
A decentralised Peer-to-Peer (P2P) networking protocol is used for replication
of state changes between the distributed nodes [12] is displayed in figure 2.
All coordination within the distributed, decentralised, transaction network is
maintained with a consensus algorithm. In Bitcoin, it is called Proof-of-Work
(PoW), formalised in [13]. In Bitcoin, the Secure Hash Algorithm 256 is used,
explored in [14], for the Merkle tree, the mathematical seal for each block
[15] and aspects of the ledger’s contents. This hashing function is considered
computationally expensive. In addition, Satoshi Nakamoto designed currency
controls implemented within the software, such as the inability to release
more currency than defined within a set period and to reduce the amount
released after a set interval [16]. These controls are expressed statically in
the Genesis block, the first block in the blockchain and the dynamic
configuration of the average time for block addition, presented in the top of
figure 4. After 11 years of continuous online operation, the Bitcoin
blockchain is the longest-running example of a functional blockchain using
this architecture [17].

It must be highlighted that the terminology used and concepts discussed can be
interchangeable with other blockchain architectures, however, they do not
necessary correlate in their characteristics or application. The blockchain
technology, at the time of writing, remains fundamentally application
specific.

Figure 4: The Bitcoin blockchain – A potential block and its components during
the mining process.

##  3 Generalised Mechanisms Behind Blockchain

In this section we seek to define a generalised description, characteristics
and mechanisms universally adopted throughout blockchain solutions. The
generalised function of blockchain is a method for digital computer storage,
which exists as an additional layer on top of current computer storage
technologies. The blockchain storage method consists of two phases; first, the
blockchain adopts unidirectional cryptogram to store a representation of the
data in the form of a message digest and the original raw data. As mentioned
in [18] and [19], in some implementations of blockchain, the raw data is
stored encrypted for data privacy. Encryption in this process is unrelated to
the underlining blockchain storage core functions, as it is applied to the
data being stored. In the second phase, the blockchain uses a cryptographic
process that produces a proof; a mathematically verifiable calculation that
the block and its associated block directly adjacent have remained unchanged
[17]. Once the first block is established, known as the genesis block, these
two phases are repeated ad infinitum, forming an online, digital, immutable
storage solution in the form of a chain of blocks.

Due to the blocks being serially attached, they are therefore chronologically
ordered. The immutability of the information stored is enforced because any
change in a previously stored block would require the rewrite of each block
after that. Furthermore, this includes calculating each of the associated
proofs and a plausible timestamp, while simultaneously being accepted by the
network participants. Moreover, as the chain increases in block count, the
likelihood of a successful modification reduces [20].

The aforementioned fundamentals of blockchains remain the same. The
generalised mechanism of a blockchain storage technology is confined to the
core component in the storage layer of the three-tier model defined in figure
1. At the storage layer in this figure, individual blocks are segregated in
two parts, first is the data location used for storage and the second is the
header location which contains parameters required for the chaining together
of the blocks. Blockchain implementations have varied with time – best
generalised by the characteristic of a compromise between the rate at which
data can be stored and the complexity in mathematical difficulty required to
link the blocks together, also expressed as the security of the blockchain.

##  4 The Blockchain Layer Model

Blockchain has been identified as a key storage solution within a number of
different fields and associated technology solutions [17] [21]. However,
standadisation of blockchain lacks the clarification, classification and
categorisation of which technologies make up core elements of blockchian
technology and which can be separated as independent technologies attributed
to blockchain technologies. This is especially apparent when reviewing related
works about blockchain, highlighted in section 5 and asserted in [22] and
[23]. It must be noted that attempts have been made, such as in [24], to
define the core blockchain properties, with the need to clarify blockchain
terminology raised in [25]. We analyse existing blockchain models and use
these to compare and present our novel three-tiered storage model, which
uniquely describes blockchain from the aspect of a storage solution, the
solution being a method for immutable online computer storage.

We begin with the identification and comparison of a selection of existing
blockchain models. In [26] and [27] a six-layer model is presented consisting
of data, network, consensus, incentive, contract, and application layer. In
reviewing this model we reflect on what we consider core blockchain components
that are required to build an immutable storage solution and which are not.
From the six-layer model we combine all the components from the data, network
and consensus layers into a single layer called the storage layer, we abstract
this further into core component groups required to build a blockchain
solution, discussed in details in section 6. However, we exclude the incentive
layer of the six-layer model as it is used only in cryptocurrencies or trading
specific blockchain implementations. The authors also acknowledge this as an
optional layer in [26]. In [28] the authors present a five-layer model
excluding the incentive layer. Furthermore, the contract layer of the above
models are not implemented universally in blockchain designs and is therefore
excluded as a core blockchain component. However, we present this as an
associated technology at the data type layer in our model in figure 1.
Finally, the application layer of both the six-layer model and the five-layer
models list industries and generalised applications which make use of the
information stored on the blockchain. In our model we remove this, as a single
blockchain design can satisfy the requirements in more than one industry or
technology solution. In addition we do not consider it contains any core
blockchain component required to function as an immutable storage solution,
but when to use a blockchain. In [29] the authors presents a 3 layer
blockchain model, as per the models above we exclude the application layer,
and smart contracts. We consider the consensus layer included as a core
component at the storage layer of our model, however, there is a number of
blockchain components which have not been considered and is therefore lacking
in adequately presenting all components and considerations of blockchain. In
[30] a reference model is presented with two sections of roles and actors, and
of services and processes. The services and processes section consist of the
blockchain components of transaction, network discovery, consensus and block
generation. Within the services the components are highlighted if it is used
only in permissioned blockchains. Within this model we include all components
associated with block generation at the storage layer of our model. However,
we include the transaction related components as not core blockchain
components but associated blockchain technologies. A transaction is the type
of data being stored and exist within the data section of each block.
Moreover, a transaction becomes immutable once stored on the blockchain but is
not required to create an immutable storage solution, presented in figure 1.
We consider our model not to conflict but to limit the scope of components to
a generalised subset of that which is required to design, reference and build
blockchain.

1 depicts the proposed logical model using three distinct layers. We discuss
the purpose for each layer first with the storage layer. This layer consists
of the core blockchain components required to obtain the immutability of
online digital data storage. The characteristics of the storage layer consist
of properties such as data immutability, chronological order, security,
mathematical proofs and cryptography representing the blockchain as an
immutable data storage technology. With the addition properties of its
supporting network that provide the data write ability for a blockchain: being
a consensus, computer hardware, fault-tolerance, controls, scalability,
centralisation, decentralisation, replication, permission and accessibility.
This writing process is through block addition this is represented by the
mining nodes in the Internet cloud of figure 2.

Second and placed above the storage layer is the organisation layer presented
in figure 1. Its purpose is to decouple the association of the blockchain, as
an immutable storage technology, with the structure or organisation of the
information being stored, and thus forming the relationship between all the
data locations across all blocks in the blockchain. The data location in each
block is presented in figure 1, alongside the block header location, within
the storage layer, with additional detail of the data location in figure 4.
The storage structure in the organisation layer often takes the form of a
transaction ledger – when the blockchain is replicated to more than one node,
this then adopts the name of a distributed ledger.

This model’s last layer is the data type layer, which decouples the data
structures such as a single transaction or smart contract, which is a computer
code stored on the blockchain, presented in figure 1. This layer’s data type
often has a close relationship with the structure used in the organisation
layer. For example, a transaction is often associated with a distributed
ledger. However, transaction types can be customised to fit the application of
the blockchain. In this model, referred to in figure 1, a focus has been
placed on the blockchain core and the associated technologies within the
context of storage. Therefore, it excludes functions such as the execution of
the smart contracts, as this is performed by external compute resources,
documented in [31]. We presented the novel three-tiered layer model that
provides a logical structure that can be used to differentiate technologies
and terminologies that are blockchain-related to categorise, classify and
define blockchain.

##  5 Blockchain Implementation

We combine the use of our blockchain layer model with a limited selection of
reviewed literature, selected from papers where blockchain is used in the
title. The purpose is to evaluate how blockchain is implemented and referenced
in each solution and is then tabulated. This table reflects our three-tiered
layer model from figure 1 with the columns of storage layer, organisation
layer, data type layer presented in table 1, highlighting what each piece of
literature implements the layers. We use this to reinforce the relevance of
our model in defining blockchain. The literature selected is grouped by
industry, field or technology in the following sections.

The Finance industry \- Blockchain’s purpose as a distributed ledger for
cryptocurrencies’ financial transactions has extended into traditional
financial transactions. In [32], blockchain is used as a ledger to represent
financial transactions as tokens. This is to prevent tax fraud by replacing
the current system and removing double claiming of tax refund amounts. The
author lacks specifics on how the blockchain is implemented, however, it can
be inferred that a distributed ledger organisation structure using a smart
contract data type is used to automate the execution of verification tasks in
the solution. In [33], a permissioned blockchain is combined with enterprise
resource planning software. This is to produce a triple-entry accounting
solution by using a ledger organisation structure in addition to the
automation of business processes using a smart contract data type as the
solution.

Energy sector \- [34] review the current use and potential uses of blockchain
to create new markets in energy production and the associated carbon trading.
The distributed ledger data structure is used, incorporating the use of the
data type of smart contracts. The overall solution is to reduce overheads or
expenses by automation of administrative tasks and trading, especially when
the energy market is decentralised and at small scale. In [35], blockchain is
used to the collect of data from smart grids, generally for billing purposes.
A permissioned, parallel, blockchain implementation is constructed, focusing
on the transaction processing rate, and the authentication and privacy of its
transactions.

Literature |  Use Case |  Storage Layer |  Organisation Layer |  Data Type Layer
---|---|---|---|---
[32] | Finance | ✓ | ✓ | ✓
[34] | Energy | ✓ | ✓ | ✓
[36] | Supply Chain | ✓ | ✓ | ✓
[37] | Supply Chain | ✓ | ✓ | ✓
[38] | Supply Chain | ✓ | ✓ | ✓
[39] | Supply Chain | ✓ |  |
[40] | Healthcare | ✓ | ✓ |
[41] | IoT | ✓ |  |
[42] | IoT | ✓ |  |
[43] | IoT | ✓ | ✓ | ✓
[44] | IoT | ✓ |  |
[45] | Vehicle networks | ✓ |  |
[46] | IoT | ✓ | ✓ |
[47] | Supply Chain | ✓ | ✓ | ✓
[48] | IoT | ✓ | ✓ |
[33] | Finance | ✓ | ✓ | ✓
[49] | E-Voting | ✓ | ✓ |
[50] | Private Storage | ✓ | ✓ |
[51] | Process Management | ✓ | ✓ | ✓
[52] | Healthcare | ✓ | ✓ | ✓
[35] | Energy | ✓ |  |

Table 1: Blockchain literature – The identification of which storage layers
were mentioned in each implementation

Global supply chain solutions \- In [36], a blockchain is used to coordinate
global supply chains, and manage risk, supply and demand relating to air
logistics. In [47], a similar solution is presented where the logistics mode
is generalised. The depth of the necessary blockchain implementation is
lacking, however, the data type of smart contracts using the organisation of a
distributed ledger is named. A blockchain is used for the integrity of orders
through its immutability and the analytics of supply chain transactions. In
[37], an agricultural supply chain solution implements a dual blockchain
public and private. The public blockchain serves the same purpose as in [36],
with the private blockchain being used to store confidential data. In [38], a
blockchain for logistics and the supply chain uses improved communication,
through data collaboration between parties, in a traditionally hierarchical
layered relationship. In [39], the supply chain is enhanced with a blockchain
to establish the integrity of electronic hardware, and its supporting
components and services. This design uses a distributed private blockchain,
with an independent storage configuration within each block, that is, it is
not in an organisation of a ledger, but segmented to allow for the
verification of data.

Health industry \- In [40], focuses on the improved management of health
records for both healthcare and biomedical applications, the authors seek to
remove traditional centralised database management systems (DBMS) – the
software that organises data into information through the use of a query
language. In this solution, the desired aspects of blockchain are its lack of
centralised governance for record access and the ability to audit
chronologically and provide immutability for information stored. Also, this
solution highlights the availability and robustness of data stored as
distributed replica copies. It can be inferred that the data is stored via a
transaction within an organisation structure of a ledger. That is each update
to a medical record is a stored with other entries within a block, this being
its data type as presented in figure 1. The complete medical record is to span
multiple blocks as the sum of all the entries within the blockchain. The
purpose of a blockchain in this solution is the availability of health record
information. In [52], a blockchain is used to store an index of information.
This includes a scheme for accessing encrypted health records stored
externally to the blockchain across independent data storage platforms. A
smart contract data structure is used to manage the financial aspects of the
system, such as fees for record access.

Internet of Things (IoT) \- In [41] and [42], the authors used blockchain as
an extension to the IoT and mobile edge devices as a storage solution with the
focus on removing the storage overheads from traditionally low powered
devices. This forms a replicated blockchain state over a distributed network
topology, which incorporates the compute overheads required to maintain the
necessary read-write latency, integrity, security and availability for the IoT
devices’ data storage. Similarly, in [43], the authors demonstrate a solution
to reduce overheads required by IoT devices, especially using the Ethereum
blockchain architecture, which infers the use of the data type smart
contracts. In [46], a blockchain performance comparison is carried out between
a cloud platform blockchain and a private blockchain to determine acceptable
latency for IoT devices. In this solution, a distributed ledger organisation
structure is implemented, however, core blockchain specifics are lacking. In
[44], a blockchain is implemented for authorisation and authentication of IoT
devices in a two-step process, first a public blockchain holds the registered
manufacture ID for an IoT device. In the second step, a private blockchain,
with authorised mining nodes, manages the registration of each device. Both
configurations use a distributed blockchain to store a unique transaction
structure for its data type, related to its role in authorisation and
authentication of an IoT device within the network. Furthermore, in [48], a
similar blockchain solution is implemented for IoT devices, which includes
detail about the use of core blockchain technologies.

Vehicle networks \- In [45], the solution uses two types of blockchains – one
is for a restricted group’s communication and the other for broadcast
messages, where selected vehicles act as mining nodes. These nodes add new
transactions obtained from vehicles within its range. The use of blockchain in
this example is as storage, which accepts a file as the data type this being
presented in figure 1 as a file object. This solution makes use of the
distributed storage replication for improved availability.

E-voting \- In [49], blockchain in e-voting uses a distributed ledger
organisation structure presented in figure 1, with tokens or coins being
issued and later used to cast votes. Technical detail is lacking about the
fundamental breakdown of the technologies used.

Personal data storage \- In [50], the blockchain’s purpose is to store
personal data or ID data in an encrypted state. The blockchain uses a custom
transaction data type for storage within a distributed ledger organisation
structure. The technologies used in the blockchain are discussed, including
the external supporting systems that allow for data exchange.

Business process management \- In [51], a review is done directly relating to
the implementation of blockchain and smart contract data structures, as
presented in figure 1, for the execution of business processes. The general
technical details of blockchain are explored, but the specific implementation
is not discussed.

What can be concluded from the related works reviewed is that each paper
refers to blockchain as a solution to a real world challenge, however, the
identification and classification of blockchain is often lacking. Moreover,
this is highlighted by the difference in the solution characteristics. Table 1
identifies which storage layers (based on figure 1) are discussed in each
blockchain paper. This highlights that the term blockchain always includes
components of the storage layer, with components at the organisation layer and
data type layer being associated and optional technologies for inclusion.
Moreover, blockchain can be defined and identified by the technologies that
make it an immutable storage solution, only within the storage layer, shown in
figure 1.

Figure 5: Blockchain components in the storage layer.

##  6 Blockchain Components

To identify the core blockchain components we introduce an extension to the
storage layer model presented in figure 1, where we move from the design
construction of a blockchain to a logical structure in figure 5. This
structure consist of seven groups of components that make up a blockchain
existing solely at the storage layer. Every blockchain can be defined by which
components are implemented, moreover, these groups generalise the necessary
components to construct a blockchain. As current blockchain solutions remain
application specific, each group contains the components, technologies or
architectural considerations that exist as either a working implementation or
within research articles. In figure 5 is the storage layer components, any
layers above this we consider a blockchain’s associated components,
technologies or architectural considerations, expressed within the
organisation layer and the data type layer, presented in figure 1. In the
following sections we explore each of the seven component groups at the
storage layer of our novel blockchain component model.

###  6.1 The Storage Layer

The storage layer, in figure 5 presents the components that we consider a
blockchain’s core components - a generalised representation of components
found in blockchain implementations. The seven components presented cover the
topics of the blockchain software, the privacy and a varying level of
security, discussed in the participation types in a blockchain, and the
distribution of storage through the replication of the blockchain. We continue
with the components of the controls which manage the blockchain’s function,
the consensus method that coordinates the blockchain’s participation, the
hashing algorithms that give immutability and functionality to the blockchain,
and finally the specific blockchain computer hardware. Each of these
components is explored in the following sections.

####  6.1.1 Software Routines

We begin with the software routines component within the storage layer of our
three-tiered blockchain model, presented in figure 5. Blockchain typically can
be considered a replicated state machine for recording data in an immutable
manner, this is achieved through the use of software installed on each of the
participants computers. To control, operate, and coordinate this replicated
state machine, a collection of algorithms, procedures and technologies layout
the function and design of the blockchain [53]. A programming language needs
to be selected that supports the core components required in the blockchain
design, such as the components for the Bitcoin blockchain, which were
discussed in section 2. As an application suite, the blockchain software
routines, can be broken into server or node components and client components
used to interact with the blockchain and its supporting network. It is this
selection of software with which the blockchain is started, utilised and
maintained during its operation.

Not unique to blockchain is the software development lifecycle (SDLC); this
brings about new challenges regarding centralised or distributed control,
coordination of resources, communication and interaction of blockchain
stakeholders, who all contribute to the successful operation of the blockchain
[54]. This is especially apparent when a challenge arises with a functioning
blockchain or its network. An example of this occurred in 2017 when the
Bitcoin blockchain suffered from design constraints and excessive transaction
processing times. This resulted in the emergence of two solutions, the Bitcoin
Core blockchain and the Bitcoin Cash blockchain. A difference in the
blockchain software development direction caused a schism between the
supporting decentralised developers [55]. On the contrary, a private
blockchain with centralised developers is unlikely to have a similar result.
This is especially true when a centralisation of control and authority is
desirable in a blockchain solution. Blockchain software routines define a
blockchain as storage and the supporting network operations – they are
therefore considered core blockchain components, highlighted in figure 5.

####  6.1.2 Participation

Referencing our three-tiered blockchain model we next consider the
participation component in the storage layer, presented in figure 5.
Blockchain participation can be divided into two main areas, the first is
client participation, that is, who has access to the data on the blockchain.
Access being read access to existing data and write access to queue data for
inclusion in the next block [56]. The second area is the server or node
access, that is, what authentication is required to participate in the
blockchain network for block addition onto the blockchain and the supporting
tasks such as transaction replication. These two roles can be identified in
figure 2, with the clients being the two computers on the left of the figure
conducting a transaction and the server or node being part of a mining pool or
separate mining nodes. However, the role or task is not necessarily limited to
mining.

Blockchain participation requirements are defined as either being a public
blockchain, having no authentication requirements for participation, or a
private blockchain, having client and server participation requiring
authentication. A blockchain can also consist of a variation of authentication
required for the client’s and the server’s participation. This can be for both
the data stored on the blockchain and the functions of the blockchain network
[57]. This is sometimes referred to as a hybrid model and when authentication
is required, this is referred to as a permissioned blockchain. The type of
blockchain generally has a relationship with the consensus methods used,
described in section 6.1.5, as some consensus types are not desirable for the
participation types previously stated, due to the tradeoff between security
and the rate at which blocks can be added [58]. The participation within the
blockchain network and access to the data on the blockchain are considered
core components, shown in figure 5 and a necessary consideration in a
blockchain’s architecture.

####  6.1.3 Distribution

The next component of our storage layer model, presented in 5, is the
distribution and replication of the blockchain throughout its network, and the
computer storage requirement for the blockchain. The blockchain storage
distribution is a consideration that is determined by elements of its
participation in section 6.1.2. Peer-to-peer computer storage replication has
been a popular blockchain storage replication protocol for use with public
blockchain participation over the Internet. This can be broken into two
designs; first, unstructured distribution using methods such as Gossip
protocols, where it is assumed that all known neighbors have a uniform latency
or distance [59]. The second distribution design is structured, with each
neighbor’s network properties, such as latency or distance, being calculated
and used as a network map [60]. This network topology creates efficiencies in
consensus, network usage, replication rate, transaction addition and
transaction verification rate.

In addition to the network topology is the storage requirements of the
blockchain. Some blockchain configurations allow for different purpose nodes
to reduce the storage overheads within the network. This is achieved by
requiring only some of the nodes to retain complete copies of the blockchain.
Private blockchains can benefit by using traditional shared storage
technologies, such as a storage area network utilising low latency
connectivity, such as a fiber channel and low latency local area network [61].
This can eliminate some of the undesirable temporal traits through the
centralisation of a blockchain.

As a universal consideration, distribution requires a set of protocols to
engage in tasks for the acceptance of new blocks, replicating existing blocks,
node name resolution, and replicating transactions between nodes. These
protocols allow for nodes to serve blockchain information and receive
blockchain information [62]. This is defined in the blockchain’s software
routines in section 6.1.1 and is executed based on the participation model
explored in section 6.1.2. This is considered another core component in a
blockchain’s design, displayed in figure 5.

####  6.1.4 Controls

From our three-tiered model we next consider the component in the storage
layer called controls, presented in figure 5, these are used to manage aspects
of a blockchain’s workings. At the time of writing, controls used in a
blockchain remained application specific. One common control used in
blockchains is the implementation of temporal limitations [63]. This type of
control is often implemented within the blockchain’s consensus algorithm
discussed in detail in section 6.1.5. The consensus algorithm PoW has control
parameters adjusted within the header of each block, expressed as the target
difficulty in figure 6. This control functions by adjusting a difficulty value
for the complexity of the proof required, in doing so the blockchain network
maintains an average time of ten minutes between block additions, expressed in
the upper portion of figure 4. The purpose of this is for currency control; by
enforcing a limit to the growth rate of the blockchain, this in turn limits
the amount of Bitcoin cryptocurrency released in a given period. Another
example of a blockchain control, expressed as a temporal limitation, is during
the operation of a blockchain consensus algorithm called Proof-of-Elapsed Time
(PoET), a temporal control is enforced by specialised hardware. This is
designed to invoke a wait in block processing for a defined period [64].

Another example of an application specific blockchain control, which is not a
temporal limitation, is in the Bitcoin blockchain. This is the halving of the
amount of Bitcoin cryptocurrency released every cycle; this cycle being the
addition of every 210 thousand blocks. From first set amount being defined in
the Genesis block of the blockchain, presented in the top section of figure 4,
this cycle has continued to enforce this control. The control is implemented
by the parameter of the Genesis block, and in the software routines, explored
in section 6.1.1, and is expressed in each block of the blockchain.

The controls mentioned above are application specific and are undesirable for
some blockchain implementations, such as collecting votes for a vast
population in a limited period, in [65], or the registration of health
information during an active pandemic. Blockchain controls are unlikely to be
generalised, however, they are a consideration when designing a blockchain
especially regarding the design of the organisation layer and data type layer,
highlighted in figure 1. Blockchain controls exist within the storage layer
and are considered a core blockchain component, presented in figure 5.

Figure 6: The Bitcoin blockchain block header layout.

####  6.1.5 Consensus Methods

From our blockchain layer model we discuss the next component in the storage
layer called consensus, presented in figure 5. The purpose of a consensus
method in a network of nodes is to establish a protocol for the negotiation of
how each node will function to achieve a single task. This is regardless of
the usefulness or willingness of each node to do so [66]. This is commonly
referred to as a Byzantine agreement, which assumes the existence of malicious
or intermittent nodes. Consensus forms coordination of the network nodes.

In a blockchain network, the consensus method is explicitly used to agree on
what blocks are added to a blockchain, and is defined in the building of the
software routines, described in section 6.1.1. When viewed at a high level,
the consensus methods used are selected based on the characteristic of what
blockchain network participation type has been selected, explored in section
6.1.2 and the blockchain method for distribution selected explored in section
6.1.3. A general criteria for blockchain consensus selection is the ability
for the network to grow or scale, such scalability constraints are inherent in
some consensus methods [67].

Blockchain consensus methods are numerous covered in detail in [68] and [67].
An identification, explanation and examination of current consensus methods in
relation to blockchain have been extensively documented. A general overview is
that public blockchain consensus methods, such as PoW, trade speed for
security to function between unverified and unauthenticated network nodes.
Therefore consensus convergence is expected to be delayed. On the contrary, a
consensus method such as a variant of a Byzantine Fault Tolerant (BFT)
algorithm is often used to negotiate orderly block addition and replication,
and trades security for speed. This is often used for nodes in a private
blockchain network, which are authorised and authenticated before their
participation and therefore the consensus convergence is rapid [69] [70]. In
must be noted that Byzantine Fault Tolerance like methods for consensus are
not unique to blockchain and have been in existence prior to blockchain [71].
In the following section will seek a different approach to investigate some
commonly available open frameworks, projects and source code used for
blockchain development, where a traditional block construction is implemented.
We will identify each consensus method and how it functions.

Open Frameworks and Projects – First is the Bitcoin core blockchain project
review, in [72], which uses a PoW consensus method. A significantly more
compute intensive PoW consensus method is used; the work being a solution to a
mathematical puzzle [73]. The consensus method consists of the production of
the proof or block seal. The requirement for the proof in the Bitcoin core
blockchain, in January 2021, resulted in the network producing a little over
$166\times 10^{18}$ attempts to solve the puzzle each second. By using a
spread of ASIC technology from this period, presented in figure 7, it can be
estimated that 4.7 and 26 gigawatts of electricity was required every second
to maintain the blockchain. This energy usage is directly related to the total
capacity of the mining nodes in the network, and therefore this consensus
method is considered energy intensive. However, this is not constant
throughout the operation of the blockchain and is a result of the controls
discussed in section 6.1.4.

For the consensus method of PoW on Bitcoin Core blockchain we look into how
this is implemented. The values which are used to determine a successful block
proof are stored in each block’s header value, displayed in figure 6, and as
parameters in the ’coinbase’ transaction. The first transaction of a block
which is created by the mining nodes governed by software routines discussed
in 6.1.1. Each block is tested by all the nodes receiving the block update by
a calculation of the blocks parameters. An example of an accepted proof is at
the block numbered 632,462, with the truncated proof or hash starting with
‘0000000000000000000a15…’. The number of leading zeros is the result of the
required difficulty expressed in the 4 byte location of the header. This hash
was found using the nonce value of 2,459,281,113. The nounce value is
expressed in both a 4 byte location in the header and in the extraNonce
parameter of the coinbase transaction. The resulting proof or hash is produced
from all the 6 areas of the block header.

PoW is also probabilistic – it is possible that more than one node can locate
a suitable hash, having an equal or greater number of leading zeros. When this
occurs, the nature of the Gossip communication protocol used results in an
imbalance of the updates announcements throughout the network. This results in
one version of the blockchain being longer than the other. The longest version
of the chain takes precedence, which is the version held by greater than 50
percent of the network. The shorter version is labelled a fork in the
blockchain and is ignored. As a result, the block and its transactions are
discarded. Due to this, transaction confirmation is not instant and works on
the principle that the more blocks that are added, the less likely that the
block and the transaction will be discarded [74]. The implementation of PoW
consensus using this method allows for a globally sparse network of an ad-hoc
number of participants.

The second is the Hyperledger project, which consists of a modular approach to
a blockchain implementation [75]. We will look into two solutions within this
project, Indy and Sawtooth and the consensus method applied in each. Indy is a
private blockchain solution that implements a Redundant Byzantine Fault
Tolerance (RBFT) based protocol to reach consensus [76]. It is acknowledged
that a private blockchain configuration is implemented in combination with a
centralised method for access control, and therefore, the trust in a node is
established before its participation. Due to this, a single node is only
required to be selected to create a seal for the block. This results in a
minimal amount of computational power to maintain the blockchain, and allows
for accelerated block addition. In RBFT, an implementation of Byzantine Fault
Tolerance is used to select a primary node for processing the block. This
process is replicated to produce a backup primary node, which is a node that
hasn’t been selected as a primary or backup primary. RBFT can include many
backup primaries, which perform monitoring of the primary to determine if it
has failed. All messages are signed and processed by all nodes, but applied to
the blockchain only by the primary [77]. The backup nodes compare speed and
accuracy to establish trust in the primary. The primary node will seal the
block using the Boneh–Lynn–Shacham signature scheme [78], resulting in a
170-bit seal of all the nodes involved in consensus.

Sawtooth uses a different consensus method, called Proof-of-Elapse-Time (PoET)
consensus [79]. PoET trust is established through the secure execution of the
algorithm within a proprietary environment, using specialised hardware.
Therefore, trust is centralised around the manufacture of the hardware. PoET
requires that each hardware node registers using a key pair, thus forming a
permission blockchain. PoET works by each node in the network calculating a
wait time, which follows a statistical distribution for minimising two
devices’ wait times colliding. A wait time calculation can be used a set
number of times before it has to be recalculated, counting backwards from 25
to 0. Each node waits for its specific time before adding a block to the
blockchain. All nodes do verification in the network before the block is
accepted. The blockchain is statistically analysed to reveal any anomalies
with the participating nodes [64].

The third is Ethereum 2.0 and the Beacon Chain, which implements a Proof-of-
Stake (PoS) consensus model [80]. This method considers that an entity that
has a significant ownership of the cryptocurrency is trusted to participate in
the addition of blocks to the blockchain. This stake is forfeited or
discounted in the event of malicious participation. From the group of
validator nodes, each one providing its stake, one is selected via an
algorithm to carry out the block addition. Each block is signed by the
selected node using a Boneh–Lynn–Shacham signature scheme. Verification of
blocks added is then carried out by the validator group. This group consists
of 128 members called a committee and works on their associated block in a
sub-unit called a shard [81]. This model results in significantly less
computational resources to operate, and removes the incentive for centralised
mining pools within the network, in [82].

The fourth is the Graphene blockchain, which uses a Delegated Proof-of-Stake
(DPoS) consensus model [83]. All aspects of a proof-of-stake consensus are
applied. However, the difference is the removal of the algorithm for the
selection of the validator node. This is replaced with the nodes voting for a
node which is tasked with the addition of the next block. The consensus
modifications improve the speed at which blocks can be processed [84].

The fifth is Ethereum’s mainnet blockchain, which uses a memory intensive PoW
consensus method [85]. This differs from the Bitcoin blockchain consensus in
several ways. The transactions are stored in a ledger, with each block having
a complete state of ledger stored as a Merkel tree, displayed in figure 3.
Ethereum’s mainnet uses a hashing algorithm called Keccak-256, which is a
modified implementation of SHA3-256. Hashes are performed on a random
selection of state and transaction data in the blockchain – because of this,
the whole blockchain needs to be available in memory. The PoW is finding a
nonce value, which produces a hash with the required difficulty specified in
the block header. This approach assists to limit the usefulness of ASIC chips
in the PoW mining process, due to the insufficient memory included in ASIC
chips. Once the block is complete, it is announced to other mining nodes and
verified. The longest blockchain is maintained, with any forks being
discarded, in the event a block solution is found by more than one node [86].

The last is the Exonum blockchain, which uses a Practical Byzantine Fault
Tolerance (PBFT) with some customisation for its consensus model [87]. This
requires the network of nodes to be partially synchronous, as the consensus
steps are processed in rounds and coordinated through the use of application
messages. When a signed message arrives, it is verified and its transaction is
added to a transaction queue. Voting is carried out and accepted if two-thirds
or more of the nodes accept the transactions to be included in the block and
accept the node for processing the block. This selected node is given the
title leader and issued a Proof-of-Lock (PoL), required for block addition,
which serves a similar purpose to a transaction lock in a database. Once the
items have been added to the block, they are then deleted from the transaction
queue. These steps are repeated to form the next block addition cycle.

Generalised Consensus Methods – In the following, other solutions to consensus
within a blockchain network are reviewed. A number of PoS variations exist,
such as Leased Proof-of-Stake (LPoS), in which trust can be leased from an
owner of a cryptocurrency, and Proof-of-Stake Anonymous (PoSA), which has a
focus on obfuscating a transaction’s inputs and outputs. Proof-of-Stake Time
(PoST) is based on how long the cryptocurrency has remained at an account or
wallet address. The consensus model Proof-of-Burn (PoB), in [88], establishes
trust through the owner of the node disposing of cryptocurrency. This works as
surety that the node is honest and that the block and transactions are formed
correctly. The consensus model Proof-of-Importance (PoI) [89], takes into
account the amount of cryptocurrency, how many transactions are carried out
using the associated wallet or account address, and the system’s
configuration. The consensus model Proof-of-Luck (PoL) [90], makes use of a
trusted execution environment or specialised hardware. A chain is processed in
rounds, where communication on the luck factor calculation is taken into
account. Certain values are considered desirable, which result in establishing
a preferred block to be included in the blockchain, other blocks are
discarded. Proof-of-human-work requires that the solution to a computationally
verifiable problem is done by a person [91]. Proof-of-useful-work returns a
prime number value, which can be used in applications outside of the
blockchain consensus method [92].

The threshold relay model consensus method [93], works by using a verifiable
random function to produce a signing token, which is then broadcast to the
network. Each node in the network with its designated role produces a block
using this token. Once the node creates the block, it is returned to another
decentralised process, labelled the notoriety, which receives all the blocks.
A block is selected and broadcast as the next successful block in the chain
through a set of rules. It has to be noted that the consensus methods explored
above do not encompass every known type, but seek to highlight some
differences in blockchain consensus implementations. Consensus methods are
considered core components of a blockchain and are located at the storage
layer, in figure 5.

####  6.1.6 Hashing Algorithms

The next component of our blockchain layer model is the hashing algorithms
exiting in the storage layer, presented in figure 5. Hashing algorithms have
the primary function to form cohesion of the blocks, or linking in a
blockchain. In this section we explore the implementations and hashing
algorithms used in blockchain solutions. A hashing algorithm is a computer
implementation of a hash function and can be generalised to represent data in
a unique encoding scheme [94]. Blockchains make use of cryptographic hashing,
where the encoding of an arbitrary amount of data called a message, not
exceeding the function’s upper bounds, results in a fixed size code called the
message digest. It is considered not possible to reverse this process to
expose the original message [95]. Depending on the blockchain’s
implementation, the selected purpose of a hash function can be broken into the
fundamental requirements for a blockchain. First, a hashing function needs to
be implemented to ensure data contained within a block remains unchanged, by
verifying its hash representation. Second, when a puzzle is used, generally in
PoW, it provides consensus when joining blocks together, explored in section
6.1.5. In both cases, the hash function selected needs to be collision
resistant, that is, only one message is represented by exactly one message-
digest. In addition, different hash functions can be used in one blockchain
implementation. Furthermore, hashing can also be used on the data stored
within each block, which exist at the data type layer in figure 1, such as in
a wallet’s address, which is a message digest of the public key, [96].

Blockchains, being application specific, have selected their hash functions
based on other criteria. One of these criterion is to remove the participants
using ASIC mining, by implementing multiple hash functions in the mining
process. The output of one hash function is passed to the input of another
hash function, in a chain of different hash functions. X11, X12, X13, X14,
X15, X16R, X16S, X17 follow this to include a selection of hashes from Blake,
Blue Midnight With, Cubehash, Djb2, ECHO, Fugue, Grøstl, Hamsi, JH, Keccak,
Loselose, Luffa, SHA2-512, Shabal, Shavite-3, SIMD, Skein, and Whirlpool.
Other implementations have used a similar approach to achieve ASIC mining
resistance, with the preferred method of CPU or GPU mining [97]. The reason
for this exclusion is to decentralise the mining processes by reducing the
cost of hardware outlay for participants, with varying levels of success.
Also, it allows more participation and therefore the more likely adoption of
the blockchain and its application. Another criterion is the hash function’s
performance, such as comparing of the SHA2 family of hash functions 256, 384,
and 512 [98], with blockchain implementations maintaining a preference for
SHA2-256. A comparison of blockchain’s hash function concerning performance is
explored in [99]. The amount of data to be hashed is a consideration for both
the message size limits of the hash function and the estimated time to
calculate a message digest.

Hash functions used in a blockchain are used nearly universally for data
validation. However, some block seals are implemented using a different
technique of signing, which is explored in section 6.1.5. Hashing components
are core to a blockchain solution and therefore exist at the storage layer, in
figure 5.

Figure 7: ASIC evolution for blockchains using SHA-256 hash function from the
year 2014 until 2020. Presenting the watts of electricity required for 1000
hash calculations every second. Ordered from left to right by the nanometer
technology used.

####  6.1.7 Hardware

From our three-tiered layer model we present the last component in the storage
layer labelled hardware, presented in figure 5. Blockchain specific hardware
development has been historically driven by the desire to accelerate the rate
at which a successful hash can be located [100]. However, it must be noted
that not all consensus algorithms and therefore blockchains require
specialised hardware [101]. This is due to being intensive in node memory and
not in node compute cycles. A non-blockchain specific GPU is used to generate
the proof in some implementations. Some blockchain consensus methods make it
advantageous to incorporate parallel processing using application specific
integrated circuits (ASIC), explored in section 6.1.5. ASIC are specially
designed hardware used in the blockchain block addition process, also known as
mining. These ASIC are designed around a particular hashing function,
previously discussed in section 6.1.6. Application specific blockchain
hardware has been generally driven by the incentive of financial reward of the
respective blockchain cryptocurrency. This is best explained using Bitcoin’s
blockchain, specially the PoW consensus using SHA-256 hash function, and its
evolution.

The Bitcoin blockchain’s PoW consensus method has resulted in four main
generations of blockchain mining solutions. As this technology was novel,
block calculations and the search for a successful hash was done with
software. This first generation of blockchain mining node used the computer’s
central processing unit (CPU). This was the most cost-effective way to process
blocks relative to the financial reward. As the interest in the technology
spread, so too did innovation of faster ways to calculate a successful block
hash and the likelihood of receiving the associated financial reward. This
resulted in the second generation of mining, which made use of graphic
processing units (GPU). This resulted in significant improvements to
processing hashes [99]. As these methods became too ineffective and
inefficient in terms of the rate of processing hashes per second, a move to
specifically configured hardware resulted; this being the third generation of
mining using field-programmable gate arrays (FPGA) [102].

FPGAs were used as a decoupled hardware solution. These devices allow the
hardware to be programmed to perform a specific task, such as the routine
required for blockchain mining, and are specially designed for the SHA-256
hash function [103]. The difficulty parameter continued to grow and made this
solution obsolete. This resulted in the fourth and current generation of
mining hardware identified by the use of application specific integrated
circuits (ASIC). These chips are designed with the algorithm implemented and
fixed at the chip manufacturing stage.

ASIC technology has continued to be developed with improvements in power
efficiency and an increase in the rate at which hashes are calculated. In
table 2, the type of hash function deployed as an ASIC chip is tabulated. The
column ‘maintained’ identifies if the ASIC for the hash function is still
under development. As a continuation of the work in [104], it can be observed
that the opportunities have diminished to implement novel ideas for executing
the algorithm, such as it was during the first to third generations of mining
and in the early years of the fourth generation. Figure 7 shows the number of
watts of electricity for 1000 hash calculations per second, sorted by the ASIC
technology evolution from 55 nanometers until the current designs of 7
nanometers, between March 2014 and May 2020. This highlights that
comparatively smaller gains are achieved over time, furthermore, the gains
today are directly associated with which ASIC nanometer technology is used to
build the chip. Such ASIC’s are then incorporated into hardware units
consisting of hundreds ASIC chips, often called mining rigs.

Specific blockchain hardware has also included propriety hardware,
specifically designed for certain consensus methods such as PoET discussed in
section 6.1.5. In addition, some implementations continue to use generalised
CPU and GPU hardware in the block addition process. It is acknowledge that
hardware is critical for all blockchain solutions and we consider it a core
component existing at the storage layer, in figure 5.

###  6.2 Organisation Layer

The organisation layer and the components defined are considered as associated
blockchain technology, presented in our model in figure 1. Moreover components
of this layer are considered optional to use when building an immutable
storage solution, as highlighted by the omission of the organisational layer
in some blockchain implementations, presented in table 1. Furthermore, data
can be stored on a blockchain without any organisation. This is due to the
blockchain properties at the storage layer; such as chronological ordering or
immutability of data, which may be sufficient for a solution. Moreover, the
organisation of data may be performed by the software application using the
blockchain for its storage. However, this layer is often used to structure the
block data and forms consistency across all blocks in the blockchain, with the
distributed ledger being the most commonly used data structure to date. In
practice, there is no limitation to what data structure can be implemented. In
this section we will explore the types of data structures existing at the
organisation layer.

Hash Function Name | Proof Type | ASIC Implementation | Maintained
---|---|---|---
SHA-256 | PoW | ✓ | ✓
X11 | PoW | ✓ | ✓
Ethash SHA3-512 | PoW | ✓ |
Equihash | PoW | ✓ | ✓
CryptoNight | PoW | ✓ |
Scrypt | PoW | ✓ |
Table 2: Implementation as an ASIC chip.

####  6.2.1 Ledger Structure

We begin with the organisation layer type of the ledger, presented in figure
1. Blockchain in its original application of Bitcoin implemented a ledger to
manage the cryptocurrency in existence. The ledger is updated using
transactions, including the change that will occur. In the case of Bitcoin, it
is the change of ownership of the cryptocurrency, this process is presented on
the left of figure 2. This transaction is then recorded in the ledger through
the blockchain mining process presented in figure 4. Furthermore, ledgers are
not limited to financial transactions and can extend to any update in the form
of a transaction. The term Distributed Ledger Technology (DLT) has also been
used to describe a blockchain, with an organisation structure of a ledger.
However, not all distributed ledger technology makes use of a chaining of
blocks; some implement a chaining of transactions to form a ledger [105].
Overall distributed ledger technologies focus on immutability and the rate at
which transactions can be processed in a centralised environment, in
comparison to blockchain ledgers, which are generally security focused and
commonly designed for a decentralised environment, previously discussed in the
section 6.1.2. Ledgers are optional components that organise data contained
within each block to produce an association of data across all blocks, and are
placed in the organisation layer of figure 1.

####  6.2.2 Database Structure

Blockchain has been implemented to make use of relational and NoSQL database
management systems, to improve information access when storing data on a
blockchain. Requests are processed through a database management system.
However, the database is stored as a blockchain. Therefore, maintains the
properties of a blockchain, such as immutability, replication, and security in
a decentralised environment [106]. Blockchain in itself can have its data
organised to reflect a database structure natively, supporting traditional
functions of database management systems, such as query language support and
indexing, thus removing the need for a database management system [107]. This
type of structure organises data both in and across the blocks and therefore
exists at the organisation layer, in figure 1.

####  6.2.3 Other Structures

Blockchain implementations have included structures for storing and updating
medical records, for IoT data storage, which varies on the type of device
sending the data, to support structures for the authentication and
authorisation of devices, and for traditional raw data organisation, in
section 5. Technical specification of such solutions often lacks the details
of exactly what structure it would require at the organisation layer, and
proves to be application specific. However, this section is to acknowledge the
existence of organisation structures, which have been implemented or purposed
but are not shared or defined. As such structures are for the organisation of
data between blocks, they are placed in the organisation layer, in figure 1.

###  6.3 Data Type Layer

The data type layer, in figure 1, is used to establish the purpose of the
blockchain by defining what data will be stored. This layer establishes the
application specific use of the blockchain, identified by what type of
information and in what format it is to be stored. This is akin to file types
in a file system such as MP3, GIF and PEM. Components of this layer are
considered optional to use when building an immutable storage solution, as
highlighted by the omission of the data type layer in some blockchain
implementations [57], and presented in table 1. It is acknowledged that a
blockchain primary purpose is for data storage, however, we consider that the
structure of data being stored is not part of the core components required to
produce an immutable storage solution, that is blockchain, presented in figure
5. Moreover, a blockchain will continue to process blocks even if the data
section of the block is empty. We define what types of data are commonly
implemented at the data type layer of our model in the following sections.

####  6.3.1 Smart-Contracts

At the data type layer of our three-tiered model, in figure 1, we begin with
smart contracts. Smart contracts are applications stored on a blockchain and
are executed externally to the blockchain on a supporting compute virtual
machine or in a containerisation platform. Due to the immutability of
blockchain storage, a smart contract solution includes the use of a unique
programming language. Furthermore, traditional software development
lifecycles, especially regarding update and release cycles, are no longer
considered valid approaches [108]. A one-time release of a smart contract is
required, therefore, the accuracy of the software development and testing is
paramount. Due to this, novel development considerations need to be considered
when implementing smart contracts, moreover, smart contracts and the
associated programming language are blockchain specific.

The Ethereum blockchain was explicitly designed to support smart contracts,
with the architecture being turing complete, meaning it can represent any
algorithm [109] [110]. Aspects of smart contracts on this blockchain will be
explored beginning with the compute cycles. These are accounted for, described
as the execution time of a smart contract, and are limited to a variable
called ‘gas’, paid for with Ether, Ethereum’s cryptocurrency. The result of
exceeding this variable is the premature termination in computation of the
smart contract [111]. Smart contract code execution needs to be tested to
ensure it remains within these limits. In addition to development correctness,
all aspects of the contract need to be finalised, such as the wallet address
of each party. Unlike traditional contracts, there is no option for
amendments.

Smart contracts are not limited to party transactions and can be linked
together to perform a greater task. This has brought about the realisation of
distributed applications, applications within a replicated blockchain [112].
These applications function as the back-end and provide an _Application
Programming Interface_ (API), with the front-end being developed to use this
API to produce the presentation of an interface for the application. This can
be in the form of a web interface [113]. Smart contract development has
evolved to support different programming languages, and therefore different
syntax. Smart contract structure remains application specific, but is a
recognised data type at the data type layer, in figure 1.

####  6.3.2 Transactions

From our blockchain model, in figure 1, we next discuss the transaction data
type. Transactions can represent updates to any data structure existing at the
organisation layer, with the structure of an update remaining application
specific. Transactions have commonly been associated with and organised to
form a ledger, with the transaction being used to modify ownership of items
existing in a distributed ledger. This can either represent a physical or
tangible item as a token, often called a non-fungible token (NFT) or the
ownership of a digital asset such as a cryptocurrency. A single transaction
can be between multiple parties, it a Bitcoin blockchain transaction this is
expressed as multiple outputs in the transaction definition [114].
Transactions have also been used to update other objects stored on a
blockchain that are not in the organisation of a ledger. Such objects include
medical records [40] and the storage of IoT output data [44]. The structure of
transactions remains application-specific; at present, it is the most common
data structure in use. This exists at the data type layer in figure 1.

####  6.3.3 File Storage

The file storage component existing at the data type layer, in figure 1, is
explored next. Blockchains implemented for a file storage solution often do
not store the file on the blockchain, but store a representation of a file in
the form of a hash digest or only the associated metadata belonging to the
file, specifically its location on external storage [115] [116]. However, with
an appropriate hashing algorithm and the consideration of the network size,
that is the number of replicas of a blockchain, therefore, the total storage
consumed, files can be stored within blocks on a blockchain [117]. A
blockchain supporting small files, such as text documents, transforms them
into an immutable document without the need for external encoding. A similar
solution was purposed for the storage of system log files [118]. Direct file
storage remains primarily theoretical. However, it is a consideration for a
data type at the data type layer, displayed in our novel model in figure 1.

####  6.3.4 Objects and Other Data Packages

Objects and other data packages have been acknowledged as a data type at the
data type layer in figure 1. There are currently active blockchain based
applications used to store message communications, comments to published
media, and blog content [119]. Other message based objects can be stored on a
blockchain as data structures, such as JavaScript object notation (JSON),
extensible markup language (XML) and YAML. Each of these natively manages the
organisation of data into information through the use of a key structure. Such
structures are universally accepted and are designed for interoperability
between technology solutions [120]. This grouping has significant research and
experimental potential within blockchain based solutions, and is used as a
placeholder for future developments.

##  7 Future Considerations

Application-specific implementations of blockchain and its associated
technologies continue to be the dominant approach to blockchain storage
solutions. In recent years, blockchain and distributed ledger projects have
been growing to support reusable, open-source code, in a modular design.
Modular means the ability to add components from the storage layer presented
in figure 5 and discussed in section 6. This removes the necessity to design a
blockchain in its entirety and therefore an application-specific solution, as
not all blockchains are suited to every solution. These blockchain projects
focus on generalised implementations that suit a range of solutions but
differentiate between each project by highlighting the individual strengths,
making it more likely to find an out-of-the-box blockchain solution. In figure
1, blockchain and its associated components are identified and generalised,
however, due to current application-specific implementations and the lack of
detail into how the solution uses blockchain, as an immutable storage
technology, this model is incomplete. Placeholders of ‘other’, at the
organisation and data type layer, allow for the extension of this model as a
future consideration to extend the components as each type is standardised.

Standardisation will benefit blockchain’s adoption, the interoperability of
blockchain solutions, and the development practices that extend into all
aspects of blockchain; being its associated technologies, components and
terminologies. Future considerations include the introduction of _Request For
Comment_ (RFC) like documentation or an ‘International Organization for
Standardization’ guidance to outline the specification for each of the
technology components, to assist in the compatibility of immutable storage
solutions both in the design and development phases. In is acknowledged that
work has been started in a formalisation process within the Institute of
Electrical and Electronics Engineers (IEEE), presented in [121]. It is
envisioned that such an approach will result in an alignment between the
theoretical understanding and the practical application of blockchain as an
immutable storage solution and any associated blockchain technologies.

##  8 Conclusion

This paper presents a novel layered model to categorise technologies and
terminologies that are either directly required for a blockchain’s core
function at the base layer and the associated optional components in the
layers above this. Article presents a universally recognised logical structure
that can be used as a guide when referencing and building a blockchain storage
solution. This helps to address the current lack of consistency in the
implementation and interpretation of blockchain architecture as emphasised by
a review of a selected literature on the topic. Our proposed layered model
produces a modular structure to allow for a granular selection of blockchain
components comprised from all known blockchain technologies. Each
categorisation is explored in detail to build a group of related concepts and
technologies. By generalising blockchain as an immutable online storage
solution, we highlight the key aspects that have made it a valuable technology
making it the only method for continuous write-once, read-only online storage
and achieving this without governance.

## References

  * [1] Michael Hudson.  … and forgive them their debts: Lending, Foreclosure and Redemption From Bronze Age Finance to the Jubilee Year, 2018.
  * [2] K. Goda and M. Kitsuregawa.  The History of Storage Systems.  Proceedings of the IEEE, 100(Special Centennial Issue):1433–1440, 2012.
  * [3] Winfred Yaokumah.  Modelling the Impact of Administrative Access Controls on Technical Access Control Measures.  Information Resources Management Journal (IRMJ), 30(4):53–70, 2017\.
  * [4] Saul Gorn.  Rectangular holes in twelve-row punched cards.  Communications of the ACM, 9(10):763, 1966.
  * [5] Lance J Hoffman.  Computers and privacy: A survey.  ACM Computing Surveys (CSUR), 1(2):85–103, 1969.
  * [6] Satoshi Nakamoto.  Bitcoin: A peer-to-peer electronic cash system.  Technical report, Manubot, 2008.
  * [7] Joris Claessens, Bart Preneel, and Joos Vandewalle.  How can mobile agents do secure electronic transactions on untrusted hosts? A survey of the security issues and the current solutions.  ACM Transactions on Internet Technology (TOIT), 3(1):28–48, 2003\.
  * [8] Whitfield Diffie and Martin Hellman.  New directions in cryptography.  IEEE transactions on Information Theory, 22(6):644–654, 1976.
  * [9] W. Diffie.  The first ten years of public-key cryptography.  Proceedings of the IEEE, 76(5):560–577, 1988.
  * [10] Neal Koblitz.  Elliptic curve cryptosystems.  Mathematics of computation, 48(177):203–209, 1987.
  * [11] Ralph C Merkle.  Protocols for public key cryptosystems.  In 1980 IEEE Symposium on Security and Privacy, pages 122–122. IEEE, 1980.
  * [12] Manoj Parameswaran, Anjana Susarla, and Andrew B Whinston.  P2P networking: An information sharing alternative.  Computer, 34(7):31–38, 2001.
  * [13] Markus Jakobsson and Ari Juels.  Proofs of work and bread pudding protocols.  In Secure information networks, pages 258–272. Springer, 1999\.
  * [14] Maria Rona L Perez, Bobby Gerardo, and Ruji Medina.  Modified SHA256 for securing online transactions based on Blockchain Mechanism.  In 2018 IEEE 10th International Conference on Humanoid, Nanotechnology, Information Technology, Communication and Control, Environment and Management (HNICEM), pages 1–5. IEEE, 2018.
  * [15] Aviv Zohar.  Bitcoin: under the hood.  Communications of the ACM, 58(9):104–113, 2015.
  * [16] Rainer Böhme, Nicolas Christin, Benjamin Edelman, and Tyler Moore.  Bitcoin: Economics, technology, and governance.  Journal of economic Perspectives, 29(2):213–238, 2015.
  * [17] Jesse Yli-Huumo, Deokyoon Ko, Sujin Choi, Sooyong Park, and Kari Smolander.  Where is current research on blockchain technology?—a systematic review.  Public Library of Science (PLoS), 11(10):e0163477, 2016.
  * [18] Hao Jin, Ke Zhou, Hong Jiang, Dongliang Lei, Ronglei Wei, and Chunhua Li.  Full integrity and freshness for cloud data.  Future Generation Computer Systems, 80:640–652, 2018.
  * [19] Jiaxing Li, Jigang Wu, and Long Chen.  Block-secure: Blockchain based scheme for secure P2P cloud storage.  Information Sciences, 465:219–231, 2018.
  * [20] Rui Zhang, Rui Xue, and Ling Liu.  Security and Privacy on Blockchain.  ACM Computing Surveys, 52(3), July 2019.
  * [21] Fran Casino, Thomas K Dasaklis, and Constantinos Patsakis.  A systematic literature review of blockchain-based applications: Current status, classification and open issues.  Telematics and Informatics, 36:55–81, 2019.
  * [22] Marten Risius and Kai Spohrer.  A blockchain research framework.  Business & Information Systems Engineering, 59(6):385–409, 2017\.
  * [23] Tommy Koens and Erik Poll.  What blockchain alternative do you need?  In Data Privacy Management, Cryptocurrencies and Blockchain Technology, pages 113–129. Springer, 2018.
  * [24] Bert-Jan Butijn, Damian A Tamburri, and Willem-Jan van den Heuvel.  Blockchains: A Systematic Multivocal Literature Review.  ACM Computing Surveys (CSUR), 53(3):1–37, 2020.
  * [25] Hanna Halaburda.  Blockchain revolution without the blockchain?  Communications of the ACM, 61(7):27–29, 2018.
  * [26] Yong Yuan and Fei-Yue Wang.  Blockchain and cryptocurrencies: Model, techniques, and applications.  IEEE Transactions on Systems, Man, and Cybernetics: Systems, 48(9):1421–1428, 2018.
  * [27] Yang Xinyi, Zhang Yi, and Yulin He.  Technical characteristics and model of blockchain.  In 2018 10th International Conference on Communication Software and Networks (ICCSN), pages 562–566, 2018.
  * [28] Zhangbo Duan, Hongliang Mao, Zhidong Chen, Xiaomin Bai, Kai Hu, and Jean-Pierre Talpin.  Formal modeling and verification of blockchain system.  In Proceedings of the 10th International Conference on Computer Modeling and Simulation, ICCMS 2018, page 231–235, New York, NY, USA, 2018\. Association for Computing Machinery.
  * [29] James Clavin, Sisi Duan, Haibin Zhang, Vandana P. Janeja, Karuna P. Joshi, Yelena Yesha, Lucy C. Erickson, and Justin D. Li.  Blockchains for government: Use cases and challenges.  Digit. Gov.: Res. Pract., 1(3), November 2020.
  * [30] Andreas Ellervee, Raimundas Matulevicius, and Nicolas Mayer.  A comprehensive reference model for blockchain-based distributed ledger technology.  In ER Forum/Demos, pages 306–319, 2017.
  * [31] Shuai Wang, Liwei Ouyang, Yong Yuan, Xiaochun Ni, Xuan Han, and Fei-Yue Wang.  Blockchain-enabled smart contracts: Architecture, applications, and future trends.  IEEE Transactions on Systems, Man, and Cybernetics: Systems, 49(11):2266–2277, 2019.
  * [32] Hissu Hyvärinen, Marten Risius, and Gustav Friis.  A blockchain-based approach towards overcoming financial fraud in public sector services.  Business & Information Systems Engineering, 59(6):441–456, 2017\.
  * [33] Jun Dai and Miklos A Vasarhelyi.  Toward blockchain-based accounting and assurance.  Journal of Information Systems, 31(3):5–21, 2017.
  * [34] Merlinda Andoni, Valentin Robu, David Flynn, Simone Abram, Dale Geach, David Jenkins, Peter McCallum, and Andrew Peacock.  Blockchain technology in the energy sector: A systematic review of challenges and opportunities.  Renewable and Sustainable Energy Reviews, 100:143–174, 2019.
  * [35] Xin Chen, Jiachen Shen, Zhenfu Cao, and Xiaolei Dong.  A Blockchain-Based Privacy-Preserving Scheme for Smart Grids.  In Proceedings of the 2020 2nd International Conference on Blockchain Technology, pages 120–124, 2020.
  * [36] Tsan-Ming Choi, Xin Wen, Xuting Sun, and Sai-Ho Chung.  The mean-variance approach for global supply chain risk analysis with air logistics in the blockchain technology era.  Transportation Research Part E: Logistics and Transportation Review, 127:178–191, 2019.
  * [37] Kaijun Leng, Ya Bi, Linbo Jing, Han-Chi Fu, and Inneke Van Nieuwenhuyse.  Research on agricultural supply chain system with double chain architecture based on blockchain technology.  Future Generation Computer Systems, 86:641–649, 2018.
  * [38] Guido Perboli, Stefano Musso, and Mariangela Rosano.  Blockchain in logistics and supply chain: A lean approach for designing real-world use cases.  IEEE Access, 6:62018–62028, 2018.
  * [39] Xiaolin Xu, Fahim Rahman, Bicky Shakya, Apostol Vassilev, Domenic Forte, and Mark Tehranipoor.  Electronics supply chain integrity enabled by blockchain.  ACM Transactions on Design Automation of Electronic Systems (TODAES), 24(3):1–25, 2019.
  * [40] Tsung-Ting Kuo, Hyeon-Eui Kim, and Lucila Ohno-Machado.  Blockchain distributed ledger technologies for biomedical and health care applications.  Journal of the American Medical Informatics Association, 24(6):1211–1220, 2017.
  * [41] X. Xu, X. Zhang, H. Gao, Y. Xue, L. Qi, and W. Dou.  BeCome: Blockchain-Enabled Computation Offloading for IoT in Mobile Edge Computing.  IEEE Transactions on Industrial Informatics, 16(6):4187–4195, 2020\.
  * [42] Pankaj Mendki.  Blockchain enabled IoT edge computing.  In Proceedings of the 2019 International Conference on Blockchain Technology, pages 66–69, 2019.
  * [43] Matevž Pustišek, Dejan Dolenc, and Andrej Kos.  LDAF: Low-Bandwidth Distributed Applications Framework in a Use Case of Blockchain-Enabled IoT Devices.  Sensors, 19(10):2337, 2019.
  * [44] Ujjwal Guin, Pinchen Cui, and Anthony Skjellum.  Ensuring proof-of-authenticity of IoT edge devices using blockchain technology.  In 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), pages 1042–1049. IEEE, 2018.
  * [45] Zhe Yang, Kan Yang, Lei Lei, Kan Zheng, and Victor CM Leung.  Blockchain-based decentralized trust management in vehicular networks.  IEEE Internet of Things Journal, 6(2):1495–1505, 2018.
  * [46] Mayra Samaniego, Uurtsaikh Jamsrandorj, and Ralph Deters.  Blockchain as a Service for IoT.  In 2016 IEEE international conference on internet of things (iThings) and IEEE green computing and communications (GreenCom) and IEEE cyber, physical and social computing (CPSCom) and IEEE smart data (SmartData), pages 433–436. IEEE, 2016.
  * [47] Sara Saberi, Mahtab Kouhizadeh, Joseph Sarkis, and Lejia Shen.  Blockchain technology and its relationships to sustainable supply chain management.  International Journal of Production Research, 57(7):2117–2135, 2019\.
  * [48] Ali Dorri, Salil S Kanhere, and Raja Jurdak.  Towards an optimized blockchain for IoT.  In 2017 IEEE/ACM Second International Conference on Internet-of-Things Design and Implementation (IoTDI), pages 173–178. IEEE, 2017\.
  * [49] Nir Kshetri and Jeffrey Voas.  Blockchain-enabled e-voting.  IEEE Software, 35(4):95–99, 2018.
  * [50] Guy Zyskind, Oz Nathan, et al.  Decentralizing privacy: Using blockchain to protect personal data.  In 2015 IEEE Security and Privacy Workshops, pages 180–184. IEEE, 2015.
  * [51] Jan Mendling, Ingo Weber, Wil Van Der Aalst, Jan Vom Brocke, Cristina Cabanillas, Florian Daniel, Søren Debois, Claudio Di Ciccio, Marlon Dumas, Schahram Dustdar, Avigdor Gal, Luciano García-Bañuelos, Guido Governatori, Richard Hull, Marcello La Rosa, Henrik Leopold, Frank Leymann, Jan Recker, Manfred Reichert, Hajo A. Reijers, Stefanie Rinderle-Ma, Andreas Solti, Michael Rosemann, Stefan Schulte, Munindar P. Singh, Tijs Slaats, Mark Staples, Barbara Weber, Matthias Weidlich, Mathias Weske, Xiwei Xu, and Liming Zhu.  Blockchains for Business Process Management - Challenges and Opportunities.  ACM Transactions on Management Information Systems (TMIS), 9(1), February 2018.
  * [52] Lanxiang Chen, Wai-Kong Lee, Chin-Chen Chang, Kim-Kwang Raymond Choo, and Nan Zhang.  Blockchain based searchable encryption for electronic health record sharing.  Future Generation Computer Systems, 95:420–429, 2019.
  * [53] Xiwei Xu, Cesare Pautasso, Liming Zhu, Vincent Gramoli, Alexander Ponomarev, An Binh Tran, and Shiping Chen.  The blockchain as a software connector.  In 2016 13th Working IEEE/IFIP Conference on Software Architecture (WICSA), pages 182–191. IEEE, 2016.
  * [54] Nayan B Ruparelia.  Software development lifecycle models.  ACM SIGSOFT Software Engineering Notes, 35(3):8–13, 2010.
  * [55] Yujin Kwon, Hyoungshick Kim, Jinwoo Shin, and Yongdae Kim.  Bitcoin vs. Bitcoin Cash: Coexistence or Downfall of Bitcoin Cash?  In 2019 IEEE Symposium on Security and Privacy (SP), pages 935–951. IEEE, 2019.
  * [56] Zibin Zheng, Shaoan Xie, Hongning Dai, Xiangping Chen, and Huaimin Wang.  An overview of blockchain technology: Architecture, consensus, and future trends.  In 2017 IEEE international congress on big data (BigData congress), pages 557–564. IEEE, 2017.
  * [57] Tien Tuan Anh Dinh, Rui Liu, Meihui Zhang, Gang Chen, Beng Chin Ooi, and Ji Wang.  Untangling blockchain: A data processing view of blockchain systems.  IEEE Transactions on Knowledge and Data Engineering, 30(7):1366–1385, 2018.
  * [58] Suyash Gupta, Jelle Hellings, Sajjad Rahnama, and Mohammad Sadoghi.  Blockchain Consensus Unraveled: Virtues and Limitations.  In Proceedings of the 14th ACM International Conference on Distributed and Event-Based Systems, DEBS ’20, page 218–221, New York, NY, USA, 2020. Association for Computing Machinery.
  * [59] Yahya Shahsavari, Kaiwen Zhang, and Cahmseddine Talhi.  Performance modeling and analysis of the bitcoin inventory protocol.  In 2019 IEEE International Conference on Decentralized Applications and Infrastructures (DAPPCON), pages 79–88. IEEE, 2019.
  * [60] M. F. sallal, G. Owenson, and M. Adda.  Proximity Awareness Approach to Enhance Propagation Delay on the Bitcoin Peer-to-Peer Network.  In 2017 IEEE 37th International Conference on Distributed Computing Systems (ICDCS), pages 2411–2416, 2017.
  * [61] H. Sukhwani, J. M. Martínez, X. Chang, K. S. Trivedi, and A. Rindos.  Performance Modeling of PBFT Consensus Process for Permissioned Blockchain Network (Hyperledger Fabric).  In 2017 IEEE 36th Symposium on Reliable Distributed Systems (SRDS), pages 253–255, 2017.
  * [62] Amool Sudhan and Manisha J Nene.  Peer Selection Techniques for Enhanced Transaction Propagation in Bitcoin Peer-to-Peer Network.  In 2018 Second International Conference on Intelligent Computing and Control Systems (ICICCS), pages 679–684. IEEE, 2018.
  * [63] D. Fullmer and A. S. Morse.  Analysis of Difficulty Control in Bitcoin and Proof-of-Work Blockchains.  In 2018 IEEE Conference on Decision and Control (CDC), pages 5988–5992, 2018.
  * [64] Lin Chen, Lei Xu, Nolan Shah, Zhimin Gao, Yang Lu, and Weidong Shi.  On security analysis of proof-of-elapsed-time (poet).  In International Symposium on Stabilization, Safety, and Security of Distributed Systems, pages 282–297. Springer, 2017.
  * [65] Kashif Mehboob Khan, Junaid Arshad, and Muhammad Mubashir Khan.  Investigating performance constraints for blockchain based secure e-voting system.  Future Generation Computer Systems, 105:13–26, 2020.
  * [66] Michael Barborak, Anton Dahbura, and Miroslaw Malek.  The consensus problem in fault-tolerant computing.  ACM Computing Surveys (CSur), 25(2):171–220, 1993.
  * [67] Yang Xiao, Ning Zhang, Wenjing Lou, and Y Thomas Hou.  A survey of distributed consensus protocols for blockchain networks.  IEEE Communications Surveys & Tutorials, 22(2):1432–1465, 2020\.
  * [68] Natalia Chaudhry and Muhammad Murtaza Yousaf.  Consensus algorithms in blockchain: Comparative analysis, challenges and opportunities.  In 2018 12th International Conference on Open Source Systems and Technologies (ICOSST), pages 54–63. IEEE, 2018.
  * [69] Vincent Gramoli.  From blockchain consensus back to byzantine consensus.  Future Generation Computer Systems, 107:760–769, 2020.
  * [70] Ramakrishna Kotla and Michael Dahlin.  High throughput Byzantine fault tolerance.  In International Conference on Dependable Systems and Networks, 2004, pages 575–584. IEEE, 2004.
  * [71] Miguel Castro and Barbara Liskov.  Practical Byzantine Fault Tolerance and Proactive Recovery.  ACM Trans. Comput. Syst., 20(4):398–461, November 2002.
  * [72] Bitcoincore.  Bitcoin Core project.  https://bitcoincore.org/, 2020.  "[Online] accessed: January. 05, 2021".
  * [73] Yoad Lewenberg, Yoram Bachrach, Yonatan Sompolinsky, Aviv Zohar, and Jeffrey S Rosenschein.  Bitcoin mining pools: A cooperative game theoretic analysis.  In Proceedings of the 2015 International Conference on Autonomous Agents and Multiagent Systems, pages 919–927, 2015.
  * [74] Christian Decker, Jochen Seidel, and Roger Wattenhofer.  Bitcoin Meets Strong Consistency.  In Proceedings of the 17th International Conference on Distributed Computing and Networking, ICDCN ’16, New York, NY, USA, 2016. Association for Computing Machinery.
  * [75] Hyperledger.  Hyperledger Architecture, Volume 1 Introduction to Hyperledger Business Blockchain Design Philosophy and Consensus.  https://www.hyperledger.org/wp-content/uploads/2017/08/Hyperledger_Arch_WG_Paper_1_Consensus.pdf, 2017\.  Accessed: 2020-12-01.
  * [76] Pierre-Louis Aublin, Sonia Ben Mokhtar, and Vivien Quéma.  RBFT: Redundant Byzantine Fault Tolerance.  In Proceedings of the 2013 IEEE 33rd International Conference on Distributed Computing Systems, pages 297–306. IEEE Computer Society, 2013\.
  * [77] Hyperledger.  Hyperledger Indy-plenum consensus-protocol.  https://github.com/hyperledger/indy-plenum/blob/master/docs/source/diagrams/consensus-protocol.png, 2019\.  "[Online] accessed: January. 05, 2021".
  * [78] Dan Boneh, Ben Lynn, and Hovav Shacham.  Short signatures from the Weil pairing.  Journal of cryptology, 17(4):297–319, 2004.
  * [79] Kelly Olson, Mic Bowman, James Mitchell, Shawn Amundson, Dan Middleton, and Cian Montgomery.  Sawtooth: An Introduction.  The Linux Foundation, 2018.
  * [80] Ethereum proof-of-stake.
  * [81] Mahdi Zamani, Mahnush Movahedi, and Mariana Raykova.  RapidChain: Scaling Blockchain via Full Sharding.  In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS ’18, page 931–948, New York, NY, USA, 2018\. Association for Computing Machinery.
  * [82] W. Y. Maung Maung Thin, N. Dong, G. Bai, and J. S. Dong.  Formal Analysis of a Proof-of-Stake Blockchain.  In 2018 23rd International Conference on Engineering of Complex Computer Systems (ICECCS), pages 197–200, 2018.
  * [83] Graphene Blockchains List-2018.  https://github.com/graphene-foundation/blockchains/.  [Online] accessed: May. 03, 2021.
  * [84] Changqiang Zhang, Cangshuai Wu, and Xinyi Wang.  Overview of Blockchain Consensus Mechanism.  In Proceedings of the 2020 2nd International Conference on Big Data Engineering, BDE 2020, pages 7–12, New York, NY, USA, 2020. Association for Computing Machinery.
  * [85] Ethereum proof-of-work.
  * [86] Arthur Gervais, Ghassan O Karame, Karl Wüst, Vasileios Glykantzis, Hubert Ritzdorf, and Srdjan Capkun.  On the security and performance of proof of work blockchains.  In Proceedings of the 2016 ACM SIGSAC conference on computer and communications security, pages 3–16, 2016.
  * [87] Exonum.  Bitfury Exonum exonum: Byzantine fault tolerant protocol for blockchains.  https://exonum.com/theme/public/img/downloads/wp_consensus_181227.pdf, 2018\.  "[Online] accessed: January. 05, 2021".
  * [88] Kostis Karantias, Aggelos Kiayias, and Dionysis Zindros.  Proof-of-burn.  In International Conference on Financial Cryptography and Data Security, pages 523–540. Springer, 2020.
  * [89] L. S. Sankar, M. Sindhu, and M. Sethumadhavan.  Survey of consensus protocols on blockchain applications.  In 2017 4th International Conference on Advanced Computing and Communication Systems (ICACCS), pages 1–5, 2017.
  * [90] Mitar Milutinovic, Warren He, Howard Wu, and Maxinder Kanwal.  Proof of Luck: An Efficient Blockchain Consensus Protocol.  In Proceedings of the 1st Workshop on System Software for Trusted Execution, SysTEX ’16, New York, NY, USA, 2016. Association for Computing Machinery.
  * [91] Jeremiah Blocki and Hong-Sheng Zhou.  Designing Proof of Human-Work Puzzles for Cryptocurrency and Beyond.  In Martin Hirt and Adam Smith, editors, Theory of Cryptography, pages 517–546, Berlin, Heidelberg, 2016. Springer Berlin Heidelberg.
  * [92] Angelique Faye Loe and Elizabeth A. Quaglia.  Conquering Generals: An NP-Hard Proof of Useful Work.  In Proceedings of the 1st Workshop on Cryptocurrencies and Blockchains for Distributed Systems, CryBlock’18, page 54–59, New York, NY, USA, 2018. Association for Computing Machinery.
  * [93] Dfinity.  DFINITY Technology Overview Series consensus system.  https://dfinity.org/pdf-viewer/library/dfinity-consensus.pdf, 2018.  "[Online] accessed: January. 05, 2021".
  * [94] Lianhua Chi and Xingquan Zhu.  Hashing techniques: A survey and taxonomy.  ACM Computing Surveys (CSUR), 50(1):1–36, 2017.
  * [95] Maoning Wang, Meijiao Duan, and Jianming Zhu.  Research on the security criteria of hash functions in the blockchain.  In Proceedings of the 2nd ACM Workshop on Blockchains, Cryptocurrencies, and Contracts, pages 47–55, 2018.
  * [96] Dipankar Dasgupta, John M Shrein, and Kishor Datta Gupta.  A survey of blockchain from security perspective.  Journal of Banking and Financial Technology, 3(1):1–17, 2019.
  * [97] H. Cho.  Correction to “ASIC-Resistance of Multi-Hash Proof-of-Work Mechanisms for Blockchain Consensus Protocols”.  IEEE Access, 7:25086–25086, 2019.
  * [98] N. Sklavos and O. Koufopavlou.  On the hardware implementations of the SHA-2 (256, 384, 512) hash functions.  In Proceedings of the 2003 International Symposium on Circuits and Systems, 2003. ISCAS ’03., volume 5, pages V–V, 2003.
  * [99] Alexandr Kuznetsov, Kyryl Shekhanin, Andrii Kolhatin, Diana Kovalchuk, Vitalina Babenko, and Iryna Perevozova.  Performance of Hash Algorithms on GPUs for Use in Blockchain.  In 2019 IEEE International Conference on Advanced Trends in Information Theory (ATIT), pages 166–170. IEEE, 2019.
  * [100] Matthew Vilim, Henry Duwe, and Rakesh Kumar.  Approximate Bitcoin Mining.  In Proceedings of the 53rd Annual Design Automation Conference, DAC ’16, New York, NY, USA, 2016. Association for Computing Machinery.
  * [101] Runchao Han, Nikos Foutris, and Christos Kotselidis.  Demystifying crypto-mining: Analysis and optimizations of memory-hard pow algorithms.  In 2019 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS), pages 22–33. IEEE, 2019.
  * [102] Mostafa I. Soliman and Ghada Y. Abozaid.  FPGA implementation and performance evaluation of a high throughput crypto coprocessor.  Journal of Parallel and Distributed Computing, 71(8):1075 – 1084, 2011.
  * [103] KN Devika and Ramesh Bhakthavatchalu.  Parameterizable FPGA Implementation of SHA-256 using Blockchain Concept.  In 2019 International Conference on Communication and Signal Processing (ICCSP), pages 0370–0374. IEEE, 2019.
  * [104] Michael Bedford Taylor.  The evolution of bitcoin hardware.  Computer, 50(9):58–66, 2017.
  * [105] Niclas Kannengießer, Sebastian Lins, Tobias Dehling, and Ali Sunyaev.  Trade-Offs between Distributed Ledger Technology Characteristics.  ACM Comput. Surv., 53(2), May 2020.
  * [106] Senthil Nathan, Chander Govindarajan, Adarsh Saraf, Manish Sethi, and Praveen Jayachandran.  Blockchain Meets Database: Design and Implementation of a Blockchain Relational Database.  Proc. VLDB Endow., 12(11):1539–1552, July 2019.
  * [107] Yanchao Zhu, Zhao Zhang, Cheqing Jin, Aoying Zhou, and Ying Yan.  Sebdb: Semantics empowered blockchain database.  In 2019 IEEE 35th international conference on data engineering (ICDE), pages 1820–1831. IEEE, 2019.
  * [108] G. Destefanis, M. Marchesi, M. Ortu, R. Tonelli, A. Bracciali, and R. Hierons.  Smart contracts vulnerabilities: A call for blockchain software engineering?  In 2018 International Workshop on Blockchain Oriented Software Engineering (IWBOSE), pages 19–25, 2018.
  * [109] A. Teller.  Turing completeness in the language of genetic programming with indexed memory.  In Proceedings of the First IEEE Conference on Evolutionary Computation. IEEE World Congress on Computational Intelligence, pages 136–141 vol.1, 1994.
  * [110] John E. Hopcroft, Rajeev Motwani, and Jeffrey D. Ullman.  Introduction to Automata Theory, Languages, and Computation, 2nd Edition.  SIGACT News, 32(1):60–65, March 2001.
  * [111] Xiaoqi Li, Peng Jiang, Ting Chen, Xiapu Luo, and Qiaoyan Wen.  A survey on the security of blockchain systems.  Future Generation Computer Systems, 107:841–853, 2020.
  * [112] Roberto Tonelli, Andrea Pinna, Gavina Baralla, and Simona Ibba.  Ethereum Smart Contracts as Blockchain-Oriented Microservices.  In Proceedings of the 19th International Conference on Agile Software Development: Companion, XP ’18, New York, NY, USA, 2018. Association for Computing Machinery.
  * [113] Jianbo Gao.  Guided, automated testing of blockchain-based decentralized applications.  In 2019 IEEE/ACM 41st International Conference on Software Engineering: Companion Proceedings (ICSE-Companion), pages 138–140. IEEE, 2019\.
  * [114] Johannes Göbel and Anthony E Krzesinski.  Increased block size and Bitcoin blockchain dynamics.  In 2017 27th International Telecommunication Networks and Applications Conference (ITNAC), pages 1–6. IEEE, 2017.
  * [115] S. Cui, M. R. Asghar, and G. Russello.  Towards Blockchain-Based Scalable and Trustworthy File Sharing.  In 2018 27th International Conference on Computer Communication and Networks (ICCCN), pages 1–2, 2018.
  * [116] Hossein Shafagh, Lukas Burkhalter, Anwar Hithnawi, and Simon Duquennoy.  Towards Blockchain-Based Auditable Storage and Sharing of IoT Data.  In Proceedings of the 2017 on Cloud Computing Security Workshop, CCSW ’17, page 45–50, New York, NY, USA, 2017. Association for Computing Machinery.
  * [117] M. Dai, S. Zhang, H. Wang, and S. Jin.  A Low Storage Room Requirement Framework for Distributed Ledger in Blockchain.  IEEE Access, 6:22970–22975, 2018.
  * [118] W. Pourmajidi and A. Miranskyy.  Logchain: Blockchain-Assisted Log Storage.  In 2018 IEEE 11th International Conference on Cloud Computing (CLOUD), pages 978–982, 2018.
  * [119] SM Habibul Mursaleen Chowdhury, Ferdous Jahan, Sarawat Murtaza Sara, and Dip Nandi.  Secured Blockchain Based Decentralised Internet: A Proposed New Internet.  In Proceedings of the International Conference on Computing Advancements, pages 1–7, 2020.
  * [120] Kazuaki Maeda.  Performance evaluation of object serialization libraries in XML, JSON and binary formats.  In 2012 Second International Conference on Digital Information and Communication Technology and it’s Applications (DICTAP), pages 177–182. IEEE, 2012.
  * [121] IEEE.  IEEE Standard for Data Format for Blockchain Systems.  IEEE Std 2418.2-2020, pages 1–32, 2020.
  * [122] Pratima Sharma, Rajni Jindal, and Malaya Dutta Borah.  Blockchain Technology for Cloud Storage: A Systematic Literature Review.  ACM Comput. Surv., 53(4), August 2020.
  * [123] Mohammad Dabbagh, Mehdi Sookhak, and Nader Sohrabi Safa.  The evolution of blockchain: A bibliometric study.  IEEE Access, 7:19212–19221, 2019.
  * [124] Di Yang, Chengnian Long, Han Xu, and Shaoliang Peng.  A Review on Scalability of Blockchain.  In Proceedings of the 2020 The 2nd International Conference on Blockchain Technology, ICBCT’20, page 1–6, New York, NY, USA, 2020. Association for Computing Machinery.
  * [125] Sarah Underwood.  Blockchain beyond Bitcoin.  Commun. ACM, 59(11):15–17, October 2016.
  * [126] Ian Miers, Christina Garman, Matthew Green, and Aviel D Rubin.  Zerocoin: Anonymous distributed e-cash from bitcoin.  In 2013 IEEE Symposium on Security and Privacy, pages 397–411. IEEE, 2013.
  * [127] Neil Gandal, JT Hamrick, Tyler Moore, and Tali Oberman.  Price manipulation in the Bitcoin ecosystem.  Journal of Monetary Economics, 95:86–96, 2018.
  * [128] Mauro Conti, E Sandeep Kumar, Chhagan Lal, and Sushmita Ruj.  A survey on security and privacy issues of bitcoin.  IEEE Communications Surveys & Tutorials, 20(4):3416–3452, 2018\.
  * [129] Michael A Cusumano.  The bitcoin ecosystem.  Communications of the ACM, 57(10):22–24, 2014.
  * [130] Joe Abou Jaoude and Raafat George Saade.  Blockchain applications–usage in different domains.  IEEE Access, 7:45360–45381, 2019.
  * [131] Erikson Júlio De Aguiar, Bruno S. Faiçal, Bhaskar Krishnamachari, and Jó Ueyama.  A Survey of Blockchain-Based Strategies for Healthcare.  ACM Computing Surveys, 53(2), March 2020.
  * [132] Laphou Lao, Zecheng Li, Songlin Hou, Bin Xiao, Songtao Guo, and Yuanyuan Yang.  A Survey of IoT Applications in Blockchain Systems: Architecture, Consensus, and Traffic Modeling.  ACM Computing Surveys, 53(1), February 2020.
  * [133] Donald R Morrison.  PATRICIA—practical algorithm to retrieve information coded in alphanumeric.  Journal of the ACM (JACM), 15(4):514–534, 1968.
  * [134] Bertony Bornelus, Hongmei Chi, and Guillermo A Francia III.  Integrating Blockchain Technology in Healthcare via Active Learning.  In Proceedings of the 2020 ACM Southeast Conference, pages 122–126, 2020.
  * [135] Qingji Zheng and Shouhuai Xu.  Secure and efficient proof of storage with deduplication.  In Proceedings of the second ACM conference on Data and Application Security and Privacy, pages 1–12, 2012.
  * [136] Harry Kalodner, Malte Möser, Kevin Lee, Steven Goldfeder, Martin Plattner, Alishah Chator, and Arvind Narayanan.  Blocksci: Design and applications of a blockchain analysis platform.  In 29th USENIX Security Symposium (USENIX Security 20), pages 2721–2738. USENIX Association, August 2020.