Repeat-Authenticate Scheme for Multicasting of Blockchain Information in IoT Systems

TL;DR

This paper introduces a multicast-based authentication scheme for blockchain information dissemination in IoT systems, reducing communication overhead and exploiting blockchain structure for efficient, reliable, and timely authentication over wireless channels.

Contribution

It proposes a novel multicast authentication scheme with time-amortized signatures and redundancy coding, improving efficiency and reliability in blockchain IoT communication.

Findings

Multicast approach reduces communication resources compared to unicast.

Time-amortized signatures enable delayed authentication, saving bandwidth.

Redundant coding improves reliability over unreliable wireless channels.

Abstract

We study the problem of efficiently disseminating authenticated blockchain information from blockchain nodes (servers) to Internet of Things (IoT) devices, through a wireless base station (BS). In existing blockchain protocols, upon generation of a new block, each IoT device receives a copy of the block header, authenticated via digital signature by one or more trusted servers. Since it relies on unicast transmissions, the required communication resources grow linearly with the number of IoT devices. We propose a more efficient scheme, in which a single copy of each block header is multicasted, together with the signatures of servers. In addition, if IoT devices tolerate a delay, we exploit the blockchain structure to amortize the authentication in time, by transmitting only a subset of signature in each block period. Finally, the BS sends redundant information, via a repetition code, to deal with the unreliable wireless channel, with the aim of decreasing the amount of feedback required from IoT devices. Our analysis shows the trade-off between timely authentication of blocks and reliability of the communication, depending on the packet loss rate offered by the channel. The numerical results show that the performance benefits of the proposed scheme makes it a viable starting point for designing new lightweight protocols for blockchains.

Figures

Equations

$$s=\lfloor \frac{b-k{l}_b}{l_s}\rfloor$$

$$\Phi =\underset{t\to \infty }{\lim }\frac{1}{t}\sum _{\tau =0}^t\sum _{u=0}^U\text{mathbbm}1\{d_u(\tau )>d\}.$$

$$p_{1,1}=p_s\left(1-p_{e,b}^k\right),$$

$$p_s$$

$$=\sum _{j=1}^{\min (V_u,s)}(1-p_{e,s}^j)\frac{\left(\genfrac{}{}{0ex}{}{V_u}{j}\right)\left(\genfrac{}{}{0ex}{}{V-V_u}{s-j}\right)}{\left(\genfrac{}{}{0ex}{}{V}{s}\right)}.$$

