2102 IEEE INTERNET OF THINGS JOURNAL, VOL. 7, NO.

3, MARCH 2020

Blockchain of Finite-Lifetime Blocks With

Applications to Edge-Based IoT
Chan Kyu Pyoung and Seung Jun Baek , Member, IEEE

Abstract—Edge computing is a promising approach for provi- Blockchain is a peer-to-peer distributed ledger which
sioning distributed cloud services to Internet of Things (IoT) has initially gained success with cryptocurrencies such as
systems. Many recent studies propose that edge nodes use Bitcoin [6]. Because blockchain is nearly forge- and tamper-
blockchain for the decentralized management and access control
of IoT data. However, due to the massive volume of data and proof, it can handle secure transactions and data processing
related transactions, edge servers will eventually run out of space without authoritative intermediary. Blockchain is also charac-
to store the full chain. We introduce scalable and lightweight terized by security, transparency, integrity, and decentralization
architecture called LiTiChain, a blockchain of blocks with finite and is currently applied to various fields, such as finance,
lifetime. In LiTiChain, outdated transactions and blocks, that is, manufacturing, health care, etc., [7]. We consider a scalable
the blocks whose lifetimes are expired, can be safely removed
from the chain. Two graphs are merged into the structure of blockchain architecture suitable for IoT in the edge computing
LiTiChain: 1) a tree representing the order of expiry of lifetimes environment.
and 2) a linear graph representing the order of block creation. Due to the sheer number of connected IoT devices, cen-
We show that this construction not only ensures the connectiv- tralized cloud architecture has scalability problems in gath-
ity of the chain after block deletions but also helps to maintain ering and processing generated data. The edge computing
the block height of shortened chain. LiTiChain also supports
transactions whose lifetime is unknown at the time of creation. framework [8]–[10] alleviates the problems by bringing com-
It is possible that some expired blocks need to be retained in putation, data processing, and storage services closer to the
the chain, in case they are needed to validate remaining blocks, IoT devices. In edge computing, the first-hand processing of
which incurs additional storage costs. A detailed analysis of such IoT data is done at the edge servers which may compress
overhead in storage costs is presented for stochastic and worst and summarize the collected data. The summarized data in
case scenarios. Extensive simulation is performed on actual and
synthetic IoT data so as to gain insights on the storage costs under a greatly reduced size can be later forwarded to the central
various lifetime distributions. It is demonstrated that LiTiChain cloud. The edge layer can offload not only data processing
provides a simple yet effective solution to scalability problems in tasks from cloud but also low-latency compute-intensive tasks
storing blockchains for the IoT ecosystems. from the IoT devices. Recently, there has been much interest
Index Terms—Blockchain, edge computing, Internet of Things in machine-learning tasks which are delay-sensitive requiring
(IoT), security, storage costs. quick inference for speech recognition, translation, image clas-
sification, and video recognition [11]. Edge computing can
I. I NTRODUCTION thus effectively reduce power consumption and computational
load of IoT devices [12]–[17].
HE INTERNET of Things (IoT) industry continues to
T grow fast, and it is projected that over 60 billion devices
will have the Internet connectivity by 2025 with the global
We envision edge-based IoT systems where the edge servers
form a distributed network supporting storage and sharing
of IoT data using blockchain. The idea has been explored
market size surpassing a trillion dollars [1]. As IoT becomes in prior works; for example, EdgeChain [18] is proposed to
prevalent in daily life handling sensitive and private data, the record the activities and transactions among IoT along with
IoT security has become a major concern. With an explo- the resource management. Also, a model for sharing econ-
sive number of connected devices, it is challenging to address omy services based on blockchain is proposed [19], where the
issues in privacy, device reliability, hacking, and data integrity. intelligent processing of multimedia and cyber-physical data
In particular, centralized approaches to the IoT security have occurs at edge nodes which handle key transactions through
faced limitations due to the massive scale of generated data. blockchain. A decentralized storage system for IoT data with
To overcome these problems, a number of recent studies took blockchain-based access control was proposed [20] on top of
decentralized approaches using blockchain [2]–[5]. the decentralized cloud architectures such as Cloudlets [21].
Manuscript received July 25, 2019; revised October 22, 2019 and November The challenge with managing IoT data through blockchain
5, 2019; accepted December 3, 2019. Date of publication December 13, 2019; is, however, the scalability in the storage capacity. Currently,
date of current version March 12, 2020. This work was supported by for Bitcoin, more than 225 GB is required to store the full
the National Research Foundation of Korea grant funded by the Korea
Government (MSIT) under Grant 2018R1A2B6007130. (Corresponding chain. The transaction rate of Bitcoin is typically less than
author: Seung Jun Baek.) ten per second. By contrast, the generation rate of data from
The authors are with the Computer Science and Engineering massive-scale IoT devices and the associated transactions will
Department, Korea University, Seoul 02841, South Korea (e-mail:
[email protected]; [email protected]). be significantly higher than those of monetary transactions in
Digital Object Identifier 10.1109/JIOT.2019.2959599 cryptocurrencies. Because each edge server has a direct control
2327-4662 c 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: UNIVERSITY COLLEGE CORK. Downloaded on December 08,2024 at 09:44:46 UTC from IEEE Xplore. Restrictions apply.
PYOUNG AND BAEK: BLOCKCHAIN OF FINITE-LIFETIME BLOCKS WITH APPLICATIONS TO EDGE-BASED IoT 2103

over the associated client IoT devices and their data, each fixed, permanent, or indefinite lifetime depending on if the life-
server should be able to fully verify transactions and blocks, time is either deterministically finite, infinite, or undetermined,
i.e., should be a “full node,” and thus should store the full respectively, at the time of creation. This aspect complements
chain. The blockchain is, by design, an ever-growing, perma- the traditional blockchain which is not intended for handling
nent record of data blocks. Thus, the scalability of storage is data of which the validity lasts for a finite duration.
problematic with existing approaches, considering that edge We propose and explore the architecture of LiTiChain in the
servers typically have limited storage space. rest of this article. Due to the variability of block lifetimes,
In this article, we introduce a scalable and lightweight the topology of the proposed blockchain may change over
blockchain architecture called LiTiChain (pronounced as time. Particularly, if past blocks are deleted, the blochchain
litty1 -chain). LiTiChain is a blockchain of blocks with finite data structure may become disconnected. We thus propose a
lifetime. If the lifetime of a block expires, the block can be blockchain structure which merges two types of graphs: the
deleted from the chain. Thus, the size of the chain does not first graph with a tree structure based on the order of expira-
necessarily grow monotonically over time. The lifetime of a tion of lifetimes; and the second graph with a linear structure
block is determined by the lifetime of transactions within the based on the order of creation as in the conventional chain.
block; that is, we mainly consider transactions with lifetimes. We show that the former structure ensures the connectivity of
In addition to storage issues, we give rationale behind con- the chain, whereas the latter increases the height of the chain,
sidering IoT data and transactions with lifetimes. IoT generates i.e., the distance to the genesis block, leading to an improved
time-series data, such as sensor measurements, event logs, strength of security of the chain.
environmental and behavioral data, etc. Certain types of trans- Meanwhile, a block may be retained in LiTiChain although
actions may lose value over time. For example, suppose a its lifetime has expired because there may exist other blocks
customer equipped with an IoT device gets issued with a which refer to the block for validation purposes. The deletion
coupon with expiration date. The issuer of the coupon needs of the referred block will be delayed, which incurs additional
to keep track of the transaction (issuance) until the expiration storage costs. We will discuss methods to reduce such costs
date; however, after the expiration date, there is little point due to overdue blocks. A detailed analysis on how the retention
in storing that information. The depreciation of data and its overhead will affect the total storage cost is provided as well.
transactions over time is common in IoT applications. We summarize our contributions as follows.
Also, there is a growing concern in the privacy of 1) We propose a scalable blockchain architecture called
blockchains. Blockchain is pseudonymous, where a participant LiTiChain, which manages transactions with finite life-
is identified by its public key or hash. However, it is possible to times. In LiTiChain, the expired blocks can be removed
infer the actual identity of users by analyzing their transaction from the chain while maintaining its connectivity.
patterns recorded in the ledger [22], [23]. This issue can be LiTiChain provides a simple solution to storage prob-
partly addressed if some outdated transactions can be erased lems of conventional blockchains and is suitable for
in a timely manner. Besides, the IoT data shared among partic- edge-based IoT ecosystems generating a large number
ipants may contain personal information which its owner may of transactions.
not want to disclose permanently. Thus, a user may request 2) We present both stochastic and worst case analysis on
data or transaction history to be removed from the record. the storage costs incurred by retained blocks. For the
Blockchain has evolved into a platform not only for cryp- stochastic model, we derive the expected cost of reten-
tocurrency but also for transactions in healthcare and insurance tion overhead in a closed form. We also obtain an upper
which contain sensitive personal information, such as disease bound on the worst-case retention cost (RC) of overdue
and genetic information. General data protection regulation blocks.
(GDPR) [24] in European Union (EU) protects the fundamen- 3) We extensively perform numerical experiments using the
tal rights to the privacy of data subjects in Europe. The right actual and synthetic IoT data sets. We examine and pro-
to be forgotten (Article 17) stipulates that the record shall be vide insights on the storage costs, topology changes, and
removed if the purpose of collecting personal information has retention overhead of LiTiChain.
been fulfilled or that the information subject has withdrawn its The remainder of this article is organized as follows.
consent. Thus, personal information should be considered for We review the related work in Section II. We describe the
deletion if it is not necessary for the purpose of use or if the system model of our proposed blockchain in Section III. The
retention period has passed. If a user intentionally uploads data algorithms for block creation and deletion are presented in
with explicit contents or private information without consent, Section IV. In Section V, we analyze the worst case in our
the data will permanently remain in the blockchain. Thus, it proposed blockchain. The performance evaluation via simula-
is desirable to remove data that conflicts with societal norms tions is presented in Section VI. Section VII concludes this
and values from the storage even without agreements with the article.
uploader.
The lifetime of a transaction, however, may not be always
available when the transaction is created. LiTiChain is II. R ELATED W ORK
designed to handle three types of transactions: those with a The conventional centralized approaches to IoT security can
be vulnerable in large scale systems. To address the scalability
1 Although now obsolete, litty meant little in the English literature. issues, decentralized methods based on blockchain are recently

