<<

arXiv:2003.05687v1 [cs.DC] 12 Mar 2020 aigtefaue etoe bv,bokhi tl lack still above, Desp mentioned industry. the features of secure, the parties more the having implementation among solut trust their less storage make involving au- to app central blockchain traditional enterprise any with their many of upgraded differences, permission these cations the cherish To without thority. transfer us immutability, to [2]. security control, dom administration numerous cryptographic database,” no in decentralization, hashes, chained and its like traditional blockchain ways from differs between Blockchain databas “difference a as “blockchain or as out carried been have blockchain capabil limited from matters. storage privacy suffer cloud solutions and decentralized has these using but blockchain by to solutions, store solved to somehow and where “How been problem on The decentralizat questions data”. This data. many store of raises insurance replica blockchain a markets, has of peer financial n each decentralized peers, this as of In industry. such application chain supply decentralized enterprises industries, of of development varied trans The peer in way. the to immutable pushed peer and for blockchain secure ledger a distributed in a actions as acting decade, A,DSTerm Immutability. Theorem, DCS CAP, eindseiclyfrbokhi n rvd oto the of features. cen most database privacy, with provide immutability, along and resistance, like that blockchain functionality databases of for different blockchain review proof specifically we the question, designed a conject for second ”DCS-satisfiability used using a the postulate was For By we it theorem, . CAP as the blockchain approach the relaxation analogous for Consis CAP theorem (Decentralization, the DCS ) the theore how influenced explain tolerance) databases for We latency. Availability, low (Consistency, and analytics, ri consistency, Consis real-time transactional (Atomicity, Durability) ACID and as Isolation, such features different h blockchain explain locking to we contributes question, first technology the functiona database For new databases? the of modern blockcha some introduction influenced How in the has 2. influenced and has technology t technology?, technology database addresses blockchain the of It development How Blockchain. 1. and questions: Databases : two fe h neto ici 1,mn usin bu the about questions many [1], bitcoin of invent the After last the from popularity immense gained has Blockchain Keywords Abstract Ti oki bu h uuliflec between influence mutual the about is work —This Bokhi,Dtbs,Dcnrlzto,ACID, Decentralization, Database, —Blockchain, rnsi eeomn fDtbssand Databases of Development in Trends .I I. ∗ owga nvriyo cec n ehooy(TU Tron (NTNU) Technology and Science of University Norwegian NTRODUCTION : aakRaikwar Mayank { † mayank.raikwar,danilog nvriyS.CrladMtoisSoj,Macedonia Skopje, Methodius and Cyril Ss. University Blockchain hqueries, ch ∗ known m aioGligoroski Danilo , sorship etwork yun- by tency, tency, ure.” free- lities } ion ing ion are ow wo ity ite e” li- nn.o goran.velinov@finki.ukim.mk @ntnu.no, in n s s - ntebokhi ytm nasmlrwyt h A theorem CAP the to way similar a in pres systems properties blockchain trade-off the the p in and this theorem DCS Finally, the solutions. describes da blockchain-enabled traditional provide or explanation use but platforms detailed that blockchain a solutions about of decentralized also design different is the work in of The used applications. be use that can databases specific or traditional of used abo the summary is work detailed about This a systematization [11]. providing nor industries or specific surveys some [10]) in numerous blockchain systems studies in blockchain found of the be cryptographi development of can specific those (that components the been about of and has neither work study characteristics is work no systematized This knowledge, trends. a our databases. towards of few blockchain very best done involves for the that per- to but [9] A However, done, database technologies. been distributed already blockchain has on and study database develop- formance the influenced of mutually ment and interchanged tremendous eeo lccandtbs ouin ospotSQL-like as support such to to startups efforts solutions queries. their as database devoted well blockchain have as [5], develop SAP, BigchainDB all database [4], and including with FlureeDB Oracle, indus- companies, database IBM, Few Many blockchain giants topic. features. their blockchain required built in the interesting already features have an database tries is clou of vice-versa and adoption scalability, or fast The latency, databases struct low hosting. blockchain query [3], rich These compliant types, data ACID parties. complex data like a network features on support the agreement joint by hav the block databases for mechanism distributed consensus These their introduced. and developed and efficiency its integrat database. now a are enhances with platforms blockchain application the of blockchai Many the both security. of database, features the la- and having low Thus with data. quer complex blockchain blockchain and scalability, a fast the throughput, leverage create high tency, will to or, features inclusion database blockchain The integ with database. either blockchain-oriented by traditional features the database ="">c ing traditional Blockchain has. the database leverage traditional which features some u Contribution. Our been have databases blockchain many years, recent In ∗ oa Velinov Goran , ntels eae ewtesda witnessed we decade, last the In hi,Norway dheim, † tabases fthe of e on ies aper ure, rat- ing are ent an of ut d n e c Influence Feature Database domain Blockchain domain direction High throughput and scalability X (in distributed databases) → To be implemented Transactions latency Low → High Serializable isolation Alternatives to 2-phase locking ← X ACID properties X → Hyperledger Fabric [6] due to CouchDB [7] Complex queries on the historic data X → Techniques such as VQL [8] Decentralization New, blockchain-style databases ← X Mechanisms that prevents deletes Immutability (tamper-resistance) ← X and record updates’ history

Movement of digital assets New, blockchain-style distributed ← X databases CAP (Consistency, Availability, Partition tolerance) X → DCS (Decentralization, Consistency, Scalability) I A SUMMARYOFTHEMUTUALINFLUENCEANDTHEENTANGLEDDEVELOPMENTOF DATABASES AND BLOCKCHAIN for the database systems [12]. We hope that our work will decade. Decentralization is not available in the traditional be useful for industries or academia within the blockchain distributed database. With the advent of new blockchain- as a guide for choosing the appropriate database for their style databases, the decentralization is now possible and blockchain use-cases from the list of databases mentioned. leads a promising growth to be used in many applications. Additionally, using our work, those involved in the research • One of the other excellent features of blockchain is and the development of modern databases can potentially immutability or tamper-resistance of transactions. This upgrade the functionalities of the databases that they are tamper-resistance can be achieved in database systems developing with some blockchain functionalities. by mechanisms that disallow the deletes and updates in II. MUTUALINFLUENCEANDDEVELOPMENT the database. Blockchain and database both can achieve many function- • Blockchain allows the creation and movement of digital alities and features by coping with each other. If we frame assets, which is not allowed in a classical database. But, a blockchain as a database to provide a storage mechanism, blockchain-style distributed database can have this feature then we can analyze how it differs from actual database as a built-in feature. systems. The following are the key points where blockchain In Table I we give a summary of this mutual influence and and database differ in their properties, but both can leverage the entangled development of databases and blockchain. and enhance the characteristics of each other. III. CAP THEOREM FOR BLOCKCHAIN CAP was introduced 20 years ago by Brewer [3] as a • Traditional blockchain throughput decreases when the principle or conjecture, and two years later, it was proven in processing capacity of nodes participating in the the asynchronous as a CAP theorem by Gilbert blockchain increases. Yet, in the case of the distributed and Lynch in [12]. In the same paper, similar impossibility database, the throughput increases when the nodes in- results were proven for a partially synchronous network model. creases. Hence throughput can be enhanced. Additionally, by weakening the consistency conditions, they • The latency of transactions in blockchain is usually high showed that it is possible to achieve all three properties in the compared to the latency in database. Thus, the latency so-called t-Connected . can be made low as desired with the use of a database. In more details, CAP theorem identifies the three specific • Transactions in blockchain require serializable isolation, which can be achieved by consensus pro- properties for any distributed/decentralized system. C A P viding strong consistency. For the databases, there is These properties are onsistency, vailability and artition a well-understood mechanism called 2-phase locking Tolerance. and concurrency-control [13]. However, new blockchain • Consistency - Any read in the distributed system gives databases such as BlockchainDB [14] based on Mon- the latest write on the nodes. goDB [15] start to offer new transaction mechanisms • Availability - A Client always receives a response at any based on blockchain. point of time irrespective of whether the read is the latest • Most of the blockchain platforms do not support complex write. queries in its historic data. These queries are needed in • Partition Tolerance - In case of partition between nodes many applications to the desired . in the distributed system, the system should still be The complex query feature is available in most of the functioning. databases, but the provenance queries on historic data can CAP theorem states that it is possible to achieve two of be supported by the use of Multi-Version Concurrency these three properties as guaranteed features in a distributed Control [16]. network, but it is impossible to achieve all three features at • The decentralization feature of blockchain has rewired the same time. In practice, a distributed system always needs most of the financial systems and industries from the last to be partition tolerant, thus leaving us to choose one property A (AP) S (CA) (CS) (DS) Cassandra [20], PostgreSQL, Hyperledger [6], IPFS [23] MySQL DynamoDB [21], MultiChain [25] CouchDB [7] C P C D (CP) (DC) MongoDB [15], HBase [18], Bitcoin [1], Ethereum [24] RedisDB [19] Fig. 2. DCS Triangle for Blockchain systems Fig. 1. CAP Triangle for Database systems Systems like Interplanetary (IPFS) [23] do not from Consistency or Availability. Hence, there is a trade-off provide consistency as the different parts of data are distributed between consistency and availability. to different nodes (thus, they are DS systems). Figure 2 depicts CAP theorem has also made its influence in the blockchain the different systems, according to the DCS theorem. (see, for example [17]). If we pick Availability over If we apply a similar relaxation approach as it was used for Consistency, any reads are not guaranteed to be up-to-date, and the proof of the CAP theorem in [12], we have the following we call the system as AP. However, if we choose Consistency reasoning: In DC systems, scalability is a big issue. Hence, over Availability, the system, called CP, would be unavailable to solve the scalability, many techniques are proposed, such at the time of partition and might disrupt the consensus. Thus as Sharding [26], Lightening network [27], or by using the in blockchain systems, both properties are desirable. Though scalable consensus algorithms. Furthermore, in DS systems, blockchain does not always require strong consistency, even- the consistency can be achieved by using the safe and verifi- tual consistency can serve the purpose and can be achieved able smart contracts, by making the blockchain attack resilient through consensus. For example, in the case of bitcoin, the and by handling the forks. Therefore in a way, all the DCS longest chain method brings eventual consistency, but there properties are achievable with some appropriate relaxations are no fix methods to achieve eventual consistency and leaves and balances. Here for blockchain systems, we postulate the this topic for debate. Figure 1 shows the different database following conjecture for achieving all three properties: Conjecture 1 (DCS-satisfiability): systems according to the CAP theorem. There a well- An analogy to the CAP theorem for blockchain have been balanced and relaxed of requirements for Decentralization, Consistency, and Scalability (DCS) properties such that a proposed as the DCS theorem [22], where DCS abbreviation blockchain system can have all three properties satisfied. refers to Decentralization, Consistency, Scalability. The DCS While for the CAP theorem, the relaxation of the require- theorem states that a blockchain system can have at most two ments was achieved by the introduction of the t-connected properties simultaneously out of the three estates of DCS. The consistency model, a precise analogous mathematical model- DCS properties can be defined as follows: ing for the blockchain systems is an active and open field of • Decentralization - There is no trusted entity controlling research. the network, hence no single point of failure. are inherently decentralized, but in the DCS triangle, IV. DATABASES FOR BLOCKCHAIN USE we are considering the case of full decentralization. In The database systems have been used for storing transaction the case of full decentralization, any node can the data of blockchain. The following databases have different network and participate as a validator. characteristics. Based on these characteristics, a database can • Consistency - The blockchain nodes will read the same be chosen to be used in particular blockchain applications. data at the same time. The query for the blockchain data A. Systems on any blockchain node should fetch the same result. The consistency in blockchain should prevent double- PostgreSQL [32] is a free and open-source relational spending and should be brought from the consensus database management system (RDBMS). It has a wide variety used. of native data types and supports user-defined objects, which • Scalability - The performance of blockchain should in- can be beneficial to define blockchain assets in the blockchain crease with the increase in the number of peers and system. It is highly modular, extensible, and also supports the number of allocated computational resources. The isolation on different levels. PostgreSQL has been used to throughput and the capacity of the system should be high, create blockchain relational database, where the replicas are and latency should be low. managed by different organizations that do not trust each In a similar way to CAP, we can also categorize the other [33]. blockchain systems in DCS as DC, CS, and DS systems as MySQL [34] and its community developed fork MariaDB is open source relational database system with advanced trade-offs between the DCS properties. Most of the crypto- 1 currencies like Bitcoin [1] can be considered as DC systems. and clustering features. OurSQL is a standalone Nevertheless, all the permissioned blockchains do not have 1https://en.bitcoinwiki.org/wiki/DPoS, http://oursql.org, full decentralization, hence should be regarded as CS systems. https://covenantsql.io, https://dqlite.io, http://www.rqlite.com/ Decentral- Low High System Consensus Consistency Scalability Immutability Sharding ization Latency Throughput MongoDB, BigchainDB Tendermint[28] ✓ ✓ ✓ ✓ ✓ ✓ ✓ RethinkDB Underlying BlockchainDB Key-Value Blockchain ✓ ✓ — ✓ ✗ ✗ ✓ Consensus Key-Value, Paxos [29] Cassandra ✓ ✓* ✓ ✗ ✓ ✓ ✓– store Consensus Whatever ChainifyDB Relational ledger ✓ — ✓ ✓ — ✓ — Consensus Raft CockroachDB Key-Value ✗ ✓ ✓ ✗ ✓ — ✓ Consensus Key-Value, No CosmosDB Document, ✗ ✓** ✓ ✗ ✓ ✓ ✓ Consensus Graph No CouchDB Key-Value ✗ ✓* ✓ ✗ ✓ ✓ ✓– Consensus DPOS 1, CovenantSQL SQLite DB ✓ ✓ — ✓ — — — BFT-Raft [30] C-Raft [31] Dqlite SQLite DB ✗ — — ✗ ✓ ✓ — Consensus Document, PBFT, FlureeDB ✓ ✓ ✓ ✓ ✓ ✓ ✓ Graph Raft No, but uses HBasechainDB HBase Blockchain ✓ ✓ ✓ ✓ ✓ ✓ ✓ Pipelining Document Raft MongoDB ✗ ✓ ✓ ✗ — ✗ ✓ Based Based POW type OurSQL Mysql ✓ — — ✓ — — — Consensus BFT Postchain Relational ✓ ✓ ✓ ✓ — — — Based Not ProvenDB MongoDB ✓ ✓ — ✓ — ✗ — Mentioned No QLDB Document ✗ ✓ ✓ ✓ — — — Consensus Raft Rqlite SQLite DB ✗ ✓** — ✗ — — — Consensus BFT TiesDB Document ✓ — — ✗ — — ✓ Based Raft TitaniumDB Key-Value ✗ ✓ ✓ ✗ — — ✓ Consensus No VoltDB Relational ✗ ✓ ✓ ✗ ✓ ✓ ✓ Consensus TABLE II COMPARISON MATRIX FOR DIFFERENT SYSTEMS.HERE, ‘✓’ INDICATES THAT THE FEATURE IS PRESENT, ‘✗’ INDICATES THAT THE FEATURE IS NOT PRESENTINTHECORRESPONDINGSYSTEM, ‘✓*’ REPRESENTSEVENTUALCONSISTENCY, ‘✓**’ REPRESENTSCONFIGURABLECONSISTENCY, ‘✓–’ REPRESENTS THAT DATABASE HAS ITS OWN SHARDING METHOD, ‘—’ REPRESENTS INCONCLUSIVE DATA connected to MySQL database. It is a combination of B. NoSQL Database Systems Blockchain and MySQL. OurSQL can be used for private MongoDB [15] is the fastest-growing document-based blockchain applications. database in the market. The distributed architecture of Mon- SQLite [35] is an embedded, non client-server, ACID- goDB makes it an ideal platform for building blockchain compliant relational database system. It is suitable to be databases. MongoDB offers data model flexibility, high scala- embedded as a local database in the blockchain nodes. bility, robust security, complex queries, and SQL capabilities. CovenantSQL (CQL) 1 is a decentralized, trusted, GDPR- Due to its powering technological features, it is used by many compliant with blockchain features built on SQLite. It can be leading enterprises nowadays. The MongoDB Enterprise edi- used as a low cost database as a (DBaaS). CQL has tion supports , auditing, sharding, and access con- layered architecture, consisting of Global Consensus Layer, trol. BigchainDB [5] was initially built upon RethinkDB [36] SQL Consensus Layer, and Datastore Layer. Dqlite 1 (dis- cluster, but from version 2.0 it employs Tendermint consen- tributed SQLite) is an open-source, fast, Disk-backed database sus [28] over a set of independent MongoDB instances. Also, with in-memory options. It best suits for fault-tolerant IoT ProvenDB [37] adds the blockchain characteristic layer on top and Edge devices. RQLITE 1 is an open-source, lightweight, of the MongoDB database. EthernityDB [38] can be used to fault-tolerant, and distributed relational database. It allows the integrate database functionalities in Ethereum blockchain [24] dynamic creation of a cluster of nodes and provides node-to- by modularizing the Ethereum smart contracts. EthernityDB node encryption. RQLITE appears a potential candidate for uses MongoDB for the coupling with Ethereum blockchain. the lightweight blockchain solutions. CouchDB [7] is a key-value and provides rich query capability similar to MongoDB. Hyperledger Fabric [6] system, many NewSQL systems evolved. These NewSQL uses CouchDB as a state database for storing chaincode systems can be useful for building blockchain applications. processed transaction data as key-value pairs. It supports rich Some of the promising NewSQL systems are as follows: queries against chaincode data. Hyperledger Composer also VoltDB [46] is an open-source, in-memory database. The uses CouchDB by converting SQL queries into CouchDB new version of VoltDB V8 adds many new capabilities. It JSON queries. supports user-defined SQL functions, which can be useful in QLDB QLDB [39] is a ledger database that smart contracts in blockchain. It provides SQL support for the abstracts many features of blockchain. It renders a tamper- traversal of blockchain records with recursive Common Table resistant, transparent, and cryptographically verifiable ledger Expressions (CTE). of transactions. QLDB lacks decentralization and hence does TiDB [47] (“Titanium DB”) is an open-source, distributed not follow any consensus algorithm. Therefore it best suits the SQL database with strong consistency and . It enterprises which do not require any consensus and still want has modular design containing three components for the clus- to have immutability of its data. QLDB also supports SQL ter coordination, replicating key-value store, and scheduling queries. SQL queries. Cassandra [20] is one of the most CockroachDB [48] is an open-source, key-value database. popular NoSQL database developed by . Currently, It supports strongly consistent ACID semantic and horizontal it is in use at many big enterprises like Netflix, Instagram, scalability. It uses 2-phase protocols for transaction Github, and eBay. It is a fully decentralized system and pro- . vides great performance, durability and without D. Modern databases influenced by blockchain compromising availability. Cassandra has its named CQL to interact with the system. When establishing FlureeDB [4] is a scalable blockchain database. It con- consistency, Cassandra also supports lightweight transactions. solidates blockchain with the document and TiesDB [40] is a public, decentralized, and distributed to support a broad range of industrial use cases. It provides database. Ties Network is a deep modification of the Cassandra rich access capability directly inside the database. It offers database. It is flexible on choosing an underlying NoSQL sharding, censorship resistance, privacy, cloud hosting, and database and hence inherits most of the features from the uses composite consensus, which enables multiple DBs to underlying database. It adds Byzantine fault tolerance (BFT), be queried as a single DB. Each block of blockchain in while most of the NoSQL database lacks BFT. It is fast and FlureeDB represents a unique time moment, and this feature supports sharding, smart contracts, and incentive schemes. It is called ”time-travel.” Many of the enterprise applications can be used to build decentralized applications providing fast with complex data-needs can benefit from FlureeDB and its data retrieval. features. CosmosDB Azure Cosmos [41] DB is Microsoft’s glob- Postchain [49] combines the features of a mature distributed ally distributed, fully-decentralized, multi-model database. The database and blockchain. A blockchain solution can be imple- database models can be key-value, graph, or document. It pro- mented using Postchain and SQL. It has powerful features vides availability and consistency with comprehensive service to manage integrity, validation, and data independence, along level agreements (SLAs). It offers multi-master replication with the inherited traits from the underlying standard database. BlockchainDB [14] implements a database layer on the across various regional distributions. Many enterprises can top of an existing blockchain system and leverages database benefit from building a decentralized blockchain application system capabilities like SQL queries. It provides partitioned using CosmosDB. storage of blockchain data among the peers in the network. HBase [42] is a NoSQL distributed database tuned for ChainifyDB [50] adds the blockchain characteristic layer the massive data sets. HBasechainDB [43] is a scalable big on top of a standard database. Hence, it leverages enterprises data store based on the of blockchain. This frame- to build decentralized cutting-edge blockchain applications on work gives the ability to the of blockchain. top of their database systems. HBaseChainDb works on the underlying HBase database [18] There are many other solutions for providing different func- in the Hadoop . It adds blockchain functionalities tionalities in blockchain systems. For example, OrbitDB [51] of decentralization and immutability on the top of HBase. can be an excellent choice for blockchain applications or HBaseChainDB can be used by enterprises whose systems decentralized apps (dApps). Moreover, some of the works are already exist in the Hadoop ecosystem. also oriented towards providing a specific functionality in the Some of the promising NoSQL databases for the use in blockchain. For example, JainDB 2, is a data for blockchain are RethinkDB [36], RedisDB [19], AWS Dy- JSON objects and provides REST API services to interact with namoDB [21], and Etcd [44]. the blockchain data store; vChain [52], VQL [8], delivers C. NewSQL Database Systems efficient and verifiable data query services in the blockchain Those are relational, distributed database systems that offer systems. The analysis presented in this section is summarized in Table II. ACID semantics without compromising the scalability. After the introduction of Spanner [45], the first NewSQL 2https://github.com/rzander/jaindb V. CONCLUSION [22] . Zhang and H.-A. Jacobsen, “Towards dependable, scalable, and pervasive distributed ledgers with blockchains.” in ICDCS, 2018, pp. The last decade was a decade of an intense interchanged 1337–1346. and mutually influenced development of the database and [23] J. Benet, “IPFS - content addressed, versioned, P2P file system,” arXiv, blockchain technologies. To the best of our knowledge, this is 2014. [Online]. Available: http://arxiv.org/abs/1407.3561 the first systematized study of those development trends. We [24] G. Wood, “Ethereum: A Secure Decentralised Generalised Transaction Ledger,” Yellow Paper, 2014. provided a detailed summary of traditional databases, which [25] “Multichain,” 2015. [Online]. Available: https://www.multichain.com/ are used or can be used in the design of blockchain platforms [26] L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert, and P. Saxena, or applications. Further, we presented a detailed explanation of “A Secure Sharding Protocol For Open Blockchains,” in Proceedings of the 2016 ACM SIGSAC Conference on and different decentralized solutions that uses traditional databases Security. ACM, 2016, pp. 17–30. and provides blockchain-enabled solutions. We also discussed [27] J. Poon and T. Dryja, “The Bitcoin Lightning the analogous theorem to the CAP theorem for the databases Network: Scalable off-chain instant payments,” known as DCS theorem and postulated an analogous DCS- https://www.bitcoinlightning.com/wp-content/uploads/2018/03/lightning-network-paper.pdf, 2016. satisfiability conjecture. [28] J. Kwon, “Tendermint: Consensus without mining,” Draft v. 0.6, fall, vol. 1, p. 11, 2014. [Online]. Available: https://tendermint.com REFERENCES [29] L. Lamport, “The part-time parliament,” ACM Transactions on Computer Systems (TOCS), vol. 16, no. 2, pp. 133–169, 1998. [1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system, [30] J. Clow and Z. Jiang, “A byzantine http://bitcoin.org/bitcoin.pdf,” 2009. fault tolerant raft,” 2017. [Online]. Available: [2] M. J. M. Chowdhury, A. Colman, M. A. Kabir, J. Han, and P. Sarda, https://www.scs.stanford.edu/17au-cs244b/labs/projects/clow jiang.pdf “Blockchain versus database: A critical analysis,” in 2018 IEEE Trust- [31] D. Ongaro and J. Ousterhout, “In search of an understandable consensus Com/BigDataSE, Aug 2018, pp. 1348–1353. algorithm,” in 2014 USENIX Annual Technical Conference. Philadel- [3] E. A. Brewer, “Towards robust distributed systems,” in PODC, vol. 7. phia, PA: USENIX Association, Jun. 2014, pp. 305–319. Portland, OR, 2000. [32] “Postgresql v10.” [Online]. Available: https://www.postgresql.org [4] “Flureedb,” 2017. [Online]. Available: https://flur.ee [33] S. Nathan, C. Govindarajan, A. Saraf, M. Sethi, and P. Jayachandran, [5] T. McConaghy et al., “BigchainDB: a scalable blockchain database,” “Blockchain meets database: Design and implementation of a blockchain White paper, 2016. relational database,” arXiv, 2019. [6] E. Androulaki et al., “Hyperledger fabric: A distributed [34] MariaDB Foundation , “MariaDB 10.5.0 now available,” Dec 2019. for permissioned blockchains,” in Proceedings of the Thirteenth EuroSys [Online]. Available: https://mariadb.org/mariadb-10-5-0-now-available/ Conference. ACM, 2018, pp. 30:1–30:15. [35] Hipp, Wyrick & Company, Inc., “SQLite,” 2020. [Online]. Available: [7] J. C. Anderson, J. Lehnardt, and N. Slater, CouchDB: the definitive https://www.sqlite.org/ guide: time to relax. O’Reilly Media, Inc., 2010. [36] L. Walsh, V. Akhmechet, and M. Glukhovsky, “Rethinkdb- [8] Z. Peng, H. Wu, B. Xiao, and S. Guo, “VQL: Providing Query Efficiency rethinking database storage,” 2009. [Online]. Available: and Data Authenticity in Blockchain Systems,” in 2019 IEEE ICDEW, https://pdfs.semanticscholar.org/3cdf/b12ceee0f82a08b352cead0bf791477dca98.pdf April 2019, pp. 1–6. [37] ProvenDB Team, “ProvenDB, Trust your data,” Yellow paper, 2019. [9] S. Bergman, M. Asplund, and S. Nadjm-Tehrani, “Permissioned [38] S. Helmer, M. Roggia, N. E. Ioini, and C. Pahl, “EthernityDB – blockchains and distributed databases: A performance study,” Concur- Integrating Database Functionality into a Blockchain,” in New Trends in rency and Computation: Practice and Experience, p. e5227, 2018. Databases and Information Systems. Springer International Publishing, [10] M. Raikwar, D. Gligoroski, and K. Kralevska, “SoK of used cryptogra- 2018, pp. 37–44. phy in blockchain,” IEEE Access, vol. 7, pp. 148 550–148 575, 2019. [39] “Amazon quantum ledger database,” 2019. [Online]. Available: [11] A. Hasselgren, K. Kralevska, D. Gligoroski, S. A. Pedersen, and https://aws.amazon.com/qldb/ A. Faxvaag, “Blockchain in healthcare and health sciences–a scoping review,” International Journal of Medical , p. 104040, 2019. [40] D. K. Anton Filatov, “Ties.network, database management system, technical description,” Yellow paper, Aug 2017. [12] S. Gilbert and N. Lynch, “Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services,” Acm Sigact News, [41] J. . Guay Paz, Introduction to Azure Cosmos DB. Berkeley, CA: vol. 33, no. 2, pp. 51–59, 2002. Apress, 2018, pp. 1–23. [13] H. T. Kung and J. T. Robinson, “On optimistic methods for concurrency [42] The Apache Foundation, “Welcome to Apache HBase,” 2020. control,” ACM Trans. Data. Syst., vol. 6, no. 2, pp. 213–226, Jun. 1981. [Online]. Available: https://hbase.apache.org/ [14] M. El-Hindi, M. Heyden, C. Binnig, R. Ramamurthy, A. Arasu, [43] M. S. Sahoo and P. K. Baruah, “Hbasechaindb – a scalable blockchain and D. Kossmann, “BlockchainDB - Towards a Shared Database on on hadoop ecosystem,” in Supercomputing Frontiers, Blockchains,” in Proceedings of the 2019 International Conference on R. Yokota and W. Wu, Eds. Cham: Springer International Publishing, Management of Data. ACM, 2019, pp. 1905–1908. 2018, pp. 18–29. [15] MangoDB, “Building enterprise-grade blockchain databases with mon- [44] “Etcd: A distributed, reliable key-value store for the most critical data godb,” White paper, Nov 2017. of a distributed system,” 2019. [Online]. Available: https://etcd.io [16] P. A. Bernstein and N. Goodman, “Multiversion concurrency controlthe- [45] J. C. Corbett, J. Dean, M. Epstein, A. Fikes, C. Frost, J. J. Furman, ory and algorithms,” ACM Trans. Data. Syst., vol. 8, no. 4, pp. 465–483, S. Ghemawat, A. Gubarev, C. Heiser, P. Hochschild et al., “Spanner: 1983. globally distributed database,” ACM Transactions on Computer [17] I. Weber, V. Gramoli, A. Ponomarev, M. Staples, R. Holz, A. B. Tran, Systems (TOCS), vol. 31, no. 3, pp. 1–22, 2013. and P. Rimba, “On availability for blockchain-based systems,” in 2017 [46] M. Stonebraker and A. Weisberg, “The VoltDB Main Memory DBMS,” IEEE SRDS, 2017, pp. 64–73. IEEE Data Eng. Bull., vol. 36, no. 2, pp. 21–27, 2013. [18] Mehul Nalin Vora, “Hadoop-hbase for large-scale data,” in Proceedings [47] “TiDB, SQL at Scale,” https://pingcap.com/en/, 2019. of 2011 International Conference on and Network [48] “CockroachDB, An evolution of the database,” 2017. [Online]. Technology, vol. 1, Dec 2011, pp. 601–605. Available: https://www.cockroachlabs.com [19] J. L. Carlson, in action. Manning Shelter Island, 2013. [49] J. M. Graglia and C. Mellon, “Blockchain and property in 2018: [20] A. Lakshman and P. Malik, “Cassandra: A decentralized structured At the end of the beginning,” Innovations: Technology, Governance, storage system,” SIGOPS Oper. Syst. Rev., vol. 44, no. 2, pp. 35–40, Globalization, vol. 12, no. 1-2, pp. 90–116, 2018. Apr. 2010. [50] F. M. Schuhknecht, A. Sharma, J. Dittrich, and D. Agrawal, “Chaini- [21] S. Sivasubramanian, “Amazon dynamoDB: a seamlessly scalable non- fyDB: How to Blockchainify any System,” 2019. relational database service,” in Proceedings of the 2012 ACM SIGMOD [51] “OrbitDB, Peer-to-Peer Databases for the Decentralized Web,” 2015. International Conference on Management of Data, 2012, pp. 729–730. [Online]. Available: https://orbitdb.org [52] C. Xu, C. Zhang, and J. Xu, “vChain: Enabling Verifiable Boolean Range Queries over Blockchain Databases,” in Proceedings of the 2019 International Conference on Management of Data, 2019, pp. 141–158.