Volume 7, Issue 12, December – 2022 International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

The Anatomy of Blockchain Database Systems

Blockchain Database System
Aditi Morey, Akanksha Kulkarni
School of Engineering Ajeenkya DY Patil University,
Pune, India-412105

Abstract:- Blockchains are here for more than ten- I. INTRODUCTIONS

fifteen years and currently, we are adopting the
blockchain techniques in databases, and vice-versa. In the last many years, the line between blockchain systems
Example, A typical blockchain data structures, such as and distributed databases has been disappeared to a certain degree.
cryptographically-linked blocks and Merkle trees, have We have seen adopting the blockchain techniques in databases.
been interspersed. Into verifiable databases. On the Example, blockchain data structures, such as cryptographically-
other hand, database techniques, such as sharding and linked blocks and Merkle trees , have been interspersed into
concurrency control, have been interspersed. Into verifiable ledger databases and hybrid blockchain database
blockchains. In this paper, I am looking at systems that systems. And we have also seen the database techniques used in
combine both blockchain and database techniques. I blockchains. For example, shading is used to scale blockchains,
classify these systems into three types and that is given while the optimistic concurrency control (OCC) is used to decrease
below (1) Permissioned Blockchains, (2) Hybrid the number of aborted transactions. By focusing on the design and
Blockchain Database Systems, (3) Ledger Databases. I implementation of systems that combine blockchain and database
also present their anatomy, including the features, techniques, we are classifying them into three categories. Going
techniques, and design choices, by analyzing a few from the systems that have strong blockchain features to the
representative systems. In the end, I highlight their systems that are very closer to the databases, these three categories
challenges and discuss research directions are as follows:- (1) permissioned blockchains, (2) hybrid
blockchain database systems, and (3) ledger databases. From a
effective view, all these systems consist of the distributed server
nodes that communicate via a broadcasting service based on some
consensus protocol. Each server node has a ledger (blockchain
data structure) and a local database. Both the server nodes and the
users (or clients) that interact with these nodes need to be
authenticated. The broadcasting service is implemented either with
a Crash Fault Tolerant (CFT) consensus protocol, that is closer to
distributed databases, or a Byzantine Fault Tolerant (BFT)
consensus that resembles typical blockchains. In this paper, we
analyze a few representative systems and present their anatomy in
terms of design, techniques, features, and limitations.

Table 1: Categories, Features and Examples

IJISRT22DEC1378 www.ijisrt.com 2200

Volume 7, Issue 12, December – 2022 International Journal of Innovative Science and Research Technology
ISSN No:-2456-2165
II. CLASSIFICATION permissioned blockchains however they need totally different
motivations, use cases, and database integration. These
When analyzing the systems that mix each info and systems are actuated by the necessity of organizations to share
blockchain techniques, we will distinguish 3 main categories. a database or elements of a database. In general, this info
First, we've permissioned blockchains (also referred to as non- already exists and it's loosely-coupled to the hybrid blockchain
public, enterprise, or consortium) that have a lot of blockchain database system. For example, during a provide chain scenario,
options than databases. Second, we have hybrid blockchain there ought to be a shared database with shipping choices
database systems which may be more classified into out-of- and costs. Shipping corporations update this database, whereas
blockchain databases and out-of- database blockchains. Third, the opposite parties simply scan the data. In such a case, we
we have (centralized) ledger databases. Table a pair of want a ledger to stay track of the updates in a clear and
presents the features of such systems and many samples of the tamper-evident way. Associate in Nursing authentication
progressive for every class Permissioned blockchains, as mechanism is required to access the ledger and also the
critical typical permission less or private blockchains broadcasting service. Given this, most of the projected hybrid
comparable to Bitcoin and Ethereum, use authentication for the blockchain database systems think about solely CFT broadcasting
parties using the blockchain (i.e., shoppers and peers). they're services. As expected, if a BFT agreement is used instead, the
named permissioned or non-public blockchains as a result of performance of the system considerably degrades.
solely echt parties will use them. These blockchains are
generally utilized in enterprise setups and that they are Ledger Databases are at the opposite finish of the
operated by a association of organizations, hence, they are centralized-decentralized administration spectrum since they're
known as enterprise or consortium blockchains. In such hosted and operated by one organization. In such a centralized
setups, a corporation hosts one or a lot of blockchain peers (or model, the users have to be compelled to trust that
nodes). Since quite one organization is responsible of organization. to extend the trust, ledger knowledgebases use
administrating and operational the blockchain, a permissioned tamper- evident data structures and publish the hashes of the
blockchain may be a redistributed system wherever the ledger append-only ledger or give proofs for current states within the
is replicated on all the nodes (or peers). Initially, a number of database. Such systems is also distributed to increase fault
these permissioned blockchains thought of victimisation tolerance and improve performance. However, they are not
Byzantine Fault Tolerant (BFT) agreement protocols to copy the distributed to increase the trust as is that the case for the
ledger. For example, Hyperledger material v0.6 used PBFT other two categories. Moreover, the database and the ledger
and gathering provides support for IBFT . However, these are tightly-coupled to the server nodes. While such systems
BFT protocols degrade the performance of a blockchain require higher trust from the users, they provide higher
regarding outturn and latency. that's why most of this performance and zero administration efforts compared to the
permissioned blockchains use Crash Fault Tolerant (CFT) other two categories.
consensus mechanisms, comparable to Raft and Apache
Kafka. Hybrid Blockchain info Systems are terribly similar to

