sign in sign up
<<
Home , Acid, Relational model, Stored procedure, Transaction processing

Not ACID, not , but A Perspective on

Stefan Tai, Jacob Eberhardt and Markus Klems Systems Engineering, Technische Universitat¨ Berlin, Germany

Keywords: SALT, , Decentralized, ACID, BASE, Transaction Processing.

Abstract: Traditional ACID transactions, typically supported by relational 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, 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

755

Tai S., Eberhardt J. and Klems M. Not ACID, not BASE, but SALT - A Transaction Processing Perspective on Blockchains. DOI: 10.5220/0006408207550764 In Proceedings of the 7th International Conference on and Services Science (CLOSER 2017), pages 755-764 ISBN: 978-989-758-243-1 Copyright ="tag">c 2017 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

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- Each transaction transforms the database from less execution and recording of transactions se- • 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 . straints. Concurrent transactions are executed by maintain- 2. A blockchain is a shared append-only distributed • database with full 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 , 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 , 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

RM1 RM2 3.1 Understanding ACID interface interface XA XA interface interface 1 3 In the 1980s, management sys- Resource Resource tems (RDBMS) based on Codd’s Manager Manager were first introduced. With the addition of TP tech- Tx interface nologies to RDBMS a few years later, originally pro- Resource Resource posed by Jim Gray, the acronym “ACID transaction” 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

756 Not ACID, not BASE, but SALT - A Transaction ProcessingNot ACID, Perspective not BASE, on Blockchains but SALT

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- tributes incoming requests to peers of nodes with With the emergence of unprecedented scalability symmetrical responsibilities and capabilities. Re- needs of modern Web applications, an alternative to quests are served by one or more resource managers the rather expensive and consistency-focused ACID directly, and changes are propagated (2) to other re- model was introduced: BASE – Basically Avail- quired nodes subsequently. The number of resource able, Soft state, Eventually consistent. The term was managers required depends on the sharding model coined around the year 2000, deliberately constructed and the system configuration chosen, ranging from a to describe a model that is diametrically opposed to single node (single replica) to a quorum of nodes to, ACID (Brewer, 2000). theoretically, all replicas of a given data record. Today, BASE is a model commonly favored by cloud systems and NoSQL stores. BASE captures the 1a Load following properties (Pritchett, 2008): Application Balancer A system is basically available when supporting RM interface 1b • partial failures without total system failure. RM1 RM2 The state of the system is ‘soft’ in that it can interface interface • sync sync change over time even if no further updates are 2 Resource Resource made. Manager Manager The system will eventually become consistent, if • no new updates are made to the system. Resource Resource Generally, BASE systems follow a peer-to-peer architecture, where each peer is equally responsible for a of the overall data, a so-called shard. An Figure 2: Architecture of a System following the BASE incoming client request is forwarded to a responsible model. node based on a sharding function, e.g., a distributed hashtable. No notion of a transaction manager exists Notice that BASE refers to properties of the TP with BASE systems; all nodes can instead process in- system more so than of an individual transaction, and coming requests, which dramatically increases scala- that BASE hardly describes any guarantee: being ba- bility and throughput. Shards themselves are usually sically available, soft-state and eventually consistent replicated for increased fault tolerance. Hence, not are very weak guarantees, if any. In comparison to only the data itself, but also the control over it is dis- ACID, BASE does not address atomicity and does not tributed. support isolation. BASE compromises consistency BASE systems typically use optimistic replication to eventual consistency. Durability (persistence) of techniques and thereby trade some consistency for changes to the system is the only property common to availability. Instead of requiring availability of all both models. components that are participating in a logical transac- In the context of BASE systems, the term trans- tion (and thereby coupling all components when pro- action (and transaction processing, correspondingly) cessing the transaction), a BASE design encourages is misleading. A “BASE transaction” – if at all – interaction only with select nodes and components, probably is best understood as the unit of work com- thereby tolerating partial failures (of other nodes and prising an initial client request to one system node components) and accepting that the overall consis- and all subsequent steps to propagate the effects of tency will be in a state of flux. Read and write oper- that request to all other required nodes. However, we ations by different clients can be performed by differ- prefer referring to “ACID transactions” (rather than ent nodes in the system, thereby ensuring high avail- “ACID systems”) and to “BASE systems” (rather than ability. Updates written to a node typically are prop- “BASE transactions”) instead, reflecting the focus of agated asynchronously to other required nodes after each of the acronyms. returning to the client – the system therefore is in soft state and, if no new updates are made to a given data