Authorized licensed use limited to: UNIVERSITY COLLEGE CORK. Downloaded on December 08,2024 at 09:44:46 UTC from IEEE Xplore. Restrictions apply.
2104 IEEE INTERNET OF THINGS JOURNAL, VOL. 7, NO. 3, MARCH 2020

proposed. Dorri et al. [25] proposed a decentralized, privacy works on distributed storage for IoT data empowered by
preserving, and secure architecture based on blockchain for blockchain. Liang et al. [39] proposed DroneChain to ensure
interconnected smart vehicles. The privacy of user was ensured the secure communication and integrity of data collected from
by changing the public key for each transaction. The authors drones. They simulated the average response time of data
found various applications of their architecture to the auto- transmission with an increasing number of drones and showed
motive industry, such as remote software updates, insurance, the effectiveness in scalability. Biswas et al. [40] proposed a
smart charging for electric vehicles, and car-sharing services. scalable blockchain framework for IoT, where they created a
Novo [26] introduced a distributed access control system for local peer network and achieved increased transaction rate and
IoT using blockchain. The IoT devices are indirectly con- the ledger scalability through all peers. Jiang et al. [41] inte-
nected to blockchain through management hub nodes, where grated Internet of Vehicles (IoV) and blockchain for distributed
the hub node used a signed certificate allowing the IoT devices and secure storage of big data. Li et al. [42] proposed the
to verify its authenticity. Wan et al. [27] proposed a par- blockchain-based large-scale IoT data storage and protection.
tially decentralized Industrial IoT (IIoT) architecture for smart The features of the proposed distributed storage are: the IoT
factory based on blockchain. They combined the Bell-La data are stored off-chain; the access to IoT data is controlled by
Padula model and the Biba model to ensure confidentiality, the majority of miners; and all access activities are recorded
integrity, and availability of data and service. Their proposed in the blockchain. Xu et al. [43] introduced Healthchain, a
scheme achieved an improved security and privacy protection privacy-preserving system for large-scale health data based on
than the centralized IIoT architecture in automatic production blockchain, where the IoT data and doctors’ diagnoses are
platforms. stored in IPFS.
Next, we introduce scalable systems and solutions for The studies in [44] and [45] consider redactable
blockchain. InterPlanetary file system (IPFS) [28], [29] is a blockchains at the block- and transaction-level, respectively.
decentralized and distributed file system with high integrity Deuber et al. [44] proposed a redactable blockchain that avoids
and resiliency. Unlike HTTP Web, IPFS maintains a stable heavy cryptographic primitives and used a consensus-based
system because data can be shared by connected nodes even voting in the permissionless setting. The proposed chain con-
in the presence of disconnected nodes. In order to maintain sists of blocks which are linearly connected by two links, the
the network, miners are paid with Filecoin [30] as a reward old and the new link. If a new block in the candidate block pool
for providing data storage and retrieval. Sharding [31] is an receives approval votes in the majority, the old block can be
on-chain solution that divides the entire network into shards replaced with the new one. The old state of the block is main-
in order to store transactions separately, and then to process tained for validation purposes. However, the chain length and
the stored transactions in parallel. Plasma [32] is an off-chain structure remain unchanged under their framework, and the
solution that enables scalable transactions on Ethereum by work does not address the storage problem for blockchains.
introducing blockchain-in-blockchain structure consisting of Derler et al. [45] introduced a policy-based chameleon-hash
child- and parent-chain. Transactions are offloaded to and are functions (PCHs) for fine-grained and controlled rewriting in
processed by the child-chain, where the processed transactions blockchain. The scheme uses the property of chameleon-hash
are verified and stored at the parent chain in the form of the functions such that the hash collisions can be generated after
Merkel root of their hashes. making arbitrary changes to blocks, only by authorities in pos-
The following studies consider an architecture combining session of a secret key, which is otherwise collision resistant.
IoT, blockchain, and edge computing. Sharma et al. [33] The secret key which can “unlock” the interlocked chain of
presented a distributed cloud architecture using blockchain. In blocks (called the trapdoor key), which makes blocks mod-
the edge of the IoT network, a distributed fog node consist- ifiable, needs to be shared among the authorities. However,
ing of software-defined networking (SDN) controllers based there is a risk of a small number of authorities entitled to
on blockchain is used for a low-latency service of com- redact transactions being compromised, in which case the
puting resources. Fog nodes are used as assisted computing entire system can fail.
resources where the raw data is stored in distributed cloud None of the aforementioned works have explicitly addressed
storage. Pan et al. [18] designed an edge-IoT framework the issue of storing ever-growing blockchain along with the
called “EdgeChain” based on blockchain and smart contracts. possibility of block removals. Conversely, LiTiChain can be
EdgeChain is a credit-based resource management system applied to all of the above works, whenever there is need for
to control the resources offered to IoT devices by the edge lightweight blockchain which can delete outdated blocks so as
servers. Kang et al. [34] proposed a reputation-based sharing to secure storage spaces for edge servers acting as full nodes.
of vehicle data with consortium blockchain and smart con-
tract. Their scheme is intended for secure and efficient data
III. P ROPOSED M ETHOD
management in the vehicular edge network, where the control
and storage of data is done at the edge nodes which are the A. System Model
roadside units (RSUs). We consider an IoT system consisting of a IoT devices and
The scalability is crucial for the storage of a massive amount a network of edge servers. Each IoT device is associated with
of data collected from IoT devices. Blockchain has been an edge server in the vicinity. Each edge server is responsible
applied to the storage on clouds [35], [36] as well as the dis- for processing and storing data collected from a group of IoT
tributed storage [37], [38]. In the following, we summarize devices, where the edge servers communicate with one another

Authorized licensed use limited to: UNIVERSITY COLLEGE CORK. Downloaded on December 08,2024 at 09:44:46 UTC from IEEE Xplore. Restrictions apply.
PYOUNG AND BAEK: BLOCKCHAIN OF FINITE-LIFETIME BLOCKS WITH APPLICATIONS TO EDGE-BASED IoT 2105

in a peer-to-peer (P2P) manner through the Internet. The edge