$$p_{1,j}=\{\begin{array}{ll}{p}_s(1-p_s{)}^{j-1}(1-p_{e,b}^k{)}^j,& \text{if}1\le j\le d-k+1\\ p_s(1-p_s{)}^{j-1}(1-p_{e,b}^k{)}^{d-k+1}& \\ {\prod }_{i=d-k+2}^j(1-p_{e,b}^{d-i+1}),& \text{if}d-k+1<j\le d.\end{array}$$

$$p_{1,0}=1-\sum _{j=1}^d{p}_{1,j},$$

$$\mathbf{P}=\left(\begin{array}{ccc}0& p_{0,1}& 0\\ p_{1,0}& p_{1,1}& {\sum }_{j=2}^d{p}_{1,j}\\ 0& 1& 0\end{array}\right)$$

$$\mathbf{\pi }=\left(\begin{array}{ccc}{p}_{1,0}& 1& {\sum }_{j=2}^d{p}_{1,j}\end{array}\right).$$

$$T$$

$$=\frac{1}{d\cdot p_{1,0}+1\cdot p_{1,1}+{\sum }_{j=2}^{d}j\cdot p_{1,j}}.$$

$$\Phi =U\cdot T\cdot p_{1,0}.$$

$$p_{1,j}=$$

$$=$$

$$p_{1,j}=$$

$$\left(\prod _{i=d-k+2}^{j-1}(1-p_s)(1-p_{e,b}^{d-i+1})\right)\cdot$$

$$p_s(1-p_{e,b}^{d-j+1}),$$

$$p_{1,j}=p_s(1-p_s{)}^{j-1}(1-p_{e,b}^k{)}^{d-k+1}\prod _{i=d-k+2}^j(1-p_{e,b}^{d-i+1}).$$

Full text

I Introduction

In recent years, there has been a growing interest in understanding the potential applications of blockchains to the Internet of Things (IoT) landscape [1]. However, the literature on the integration of the blockchain protocols with the wireless networks is still scarce [2]. 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 [3].

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, leading potentially to a communication bottleneck. A related problem is that the legacy schemes use reliable transport layer (e.g. TCP), which involves a significant signalling overhead and is thus unsuitable 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 highly likely to be interested in receiving the same information, namely the same blocks or, in case of lightweight clients [4], just the block headers. 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.111The servers authenticate the data packet carrying the block and should not be confused with the blockchain validators, which sign the block. 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 through transactions.

By leveraging 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, in general, provided by forward error correction (FEC). In this work we attain reliability in the simplest form of FEC, which is a mere repetition of the blocks. The signatures are not repeated, since we rely on the signature amortization property that is inherent to the blockchain protocols and 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 may arise, as illustrated in the examples in Fig. 1, in which there is a server and three clients, which are initially synchronized. The server first multicasts a block to the clients, but none of the clients receive the signature, see Fig. 1(a). Consequently, since the clients cannot verify the block, they are now delayed by one block, see Fig. 1(b). The server then sends a third block to the three clients. The first client receives the block without signature, increasing its authentication delay to two blocks, see Fig. 1(c). For the second client, both the third block and its signature are received, making the second block authenticated as well, thanks to the chaining. The third client only receives the signature of the third block. In this case, the number of non-authenticated blocks is also two, as the signature of the third block can not be chained because signatures are chained through blocks. Hence, the use of amortized signatures mitigates the effect of packet loss. As soon as the blocks are chained, the client can authenticate its copy of the blockchain using only a subset of the signatures.

Through analysis of the scheme, we show 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 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.

II Background

II-A Blockchains

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 [5]. 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 [5]. 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 [6]. The forks are resolved by voting on which of the co-existing chains should be considered valid [5]. After the resolution of a fork, the block that remains without children, see Fig. 2, termed orphan in Bitcoin, is deleted from memory. In principle, a fork can last many blocks, however regular blockchain networks are well connected to avoid generating consecutive orphan blocks.

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 [7, 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.222Alternatively, they can implement incentive-based protocols, e.g. see [8], 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 [9]. 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 [10], can be used to reduce the communication cost [11]. 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 [12]. 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 [12]. 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 [9].

III System model

We assume a set of $V$ servers and a set of $U$ 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 $t=1,2,\ldots$, the BS receives $V$ copies of the block and $V$ signatures (a pair from each server). The BS verifies all of them, discarding invalid blocks.

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 $l_{b}$ and $l_{s}$ bits, respectively. We assume that modulation and rate of the BS transmission are fixed and the bit error probability is $P_{\text{bit}}$ for the downlink channels of all clients. Thus, the probability of not receiving a block or signature is given by $p_{e,b}=1-(1-P_{\text{bit}})^{l_{b}}$ and $p_{e,s}=1-(1-P_{\text{bit}})^{l_{s}}$, respectively.

A client $u\in 1,\ldots,U$ 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. To avoid sending to the IoT devices information that is forked out from the blockchain, servers apply a delay before sending blocks to the BS. The delay, same for all servers, is chosen larger than the maximum duration of a fork. Accordingly, IoT devices never observe the event of fork, which is always resolved on the server side, at the expense of additional information delay.

We denote by $h$ the number of blocks in the blockchain. Further, we denote by $d_{u}^{r}$ the difference between $h$ and the last block that $u$ received and that is chained with the genesis block, and by ${d}_{u}^{a}$ the difference between $h$ and the last block chained with the genesis block for which $u$ received a valid signature. Note that $d_{u}^{a}\geq d_{u}^{r}$. In the example of Fig. 4, $d_{1}^{r}=0$, $d_{1}^{a}=1$, $d_{2}^{r}=d_{2}^{a}=4$, $d_{3}^{r}=d_{3}^{a}=5$. The maximum tolerated authentication delay, same for all devices, is $d$ block periods. $d$ does not include the delay introduced by servers.

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” [13]). 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 $k$ blocks333This forms a repetition code, which represents the simplest instance of packet-level FEC. Future works may introduce more complex coding schemes. and $s$ signatures that authenticate the last block among these $k$, see Fig. 5. In each block period, the $s$ signatures to be sent are chosen uniformly at random out of the available $V$ 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 $k$, 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 $b$ bits in each block period. The available resources permit to send

[TABLE]

signatures in a period, where $l_{b}$ and $l_{s}$ are the lengths of a block and a signature, respectively. It is necessary that $b$ is large enough to allow $s>1$ such that the data stream is authenticated.

The feedback from a client $u$ to the BS consists of a single bit and is transmitted only when $d_{u}^{a}>d$, where the maximum tolerated authentication delay $d$ is a design parameter. The purpose of the feedback is to trigger a unicast transmission of the last $d$ blocks from the BS to $u$, together with a signature to authenticate all of them, so that $u$ can re-synchronize. In case of such event, the BS has to allocate extra resources in addition to the $b$ bits, used for multicasting. According to this mechanism, the BS receives between 0 and $U$ feedback packets in a block period, depending on the synchronization state of the devices. In the example in Fig. 4, client $u=3$ sends the UL packet because $d=4$ and $d_{3}^{a}=5$. Note that $d$ also provides a upper bound to the value of $k$, as $k\leq d$.

V Analysis

In this section, we analyze how to select the parameter $k$ depending on the QoS ($\Phi$) to be offered. The QoS is defined as the long-term average number of clients delayed beyond the deadline $d$ (that is, the number of re-synchronizations triggered):

[TABLE]

Ideally $\Phi$ is zero, because there are no delayed clients.

At each period $t$, a client $u\in 1,\ldots,U$ checks if the block generated $d$ periods before (i.e. at $t-d$) has been received and authenticated, see Fig. 7. Recall that block generated at $t-d$ can be authenticated in two ways: a packet containing its signature is received at $t-d$; or a packet containing a signature is received at $t_{j}$, $t-d<t_{j}\leq t$ and all blocks between $t-d$ and $t_{j}$ have been received. This permits to authenticate the blocks at $t-d$ 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 $t$) is chained and authenticated, the client will surely not fail within the next $d$ periods.