Fig. 1: A Generic Hybrid Blockchain Database System

IJISRT22DEC1378 www.ijisrt.com 2201

Volume 7, Issue 12, December – 2022 International Journal of Innovative Science and Research Technology
ISSN No:-2456-2165
III. TYPES OF BLOCKCHAIN

Fig. 2: The types of blockchain

IV. ANATOMY or BFT consensus protocol.

In this section, we start with the similarities among the For example, the latest version of Fabric uses Raft, which
three categories, and after that we'll present the particularities is CFT, while Quorum supports, among others, IBFT. Each
of each category together with the details of a few server node connects to a local database and keeps a copy of
representative systems. the distributed ledger. Note that the local database and the
ledger are different. The former keeps the latest version of the
 Overview data (e.g., states, accounts, assets), while the latter keeps the
Typically, systems that combines the blockchain and entire update history using tamper-evident data structures. For
database features they have the similar architecture to the one example, Fabric uses LevelDB or CouchDB as its local
depicted in Figure 1. The system consists the same distributed database, which is also called World State. On the other hand,
server nodes, where each and every node handles user requests the ledger in Fabric is a linked list of blocks where the header
and also coordinates with the other nodes via a broadcasting of a block is linked to the header of the previous block using a
service. The clients need to be authenticated before sending the cryptographic hash. Other systems use data structures based on
requests to the nodes. A server node sends local updates and Merkle trees to represent the ledger. Figure 2 shows the types
receives remote updates from the broadcasting service. This of blockchain. We briefly compare these two ledger data
broadcasting service can also be distributed across a few nodes, structure, as illustrated in Figure 3.
it is not necessary that they are same as the server nodes.
Moreover, the broadcasting service is implemented with a CFT The hashed blocks data structure,

Fig. 3: Ledger Data Structures

IJISRT22DEC1378 www.ijisrt.com 2202

