8228 IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 35, NO.

8, AUGUST 2023

MSTDB: A Hybrid Storage-Empowered

Scalable Semantic Blockchain Database
Enyuan Zhou , Student Member, IEEE, Zicong Hong , Graduate Student Member, IEEE,
Yang Xiao , Member, IEEE, Dongxiao Zhao, Qingqi Pei , Senior Member, IEEE,
Song Guo , Fellow, IEEE, and Rajendra Akerkar

Abstract—Blockchain has been regarded as a trusted carrier for distributed data storage. With large volumes of valuable data stored on
blockchain, data query has become a major requirement. However, the existing blockchains do not provide efficient query functionality
because of their deep-rooted chain structure. Blockchain database is a new direction that constructs index on top of blockchain to provide
rich query functionalities. The existing works are either insecure because the query process separates from the blockchain consensus, or
inscalable because all the data needs to be stored in the block. In this paper, we propose a novel semantic blockchain database called
MSTDB. We design a hybrid on/off chain blockchain storage architecture in which the majority of blockchain storage is offloaded to the
off-chain storage and a novel index structure named Merkle Semantic Trie (MST) is designed to be a secure and semantic bridge
between on- and off-chain. Based on MST, MSTDB provides a variety of semantic query functions including multi-keyword query,
range query, Top-K query, and cross-chain query. To improve the performance further, we design some index compression and query
preprocessing techniques for MSTDB. Extensive experiments demonstrate the effectiveness and efficiency of our blockchain database.

Index Terms—Blockchain database, data sharing, distributed query, index

1 INTRODUCTION As a distributed ledger technology, blockchain can guarantee

recent years, blockchain systems represented by Bit-
I N
coin [1] and Ethereum [2] have attracted growing attention.
 Enyuan Zhou is with the Department of Computing, Hong Kong Polytech-
nic University, Hung Hom, Hong Kong, and also with the State Key Labo-
ratory of ISN, School of Cyber Engineering, Xidian University, Xi’an,
Shaanxi 710071, China. E-mail: en-yuan.zhou@connect.polyu.hk.
 Zicong Hong and Song Guo are with the Department of Computing, Hong
Kong Polytechnic University, Hung Hom, Hong Kong. E-mail: zicong.
hong@connect.polyu.hk, song.guo@polyu.edu.hk.
 Yang Xiao is with the State Key Laboratory of ISN, School of Cyber Engi-
neering, Xidian University, Xi’an, Shaanxi 710071, China.
E-mail: yxiao@xidian.edu.cn.
 Dongxiao Zhao and Qingqi Pei are with the State Key Laboratory of ISN,
Shaanxi Key Laboratory of Blockchain and Secure Computing, Xidian
University, Xi’an, Shaanxi 710071, China. E-mail: bigctime@163.com,
qqpei@mail.xidian.edu.cn.
 Rajendra Akerkar is with Big Data Research Group, Western Norway
Research Institute, 6856 Sogndal, Norway. E-mail: rak@vestforsk.no.
Manuscript received 15 June 2021; revised 28 September 2022; accepted 30
October 2022. Date of publication 8 November 2022; date of current version
21 June 2023.
The work of Enyuan Zhou, Yang Xiao, Qingqi Pei, and Dongxiao Zhao was sup-
ported in part by the National Key Research and Development Program of China
under Grant 2020YFB1807500, in part by the National Natural Science Founda-
tion of China under Grants 62132013, 62102295, 62276198, 62202358 and
61902292, in part by the Key Research and Development Programs of Shaanxi
under Grant 2021ZDLGY06-03. the work of Enyuan Zhou, Zicong Hong, and
Song Guo was supported in part by fundings from the Key-Area Research and
Development Program of Guangdong Province under Grant 2021B0101400003,
in part by Hong Kong RGC Research Impact Fund (RIF) under Grant R5060-19,
in part by General Research Fund (GRF) under Grants 152221/19E, 152203/20E
and 152244/21E, in part by the National Natural Science Foundation of China
under Grant 61872310, and in part by Shenzhen Science and Technology Innova-
tion Commission under Grant JCYJ20200109142008673.
(Corresponding authors: Yang Xiao and Song Guo.)
Recommended for acceptance by N. Zhang.
Digital Object Identifier no. 10.1109/TKDE.2022.3220522
1041-4347 © 2022 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See ht_tps://www.ieee.org/publications/rights/index.html for more information.
Authorized licensed use limited to: Chaitanya Bharathi Institute of Tech - HYDERABAD. Downloaded on August 03,2023 at 06:04:56 UTC from IEEE Xplore. Restrictions apply.
high security and reliability of data, and has been adopted in
different types of applications which involve multiple
untrusted participants [3], such as supply chains [4], asset
digitization [5], decentralized identifiers [6], and commodity
traceability [7]. For example, in a supply chain scenario, mul-
tiple companies who do not trust each other need a complete
historical record of their transactions (such as making quotes
and placing orders) for traceability. The characteristics of
full-ledger sharing, ethedible consensus and tamper-proof
storing for blockchain makes it suitable for use in the supply
chain.
However, in comparison with the traditional databases,
most of the existing blockchains do not provide rich and effi-
cient query functionalities such as SQL, keyword query, etc.,
which significantly influences the user experience and
restricts the application of blockchains. For example, Bitcoin
only provides some simple query APIs based on the hash or
number of blocks (such as getBlockByHash, and getBlockBy-
Num, etc. [8]) Thus, in the above blockchain-based supply
chain, users cannot query transactions with some keywords,
like “Logistics providers
[“DHL,” “UPS,” “FedEx”],” or
search for some history records in a certain period of time,
such as “ 3.99$ < Unit price of pork < 5.99$”.
The main reason is that most of blockchain designers
only take the tamper-proof characteristic of but not the
semantic value of the data into account. To solve the prob-
lem, there have been some works about adding semantic
features to the blockchain and providing query functions
for it, but they have certain limitations as follows. On the
one hand, a few studies [9], [10], [11] are off-chain schemes.
They extract semantic data from the blockchain and put it
in a local database to provide query services. It is easy to
 ZHOU ET AL.: MSTDB: A HYBRID STORAGE-EMPOWERED SCALABLE SEMANTIC BLOCKCHAIN DATABASE
implement but is separated from the blockchain system, so
they cannot guarantee the security for the clients’ query. On
the other hand, some other studies [12], [13] try to build the
query model completely on-chain. However, they put all
the data and index information in the block. The excessive
coupling makes their systems inscalable.
Motivated by an emerging data storage mode for
blockchain, i.e., a combination of on and off-chain stor-
age [14], our basic idea is to build a semantic query layer
on the top of a hybrid blockchain storage. We plan to put
most of the data off the chain, and place the semantic
information and index information of data on the chain.
There are two challenges to support convenient query in
such a hybrid storage architecture and we summarize
them as follows
 Inefficient semantic query. The underlying key-value
database of the existing blockchain systems makes
the clients can query a block or transaction based on
its number or hash, but cannot query based on the
semantic information of the targeted data, which is
more often in a real-life application scenario. On the
other hand, the append-only structure makes the cli-
ents must traverse the entire blockchain to ensure
the completeness of the query result, which brings
clients a terrible query experience.
 None semantic link. The existing blockchain systems
adopt hash values for mapping between the on-chain
and off-chain data. The hash values can only guaran-
tee that the off-chain data will not be tampered with.
However, they do not establish the index for the
semantic information of the off-chain data. Thus, the
clients need to frequently access the whole off-chain
data for each query, which is time-consuming and
inefficient.
Therefore, in this paper, we propose a hybrid semantic
blockchain database named MSTDB. It adds the semantic
feature in blockchain system and provides rich and effi-
cient query methods for the hybrid on-chain and off-chain
data. We first use a hybrid on/off chain storage and
employ an improved TF-IDF model to extract semantic
information of the off-chain data, and upload this informa-
tion to the chain by way of transactions. Next, we build an
on-chain index structure named Merkle semantic trie
(MST) in block, which contains some index components
including inverted index, B+ tree and Merkle Patricia Trie,
etc. And we introduce the query processing via MST,
including multi-keyword query, range query, Top-K
query, and authenticated query. These functions are moti-
vated by traditional databases, while we have specially
designed these technologies for the decentralized and
chain structure of the blockchain. Finally, we have opti-
mized the specific design of our scheme. We compress the
index to reduce the storage cost and design a special index
traversal scheme to support Top-K query for blockchain,
which improve the system’s performance. Besides, we
design an approach for cross-chain query, which solves the
problem of information interaction between heterogeneous
chains. To overcome the scalability challenges of MST-B+
tree, we propose a cryptographic vector commitment (VC)-
based scheme refinement.
Authorized licensed use limited to: Chaitanya Bharathi Institute of Tech - HYDERABAD. Downloaded on August 03,2023 at 06:04:56 UTC from IEEE Xplore. Restrictions apply.
8229
The contributions of our paper are summarized below.
 We propose a hybrid on/off chain storage architec-
ture to reduce the blockchain space cost, and add
semantic features to blockchain system.
 We create a novel index structure on blockchain
which is composed of meta-data in transactions and
maintained by miners through the consensus mecha-
nism, and based on this structure, our system can
provide rich query functions including authenticated
multi-keyword query, authenticated range query,
authenticated Top-K query, and authenticated cross-
chain query.
 We make some improvements to the program to
enhance its availability. We first use a F-B point to
reduce the number of nodes in the index. Second,
node point is an effective ways to prevent space
reuse. Third, we add a Bloom filter to the block to
preprocess the query.
 We implement the prototype of MSTDB on Ether-
eum, and we conduct extensive evaluation of it.
Some experiments on three datasets are done, show-
ing that our scheme has good response time, lower
query results verification cost and superior effective-
ness and completeness.
The rest of this paper is organized as follows. Section 2
introduces some related works. In Section 3, we define the
system and query model. Section 4 represents our architec-
tures, including the hybrid storage and indexing mecha-
nism, and the query processing. Some design refinements
are shown in Section 5. In Section 6, we perform the experi-
ments and verify the availability and effectiveness of our
system by analyzing the experimental results. Finally, Sec-
tion 7 gives the conclusion and our future work.
2 RELATED WORK
2.1 Blockchain Data Storage
Blockchain is a decentralized ledger which preserves all his-
torical transaction records. Underlying most blockchain sys-
tems is key-value databases like levelDB and couchDB,
which find the one-to-one corresponding value through a
certain key. The data structure of blockchain is a chain which
is linked from one block to another, and with the block data
increasing, the amount of data stored by a blockchain node
has become very huge. Bitcoin blockchain size has reached
341.89 GB in April 2021 [15], and at the same time, the size of
Ethereum also exceeded 300GB [16]. To reduce the on-chain
storage pressure, some hybrid on-chain and off-chain storage
schemes [14] [17] have been proposed for better scalability of
blockchain system. Their main approach is to store most of
the data off the chain in a distributed peer-to-peer network
(e.g., Bittorrent network [18] and IPFS network [19]), with
hash values of the entire data or partitioned data blocks on
the blockchain. The on-chain hash value can ensure the con-
sistency of off-chain data and some simple query like check-
ing the balance and querying blocks. For example, Zhang
et al. [20] proposed a blockchain-based data marketplace
with quality-aware incentives, where transaction records are
preserved off-chain, and transaction hash values are stored
on-chain for checks. However, as we say in introduction,
 8230 IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 35, NO. 8, AUGUST 2023