Based on this key consideration, we introduce the variable $x(t)\in\{0,\ldots,d\}$ that is used to track the authentication state the client. When the client may request a unicast re-synchronization, the state is $x(t)=1$. From here, if the block $t-d$ is not authenticated, the client transitions to state $x(t+1)=0$, corresponding to the unicast re-synchronization, at which the last $d+1$ authenticated blocks are sent. After the client has been re-synchronized, it cannot request a unicast re-synchronization for the next $d$ periods, and hence it spends $d$ periods in state [math] before going back to state $x(t+d+1)=1$. On the other hand, if in state $x(t)=1$ the block $t-d$ has been authenticated by a signature received at $t-d+j$, where $0\leq j\leq d-1$, the client does not fail. In our process, it corresponds to a transition from $x(t)=1$ to $x(t+1)=j+1$. The sojourn time in $x(t+1)=j$ is $j$, because the successive $j-1$ blocks are authenticated as well. From here, the client always returns to $x(t+j-1)=1$. A possible interpretation of $x(t)$ is that it tracks the oldest chained signature found between $t-d$ and $t$. For instance, if a client always receives a chained signature in each period, it would stay in state $x(t)=1\,\forall t$. If it never receives trusted multicast signatures, it only receives unicast re-synchronizations, looping between $x=0$ and $x=1$. Finally, if the channel is reliable and the client receives a trusted signature every $d$ periods, it loops between states $x=1$ and $x=d$. In the following text we find the expressions for the transition probabilities $p_{1,j}$ for $0\leq j\leq d$.

The probability that block at $t-d$ is signed and received is

[TABLE]

where $p_{s}$ is the probability of receiving the packet (from at least one of the trusted servers) with a signature of the block and $p_{e,b}^{k}$ the probability of not receiving a packet containing the block in any of the $k$ transmission attempts. To find $p_{s}$, we indicate the number of servers trusted by client $u\in 1,\ldots,U$ as $V_{u}$, $0<V_{u}\leq V$. 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:

[TABLE]

Here, $\binom{V_{u}}{j}$ are the number of combinations for which $j$ signatures, out of the $V_{u}$ available from trusted servers, are selected to be multicasted; $\binom{V-V_{u}}{s-j}$ are the number of combinations of the signatures from untrusted servers (there are $V-V_{u}$), of which $s-j$ are transmitted. Finally, there are $\binom{V}{s}$ combinations of $s$ signatures that can be transmitted among the $V$ available at the BS.

