{'fraction_non_alphanumeric': 0.02889055010773493, 'fraction_numerical': 0.005320786245107955, 'mean_word_length': 5.2840563691627525, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Trends in Development of Databases and Blockchain

This work is about the mutual influence between two technologies: Databases and Blockchain. It addresses two questions: 1. How the database technology has influenced the development of blockchain technology?, and 2. How blockchain technology has influenced the introduction of new functionalities in some modern databases? For the first question, we explain how database technology contributes to blockchain technology by unlocking different features such as ACID (Atomicity, Consistency, Isolation, and Durability) transactional consistency, rich queries, real-time analytics, and low latency. We explain how the CAP (Consistency, Availability, Partition tolerance) theorem known for databases influenced the DCS (Decentralization, Consistency, Scalability) theorem for the blockchain systems. By using an analogous relaxation approach as it was used for the proof of the CAP theorem, we postulate a"DCS-satisfiability conjecture."For the second question, we review different databases that are designed specifically for blockchain and provide most of the blockchain functionality like immutability, privacy, censorship resistance, along with database features.


I. INTRODUCTION
Blockchain has gained immense popularity from the last decade, acting as a distributed ledger for peer to peer transactions in a secure and immutable way. The development of blockchain pushed the market of decentralized applications in varied enterprises such as financial markets, insurance industries, supply chain industry. In this decentralized network of peers, each peer has a replica of data. This decentralization of blockchain raises many questions on "How and where to store data". The problem where to store blockchain data has been somehow solved by using decentralized cloud storage solutions, but these solutions suffer from limited capability and user privacy matters.
After the invent of bitcoin [1], many questions about the blockchain have been carried out as "blockchain as a database" or "difference between blockchain and database," [2]. Blockchain differs from traditional databases in numerous ways like its decentralization, cryptographic security using chained hashes, no administration control, immutability, freedom to transfer without the permission of any central authority. To cherish these differences, many enterprise applications upgraded their traditional database storage solution with blockchain to make their implementation more secure, involving less trust among the parties of the industry. Despite having the features mentioned above, blockchain still lacks some features which traditional database has. Blockchain can leverage the traditional database features by either integrating the traditional database with blockchain or, to create a blockchain-oriented distributed database. The inclusion of the database features will leverage the blockchain with low latency, high throughput, fast scalability, and complex queries on blockchain data. Thus having the features of both blockchain and database, the application enhances its efficiency and security. Many of the blockchain platforms are now integrating with a database.
In recent years, many blockchain databases have been developed and introduced. These distributed databases have their consensus mechanism for the joint agreement on a data block by the network parties. These blockchain databases support features like complex data types, rich query structure, ACID compliant [3], low latency, fast scalability, and cloud hosting. The adoption of database features in blockchain or vice-versa is an interesting research topic. Few industries have already built their blockchain database with all the required features. Many companies, including database giants IBM, Oracle, and SAP, as well as startups such as FlureeDB [4], BigchainDB [5], have devoted their efforts to develop blockchain database solutions to support SQL-like queries.
Our Contribution. In the last decade, we witnessed a tremendous interchanged and mutually influenced development of the database and blockchain technologies. A performance study on distributed database [9] for blockchain has already been done, but that involves very few databases. However, to the best of our knowledge, no work has been done towards a systematized study of those development trends. This work is neither about the specific cryptographic characteristics and components of the blockchain systems (that can be found in numerous surveys or systematization of knowledge studies [10]) nor about the specific use of blockchain in some specific industries [11]. This work is about providing a detailed summary of traditional databases that are used or can be used in the design of blockchain platforms or applications. The work is also about a detailed explanation of different decentralized solutions that use traditional databases but provide blockchain-enabled solutions. Finally, this paper describes the DCS theorem and the trade-off properties present in the blockchain systems in a similar way to the CAP theorem  for the database systems [12]. We hope that our work will be useful for industries or academia within the blockchain as a guide for choosing the appropriate database for their blockchain use-cases from the list of databases mentioned. Additionally, using our work, those involved in the research and the development of modern databases can potentially upgrade the functionalities of the databases that they are developing with some blockchain functionalities.
II. MUTUAL INFLUENCE AND DEVELOPMENT Blockchain and database both can achieve many functionalities and features by coping with each other. If we frame blockchain as a database to provide a storage mechanism, then we can analyze how it differs from actual database systems. The following are the key points where blockchain and database differ in their properties, but both can leverage and enhance the characteristics of each other.
• Traditional blockchain throughput decreases when the processing capacity of nodes participating in the blockchain increases. Yet, in the case of the distributed database, the throughput increases when the nodes increases. Hence throughput can be enhanced.
• The latency of transactions in blockchain is usually high compared to the latency in database. Thus, the latency can be made low as desired with the use of a database.
• Transactions in blockchain require serializable isolation, which can be achieved by consensus algorithms providing strong consistency. For the databases, there is a well-understood mechanism called 2-phase locking and concurrency-control [13]. However, new blockchain databases such as BlockchainDB [14] based on Mon-goDB [15] start to offer new transaction mechanisms based on blockchain.
• Most of the blockchain platforms do not support complex queries in its historic data. These queries are needed in many applications to retrieve the desired information.
The complex query feature is available in most of the databases, but the provenance queries on historic data can be supported by the use of Multi-Version Concurrency Control [16].
• The decentralization feature of blockchain has rewired most of the financial systems and industries from the last decade. Decentralization is not available in the traditional distributed database. With the advent of new blockchainstyle databases, the decentralization is now possible and leads a promising growth to be used in many applications.
• One of the other excellent features of blockchain is immutability or tamper-resistance of transactions. This tamper-resistance can be achieved in database systems by mechanisms that disallow the deletes and updates in the database.
• Blockchain allows the creation and movement of digital assets, which is not allowed in a classical database. But, a blockchain-style distributed database can have this feature as a built-in feature. In Table I we give a summary of this mutual influence and the entangled development of databases and blockchain.
III. CAP THEOREM FOR BLOCKCHAIN CAP was introduced 20 years ago by Brewer [3] as a principle or conjecture, and two years later, it was proven in the asynchronous network model as a CAP theorem by Gilbert and Lynch in [12]. In the same paper, similar impossibility results were proven for a partially synchronous network model. Additionally, by weakening the consistency conditions, they showed that it is possible to achieve all three properties in the so-called t-Connected Consistency model.
In more details, CAP theorem identifies the three specific system properties for any distributed/decentralized system. These properties are Consistency, Availability and Partition Tolerance.
• Consistency -Any read in the distributed system gives the latest write on the nodes.
• Availability -A Client always receives a response at any point of time irrespective of whether the read is the latest write.
• Partition Tolerance -In case of partition between nodes in the distributed system, the system should still be functioning. CAP theorem states that it is possible to achieve two of these three properties as guaranteed features in a distributed network, but it is impossible to achieve all three features at the same time. In practice, a distributed system always needs to be partition tolerant, thus leaving us to choose one property C A P (CP) MongoDB [15], HBase [18], RedisDB [19] (AP) Cassandra [20], DynamoDB [21], CouchDB [7] (CA) PostgreSQL, MySQL from Consistency or Availability. Hence, there is a trade-off between consistency and availability. CAP theorem has also made its influence in the blockchain realm (see, for example [17]). If we pick Availability over Consistency, any reads are not guaranteed to be up-to-date, and we call the system as AP. However, if we choose Consistency over Availability, the system, called CP, would be unavailable at the time of partition and might disrupt the consensus. Thus in blockchain systems, both properties are desirable. Though blockchain does not always require strong consistency, eventual consistency can serve the purpose and can be achieved through consensus. For example, in the case of bitcoin, the longest chain method brings eventual consistency, but there are no fix methods to achieve eventual consistency and leaves this topic for debate. Figure 1 shows the different database systems according to the CAP theorem.
An analogy to the CAP theorem for blockchain have been proposed as the DCS theorem [22], where DCS abbreviation refers to Decentralization, Consistency, Scalability. The DCS theorem states that a blockchain system can have at most two properties simultaneously out of the three estates of DCS. The DCS properties can be defined as follows: • Decentralization -There is no trusted entity controlling the network, hence no single point of failure. Blockchains are inherently decentralized, but in the DCS triangle, we are considering the case of full decentralization. In the case of full decentralization, any node can join the network and participate as a validator.
• Consistency -The blockchain nodes will read the same data at the same time. The query for the blockchain data on any blockchain node should fetch the same result. The consistency in blockchain should prevent doublespending and should be brought from the consensus algorithm used.
• Scalability -The performance of blockchain should increase with the increase in the number of peers and the number of allocated computational resources. The throughput and the capacity of the system should be high, and latency should be low. In a similar way to CAP, we can also categorize the blockchain systems in DCS as DC, CS, and DS systems as trade-offs between the DCS properties. Most of the cryptocurrencies like Bitcoin [1] can be considered as DC systems. Nevertheless, all the permissioned blockchains do not have full decentralization, hence should be regarded as CS systems.  [23] do not provide consistency as the different parts of data are distributed to different nodes (thus, they are DS systems). Figure 2 depicts the different systems, according to the DCS theorem.
If we apply a similar relaxation approach as it was used for the proof of the CAP theorem in [12], we have the following reasoning: In DC systems, scalability is a big issue. Hence, to solve the scalability, many techniques are proposed, such as Sharding [26], Lightening network [27], or by using the scalable consensus algorithms. Furthermore, in DS systems, the consistency can be achieved by using the safe and verifiable smart contracts, by making the blockchain attack resilient and by handling the forks. Therefore in a way, all the DCS properties are achievable with some appropriate relaxations and balances. Here for blockchain systems, we postulate the following conjecture for achieving all three properties: Conjecture 1 (DCS-satisfiability): There exist a wellbalanced and relaxed set of requirements for Decentralization, Consistency, and Scalability (DCS) properties such that a blockchain system can have all three properties satisfied.
While for the CAP theorem, the relaxation of the requirements was achieved by the introduction of the t-connected consistency model, a precise analogous mathematical modeling for the blockchain systems is an active and open field of research.

IV. DATABASES FOR BLOCKCHAIN USE
The database systems have been used for storing transaction data of blockchain. The following databases have different characteristics. Based on these characteristics, a database can be chosen to be used in particular blockchain applications.

A. Relational Database Systems
PostgreSQL [32] is a free and open-source relational database management system (RDBMS). It has a wide variety of native data types and supports user-defined objects, which can be beneficial to define blockchain assets in the blockchain system. It is highly modular, extensible, and also supports isolation on different levels. PostgreSQL has been used to create blockchain relational database, where the replicas are managed by different organizations that do not trust each other [33].
MySQL [34] and its community developed fork MariaDB is open source relational database system with advanced replication and clustering features. OurSQL 1 is a standalone No, but uses Blockchain Pipelining  SQLite [35] is an embedded, non client-server, ACIDcompliant relational database system. It is suitable to be embedded as a local database in the blockchain nodes.
CovenantSQL (CQL) 1 is a decentralized, trusted, GDPRcompliant with blockchain features built on SQLite. It can be used as a low cost database as a service (DBaaS). CQL has layered architecture, consisting of Global Consensus Layer, SQL Consensus Layer, and Datastore Layer. Dqlite 1 (distributed SQLite) is an open-source, fast, Disk-backed database with in-memory options. It best suits for fault-tolerant IoT and Edge devices. RQLITE 1 is an open-source, lightweight, fault-tolerant, and distributed relational database. It allows the dynamic creation of a cluster of nodes and provides node-tonode encryption. RQLITE appears a potential candidate for the lightweight blockchain solutions.

B. NoSQL Database Systems
MongoDB [15] is the fastest-growing document-based database in the market. The distributed architecture of Mon-goDB makes it an ideal platform for building blockchain databases. MongoDB offers data model flexibility, high scalability, robust security, complex queries, and SQL capabilities. Due to its powering technological features, it is used by many leading enterprises nowadays. The MongoDB Enterprise edition supports encryption, auditing, sharding, and access control. BigchainDB [5] was initially built upon RethinkDB [36] cluster, but from version 2.0 it employs Tendermint consensus [28] over a set of independent MongoDB instances. Also, ProvenDB [37] adds the blockchain characteristic layer on top of the MongoDB database. EthernityDB [38] can be used to integrate database functionalities in Ethereum blockchain [24] by modularizing the Ethereum smart contracts. EthernityDB uses MongoDB for the coupling with Ethereum blockchain.
CouchDB [7] is a key-value data store and provides rich query capability similar to MongoDB. Hyperledger Fabric [6] uses CouchDB as a state database for storing chaincode processed transaction data as key-value pairs. It supports rich queries against chaincode data. Hyperledger Composer also uses CouchDB by converting SQL queries into CouchDB JSON queries. QLDB Amazon QLDB [39] is a ledger database that abstracts many features of blockchain. It renders a tamperresistant, transparent, and cryptographically verifiable ledger of transactions. QLDB lacks decentralization and hence does not follow any consensus algorithm. Therefore it best suits the enterprises which do not require any consensus and still want to have immutability of its data. QLDB also supports SQL queries.
Cassandra Apache Cassandra [20] is one of the most popular NoSQL database developed by Facebook. Currently, it is in use at many big enterprises like Netflix, Instagram, Github, and eBay. It is a fully decentralized system and provides great performance, durability and fault tolerance without compromising availability. Cassandra has its query language named CQL to interact with the system. When establishing consistency, Cassandra also supports lightweight transactions.
TiesDB [40] is a public, decentralized, and distributed database. Ties Network is a deep modification of the Cassandra database. It is flexible on choosing an underlying NoSQL database and hence inherits most of the features from the underlying database. It adds Byzantine fault tolerance (BFT), while most of the NoSQL database lacks BFT. It is fast and supports sharding, smart contracts, and incentive schemes. It can be used to build decentralized applications providing fast data retrieval.
CosmosDB Azure Cosmos [41] DB is Microsoft's globally distributed, fully-decentralized, multi-model database. The database models can be key-value, graph, or document. It provides availability and consistency with comprehensive service level agreements (SLAs). It offers multi-master replication across various regional distributions. Many enterprises can benefit from building a decentralized blockchain application using CosmosDB.
HBase [42] is a NoSQL distributed database tuned for the massive data sets. HBasechainDB [43] is a scalable big data store based on the concept of blockchain. This framework gives the ability to handle the big data of blockchain. HBaseChainDb works on the underlying HBase database [18] in the Hadoop ecosystem. It adds blockchain functionalities of decentralization and immutability on the top of HBase. HBaseChainDB can be used by enterprises whose systems already exist in the Hadoop ecosystem.

C. NewSQL Database Systems
Those are relational, distributed database systems that offer ACID semantics without compromising the scalability. After the introduction of Google Spanner [45], the first NewSQL system, many NewSQL systems evolved. These NewSQL systems can be useful for building blockchain applications. Some of the promising NewSQL systems are as follows: VoltDB [46] is an open-source, in-memory database. The new version of VoltDB V8 adds many new capabilities. It supports user-defined SQL functions, which can be useful in smart contracts in blockchain. It provides SQL support for the traversal of blockchain records with recursive Common Table  Expressions (CTE).
TiDB [47] ("Titanium DB") is an open-source, distributed SQL database with strong consistency and high availability. It has modular design containing three components for the cluster coordination, replicating key-value store, and scheduling SQL queries.
CockroachDB [48] is an open-source, key-value database. It supports strongly consistent ACID semantic and horizontal scalability. It uses 2-phase commit protocols for transaction serializability.

D. Modern databases influenced by blockchain
FlureeDB [4] is a scalable blockchain database. It consolidates blockchain with the document and graph database to support a broad range of industrial use cases. It provides rich access capability directly inside the database. It offers sharding, censorship resistance, privacy, cloud hosting, and uses composite consensus, which enables multiple DBs to be queried as a single DB. Each block of blockchain in FlureeDB represents a unique time moment, and this feature is called "time-travel." Many of the enterprise applications with complex data-needs can benefit from FlureeDB and its features.
Postchain [49] combines the features of a mature distributed database and blockchain. A blockchain solution can be implemented using Postchain and SQL. It has powerful features to manage integrity, validation, and data independence, along with the inherited traits from the underlying standard database.
BlockchainDB [14] implements a database layer on the top of an existing blockchain system and leverages database system capabilities like SQL queries. It provides partitioned storage of blockchain data among the peers in the network.
ChainifyDB [50] adds the blockchain characteristic layer on top of a standard database. Hence, it leverages enterprises to build decentralized cutting-edge blockchain applications on top of their database systems.
There are many other solutions for providing different functionalities in blockchain systems. For example, OrbitDB [51] can be an excellent choice for blockchain applications or decentralized apps (dApps). Moreover, some of the works are also oriented towards providing a specific functionality in the blockchain. For example, JainDB 2 , is a data warehouse for JSON objects and provides REST API services to interact with the blockchain data store; vChain [52], VQL [8], delivers efficient and verifiable data query services in the blockchain systems. The analysis presented in this section is summarized in Table II. V. CONCLUSION The last decade was a decade of an intense interchanged and mutually influenced development of the database and blockchain technologies. To the best of our knowledge, this is the first systematized study of those development trends. We provided a detailed summary of traditional databases, which are used or can be used in the design of blockchain platforms or applications. Further, we presented a detailed explanation of different decentralized solutions that uses traditional databases and provides blockchain-enabled solutions. We also discussed the analogous theorem to the CAP theorem for the databases known as DCS theorem and postulated an analogous DCSsatisfiability conjecture.