Smart Contracts for Machine-To-Machine Communication: Possibilities and Limitations
Total Page:16
File Type:pdf, Size:1020Kb
Smart Contracts for Machine-to-Machine Communication: Possibilities and Limitations Yuichi Hanada Luke Hsiao Philip Levis Stanford University Stanford University Stanford University [email protected] [email protected] [email protected] Abstract—Blockchain technologies, such as smart contracts, present a unique interface for machine-to-machine communication that provides a secure, append-only record that can be shared without trust and without a central administrator. We study the possibilities and limitations of using smart contracts for machine-to-machine communication by designing, implementing, and evaluating AGasP, an application for automated gasoline purchases. We find that using smart contracts allows us to directly address the challenges of transparency, longevity, and Figure 1. A traditional IoT application that stores a user’s credit card trust in IoT applications. However, real-world applications using information and is installed in a smart vehicle and smart gasoline pump. smart contracts must address their important trade-offs, such Before refueling, the vehicle and pump communicate directly using short-range as performance, privacy, and the challenge of ensuring they are wireless communication, such as Bluetooth, to identify the vehicle and pump written correctly. involved in the transaction. Then, the credit card stored by the cloud service Index Terms—Internet of Things, IoT, Machine-to-Machine is charged after the user refuels. Note that each piece of the application is Communication, Blockchain, Smart Contracts, Ethereum controlled by a single entity. I. INTRODUCTION centralized entity manages application state and communication protocols—they cannot function without the cloud services of The Internet of Things (IoT) refers broadly to interconnected their vendors [11], [12]. In Figure 1, without the cloud service, devices that communicate, share data, measure the physical the vehicle is unable to pay the gas station. world, and interact with people. IoT applications have been The third challenge is trust. In Figure 1, the user must trust deployed in a wide variety of domains such as healthcare, the vendor with their credit card information, and the credit manufacturing, agriculture, and transportation. They also have card company acts as a trusted third party to help manage funds the potential to transform daily life through smart homes, cities, and resolve disputes in exchange for non-negligible fees. IoT and infrastructure [1–3]. Cisco and Ericsson estimate that there transactions that involve the exchange of digital or physical will be 100 billion IoT devices by 2020 [4]. assets require trust, which inherently involves risks. Examples Many IoT applications rely on machine-to-machine com- of such risks are the vendor leaking credit card information munication—the communication between devices with limited or the credit card company undermining the fairness of an or without human intervention [5]—to automate tasks, send exchange by colluding when resolving disputes [13]. Each of commands, and/or distribute information. Figure 1 shows an ex- these risks can compromise an IoT application. ample of this broad class of machine-to-machine applications, a To summarize these challenges: smart vehicle automatically paying for its refueling. Machine- to-machine applications encounter three technical challenges 1) IoT applications acting on behalf of users benefit from that human-centric applications solve with a person in the loop. transparency. Without it, users cannot verify the actions The first challenge is transparency. IoT devices are infa- their applications are taking on their behalf. mously insecure [6], [7], but encryption makes it extremely 2) Long-lived IoT devices may outlive the infrastructure arXiv:1806.00555v2 [cs.CY] 8 Jan 2019 difficult to verify that they are acting appropriately. In Figure 1, that supports them, causing them to fail or exposing where actions are automatically performed by a smart vehicle vulnerabilities. They lack longevity. on a user’s behalf, it would be impossible for the user to audit 3) IoT applications that exchange goods or services require the encrypted information sent from their vehicle to the cloud trust. This often adds financial overhead and risks that service to ensure that private data was not also sent—a concern can subvert an application. that is well justified [8], [9]. One approach to addressing these challenges is to use The second challenge is longevity. IoT devices are often ex- blockchain technologies. A blockchain provides a publicly- pected to function for decades. Some of these objects may still auditable, append-only ledger that ensures full transparency of be in use long after their vendors stop maintaining them [10]. transactions performed on the chain. It also allows state to be But, because these devices are often vertical silos—where a stored in a distributed manner among the nodes in a network c 2018 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. DOI: 10.1109/IOTAIS.2018.8600854 that persists as long as a network of nodes exists. Furthermore, a cryptographic hash and references the hash of the block blockchain-based ledgers that support smart contracts allow preceding it—forming the links, or chain, between each block. applications to embed the contractual logic of a transaction onto In addition, blocks may contain transactions, which record a the blockchain. This way, the logic is executed independently transfer of data or assets between two addresses. As a result, and automatically by each node on the network using the data any node in a blockchain network with access to the blockchain provided on the blockchain—reducing the need for trust and can traverse it to construct the global state stored on the chain. third party involvement in a transaction [14]. Nodes in a blockchain network operate on the same blockchain However, these beneficial properties come with impactful and form a peer-to-peer network where each node replicates all trade-offs: certain blockchain consensus algorithms, such as the or part of the blockchain. proof-of-work used in Ethereum, significantly limit the perfor- In order to submit transactions to the chain, each node uses mance of executing transactions in terms of both throughput a pair of public and private keys. First, the node constructs and latency; the availability of a public log of transactions raises and signs a transaction and broadcasts it to its one-hop peers. important privacy considerations; and smart contracts require Each node validates any transactions it receives, dropping special care in deployment. Because a smart contract acts as invalid transactions, before broadcasting it to its peers. These the absolute arbiter for transactions performed through it, bugs transactions form a pool of valid, pending transactions that are in a smart contract may incur costly damages that are difficult ready to be included in a block. Miners are nodes in the network or impossible to resolve [15]. that construct new blocks to be added to the blockchain and Researchers have proposed a variety of uses for blockchain broadcasts them to its peers, who verify it before appending it. and smart contracts in IoT applications (Section II-D). Our This process continuously repeats. Each blockchain employs work presents an initial technical and experimental evaluation a consensus mechanism to resolve different states, or “forks” of this approach. We present AGasP, an IoT application for in the network, and the choice of mechanism varies among automated, machine-to-machine gasoline purchases that uses networks. [17] details a variety of consensus mechanisms. smart contracts to perform transactions. In contrast to the B. Smart Contracts traditional centralized IoT architecture shown in Figure 1, AGasP allows users to audit all interactions and can continue to Smart contracts “combine protocols, user interfaces, and function as long as the blockchain network exists. Furthermore, promises expressed via those interfaces, to formalize and secure by using smart contracts to cut out third parties, AGasP can save relationships over public networks [14].” In other words, smart gas stations over 79% in fees for a typical transaction. contracts allow users to execute a script on a blockchain network in a verifiable way and allows many problems to be Contributions This paper makes these contributions: solved in a way that minimizes the need for trust. To do so, they 1) The design, implementation, and evaluation of AGasP, allow users to place trust directly in the deterministic protocols an application that uses smart contracts for automated and promises specified in a smart contract, rather than in a third gasoline purchases between a vehicle and gas station. party. For example, in Figure 1, users must trust the vendor with 2) A discussion of the practical trade-offs of using smart their credit card number, and the gas station must trust the credit contracts for machine-to-machine communication. We card company to pay on behalf of the user in exchange for fuel. find that transaction latencies are sensitive to transaction With smart contracts, a user can pay the gas station directly by fees and that the 95-percentile latency can be on the order using the protocol and promises established in the contract such of hours (Section VI). that neither party can manipulate the exchange. The remainder of the paper is structured as follows. Section II A smart contract has its own address and account on the describes the building blocks for using smart contracts. Sec- blockchain. Consequently, it can maintain its own state and take tion III makes the case for smart contracts. Section IV describes ownership of assets on the blockchain, which allows it to act AGasP’s design and implementation while Section V evaluates as an escrow.