nodes may be associated with a single central cloud or multiple
cloud service entities.
IoT devices generate data over time. Any activities on data,
such as access, computation, storage, networking, etc., are
regarded as transactions. The edge servers will use blockchain
for secure record-keeping and control of transactions of IoT
data. We assume that a permissioned blockchain is used such
that only edge servers with permissions can participate in the
blockchain network as a full node. Permissioned chain is also
appropriate for processing transactions with a high throughput.
Because of the lightweight and resource-constrained nature of
IoT devices, the devices only generate and report raw data
to edge nodes. Any activities, such as maintenance, storage,
and computation related to the blockchain, are done by edge
servers. Because a permissioned blockchain is adopted, edge
servers may use a practical Byzantine fault-tolerance (PBFT)
algorithm [46] to reach a distributed consensus. We assume
that the block creation is validated through PBFT. PBFT may
also be used for the block deletion. In case there exist adver-
saries which refuse to accept the deletion, the block is not
deleted and remains in the blockchain until it is validated by
PBFT. Once the validity of a block is verified, the verification
is notified to other edge servers, and a new block is con-
nected to the blockchain of each edge server. This is similar
to verifying the validity of the Bitcoin blockchain.
The edge server has relatively limited storage compared
to, e.g., central cloud servers. Thus, permanently storing the Fig. 1. Construction of EOG in LiTiChain. (a) Block lifetimes and endtimes.
(b) Inserting blocks. (c) Deleting blocks.
full history of IoT transactions can be problematic, especially,
if a large number of IoT devices frequently generate data.
Moreover, the value of event data collected by IoT devices 1) Suppose there exist blocks whose endtime is later than
may depreciate over time. To address scalability issues, we that of the new block bi . Among those blocks, bi is
introduce LiTiChain where outdated blocks can be deleted connected to one with the earliest endtime by a directed
as follows. Each transaction is assumed to have a finite life- edge from bi to the connected block.
time after which the transactions losses value, and thus can be 2) If all of the endtimes of existing blocks are earlier than
deleted from record. A block may contain multiple transactions that of the new block bi , connect bi to the genesis block
with different lifetimes. We define the lifetime of a block as G with a directed edge from bi to G. The lifetime of G
the time from the creation of the block to the latest endtime is assumed to be infinite.
among transactions, where the endtime of a transaction/block The directed graph obtained from the above insertion rule
as the absolute time index at which its lifetime expires. If is called endtime ordering graph (EOG). EOG will have a
the lifetime of a block expires, it can be deleted from the tree topology according to the precedence relation of end-
blockchain to secure storage resource at edge servers. times, where the root node is the genesis block G. For a given
directed edge, we will call the head of the edge as the parent
node, and the tail of the edge as the child node. For block
B. Ensuring Chain Connectivity: Endtime Ordering Graph bi , the parent node of bi according to endtime ordering is
In conventional blockchain with linearly connected blocks, denoted by b∗i throughout this article. Fig. 1 shows an example
if a block is deleted before the endtime of a block which was of constructing EOG. The endtime ei ’s is the blocks is shown
created later, the blockchain will be disconnected. We consider in Fig. 1(a). The insertion of blocks is shown in Fig. 1(b),
structures which ensure the connectivity of blocks as follows. where the numbers in the block represents endtime ei . When
LiTiChain has a graph structure based on the order of endtime the lifetime of a block expires, the block is deleted from the
of the blocks. When a block is created, we create a directed blockchain as shown in Fig. 1(c). We observe that EOG is a
edge emanating from the new block to an existing block. The connected graph at all times because a child node in the tree-
edge direction represents that the hash of the new block is a structured EOG will always have earlier endtime than that of
function of the hash of the connected block. Below we outline its parent node.
how to insert a new block to the existing blockchain. The block
created for the ith time is denoted by bi for i = 1, 2, . . . The C. Increasing Block Height
timestamp at which the ith block is created is denoted by ti , A potential problem with EOG structure is that the height
and the endtime of bi is denoted by ei . of a block, measured as the distance from the block to the

Authorized licensed use limited to: UNIVERSITY COLLEGE CORK. Downloaded on December 08,2024 at 09:44:46 UTC from IEEE Xplore. Restrictions apply.
2106 IEEE INTERNET OF THINGS JOURNAL, VOL. 7, NO. 3, MARCH 2020

Fig. 2. Final graph of blocks is an union of EOG and AOG.

genesis, can be shallow. In other words, the length of the path

starting from a block and following the edge directions track-
Fig. 3. Hash fields in the header of block bi .
ing back to G, can be short. For example, in the rightmost
case, the height of b5 is only 2, although the total number
of blocks excluding G is 5. Thus, in conventional blockchain,
Block Hash: The block header of conventional blockchain
the height of b5 would have been 5. Moreover, unlike conven-
contains the hash of the previous block. By contrast, in
tional blockchains, the total size of blockchain may not always
LiTiChain, there are two fields in the block header which con-
increase due to the deletion of blocks, which may create shal-
tain block hashes. For block bi , we refer to b∗i as ParentBlock
low branches. Longer chains are preferable from the security
and b−i as PreviousBlock. We also define two fields for hashes
perspective, as can be seen from the so-called “longest chain
in the header of block bi as follows.
rule” in Bitcoin blockchain [6]. When multiple new chains are
1) ParentBlockHash: Hash of ParentBlock b∗i of bi .
created in the Bitcoin blockchain, the longest chain (in terms
2) PreviousBlockHash: Hash of PreviousBlock b− i
of the total difficulty) from the genesis block is chosen as the
of bi .
valid chain by miners. The rough idea is that, the longer the
Thus, the first hash implements the directed edge of EOG, and
chain, it would be harder to undo that chain, thus the chain is
the second hash implements the directed edge of AOG. Fig. 3
considered to be more secure.
shows two fields for hashes in the header of block bi .
In order to address that issue, we consider a simple method
to increase the block height of the EOG-based chain. We
consider another graph of linear topology called the arrival D. Retention Cost and K-Height Insertion
ordering graph (AOG). AOG is simply a linear graph accord- Suppose the endtime of a block, say bi , has passed. Then
ing to the order of arrival (creation) of blocks. Upon creation bi is an expired block and should be deleted from the chain.
of a new block, say bi , we form a directed edge from bi to However, suppose there was block bi+1 which arrived next
the previously and most recently created block in the chain to bi and its endtime ei+1 was later than ei . Because bi+1 is
which is denoted by b− i . For example, if bi−1 exists in the not expired yet, bi should not be deleted from the blockchain
chain and was not deleted when bi is created, then we have because bi is necessary for verifying the validity of bi+1 . In
b−i = bi−1 . AOG has the linear linked-list structure of the con- this case, our rule is that bi must remain in the chain until
ventional blockchain. LiTiChain is obtained by merging EOG the expiry of bi+1 . This incurs extra storage cost because bi
and AOG; specifically, we take a union of the sets of edges of must be retained beyond its endtime, and its expiry time is
AOG and EOG. Thus, for block bi , there will be two directed effectively extended. The storage cost of data is defined to
edges emanating from bi , one to b∗i and the other to b− i , deter- be the product of the data size and its storage time. RC of a
mined from EOG and AOG, respectively. If b∗i = b− i , bi has block is defined to be the additional storage cost incurred by
one parent, and there will be only one edge from bi to b∗i . The the extended expiration time of the retained block.
height of a block is now defined as the maximum distance path The retention mechanism maintains the “hash-chained”
on the edge union starting from the block to G. Note that the property of the blockchain. This is because the validity of an
height of a block is also equivalent to the length of the path to arbitrary block and the blocks preceding it can be recursively
G in AOG which is same as the height in Bitcoin blockchain. verified for validation by the associated ParentBlockHash
An example is shown in Fig. 2. On the right of Fig. 2 is and PreviousBlockHash, because both ParentBlock and
the AOG, and on the left shows the final form of LiTiChain PreviousBlock of a block to be verified always exist in the
obtained from the union of EOG and AOG. The height of b4 chain during the block’s lifetime (the former precedes in life-
is 2 under EOG only; however, the height increases to 4 after time, and the latter is retained) and are available for validation.
merging. Note that PreviousBlockHash field in the header through

Authorized licensed use limited to: UNIVERSITY COLLEGE CORK. Downloaded on December 08,2024 at 09:44:46 UTC from IEEE Xplore. Restrictions apply.
PYOUNG AND BAEK: BLOCKCHAIN OF FINITE-LIFETIME BLOCKS WITH APPLICATIONS TO EDGE-BASED IoT 2107

Fig. 4. RC incurred by the extended expiration time of a block.

which the block validity can be verified is similar to the field