757 CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

4 SALT: THE BLOCKCHAIN network agrees on its validity. Essentially, commu- ALTERNATIVE TO ACID AND nity consensus determines the system state – unlike in ACID and BASE, where it is solely controlled by a BASE central authority. While ACID transactions provide convenient consis- Ledgered tency guarantees and BASE systems scale to meet the All agreed-on transactions are added to an append- demands of the largest of applications, they both re- only transaction ledger and cannot be revoked. State quire the users’ trust. A blackbox to the clients, the changes cannot be undone; compensating transac- correct execution of transactions can rarely be con- tions can be processed, however. trolled. For example, when you send money to a bank Note, though, that the ledgered property is a bit account, you cannot be sure that this account was ac- weaker than the durability property in ACID. Due to tually credited. You rather trust your bank to play by the majority-based agreement process, a part of the the rules and to keep balances correct. ledger may be overwritten by another, later version. Turning to blockchains now, an alternative to The likeliness of this happening for a given transac- ACID and BASE is introduced. Blockchains address tion quickly diminishes with the number of transac- this trust concern and propose a system design that tions succeeding said transaction. enables transactions which do not involve trust in a central party (therefore, the interactions become trust- Tamper-Resistant less). These transactions neither fit the ACID nor the A transaction cannot be manipulated or censored. BASE model, which is why we introduce SALT as This has two dimensions: Pending and agreed-on a new acronym to describe the unique properties of transactions. blockchain-based transactions and systems. Unlike with ACID and BASE, there is no cen- Whereas ACID compromises availability in favor tral access management. The access control model of consistency, and BASE compromises consistency is completely decentralized and tied to asymmetric in favor of availability, blockchains compromise scal- cryptography. Pending transactions contain a signa- ability in favor of trustless interactions (Tai, 2017). ture that only the original sender can create. There are As explained before, ACID focuses on properties no privileged users which could alter or block pend- of transactions while BASE focuses on properties of ing transactions. Furthermore, the ledger data struc- the system. Hence, we provide two SALT perspec- ture is designed in a way that any alteration to an tives: a transactions perspective, and a systems per- agreed-on transaction would invalidate the data struc- spective. tures. Hence, other nodes in the network could never be convinced of such an invalid history. 4.1 SALT – The Transactions 4.2 SALT – The Systems Perspective Perspective Blockchain-basesd systems supporting transactions Blockchain-based transactions can be character- can be characterized as Symmetric, Admin-free, ized as Sequential, Agreed, Ledgered, and Tamper- Ledgered, and Time-consensual. resistant. Notice that blockchains use two main types of data Symmetric records: transactions and blocks. A block groups a set All nodes in the peer-to-peer network symmetrically of transactions. The SALT transaction properties also share their responsibilities. This does not only refer apply to blocks, however, for now, we will concen- to transaction processing, but also to state storage and trate on transactions and discuss blocks in section 4.2 propagation of information. when defining the SALT systems properties. Admin-free Sequential As a fully peer-to-peer system, there is no concept of All transactions are processed sequentially. Unlike a system administrator who is responsible for main- with ACID transactions, there is no parallel process- tenance, infrastructure provisioning or access control. ing of transactions in the SALT model. However, just Updates of peers happen on an individual basis and like the isolation property in ACID, all transactions by that are subject to community consensus. are processed in a sequential order. Ledgered Agreed All peers in the system maintain an append-only data A transaction is accepted when the majority of the structure of transactions which we refer to as the

758 Not ACID, not BASE, but SALT - A Transaction ProcessingNot ACID, Perspective not BASE, on Blockchains but SALT

