sign in sign up
<<
Home , Acid, NoSQL, 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 {st, je, mk}@ise.tu-berlin.de

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 , 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 . straints. 2. A blockchain is a shared append-only distributed • Concurrent transactions are executed by maintain- 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

3.1 Understanding ACID RM1 RM2 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 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 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 Resource Resource • The system will eventually become consistent, if Manager Manager no new updates are made to the system. Generally, BASE systems follow a peer-to-peer Resource Resource architecture, where each peer is equally responsible for a of the overall data, a so-called shard. An incoming client request is forwarded to a responsible Figure 2: Architecture of a System following the BASE node based on a sharding function, e.g., a distributed model. hashtable. No notion of a transaction manager exists with BASE systems; all nodes can instead process in- coming requests, which dramatically increases scala- Notice that BASE refers to properties of the TP bility and throughput. Shards themselves are usually system more so than of an individual transaction, and replicated for increased fault tolerance. Hence, not that BASE hardly describes any guarantee: being ba- only the data itself, but also the control over it is dis- sically available, soft-state and eventually consistent tributed. are very weak guarantees, if any. In comparison to BASE systems typically use optimistic replication ACID, BASE does not address atomicity and does not techniques and thereby trade some consistency for support isolation. BASE compromises consistency availability. Instead of requiring availability of all to eventual consistency. Durability (persistence) of components that are participating in a logical transac- changes to the system is the only property common to tion (and thereby coupling all components when pro- both models. cessing the transaction), a BASE design encourages In the context of BASE systems, the term trans- interaction only with select nodes and components, action (and transaction processing, correspondingly) thereby tolerating partial failures (of other nodes and is misleading. A “BASE transaction” – if at all – components) and accepting that the overall consis- probably is best understood as the unit of work com- tency will be in a state of flux. Read and write oper- prising an initial client request to one system node ations by different clients can be performed by differ- and all subsequent steps to propagate the effects of ent nodes in the system, thereby ensuring high avail- that request to all other required nodes. However, we ability. Updates written to a node typically are prop- prefer referring to “ACID transactions” (rather than agated asynchronously to other required nodes after “ACID systems”) and to “BASE systems” (rather than returning to the client – the system therefore is in soft “BASE transactions”) instead, reflecting the focus of state and, if no new updates are made to a given data each of the acronyms. 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 A transaction cannot be manipu- less). These transactions neither fit the ACID nor the lated or censored. This has two dimensions: Pending BASE model, which is why we introduce SALT as and agreed-on transactions. a new acronym to describe the unique properties of Unlike with ACID and BASE, there is no cen- blockchain-based transactions and systems. tral access management. The access control model Whereas ACID compromises availability in favor is completely decentralized and tied to asymmetric of consistency, and BASE compromises consistency cryptography. Pending transactions contain a signa- in favor of availability, blockchains compromise scal- ture that only the original sender can create. There are ability in favor of trustless interactions (Tai, 2017). no privileged users which could alter or block pend- As explained before, ACID focuses on properties ing transactions. Furthermore, the ledger data struc- of transactions while BASE focuses on properties of ture is designed in a way that any alteration to an the system. Hence, we provide two SALT perspec- agreed-on transaction would invalidate the data struc- tives: a transactions perspective, and a systems per- tures. Hence, other nodes in the network could never spective. be convinced of such an invalid history.