of previous block hash in Bitcoin blockchain.
An example is shown in Fig. 4. The endtime of block b2 is
e2 = 30. However, b2 cannot be deleted at e2 , but must remain Fig. 5. Example with varying K.
in the chain until t = 40, which is the endtime of block b3 . 2) Permanent: The lifetime is infinite at the time of
Thus, the expiry time of b2 is extended by 10 time units. If b2 creation.
in the example has size 1MB and 10 extra seconds to remain 3) Indefinite: The lifetime is not known, but can be
in the chain, the RC of bi is 10 MB·sec. expired at any time.
Limiting Block Height: The total RC of the chain will tend The deletion of indefinite-type transactions can be requested
to increase as the total number of blocks. One way to allevi- at any time. However, the transaction or its containing block
ate this problem is to limit the number of edges coming from is not deleted immediately upon request; such deletion would
AOG. For that purpose, we propose K-height block insertion be inconsistent with the construction of LiTiChain. Instead,
for some integer parameter K as follows. Suppose we wish to we assume that blocks containing indefinite-type transactions
create a new block bi , we create two edges: 1) one connect- are renewed periodically as follows.
ing to ParentBlock b∗i and 2) the other to PreviousBlock b− i . The renewal of a block is creating a new copy of the
Assume b∗i = b− i . We propose the following: create an arrival block and then deleting the block. The new block contains
ordering edge to b− ∗
i only if the height of bi is less than K. indefinite-type transactions copied from the original block. At
∗
1) Suppose the height of bi is less than or equal to K. Then the time of creation of a block, the lifetime of indefinite-type
the arrival ordering edge to b−i will be created as usual. transactions are set to D, where D is a system parameter.
2) Suppose the height of b∗i is greater than K. Then Depending on applications, D may vary among indefinite-type
we do not create the edge to b− i , and RC will not blocks. Setting D too short would incur the overhead of fre-
incur for block bi . Both ParentBlockHash and quent renewals, whereas setting D too long would result in
PreviousBlockHash are set to the hash of b∗i . the late deletion of the block. For example, D can be sim-
The idea is that if the height of a block is more than K, we ply set on the order of days, months, or years, depending on
consider its height to be sufficient, and focus on minimizing the nature of associated transactions and can be determined
the overall RC of the chain by removing the arrival ordering by the entity which issues the deletion request. Suppose that
edge. Parameter K can range from 0 to ∞. K = 0 means that the lifetime of a block expires and needs to be deleted. The
our blockchain is constructed based only on EOG, in which block is checked if it contains indefinite-type transactions. If
RC is always zero. K = ∞ means that the height of any so, a new block with lifetime D is created containing the copy
block will be equal to the number of previously created blocks of those indefinite-type transactions, and the original block is
existing in the current chain, providing the maximum possible deleted. It is possible that a request for deletion of a transac-
height to all the blocks. tion may occur during the lifespan of the block. However, the
Fig. 5 shows an example of blockchain with K. As K block containing the transaction is not deleted until the next
changes from 1 to 4, the height of b6 increases to 4, 5, and 6 renewal of the block. Instead, at the next cycle of renewal,
and the total RC increases to 20, 39, and 56. Clearly, there such transactions are excluded from the new block. This is
exists a tradeoff, reducing storage cost incurred by expiry consistent with the construction of LiTiChain. Besides, if there
extension versus providing greater height to the blocks for are multiple indefinite-type transactions with similar renewal
enhanced security. Thus, K is a tunable parameter, and we will times, those transactions can be grouped and put into a single
explore how K affects the storage cost and average height in indefinite-type block at the time of renewal.
the simulation section. In summary, the rules for renewal are as follows. Suppose
a block is scheduled to be deleted at time t, then at time t.
E. Indefinite Lifetimes 1) Check if the block contains indefinite transactions which
It is possible that the lifetime of a transaction is not decided are not requested to be deleted.
at the time of creation. Such transactions are referred to have 2) If so, create a new block containing only those transac-
indefinite lifetimes. We categorize transactions into three types tions and insert the block to blockchain. The block is
according to their lifetime properties. scheduled to be renewed at t + D.
1) Fixed: The lifetime is known at the time of creation. 3) Delete the old block.

Authorized licensed use limited to: UNIVERSITY COLLEGE CORK. Downloaded on December 08,2024 at 09:44:46 UTC from IEEE Xplore. Restrictions apply.
2108 IEEE INTERNET OF THINGS JOURNAL, VOL. 7, NO. 3, MARCH 2020

Algorithm 1 K-Height Insertion of a Block

1: Output : Newly created block bi with endtime ei
2: Given : renewal period D, height constraint K, transactions
τ1 , . . . , τm
3: /∗ Determining endtime ei ∗/
4: Set ei be the maximum of the endtimes of τ1 , . . . , τm .
If some τj is of indefinite-type, regard its endtime as the
current time plus D.
5: /∗ Determining the parent block
according to endtime ordering ∗/
6: j∗ ← min{j|ei ≤ ej }
7: b∗i ← bj∗
8: Let d denote the height of parent block b∗i .
9: /∗ Determining the previous block
according to arrival ordering ∗/
10: l∗ ← maxl=0,1,...,i−1 {l|block bl exists in the chain}
/∗ Constraining height of the new Fig. 6. Example of ExpiryTime and DeletionTime.
block ∗/
11: if d > K then
12: b−i ← bi
∗ 2) PreviousBlockHash: Explained in Section III-C.
13: else 3) ExpiryTime: The time of the expiration of the block
14: b−i ← bl∗
lifetime.
15: end if ExpiryTime is set to the endtime of a block which is
16: Create block bi . Add transactions τ1 , . . . , τm to bi . In the obtained by adding the lifetime of the block to the times-
header of bi , do the following: tamp at which the block is created. A block will be deleted
17: Set timestamp field ti to the current time. from the chain if ExpiryTime has passed, except that its
18: Set ParentBlockHash field to Hash(b∗i ). expiry is extended by the next block. Thus, a node must sepa-
19: Set PreviousBlockHash field to Hash(b− i ).
rately maintain another variable for each block, which we call
20: Set ExpiryTime field to ei . DeletionTime. DeletionTime of a block, say bi , is ini-
21: Set DeletionTime variable for block bi to ei . tially set to the endtime ei . If later block j is created, and bj
refers to bi such that bi = b− j and ei < ej , DeletionTime
field of bi is extended to ej , so that bi is not deleted until
the expiry of bj . In summary, ExpiryTime represents the
Block renewal can be used for maintaining the overall block
expiration of the transaction data within the block, whereas
height as follows. In case the lifetimes of blocks created ear-
DeletionTime simply indicates when this block should be
lier are short overall, and as a result, most of the intermediate
deleted. Note that only ExpiryTime is recorded at the block,
nodes in AOG are deleted, the maximum distance paths from
but DeletionTime is a changing variable and thus is not
blocks to G will tend to be short, decreasing the overall
recorded in the block because the block is not modifiable by
block heights. This can be fixed by intermittently creating
definition.
bogus blocks in order to increase the heights as follows. The
An example is shown in Fig. 6. At t = 5, b1 is expired
bogus blocks contain empty transactions and have indefinite
without being deleted, because b2 has reference to b1 by b1 =
lifetimes. The system can track, e.g., the average maximum
b−2 and e1 < e2 . At t = 10, b1 is deleted and b2 is expired
heights of blocks, and bogus blocks can be generated trig-
but is not deleted due to the reference by b3 . In case of b3 ,
gered by the event that the measured height falls below certain
because there is no block referring to b3 , expiry and deletion
threshold. The purpose of bogus blocks is for keeping a suf-
of b3 occur simultaneously at t = 15.
ficient number of blocks in the chain to maintain its overall
height. The bogus blocks can be either renewed or deleted
B. Block Deletion and Renewal
depending on the average maximum heights of the chain at
the time of renewal. Algorithm 2 shows the procedure to delete or renew a
block. For every block, if its DeletionTime is reached,
Algorithm 2 is executed. Note that if the current block to
IV. A LGORITHM
be deleted contains indefinite-type transactions which are not
A. Block Creation and Insertion requested for deletion, a new block will be created contain-
The algorithm of K-height insertion of the ith block to ing a copy of those transactions. The timestamp of the new
the blockchain is outlined in Algorithm 1. The block format block is equal to that of the original block, since the timestamp
of the proposed blockchain is similar to that of conven- represents the creation time of the transactions. The expiration
tional blockchain, except that the block header has following and deletion time is set to D time units after; at the expiration,
additional fields. there will be the renewal of this new block, and the process
1) ParentBlockHash: Explained in Section III-C. repeats. Eventually, if all the transactions are requested for

Authorized licensed use limited to: UNIVERSITY COLLEGE CORK. Downloaded on December 08,2024 at 09:44:46 UTC from IEEE Xplore. Restrictions apply.
PYOUNG AND BAEK: BLOCKCHAIN OF FINITE-LIFETIME BLOCKS WITH APPLICATIONS TO EDGE-BASED IoT 2109

Algorithm 2 Deletion/Renewal of a Block

1: Given : Block bi to be deleted/renewed
2: if bi contains indefinite-type transactions τ1 , . . . , τm which
are not requested for deletion then
3: Create block bj . Do K-height insertion of bj with:
4: Add transactions τ1 , . . . , τm to bj .
5: Set timestamp of bj as ti (timestamp of bi ).
6: Set ExpiryTime field and DeletionTime variable
to current time plus D
7: end if
8: Delete bi

Fig. 7. Example of block renewal.