Legend Application 7 internal external 3 interface interface 1 Tx Block Tx Block Tx Block interface interface interface interface interface interface 8 8 2 4 4 Transaction Block Transaction Block Transaction Block Manager validation Manager validation Manager validation Tx Tx Tx validation validation 5 validation Block Block Block mining mining mining Resource Resource Resource Manager 9 Manager 6 Manager 9 Append Append Append block block block

Resource Resource Resource

Miner

Figure 3: Transaction-oriented Architecture of the SALT system perspective. ledger. Before transactions can be appended to that many nodes. ledger, all nodes in the network need to agree on an Some of the nodes – called the miners – group order to maintain the ledgers consistency. their pending transactions into candidate blocks, the Since finding consensus is expensive, blockchains unit of consensus. This happens in parallel on many introduce blocks, a data structure that groups a set of nodes and a consensus algorithm, (e.g., Proof-of- transactions. Blocks are then used as the unit of con- Work, Proof-of-Stake) is used to decide which node’s sensus, thus reducing the number of consensus rounds candidate block becomes a valid block accepted by relative to the number of transactions. When consen- the network without communication between peers. sus is found, the agreed-on block is appended to the This is referred to as mining (5). This agreed-on block ledger and with it the contained transactions. is then appended to the miner’s blockchain (6) and broadcast (7) so it spreads to all nodes in the network Time-consensual To ensure timely processing of in a gossip-like way. The receiving nodes check the transactions while tolerating network latencies due to validity of the block (8) by validating all contained geo-distribution of the networks’ peers, the consensus transactions as well as the contained proof, that the algorithm targets a defined average time between the block was actually selected in the consensus process. creation of two blocks. This is called the block inter- A valid block is then appended to the node’s local val. Hence, while not guaranteed, a transaction is on blockchain. As this happens on all nodes in the net- average processed and included into the ledger within work, the contained transactions are now reflected in half the block interval. the overall system state.

4.3 Understanding SALT 4.4 Comparing SALT, ACID and BASE

Figure 3 illustrates a TP system in support of SALT A SALT transaction conceptually is simpler than an transactions. An application can begin a transaction ACID transaction; there is no concept of grouping with any of the peers in the system (1). Each peer multiple operations into an atomic unit-of-work from maintains a local copy of the entire blockchain. The a client perspective. Hence, no SALT property di- transaction is validated locally at the chosen node and rectly relates to the atomicity property of ACID. Note, – if valid – added to its list of ”pending transactions” however, that grouping multiple operations is possible (2). Furthermore, the node propagates the validated inside a SALT system by creating stored procedures. transaction to other nodes in the network (3). The We expand on this idea in section 4.5. Neither of both receiving nodes perform the same steps themselves approaches is commonly supported in BASE systems. (4), which together to a gossip-like spread of The isolation property of ACID is closely related valid transactions and them being in pending state on to the sequential processing of transactions in the

759 CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

