Blockchain Meets Database: Design and Implementation of a Blockchain Relational Database Senthil Nathan1, Chander Govindarajan1, Adarsh Saraf1, Manish Sethi2, and Praveen Jayachandran1 1IBM Research - India, 2IBM Industry Platforms, USA 1(snatara7, chandergovind, adasaraf, praveen.j)@in.ibm.com, [email protected] ABSTRACT In this paper, we design and implement the first-ever de- consensus among a set of untrusted parties. Opinion on the centralized replicated relational database with blockchain technology has varied widely from being hailed as the biggest properties that we term blockchain relational database. We innovation since the Internet to being considered as another highlight several similarities between features provided by database in disguise. For the first time, we undertake the blockchain platforms and a replicated relational database, challenge of explaining blockchain technology from the per- although they are conceptually different, primarily in their spective of concepts well known in databases, and highlight trust model. Motivated by this, we leverage the rich fea- the similarities and differences between the two. Existing tures, decades of research and optimization, and available blockchain platforms [18, 52, 40, 15], in an attempt to build tooling in relational databases to build a blockchain rela- something radically new and transformative, rebuild a lot of tional database. We consider a permissioned blockchain features provided by databases, and treat it as just a store model of known, but mutually distrustful organizations each of information. We take a contrarian view in this paper. operating their own database instance that are replicas of By leveraging the rich features and transactional process- one another. The replicas execute transactions indepen- ing capabilities already built into relational databases over dently and engage in decentralized consensus to determine decades of research and development, we demonstrate that the commit order for transactions. We design two approach- we can build a blockchain relational database with all fea- es, the first where the commit order for transactions is agreed tures provided by existing blockchain platforms and with upon prior to executing them, and the second where trans- better support for complex data types, constraints, triggers, actions are executed without prior knowledge of the commit complex queries, and provenance queries. Furthermore, our order while the ordering happens in parallel. We leverage approach makes building blockchain applications as easy as serializable snapshot isolation (SSI) to guarantee that the building database applications; developers can leverage the replicas across nodes remain consistent and respect the or- rich tooling available for backup, analytics, and integration dering determined by consensus, and devise a new variant with existing enterprise systems. Applications that have of SSI based on block height for the latter approach. We a strong compliance and audit requirements and need for implement our system on PostgreSQL and present detailed rich analytical queries such as in financial services that are performance experiments analyzing both approaches. already built atop relational databases, or ones that are reliant on rich provenance information such as in supply PVLDB Reference Format: chains are likely to most benefit from the blockchain rela- Senthil Nathan, Chander Govindarajan, Adarsh Saraf, Manish tional database proposed in this paper. Sethi, Praveen Jayachandran. Blockchain Meets Database: De- sign and Implementation of a Blockchain Relational Database. With a focus on enterprise blockchain applications, we tar- PVLDB, 12(11): 1539-1552, 2019. get a permissioned setup of known but untrusted organiza- DOI: https://doi.org/10.14778/3342263.3342632 tions each operating their own independent database nodes but connected together to form a blockchain network. These 1. INTRODUCTION database nodes need to be replicas of each other but dis- trust one another. Replication of transaction logs and state Blockchain has gained immense popularity over recent among multiple database nodes is possible using master- years, with its application being actively explored in several slave [17, 26, 46, 51] and master-master [26, 49, 51] proto- industries. At its core, it is an immutable append-only log cols. In these protocols, the master nodes need to be trusted; of cryptographically signed transactions, that is replicated for any transaction, a single node executes it and propagates and managed in a decentralized fashion through distributed the final updates to other nodes either synchronously [39, 21, 45] or asynchronously [29, 43, 47] , which would not work This work is licensed under the Creative Commons Attribution- in a blockchain network. Hence, transactions need to be NonCommercial-NoDerivatives 4.0 International License. To view a copy independently executed on all nodes. Further, such an ex- of this license, visit http://creativecommons.org/licenses/by-nc-nd/4.0/. For ecution and subsequent commits across multiple untrusted any use beyond those covered by this license, obtain permission by emailing nodes must result in the same serializable order to ensure [email protected]. Copyright is held by the owner/author(s). Publication rights consistency. We need a novel replication protocol with a licensed to the VLDB Endowment. notion of decentralized trust. Although fault-tolerant syn- Proceedings of the VLDB Endowment, Vol. 12, No. 11 chronous commit protocols [30, 50] exist, they cannot be ISSN 2150-8097. DOI: https://doi.org/10.14778/3342263.3342632 used as they either require a centralized trusted controller 1539 or multple rounds of communications per transaction which (2) User authenticity & non-repudiability: Permis- would be costly in a network with globally distributed nodes. sioned blockchain systems employ public key infrastructure In this paper, we address this key challenge of ensuring for user management and ensuring authenticity. Users be- that all the untrusted database nodes execute transactions long to organizations that are permissioned to participate independently and commit them in the same serializable or- in the network. Transactions are digitally signed by the in- der asynchronously. Towards achieving this, we make two voker and recorded on the blockchain, making them non- key design choices. First, we modify the database to sep- repudiable. Relational databases have sophisticated user arate the concerns of concurrent transaction execution and management capabilities including support for users, roles, decentralized ordering of blocks of transactions. We leverage groups, and various user authentication options. However, ordering through consensus only to order blocks of transac- submitted and recorded transactions are not signed by the tions, and not for the serializable ordering of transactions invoker making them repudiable. within a single block. Second, independently at each node, (3) Confidentiality & access control: Some permis- we leverage serializable snapshot isolation (SSI) [24, 44] to sioned blockchains support the notion of confidentiality; sm- execute transactions concurrently and then serially validate art contracts, transactions and data are only accessible by & commit each transaction in a block to obtain a serializable authorized users. In addition, access to invoke functions order that will be identical across all untrusted nodes. and to modify data is restricted to specific users. Relational We make the following contributions in this paper: (1) We databases have comprehensive support for access control on devise two novel approaches of building a blockchain plat- tables, rows, columns and PL/SQL procedures. Some re- form starting from a database, (a) where block ordering is lational databases even provide features like content-based performed before transaction execution, (b) where transac- access control, encryption and isolation of data. Advanced tion execution happens parallelly without prior knowledge confidentiality features where only a subset of the nodes have of block ordering. (2) We devise a new variant of serializable access to a particular data element or smart contract can be snapshot isolation [44] based on block height to permit trans- implemented, although we don’t consider that in this paper. action execution to happen parallelly with ordering. (3) We (4) Immutability of transactions and ledger state: implement the system in PostgreSQL using only 4000 lines The blockchain ledger is an append-only log of blocks con- of C code and present the modified architecture. taining sets of transactions that are chained together by The rest of this paper is organized as follows. We highlight adding the hash of each block to it’s succeeding block. This the properties required in a blockchain platform, motivate makes it difficult for an attacker to tamper with a block and how several of these are either partially or fully available avoid detection. The ledger state can only be modified by in relational databases, and identify shortcomings that need invoking smart contract functions recorded as transactions to be addressed in §2. We discuss our design in §3 and on the blockchain and are immutable otherwise. Although a describe two approaches to transaction processing leveraging database logs all submitted transactions, executed queries, serializable snapshot isolation. We provide an account of our and user information, it isn’t possible to detect changes to prototype implementation on PostgreSQL