In recent years, there has been a growing interest in understanding the potential applications of blockchains to the Internet of Things (IoT) landscape . However, the literature on the integration of the blockchain protocols with the wireless networks is still scarce . In this respect, discovering the trade-offs and potential bottlenecks of blockchain protocols plays a pivotal role in the context of IoT systems, in which devices typically have constrained energy resources and are connected by low-cost wireless networks, e.g. Wi-Fi, Bluetooth, or LoRaWAN .
In this work, we investigate the communication cost incurred by a wireless base station (BS) for sending blockchain information to IoT devices. In legacy blockchain synchronization schemes, a device, connected to the blockchain network via the BS, receives an update whenever a new block is generated by the blockchain network. Clearly, such schemes do not scale well when the number of devices connected to the same BS grows, and a communication bottleneck may arise. A related problem is that legacy schemes use reliable transport layer (e.g. TCP), which involves a significant signalling overhead and which may not be suitable for low-energy IoT devices.
Our proposal is based on the key observation that if devices are connected to the same blockchain network, they are in fact interested in receiving the same information, i.e. the same blocks (or just the block headers, in case of lightweight clients ). The only difference among the devices is the set of servers that each device trusts. Hence, the block should be authenticated by several servers in such a way that each node trusts at least one of the authentication servers. The servers of the blockchain network provide authentication of blocks by sending to devices a digital signature that signs the block. Therefore, in our proposal the end-to-end channel from blockchain nodes to IoT devices is authentic but not confidential. Still, a confidential channel can be set up when a device needs to exchange additional information, i.e. transactions.
By leveraging on the broadcast nature of the wireless medium, we design a scheme in which the BS multicasts blocks to all devices, together with a set of server signatures. Reliable transmission is provided using forward error correction (FEC), which in this work is implemented by a simple repetition of the blocks. The signatures are not repeated, since we rely on the signature amortization property that is embedded in blockchain protocols, which allows a device to authenticate all previously chained blocks by receiving a single signature. Depending on the progress of the reception of blocks and signatures, several cases my arise, as illustrated in the examples in Fig. 1, in which there is a sender and three receivers. Specifically, in Fig. 1(a), the server sends a block and its signature to the three receivers. The first one receives two blocks without signatures; i.e., the authentication delay is two blocks. For the second receiver, the third block and its signature are received, making the second block authenticated as well, thanks to the chaining. For the third one, the first block and its signature are received, followed by the second block and the signature of the third block. In this case, the number of non-authenticated blocks is two, as the signature of the third block can not be chained. Hence, the use of amortized signatures mitigates the effect of packet loss.
The proposed scheme is challenged by the presence of forks, which are a distinguishing characteristic of blockchains. Forks are events characterized by parallel existence of more than one valid version of the blockchain; a fork gets resolved when a network eventually elects a unique valid version. In the proposed scheme, the BS transmits all the possible versions of the blockchain (i.e. the related block streams) during a fork event.
The analysis of the scheme shows that the BS can trade-off the timely authentication of block streams, and their reliable transmission, by selecting the length of the code, i.e. repetitions of the blocks. The analysis also shows the negative impact of forks on the performance of the scheme.
The remainder of the paper is organized as follows. Section II provides a brief introduction to blockchain and to related works. Section III presents the system model. Section IV elaborates the proposed scheme, while Section V is devoted to its analysis. Section VI presents the evaluation and Section VII concludes the paper.
In a blockchain network, a (possibly large) set of nodes store a copy of a same ledger. The ledger records the modifications to the state of a system, e.g. a financial accounting . The modifications are batched into information blocks, which also include a header that contains metadata. The initial state is described in a block called genesis, see Fig. 2. Upon each modification of the state, a new block is propagated through the network, becomes locally validated by the nodes, and, if valid, is appended to each nodes’ local copy of the ledger. Each block contains in their header the hash value of the previous block header, which enforces an order and ensures uniqueness of the ledger, see Fig. 2. To avoid uncontrolled generation of blocks, nodes can only propagate blocks that fulfil certain consensus rules, e.g. proof-of-work . This provides consistency of the ledgers, without a centralized trusted authority .
The propagation delays in the network might cause forks, i.e. presence of conflicting, valid chains of blocks . The forks are resolved by voting on which of the co-existing chains should be considered valid . After the resolution of a fork, the block that remains without children, see Fig. 2, is termed orphan in Bitcoin  and uncle in Ethereum . In this paper we follow the nomenclature of Bitcoin. In principle, a fork can last many blocks, or even be persistent if part of the nodes starts following different consensus rules . However, in regular blockchain networks, nodes that generate blocks are well connected to each others, to avoid generating orphan blocks, and forks are usually resolved after one block.
As the validation of blocks is an expensive process in terms of memory and computing resources, lightweight clients typically request only the block header, instead of the entire block, delegating the verification to trusted nodes. In addition, they may request part of the ledger that they are interested in observing [9, 4]. Since this entails full trust in the nodes, in order to detect misbehaving ones, a lightweight client can request the information from a set of nodes, and verify that the received block headers are consistent.111Alternatively, they can implement incentive-based protocols, e.g. see , which are not treated in this paper. The model described in the following text focuses on lightweight clients, which represent typical IoT devices.
Ii-B Related work
The problem of reliable and authenticated multicasting of data streams is a well-investigated subject . Here, a message is authenticated when it is digitally signed by a trusted party and the signature is received. However, message and signature are not necessarily sent together. Hence, when a message is received, but not authenticated, it is considered useless.
In systems where authentication delay is tolerated, amortized signatures, based on cryptographic hash functions , can be used to reduce the communication cost . The idea is to include in each message the hash value of the previous message, thus chaining them in a sequence. In this way, the reception of a valid signature for a message makes the previous messages authenticated as well. This feature, illustrated in Fig. 1, is already embedded in the blockchain by design, thanks to the block chaining.
When a delay is not acceptable, the signatures of different parties can be combined to a shorter one, generated by aggregate signature schemes . When the aggregate signature is valid, it means that all servers authenticated it. However, the signature verification algorithm has a high computational cost and requires the storage of the public keys of all signers . For this reason, this solution is not suitable for the IoT system that we consider.
Finally, in the context of wireless multicasting of data streams, FEC techniques are used to limit the feedback from receivers, in case of packet loss .
Iii System model
We assume a set of servers and a set of clients, and a BS, as depicted in Fig. 3. The servers are observing the updates to the state of a blockchain, by receiving new blocks from the blockchain network. The block generation process is assumed to be stationary and each new block defines a new period. Every time the servers receive a valid block, they extract the block header, sign it, and send it to the BS reliably and with a negligible delay. The block header is signed using public-key cryptography. To simplify the nomenclature and with a slight abuse of terminology, hereafter we shall refer to the block header as block; we also note that the presented analysis is independent from the amount of information in the blocks.
Assuming that all servers are reliable, in block period , the BS receives blocks and signatures (a pair from each server). The BS verifies all of them, discarding invalid blocks. The number of distinct blocks received by the BS within a block period defines the number of forks happening in the blockchain network, which ranges between (no forks) and (each server sends a different block). For simplicity, we assume that there is at most one concurrent fork, which is the scenario shown in Fig. 2. This assumption is reasonable if the blockchain network is sufficiently well connected. This is the case of existing systems, in which generating a orphan block causes economic loss to the node.
The clients are connected to the BS via wireless links, see the right part of Fig. 3. The length of the packet containing a block and a signature packet is and
bits, respectively. We assume that modulation and rate of the BS transmission are fixed and the bit error probability isfor the downlink channels of all clients. Thus, the probability of not receiving a block or signature is given by and , respectively.
A client trusts a subset of the servers, for which it knows the public keys. Each client informs the BS of the ID of one of the trusted server during the initialization phase. When a valid signature is received from the trusted subset of servers, the corresponding block is considered valid, as well as all previously chained blocks. The client stores the valid blocks and signatures, as shown in Fig. 4. When a fork happens, stores two chains, until the fork is resolved and one of them is marked invalid. The invalid chain and the associated signatures are deleted.
We denote by the number of blocks in the blockchain. Further, we denote by the difference between and the last block that received and that is chained with the genesis block, and by the difference between and the last block chained with the genesis block for which received a valid signature. Note that . In the example of Fig. 4, there are no forks, and , , , . The maximum tolerated authentication delay, same for all devices, is block periods.
The uplink (UL) channel is assumed reliable within the duration of the block period (that typically lasts several seconds). The UL serves as signal to the BS that the blocks have been received, and to request specific information of interest included in the blockchain state (e.g. “transactions” or their “receipts” ). However, the latter feature is not analyzed in this work.
Iv Repeat-Authenticate Scheme
In the proposed scheme, the BS transmits multicast packets containing either a block or a signature, using fixed rate and power. Clients tolerate a delay, hence the BS does not transmit all signatures in all block periods. Instead, in a generic block period the BS sends the most recent blocks222This forms a repetition code, which represents the simplest instance of packet-level FEC. Future works may introduce more complex coding schemes. and signatures that authenticate the last block among these , see Fig. 5(a). In each block period, the signatures to be sent are chosen uniformly at random out of the available server signatures; this ensures that on average the same number of signatures are transmitted for each server. Each client can possibly receive more trusted signatures per block period by trusting more servers, but the BS is not informed about this.
We assume that , i.e., the number of packets containing blocks in each period, is fixed. Moreover, the channel resources allocated for the multicast transmissions are fixed to bits in each block period. The available resources permit to send
signatures in a period, where and are the lengths of a block and a signature, respectively. It is necessary that is large enough to allow such that the data stream is authenticated, and , to accommodate the potential fork, as discussed later on.
The feedback from a client to the BS consists of a single bit and is transmitted only when , where the maximum tolerated authentication delay is a design parameter. The purpose of the feedback is to trigger a unicast transmission of the last blocks from the BS to , together with a signature to authenticate all of them, so that can re-synchronize. In case of such event, the BS has to allocate extra resources in addition to the bits, used for multicasting. According to this mechanism, the BS receives between 0 and feedback packets in a block period, depending on the synchronization state of the devices. In the example in Fig. 4, client sends the UL packet because and . Note that also provides a upper bound to the value of , as .
In case of a fork, there are two competing blocks to be transmitted to clients. To ensure fairness, the same amount of resources is allocated to both blocks, see Fig. 5(b) in which the competing versions are denoted “1a” and “1b”. To accommodate the additional packet, we reduce the number of repetitions to in the period at which the fork happens. This affects the -th last block, which is only repeated times in total. From the point of view of a client, there are three cases: (i) the servers trusted by all sign the fork that will eventually be invalidated, (ii) they all sign the valid fork and (iii) some of the trusted servers sign the valid fork and some the invalid fork. Hence, depending on the set of trusted servers, in case (ii) a client may not even be able to authenticate the event of fork.
In this section, we analyze how to select the parameter depending on the QoS () to be offered. The QoS is defined as the long-term average number of clients delayed beyond the deadline (that is, the number of re-synchronizations triggered):
Ideally is zero, because there are no delayed clients.
At each period , a client checks if the block generated periods before (i.e. at ) has been received and authenticated, see Fig. 7. Recall that block generated at can be authenticated in two ways: a packet containing its signature is received at ; or a packet containing a signature is received at , and all blocks between and have been received. This permits to authenticate the blocks at by leveraging the ledger chain structure. It follows that it is unnecessary to observe the synchronization process at each period, but only when the client may possibly fail. For instance, if the most recent block (generated at ) is chained and authenticated, the client will surely not fail within the next periods.
Based on this key consideration, we introduce the variable that is used to track the authentication state the client. When the client may request a unicast re-synchronization, the state is . From here, if the block is not authenticated, the client transitions to state , corresponding to the unicast re-synchronization, at which the last authenticated blocks are sent. After the client has been re-synchronized, it cannot request a unicast re-synchronization for the next periods, and hence it spends periods in state before going back to state . On the other hand, if in state the block has been authenticated by a signature received at , where , the client does not fail. In our process, it corresponds to a transition from to . The sojourn time in is , because the successive blocks are authenticated as well. From here, the client always returns to . A possible interpretation of is that it tracks the oldest chained signature found between and . For instance, if a client always receives a chained signature in each period, it would stay in state . If it never receives trusted multicast signatures, it only receives unicast re-synchronizations, looping between and . Finally, if the channel is reliable and the client receives a trusted signature every periods, it loops between states and . In the following text we find the expressions for the transition probabilities for .
The probability that block at is signed and received is
where is the probability of receiving the packet (from at least one of the trusted servers) with a signature of the block and the probability of not receiving a packet containing the block in any of the transmission attempts. To find , we indicate the number of servers trusted by client as , . Hence, the probability that it receives at least one signature from a trusted server, in a period, depends on both the packet loss and the probability that the signature of a specific server is sent:
Here, are the number of combinations for which signatures, out of the available from trusted servers, are selected to be multicasted; are the number of combinations of the signatures from untrusted servers (there are ), of which are transmitted. Finally, there are combinations of signatures that can be transmitted among the available at the BS.
Even if the block at is not signed, it may be authenticated by a block completed between and , if they are chained. The probability that block at is received and not signed, but authenticated by the -th successive block is found as follows. Since the first (chained) signature is received after , we must take into account that blocks are received but not signed; we also take into account that the most recent blocks (those for which ) are transmitted less than times. The observations lead to the expression:
The derivation is given in Appendix A. Note the similarity with a geometric distribution, that is “weighted” by the probability of chainingblocks. The probability of failure is found as:
and directly follows from the definition of the process.
This concludes the characterization of the transition probabilities of the process of Fig. 6
. We can simplify the Markov chain of Fig.6 by grouping all states into a state . The new chain has three states with transition probabilities:
and stationary probabilities equal to:
The average number of periods spent in states , and are , and , respectively. We find the average time spent in state as:
Then, the average number of clients that can potentially fail in a period is , since they follow independent processes. Among them, the average number of clients that actually fail in a period is:
Impact of forks
In this work, we only consider forks that last one block, that, as motivated in Sec. II, are the type usually observed in existing networks. Moreover, since the forks are infrequent events, we assume that there is at most one fork in consecutive blocks.333If devices tolerate a very large delay , the assumption does not hold and the analysis is more complex. There are two effects occurring during the period in which the fork happens: (i) the signatures of the orphan block, even if received, are not useful for authentication and (ii) there are repetitions of blocks, instead of , to accommodate the two competing blocks, as shown in Fig. 5(b).
Regarding effect (i), the probability of receiving a signature by a trusted server on the valid fork, depends on the fraction of such servers that are on the valid fork. In fact, if a client only trusts servers that sign an orphan block, those signature are not useful for authentication. Here we assume that the servers are split in two sub-groups by the fork and the fraction of servers on the valid fork is . Thus, (4) becomes:
In effect, is the probability that a trusted signature on the fork that is not orphaned is received.
In respect to the effect (ii), assume to be at period and that a fork happened at period , with .444The authentication from is not considered valid as that block might be orphaned. To find the probability of transitioning from state to , given that the fork is in period , , observe that, if , the transition probability is the same of (5). However, if , the transition probabilities become those of (13). The expression adapts (5) to include the two effects, only for the the block that is forked.
The comparison of (V) and (13) with their correspondent cases without fork, (4) and (5), clearly shows that a fork affects the probability of staying synchronized. However, there is no direct relationship with , which is defined as long-term average, see (2). The analysis can be easily extended to scenarios in which there are more than two forks, or different distributions of number of servers in each fork. On the other hand, the analysis of forks lasting more than one period is nontrivial.
The numerical results are obtained considering block header size of bits (the size of a block header in Bitcoin) and signature size of bits. The BS allocates bits per block period for the multicasting. The maximum tolerated delay is blocks.555In blockchain applications, it is common to wait several periods, ranging from six in Bitcoin  to tens in other blockchain systems , before trusting that the block will not be forked out.
First, we study the performance of the scheme, in terms of the the average number of failures, , see Fig. 8, for which we set and assume that each client trusts a different server. The figure shows a good match between the numerical and analytical values. It can be observed that increases with the bit error probability, , and with the number of servers, as expected. In the cases when is 2 and 5, the number of signatures sent in a period are and , respectively. It is worth to note that, if is low, it is better to reduce the number of repetitions, , in order to accommodate more signatures. However, above a certain threshold value of , the decision is inverted.
The model also captures the impact of different number of trusted servers per client. Fig. 9 reports the average number of failures per block as function of repetitions and number of servers trusted by each client. The bit error probability is fixed to . In Fig. 9(a), each client trusts one server. It results that a low number of repetitions are sufficient to increase the reliability. In effect, increasing reduces the number of signatures per period (see (1)), then the information is received but not authenticated. Fig. 9(b), shows that when a client trusts five (randomly selected) servers, i.e. , the value of is drastically decreased, as it disposes of much frequent authentication. In both graphs, the value of is only defined in the points where , that is the condition for which the signature of each server is sent at least once every periods (on average).
Vii Discussion and Conclusion
We have introduced the concept of separation of common information, i.e. block headers, and information of interest for single IoT devices, for lightweight blockchain protocols. Then, we focused on the efficient transmission of common information and proposed to multicast it, leveraging on the broadcast nature of the wireless channel, as a means to decrease the resources used by the BS, in downlink, and by the IoT devices, for the feedback in UL. We presented a scheme that provides updates that are timely and authenticated by trusted sources, to a large number of IoT devices. The scheme ensures the integrity of the information sent by the BS via digital signatures; however, it is inevitable that the BS can hide valid blocks or signatures by not transmitting them. The extension in this research direction is part of our current work. Moreover, we analytically showed that the presence of forks has a negative impact on the probability of receiving the authenticated updates. A practical solution that can be considered by future protocols is to delay the information at the BS, for one or more block periods, before transmitting it to the devices. This saves the BS the burden of transmitting blocks that are orphaned afterwards.
The numerical simulations showed how the performances of the scheme depend on the number of IoT devices, the number of servers that they trust, and the wireless channel quality (bit error rate). The scheme finds straighforward application in wireless BS, such as Wi-Fi access points. However, we have only evaluated the parameters of Bitcoin blockchain, in which the size of a digital signature is comparable with the one of a block header. As this is not the case for other blockchains, such as Ethereum, the impact of the ratio between size of the block header and digital signature should be evaluated.
In conclusion, our work advocates for further research in improving the connectivity of wireless IoT tailored for blockchain applications.
Appendix A: Derivation of (5)
The transitioning from state to state happens when the first signatures are not received, and the -th is received. In addition, all the blocks should be received, to allow the authentication chaining. We distinguish between two cases.
In the first case, , each block is transmitted exactly times, and we write:
Note that, in (14), we account for unsuccessful transmissions of packets containing signatures; successful transmissions of packets containing blocks (each repeated times); one successful signature transmission, and successful transmission of the -th block.
In the second case, , we take into account that blocks indexed are transmitted less than times, because they are recent. For instance, block with index is transmitted times, block is transmitted times. The last block () is transmitted only once. Based on these observations, we write
where (15) takes into account that the first blocks are transmitted times, (17) that the -th block is the only one whose signature is successfully transmitted (with probability ). Finally, (16) takes into account the intermediate blocks that are transmitted less than times. The equation can be re-arranged as:
The two cases correspond to those of (5).
The work was supported in part by the European Research Council (ERC Consolidator Grant no. 648382 WILLOW) within the Horizon 2020 Program.
-  K. Christidis and M. Devetsikiotis, “Blockchains and smart contracts for the internet of things,” IEEE Access, vol. 4, pp. 2292–2303, 2016.
-  P. Danzi, A. E. Kalør, R. B. Sørensen, A. K. Hagelskjær, L. D. Nguyen, Č. Stefanović, and P. Popovski, “Communication aspects of the integration of wireless iot devices with distributed ledger technology,” arXiv preprint arXiv:1903.01758, 2019.
-  A. Durand et al., “Resilient, crowd-sourced lpwan infrastructure using blockchain,” in Proceedings of the 1st Workshop on Cryptocurrencies and Blockchains for Distributed Systems. ACM, 2018, pp. 25–29.
-  P. Danzi, A. E. Kalør, Č. Stefanović, and P. Popovski, “Delay and communication tradeoffs for blockchain systems with lightweight iot clients,” IEEE Internet of Things Journal, vol. (Early Access), 2019.
-  S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” [Online]. Available: https://bitcoin.org/bitcoin.pdf, 2008, accessed: 2017-08-21.
-  A. Narayanan, J. Bonneau, E. Felten, A. Miller, and S. Goldfeder, Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction. Princeton University Press, 2016.
-  C. Decker and R. Wattenhofer, “Information propagation in the bitcoin network,” in IEEE P2P 2013 Proceedings. IEEE, 2013, pp. 1–10.
-  G. Wood, “Ethereum: A secure decentralised generalised transaction ledger,” [Online]. Available: http://gavwood.com/paper.pdf, 2014, accessed: 2017-08-21.
-  P. Danzi, A. E. Kalor, C. Stefanovic, and P. Popovski, “Analysis of the communication traffic for blockchain synchronization of iot devices,” in 2018 IEEE International Conference on Communications (ICC). IEEE, 2018, pp. 1–7.
-  D. Gruber et al., “Unifying lightweight blockchain client implementations,” NDSS 2018 - Workshop on Decentralized IoT Security and Standards, 2018.
-  A. Nafaa, T. Taleb, and L. Murphy, “Forward error correction strategies for media streaming over wireless networks,” IEEE Communications Magazine, vol. 46, no. 1, 2008.
-  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.
-  J. M. Park, E. K. Chong, and H. J. Siegel, “Efficient multicast stream authentication using erasure codes,” ACM Transactions on Information and System Security (TISSEC), vol. 6, no. 2, pp. 258–285, 2003.
-  D. Boneh, M. Drijvers, and G. Neven, “Compact multi-signatures for smaller blockchains,” in International Conference on the Theory and Application of Cryptology and Information Security. Springer, 2018, pp. 435–464.
-  F. Zsolt, “Client side flow control model for the les protocol,” [Online]. Available: https://github.com/zsfelfoldi/go-ethereum/wiki/Client-Side-Flow-Control-model-for-the-LES-protocol, 2016, accessed: 2018-07-17.
-  Kraken.com, “How long do digital assets/cryptocurrency deposits take?” [Online]. Available: https://support.kraken.com/hc/en-us/articles/203325283-How-long-do-digital-assets-cryptocurrency-deposits-take-, 2019, accessed: 2019-03-26.