SALT model. In both models, transactions have a 4.5 T for Turing Complete? well-defined order that is consistent within the net- work. In BASE systems, in contrast, a defined global Traditional TP systems know the concepts of stored order of transactions is not enforced by the system procedures. These procedures group a sequence of and does not have to exist, which is why BASE sys- database operations and can be exposed to clients. tems are soft-state. This reduces the permissions clients require and can Both, the agreed-on property of SALT and the also improve usability. consistency property of ACID, refer to the validity With blockchains, the same concept becomes of transactions and are thus closely related. While much more powerful. The procedure is executed essentially the same guarantee, the parties enforcing on every node in the network and the resulting state the guraranee differ: In the ACID case, specific com- changes are applied. Hence, a on ponents of the TP system check the post transaction a blockchain is essentially a piece of software that is database state for integrity and reject transactions in executed in a fully decentralized way without anyone case of violations. In the SALT case, all nodes in the being able to control it. network independently validate transactions based on Applying the concept of stored procedures to an agreed-on ruleset and acknowledge them depend- blockchains has two challenges, though. Because the ing on the result. state changes caused by the stored procedures on ev- Note, that this notion of consistency in ACID and ery node have to be consistent, the code needs to be SALT is different from the system-centric consistency deterministic. Furthermore, for the network to make notion in BASE. With BASE systems, consistency progress and for block times to average the targeted refers to (reaching) equivalence of state across repli- block interval, there can be no infinite loops or long cas. This notion of consistency is a pre-requisite for running transactions. distributed systems in support of ACID transactions, Determinism can be achieved by not allowing any also. Yet, ACID makes no direct statement about non-deterministic operations in stored procedures. replica consistency. In systems supporting BASE, External API calls, for example, cannot be allowed, replicas can be in conflicting state because they each as they might yield different results when performed process a different set of transactions. The same can on different nodes in the network. happen in systems supporting SALT, when two nodes mine different blocks and hence temporarily maintain The second problem, preventing infinite loops, different state. Whereas systems supporting BASE theoretically reduces to the halting problem: Does are guaranteed to converge in the absence of new a given program terminate or will it run forever? It transactions, in SALT systems the conflict is resolved is well known, that this problem is undecidable for by deciding for exactly one block to be agreed-on by turing-complete languages, so another way of pre- all peers. venting infinite loops has to be found. Another interesting exists between the One approach is to write stored procedures in a ledgered property of SALT and the durability prop- less powerful language so they are guaranteed to ter- erty of ACID, as already briefly discussed in 4.1. Not minate after a well-defined number of steps. While considering factors external to the system, a trans- this constrains overall expressiveness, it enhances se- action written to a TP system supporting ACID or curity by reducing potential vulnerabilities. A promi- BASE is guaranteed to be persistent and cannot be nent example of a blockchain following this approach lost. This guarantee is weakened to a probabilis- is Bitcoin, which provides a rather limited scripting tic version in the SALT model. It can happen, that language mainly used for signature verification. a transaction is no longer represented in the system Another approach is to introduce a cost model state although it has been processed successfully at to a turing-complete language: Every is an earlier point in time. With the number of subse- assigned a price and an initial endowment is speci- quent transactions, the probability of this happening fied for a stored procedure when it is called. With quickly diminishes (Nakamoto, 2008). While having that, every stored procedure is guaranteed to halt, be- to rely on probabilistic state appears unreliable, it is cause even if it contains an infinite loop, the endow- barely a problem in current networks (e.g., Bitcoin or ment will be used up at some point which causes ex- Ethereum). As a best practice, users wait for a cer- ecution to stop. Although it involves additional risk tain number of blocks (based on their risk threshold) from a security perspective, this approach is certainly succeeding the block containing their transaction until more expressive and enables more powerful appli- they consider the transaction to be final. cations. However, the cost calculation and tracking during execution involve considerable overhead. The Ethereum blockchain adopts this approach and refers

760 Not ACID, not BASE, but SALT - A Transaction ProcessingNot ACID, Perspective not BASE, on Blockchains but SALT

to its stored procedures as Smart Contracts (Buterin, 2014), (Wood, 2014). Create Register List in digital artwork artwork catalog Media Creator 5 DESIGNING SALTy APPLICATIONS File Store Doc Store Blockchain Blockchain (AWS S3) (Couchbase) (Ethereum) (Bitcoin)

With an understanding of SALT transactions and Art Portfolio Sales Contracts Owner History Payments Data Mgt.