they lack semantic queries such as keyword query, range
query or Top-K query, which are fundamental properties for
scenarios such as health services [21], [22]. In addition to
these problems, in practical applications, some information
may be distributed on different blockchains, and these block-
chains are heterogeneous [23], which also leads to difficulties
in information exchange between them. Some works focus
on transaction [24] or data migration [25], but cannot con-
sider the query requirement between different chains. Shard-
ing and payment channel network [26], [27] are other
approaches for blockchain scalability. Sharding divides the
transactions into different groups to reduce the storage cost
for blockchain nodes, but the query still needs to traverse all
the shards, which increases the communication overhead.
2.2 Blockchain Query
Blockchain is an append-only data structure, and through the
hash pointer to establish the tamper proof binding relation-
ship between the front and back blocks. However, its
append-only attribute also means that a query of all the block-
chain data requires traversing backward the entire chain to
ensure that the search results are complete. Since most block-
chain systems are based on key-value databases, it can only
provide some simple operations such as key update, search,
and write, etc. Taking Ethereum as an example, it supports
several query methods: (i) query block by block height; (ii)
query block by block hash; (iii) query transaction by transac-
tion hash.
To optimize query experience, some works focus on mod-
ify blockchain structure to improve search capabilities. These
works are divided into two categories: adding outside data-
bases and build-in index. Some recent works including
EtherQL [10], BigchainDB [11] and blockchainDB [9] focus on
building a query layer on top of blockchain to provide richer
query functionality. EtherQL develops a middleware which
can automatically keep data in sync between blockchain and
external databases, and provides some RESTful APIs for the
client to call blockchain handler and query interface. Big-
chainDB is a distributed database with blockchain character-
istics. It uses mongoDB and a rich query language is
designed. But bigchainDB is not essentially a traditional
blockchain system because it does not have the full replica-
tion feature. BlockchainDB is a shared database system based
on blockchain, and its main applicable scenario is a multiple
distributed database where the participants do not trust
others and they frequently read and write data. FalconDB [28]
is a Blockchain-based Collaborative Database that enhances
the client-side verifiability and system availability.
Adding an index inside the blockchain is an intrusive
design [29], and it maintains the highly decentralized nature
of blockchain. ECBC [12] is a high performance educational
certificate blockchain with efficient query. It builds a tree
index structure in block and it can provide users with a bet-
ter query experience. GEM 2 -tree [30] designs an optimized
Merkle-B+ tree to implement gas-efficient authenticated
range query. SEBDB [31] adds relational data semantics into
blockchain database, and provides SQL-like languages as
its general interface. Besides, vChain [32] and SEBDB use
authenticated data structure (ADS) to implement authenti-
cated query, which guarantees the integrity of query results.
Authorized licensed use limited to: Chaitanya Bharathi Institute of Tech - HYDERABAD. Downloaded on August 03,2023 at 06:04:56 UTC from IEEE Xplore. Restrictions apply.
Zhang et al, [33] propose a hybrid-storage architecture for
blockchain and improve the data management scalability
by a novel Chameleon index-based ADS.
Comparison: First, our MSTDB system has richer query
functionality than traditional blockchain systems such as
Bitcoin and Ethereum. Second, compared with some total
off-chain approaches including EtherQL, BigchainDB and
blockchainDB, MSTDB has a stronger level of decentraliza-
tion, which ensures higher data security and tamper-proof.
Third, in terms of scalability, our hybrid architecture has
greater scalability and less storage cost than some complete
on-chain schemes like ECBC. Finally, compared with
vChain and SEBDB whose key research is the security of
authenticated query, our MSTDB mainly focuses on the
structure of index and query performance.
2.3 New Achievements
Our previous work [34] proposes a query scheme for a
hybrid storage blockchain. Based on the previous work, this
paper has designed several technologies to optimize the
blockchain database in terms of performance and storage.
First, the query method in the previous work traverses
and returns the results without a relevance ranking. How-
ever, in practice, returning all results is inefficient and costly
because the user may only want the results that are most rel-
evant or relatively relevant. Thus, this paper proposes a
Top-K query based on an efficient index traversal scheme
designed for blockchain database (see Section 4.3.3).
Second, in our previous work, the space cost by the index
will be very large when the data is massive, which causes
high on-chain storage thus index access becomes the perfor-
mance bottleneck of our system. To solve this problem, we
proceed some design refinements for performance, includ-
ing index compression and bloom filter (see Sections 5.1
and 5.2).
Third, our previous work only focuses on a single-chain
scenario. Considering different blockchains have different
characteristics and applicable scenarios, the query data may
exist on different chains and the data users want to query
multiple blockchains at the same time. Therefore, consider-
ing the data silos between different blockchains, we extend
our solution to a multi-chain architecture based on a Simpli-
fied Retrieval Verification approach (see Section 5.3).
Finally, in comparison to the previous work, we adopt
three larger datasets and conduct a large-scale experiment
with more nodes to evaluate MSTDB (see Section 6).
3 PROBLEM DEFINITION
3.1 System Model
There are two types of nodes in MSTDB as follows
 Data owner: A data owner is a user that holds the off-
chain data like text documents and can upload it to
the blockchain by sending transactions.
 Full nodes: A full node is a node that fully validates
and stores transactions and blocks. It exists in the
P2P network and exchanges information with other
full nodes. All full nodes participate in the consensus
process. For example, in Bitcoin or Ethereum, each
miner is a full node.
 ZHOU ET AL.: MSTDB: A HYBRID STORAGE-EMPOWERED SCALABLE SEMANTIC BLOCKCHAIN DATABASE
 Light nodes: A light node is a client that stores the
header information of blockchain and request every-
thing else from the full nodes. They can verify the
validity of the data against the merkle tree’s roots in
the block headers. For example, in Bitcoin or Ether-
eum, a wallet application is a light node.
3.2 Query Models
Document is the basic unit of our hybrid storage system,
which is a text file composed of words and sentences. A
document has some attributes that can be queried: keyword,
size, etc. The full nodes in MSTDB are going to provide the
light nodes with the following query functions
 A multi-keyword query is in the form of a keyword
tuple < key1 ; key2 ; key3 > connected with connec-
tive AND, OR, etc. It is sometimes referred to as a
Boolean query. For example, “Fruit” ^ (“Apple” _
“Strawberry” means the user wants to obtain results
that contain fruit together with both apple and
strawberry or at least one of them.
 The user may want to find some documents whose
size is in a range ½Si ; Sj . For instance, the user may
want to search for a document whose size is between
5 and 10 KBs, and his/her input is like ½5; 10.
 The user inputs a document and wants to find the
first k documents most similar to the document. Still
an example of supply chain, the user probably input
a fruit list containing information about his ideal
fruits, and the system returns him k search results
most similar to his input.
 The cross-chain retrieval needs exist when the data
being searched exists in multiple chains, and the
user can choose to perform cross-chain query on
which chains. For example, if a user wants to search
for some fruit and vegetable providers and these two
companies are on two different chains, the user can
call the cross-chain query API.
3.3 System Goals
Due to the decentralized nature of the blockchain system,
there is not a trusted node responsible for the unified
administration of the entire system. The completeness and
correctness of the query result are the major concerns of our
scheme. A malicious full node may maliciously tampers
with the index on the chain, and the full node performing
the query may also return incomplete or misleading results
to the light node. The superiority of our system lies mainly
in two security related indicators, i.e.,
 Correctness: whether the expected query results are
returned;
 Completeness: whether all the query results are
returned.
Besides, a query system must ensure that users can quickly
find search results without adding too much additional
space overhead. Therefore, the performance of our system is
reflected in two following aspects, i.e.,
 Response time: the time consumption for various
queries;
Authorized licensed use limited to: Chaitanya Bharathi Institute of Tech - HYDERABAD. Downloaded on August 03,2023 at 06:04:56 UTC from IEEE Xplore. Restrictions apply.
8231
Fig. 1. System architecture.
 Index Storage: the storage overhead of the index
structure.
4 ARCHITECTURE
4.1 Architecture Overview
Our system architecture consists of three parts: off-chain
storage, on-chain index processing and query APIs. The
architecture of our system is illustrated in Fig. 1.
 Off-chain storage: This part represents the data stor-
age and devices off the blockchain, and their storage
medium can be a traditional database, cloud storage,
and IPFS, etc. The most of the original data are kept
by a single organization, and they can establish a
relationship with the data on the chain through a
mapping method. The details of hybrid storage will
be covered in Section 4.2.1.
 On-chain index processing: Miners in the system main-
tain a global index structure by processing transac-
tions, and update it with the increase of blocks. See
Section 4.2.2 for details.
 Query APIs: This part is responsible for data query,
including a variety of analytical query functions. All
full nodes could call these functions locally, and pro-
vide authentication query function for light nodes.
In section 4.3, we introduce the specific query
processes.
The life cycle of the off-chain data like documents main-
tenance has three steps: 1) Each data owner stores a number
of documents. The details are shown in Section 4.2.1. 2) To
upload one of its documents to the blockchain, a data owner
uploads the metadata of the document by submitting a
transaction to the blockchain. The details are shown in Sec-
tion 4.2.1. 3) Data owners can update the contents of their
documents, and they submit a transaction with updated
metadata to the blockchain network.
4.2 Storage and Index
In this section, we first give an overview of the storage and
index of MSTDB. This part consists of three main compo-
nents: hybrid storage, information extraction, and on-chain
index. We give some brief introduction about these three
components.
 8232
