Not ACID, not BASE, but SALT A Transaction Processing Perspective on Blockchains Stefan Tai, Jacob Eberhardt and Markus Klems Information Systems Engineering, Technische Universitat¨ Berlin fst, je, [email protected] Keywords: SALT, blockchain, decentralized, ACID, BASE, transaction processing Abstract: Traditional ACID transactions, typically supported by relational database management systems, emphasize database consistency. BASE provides a model that trades some consistency for availability, and is typically favored by cloud systems and NoSQL data stores. With the increasing popularity of blockchain technology, another alternative to both ACID and BASE is introduced: SALT. In this keynote paper, we present SALT as a model to explain blockchains and their use in application architecture. We take both, a transaction and a transaction processing systems perspective on the SALT model. From a transactions perspective, SALT is about Sequential, Agreed-on, Ledgered, and Tamper-resistant transaction processing. From a systems perspec- tive, SALT is about decentralized transaction processing systems being Symmetric, Admin-free, Ledgered and Time-consensual. We discuss the importance of these dual perspectives, both, when comparing SALT with ACID and BASE, and when engineering blockchain-based applications. We expect the next-generation of decentralized transactional applications to leverage combinations of all three transaction models. 1 INTRODUCTION against. Using the admittedly contrived acronym of SALT, we characterize blockchain-based transactions There is a common belief that blockchains have the – from a transactions perspective – as Sequential, potential to fundamentally disrupt entire industries. Agreed, Ledgered, and Tamper-resistant, and – from Whether we are talking about financial services, the a systems perspective – as Symmetric, Admin-free, sharing economy, the Internet of Things, or future en- Ledgered, and Time-consensual. ergy markets – any application where some form of Following either ACID, BASE, or SALT naturally trade and agreement among different parties occurs is results in different notions of transactions and dif- deemed a candidate for blockchains. And when us- ferent transactional system architectures. Using two ing blockchains, so the promise, trustless interactions real-world application examples that use blockchains – in the sense that trust no longer must be managed we illustrate how different business transactions map by some central or intermediating party – and hence to a combination of these three transaction models lowered transaction costs and other benefits of decen- and corresponding data management components. tralization are introduced. Is this considerable interest in blockchain technol- ogy justified? What are blockchain-based transac- 2 BLOCKCHAINS tions? How do blockchain-based transactions com- pare to traditional database and distributed systems Since its inception in 2008 as the technology behind transactions? Do blockchains replace other database Bitcoin (Nakamoto, 2008), blockchains are discussed technology and systems or should they be used as a in a diversity of communities in research and practice. complement? These include cryptocurrency and security, databases In this keynote paper, we take a transaction pro- and distributed systems, IT law, entrepreneurship, and cessing perspective on blockchains. With relational many more. In addition, blockchain developer com- database management systems that implement ACID munities exist, focusing on specific blockchain tech- transactions, and cloud systems and NoSQL stores nologies such as Bitcoin, Ethereum, Hyperledger, and that favor the BASE model, we have two established other. Out of the many views on blockchains and cor- models to compare blockchain-based transactions responding definitions that exist, we like to emphasize the following three: • A transaction consisting of multiple operations is executed as a whole or not at all (“all or nothing”). 1. A blockchain is a peer-to-peer protocol for trust- less execution and recording of transactions se- • Each transaction transforms the database from cured by asymmetric cryptography in a consistent one consistent, valid state to another, adhering and immutable chain of blocks – the blockchain to all validation rules and database integrity con- developers and technology view. straints. 2. A blockchain is a shared append-only distributed • Concurrent transactions are executed by maintain- database with full replication and a cryptographic ing isolation, that is, by executing them as if they transaction permissioning model – the IT architect were sequential. and data management view. • Once a transaction has been committed, the re- sults become permanent. 3. A blockchain is a shared decentralized ledger, en- abling business disintermediation and trustless in- The responsibilities to achieve the ACID proper- teractions, thereby lowering transaction costs – ties are spread across different components of a TP the business executive and applications view. system (Bernstein and Newcomer, 2009). A transac- tion manager component typically is required to drive With each of these three definitions, a different coordination protocols among the resource managers, emphasis is set, focusing either on the protocol aspect, for example, the 2PC completion protocol. Consis- the data management aspect, or the decentralization tency is a responsibility of components that perform aspect of blockchains. Yet, all three definitions make validation checks, for example, by using the rules use of the term transaction. In the following, we thus of the database itself. Isolation requires some con- take a closer look at what a transaction is and how currency control, which typically relies upon locking such transactions traditionally have been supported by protocols such as the 2PL. And durability typically is transaction processing systems. a responsibility of the database itself. Figure 1 illustrates a TP system in support of ACID transactions. An application interacts with 3 TRADITIONAL the transaction manager to begin (1) and end (3) a transaction as a logical unit-of-work. Each transac- TRANSACTIONS AND TP tion groups a set of operations (2) on one or more SYSTEMS databases (resources). For each resource involved in a transaction, a resource manager component ex- A (business) transaction, in its most generic sense and ists. The resource managers must be registered with as used in commerce, is an instance of buying or sell- the transaction manager and must understand proto- ing something. In computer science, a transaction is cols and provide interfaces in support of transaction a logical unit of work performed within a transaction processing, e.g., the X/Open XA interface, so that processing system (TP system). A TP system, in turn, the transaction manager can run completion protocols refers to an information processing system that di- when committing the transaction (4). vides all processing work into transactions, in a way that each transaction can be guaranteed a set of prop- Application erties by the system. 2 3.1 Understanding ACID RM1 RM2 interface interface XA XA interface interface 1 3 In the 1980s, relational database management sys- Resource Resource tems (RDBMS) based on Codd’s relational model Manager Manager were first introduced. With the addition of TP tech- Tx nologies to RDBMS a few years later, originally pro- interface posed by Jim Gray, the acronym “ACID transaction” Resource Resource Transaction was born (Gray and Reuter, 1992). ACID refers to a Manager set of guarantees for each transaction to be processed 4 by the TP system: Atomicity, Consistency, Isolation, Figure 1: Architecture of a TP system supporting ACID and Durability. transactions. ACID has since been understood as a very conve- nient model: Guaranteeing the ACID properties implies that whenever things do go wrong, the TP system will item, will only eventually converge to a consistent detect the failure and rollback any intermediate steps state. taken, if necessary. Figure 2 illustrates a system that follows the BASE model. An application interacts either directly 3.2 Understanding BASE with a resource managing component (1.b), or, more typically, through some load balancer (1.a) that dis- With the emergence of unprecedented scalability tributes incoming requests to peers of nodes with needs of modern Web applications, an alternative to symmetrical responsibilities and capabilities. Re- the rather expensive and consistency-focused ACID quests are served by one or more resource managers model was introduced: BASE – Basically Avail- directly, and changes are propagated (2) to other re- able, Soft state, Eventually consistent. The term was quired nodes subsequently. The number of resource coined around the year 2000, deliberately constructed managers required depends on the sharding model to describe a model that is diametrically opposed to and the system configuration chosen, ranging from a ACID (Brewer, 2000). single node (single replica) to a quorum of nodes to, Today, BASE is a model commonly favored by theoretically, all replicas of a given data record. cloud systems and NoSQL stores. BASE captures the following properties (Pritchett, 2008): 1a Load Application • A system is basically available when supporting Balancer partial failures without total system failure. RM interface 1b • The state of the system is ‘soft’ in that it can RM1 RM2 change over time even if no further updates are interface interface made. sync sync 2