deletion, the block and transactions will be completely erased
from the chain.
An example of block renewal is shown in Fig. 7. Suppose Proof: Suppose the lifetime of the typical block at t = 0 is
a block contains three transactions Tx 1, 2, and 3, where Tx 1 in [x, x+dx) which occurs with probability ≈ g(x)dx. Because
and 3 are of indefinite type and Tx 2 is of fixed type. The RC depends only on the block arrived right next to the typical
lifetime of Tx 1 and 3 is given by D, and suppose D is longer block but not on others. Thus, we consider the probability that
than the lifetime of Tx 2. The lifetime of the block is set to the next block at [y, y + dy) which is given by
D and is scheduled to be deleted at time t + D. At time t + D,
the lifetime of Tx 2 is expired and none of the indefinite-type exp(−λy) · λ dy.
transactions have been requested for deletion. Thus, the block
is renewed and the new block contains the copy of Tx 1 and 3, This is because there must be no arrival from  during time
and is scheduled to be deleted (renewed) at time t + 2D. Then, interval [0, y) which occurs with exp(−λy), and the probability
before time t + 2D, there was a request for deletion of Tx 1. of arrival in [y, y + dy) is given by λdy. Suppose that the
Then at time t + 2D, the block is renewed and only Tx 3 is lifetime of the next block is in [z, z + dz), which occurs with
included in the new block. probability ≈ g(z)dz. The RC will incur if:
1) the arrival of the next block is earlier than the expiration
of the lifetime of the typical block;
V. A NALYSIS 2) the lifetime of the next block is longer than the residual
In this section, we analyze how RC contributes to the total lifetime of the typical block.
storage cost. Due to the dynamic nature of creation and dele- The conditions are given by y ≤ x and z ≥ x − y, respectively.
tion of blocks, it is difficult to analyze RC for general cases. Because the block has unit size, the incurred RC is given by
Thus, for analytical tractability, we consider two cases: 1) the
average cost analysis when the block creation times constitute 1(y ≤ x) · 1(z ≥ x − y) · {z − (x − y)}
a stationary Poisson process and 2) the worst-case analysis with the associated probability
for a finite number of blocks. Throughout the analysis, it is
assumed that each block has the unit size. We also assume g(x)dx · λ exp(−λy)dy · g(z)dz
that all the transactions have fixed-type lifetimes.
which results in (1).
The RC can be regarded as the additional amount of time
A. Average RC for Poisson Arrivals of Blocks the block needs to stay at the chain. Assume that the mean
Suppose the blocks are created at time instants according to lifetime is given by μ−1 for some μ > 0. Thus, the mean
homogeneous Poisson process  with rate λ. The lifetime of occupation time of a typical block is given by
blocks is independent and identically distributed with probabil- 1
ity density function (pdf) g(·). Let E0 denote the expectation E0 [C] + .
μ
with respect to the Palm distribution P0 with respect to the
block arrival process . The Palm distribution [47] P0 is con- The mean arrival rate of the blocks to the system is λ. Thus,
ditional on the “typical” block being created at time 0. The by Little’s formula, the mean storage space occupied by the
framework of Palm distribution is useful for evaluating the chain is given by
costs viewed from a typical block, i.e., informally speaking, a  
1
block randomly selected from the arrival process without bias. λ E0 [C] +
μ
Theorem 1: Let C denote the RC seen by a typical block
from . We have that which is the mean number of blocks in the chain in the steady
 ∞ x ∞ state.
E [C] = λ
0
(z − x + y)e−λy g(z)g(x)dz dy dx. Theorem 1 enables us to evaluate the mean RC in closed
0 0 x−y form for some types of lifetime distributions. For exam-
(1) ple, suppose the lifetimes of blocks are independently and

Authorized licensed use limited to: UNIVERSITY COLLEGE CORK. Downloaded on December 08,2024 at 09:44:46 UTC from IEEE Xplore. Restrictions apply.
2110 IEEE INTERNET OF THINGS JOURNAL, VOL. 7, NO. 3, MARCH 2020

exponentially distributed with parameter μ, that is from S and denote the ith smallest number by li . We have the
following relation among si ’s and li ’s:
g(x) = μ exp(−μx), x ≥ 0.
0 = s1 < s2 < · · · < s n < l1 < l2 < · · · < l n .
2 2
Then, we get from (1)
⎧ Note that strict inequalities hold because endtimes are distinct.
⎪
⎪ 1 Theorem 2: We have that
⎨ , λ=μ
E0 [C] = 4μλ  T n
2
⎪
⎪
1
−
1
, λ = μ. [N∞ (t)dt − N0 (t)]dt ≤ (li − si ).
⎩
μ − λ λ + μ 2μ 0 i=1
We prove the theorem by following the proof outlined
B. Worst-Case RC in [48] which proposes the string reversal algorithm which
Next, we consider deterministic setup which yields the worst will be explained in the sequel. Define f (x) := max(x, 0).
possible RC. The goal is to obtain an upper bound on the Lemma 1: For any real numbers s1 , s2 < l1 , l2
incurred RC. We consider the RC associated with a finite
number of blocks during a finite-time horizon. f (l1 − s1 ) + f (l2 − s2 ) > f (l1 − l2 ) + f (s1 − s2 ).
Assumption 1: Our assumptions for analysis are as follows. Proof: The proof for Lemma 1 is similar to proof of
1) A total of n blocks b1 , . . . , bn with endtimes e1 , . . . , en [48, Lemma 1]. For s1 , s2 < l1 , l2 , we have inequalities
are created in sequence.
2) The blocks have distinct endtimes. l2 > s 1
3) The last block bn is created before the earliest endtime (l2 − s2 ) > (s1 − s2 )
among all the blocks. (l1 − s1 ) > (l1 − l2 )
Due to Assumption 1 3), no blocks are deleted until all of
(l1 − s1 ) + (l2 − s2 ) > (l1 − l2 ) + (s1 − s2 ). (2)
the n blocks are created. Also from the assumptions, RC is
completely determined by the ordering of e1 , . . . , en . We con- From (2), we can show the following in four cases.
sider the ordering for the worst possible RC, which gives an 1) If l1 > l2 and s1 > s2
upper bound of RC for all possible cases. Below, we formu-
late the worst-case analysis as the combinatorial optimization f (l1 − s1 ) + f (l2 −s2 ) > f (l1 − l2 ) + f (s1 − s2 ).
problem. 2) If l1 > l2 and s1 ≤ s2
We will consider the total storage costs for cases of K = ∞
and K = 0. We will compare two cases, because evaluating f (l1 − s1 ) + f (l2 − s2 ) > f (l1 − l2 ).
case K = ∞ will give a full account of RC in our scheme, 3) If l1 ≤ l2 and s1 > s2
whereas no RC will be incurred under case K = 0. Let N∞ (t)
and N0 (t) denote the total number of blocks in the blockchain f (l1 − s1 ) + f (l2 − s2 ) > f (s1 − s2 ).
at time t with K = ∞ and K = 0, respectively. Assume
4) If l1 ≤ l2 and s1 ≤ s2
b1 is created at time 0, and let T denote the latest endtime
among e1 , . . . , en . We would like to compare the total storage f (l1 − s1 ) + f (l2 − s2 ) > 0.
cost incurred during the lifetime of the chain. Because the
blocks have unit size, the total storage cost for case K = ∞ From (2) and the above four cases, Lemma 1 is proved.
is given by Let X be an ordered sequence of n numbers x1 , . . . , xn .
Define
 T
n−1
N∞ (t)dt
0 C(X) = f (xi+1 − xi ).
i=1
that is, it is the area under N∞ (t) by definition. Similarly,
T
we consider 0 N0 (t)dt which is also equal to the sum of the Lemma 2: Consider sequence X that is an arbitrary per-
lifetime of the blocks. The total RC of case K = ∞ is then mutation of s1 , s2 , . . . , l1 , l2 , . . . ,. We can find permutation
given by X ∗ which maximizes C(X) by successively applying a string
 T reversal algorithm [48] to X. We have that
[N∞ (t) − N0 (t)]dt n
2
0 ∗
C(X ) = (li − si ).
for which we will find an upper bound. i=1
We introduce the following notations. Denote the earliest
Proof: We will follow similar arguments as those of
endtime by ê. Consider set S such that
[48, Lemma 2]. We consider the even and odd cases of n.
S := {e1 − ê, e2 − ê, . . . , en − ê}. Case 1 (n = 2k): Consider X1 which is an arbitrary per-
mutation of s1 , s2 , . . . , l1 , l2 , . . . Suppose we apply the string
Consider (n/2) smallest numbers of S and denote the ith reversal algorithm to X1 , change it to X2 as follows. We say X
smallest number by si . Next, consider the rest of numbers is in alternating arrangement [48] if the odd-indexed elements

Authorized licensed use limited to: UNIVERSITY COLLEGE CORK. Downloaded on December 08,2024 at 09:44:46 UTC from IEEE Xplore. Restrictions apply.
PYOUNG AND BAEK: BLOCKCHAIN OF FINITE-LIFETIME BLOCKS WITH APPLICATIONS TO EDGE-BASED IoT 2111