Monegraph Binary Assets & Catalogs Crypto Hashes Virtual Currency SALT systems, we now turn to the question of how JSON Docs to design the next generation of decentralized trans- actional applications that use blockchains. Innovative companies are already building such applications to- Agree Make a Transfer of day, which allows us to discuss SALT in the context to terms payment ownership of specific industry use cases. Besides financial ap- Media Owner plications in the banking and insurance industry, there are numerous examples of non-financial, blockchain- Figure 4: Monegraph use case from a combined transac- based applications, such as notary services, digital tions and data management systems perspective. content monetization, decentralized storage, decen- tralized IoT, and so on (Crosby et al., 2015). Using blockchain technology, Monegraph gains We propose to approach the design and analysis the following SALT transaction properties. of blockchain-based applications along the two SALT perspectives: the transactions perspective, and the Sequential systems (data management components) perspective. Transactions are guaranteed to be processed in a se- We selected two non-financial use cases to illustrate quential order so that the transfer of media rights from the basic approach. creators to owners is performed without “double sell- ing”, i.e., selling the same rights to different media 5.1 Monegraph Use Case owners. Agreed The first use case, Monegraph, is a content distri- Since an agreement among the majority of the bution and monetization platform that enables media blockchain network is required, it becomes more dif- creators to transfer rights of digital artwork to media ficult to illegitimately claim media rights ownership. owners (Monegraph, 2017). With the platform, me- Once an agreement on a transaction has been reached dia creators, such as photographers, videographers, in the network, there is a certain level of trust that me- and musicians, can monetize their work, and media dia rights that have been exchanged really belong to owners can manage their media’s use rights, distribute the agreed-on media owner. content, and share revenue with media creators, pub- lishing partners, and affiliates. Ledgered Appending all agreed-on transactions to a public 5.1.1 The Transactions Perspective ledger asserts that media ownership records cannot be revoked by a single party or a small part of the net- The main business transactions from the point of view work. Thereby, media owners gain trust that their dig- of the two main stakeholders, the media creators and ital rights ownership cannot be single-handedly an- the media owners, are the following, as depicted in nulled by a seller. figure 4. Media creators can, for example, create and up- Tamper-resistant • load digital artwork (as a file), register the artwork All transactions are tamper-resistant, making it diffi- as a public record, and list their artwork in a pri- cult to forge transactions, e.g., by replacing the media vate catalog. owner in a transaction through a man-in-the-middle attack. Media owners use the platform to agree to terms • (in the form of a Smart Contract), make payments 5.1.2 The Systems Perspective using Bitcoin or traditional payment transactions, and transfer ownership of the public record. Monegraph uses three different types of data stores for enabling the business transactions described be-

761 CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

fore: provenance of items across different supply chains 1. A blob store for digital artworks, which stores the (Provenance, 2017). Thereby, Provenance makes it art portfolio as binary files (jpeg, mp4, mp3, etc.). possible for consumers to transparently retrace the The blob store (using AWS S3) is suitable for stor- origin of products that they purchase. A pilot project ing multiple Petabytes of unstructured data in a shows how blockchain technology can be used for flat namespace. tracing yellowfin and skipjack tuna fish in Indonesia from catch to consumer. 2. A NoSQL for storing sales contracts and catalog data in JSON format. The NoSQL Register Hand-over document store (using Couchbase) is suitable for catch catch Fisher storing Terabytes of semi-structured data.

3. Two blockchain data stores for storing Gigabytes Receive Receive catch certificate

of data: Supplier (a) One blockchain, Ethereum, is used for stor- Ship Tag products ing the ownership history of digital artworks as products Factory

crypto hashes. Provenance Display Consumer (b) Another blockchain, the Bitcoin system, is used provenance POS scans tag for facilitating payments with the Bitcoin vir- data tual currency.