4.1 SALT – The transactions 4.2 SALT – The systems perspective perspective Blockchain-basesd systems supporting transactions can be characterized as Symmetric, Admin-free, Blockchain-based transactions can be character- Ledgered, and Time-consensual. ized as Sequential, Agreed, Ledgered, and Tamper- resistant. Symmetric Notice that blockchains use two main types of data All nodes in the peer-to-peer network symmetrically records: transactions and blocks. A block groups a set share their responsibilities. This does not only refer of transactions. The SALT transaction properties also to transaction processing, but also to state storage and apply to blocks, however, for now, we will concen- propagation of information. trate on transactions and discuss blocks in section 4.2 when defining the SALT systems properties. Admin-free As a fully peer-to-peer system, there is no concept of Sequential a system administrator who is responsible for main- All transactions are processed sequentially. Unlike tenance, infrastructure provisioning or access control. with ACID transactions, there is no parallel process- Updates of peers happen on an individual basis and ing of transactions in the SALT model. However, just by that are subject to community consensus. like the isolation property in ACID, all transactions are processed in a sequential order. Ledgered All peers in the system maintain an append-only data Agreed structure of transactions which we refer to as the A transaction is accepted when the majority of the ledger. Before transactions can be appended to that 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, all nodes in the network need to agree on an many nodes. order to maintain the ledgers consistency. Some of the nodes – called the miners – group Since finding consensus is expensive, blockchains their pending transactions into candidate blocks, the introduce blocks, a data structure that groups a set of unit of consensus. This happens in parallel on many transactions. Blocks are then used as the unit of con- nodes and a consensus algorithm, (e.g., Proof-of- sensus, thus reducing the number of consensus rounds Work, Proof-of-Stake) is used to decide which node’s relative to the number of transactions. When consen- candidate block becomes a valid block accepted by sus is found, the agreed-on block is appended to the the network without communication between peers. ledger and with it the contained transactions. This is referred to as mining (5). This agreed-on block is then appended to the miner’s blockchain (6) and Time-consensual To ensure timely processing of broadcast (7) so it spreads to all nodes in the network transactions while tolerating network latencies due to in a gossip-like way. The receiving nodes check the geo-distribution of the networks’ peers, the consensus validity of the block (8) by validating all contained algorithm targets a defined average time between the transactions as well as the contained proof, that the creation of two blocks. This is called the block inter- block was actually selected in the consensus process. val. Hence, while not guaranteed, a transaction is on A valid block is then appended to the node’s local average processed and included into the ledger within blockchain. As this happens on all nodes in the net- half the block interval. work, the contained transactions are now reflected in 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 transactions. An application can begin a transaction A SALT transaction conceptually is simpler than an with any of the peers in the system (1). Each peer ACID transaction; there is no concept of grouping maintains a local copy of the entire blockchain. The multiple operations into an atomic unit-of-work from transaction is validated locally at the chosen node and a client perspective. Hence, no SALT property di- – if valid – added to its list of ”pending transactions” rectly relates to the atomicity property of ACID. Note, (2). Furthermore, the node propagates the validated however, that grouping multiple operations is possible transaction to other nodes in the network (3). The inside a SALT system by creating stored procedures. receiving nodes perform the same steps themselves We expand on this idea in section 4.5. Neither of both (4), which together to a gossip-like spread of approaches is commonly supported in BASE systems. valid transactions and them being in pending state on The isolation property of ACID is closely related to the sequential processing of transactions in the 4.5 T for Turing Complete? SALT model. In both models, transactions have a well-defined order that is consistent within the net- Traditional TP systems know the concepts of stored work. In BASE systems, in contrast, a defined global procedures. These procedures group a sequence of order of transactions is not enforced by the system database operations and can be exposed to clients. and does not have to exist, which is why BASE sys- This reduces the permissions clients require and can tems are soft-state. also improve usability. Both, the agreed-on property of SALT and the With blockchains, the same concept becomes consistency property of ACID, refer to the validity much more powerful. The procedure is executed of transactions and are thus closely related. While on every node in the network and the resulting state essentially the same guarantee, the parties enforcing changes are applied. Hence, a on the guraranee differ: In the ACID case, specific com- a blockchain is essentially a piece of software that is ponents of the TP system check the post transaction executed in a fully decentralized way without anyone database state for integrity and reject transactions in being able to control it. case of violations. In the SALT case, all nodes in the Applying the concept of stored procedures to network independently validate transactions based on blockchains has two challenges, though. Because the an agreed-on ruleset and acknowledge them depend- state changes caused by the stored procedures on ev- ing on the result. ery node have to be consistent, the code needs to be Note, that this notion of consistency in ACID and deterministic. Furthermore, for the network to make SALT is different from the system-centric consistency progress and for block times to average the targeted notion in BASE. With BASE systems, consistency block interval, there can be no infinite loops or long refers to (reaching) equivalence of state across repli- running transactions. cas. This notion of consistency is a pre-requisite for Determinism can be achieved by not allowing any distributed systems in support of ACID transactions, non-deterministic operations in stored procedures. also. Yet, ACID makes no direct statement about External API calls, for example, cannot be allowed, replica consistency. In systems supporting BASE, as they might yield different results when performed replicas can be in conflicting state because they each on different nodes in the network. process a different set of transactions. The same can The second problem, preventing infinite loops, happen in systems supporting SALT, when two nodes theoretically reduces to the halting problem: Does mine different blocks and hence temporarily maintain a given program terminate or will it run forever? It different state. Whereas systems supporting BASE is well known, that this problem is undecidable for are guaranteed to converge in the absence of new turing-complete languages, so another way of pre- transactions, in SALT systems the conflict is resolved venting infinite loops has to be found. by deciding for exactly one block to be agreed-on by One approach is to write stored procedures in a all peers. less powerful language so they are guaranteed to ter- Another interesting exists between the minate after a well-defined number of steps. While ledgered property of SALT and the durability prop- this constrains overall expressiveness, it enhances se- erty of ACID, as already briefly discussed in 4.1. Not curity by reducing potential vulnerabilities. A promi- considering factors external to the system, a trans- nent example of a blockchain following this approach action written to a TP system supporting ACID or is Bitcoin, which provides a rather limited scripting BASE is guaranteed to be persistent and cannot be language mainly used for signature verification. lost. This guarantee is weakened to a probabilis- Another approach is to introduce a cost model tic version in the SALT model. It can happen, that to a turing-complete language: Every is a transaction is no longer represented in the system assigned a price and an initial endowment is speci- state although it has been processed successfully at fied for a stored procedure when it is called. With an earlier point in time. With the number of subse- that, every stored procedure is guaranteed to halt, be- quent transactions, the probability of this happening cause even if it contains an infinite loop, the endow- quickly diminishes (Nakamoto, 2008). While having ment will be used up at some point which causes ex- to rely on probabilistic state appears unreliable, it is ecution to stop. Although it involves additional risk barely a problem in current networks (e.g., Bitcoin or from a security perspective, this approach is certainly Ethereum). As a best practice, users wait for a cer- more expressive and enables more powerful appli- tain number of blocks (based on their risk threshold) cations. However, the cost calculation and tracking succeeding the block containing their transaction until during execution involve considerable overhead. The they consider the transaction to be final. Ethereum blockchain adopts this approach and refers to its stored procedures as Smart Contracts (Buterin, 2014), (Wood, 2014). Create Register List in digital artwork artwork catalog