of X or x1 , x3 , x5 , . . . is some permutation of small values The upper bound is achieved if e1 , . . . , en are in alter-
s1 , s2 , . . . and the even-indexed elements of X are a permuta- nating arrangement such that endtimes with odd indices
tion of l1 , l2 , . . . Suppose X1 is not in alternating arrangement, e1 , e3 , e5 , . . . are given by some permutation of small endtimes
we regard X1 as a string and operate on a substring of X1 which ê + s1 , ê + s2 , ê + s3 , . . . , and the endtimes with even indices
is not alternating such that are given by some permutation of large endtimes ê + l1 , ê + l2 ,
ê + l3 , . . .
X1 = , . . . , s3 , [s4 , . . . , l2 ], l3 , . . .
We provide a looser bound on the ratio of storage costs
X2 = , . . . , s3 , [l2 , . . . , s4 ], l3 , . . . when n is even. We show that the storage overhead due to RC
That is, the substring in the bracket of X1 is reversed in order is at most twice the storage cost without RC.
to yield the substring in the brackets in X2 . We can write C(X1 ) Corollary 1: Suppose n is even. We have that
and C(X2 ) as follows: T
0 N∞ (t)dt
k
2 i=1 li
C(X1 ) =  + f (s4 − s3 ) + f (l3 − l2 ) T
≤ k
≤ 2.
0 N0 (t)dt i=1 (si + li )
C(X2 ) =  + f (l2 − s3 ) + f (l3 − s4 )
Proof: Let n = 2k. Clearly we have that
where  means the common cost for X1 and X2 . By Lemma 1,
we have that C(X2 ) > C(X1 ).  T k
This implies that we can successively apply string rever- N0 (t)dt = nê + (si + li )
sal algorithm to X and increase the cost function C(X) 0 i=1
until X is in alternating arrangement. Due to the property
of f , it is clear that all strings X in alternating arrange- which implies that, by Theorem 2
ment have the same cost. Specifically, consider X ∗ =  k k
T
s1 , l1 , s2 , l2 s3 , l3 , . . . , sk−1 , lk−1 , sk , lk . We have that for arbi- N∞ (t)dt ≤ nê + (si + li ) + (li − si )
trary string X 0 i=1 i=1
C(X) ≤ C(X ∗ ) k
= nê + 2 li .
= (l1 − s1 ) + (s2 − l1 ) + (l2 − s2 )
i=1
+ · · · + (sk − lk−1 ) + (lk − sk )
k k Thus, we have that
= li − si . T
0 N∞ (t)dt
k k
nê + 2 i=1 li 2 i=1 li
i=1 i=1
T
≤ k
≤ k
Case 2 (n = 2k +1): The proof is nearly identical to case 1. 0 N0 (t)dt nê + i=1 (si + li ) i=1 (si + li )
We can show that the maximum cost is achieved by alternating k
2 i=1 li
arrangement of string. The maximum cost can be achieved by ≤ k
=2
string X ∗ = s1 , m, l1 , s2 , l2 s3 , l3 , . . . , sk−1 , lk−1 , sk , lk , where i=1 li
m is the k + 1th largest number, or the element in the middle for which we used ê ≥ 0 and li > si ≥ 0 for all i.
of string s1 , s2 , . . . , l1 , l2 , . . . We have that
C(X) ≤ C(X ∗ ) VI. P ERFORMANCE E VALUATION
= (m − s1 ) + (l1 − m) + (l2 − s2 )
In this section, we evaluate the performance of our
+ · · · + (lk−1 − sk−1 ) + (lk − sk ) blockchain system through simulation. We focus on evaluating
k k average storage occupied by blocks and average block heights.
= li − si .
i=1 i=1
A. Performance Metrics
Proof of Theorem 2: The RC for case K = ∞ is bounded As previously, let N(t) denote the number of blocks in
above as follows. By definition, the RC of block i is given by the chain at time t. We assume all the blocks have the unit
max(ei+1 −ei , 0) = f (ei+1 −ei ). Thus, the total RC is given by size. Thus, the average storage space occupied by the chain
n−1
is proportional to N(t). We define the time average of storage
occupied by the chain by
C= f (ei+1 − ei ).

i=1 1 T
T N := lim N(t)dt.
Note 0 N0 (t)dt is simply the sum of the lifetimes of the T→∞ T 0
T
blocks. Also due to Assumption 1, we have that 0 N∞ (t)dt =
T We define the longest path from the newly created block to the
C + 0 N0 (t)dt. From Lemma 2, we have that genesis block as the height of a block. The average height D
n
2 is defined as taking the average block heights over all blocks
C≤ (li − si ). in the chain measured at the instants of block creation and
i=1 deletion.

Authorized licensed use limited to: UNIVERSITY COLLEGE CORK. Downloaded on December 08,2024 at 09:44:46 UTC from IEEE Xplore. Restrictions apply.
2112 IEEE INTERNET OF THINGS JOURNAL, VOL. 7, NO. 3, MARCH 2020

Fig. 8. Distribution of lifetime. (a) Operation time distribution from taxi trip record. (b) Distribution of Z. (c) Distribution of Ẑ. (d) Distribution of Z̃.

B. Simulation Settings Case 2: We hypothesize that if the lifetime has a bimodal

We used the MATLAB tool to implement the proposed algo- distributions with modes at small and large lifetime values, i.e.,
rithms and to perform simulation for three different types lifetimes are either very short or very long, it would worsen
of lifetime distributions. In the simulation, only fixed-type the cost overhead due to RC. The rationale is that the blocks
transactions were considered. with short lifetime suffer relatively more from the amount of
Case 1: In order to use realistic IoT data with lifetimes, time held back by blocks with long lifetimes. In order to obtain
we chose the data set published by the New York City Taxi lifetime data with a bimodal distribution, we produced lifetime
and Limousine Commission (TLC) on trip record data for data sampled from Z which is a mixture of two Gaussian
yellow taxis in December 2018 [49]. We extracted 10 000 distributions as follows:

data points of operating times ranging between 301 and Z1 , w.p. 0.5
Z=
4000 s from the population of 8 million data points. The Z2 , w.p. 0.5
operating time is the time difference between the engage-
ment and disengagement of the taximeter for a passenger where Z1 ∼ N(300, 1102 ) and Z2 ∼ N(1200, 1102 ). We
group. sampled 10 000 lifetime data from Z. Fig. 8(b) shows the
In addition to the taxi data set, we assumed that each distribution of Z.
taxi will generate some event data every 1 s during a trip. Case 3: In order to compare the RC generated by the change
This event data can be considered as monitoring information, in the mixing proportion in the Gaussian mixture, case 3 has
such as real-time taxi fare, location, and speed. Indeed, if the same settings as case 2 except for the mixing proportions.
autonomous taxi vehicles become prevalent in the near future, We consider two cases of lifetime distributions as follows:

such real-time monitoring data of vehicles will be generated Z1 , w.p. 0.1
Ẑ = (3)
in high volume. We assume such event data is reported to the Z2 , w.p. 0.9

edge servers. The event data is considered as “transactions” Z1 , w.p. 0.9
Z̃ = (4)
which will be stored in our blockchain in the simulation. We Z2 , w.p. 0.1.
assume that a block is created every 5 min; thus, a block
contains 300 transactions. We also assume that the size of Fig. 8(c) and (d) shows the distribution of (3) and (4),
each block is 1 MB. In our blockchain, the trip record data respectively.
and event data are used as the transactions to be stored. The
operating time is defined as the lifetime of those transactions. C. Simulation Results
Fig. 8(a) shows a distribution of operation times from the taxi Fig. 9(a)–(c) shows the simulation results for trip record data
trip record. of New York taxi (case 1). Fig. 9(d)–(f) shows the results for

Authorized licensed use limited to: UNIVERSITY COLLEGE CORK. Downloaded on December 08,2024 at 09:44:46 UTC from IEEE Xplore. Restrictions apply.
PYOUNG AND BAEK: BLOCKCHAIN OF FINITE-LIFETIME BLOCKS WITH APPLICATIONS TO EDGE-BASED IoT 2113

(a) (b) (c)

(d) (e) (f)

Fig. 9. Average total storage, total storage cost ratio, and height under LiTiChain.

bimodally distributed lifetime (case 2). Fig. 9(a) and (d) shows originally short lifetime, but are changed to have the long life-
the average storage cost against varying values of height con- time, will take about 25% of the total blocks. This is 50%
straint K. Fig. 9(a) and (d) shows the plots of storage occupied increase in the proportion of the blocks with a long lifetime.
by blocks averaged over time interval [0, W] against window Assuming the blocks with the long lifetime will occupy most
value W. We observe that the average storage blows up for of the total storage, the overhead of RC will be close to 50% of
conventional blockchain because it permanently stores all the the baseline storage. From Fig. 9(e), we indeed observe that the
incoming transactions. However, for our schemes, the average overhead due to RC rises over 40% if K = ∞. Interestingly,
storage converges quickly to stable values. similar overhead is observed in Fig. 9(b) with lifetime dis-
Fig. 9(b) and (e) shows the average storage N for varying tribution with single tail given by Fig. 8(a). This seems to
height constraint K. The baseline case is K = 0, and the aver- be because most of the blocks have a short lifetime from the
age storage for changing K is normalized to the baseline in shape in Fig. 8(a). Thus, if blocks with short lifetimes are
the figures. Fig. 9(b) and (e) shows the average storage are referred to by a few blocks with long lifetime, the increased
about 100%–142% and 100%–140% of the baseline storage overhead in the RC is expected to be significant to the overall
depending on K. Note that Fig. 9(b), (c), (e), and (f) is plotted storage.
against a set of K values, and their horizontal axis is not to Blocks Generated in Bursts: Next, we consider the case
scale. By controlling height constraint K from 0 to ∞, we where blocks are generated in bursts. Specifically, we eval-
achieve varying degrees of the tradeoff between security and uate the storage cost of a finite number of, say n, blocks,
storage costs. As K becomes larger, the average height of the where all the n blocks are created during a short time period
blocks increases, strengthening the security of the chain. With relative to their lifetimes. Note that this setup is similar to
smaller values of K, the block heights tend to be shallow, Assumption 1 in the RC analysis. Our goal is to compare the
however, the overall RC will decrease, leading to a reduced RC from worst case analysis with the RC from the previous
storage requirement for the blockchain. data sets. We proved that the maximum RC incurs if the end-
Let us compare the performances of cases 1 and 2. We times are in alternating arrangement. In the simulation, we
observe that the overhead due to RC tends to be similar for compare the theoretical worst-case cost with the cases the end-
cases 1 and 2. For case 2, we may consider the following times of blocks are in a random arrangement according to the
back-of-the-envelop calculation on the overhead due to RC. data sets.
Suppose the lifetime can take only two values: 1) very long and In the simulation, 50 blocks are created in burst, where the
2) very short. Assume that the probability of a block having block lifetimes are sampled from the distributions of cases 1
either length of lifetime is 0.5. Then roughly half of the total and 2. We assume that the blocks are created at distinct time
blocks will be created with the short lifetime. Furthermore, instants but within a negligibly short period of time, so that
roughly half of those will be referred to by a block with the the order of block endtimes is equal to that of the lifetimes.
long lifetime which arrived next to it. Thus, the blocks with For each case, the storage costs for K = 0 and K = ∞