Blockchain ERP System Provenance The two different NoSQL data stores (S3 and (Ethereum) (Tally-O) (RDBMS) Couchbase) that Monegraph uses are both BASE sys- Data Mgt. tems which enable scalable and highly-available data Figure 5: Provenance use case from a combined transac- storage of unstructured items in a blob store, and tions and data management systems perspective. semi-structured JSON items in a document store, re- spectively. It would be prohibitively expensive to 5.2.1 The Transactions Perspective use the Ethereum blockchain as a data store for these items. Using the Ethereum blockchain as part of the Provenance uses blockchain technology to integrate data management system, however, enables, in partic- different stakeholders across the supply chain, en- ular, the following SALT system properties that sim- abling them to support the following business trans- plify revenue sharing and payment distribution. actions, as shown in figure 5. Ledgered 1. Local fishermen in Indonesia register their catch Transparently storing all agreed-on transactions in a (by sending an SMS message to a Provenance ap- public ledger simplifies revenue sharing between mul- plication), which triggers the creation of a public tiple parties, such as publishers, media creators, and digital certificate that represents the physical good affiliates, without layers of intermediaries that use in the blockchain. their own complex accounting and rights management processes. For example, a third-party that wants to li- 2. Along with the physical transaction of the catch cense media can more easily verify media ownership from fisher to supplier, suppliers receive the digi- of the party that claims to be the media owner by look- tal certificate from the blockchain. ing up the ownership record in the public blockchain. 3. In the factory that processes and packages the fish, the products are tagged (e.g., using QR codes, bar- Time-consensual codes, NFC tags, etc.), and can thereby be traced The time-consensual property implies that transac- along the supply chain by linking the tag to the tions are appended to the ledger after a defined av- digital certificate. erage time period. Although this could be problem- atic for some applications, a certain delay involved in 4. At the Point of Sale, consumers scan the tag transferring media rights could still be acceptable in on a product (e.g., a QR code) with their mo- this use case. phones and retrieve information regarding the product’s provenance. 5.2 Provenance Use Case In the tuna fish tracing pilot project of Provenance, NGOs perform audits to validate compliance along The second use case, Provenance, is a supply chain the supply chain. Therefore, the system is not com- traceability application that provides insight into the pletely trustless. However, audits are simplified by

762 Not ACID, not BASE, but SALT - A Transaction ProcessingNot ACID, Perspective not BASE, on Blockchains but SALT

using the blockchain as a shared data layer for certifi- point of sale. A blockchain-based peer-to-peer net- cates. working approach with symmetrically shared respon- Using blockchain technology for building the cer- sibilities takes the role of an “honest broker” in such tification system enables, in particular, the following a distributed certification system. SALT transaction properties. Admin-free Agreed The blockchain serves as an integration layer between There is no single party that governs the certification different stakeholders with heterogeneous IT systems process. Instead, an agreement between all stakehold- that are ranging from the mobile phones of local pro- ers is automatically formed based on defined conven- ducers to the ERP systems of manufacturers. Tra- tions of the blockchain consensus protocol. The cer- ditionally, a governing third-party, such as an NGO, tification data is thereby not prone to arbitrary actions would have been required to integrate all IT systems of a single party. along the supply chain with their own auditing sys- tem, thereby increasing cost of operations. Cost shar- Ledgered ing is difficult and could weaken the trustworthiness The agreed-on transactions in a blockchain cannot be of the system due to adverse incentives of the govern- revoked, thereby providing a perfectly auditable sys- ing third-party who might be more interested in pleas- tem which is particularly important for NGOs who ing the sponsor rather than performing proper over- are responsible for auditing the uninterrupted chain sight. of custody from raw fish to packaged products at the Moreover, by using a blockchain, the authentica- point of sale. It is practically impossible for a sin- tion system is drastically simplified compared to cen- gle party to modify transactions once they have been trally managed public key infrastructure. This re- appended to the blockchain. moves a critical single-point-of-failure and security risk from the certification system. 5.2.2 The Systems Perspective