Even if the block at $t-d$ is not signed, it may be authenticated by a block completed between $t-d$ and $t$, if they are chained. The probability that block at $t-d$ is received and not signed, but authenticated by the $j$-th successive block is found as follows. Since the first (chained) signature is received after $j$, we must take into account that $j-1$ blocks are received but not signed; we also take into account that the most recent $k-1$ blocks (those for which $d-k+1<j\leq d$) are transmitted less than $k$ times. The observations lead to the expression:

[TABLE]

The derivation is given in Appendix A. Note the similarity with a geometric distribution, that is “weighted” by the probability of chaining $j$ blocks. The probability of failure is found as:

[TABLE]

and $p_{j,1}=1,\,\forall j\neq 1$ 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 $j>1$ into a state $G$. The new chain has three states $\{0,1,G\}$ with transition probabilities:

[TABLE]

and stationary probabilities equal to:

[TABLE]

The average number of periods spent in states [math], $1$ and $G$ are $S_{0}=d$, $S_{1}=1$ and $S_{G}=\sum_{j=2}^{d}j$, respectively. We find the average time spent in state $1$ as:

[TABLE]

Then, the average number of clients that can potentially fail in a period is $U\cdot\pi_{1}$, since they follow independent processes. Among them, the average number of clients that actually fail in a period is:

[TABLE]

VI Results

The numerical results are obtained considering block header size of $l_{b}=640$ bits (the size of a block header in Bitcoin) and signature size of $l_{s}=512$ bits. The BS allocates $b=8000$ bits per block period for the multicasting. The maximum tolerated delay is $d=10$ blocks.444In blockchain applications, it is common to wait several periods, ranging from six in Bitcoin [5] to tens in other blockchain systems [14], 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, $\Phi$, see Fig. 8, for which we set $U=V$ 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 $\Phi$ increases with the bit error probability, $P_{\text{bit}}$, and with the number of servers, as expected. In the cases when $k$ is 2 and 5, the number of signatures sent in a period are $s=13$ and $s=9$, respectively. It is worth to note that, if $P_{\text{bit}}$ is low, it is better to reduce the number of repetitions, $k$, in order to accommodate more signatures. However, above a certain threshold value of $P_{\text{bit}}$, 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 $\Phi$ as function of repetitions $k$ and number of servers trusted by each client. The bit error probability is fixed to $P_{\text{bit}}=4\times 10^{-4}$. 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 $k$ 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. $V_{u}=5$, the value of $\Phi$ is drastically decreased, as it disposes of much frequent authentication. In both graphs, the value of $\Phi$ is only defined in the points where $V/s>d$, that is the condition for which the signature of each server is sent at least once every $d$ periods (on average).

VII 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 withhold valid blocks or signatures by not transmitting them. The extension in this research direction is part of our current work.

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 straightforward 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. The proposed scheme can, in principle, be extended for the transmission of large block headers or even of the full blocks, if packet fragmentation is taken into account.

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 $1$ to state $j$ happens when the first $j-1$ signatures are not received, and the $j$-th is received. In addition, all the $j$ blocks should be received, to allow the authentication chaining. We distinguish between two cases.

In the first case, $j\leq d-k+1$, each block is transmitted exactly $k$ times, and we write:

[TABLE]

Note that, in (12), we account for $j-1$ unsuccessful transmissions of packets containing signatures; $j-1$ successful transmissions of packets containing blocks (each repeated $k$ times); one successful signature transmission, and successful transmission of the $j$-th block.

In the second case, $j>d-k+1$, we take into account that blocks indexed $d-k+1<i\leq j$ are transmitted less than $k$ times, because they are recent. For instance, block with index $i=d-k+2$ is transmitted $k-1$ times, block $i=d-k+3$ is transmitted $k-2$ times. The last block ($j=d$) is transmitted only once. Based on these observations, we write

[TABLE]

where (13) takes into account that the first $d-k+1$ blocks are transmitted $k$ times, (15) that the $j$-th block is the only one whose signature is successfully transmitted (with probability $p_{s}$). Finally, (14) takes into account the intermediate blocks that are transmitted less than $k$ times. The equation can be re-arranged as:

[TABLE]

The two cases correspond to those of (5).

Acknowledgment

This work has been in part supported the European Research Council (ERC) under the European Union Horizon 2020 research and innovation program (ERC Consolidator Grant Nr. 648382 WILLOW) and Danish Council for Independent Research (Grant Nr. 8022-00284B SEMIOTIC).