Hybrid Storage. Our storage pattern is a hybrid on-chain
and off-chain storage. Most of the data are stored in some
off-chain spaces such as distributed databases (Hbase, redis,
etc) and IPFS. Off-chain data could be unstructured, semi-
structured, or relational. Section 4.2.1 describes some data
structures and storage medium of blockchain.
Information Extraction. To establish a semantic mapping
between the on-chain and off-chain data, we propose an off-
chain information extraction algorithm. Through the algo-
rithm, the most valuable meta-data can be extracted from
the huge off-chain data and be sent to the blockchain in the
form of transactions. This meta-data is the basic component
of the on-chain index structure. The detailed information
extraction algorithm is described in Section 4.2.2.
On-Chain Index. An on-chain index structure (IS) is the
core of MSTDB, which is established in the block body.
Once the extracted meta-data is sent to the blockchain in the
form of transaction, the full nodes jointly process them and
update the IS together. Since the index structure is updated
with the increase of transactions, it always keeps up to date
in the latest block. Furthermore, our index structure is com-
patible with various blockchain systems because it does not
rely on any specific underlying database. We will elaborate
the specific design and the generation process of our index
structure in Section 4.2.3.
4.2.1 Hybrid Storage
The storage model of MSTDB is a hybrid on-chain and off-
chain architecture. Off-chain data are managed by some pri-
vate data owner, and stored in some distributed devices
like distributed databases or IPFS. Since the off-chain data
are stored in some private spaces and their copies do not
need to be synchronized across the whole network, the stor-
age cost of off-chain data is not very high. We focus on the
storage cost of on-chain part. A blockchain is a data struc-
ture which is linked from one block to another. Each block
contains two parts: the block header and block body. In the
block header, a core data called hash point which deter-
mines the context of a block and ensures the block data can-
not be tampered with.
Transaction is the basic data content in blockchain sys-
tem, and a series of them are stored in the block body. All
transactions have a standard format, and every transaction
has a transaction hash through it we could locate the trans-
action quickly. Inside the block body, a number of transac-
tions are arranged to form a Merkle tree. Merkle tree is a
hash-based Multi-tree, which uses layers of hashing to
ensure that the order of transactions in a block is not tam-
pered with. Bitcoin uses Merkle tree to conserve transac-
tions, and put the root hash of the Merkle tree into the block
header. Unlike bitcoin, Ethereum is an account-based
model, known as a transaction-driven state machine. It uses
Merkle Patricia Trie (MPT) [2] to store the states such as
account state or smart contract state. Each MPT leaf node is
an account state, while the branch stores the compressed
prefix of the account address. The miner updates the states
of the accounts in the MPT according to the transactions in
the block. Therefore, the latest states of all accounts are
stored in the latest block, with the root hash of the MPT in
the block header.
Authorized licensed use limited to: Chaitanya Bharathi Institute of Tech - HYDERABAD. Downloaded on August 03,2023 at 06:04:56 UTC from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 35, NO. 8, AUGUST 2023
All on-chain data including block headers and block bod-
ies are stored in the database of the blockchain system, such
as LevelDB, RocksDB, etc. But what are stored in the data-
base are not the original on-chain data, since all data need
to be serialized to be stored in the database. For example,
Ethereum uses the Recursive Length Prefix (RLP) [35] codes
to perform network transmission and persistent storage.
After the encoding process of on-chain data, they are stored
physically in some devices such as disk. The write efficiency
of the underlying database of the blockchain is extremely
high which is mainly due to the sequential writing scheme
of LSM-Tree [36]. However, since the low transaction
throughput, this advantage of fast writing is not reflected in
the existing blockchain system.
The data owners need to upload the off-chain data like
documents to the blockchain by sending the transactions, and
the transaction form is as < Tid; SendId; docID; metadata >
, where Tid is the unique identity of the transaction, sendId is
the address of transaction initiator, docID is the unique iden-
tity of the document, and metadata contains the keywords list
and weights of the document.
4.2.2 Information Extraction
The goal of information extraction is to establish the seman-
tic mapping and tamper-proof ability between the on-chain
and off-chain data, which includes two steps, i.e., meta-data
extraction and hash binding. Note that the basic meta-data
(e.g., data location, data size) will be directly provided by
the data owner, thus we focus on the extraction of the
semantic keywords in this section. For backward compati-
bility, the meta-data is placed in the “data” field of transac-
tions which exist in most blockchain systems.
In the search engine filed, TF-IDF [37] is a classic keywords
extraction algorithm which can collect words that appear fre-
quently. To apply this method to blockchain system, we pro-
pose an improved TF-IDF model called Decentralization
Semantic Extraction (DSE). DSE improves the precision of
semantic feature extraction by introducing decentralized
word frequency, part-of-speech and position factors to
address the lack of semantic understanding in traditional
keyword extraction algorithms. Through the DSE model, we
build an inverted index [38] of semantic keywords.
The main purpose of TF-IDF model is to find the words
which appear frequently in one document and rarely
appears in the entire document collection. Given a word i, a
document collection N, and an individual off-chain data j 2
N, the TF-IDF can be calculated by


N
TF  IDFi;j ¼ fi;j  log ; (1)
dfi þ 1
where fi;j is the frequency of keyword i in the data j, and dfi
is the number of times the data containing the keyword i
appears in N.
A problem of TF-IDF model is that the IDF model only cal-
culates the number of documents that contain a word but
does not consider the word frequency difference between
them. In some cases, if a word has a lower frequency in a doc-
ument but does not appear in other documents, its impor-
tance for document classification is higher than that of
another word that has a higher frequency in this document
 ZHOU ET AL.: MSTDB: A HYBRID STORAGE-EMPOWERED SCALABLE SEMANTIC BLOCKCHAIN DATABASE 8233