Provenance uses the Ethereum blockchain as a secure, 6 SUMMARY AND OUTLOOK auditable, shared data layer, thereby avoiding data si- los in heterogeneous systems with limited interoper- Different notions of transactions and transaction pro- ability. With the blockchain, data can be accessed and cessing systems exist, most notably ACID transac- verified by all involved parties, rather than solely by tions and BASE systems. With the emergence of the original certificatory. blockchain technology, an alternative to ACID and By using a blockchain-based system in the tuna BASE is introduced: SALT. In this paper, we intro- tracing pilot project, Provenance gains two main ad- duced SALT along the two perspectives of transac- vantages. First, the blockchain serves as an integra- tions and TP systems. We discussed the importance tion layer between different stakeholders with het- of these dual perspectives. erogeneous IT systems that range from the mobile When engineering blockchain-based applications, phones of fishermen to complex ERP systems of man- the SALT model can be used to explain the ufacturers. Second, the peer-to-peer setup and cryp- blockchains under consideration, that is, to study both tographic properties of the system make it impossi- the business transactions and their supporting sys- ble for a single governing party to manipulate data at tems. While there are specific transactions that are some point in the supply chain, thereby strengthen- exclusively SALT, we expect the systems to always ing the confidence of consumers into the provenance encompass different data management components so information they retrieve at the point of sale. that SALT, ACID, and BASE can all be supported at The following SALT system properties are of par- the same time. The two use cases discussed are first ticular importance in the Provenance use case. examples of such systems that benefit from using mul- tiple transactional models and systems. Symmetric This immediately raises two main research ques- Fragmentation along the chain of custody makes a tions that require further exploration: certification system vulnerable to fraud. Furthermore, no single organization can be trusted to broker all data 1. Given a combination of different transaction about every product’s supply chain. Relying on a models and systems, including SALT, are there single party creates an inherent bias that eventually system-wide application properties that can be could weaken trust of consumers regarding the certi- guaranteed? fied provenance information that they receive at the

763 CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

2. With blockchain technology advancing at a rapid Crosby, M., Nachiappan, Pattanayak, P., Verma, S., and pace, will ACID, BASE and SALT continue to co- Kalyanaraman, V. (2015). Blockchain technology: exist as alternatives, or can frameworks and solu- Beyond bitcoin. Technical report, Sutardja Center for tions stacks be designed that impose an integrated Entrepreneurship & Technology, Berkeley, CA. data management using all three models? Gray, J. and Reuter, A. (1992). Transaction Processing: Concepts and Techniques. Morgan Kaufmann Pub- Further, a number of related research challenges lishers Inc., San Francisco, CA, USA, 1st edition. emerge: Monegraph (2017). https://monegraph.com/. Accessed: 2017-02-07. 1. In this paper, we suggested a business transac- Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic tions and a systems perspective when engineering cash system. blockchain-based applications. Other perspec- Pritchett, D. (2008). BASE: An alternative. ACM tives – for example, a consensus-perspective, or a Queue, 6(3):48–55. blockchain technology (platforms and tools) per- Provenance (2017). https://www.provenance.org/. Ac- spective – may also be beneficial. cessed: 2017-02-07. 2. Private and permissioned blockchains, as opposed Tai, S. (2017). Continuous, trustless, and fair: Chang- to the public blockchains discussed in this pa- ing priorities in services computing. In Advances in Service-Oriented and Cloud Computing (ASOCC). per, maintain some of the SALT properties, while Springer. compromising others. Whenever closed networks Wood, G. (2014). Ethereum: A secure decentralised gen- with different consensus algorithms and asym- eralised transaction ledger. Ethereum Project Yellow metric peers are suggested – is less SALT actually Paper. healthy? 3. Scalability (of blockchains and blockchain-based applications) is a major limitation of current blockchain technology. Heterogeneous data man- agement, as exemplified with the two use cases above, may help to improve scalability (and ad- dress related concerns of data volume, distribu- tion, and processing needs). How, and at what costs, can scalability be improved? The list above is by no means complete and fi- nal; our discussion in this paper is largely driven from a data management and distributed systems interest, while several other communities (including security, privacy, legal, economics) also formulate a number of open issues related to blockchains and blockchain- based applications. As blockchain technology and blockchain-based applications continue to evolve at a rapid pace and more lessons are learned, we ex- pect both a fine-tuning of specific open issues and a more integrated, inter-disciplinary big picture to be- come important next steps.

REFERENCES

Bernstein, P. A. and Newcomer, E. (2009). Principles of Transaction Processing. Morgan Kaufmann Publish- ers Inc., San Francisco, CA, USA, 2nd edition. Brewer, E. A. (2000). Towards robust distributed systems. In PODC, volume 7. Buterin, V. (2014). Ethereum: A next-generation smart con- tract and decentralized application platform. https:// github.com/ethereum/wiki/wiki/%5BEnglish%5D- White-Paper.

764