Volume 7, Issue 12, December – 2022 International Journal of Innovative Science and Research Technology
ISSN No:-2456-2165
As shown in Figure 3 it is a linked list of blocks where programming language). Of course, Quorum supports Solidity's
a block points to its predecessor using a cryptographic smart contracts, but it replaces the energy-inefficient proof-of-
pointer, except the first block which is called as the genesis work consensus with a few alternatives, of which Raft is the
block. Each block consists of data, metadata, and header default. In addition to Raft, Quorum also supports IBFT
sections. The data section contains all the transactions that (Istanbul BFT), QBFT (Quorum BFT), and Clique Proof- of-
are the part of the block. The header is a digest of the block Authority (POA). IBFT is inspired by PBFT, while QBFT is
add up using a hashing function. Lion's share of the an optimized version of IBFT that is also interoperable with
blockchains use SHA3 or Keccak hashing algorithms. The Hyperledger Beau, an Ethereum client developed by the
header of all the blocks except the first one is added up as Hyperledger Foundation.
the hash of the concatenation between the hash of the
previous block and the hash of the current block’s data As opposed to Fabric, Quorum has only peers and
section. A generic Merkle tree, as shown in Figure 3. It is a clients and adopts the traditional order-execute (OX)
tree where the leaves are data representing transactions and transaction lifecycle. That is, a transaction is first grouped
the internal nodes are hashes. Each parent node contains the into a block and then executed by each peer in the
hash of the concatenation of all the hashes of its children. network. Similar to Fabric, Quorum uses Level DB as its
Hence, the root node contains the hash that represents all the local database, but it adopts Merkle Patricia Trie for the
underlying transactions. We note that Merkle trees can be ledger. In our recent work, we show that Quorum with Raft
combined with hashed blocks: the data section of a block exhibits a throughput of 250 TPS, which is relatively
can be organized as a Merkle tree. For example, Quorum low for a permissioned blockchain. Corda is advertised
uses this approach to store transactions in its ledger. In as a distributed ledger technology (DLT) for enterprises.
contrast, Fabric does not use a Merkle tree: it just hashes the For that reason, it is built on Java and Kotlin so it can
transaction data as a chunk. We direct the reader to for an be better integrated with existing Java enterprise systems.
analysis of advanced Merkle tree data structures. Besides nodes, a Corda network has notaries which are
responsible for validating transactions in terms of
V. PERMISSION BLOCKCHAIN uniqueness and validity. In essence, uniqueness prevents
double-spending, while validity means that the transaction
Hyperledger Fabric is a permissioned blockchain passes the input-output tests and it has all the required
developed by the Linux Foundation with significant input from signatures. Notaries use a consensus protocol which is
IBM. There are three types of nodes in Fabric namely Clients, Raft-based in the default version of Corda. This default
Peers and Orderers. A client sends a transaction request to a set version uses H2, a relational database management system
of peers that are subject to an approval policy. For example, the written in Java, for the local database. The ledger uses a
AND policy includes all peers in the network. That is, a custom version of Merkle trees to hide transaction details
customer must submit the transaction and receive confirmations from the entities that are not involved in the transaction.
from all peers. A peer runs the transaction request in mock A recent publication shows that the performance of Corda
mode and creates read and write arrays to mark which world is very low, at 15 TPS. Even when a single notary is used
states are affected by the transaction. Because it is in to minimize the impact of consensus, the performance is
simulation mode, the peer does not save the changes to its local low due to a synchronous (blocking) transaction
database. The client then sends the peer responses to the payers processing mechanism. Diem is a permissioned
along with its transaction. These managers pack the transaction blockchain that was developed by a consortium of
into a block and broadcast the block to all peers in the network. companies led by Facebook. It was previously known as
Fabric is currently taking the Raft CFT consensus between the Libra blockchain. The entire project has been
orders. In the last phase, all peers validate the block and keep discontinued in 2022. However, Diem implements some
valid transaction changes in the local database. Note that the powerful features which are worth mentioning. For
peers don't need to redo the transaction: they just keep the write example, it uses Libra FT , a BFT consensus based on
set. The validation phase also checks the read record to see if Hotstuff which further improves PBFT. For the ledger,
any state has changed since the transaction was simulated. In Diem uses Jellyfish Merkle tree which is a sparse Merkle
such a case, the transaction is aborted. In short, Fabric tree inspired by the Merkle Patricia Trie used in
implements an Execute-Order-Validate (EOV or XOV) Ethereum. Rocks DB, a fast key-value store derived from
transaction lifecycle, unlike many other blockchains that adopt Level DB and developed by Facebook, is used as the
an Order-Execute (OX) lifecycle. Fabric supports Level DB underlying database. A recent study shows that Diem
(default) and CouchDB for world states database. The ledger is achieves around 600 TPS on 4 nodes, which is a decent
stored in the file system as a linked list of blocks, with the performance for a BFT-based blockchain.
block headers linked together using hashes. Fabric has been
extensively tested and optimized by the database research
community. Many works compare and analyze fabric
performance bottlenecks. In our recent work, we show that a
fabric with up to 10 peers can achieve around 1,000
transactions per second (TPS). Other work improves the
abandonment rate by relaxing the concurrency model (e.g.
through optimistic concurrency controls) and by rearranging
transactions. Quorum is a permissioned blockchain that gets its
source code from Ethereum (implemented in the Go

IJISRT22DEC1378 www.ijisrt.com 2203

Volume 7, Issue 12, December – 2022 International Journal of Innovative Science and Research Technology
ISSN No:-2456-2165
VI. HYBRID BLOCKCHAIN DATABASE is similar in design to Veritas, but is part of a
SYSTEM PostgreSQL relational database. In this sense, BRD is an
off-database blockchain. Also, unlike Veritas, the
 Veritas is an out-of-blockchain database that consists streaming service orders chunks of transactions (updates)
of a shared database (or table) and a blockchain ledger rather than serializing transactions in a chunk. To
for keeping auditable and verifiable updates done on speed up transactional execution, BRD implements
the shared database. Each node is operated by an concurrent execution with Serializable Snapshot
organization. A node uploads its local update logs and Isolation (SSI). Note that BRD uses PostgreSQL as
downloads remote update logs to and from a local database which supports serializable snapshot
broadcasting service. Veritas employs a concurrency isolation. BRD also uses Apache Kafka as a streaming
control mechanism based on timestamps. The service. Unlike Veritas, BRD maintains the general ledger
timestamp of a transaction represents the sequence in the same relational database, namely PostgreSQL.
number of that transaction in the log. A transaction is According to the BRD document, the system achieves a
first verified locally by the node receiving it. If it performance of 2500 TPS with a key value utilization.
passes the verification (e.g., multi-version concurrency BigchainDB is another non-database blockchain. It starts
control – MVCC), it is included in the logs and sent to with MongoDB, a NoSQL database used as a local
the broadcasting service. Once the other nodes agree to database. When using MongoDB, the main data
the updates, they send acknowledgments, and once abstraction in BigchainDB is an asset represented in
every node receives the acknowledgments, it persists JSON format. Otherwise, the transaction lifecycle is
the updates to the local database and appends them to similar to Veritas. A transaction is verified locally by a
the ledger. Note that this mechanism incurs O(N2 ) node, then a request is sent to the streaming service.
communication complexity. The original design of  BigchainDB is an asset represented in JSON format.
Veritas uses Redis, an in-memory NoSQL database, Otherwise, the transaction lifecycle is similar to Veritas.
and Apache Kafka, a CFT broadcasting service. The re- A transaction is verified locally by a node, then a
implementation of Veritas in achieves around 30,000 request is sent to the streaming service.
TPS, making it the fastest system among all those
analyzed in this paper. BigchainDB uses a BFT consensus middleware as
 Blockchain DB is an out-of-blockchain database with streaming service, namely Tendermint. Once the
prominent blockchain features: it is a shared database majority of nodes approve the transaction, it is
built over a blockchain. It is the only hybrid blockchain committed to the local database.
database that uses shading to partition the shared
BigchainDB relies on Tendermint to keep the
database. Firstly, the blockchain represents the storage
ledger in the form of a Merkle tree. Our evaluation of
layer of a Blockchain DB node. By default, Blockchain
the open source BigchainDB code shows a peak
DB uses Ethereum, but other blockchains can be used
performance of around 200 TPS with YCSB workloads.
as well via a plugin interface. With Ethereum, the
ledger  ChainifyDB is a chain of blocks outside the database,
starting from a relational database, which can be
The structure is based on Merkle Patricia Trie. PostgreSQL or MySQL. Apache Kafka is used to
Second, a node has a database layer with a simple key- stream transactions, which are SQL statements. The
value interface. Third, there is a shard manager that Ledger uses a custom style based on LedgerBlocks.
helps the database layer identify the shard where a
particular key is stored. Due to the use of such a slow A LedgerBlock contains all transactions that are
blockchain as Ethereum with Proof of Work (Pow) or part of a block, where a transaction is in its SQL
Proof of Authority (PoA), Blockchain DB has a format. The LedgerBlock then contains a list of bits
performance of around 50 TPS. Falcon DB is another representing successful transactions, a SHA256 hash
off-chain database that starts on a blockchain and digest of the data changed by the transactions, and a
provides clients with a shared database. Unlike other hash value of the previous LedgerBlock that was added
systems, Falcon DB Clients offers a relational database to the Ledger. This representation is similar to that
interface. In used by Fabric. ChainifyDB achieves throughput of
around 1000 TPS on three nodes using the SmallBank
 Falcon DB, both clients and peers must maintain a
workload when all three nodes need to reach
summary of data. The difference is that clients only
consensus. If only two out of three nodes need to reach
keep the blockchain headers to save storage space.
consensus, the throughput increases to around 5000
However, these headers are sufficient to verify the
TPS.
correctness of the requested data from the peers. Falcon
DB uses IntegriDB, an auditable SQL database, for
general ledger storage, Tendermint for consensus, and
MySQL as the local database. System performance on
a write-intensive YCSB workload (50% reads and 50%
writes) is around 3000 TPS. Note that a similar YCSB
workload is used to evaluate Veritas, BigchainDB, and
Blockchain DB. Blockchain Relational Database (BRD)

IJISRT22DEC1378 www.ijisrt.com 2204

Volume 7, Issue 12, December – 2022 International Journal of Innovative Science and Research Technology
ISSN No:-2456-2165
VII. LEDGER DATABASE changes done to the database in an immutable way.
While it is not clear what is the underlying database, the
Amazon Quantum Ledger Database QLDB is a ledger in QLDB is implemented based on Merkle trees.
verifiable database developed by Amazon and provided Our preliminary evaluation of QLDB shows a throughput
as a cloud service. QLDB follows the structure depicted of 10,000 TPS, which is relatively low for a centralized
in Figure 1 by integrating a relational database and a system. However, we note that an update in QLDB
ledger in its server node. The database keeps the current changes both the database and the ledger, and these two
states and the history of those states, while the ledger is changes are done sequentially.
an append-only journal that keeps track of all the

Table 2: Summary of Systems, Features, and Performance

LedgerDB could be a verifiable info developed by VIII. CHALLENGS

Alibaba associate degreed provided as a cloud service.
LedgerDB updates the ledger, that is predicated on a If we look at systems that combine blockchain and
Merkle tree, asynchronously. database functions, we see a lack of open source code for
most hybrid blockchain and ledger databases. Therefore, it
Specifically, the transactions are batched and also the is difficult to understand the exact implementation and
Merkle tree is updated with the batched transactions. evaluate the performance of these systems. In our previous
Hence, this approach is named batch accumulated Merkle work, we reimplemented Veritas and BlockchainDB in a
tree (bAMT). LedgerDB supports multiple underlying modular way that allows us to replace some of the
storage engines, however L-Stream, a custom storage components like the consensus mechanism and the local
developed by Alibaba, is that the default one. L-Stream is database. However, needs to do more to achieve a flexible
an append-only filesystem created specifically for and modular open-source hybrid blockchain database
LedgerDB. In terms of distributed architecture, the server system where consensus and the underlying database can be
nodes in LedgerDB are coordinated by a master that replaced in a plug-and-play manner. At the same time, such
ensures CFT and work balancing. Our preliminary systems must provide users with relational and key-value
analysis of LedgerDB shows a turnout of 20,000 TPS, interfaces.
twice higher compared to QLDB. SQL Ledger could be a
ledger info developed by Microsoft and offered as a We have found that most existing systems offer simple
service on its Azure cloud. it's an identical design to key-value interfaces, with the exception of FalconDB,
QLDB and Ledger DB, however it uses Microsoft’s SQL ChainifyDB, QLDB and SQL Ledger. What remains to be
Server because the underlying storage engine. SQL seen is the performance impact of a flexible user interface.
Ledger keeps a ledger organization supported Merkle trees For example, what are the implications of a relational
and 2 tables, namely, the Ledger Table and also the interface when the underlying database is NoSQL? For such
History Table. The Ledger Table reflects the most recent designs, the server node must be flexible enough and at the
record for a given key, whereas the History Table records same time have good performance
the previous version of that record. It is not clear what
variety of agreement is employed to coordinate among IX. CONCLUSION
multiple nodes in SQL Ledger. Moreover, the rumored
analysis was done on one server with seventy two cores. In this white paper, we discuss systems that combine
during this evaluation, SQL Ledger achieves a turnout of blockchain and database techniques. We classify these
70,000 TPS with TPC-C workloads. it's expected to check systems into three categories, namely (1) permissioned
lower SQL Ledger performance in an exceedingly blockchains, (2) hybrid blockchain database systems, and
distributed setting (3) ledger databases. Although they share a similar
architecture, each category and system within a category
has its own unique characteristics. Then we look at

IJISRT22DEC1378 www.ijisrt.com 2205

Volume 7, Issue 12, December – 2022 International Journal of Innovative Science and Research Technology
ISSN No:-2456-2165
some representative systems, such as Fabric, Quorum,
Veritas, QLDB, and LedgerDB, among others. The exact
performance of these systems is difficult to assess due to
the lack of open source code.

On the other hand, existing implementations are not

flexible and modular enough. By designing and
implementing a modular system where the UI, consensus,
and local storage are plug-and-play, we were able to
answer more existing questions. For example, can we
replace a CFT broadcast framework with a newer BFT
consensus framework without a performance hit? These
questions need to be answered in the future.

REFERENCES

[1.] Z. Amsden, et al., The Diem Blockchain,

https://archive.ph/1xfcy, 2021.
[2.] P. Antonopoulos, R. Kaushik, H. Kodavalla, S.
Rosales Aceves, R. Wong, J. Anderson, J.
Szymaszek, SQL Ledger: Cryptographically
Verifiable Data in Azure SQL Database, page
2437– 2449, 2021.
[3.] M. Baudet, A. Ching, A. Chursin, G. Danezis, F.
Garillot, Z. Li, D. Malkhi, O. Naor, D. Perelman, A.
Sonnino, State Machine Replication in the Libra
Blockchain, https://archive.ph/Uxlb3, 2019.
[4.] E. Buchman, Tendermint: Byzantine Fault
Tolerance in the Age of Blockchains, PhD thesis,
The University of Guelph, 2016.
[5.] V. Buterin, A Next-Generation Smart Contract
and Decentralized Application Platform, http://
archive.fo/Sb4qa, 2013.
[6.] Z. Gao, Y. Hu, Q. Wu, Jellyfish Merkle Tree,
https://archive.ph/s7pPF, 2019.
[7.] M. Hearn, R. G. Brown, Corda: A Distributed
Ledger, https://bit.ly/3iLajrI, 2019
[8.] T. T. A. Dinh, R. Liu, M. Zhang, G. Chen, B. C.
Ooi, J. Wang, Untangling Blockchain: A Data
Processing View of Blockchain Systems, IEEE
Transactions on Knowledge and Data Engineering,
30(7):1366–1385, 2018.
[9.] V. Buterin, A Next-Generation Smart Contract
and Decentralized Application Platform, http://
archive.fo/Sb4qa, 2013.
[10.] https://kafka.apache.org/, 2017.
[11.] BigchainDB 2.0 The Blockchain Database,
Technical report, 2018.
https://github.com/ConsenSys/quorum, 2021.
[12.] immudb,
https://codenotary.io/technologies/immudb/, 2021.
[13.] MongoDB, https://www.mongodb.com/, 2021.
[14.] PostgreSQL, https://www.postgresql.org/, 2021.
[15.] Amazon Quantum Ledger Database
https://aws.amazon.com/qldb/, 2022.
https://archive.ph/edzMi, 2022.

IJISRT22DEC1378 www.ijisrt.com 2206