The blockchain protocols have recently attracted enormous interest from researchers and industry, appearing to be a promising, but still not mature, technology. This protocol family stems from the Bitcoin specification , proposing a cryptographic-based solution to the problem of keeping consistent copies of a distributed database in a permission-less network. The idea has been extended by Ethereum protocol , where the database that is used to keep track of the states of accounts was augmented by a scripting functionality that permits any computer in the network to reconstruct the accounts’ state by simply reading the database. However, the database is hard to tamper with, as its modification requires the investment of computational resources.
The blockchain protocols offer interesting applications for the IoT ecosystem , mainly seen in the possibility of stipulating smart contracts . A smart contract is an account, whose state can be read and modified by any device according to predefined functions. If the state contains credits, a smart contract can regulate economic transactions, e.g., micro-payments, among devices. For instance, a smart contract can be used to mimic the presence of a central authority in a decentralized smart energy application, where the contract is stored and updated by devices themselves . However, in the IoT context, the modest storage and processing capabilities of the devices may require the presence of an external infrastructure to store the smart contracts.
Fig. 1 illustrates the steps of a credit transaction regulated by smart contract. Two IoT devices are connected to the peer-to-peer blockchain network, whose nodes store the smart contract, maintain the blockchain and update it with new information blocks. A device can request the blockchain network to update the smart contract state, e.g., to attribute some credit to another device (step 3 in Fig. 1). The other devices are informed of this update when they receive a new block containing the updated state (step 4 in Fig. 1). Finally, the recipient device can verify the new state and release a service to the sender (step 5 in Fig. 1). The mechanism enables the exchange of credit in absence of mutual trust, since the economic transaction is certified by a third party, i.e., the blockchain network, and hardly reversible . The objective is to assure that each device locally observes the same state of the smart contract, such that the key element in the system design is how each device stays synchronized with the most recent version of the blockchain.
In this paper, we characterize the traffic between the blockchain network and the IoT devices. The critical problems in this context are: (i) the low computational and (ii) storage resources that prevent IoT devices to act as blockchain validators, and (iii) limited communication resources. In fact, smart meters, and IoT devices in general, access the network via low-bandwidth wireless links. In addition, their connectivity is sporadic, e.g., due to energy saving policies, or limited access to channel resources. In this work, we establish two possible protocols for interacting with the blockchain network. Each protocol has different communication requirements and provides a different security level. We then propose a traffic model that can be used to extract measures of interest, such as the time needed for the blockchain synchronization, or the minimal bandwidth requirements to stay synchronized. We analyze the probability of keeping the IoT devices synchronized with the blockchain and investigate trade-offs among duty cycle (i.e., sleeping duration), goodput offered by the wireless link, and blockchain parameters (i.e., the block generation frequency and its size). The key contribution is the explicit modeling of the impact that wireless connectivity has on the blockchain synchronization and smart contract execution.
The rest of the paper is organized as follows. Section II introduces the main concepts of a blockchain protocol. Section III presents the system model. Section IV elaborates the synchronization protocols under consideration, whose analysis is perfomed in Section V. Section VI presents the numerical results. Section VII concludes this paper.
Ii Blockchain protocol
In this section, we focus on the blockchain concepts that are relevant for this work; the reader is referred to  for a detailed overview. A blockchain is a concatenated list of blocks, stored in multiple copies by the nodes of the blockchain network. Part of the nodes act as validators, i.e., they append new blocks to their local copy and also send them to the rest of the nodes. The distribution of new blocks happens in a peer-to-peer fashion. When a block is received, it is validated before it can be appended to the local list. In order to be perform validation, a node has to invest resources that are referred to as Proof of Works (PoWs); PoWs are typically computational resources needed to solve cryptographic-based problems. In case that different subsets of nodes have different local blockchains with the same number of blocks (e.g., caused by a communication network partition) the contention is solved in a consensus-based manner. At any time, the validators trust the longest known blockchain in the network.
Ii-1 Data structures
A blockchain block is composed of a header and a body. The body contains the list of transactions that are verified by the block, and has a maximum size. Each transaction is represented by a data structure, composed by a set of fields, defined in the protocol specifications ,. The header typically contains a pointer to the previous block, a solution to the PoW, the block creation time, and one or more roots of Merkle trees  that are used as Proof of Inclusion (PoI) of the transactions in the block, see Sec. II-3.
Ii-2 Proof of Work (PoW)
The PoW algorithm prevents uncontrolled generation of blocks by the validators, and guarantees that their local blockchain copies are consistent. The algorithm is run locally by all validators, with the aim to find a solution to a cryptographic puzzle . The difficulty of the puzzle is tuned to keep the expected block generation time constant, typically of the order of tens of seconds .
Ii-3 Proof of Inclusion (PoI)
The Merkle tree roots contained in the header can be used to prove the inclusion of transactions in the block without the need to download the entire block body. Specifically, cryptographic hash-values of the transactions that are included in a block are stored in a binary Merkle tree . Therefore, any node in possession of the block header can verify a transaction from another node by requesting the transaction’s data structure, together with the Merkle-tree nodes that are required to reconstruct the tree root. If the root matches the one included in the block header, then the transaction is included in the block. In Ethereum, a similar mechanism is used to prove the state of accounts, e.g., smart contracts .
Iii System model
Iii-1 Blockchain network
The blockchain network relies on peer-to-peer connections between nodes, including validators that produce information blocks and store the entire blockchain list. We assume that validators are interconnected by an ideal communication network. Furthermore, validators are assumed to be honest, and, at any time, they store the same copy of the blockchain. The chain length at time , i.e., number of generated blocks, is characterized by the homogeneous Poisson process with inter-arrival frequency .
Iii-2 The IoT device
We consider a generic IoT device , with limited storage and energy. For these reasons, it is not feasible for itself to validate the blockchain, but instead it relies on information received from the blockchain network. The analysis performed in the paper focuses on the case where is interested in verifying that a transaction has been included in the blockchain (step 4 in Fig. 1), rather than on the transaction creation. This is motivated by the fact that the creation of transactions is decoupled from their verification, where communication demands of sending a transaction to the blockchain (step 3 in Fig. 1) are negligible compared to the reception of blocks.
In order to verify transactions, stores a local copy of the (global) blockchain. We denote the length of the local blockchain by , which is never longer than the global, since is not generating blocks. The process describes the difference in the number of blocks between the global and local copy (i.e., how many blocks is delayed with respect to the global blockchain) at time . The delay in the local copy is caused by blocks created while is sleeping to save energy.
Device is connected to the blockchain network by a wireless transceiver that connects with blockchain-network (BN) nodes. The connectivity of is modelled by the two-state process with states and . In state , is connected and the synchronization protocol is triggered by the creation of new blocks. In state , is sleeping and does not receive block updates or execute the protocol. Furthermore, a transition from state to triggers a protocol execution whose duration is random; the details are given in Sec. IV. Additionally, an inadequate communication link capacity may cause the execution of a synchronization protocol to last longer than the block creation period, requiring multiple executions in order to achieve synchronization.
We are interested in characterizing after the execution of the synchronization protocol. To this end, we define the discrete-time process, , which samples at the end of the protocol executions. A realization of the introduced processes is illustrated in Fig. 2 with . Observe that is sleeping in interval , causing a delay of the local blockchain copy at . The blockchain consistency is achieved after the next protocol execution.
Iii-3 Connectivity model
The connectivity process of a device can be extremely variable and depends on the type of device. For instance, a smart meter may wake up periodically for short time intervals every 15–30 minutes . At the same time, a smartphone may be turned off during the night hours, while being connected the rest of the day. In this work, we consider a model where goes to sleep after protocol execution with probability , and then sleeps for a deterministic duration .
Iii-4 Communication link
We model ’s connectivity to the blockchain network as a stop-and-wait retransmission protocol with instant and error-free feedback and independent packet error probabilities in the downlink and
in the uplink. For simplicity, we assume that the error probabilities are independent of packet length and that the sender has unlimited retransmission attempts (i.e., its packets are eventually delivered). Under this scheme, the number of transmission attempts follows a geometric distribution. As a result, the expected goodputs in the downlink and uplink areand , where and are the downlink and uplink bit-rates, respectively. Finally, we also assume that there is an initial connection establishment and authentication phase of deterministic duration, .
The connection to the blockchain network follows a point-to-multipoint topology when ; when , connects to a single node that acts as a proxy, see Fig. 3. In the latter case, the proxy needs to be fully trusted, since it can modify the information forwarded to the IoT device . This configuration is not investigated in this paper, as it prevents the implementation of a fully decentralized architecture.
Iv Blockchain synchronization protocols
The task of a blockchain synchronization protocol is to keep constantly updated with the current state of the blockchain. Motivated by the fact that the protocol steps are not explicitly described by the most popular blockchain specifications (e.g. [1, 2]), but left to the implementation, we define two conceptual synchronization protocols: P1 and P2. They model the minimal amount of information that needs to be exchanged, while neglecting additional features included in specific blockchain implementations.
P1 is the simplest protocol variant, in which receives complete blocks from BN nodes to which is connected, and locally verifies the validity of the PoW solution and the contained transactions. This configuration, adopted in , provides the maximum possible level of security: needs not trust the individual BN nodes and is designated as a full node. However, this is hardly a feasible solution for IoT due to the high storage and computational requirements, since needs to store the complete blockchain and to check all transactions.
Protocol P2 provides a simplified architecture where , acting as a light node, only receives the block headers from BN nodes by default. Furthermore, defines a list of events that it is interested in observing, i.e. modifications to the blockchain, and this list is known by BN nodes.111In efficient implementations, the list is constructed via a Bloom filter that is matched when the events happen . Examples of events of interest are the modification of the state of a smart contract, or transactions from/to a particular address. Upon the observation of the events, BN nodes send to the part of information that has changed, together with the corresponding Merkle tree that serves as a PoI, see Sec. II-3. We assume that an event of interest is independently observed in each block period with probability , which can be tuned by by changing the set of events of interests.
To simplify the scenario, we assume that can only interact with one BN node at a time (no concurrent transfers), and that there is a single event of interest. In case that the event is observed while is sleeping, the current state of the blockchain becomes reconstructed based on the header of the most recent block. If is synchronized and a new block becomes generated, the protocol execution starts immediately. If is not synchronized after the protocol execution ends, due to the generation of a new block during the execution, a new protocol execution is started immediately afterwards. When an execution starts, it does not stop until it is completed, and stays awake during the execution. In the following, we describe possible implementations for P1 and P2.
Iv-a Protocol P1
The information exchange required by P1 depends on whether was sleeping or being idle prior to the protocol execution. Specifically, when wakes up, i.e., makes a transition , the following sequence is executed:
request new blocks from each of the BN nodes via a message of length bits, which contains information about the highest locally known block .
receives a response of length bits, from each BN node, which contains the information of their current blockchain length .
If (i.e., ), selects one random BN node and sends a message of length bits, requesting the missing blocks.
The selected BN node sends the blocks. Since there are blocks, and each block is of length bits, the total length of the message is bits.
Steps ()–() are repeated until synchronization.
In the second case, is connected and receives notifications of new blocks. The steps are:
receives a notification of the new block from each of the BN nodes, where the length of the notification message is bits. Starting from the first notification, it waits seconds, to receive all the notifications.
selects one BN node and requests the missing block.
The selected BN node sends the block.
The message exchanges are depicted in Fig. 4.
Iv-B Protocol P2
The operation of P2 are similar to P1, but the message sizes in downlink are remarkably smaller. When wakes up:
requests of new block to each of the BN nodes, via a message of length bits.
receives a response of length bits from each of the BN nodes, that contains the list of new blocks available.
selects one BN node and requests the missing block headers.
The selected BN node sends the headers. Since each header is bits long, the message length is bits.
Steps ()–() are repeated until synchronization.
If is connected and synchronized:
receives a notification of new block of length bits, from each of the BN nodes. Upon the reception of the first notification, waits for seconds.
selects one BN node and requests the missing header.
The selected BN node sends the header.
If an event of interest is observed, the BN node also sends the data structure containing the information of interest, which is of length bith, together with the PoI that is of length bits.
Observe that the adopted sampling makes an irreducible and positive recurrent Markov process. The goal of the analysis is to find its transition probabilities (see Fig. 5), which depend on the adopted protocol and which are derived in the sequel.
The probability of transitioning from state to , where the state corresponds to the number of missing blocks in the local copy of the blockchain, depends on whether is sleeping between and :
The first term, corresponding to the case that stays awake between two protocol executions, is the probability that blocks arrive during the protocol execution time :
where we use the fact that blocks are generated with Poisson arrivals with parameter . For the case where sleeps between and , the protocol execution time depends on and the number of blocks accumulated during sleep, denoted by . By marginalizing over we obtain
Note that blockchain protocols might specify a limit on the number of blocks that can be transferred with one protocol execution, which can be easily incorporated in the proposed model. Also, here we assume the reconnection time (i.e., the time for discovery of BN nodes and connection negotiation) to the blockchain network to be negligible and note that the model can be easily extended by including reconnection time into . We continue by deriving and for the proposed protocols.
V-a Protocol P1
We denote the expected time in order to successfully deliver a generic protocol message by . In case that is awake and synchronized, i.e. , the protocol execution time is
If is awake and not synchronized, the duration of the execution is a function of the number of missing blocks :
V-B Protocol P2
The analysis is similar to the one for P1, where we substitute with in all the equations, as in this case downloads only block headers. Hence, the time required to download the header in the synchronized state is:
Another difference to P1 is seen in step that refers to the case when is awake and synchronized and an event of interest happens. This triggers the transmission of the information modified on the blockchain along with the PoI, which takes seconds. The overall time to synchronize and receive the information modified on the blockchain, i.e., to execute steps -, is:
When is not synchronized, the time required to download the headers in P2 is
We also define , similarly to in Sec. V-A, which takes into account the reconnection time. If at least one event of interest happened in one of the blocks, the protocol also transfers the corresponding information, and lasts seconds.
V-C Average idle time
The presented analysis can be used to find several parameters of interest. As an example, here we show how to obtain the average time spent in idle state, when is not sleeping and not communicating (because of being synchronized), see Fig. 6. We indicate the sojourn time in state as , then we have and for
. The set of random variablesdefines a Markov renewal process, used to compute the average time spent in idle state, , where is the stationary probability of .
Vi Numerical results
|40 kbit||1536 bit|
|800 bit||1000 bit|
|A||1 Mbps||1 Mbps||100 ms|
|B||100 kbps||150 kbps||1 s|
In this section, we provide numerical results based on typical values of blockchain networks. The blockchain parameters, i.e., block period and messages length, are extracted from Ethereum protocol statistics and listed in Table I. We assume that is connected to BN nodes. We evaluate the use of two wireless technologies, named A and B and characterized by different capabilities, see Table II; the practical instances of technologies A and B are LTE Cat M1, and Bluetooth Low Energy, respectively, both oriented towards supporting IoT traffic.
First, we verify the validity of the analytical model, by comparing it with numerical simulation of the described processes, implemented in MATLAB. Fig. 7 compares transition probabilities obtained from (1) and from the numerical simulation for technology B and protocol P1, showing that the proposed model, although being simple, succeeds in capturing all the necessary details. We note that investigations performed for protocol P2 and/or technology A produce similar results, which are omitted due to the space constraints.
In Fig. 8, we show the duration of , i.e., time to execute P1 when is synchronized, for different values of , : we can observe the difference due to the different characteristics of the considered wireless interfaces. The investigations performed for , , , , show analogous results (here omitted) to the ones presented in Fig. 8.
Fig. 9 investigates the behavior of probability of staying synchronized, i.e., , for P1 and P2 and as function of system parameters. Two cases are considered: error-free communication and a channel that is ideal in uplink but error-prone in downlink; the latter case models the fact that the messages in the downlink for P1 and P2 are much longer than in the uplink. The probability of sleeping is fixed to , and we vary the duration of sleeping time . In Fig. 9(a), we obtain the probability of staying synchronized after the execution of P1 or P2. The figure shows that, to execute P1, the wireless interface needs to provide an adequate goodput to the blockchain application. In Figs. 9(b) and (c) we vary block size and generation frequency for P1, showing that the probability of staying synchronized is drastically reduced by the sleeping duration, and only slightly by the link unreliability (P2 is not studied here, as it is not affected by variations of the block size).
We now investigate the data consumption of the two protocols. In uplink, protocols are only sending control messages, resulting in a marginal data consumption. In downlink, the requirements of P1 increase linearly with the accumulated delay, because the full blocks are downloaded, while for P2 they vary with the probability that events of interest are observed, . In Fig. 10 we show that the downlink data usage is significantly reduced with P2 when compared to P1.
Finally, we show how different sleeping parameters impact the average time spent in the idle, sleeping, and protocol-executing states, see Fig. 11
. We perform a random walk on the Markov Chain corresponding to technology B and sleeping probability, while the sleeping duration is varied. Note that the fraction of time spent in idle state in P2 is only slightly increased in comparison to P1, although the amount of exchanged data in P2 is significantly smaller than in P1, see In Fig. 10. This is due to the fixed time interval that is present in both protocols, during which a device waits for the response about the current blockchain state from all BN nodes to which it is connected (refer to steps and in Sec. IV).
The advent of blockchain-based applications for IoT urges the research on their requirements to the communications system. In this work, we investigated several protocols for synchronization between IoT devices and the blockchain network and proposed a model to study the impact of the communication link quality and blockchain parameters on the synchronization process. It was showed that the duty cycle of the device should be designed by taking into account both blockchain and communication parameters, as well as that the choice of the wireless technology that guarantees the required reliability of the synchronization process depends on the blockchain parameters. Also, it was showed that if the protocol execution duration is comparable with the average block-generation period, the probability of staying synchronized rapidly decreases. In order to reduce the duration of an execution, the use of protocols where the blockchain validation is delegated to external entities is beneficial, although it reduces the devices’ security. Finally, we showed that the blockchain protocols, differently from typical IoT applications that mostly generate uplink traffic, require the allocation of a remarkable amount of downlink resources.
The work was supported in part by the European Research Council (ERC Consolidator Grant no. 648382 WILLOW) within the Horizon 2020 Program.
-  S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” [Online]. Available: https://bitcoin.org/bitcoin.pdf, 2008, accessed: 2018-01-22.
-  G. Wood, “Ethereum: A secure decentralised generalised transaction ledger,” [Online]. Available: http://gavwood.com/paper.pdf, 2014, accessed: 2017-01-22.
-  A. Dorri et al., “Towards an optimized blockchain for iot,” in Proc. of the Second International Conference on Internet-of-Things Design and Implementation. ACM, 2017, pp. 173–178.
-  K. Christidis and M. Devetsikiotis, “Blockchains and smart contracts for the internet of things,” IEEE Access, vol. 4, pp. 2292–2303, 2016.
-  P. Danzi et al., “Distributed proportional-fairness control in microgrids via blockchain smart contracts,” 2017 IEEE International Conference on Smart Grid Communications (SmartGridComm), 2017.
-  A. Narayanan et al., Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction. Princeton University Press, 2016.
-  R. C. Merkle, “A digital signature based on a conventional encryption function,” in Conference on the Theory and Application of Cryptographic Techniques. Springer, 1987, pp. 369–378.
-  G. Eibl and D. Engel, “Influence of data granularity on smart meter privacy,” IEEE Trans. on Smart Grid, vol. 6, no. 2, pp. 930–939, 2015.
-  E. Heilman et al., “Eclipse attacks on bitcoin’s peer-to-peer network.” in USENIX Security, 2015, pp. 129–144.