5 Designing SALTy Applications Creator Media

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

document store (using Couchbase) is suitable for Register Hand-over catch catch storing Terabytes of semi-structured data. Fisher 3. Two blockchain data stores for storing Gigabytes Receive Receive of data: catch certificate Supplier (a) One blockchain, Ethereum, is used for stor- Ship ing the ownership history of digital artworks as Tag products products crypto hashes. Factory Provenance (b) Another blockchain, the Bitcoin system, is used Display Consumer provenance for facilitating payments with the Bitcoin vir- POS scans tag data tual currency.

The two different NoSQL data stores (S3 and Blockchain ERP System Provenance (Ethereum) (Tally-O) (RDBMS) Couchbase) that Monegraph uses are both BASE sys- Mgt. Data tems which enable scalable and highly-available data storage of unstructured items in a blob store, and Figure 5: Provenance use case from a combined transac- semi-structured JSON items in a document store, re- tions and data management systems perspective. spectively. It would be prohibitively expensive to use the Ethereum blockchain as a data store for these 5.2.1 The Transactions Perspective items. Using the Ethereum blockchain as part of the data management system, however, enables, in partic- Provenance uses blockchain technology to integrate ular, the following SALT system properties that sim- different stakeholders across the supply chain, en- plify revenue sharing and payment distribution. abling them to support the following business trans- actions, as shown in figure 5. Ledgered Transparently storing all agreed-on transactions in a 1. Local fishermen in Indonesia register their catch public ledger simplifies revenue sharing between mul- (by sending an SMS message to a Provenance ap- tiple parties, such as publishers, media creators, and plication), which triggers the creation of a public affiliates, without layers of intermediaries that use digital certificate that represents the physical good their own complex accounting and rights management in the blockchain. 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, Time-consensual the products are tagged (e.g., using QR codes, bar- The time-consensual property implies that transac- codes, NFC tags, etc.), and can thereby be traced tions are appended to the ledger after a defined av- along the supply chain by linking the tag to the erage time period. Although this could be problem- digital certificate. 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 provenance of items across different supply chains using the blockchain as a shared data layer for certifi- (Provenance, 2017). Thereby, Provenance makes it cates. 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 2. With blockchain technology advancing at a rapid point of sale. A blockchain-based peer-to-peer net- pace, will ACID, BASE and SALT continue to co- working approach with symmetrically shared respon- exist as alternatives, or can frameworks and solu- tions stacks be designed that impose an integrated REFERENCES data management using all three models? Bernstein, P. A. and Newcomer, E. (2009). Principles of Further, a number of related research challenges Transaction Processing. Morgan Kaufmann Publish- emerge: ers Inc., San Francisco, CA, USA, 2nd edition. 1. In this paper, we suggested a business transac- Brewer, E. A. (2000). Towards robust distributed systems. tions and a systems perspective when engineering In PODC, volume 7. blockchain-based applications. Other perspec- Buterin, V. (2014). Ethereum: A next-generation smart tives – for example, a consensus-perspective, or a contract and decentralized application platform. https://github.com/ethereum/wiki/ blockchain technology (platforms and tools) per- wiki/\%5BEnglish\%5D-White-Paper. spective – may also be beneficial. Crosby, M., Nachiappan, Pattanayak, P., Verma, S., and 2. Private and permissioned blockchains, as opposed Kalyanaraman, . (2015). Blockchain technology: Be- to the public blockchains discussed in this pa- yond bitcoin. Technical report, Sutardja Center for per, maintain some of the SALT properties, while Entrepreneurship & Technology, Berkeley, CA. compromising others. Whenever closed networks Gray, J. and Reuter, A. (1992). Transaction Processing: with different consensus algorithms and asym- Concepts and Techniques. Morgan Kaufmann Pub- lishers Inc., San Francisco, CA, USA, 1st edition. metric peers are suggested – is less SALT actually Monegraph (2017). https://monegraph.com/. Accessed: healthy? 2017-02-07. 3. Scalability (of blockchains and blockchain-based Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic applications) is a major limitation of current cash system. blockchain technology. Heterogeneous data man- Pritchett, D. (2008). BASE: An alternative. ACM agement, as exemplified with the two use cases Queue, 6(3):48–55. above, may help to improve scalability (and ad- Provenance (2017). https://www.provenance.org/. dress related concerns of data volume, distribu- Accessed: 2017-02-07. tion, and processing needs). How, and at what Tai, S. (2017). Continuous, trustless, and fair: Chang- costs, can scalability be improved? ing priorities in services computing. In Advances in Service-Oriented and (ASOCC). The list above is by no means complete and fi- Springer. nal; our discussion in this paper is largely driven from Wood, G. (2014). Ethereum: A secure decentralised gen- a data management and distributed systems interest, eralised transaction ledger. Ethereum Project Yellow while several other communities (including security, Paper. 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.