Authorized licensed use limited to: UNIVERSITY COLLEGE CORK. Downloaded on December 08,2024 at 09:44:46 UTC from IEEE Xplore. Restrictions apply.
2114 IEEE INTERNET OF THINGS JOURNAL, VOL. 7, NO. 3, MARCH 2020

(a) (b)

(c) (d)

Fig. 10. Average total storage cost ratio under burst data.

are compared with the worst case in which the lifetimes are total storage cost is relatively low. In case, Fig. 10(d), there
reordered such that they are exactly in alternating arrangement. are many blocks with short lifetime, and there will be a few
Fig. 10(a) and (b) shows the comparison for the data sets in blocks held back by long-lived blocks. However, if they get
cases 1 and 2, respectively. The storage costs are averaged over retained by long-lived blocks, the relative increase in the stor-
200 times for each plot. The cost ratio of K = ∞ (resp. the age cost is high. The ratio of retained short-lived blocks and
worst case) relative to baseline with no RC (K = 0) is about its effect on the total storage cost is most “balanced” in the
136% (resp. 149%) in case 1. For case 2, the ratio is similar, case of Fig. 10(c), i.e., at the mixing proportion of 0.5 as in
given by 133% and 155%, respectively. The gap of cost ratio case 2, which yields the highest overhead due to the RC.
between K = ∞ and the worst case is higher for bimodal
distributions (13% versus 21%). This shows that indeed with
bimodal distribution in which short-lived blocks are held back VII. C ONCLUSION
by long-lived blocks, the worst case with alternating arrange- In this article, we proposed LiTiChain, a blockchain with
ment can do much worse than randomized arrangement. In finite-lifetime blocks, which is suitable for edge-based IoT
reality, it is unlikely that the alternating arrangement occurs systems. Through LiTiChain, we address the problem of con-
by chance; nonetheless, it is useful to know the upper bound ventional blockchain such that it is a permanently growing list
on the additional costs required to store the blockchain in its of information chunks. The issue of storing long blockchains
entirety. at full nodes can be resolved, if the outdated information
Next, we examine how the RC is affected by the change in can be removed in a timely manner. We introduced a tree-
the mixing proportion of the Gaussian mixture in the lifetime structured EOG which organizes the blocks according to their
distribution. Fig. 10(c) and (d) shows the storage cost ratio endtimes, so that the blocks can be deleted in an orderly fash-
for (3) and (4) in case 3, respectively. The cost ratio of case ion while maintaining the connectivity of the chain. In order to
K = ∞ (resp. the worst case) to case K = 0 is about 112% achieve various degrees of tradeoff between RC and the over-
(resp. 115%) for (3). For (4), the cost ratio is given by 133% all block heights, we proposed K-height block insertion. We
and 143%, respectively. We see that the relative overhead due also proposed the block renewal methods so as to deal with
to RC is in the order of (b) > (d) > (c) for the distributions transactions with indefinite lifetimes. The simulation results
in Fig. 10. The result can be explained as follows. In case of demonstrated the effect of the aforementioned tradeoff on the
distribution, Fig. 10(c), because most blocks have long life- total storage costs depending on the properties of lifetime
times, and thus most short-lived blocks are likely to be retained distributions. Future work will include devising a permission-
by long-lived blocks. However, the proportion of short-lived less version of erasable blockchains with insertion/deletion
blocks is small in the first place; thus the effect of RC on the throughputs acceptable for the IoT systems.

Authorized licensed use limited to: UNIVERSITY COLLEGE CORK. Downloaded on December 08,2024 at 09:44:46 UTC from IEEE Xplore. Restrictions apply.
PYOUNG AND BAEK: BLOCKCHAIN OF FINITE-LIFETIME BLOCKS WITH APPLICATIONS TO EDGE-BASED IoT 2115

R EFERENCES [25] A. Dorri, M. Steger, S. S. Kanhere, and R. Jurdak, “Blockchain: A