but also appears high in other documents. For example, if on the blockchain, it guarantees that if data owner modifies
there are 10000 documents in the system, word 1 appears 10 the raw off-chain data, the mapping relationship between
times in document 1 and does not appear in other docu- on-chain and off-chain data will be broken. To expand the
ments, and word 2 appears 1000 times in all documents. The coverage of the hash function, we add the meta-data to the
TF-IDF value of words 1 and 2 in document 1 is 40 and 1000, input parameters of it. So the hashing process becomes this
but in fact word 1 has a greater discriminating ability for doc- form: hash ¼ Hðraw datajmeta-dataÞ. Besides, if some off-
ument 1. For solving this problem, we propose a calculation chain data are deposited in IPFS or other decentralized stor-
method called Document-wisee Term Frequency Factor age network, our system can be compatible with their hash
(DTFF) to decentralize the frequency of keywords by results such as Merkle DAG root.
After the information extraction process of off-chain
DTFFi;j ¼ 2Ni;j Ni ; (2) data, we create a table called inverted index to store the
index information of every keyword. Inverted index often
where Ni;j is the number of occurrences of keyword i in
consists of a series of inverted list whose format is like <
data j, and Ni is the average number of occurrences of key-
key; docId1; docId2 . . . > , where docId is the unique identi-
word i in all data. The weight of exclusive words can be
fier of a document. Different from the traditional inverted
increased through the decentralization of DTFF. Following
index, we use block number instead of docId to represent
the above example, through the DTFF model, the weight of
the appearance position of the keyword. A problem with
word 1 is increased to 40960 and the weight of highly dis-
this modification is that if two or more transactions contain-
tinctive word 1 is highlighted.
ing the word appear in the same block, we need to traverse
In addition to term frequency, the position of a word in a
the entire block to ensure the integrity of the query. The ben-
document is also very important. For example, the weight
efits of this design will be explained in Section 4.3.1. For any
of a word which is at the beginning and end of an article
inverted list, all block numbers are sorted in descending
often has greater significance than those in the middle of
order of average weight. Moreover, although the historical
the article. We arrange the positions where the keywords
record cannot be changed due to the immutability of the
first appear in the data into a sequence with the number of
blockchain, the weight of each word in MSTDB can be
words as the total length and 1 as the unit scale, and we
updated by the blockchain nodes’ consensus. The data own-
choose the middle point as the initial coordinate. In our
ers can submit a transaction with updated metadata to the
thoughts, we determine that the words in a small range on
blockchain network to ask the blockchain nodes to update
both sides of the center point (initial coordinate) the same
the weight of word.
weights. outside the range, we measure the distance from
the initial coordinate to the word and calculate a weight fac-
tor affected by distance. The philosophy we follow is that 4.2.3 MST Tree
the longer the distance, the greater the weight. The Position
There are some search methods in blockchain system like
Factor is defined as
( searching block by hash, searching transaction by hash,
1; d < d searching block by block number, etc. However, there are no
PFi;j ¼ ; (3) semantic meanings included in the input parameters of these
"  dd ; d  d
methods. It is inefficient to process a query request if a user
where " is an increased weight multiple, d is the distance of wants to query some information by keywords, because the
the word i from the initial coordinate, d 2 ½0; L=2Þ and L is node must scan all blocks one by one. In our scheme, an IS is
the length of the sequence. established in the block body. This IS is jointly maintained by
Furthermore, we draw lessons from the scheme of speech the miners and is always up to date in the latest block. The
classification priority based on statistical methods [39], which index structure is not a special component in the blockchain
calculates the weight of part of speech by using a fuzzy hid- system, it is kept in the database as a structure and loaded
den Markov model, using the method, we define the weights into the memory when it is used. Since it does not depend on
for keywords of different parts of speech as follows any specific underlying database, our index structure is com-
8 patible with various blockchain systems.
>
> 0:9 n: Inverted index allows fast real-time query on a single
>
>
>
> 0:8 v: keyword, but it does not provide efficient multiple key-
>
>
>
> words query. To overcome this challenge, we construct a
< 0:3 pron:
>
novel index structure called merkle semantic trie (MST) that
Posi ¼ 0:5 adj: (4) integrates the inverted index, Merkle Tree, prefix compres-
>
>
>
> 0:5 adv: sion and hash point techniques.
>
>
>
>
>
> 0:4 num: MST is a tree-shaped data structure, and there are three
>
: types of nodes in the MST: branch nodes, extension nodes,
1 idiom:
and leaf nodes. Different nodes have different features in
Then, the weight of the feature word is MST structure, and a node can only be of one type. Branch
nodes of MST has analogous duty as in tire, they only store
Wi;j ¼ TF  IDFi;j  DTFFi;j  PFi;j  Posi : (5) index-related information and provide pointers to the next-
level nodes. Leaf nodes always represent the end of a search
Hash binding is the process of storing the hash value cal- path and store the query results. The result is not the spe-
culated by the one-way hash function of the off-chain data cific information but a hash pointer which directs to the
Authorized licensed use limited to: Chaitanya Bharathi Institute of Tech - HYDERABAD. Downloaded on August 03,2023 at 06:04:56 UTC from IEEE Xplore. Restrictions apply.
 8234 IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 35, NO. 8, AUGUST 2023

Fig. 2. MST structure.

block where the corresponding transaction is located. Exten- has been sorted according to the weight in the inverted index.
sion node is a multi-functional node of MST. It contains not MST has been created when the genesis block was built, and it
only the index-related information, but also the query moves to another state after all of the transactions in a block
results and pointers. This design means that when you have been handled. The original MST had only a root node,
search for that node, it has a definite search result in this and every index pair in the transaction need to be inserted
node. But if you want to continue searching for more from the root node.
detailed and accurate results, you can enter the next level After transactions are inserted into MST, blockchain
by the pointer and explore deeply. The root node is the nodes need to update its keywords set. In an MST, each leaf
entrance to MST, and if there is only one node in MST, the node or extension node can be expressed as a boolean
root node serves as a leaf node, otherwise it is a branch expression. For example, in Fig. 2, the boolean expression of
node which has child nodes. leaf node (a) is fkey1 ^ ðkey3 ^ key2Þg. Moreover, boolean
expressions corresponding to multiple leaf nodes or exten-
sion nodes can be combined. For example, in Fig. 2, the com-
Algorithm 1. MST Node Insert
bination of boolean expressions of leaf node (a) and (b) is
Input: info as indexInfo(blockNumber and a list of key- fkey1 ^ ððkey3 ^ key2Þ _ key5Þg.
word as < keym > , node as an MST node Besides, the keyword list of queries can also be represented
1: ln lenðnode:keyÞ
in Boolean form like q = fkey1 ^ key3 ^ key2g, There may be
2: li lenðinfoÞ
some ambiguity in the order of keywords. We assume that a
3: while 9i : i  lnandi  li do
combination of leaf nodes or extension nodes denoted by
4: foreach keyi 2 info:key, nodekeyi 2 node:key do
5: if keyi 6¼ nodekeyi then
f‘‘blockchain00 ^ ð‘‘bitcoin00 _ ‘‘ethereum00 Þg is stored in the
6: go to split MST. Then, if a query is f‘‘ethereum00 ^ ‘‘blockchain00 g, the
7: if li < ln then MST cannot return any result. However, our DSE model could
8: node extendnode eliminate the ambiguity since we can sort the input keyword
9: go to split list by their weights with those of larger weights ranked ahead,
10: if li = ln then preventing recursive insertion of the keyword combinations.
11: Switch: node type The main consideration of the MST path borrows the
12: Case: leaf k extend common prefix concept of trie. Upon an insertion to the key-
13: node.value.append(blockNumber) word list, the data with the same prefix keyword combina-
14: break tion is stored to the same path. To further drop index size,
15: Case: branch we comprss paths with only one child node, which is like
16: node.value.append(blockNumber) the Patricia trie. Fig. 2 shows the specific structure of MST.
17: node extendNode Since the existence of merkle tree characteristics, each node
18: break of MST needs to be calculated a hash value. And different
19: if li > ln then type of nodes have different input of the hash function: for
20: if node.type = leaf then leaf node, the input parameters of hash function are key-
21: node extendnode words and block pointers which direct to the block and are
22: node:child:appendðinfo½i : liÞ stored in the leaf node; the hash value of branch node
23: split: node.child.append(info[0:i]) and node.child.append(info[i:li]) includes the hash result of keyword and its child nodes; as
for extension nodes, its hash value is the hash result of the
To construct the global on-chain index structure, miners keywords, block pointers, and child nodes. The role of node
extract the keyword information from transactions. The for- hash is not only to prevent the content of the node from
mat of the information we need in the transaction is being tampered with, but also to establish a logical connec-
< blockNumber; key1; key2 . . . > pairs and the keyword list tion between the parent node and the child node. The
Authorized licensed use limited to: Chaitanya Bharathi Institute of Tech - HYDERABAD. Downloaded on August 03,2023 at 06:04:56 UTC from IEEE Xplore. Restrictions apply.
 ZHOU ET AL.: MSTDB: A HYBRID STORAGE-EMPOWERED SCALABLE SEMANTIC BLOCKCHAIN DATABASE
Fig. 3. After adding the B+ tree feature to MST.
parent node and the child node are not physically connected
in the database, but the child node stores the hash value as
the key in the Key-value database, and the parent node
finds the child node through the hash value of the child
node. The root hash value saved by the root node is stored
in the MSTrootHash Field of the block header.
In Algorithm 2, we perform an insert operation of a node
in MST, including the node type conversion operation and
split operation. There are three situations to consider here
when a new keyword list appears. We describe three differ-
ent operations separately and how the node split.
4.2.4 MST-B+ Tree
Besides the keyword query, we also focus on range query
on blockchain. Merkle-B+ tree is a common ADS that is usu-
ally used to support authenticated range queries in out-
sourced databases. MST-B+ tree is a combination of MST
keyword trie and Merkle-B+ tree, which can support both
the authenticated keyword query and the authenticated
range query. The combing process consists of two steps.
The first step is the sorting process. As shown in Fig. 3, the
size information of the off-chain documents is added in the
leaf nodes and extension nodes in MST, but they are unor-
dered. To put them in order, the blockchain nodes should
sort them by their size values and add small-to-large hash
pointers between them. Through the ordered hash pointers,
all leaf nodes and extension nodes form an ordered linked
list. In the second step, after the ordered linked list is con-
structed, the blockchain nodes add the index information
into the branch nodes and leaf nodes to let them point to the
documents whose sizes are in an ordered range.
The MST part and the B+ tree part on the MST-B+ tree
are maintained and updated independently. In an MST,
each extension node or leaf node has two pointer areas
(blue area in Fig. 3) that store pointers to the document cor-
responding to the keyword query and the document corre-
sponding to the range query, respectively. For example, in
Fig. 3, the two pointers (red dotted lines) of leaf nodes (a)
point to two different documents with keyword set
fkey1; key2; key5g and document size 3 KB respectively.
4.3 Query Processing
After adding the index structure on the blockchain, our
MSTDB system can provide multiple authenticated queries.
In this section, we will introduce the query processes of
four methods.
Authorized licensed use limited to: Chaitanya Bharathi Institute of Tech - HYDERABAD. Downloaded on August 03,2023 at 06:04:56 UTC from IEEE Xplore. Restrictions apply.
8235
Fig. 4. A Structure of Multiple keywords Aho-Corasick automaton.
4.3.1 Authenticated Multi-Keyword Query
According to the definition given in Section 3.2, mutil-key-
word query needs to match the keyword combination
entered by the user with the index path in MST, and return
all results that meet the conditions. We refer to many string-
matching algorithms such as KMP (Knuth-Morris-Pratt),
and propose a multi-keyword matching structure named
Multiple keywords Aho Corasick automaton (MKACA). In
our design, MKACA is another form of MST and can always
be kept in the memory of the blockchain node. It can sup-
port incremental updates and it will be updated with MST
update in each consensus round of blockchain.
As shown in Fig. 4, the initial state of MKACA corre-
sponds to the root nodes of MST, and the receiving states
are represented as double circles, which correspond to the
extension nodes or leaf nodes. All the state transition func-
tions in MKACA correspond to index keywords on different
branch paths of MST. For example, q0 in Fig. 4 represents
the root node in Fig. 2, q1 represents the extension node
with key1, and two states q2 and q3 together represent the
leaf node with key2 and key3 because < key1; key2; key3 >
and < key1; key3; key2 > are two different matching path.
MKACA can provide the authenticated multi-keyword
query for MSTDB. The inputs of authenticated multi-key-
word queries include a keyword list and the root node of the
MST. First, the MST is converted to a corresponding
MKACA, and the keyword list is transformed to a CNF and
starts its matching processing in the initial state of MKACA.
Then, the blockchain nodes match the keyword of the CNF
in order with the different paths of MKACA. If the operator
is conjunctive, the match processing will search the MKACA
in depth, while if the operator is disjunctive, match process-
ing will search the MKACA in breadth. If the CNF has been
traversed, and matching processing has reached the receiv-
ing states, blockchain nodes return the value of the corre-
sponding node of this state. Otherwise, the blockchain nodes
return an empty result. For example, in Fig. if a query input
is key1 ^ ðkey3 _ key2Þ, the state will go from q0 to q1, q1 to
q2 and q3, but neither q2 nor q3 are the receiving states, the
match processing is failed. However, if the input is key1 ^
key3 ^ key2, the state goes from q0 to q1, q1 to q3, and finally
to q9. Since q9 is a receiving state of MKACA, the match
processing is succeeded.
 8236 IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 35, NO. 8, AUGUST 2023
The outputs of it are the multi-keyword query result R
and its verification object (VO). The correctness and com-
pleteness of the results can be guaranteed by the Merkle
proof in VO. Clients can verify the correctness of the results
by recomputing the hash value of Merkle root and compar-
ing it with the record in their local block header. The com-
pleteness can be guaranteed because one query only returns
one related node in MST, and the result cannot be mali-
ciously omitted to pass the validation.
4.3.2 Authenticated Range Query
By combining B+ tree and MST, our system can provide
verifiable range query in the hybrid storage architecture.
Range query is a common query operation in database
field, which finds some information whose value is
between an upper and lower boundary. Using the B+ tree
feature, it can find the value in the input range very sta-
bly. For verifiable range query, the full node searches the
MST-B+ tree to find the first record in the range. Then it
scans the leaf nodes from the first node until right bound-
ary of the query range. Merkle proof is packed into VO
and will be returned to the light node together with the
query result.
For authenticated range queries, the query results are a
range of MST-B+ tree nodes, thus the blockchain nodes
need to return the query results and the Merkle proof of
two points at the front and back ends of the range. The cor-
rectness and completeness of the results can be guaranteed
by the Merkle proof. Clients can verify the correctness of
the results by recomputing the hash value of Merkle root
and comparing it with the record in their local block header.
The completeness can be guaranteed because the Merkle
proof of B+ tree can prove that all in-scope results are
returned.
4.3.3 Authenticated Top-K Query
Users constantly want to seek for documents related to its
input. To meet the search needs of users, the basic solution
is returning all query results through the index, and let the
searcher find the best document by themselves. A fact is
that most of the query results are not highly matched to
user needs, thus users also take time to filter the results,
which is inefficient and has become a bottleneck of query
process. Top-K query, which is a classic optimization tech-
nique to save the query time cost. The reason why Top-K
query can improve query efficiency is that it has a key step
called early termination. Early termination first lets the
inverted list be arranged such that the most promising
documents appear early, and stop the query process as soon
as the top K results appear. Besides the early termination,
there are many effective ways such as skip within lists, omit
lists or score only partially. Top-K query calculates the rele-
vance of user input to candidate documents, and returns
the top K results according to the ranking from high to low
score. For score calculation, the index should be traversed,
and there are two traditional index traversal techniques as
follows
 Term-At-A-Time (TAAT) [40] : Query service pro-
viders first access one term (or keyword) of the query
Authorized licensed use limited to: Chaitanya Bharathi Institute of Tech - HYDERABAD. Downloaded on August 03,2023 at 06:04:56 UTC from IEEE Xplore. Restrictions apply.
request, and calculate the product of the weight of
all documents (or transactions) in the list of the
word in the inverted index and the weight of the
word in the query request. Then for each other key-
word in query request, using the same similarity
calculation method and add the product to a sum.
Miners use a temporary memory to keep track of
currently active Top-K candidates.
 Document-At-A-Time (DAAT) [41] : Each document
which is related to the query input can be calculated
independently, miner use simhash algorithm or
cosine distance to calculate the similarity between
two documents. DAAT store current Top-K result by
a simple heap structure.
Compared to TAAT, DAAT is a more space-saving solu-
tion and faster due to multi-thread parallel operations.
However, DAAT rarely terminates early, because no one
can make a preliminary overall judgment on the next docu-
ment. Many optimized approaches for termination early
use TAAT, but in blockchain system, the cost of temporary
storage space cannot be ignored, so we improve DAAT ’s
early termination conditions.
Algorithm 2. Top-K Query Baesd on BAAT
Input: Q as a query request; B as the blockchain
Output: R as Top-K query result
1: Create a min-k heap h½k and h½0 is the minimal value
2: foreach block bi 2 B do
3: if bi:avgWeight  bi:transNumber  h½0:value
then
4: continue
5: else
6: foreach doc 2 bi do
7: if cal½doc; Q > h½0:weight then
8: h½0 = doc
9: h:rebalanceðÞ
10: return h;
In our scheme, we propose a more efficient index traversal
pattern called Block-At-A-Time (BAAT) developed from
DAAT. Same as DAAT, BAAT traverses the blockchain by
calculating weights for all documents one by one and uses a
min-k heap to store the temporary top k results, while BAAT
adopts a block-based early termination scheme to skip all
documents in the block without calculating the weights of
the documents, which allows it to get query results faster
than DAAT. In BAAT, each block has pre-calculated an aver-
age score table containing the average weight of all keywords
in the block. For each keyword ki in block bi , the average
weight of ki is the average DSE weight of ki . When a query
request is received, the blockchain node who receives the
request traverses the chain from the latest block to the gene-
sis block and keeps a min-k heap to store the terminated
results. All documents in a block are compared with the
query to calculate a similarity between them, and the min-k
heap always keeps the top k relevant documents. The early
termination scheme of BAAT is that if it is assumed that
there is a document in the block that has the highest rele-
vance to all the keywords in the query and the relevance of
the document is still less than the document at the head of
the heap, the whole block can be skipped.
 ZHOU ET AL.: MSTDB: A HYBRID STORAGE-EMPOWERED SCALABLE SEMANTIC BLOCKCHAIN DATABASE
Fig. 5. Structure of VC-based MST.
The detailed algorithm of BAAT is shown in Algorithm
1. In Algorithm 1, the inputs contain a query request Q
which includes a keyword list < key1 ; key2 ; keyt > and a
blockchain B. First, the blockchain node creates a min-k
heap h[k] whose head is h[0] (line 1). Then, for each block bi
in B, the blockchain node calculates the average weights of
all keywords in the keyword list and the possible maximum
value of the block. If the maximum value is lower than the
value in h[0], the block is skipped (lines 2-4). If not, the
blockchain node will calculate the similarity of all docu-
ments in the block with the query and update the heap if
there are some more relevant documents. Finally, the block-
chain node returns the heap.
For authenticated Top-K queries, since the blockchain
nodes needs to traverse the entire chain to iterate over all
documents, it is too expensive to send the data of the entire
chain to the client for verification. Therefore, we adopt a
consensus-based verification method. The client needs to
send a query transaction to get the top k results, and the
query results are returned with a transaction receipt. Since
the query transaction are executed by all blockchain nodes,
the correctness and completeness can be guaranteed by the
consensus mechanism.
4.4 Vector Commitment-Based MST-B+ Tree
In an update intensive case, the poor scalability of our MST-
B+ tree is a problem. To overcome the scalability challenge,
motivated by [33] and [42], we propose a cryptographic vec-
tor commitment (VC)-based scheme refinement. We will
explain the refinement and the new experiment in details as
follows.
VC is a cryptographic structure that can commit an entire
array V of data with a short commitment c. A user who has
c can verify V or any item V[i] in V through a proof pro-
vided by a prover who maintains V. To generate the com-
mitment for a vector with size B, the prover needs to
generate the security parameters at first, and the parameters
can be used by other vectors with the same size B. However,
if the prover wants to generate a commitment for a vector of
another size, it needs to generate the new security parame-
ters. The process of generating security parameters is time-
consuming.
The motivation of the new design is to update fewer
nodes when inserting new nodes in the MST-B+ tree. The
processing of adding the VC scheme in MST contains three
following parts: First, as shown in Fig. 5, the blockchain
nodes sort the nodes of leaf nodes and extension nodes in
Authorized licensed use limited to: Chaitanya Bharathi Institute of Tech - HYDERABAD. Downloaded on August 03,2023 at 06:04:56 UTC from IEEE Xplore. Restrictions apply.
8237
Fig. 6. MST compression process.
MST like the MST-B+ tree, and divide the ordered list into
multiple groups of the same size to reduce the generation
time for the security parameters, each of which is an
ordered vector. Second, the blockchain nodes generate all
commitments of the vectors, and store these commitments
in the root node’s child nodes. For example, in Fig. 5, c1 to
c3 are three commitments of three vectors V1 to V3, and are
stored in the three child nodes of the root node. Third,
when some items of MST need to be inserted into MST or
updated, the blockchain nodes create new vectors or update
the existing vectors and their commitments.
The scheme of VC can support the same range query
function of Merkle B+ tree. In the authenticated range
query processing, blockchain nodes search in the root
node’s child list to find the group with the target range and
find the result in the corresponding vector first, then they
return the result with a VO to the light node. The block-
chain nodes will generate the vector commitment proofs of
the query results, and add the proofs, the relevant commit-
ments of these proofs, and the Merkle proofs of these com-
mitments to the VO. After receiving the result and VO, the
client verifies the result with the proof and the commitment
locally. Through adding the VC scheme, MSTDB only
needs to store the additional commitments of the grouped
linked list and each update of the digest value will only
lead to one time update of one commitment. Comparing
with the Merkle B+ tree, the time complexity of VC updat-
ing is reduced to O(1).
5 DESIGN REFINEMENTS FOR PERFORMANCE
5.1 Index Compression
Although our hybrid storage architecture can alleviate the
storage overhead on the chain, with the data continuing to
grow, the size of the index structure can still place an unac-
ceptable burden on the node. To allow lower storage cost
and faster access to index on disk or other devices, and limit
the memory space needed, we present an index compres-
sion approach for MST. The main problem for the expansion
of MST is that there are too many nodes store the same key-
word, because there are many intersections between key-
word combinations. To reduce the repetition rate of nodes,
we propose a method based-on F-B pointer to merge those
nodes that contain the same key.
F-B Pointer. We use a two tuples structure called F-B
pointer to achieve the compression, and F-B means front
and back. The contents of F-B pointer are two hash val-
ues which direct to the parent node and the child node
in on search path. After adding the F-B pointers, the
space complexity of MST can be reduced to O (n), and
this allows MST to ensure availability in scenarios with
massive data.
 8238 IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 35, NO. 8, AUGUST 2023
Fig. 7. Blockchain with added node pointers. The dotted lines represent
the parent node pointers to the unchanged subtrees after the MST state
changes.
Fig. 6 is a case of MST before and after compression. In
Fig. 6, the left part is an original MST, and 1 to 6 are different
keywords stored in different nodes. In the original MST,
there ithe left part is an original MST, and 1 to 6 are different
keywords stored in different nodes. In the original MST,
there is only one path between any node and the root node.
The right figure is the compressed MST. In the right figure,
all the nodes with the same keywords are merged, and the
double arrows with different colors represent the different
F-B pointers on different subtrees in the compressed MST.
For example, the red arrow with symbol 1 is < root; 1 > ,
where the root node is its predecessor and the node with
keyword 1 is its successor. In the compressed MST, the
nodes connected by all F-B pointers of the same color can be
mapped to a subtree of the root node of the original MST.
For example, in the right figure, the nodes with keywords 1,
2, 5, 6, and (3,4) are connected by the red arrows, and they
correspond to the leftmost subtree in the left figure. More-
over, the path from any node to the root node is connected
by F-B pointers of the same color between them. For exam-
ple, the three red arrows in the right figure with numbers 1,
2, 3 are three F-B pointers including < root; 1 > , < 1; 2 >
, and < 2; 3 > , each of them contains two nodes before
and after the pointer. Through the three F-B pointers, the
node with keyword 6 can establish a link with the root node
of the keyword path < 1; 2; 6 > .
Node Pointer. Another effective way to reduce storage
space of index structure is node pointer. Since MST contains
all the index information on the blockchain and always
keep the newest state in the last block, there are many differ-
ent versions of MST as the block increases. Streamlining the
index structure that is not in the latest block is an obvious
and effective means to save storage space. But to ensure the
returnability and traceability of blockchain during its fork,
it is necessary to keep a complete MST structure evolution
process. The core idea of our design is incremental modifi-
cation of the index structure. Similar to Ethereum’s state
tree, the newer block only stores the changed part of MST
and uses some node pointers to direct to the subtrees that
have not changed in MST, which are located in the previous
block. One possible problem in this design is that if a sub-
tree has not been updated for a long time, there may be too
many node pointers which direct to them. Therefore, we
allow the next block to reuse the same node pointer of the
previous block. A blockchain with added node pointers is
shown in Fig. 7.
5.2 Bloom Filter
The structure of MST results in a large change in the MST
when a new keyword that hasn’t appeared before is
Authorized licensed use limited to: Chaitanya Bharathi Institute of Tech - HYDERABAD. Downloaded on August 03,2023 at 06:04:56 UTC from IEEE Xplore. Restrictions apply.
Fig. 8. Keyword Bloom Filter.
inserted. A bloom filter is employed to quickly determine
whether a keyword to be inserted is a new keyword.
Compared with the Bloom filter in the traditional block-
chain, the main purpose of our structure is to improve
the efficiency of keyword query. We use bloom filters to
pre-match user input to minimize the use of index struc-
tures. We map the keyword list in the inverted index into
a bit vector called bitmap. For each keyword, we perform
k different hash operations, and then set 1 for the data
bit obtained by hash value modulus-128 in the bitmap.
When a new keyword keyi comes, we perform multiple
hashing
Y
k
verifyðkeyi Þ ¼ ðhashi ðkeyi Þ \ 1Þ: (6)
i
If the result is 1, the keyword is likely to be an existing
keyword. And if the result is 0, it can be determined that
this keyword has never been stored in the system, so there
is no need to access the index. The structure of the bloom fil-
ter is shown in Fig. 8. Bloom filter is not always completely
accurate. It possibly shows false positives because two or
more keywords may be mapped to the same bit of the
bloom filter. Despite the presence of false positive, the effi-
ciency of our system has still been greatly improved after
adding the bloom filter. The structure of the bloom filter is
shown in Fig. 8.
5.3 Cross-Chain Query
MST can effectively meet the needs of single-chain query,
but as we discussed before, sometimes the data required by
some users may be on different blockchains. In a cross-chain
application, different chains must be able to connect and
communicate with each other [43], which also called inter-
operability. To solve the cross-chain query problem, we
assume that there are series of different chains which all
have MST in their block, and they need query some data
which are probably stored in different chains. To establish
communication between multiple chains, we propose a
cross-chain query committee scheme based on the Merkle
proof verification. The nodes in the committee are drawn
from each blockchain in a certain proportion and replaced
after a period of time.
DEFINITION 1: Given a blockchain set B=fb1 ; b2 ; . . . ; bn g,
where bi is the number of nodes in the ith blockchain. Let
C=MaxðBÞ, and ci is the number of committee nodes of the
ith blockchain. The number of nodes in each blockchain sys-
tem is allocated as
 ZHOU ET AL.: MSTDB: A HYBRID STORAGE-EMPOWERED SCALABLE SEMANTIC BLOCKCHAIN DATABASE
8   value, the harmonic average of precision and
>
< ci ¼ PnBi c recall, which is calculated by
B (7)
j¼1 j
>
:c ¼ c  P
m i6¼m ci
Where cm is the nodes number of the blockchain who has
maximum number of nodes.
The cross-chain query process includes five steps: (i)
Each single blockchain extracts some nodes and the nodes
of multiple chains together form a cross-chain query com-
mittee. (ii) A node belongs to any blockchain system send a
cross-chain query request to the node from cross-chain
query committee of their chain. (iii) The node who requests
the query request searches locally and broadcasts the query
to the entire cross-chain committee. (iv) After receiving the
request, nodes belonging to other chains in the cross-chain
committee will query locally, and return the query result
and VO to the committee node of the request chain. (v)
When the node who broadcast the query received the query
result, it downloads the block head information from other
nodes which returned it the results. Then it verifies the
query results through the Merkle proof. (vi) The verified
query result is sent to the node that originally submitted the
query request.
6 EXPERIMENT
6.1 Experimental Setup
Dataset Description. Our experiments are done on three col-
lections: (i) Inspec: The Inspec collection contains the
abstracts of 12684 scientific documents [44]. (ii) WWW: The
WWW dataset includes the abstracts and authors informa-
tion of the papers collected from the World Wide Web Con-
ference (WWW) published during the period 2004-2014,
with 1330 documents [45]. (iii) Wiki20: Wiki20 consists of
some English research reports covering different aspects of
computer science [46]. Since the Wiki20 dataset involves dif-
ferent aspects which have different data format, it is suitable
for cross-chain query evaluation.
Environment. Our experiments are performed using
Ethereum’s golang client geth on four 64-bit Linux servers
(Ubuntu 18.04) with Intel core i9-10th CPU and 32 GB of
memory.
Evaluation Metrics. For the system goals mentioned in
Section 3.3, we measure the following metrics
 Precision and recall: To test the correctness and com-
pleteness of our scheme, we use precision to repre-
sent correctness and use recall to represent
completeness. Precision indicates the proportion of
correct results in the query results, and it can be
calculated by the number of correct results divided
by the number of all returned results. The higher
the precision, the higher the proportion of correct
results returned by the system. Recall is the frac-
tion of the relevant documents that are success-
fully retrieved, and it can be calculated by the
number of correct results divided by the number
of results that should be returned. The higher the
recall, the higher the proportion of all correct
results returned by the system. Furthermore, to
trade off precision and recall, we also adopt F-
Authorized licensed use limited to: Chaitanya Bharathi Institute of Tech - HYDERABAD. Downloaded on August 03,2023 at 06:04:56 UTC from IEEE Xplore. Restrictions apply.
8239
1
F ¼ ; (8)
a P1 þ ð1  aÞ R1
where P represents the precision, R represents the
recall, and a is the proportion of P and R. In our
experiment, we set a to 0.5 because we deem the pre-
cision and the recall equally important. The higher
the F-value, the stronger the overall retrieval ability
of the system. (See Section 6.2.1)
 Query response time: Query response time is the
amount of time from the request is sent to all results
are received. Note that different types of queries and
nodes have different response time calculation meth-
ods. For keyword query and range query, full nodes
can query through the on-chain index locally, but
the light nodes need to connect a full node and make
an authenticated query through json-RPC or other
query interfaces. Besides, cross-chain query needs to
specify which chains to retrieve, and its response
time is the total time for queries on all blockchains.
(See Section 6.2.2)
 Indexing cost and authenticated query cost: Indexing
cost is composed of the time and space cost of con-
structing the index structure. In MSTDB, the time
cost is generated in the process of generating and
updating the index. The space cost is the extra stor-
age space after adding the semantic information to
block including the extra fields in the transaction
and on-chain index structure. Besides, since light
nodes can only connect to full nodes for authenti-
cated queries, they need to consume additional time
and space costs to verify the query results. (See
Section 6.2.3)
Benchmark. We adopt Ethereum1 as a benchmark in our
experiment. Although Ethereum does not have the same
query functions (e.g., multi-keyword and range query func-
tion) as MSTDB, we implement them in Ethereum by tra-
versing all transactions in all blocks on the blockchain.
6.2 Experimental Results
6.2.1 Precision and Recall
As discussed in Section 4.2.3, due to the prefix compression
feature, the extension nodes may cause multi-keyword
query errors. We evaluate the precision, recall and F-value
of the multi-keyword query in MSTDB with different num-
ber of keywords, and the results are given in Table 1. From
the result, we can find when there are more keywords pro-
vided to the multi-keyword query, the precision will be
higher, which denotes the correctness of the query result
will be improved. It is because when the user provides
more keywords, the query accesses deeper layer and avoids
querying the results from the extension nodes in MST thus
the results will be more related to the user’s input. Further-
more, more keywords can reduce the false positives in
Bloom filters, thus improving the precision. The recall and
F-value also increase when there are more keywords and
1. https://github.com/ethereum/go-ethereum
 8240 IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 35, NO. 8, AUGUST 2023
TABLE 1
Precisions, Recalls, and F-Values at Different Numbers of
Keywords
Keywords Precision Recall
1 0.733 0.549
2 0.809 0.588
3 0.863 0.665
4 0.889 0.773
5 0.909 0.802
non-inverted list 0.615 0.261
the reason is similar to that for the precision. And the result
of non-inverted list shows that the inverted list in MST is an
important component for the multi-keyword query.
In addition, since the range query only depends on the B
+ tree which only stores data on its leaf nodes and does not
end the search at the extension nodes, its result will be defi-
nitely accurate. Thus, we only test the precision and recall
of multi-keyword query here.
6.2.2 Query Response Time
To evaluate the query response time, we test the average
query time and worst-case query time for multi-keyword
query and range query in MSTDB under two datasets. Due
to the different contents in the two datasets, we choose dif-
ferent values as the range. In the Inspec dataset we use the
file size as the range value, and in the WWW dataset we use
the collection year of the paper as the range value. Besides,
we test the response time of full nodes and light nodes for
these two queries separately. As discussed in Section 4.3.4,
although a light node does not have the whole chain data, it
can connect to any full nodes and make the authenticated
query request.
The experimental results are given in Table 2, where FN
stands for full nodes in MSTDB, LN stands for light nodes
in MSTDB, and ETH stands for an Ethereum’s node.
Besides, we assemble some query statements at the end of
the index that will not be filtered by the Bloom filter to
determine the response time of our system in the worst
case. Note that the query in Ethereum’s node does not have
the value in the worst case because each query needs to tra-
verse the whole chain. From Table 2, we can see that the
average response time of MSTDB is within 10 ms for two
query types, which is less than 1/1000 of Ethereum. This
huge performance improvement means that our index
design is very effective and greatly enhances the usability of
the blockchain database. For different types of nodes, com-
pared to the full nodes, the light nodes need an extra aver-
age query time of nor more than 1 ms, which means that the
Response Times for Three Query Types
Query approach Multi-keyword
Dataset Inspec
Node type FN LN ETH FN
Mean (ms) 5 6 27804 5 5
Worst case (ms) 23 25 - 20
Authorized licensed use limited to: Chaitanya Bharathi Institute of Tech - HYDERABAD. Downloaded on August 03,2023 at 06:04:56 UTC from IEEE Xplore. Restrictions apply.
F-value
0.627
0.681
0.751
0.826
0.852 Fig. 9. Top-K query results with three methods.
0.366
authenticated query does not introduce a significant perfor-
mance degradation.
To evaluate the performance of Top-K query in MSTDB,
we test the average response time of 8000 Top-K queries
with three different parameters (Top-1, Top-10, Top-100)
under three inverted index traversal methods (TAAT,
DAAT, BAAT), and the results can be found in Fig. 9.
From the results of the Top-K query, we can see that our
BAAT scheme has a 65% and 30% performance improve-
ment over the traditional TAAT and DAAT schemes.
Therefore, the early termination method does play a role
in our Top-K query because it can skip some irrelevant
blocks directly.
For the cross-chain query, considering the response time
is related to the number of chains in the system, we divide
the Wiki20 collection into multiple parts and test the query
response time from 1 chain to 16 chains respectively, and
the results are given in Fig. 10. Because each additional
chain needs an additional cross-chain query and verification
process, the response time increases nearly linearly accord-
ing to the increase in the number of chains. Each additional
chain increases the cross-chain query time by approxi-
mately 5 ms.
6.2.3 Index Cost and Authenticated Query Cost
To evaluate the index cost of our MSTDB, we conduct a set
of comparative experiments to test the time and space costs
before and after adding the index structure.
Time Cost. Fig. 11 shows the time for generating a block
with and without the MSTDB under different numbers of
blocks. The block confirmation time in MSTDB is mainly
longer than that in the Ethereum system. The average con-
firmation time of MSTDB is about 1894 ms and approxi-
mately 1451 ms in Ethereum. This gap means that the
addition of the MST leads to a slightly increase of about 0.44
seconds in the average block generation time. The main rea-
son is that the full nodes in MSTDB need to process the
meta-data in the transaction and update the index structure
before generating blocks.
TABLE 2
Range
WWW Inspec WWW
LN ETH FN LN ETH FN LN ETH
23320 9 10 11790 4 4 3320
21 - 38 40 - 17 18 -
 ZHOU ET AL.: MSTDB: A HYBRID STORAGE-EMPOWERED SCALABLE SEMANTIC BLOCKCHAIN DATABASE
Fig. 10. Cross-chain query.
Fig. 11. Time cost for generating blocks with and without the MST.
Fig. 12. Space cost for generating blocks with and without the MST.
Space Cost. In space cost, MSTDB’s hybrid storage archi-
tecture needs to store three parts of data: off-chain data, on-
chain data, and index data. To compare the space cost of
MSTDB and traditional blockchain system, we use MSTDB
and Ethereum to store the same amount of raw data, and
test the space they occupy respectively. For Ethereum, we
store all data on the chain in the form of transactions. Since
the transaction volume may differ from block to block, we
test the space occupied by the blocks under different trans-
action data sizes. The result is shown in Fig. 12. We can see
that in the main part of the figure, we can see that most of
the data stored in our MSTDB (over 98%) are off-chain,
while Ethereum stores all data on-chain. To better illustrate
the MSTDB on-chain data, we provide a subfigure in
Fig. 12. It can be calculated that the on-chain storage space
required for each transaction in MSTDB is less than 1 KB,
which reduces the huge storage space compared with the
totally on-chain storage scheme (each transaction is about
50 KB). Therefore, our MSTDB system reduces a large
amount of on-chain storage costs through a hybrid storage
architecture without increasing the total storage data, and
enhances the scalability of the system.
Authorized licensed use limited to: Chaitanya Bharathi Institute of Tech - HYDERABAD. Downloaded on August 03,2023 at 06:04:56 UTC from IEEE Xplore. Restrictions apply.
8241
TABLE 3
The Result of Index Compression
Dataset Original MST Compact MST Compression rate
Inspec (46.3 MB) 3558bytes 1971bytes 55.39%
WWW (11.5 MB) 2442bytes 1455bytes 59.58%
TABLE 4
The Impact of Index Compression on Query Efficiency
Dataset Original MST Compact MST rate of prolongation
Inspec 5135 ms 5371 ms 4.23%
WWW 4398 ms 4447 ms 1.11%
Fig. 13. Scalability for MST-B+ tree and MST-VC.
Furthermore, since we use an index compression method
to shrink MST, we evaluate the storage space occupied by
MST before and after compression and the result is given in
Table 3. We store the two datasets in the MSTDB in the
same environment, and test the size of the MST before and
after compression. Compression rate [47] is an important
indicator to test the compression capability of some com-
pression algorithms. It can be calculated by the ratio of the
size of the data before and after compression, and the
smaller the compression rate, the better the compression
effect. Through the result, it can be seen that the compres-
sion rate of these two datasets can reach below 60%, which
means about 40% storage overhead of the MST index can be
saved by our compression technology. Moreover, to test the
impact of index compression on query efficiency, we sepa-
rately counted the time for 1000 multi-keyword queries on
the two datasets with the two structures before and after
compression, and the results are shown in Table 4. In
Table 4, we can see that the query efficiency of the original
MST and compressed MST is near while the compressed
MST is slightly lower. The query time of the compressed
MST on the two datasets is 1% and 4% longer than that of
the original MST, respectively. These slight efficiency drops
are acceptable compared to the huge space cost savings of
over 55%
We design a vector commitment (VC)-based scheme to
improve the scalability of MST-B+ tree in Section 5.4. The
VC scheme is implemented in Python 3.7 and based on
the RSA assumption. To evaluate the scalability of MST-VC,
we test the on-chain storage cost and update time on MST-B
+ tree and VC, and the results are shown in Figs. 13a and
13b. From Fig. 13b, we can see that as the number of
 8242 IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 35, NO. 8, AUGUST 2023
TABLE 5
The Comparison of MST-B+ Tree and MST-VC
Schemes B+ tree
Query time 3744 ms
VO size 2.6 MB
Verification time 583 ms
Fig. 14. The results of authenticated queries on two datasets.
transactions increases, the VC-based scheme requires less
on-chain storage space than the B+ tree-based scheme.
Fig. 13b shows that as the number of blocks increases, the
MST-B+ tree takes longer to update the ADS, while the VC
update time remains the same. Table 5 shows that for 1000
range queries, these two schemes have the same query effi-
ciency, and the VC-based scheme has a smaller VO size and
longer verification time. Due to the full range of perfor-
mance advantages, we choose the VC-based MST-B+ tree as
the default solution in MSTDB.
Authenticated Query Cost. To evaluate the cost of authenti-
cated query, we test the VO size and verification time of
some authenticated queries on two datasets and the result is
given in Fig. 14. From Fig. 14a, we can see that the VO size
increases as the number of queries increases. On average,
each query will generate about 3 KB of VO data, and the VO
size generated by storing the Inspec dataset is indeed larger
than thar of the WWW dataset. The result of Fig. 14b shows
that the verification time of authenticated queries is propor-
tional to the query result size. The verification throughput
can reach between 1500-1900 per second and the WWW
dataset has a faster verification time than the Inspec dataset.
Since the Inspec dataset has the documents in different
fields while WWW only has the documents of a single con-
ference, the keyword lists extracted from different docu-
ments are rarely duplicated for Inspec dataset, but are
similar for WWW dataset. In MST, the same keyword is on
the same path, and different keywords will produce differ-
ent paths. Therefore, a dataset with more types of content
such as Inspec dataset will make a larger index structure
and result in a larger VO and longer verification time in
MSTDB.
7 CONCLUSION
In this paper, we propose and implement a novel hybrid
semantic blockchain system called MSTDB, to add the
semantic feature to blockchain and solve the query chal-
lenge. Compared with other works, our MSTDB system has
the following innovations: (i) reducing the storage cost on
Authorized licensed use limited to: Chaitanya Bharathi Institute of Tech - HYDERABAD. Downloaded on August 03,2023 at 06:04:56 UTC from IEEE Xplore. Restrictions apply.
chain through a hybrid storage architecture (ii) building a
semantic link between on and off chain data (iii) designing
an on-chain index structure to support rich query functions
VC
(iv) providing a safe authenticated query scheme for light
3971 ms nodes.
2.0 MB In future, we will continue to improve the performance
997 ms
of our system, and plan to explore deeper data sharing sce-
narios in the blockchain, such as cross-chain knowledge
graph and sharing-based incentive mechanism.
ACKNOWLEDGMENTS
We thank the editors and anonymous reviewers of TKDE
and the powerful computation of remote server supported
by Alibaba Cloud EFLOPS AI Platform. Our previous work
related to this paper was presented at the International
Symposium on Reliable Distributed Systems (2020) and
won the best paper award runner up in the conference. The
conference paper is available at: https://ieeexplore.ieee.
org/document/9252029/
REFERENCES
[1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,”
2008. [Online]. Available: http://bitcoin.org/bitcoin.pdf
[2] G. Wood et al., “Ethereum: A secure decentralised generalised
transaction ledger,” Ethereum Project Yellow Paper, vol. 151,
no. 2014, pp. 1–32, 2014.
[3] H. Huang, W. Kong, S. Zhou, Z. Zheng, and S. Guo, “A survey of
state-of-the-art on blockchains: Theories, modelings, and tools,”
ACM Comput. Surveys, vol. 54, no. 2, pp. 1–42, 2021.
[4] K. Francisco and D. Swanson, “The supply chain has no clothes:
Technology adoption of blockchain for supply chain trans-
parency,” Logistics, vol. 2, no. 1, 2018, Art. no. 2.
[5] P. Kuhle, D. Arroyo, and E. Schuster, “Building a blockchain-
based decentralized digital asset management system for com-
mercial aircraft leasing,” Comput. Ind., vol. 126, 2021, Art. no.
103393.
[6] J. Yin et al., “SmartDID: A novel privacy-preserving identity
based on blockchain for IoT,” IEEE Internet Things J., early access,
2022, doi: 10.1109/JIOT.2022.3145089.
[7] Q. Ding, S. Gao, J. Zhu, and C. Yuan, “Permissioned blockchain-
based double-layer framework for product traceability system,”
IEEE Access, vol. 8, pp. 6209–6225, 2020.
[8] B. developer, Blockchain RPCS, 2019. [Online]. Available: https://
developer.bitcoin.org/reference/rpc/index.html
[9] M. El-Hindi, C. Binnig, A. Arasu, D. Kossmann, and R. Ramamur-
thy, “BlockchainDB: A shared database on blockchains,” Proc.
VLDB Endowment, vol. 12, no. 11, pp. 1597–1609, 2019.
[10] Y. Li, K. Zheng, Y. Yan, Q. Liu, and X. Zhou, “EtherQL: A query
layer for blockchain system,” in Proc. Int. Conf. Database Syst. Adv.
Appl., 2017, pp. 556–567.
[11] T. McConaghy et al., “Bigchaindb: A Scalable Blockchain Data-
base,” white paper, BigChainDB, 2016.
[12] Y. Xu, S. Zhao, L. Kong, Y. Zheng, S. Zhang, and Q. Li, “ECBC:
A high performance educational certificate blockchain with effi-
cient query,” in Proc. Int. Colloq. Theor. Aspects Comput., 2017,
pp. 288–304.
[13] C. Riegger, T. Vinçon, and I. Petrov, “Efficient data and indexing
structure for blockchains in enterprise systems,” in Proc. 20th Int.
Conf. Inf. Integration Web-based Appl. Serv., 2018, pp. 173–182.
[14] J. Eberhardt and J. Heiss, “Off-chaining models and approaches to
off-chain computations,” in Proc. 2nd Workshop Scalable Resilient
Infrastructures Distrib. Ledgers, 2018, pp. 7–12.
[15] B. node, Bitcoin chain size, [Online]. Available: https://
bitcoinvisuals.com/chain-size
[16] T. E. B. Explorer, Ethereum chain size, [Online]. Available:
https://cn.etherscan.com/
[17] K. Miyachi and T. Mackey, “hOCBS: A privacy-preserving block-
chain framework for healthcare data leveraging an on-chain and
off-chain system design,” Inf. Process. Manage., vol. 58, no. 3, 2021,
Art. no. 102535.
 ZHOU ET AL.: MSTDB: A HYBRID STORAGE-EMPOWERED SCALABLE SEMANTIC BLOCKCHAIN DATABASE
[18] S. J. Arulmozhi, K. Praveenkumar, and G. Vinayagamoorthi,
“Bitcoin in India: A deep down summary,” Adv. Innov. Res., vol. 6,
no. 2, 2019, Art. no. 28.
[19] J. Benet, “IPFS-content addressed, versioned, P2P file system,”
2014, arXiv:1407.3561.
[20] C. Zhang, M. Zhao, L. Zhu, W. Zhang, T. Wu, and J. Ni, “FRUIT: A
blockchain-based efficient and privacy-preserving quality-aware
incentive scheme,” IEEE J. Sel. Areas Commun., early access, Oct.
10, 2022, doi: 10.1109/JSAC.2022.3213341.
[21] J. Liang, Z. Qin, S. Xiao, L. Ou, and X. Lin, “Efficient and secure
decision tree classification for cloud-assisted online diagnosis
services,” IEEE Trans. Dependable Secure Comput., vol. 18, no. 4,
pp. 1632–1644, Jul./Aug. 2019.
[22] J. Liang, Z. Qin, L. Xue, X. Lin, and X. Shen, “Verifiable and secure
SVM classification for cloud-based health monitoring services,”
IEEE Internet Things J., vol. 8, no. 23, pp. 17029–17042, Dec. 2021.
[23] Z. Wu, Y. Xiao, E. Zhou, Q. Pei, and Q. Wang, “A solution to data
accessibility across heterogeneous blockchains,” in Proc. IEEE 26th
Int. Conf. Parallel Distrib. Syst., 2020, pp. 414–421.
[24] M. Herlihy, “Atomic cross-chain swaps,” in Proc. ACM Symp.
Princ. Distrib. Comput., 2018, pp. 245–254.
[25] Z. Gao, H. Li, K. Xiao, and Q. Wang, “Cross-chain oracle based data
migration mechanism in heterogeneous blockchains,” in Proc. IEEE
40th Int. Conf. Distrib. Comput. Syst., 2020, pp. 1263–1268.
[26] Z. Hong, S. Guo, P. Li, and W. Chen, “Pyramid: A layered shard-
ing blockchain system,” in Proc. IEEE Conf. Comput. Commun.,
2021, pp. 1–10.
[27] Z. Hong, S. Guo, R. Zhang, P. Li, Y. Zhan, and W. Chen, “Cycle:
Sustainable off-chain payment channel network with asynchro-
nous rebalancing,” in Proc. IEEE/IFIP 52nd Annu. Int. Conf. Depend-
able Syst. Netw., 2022, pp. 41–53.
[28] Y. Peng, M. Du, F. Li, R. Cheng, and D. Song, “FalconDB: Block-
chain-based collaborative database,” in Proc. ACM SIGMOD Int.
Conf. Manage. Data, 2020, pp. 637–652.
[29] M. Zhang, Z. Xie, C. Yue, and Z. Zhong, “Spitz: A verifiable database
system,” Proc. VLDB Endowment, vol. 13, no. 12, pp. 3449–3460,
Aug. 2020.
[30] C. Zhang, C. Xu, J. Xu, Y. Tang, and B. Choi, “GEM2-tree: A gas-
efficient structure for authenticated range queries in blockchain,”
in Proc. IEEE 35th Int. Conf. Data Eng., 2019, pp. 842–853.
[31] Y. Zhu, Z. Zhang, C. Jin, A. Zhou, and Y. Yan, “SEBDB: Semantics
empowered blockchain database,” in Proc. IEEE 35th Int. Conf.
Data Eng., 2019, pp. 1820–1831.
[32] C. Xu, C. Zhang, and J. Xu, “vChain: Enabling verifiable boolean
range queries over blockchain databases,” in Proc. Int. Conf. Man-
age. Data, 2019, pp. 141–158.
[33] C. Zhang, C. Xu, H. Wang, J. Xu, and B. Choi, “Authenticated key-
word search in scalable hybrid-storage blockchains,” in Proc. IEEE
37th Int. Conf. Data Eng., 2021, pp. 996–1007.
[34] Q. Pei, E. Zhou, Y. Xiao, D. Zhang, and D. Zhao, “An efficient
query scheme for hybrid storage blockchains based on merkle
semantic trie,” in Proc. IEEE Int. Symp. Reliable Distrib. Syst., 2020.
[35] A. Coglio, “Ethereum’s recursive length prefix in ACL2,” in Proc.
16th Int. Workshop ACL2 Theorem Prover Appl., 2020, pp. 108–124.
[36] C. Luo and M. J. Carey, “LSM-based storage techniques: A
survey,” VLDB J., vol. 29, no. 1, pp. 393–418, 2020.
[37] J. H. Paik, “A novel TF-IDF weighting scheme for effective
ranking,” in Proc. 36th Int. ACM SIGIR Conf. Res. Develop. Inf.
Retrieval, 2013, pp. 343–352.
[38] H. Bast and B. Buchhold, “An index for efficient semantic full-text
search,” in Proc. 22nd ACM Int. Conf. Inf. Knowl. Manage., 2013,
pp. 369–378.
[39] I. N. Yulita, H. L. The, and adiwijaya, “Fuzzy hidden markov
models for indonesian speech classification,” J. Adv. Comput. Intell.
Intell. Informat., vol. 16, no. 3, pp. 381–387.
[40] C. Buckley and A. F. Lewit, “Optimization of inverted vector
searches,” Proc. 8th Annu. Int. ACM SIGIR Conf. Res. Develop. Inf.
Retrieval, 1985, pp. 97–110.
[41] H. Turtle and J. Flood, “Query evaluation: Strategies and opti-
mizations,” Inf. Process. Manage., vol. 31, no. 6, pp. 831–850, 1995.
[42] D. Leung, Y. Gilad, S. Gorbunov, L. Reyzin, and N. Zeldovich,
“Aardvark: An asynchronous authenticated dictionary with appli-
cations to account-based cryptocurrencies,” in Proc. 31st USENIX
Secur. Symp., 2022, pp. 4237–4254.
[43] B. Pillai, K. Biswas, and V. Muthukkumarasamy, “Cross-chain
interoperability among blockchain-based systems using trans-
actions,” Knowl. Eng. Rev., vol. 35, 2020, Art. no. e23.
Authorized licensed use limited to: Chaitanya Bharathi Institute of Tech - HYDERABAD. Downloaded on August 03,2023 at 06:04:56 UTC from IEEE Xplore. Restrictions apply.
8243
[44] “IET inspec,” 2003. [Online]. Available: https://www.theiet.org/
publishing/inspec
[45] S. D. Gollapalli and C. Caragea, “Extracting keyphrases from
research papers using citation networks,” in Proc. 28th AAAI Conf.
Artif. Intell., 2014, pp. 1629–1635.
[46] O. Medelyan, I. Witten, and D. Milne, “Topic indexing with
wikipedia,” in Proc. AAAI Conf. Artif. Intell. Workshop, 2008.
[47] V. Anh and A. Moffat, “Improved word-aligned binary compres-
sion for text indexing,” IEEE Trans. Knowl. Data Eng., vol. 18,
no. 6, pp. 857–861, 2006.
Enyuan Zhou (Student Member, IEEE) received
the BE degree in information security from North-
eastern University, and the MSc degree in cyber-
space security from Xidian University, supervised
by prof. Qingqi Pei in ISN. He is currently working
toward the PhD degree with the Department of
Computing, Hong Kong Polytechnic University.
His current research interests include Blockchain,
database, and IR.
Zicong Hong (Graduate Student Member, IEEE)
received the BEng degree in software engineer-
ing from the School of Data and Computer
Science, Sun Yat-sen University. He is currently
working toward the PhD degree with the Depart-
ment of Computing, Hong Kong Polytechnic
University. His current research interests include
blockchain, game theory, Internet of Things, and
edge/cloud computing.
Yang Xiao (Member, IEEE) received the BS and
PhD degrees from Xidian University, in 2013,
2020, respectively. His research interests focus
on adversarial attacks and defence on graph
structured data, distributed trust management
and data privacy in AI.
Dongxiao Zhao He received the bachelor’s and
master’s degrees in information and communi-
cation engineering from Xidian University. He is
currently working toward the PhD degree with
the School of Telecommunications Engineering in
Xidian University. He used to work in software
development with ZTE. His current research
interests include Blockchain, database, distrib-
uted system.
Qingqi Pei (Senior Member, IEEE) received the
BS, MS, and PhD degrees in computer science
and cryptography from Xidian University in 1998,
2005, and 2008, respectively. He is currently a
professor and a member of the State Key Labora-
tory of Integrated Services Networks, Xidian Uni-
versity. His research interests focus on cognitive
network, data security, and physical layer secu-
rity. He is a professional member of ACM and a
senior member of the Chinese Institute of Elec-
tronics and China Computer Federation.
 8244 IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 35, NO. 8, AUGUST 2023
Song Guo (Fellow, IEEE) received the PhD
degree in computer science from the University
of Ottawa. He is currently a full professor with the
Department of Computing with The Hong Kong
Polytechnic University. Prior to joining PolyU, he
was a full professor with the University of Aizu,
Japan. His research interests are mainly in the
areas of cloud and green computing, Big Data,
wireless networks, and cyber-physical systems.
He has published more than 300 conference and
journal papers in these areas and received multi-
ple best paper awards from IEEE/ACM conferences. His research has
been sponsored by JSPS, JST, MIC, NSF, NSFC, and industrial compa-
nies. He has served as an editor for several journals, including IEEE
Transactions on Parallel and Distributed Systems, IEEE Transactions
on Emerging Topics in Computing, IEEE Transactions on Green Com-
munications and Networking, IEEE Communications Magazine, and
Wireless Networks. He has been actively participating in international
conferences as general chair and TPC chair. He is a senior member of
ACM, and an IEEE Communications Society Distinguished lecturer.
Authorized licensed use limited to: Chaitanya Bharathi Institute of Tech - HYDERABAD. Downloaded on August 03,2023 at 06:04:56 UTC from IEEE Xplore. Restrictions apply.
Rajendra Akerkar is professor and head of Big
Data Research Group, Western Norway Research
Institute (Vestlandsforsking), where his primary
domain of activities is Big Data and semantic tech-
nologies with aim to combine strong theoretical
results with high impact practical results. His
recent research focuses on application of Big
Data methods to real-world challenges in mobility,
transport, energy and emergency management.
He is serving as an associate editor of Interna-
tional Journal of Metadata, Semantics and Ontolo-
gies (IJMSO), associate editor of IEEE Open Journal of the Computer
Society (OJ-CS) and Knowledge Management Track editor of Web Intelli-
gence, an international journal. He has authored 16 books, 139 research
papers and edited 19 volumes of international conferences and work-
shops.He is also actively involved in several international ICT initiatives,
and research & innovation projects, including H2020 projects, for more
than 20 years.
" For more information on this or any other computing topic,
please visit our Digital Library at www.computer.org/csdl.