distributed solution to automotive security and privacy,” IEEE Commun.
[1] (Jan. 2019). IoT Report: How Internet of Things Technology Growth Is Mag., vol. 55, no. 12, pp. 119–125, Dec. 2017.
Reaching Mainstream Companies and Consumers. [Online]. Available: [26] O. Novo, “Blockchain meets IoT: An architecture for scalable access
https://www.businessinsider.com/internet-of-things-report management in IoT,” IEEE Internet Things J., vol. 5, no. 2,
[2] M. A. Ferrag, M. Derdour, M. Mukherjee, A. Derhab, L. Maglaras, pp. 1184–1195, Apr. 2018.
and H. Janicke, “Blockchain technologies for the Internet of Things:
[27] J. Wan, J. Li, M. Imran, D. Li, and F. E. Amin, “A blockchain-based
Research issues and challenges,” IEEE Internet Things J., vol. 6, no. 2,
solution for enhancing security and privacy in smart factory,” IEEE
pp. 2188–2204, Apr. 2019.
Trans. Ind. Informat., vol. 15, no. 6, pp. 3652–3660, Jun. 2019.
[3] S. K. Lo et al., “Analysis of blockchain solutions for IoT: A systematic
literature review,” IEEE Access, vol. 7, pp. 58822–58835, 2019. [28] E. Zaghloul, T. Li, and J. Ren, “An attribute-based distributed data shar-
[4] V. Hassija, V. Chamola, V. Saxena, D. Jain, P. Goyal, and B. Sikdar, “A ing scheme,” in Proc. IEEE Global. Commun. Conf. (GLOBECOM),
survey on IoT security: Application areas, security threats, and solution 2018, pp. 1–6.
architectures,” IEEE Access, vol. 7, pp. 82721–82743, 2019. [29] H. R. Hasan and K. Salah, “Proof of delivery of digital assets using
[5] M. Wu, K. Wang, X. Cai, S. Guo, M. Guo, and C. Rong, “A com- blockchain and smart contracts,” IEEE Access, vol. 6, pp. 65439–65448,
prehensive survey of blockchain: From theory to IoT applications and 2018.
beyond,” IEEE Internet Things J., to be published. [30] J. Benet and N. Greco. (2017). Filecoin: A Decentralized Storage
[6] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” White Network. [Online]. Available: https://filecoin.io/filecoin.pdf
Paper, 2008. [31] W. Tong, X. Dong, Y. Shen, and X. Jiang, “A hierarchical sharding
[7] Z. Zheng, S. Xie, H.-N. Dai, X. Chen, and H. Wang, “Blockchain chal- protocol for multi-domain IoT blockchains,” in Proc. IEEE Int. Conf.
lenges and opportunities: A survey,” Int. J. Web Grid Services, vol. 14, Commun. (ICC), 2019, pp. 1–6.
no. 4, pp. 352–375, 2018. [32] J. Poon and V. Buterin, “Plasma: Scalable autonomous smart
[8] W. Shi, J. Cao, Q. Zhang, Y. Li, and L. Xu, “Edge computing: Vision contracts,” White Paper, pp. 1–47, 2017. [Online]. Available:
and challenges,” IEEE Internet Things J., vol. 3, no. 5, pp. 637–646, https://plasma.io/plasma.pdf
Oct. 2016. [33] P. K. Sharma, M.-Y. Chen, and J. H. Park, “A software defined fog node
[9] M. Chiang and T. Zhang, “Fog and IoT: An overview of research based distributed blockchain cloud architecture for IoT,” IEEE Access,
opportunities,” IEEE Internet Things J., vol. 3, no. 6, pp. 854–864, vol. 6, pp. 115–124, 2017.
Dec. 2016. [34] J. Kang et al., “Blockchain for secure and efficient data sharing in vehic-
[10] J. Pan and J. McElhannon, “Future edge cloud and edge computing for ular edge computing and networks,” IEEE Internet Things J., vol. 6,
Internet of Things applications,” IEEE Internet Things J., vol. 5, no. 1, no. 3, pp. 4660–4670, Jun. 2019.
pp. 439–449, Feb. 2018. [35] T. Jiang, X. Chen, and J. Ma, “Public integrity auditing for shared
[11] H. Li, K. Ota, and M. Dong, “Learning IoT in edge: Deep learning for dynamic cloud data with group user revocation,” IEEE Trans. Comput.,
the Internet of Things with edge computing,” IEEE Netw., vol. 32, no. 1, vol. 65, no. 8, pp. 2363–2373, Aug. 2016.
pp. 96–101, Jan./Feb. 2018.
[36] B. Liu, X. L. Yu, S. Chen, X. Xu, and L. Zhu, “Blockchain based data
[12] M. Satyanarayanan, “The emergence of edge computing,” Computer,
integrity service framework for IoT data,” in Proc. IEEE Int. Conf. Web
vol. 50, no. 1, pp. 30–39, Jan. 2017.
Services (ICWS), 2017, pp. 468–475.
[13] N. Kumar, S. Zeadally, and J. J. P. C. Rodrigues, “Vehicular delay-
tolerant networks for smart grid data management using mobile edge [37] C. Cai, X. Yuan, and C. Wang, “Towards trustworthy and private key-
computing,” IEEE Commun. Mag., vol. 54, no. 10, pp. 60–66, Oct. 2016. word search in encrypted decentralized storage,” in Proc. IEEE Int. Conf.
Commun. (ICC), 2017, pp. 1–7.
[14] G. Ayoade, V. Karande, L. Khan, and K. Hamlen, “Decentralized IoT
data management using blockchain and trusted execution environment,” [38] Y. Zhu, G. Zheng, and K.-K. Wong, “Blockchain empowered decen-
in Proc. IEEE Int. Conf. Inf. Reuse Integr. (IRI), 2018, pp. 15–22. tralized storage in air-to-ground industrial networks,” IEEE Trans. Ind.
[15] K. Ha, Z. Chen, W. Hu, W. Richter, P. Pillai, and M. Satyanarayanan, Informat., vol. 15, no. 6, pp. 3593–3601, Jun. 2019.
“Towards wearable cognitive assistance,” in Proc. ACM 12th Annu. Int. [39] X. Liang, J. Zhao, S. Shetty, and D. Li, “Towards data assurance and
Conf. Mobile Syst. Appl. Services, 2014, pp. 68–81. resilience in IoT using blockchain,” in Proc. IEEE Mil. Commun. Conf.
[16] S. Yi, Z. Hao, Z. Qin, and Q. Li, “Fog computing: Platform and appli- (MILCOM), 2017, pp. 261–266.
cations,” in Proc. 3rd IEEE Workshop Hot Topics Web Syst. Technol. [40] S. Biswas, K. Sharif, F. Li, B. Nour, and Y. Wang, “A scalable blockchain
(HotWeb), 2015, pp. 73–78. framework for secure transactions in IoT,” IEEE Internet Things J.,
[17] B.-G. Chun, S. Ihm, P. Maniatis, M. Naik, and A. Patti, “CloneCloud: vol. 6, no. 3, pp. 4650–4659, Jun. 2019.
Elastic execution between mobile device and cloud,” in Proc. 6th Conf. [41] T. Jiang, H. Fang, and H. Wang, “Blockchain-based Internet of
Comput. Syst., 2011, pp. 301–314. Vehicles: Distributed network architecture and performance anal-
[18] J. Pan, J. Wang, A. Hester, I. AlQerm, Y. Liu, and Y. Zhao, “EdgeChain: ysis,” IEEE Internet Things J., vol. 6, no. 3, pp. 4640–4649,
An edge-IoT framework and prototype based on blockchain and smart Jun. 2019.
contracts,” IEEE Internet Things J., vol. 6, no. 3, pp. 4719–4732, [42] R. Li, T. Song, B. Mei, H. Li, X. Cheng, and L. Sun, “Blockchain for
Jun. 2019. large-scale Internet of Things data storage and protection,” IEEE Trans.
[19] M. A. Rahman, M. M. Rashid, M. S. Hossain, E. Hassanain, Services Comput., vol. 12, no. 5, pp. 762–771, Sep./Oct. 2019.
M. F. Alhamid, and M. Guizani, “Blockchain and IoT-based cognitive [43] J. Xu et al., “Healthchain: A blockchain-based privacy preserving
edge framework for sharing economy services in a smart city,” IEEE scheme for large-scale health data,” IEEE Internet Things J., vol. 6,
Access, vol. 7, pp. 18611–18621, 2019. no. 5, pp. 8770–8781, Oct. 2019.
[20] H. Shafagh, L. Burkhalter, A. Hithnawi, and S. Duquennoy, “Towards [44] D. Deuber, B. Magri, and S. A. K. Thyagarajan, “Redactable blockchain
blockchain-based auditable storage and sharing of IoT data,” in Proc. in the permissionless setting,” in Proc. IEEE Symp. Security Privacy
ACM Cloud Comput. Security Workshop, 2017, pp. 45–50. (SP), May 2019, pp. 124–138.
[21] M. Satyanarayanan, V. Bahl, R. Caceres, and N. Davies, “The case for
[45] D. Derler, K. Samelin, D. Slamanig, and C. Striecks, “Fine-grained and
VM-based cloudlets in mobile computing,” IEEE Pervasive Computing,
controlled rewriting in blockchains: Chameleon-hashing gone attribute-
Vol. 8, no. 4, pp. 14–23, Oct./Dec. 2009.
based,” IACR Cryptol. ePrint Archive, vol. 2019, pp. 406–457, 2019.
[22] S. Meiklejohn et al., “A fistful of bitcoins: Characterizing payments
among men with no names,” in Proc. ACM Conf. Internet Meas., 2013, [46] M. Castro and B. Liskov, “Practical Byzantine fault tolerance,” in Proc.
pp. 127–140. OSDI, vol. 99, 1999, pp. 173–186.
[23] K. Christidis and M. Devetsikiotis, “Blockchains and smart contracts for [47] D. J. Daley and D. Vere-Jones, An Introduction to the Theory of Point
the Internet of Things,” IEEE Access, vol. 4, pp. 2292–2303, 2016. Processes: Volume II: General Theory and Structure. New York, NY,
[24] Regulation (EU) 2016/679 of the European Parliament and of the USA: Springer, 2007.
Council of 27 April 2016 on the Protection of Natural Persons With [48] G. Cohen, E. Tonkes, and G. Coast, “Dartboard arrangements,” J. Comb.,
Regard to the Processing of Personal Data and on the Free Movement of vol. 8, no. 2, pp. 1–8, 2001.
Such Data, and Repealing Directive 95/46/EC (General Data Protection [49] TLC Trip Record Data for Yellow Taxi Trip Records, New York City Taxi
Regulation), Eur. Parliament Council Eur. Union, Brussels, Belgium, Limousine Commission, Silver Spring, MA, USA, Dec. 2018. [Online].
May 2016. Available: https://www1.nyc.gov/site/tlc/about/tlc-trip-record-data.page

Authorized licensed use limited to: UNIVERSITY COLLEGE CORK. Downloaded on December 08,2024 at 09:44:46 UTC from IEEE Xplore. Restrictions apply.
2116 IEEE INTERNET OF THINGS JOURNAL, VOL. 7, NO. 3, MARCH 2020

Chan Kyu Pyoung received the B.S. degree in information and telecommuni- Seung Jun Baek (Member, IEEE) received the B.S. degree from Seoul
cation engineering from Incheon National University, Incheon, South Korea, National University, Seoul, South Korea, in 1998, and the M.S. and Ph.D.
in 2010, and the M.S. degree in computer and radio communications engi- degrees in electrical and computer engineering from the University of Texas
neering from Korea University, Seoul, South Korea, in 2012, where he is at Austin, TX, USA, in 2002 and 2007, respectively.
currently pursuing the Ph.D. degree. From 2007 to 2009, he was a Member of Technical Staff with the
His research interests include network resource management in cloud and Communications and Medical Systems Laboratory, DSP Systems R&D
edge, network virtualization, software-defined networking, and blockchain Center, Texas Instruments, Dallas, TX, USA. In 2009, he joined the
system. College of Informatics, Computer Science and Engineering Department,
Korea University, Seoul, where he is currently a Full Professor. His research
interests include mobile computing systems, machine learning, and data-driven
optimization.

Authorized licensed use limited to: UNIVERSITY COLLEGE CORK. Downloaded on December 08,2024 at 09:44:46 UTC from IEEE Xplore. Restrictions apply.