BLOWN: A Blockchain Protocol for Single-Hop Wireless Networks under Adversarial SINR

03/15/2021 ∙ by Minghui Xu, et al. ∙ Shandong University 0

Known as a distributed ledger technology (DLT), blockchain has attracted much attention due to its properties such as decentralization, security, immutability and transparency, and its potential of servicing as an infrastructure for various applications. Blockchain can empower wireless networks with identity management, data integrity, access control, and high-level security. However, previous studies on blockchain-enabled wireless networks mostly focus on proposing architectures or building systems with popular blockchain protocols. Nevertheless, such existing protocols have obvious shortcomings when adopted in wireless networks where nodes have limited physical resources, fall short of well-established reliable channels, variable bandwidths impacted by environments or jamming attacks. In this paper, we propose a novel consensus protocol named Proof-of-Channel (PoC) leveraging the natural properties of wireless communications, and a BLOWN protocol (BLOckchain protocol for Wireless Networks) for wireless networks under an adversarial SINR model. We formalize BLOWN with the universal composition framework and prove its security properties, namely persistence and liveness, as well as its strengths in countering against adversarial jamming, double-spending, and Sybil attacks, which are also demonstrated by extensive simulation studies.



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Distributed Ledger Technology (DLT) refers to share, replicate, and synchronize a digital ledger across a distributed network without centralized data storage. As a widely used DLT, blockchain technologies intend to organize a digital ledger as a chain of blocks to enable remarkable properties such as decentralization, immutability, and traceability. Since Bitcoin has emerged as the first open cryptocurrency, blockchain has been envisioned as a promising technology that can be used in various practical applications such as finance [47], Internet of Things (IoT) [2], supply chain [25], and security services [42]. In recent years, the popularity of 5G and IoT has arisen more problems of managing devices, sharing information, and carrying on computing tasks among wireless nodes [45]. Such problems become even intractable in a wireless network with small-world and super-dense features [9]. To overcome these challenges, effort has been made to build secure and trusted computing environments such as mobile edge computing (MEC) enabled blockchain [51] and the blockchain empowered 5G [11] in wireless networks taking advantage of blockchain technologies.

Previous studies on blockchain-enabled wireless networks mostly focus on proposing architectures or building systems on top of popular blockchain protocols that are previously deployed on the Internet. Such blockchain protocols make use of consensus algorithms that are based on either proof of resources or message passing. Proof of resources based consensus requires users to compete for proposing blocks by demonstrating their utilization of physical resources such as energy and storage (e.g. Proof-of-Work [35]) or virtual resources such as reputation and weight (e.g., Proof-of-Stake [23]). Message passing based protocols such as PBFT [8], on the other hand, require the participants to reach consensus through message exchanges. Even though these consensus algorithms perform well for existing blockchain protocols, they are not suitable for wireless networks since they are mainly developed for systems with Internet serving as the underlying network infrastructure. More specifically, wireless networks fall short of well-established reliable channels built with physical wires such as fiber as the Internet does – the open free air communications are severely impacted by environments (e.g., interference or contention) resulting in the variable channel bandwidths; and wireless networks are particularly vulnerable to jamming attacks. These two barriers make it very possible for communications to fail, making the traditional consensus algorithms inapplicable. Such problems are not sufficiently addressed by existing blockchain protocols, which motivates our study on blockchain protocols over wireless.

In this paper, we propose BLOWN, a BLOckchain protocol for Wireless Networks, to overcome the above challenges. BLOWN is a two-phase protocol that adopts a new concept, namely Proof-of-Channel (PoC), to seamlessly integrate the procedures of consensus and channel competition. In PoC, nodes compete for available channels to win the rights of proposing blocks. Such a design makes probing the wireless channel conditions part of the consensus procedure, successfully reducing the communication cost while increasing consensus efficiency and effectiveness. On the other hand, we consider that an adversary can make adversarial jamming on the nodes but controls no more than 50% wealth of the network in BLOWN, where wealth is defined to be the total number of coins held by all users. BLOWN is a provably secure system that satisfies two formal security properties: persistence and liveness. Persistence means that if an honest node proclaims a transaction as stable, other honest nodes, if queried, either report the same result or report error messages. Liveness, on the other hand, states that the transactions originated from the honest nodes can eventually be added to the blockchain. To prove BLOWN’s properties, we formally model it with a universally composable (UC) framework and analyze it accordingly. Note that it is worthy of emphasizing that PoC can be adapted to multi-hop wireless networks if combined with existing techniques such as distributed spanner construction [53] or supported by an adequate routing layer [3].

Our main contributions are summarized as follows.

  1. To the best of our knowledge, BLOWN is the first provably secure protocol that is specifically designed for wireless networks under a realistic adversarial SINR model.

  2. A novel, general Proof-of-Channel consensus protocol is proposed in this paper, which leverages the natural properties of wireless networks such as broadcast communications and channel competitions.

  3. We develop a UC-style protocol for BLOWN and formally prove BLOWN’s persistence and liveness properties by showing that it satisfies concrete chain growth, common prefix, chain quality properties.

  4. Finally, extensive simulation studies are conducted to validate our theoretical analysis.

The rest of the paper is organized as follows. Section 2 introduces the most related works on state-of-the-art blockchain protocols. Section 3 presents our models and assumptions. In Section 4, the two-phase BLOWN protocol is explained in detail. Security properties of BLOWN are analyzed in Section 5, which discusses jamming-resistant communications, double-spending attacks, and Sybil attacks. We report the results of our simulation studies in Section 6 and conclude this paper in Section 7.

2 Related Work

Blockchain consensus protocols.

We classify blockchain consensus protocols into two categories: proof of resources (virtual or physical) and message passing, and briefly overview them in this section. For a more comprehensive survey we refer the readers to


Proof of physical resources means that users compete for proposing blocks by demonstrating their utilization of physical resources. Proof-of-Work (PoW) is of the most use in blockchain. The most popular example of PoW-based blockchain is the Bitcoin proposed in 2008, which selects leaders by computational powers (Proof-of-Work) [35]. Ethereum provides the Turning-complete Ethereum Virtual Machine (EVM) and adopts a modified PoW (with Ethash) [49]. Alternatives to PoW include Proof-of-Space [13], Proof-of-Burn (PoB) [48], Proof-of-Elapsed Time (PoET) [19], in which Proof-of-Space, also known as Proof-of-Capacity or Proof-of-Storage, refers to consensus nodes competing by occupied memories or disk spaces, PoB means that a node can destroy coins to virtually earn mining rights, and PoET, proposed by Intel, leverages trusted hardware (e.g., SGX) to determine how long a node has to wait before it is allowed to generate a block.

In contrast to proof of physical resources, proof of virtual resources aims to show the utilization of virtual resources such as reputation, stake, or elaborately defined weight. For example, Proof of Stake (PoS) was developed to address the power consumption issue of PoW and it resorts to stakes as voting rights rather than computational powers. Algorand uses a cryptographic Sortition algorithm to randomly select a verifiable committee according to stakes [16]. IOHK created the Ouroboros family in recent years, which adopts PoS and G.O.D coin tossing to randomly choose a leader according to stakes [23]

. Snow White utilizes an epoch-based committee which embodies successful block miners in a specific time period so that all nodes have an identical view of the committee

[5]. In Proof-of-Reputation (PoR), each node is assigned a reputation [32], and a node can write blocks only when its reputation meets certain requirements; thus PoR always comes with incentive mechanisms or economic penalty strategies.

In message passing based blockchain protocols, nodes can perform local computations and broadcast messages to each other to reach consensus. This method provides blockchain the robustness to Byzantine failures while ensuring liveness and safety. In Ripple, a transaction that receives more than 80% votes from UNL-recorded servers can step into the next round, and transactions having survived through the whole RPCA process can be added to the blockchain [43]. ELASTICO partitions nodes by their unique identities and a consensus is reached in each shard based on byzantine agreement protocols [30]. Stellar creates overlapped shards, also known as quorum slices, leveraging Federated Byzantine Agreement (FBA) to reach consensus [46]. Omniledger uses lottery-like RandHound and VRF-based leader election algorithms to assign validators to each shard [24]. Other message-passing based protocols utilized in blockchain include PBFT [8], HoneyBadgerBFT [33], Tendermint [27], and Hotstuff [52].

Blockchain for Internet of Things. IoT encompasses devices that are generally connected to a wireless network. Blockchain has been applied for various IoT applications such as access management, security enhancement, and privacy protection. Novo developed a new architecture, which contains six components, for access management in IoT based on blockchain [39]. Dorri et al. optimized blockchain for IoT by introducing a distributed trust model, in which new blocks proposed by the users with high trust can be free from complete transaction validation to decrease the transaction processing overhead. Feng et al. [14] proposed a radio and computational resource allocation joint optimization framework for blockchain-enabled mobile edge computing. In vehicular ad hoc networks, Malik et al. [31] utilized blockchain to achieve secure key management. Guo et al. [18] presented a novel endogenous trusted framework for IoT, which integrates blockchain, software-defined networking, and network function virtualization. Guo et al. [17] constructed a blockchain-based authentication system to realize trusted data sharing among heterogeneous IoT platforms. In [29], Liu et al. developed a tokoin (token+coin) based novel framework to provide fine-grained and accountable access procedure control leveraging blockchain for various IoT applications. Its unique significance lies in that the fine-grained access policy can be defined, modified, and revoked only by the resource owner and the whole access procedure, not just the access action alone, can be accountably and securely controlled. In [28], Liu et al. proposed an important idea of extending trust from on-chain to off-chain making use of trusted hardware and blockchain to ensure that the data in digital world is consistent with the truth in physical world and that any change in physical world should be reflected instantly by the data change in digital world.

Consensus protocols for wireless networks. Since consensus is the core of blockchain and our study is closely related to wireless networks, we briefly survey the studies on consensus protocols for wireless networks. The abstract MAC layer [26] is one of the earliest models that can achieve elegant abstraction and precisely capture the fundamental guarantees of the low-level network layer performance in wireless networks. Newport provided the first tight bound for distributed consensus in radio networks [37]. With the abstract MAC layer, Newport and Robinson gave a fault-tolerant consensus algorithm that terminates within , where is the unknown network size [36]. A pioneering work on the implementation of the abstract MAC layer provides a groundbreaking scheme to adaptively tune the contention and interference in wireless channels [54]. Moniz et al. [34] proposed a BFT consensus protocol allowing faulty nodes with time complexity of . They assumed an abstract physical layer in wireless ad hoc networks and directly used high-level broadcast primitives. Chockler et al. [10] explored fault-tolerant consensus with crashed nodes. Their study reveals the relationship of collision detection and fault-tolerant consensus under a graph-based model. Assuming realistic message delays and a graph model, Scutari and Sergio designed a distributed consensus algorithm for wireless sensor networks [44], making use of a network model that considers the MAC layer with a multipath and frequency-selective channel. Aysal et al. [4] studied the average consensus problem with probabilistic broadcasts. They explored the effect of wireless medium on the consensus process and extended the non-sum preserving algorithm to accelerate convergence.

Summary. A common drawback of proof of physical resources lies in their prohibitively large demands of physical resources such as high computational power, storage, energy, or specific hardware, of which devices in wireless networks are notoriously limited; on the other hand, proof of virtual resources might encounter centralization problems caused by the over-powerful validators or authorities. Additionally, message-passing protocols always incur a significant amount of message exchanges leading to non-trivial communication overhead. Most notably, almost all existing works mentioned above were developed for the Internet resting on the close medium with sufficient bandwidth where jamming is not an issue; thus they are insufficient in addressing problems of limited bandwidths and jamming attacks arisen from the open nature of wireless communications. Motivated by these observations, in this paper we propose BLOWN, a wireless blockchain protocol that relies on the newly-developed PoC to seamlessly integrate wireless communications with blockchain consensus while guaranteeing persistence and liveness, the two critical security properties of blockchain, to counter jamming and various blockchain-specific attacks.

3 Models and Assumptions

Network Model. In this paper, we consider a network with a set of nodes arbitrarily deployed in a communication space. Such a network could contain a group of manipulated Unmanned Aerial Vehicles (UAVs) or intelligent robots in realistic scenarios. A node is equipped with a half-duplex transceiver that can transmit or receive a message, or sense the channel, but cannot transmit and receive or transmit and sense simultaneously. Let be the Euclidean distance between nodes and , denote the disk centered at with a radius , and denote the set of nodes within including .

We assume that each node knows the identities, locations and public keys of all other nodes. We further assume that each node can generate key pairs and has access to a secure EUF-CMA digital signature scheme (details of cryptographical tools employed in this paper are presented in protocol analysis and simulation sections). Each node maintains a hash-chain of blocks, and each block contains multiple transactions. We denote frequently-used notations of transaction, block, blokchain, chain of block headers by , , , and , respectively, and use super/subscript to attach more specific information. A transaction is modeled as a coin exchange process. We adopt the notion of the unspent transaction outputs (UTXOs) accounting method. A UTXO-based account stores coins in a set of UTXOs, and a UTXO defines an output of a blockchain transaction that has not been spent. This UTXO model provides a high level of security since it is convenient to authenticate all transaction sequences using UTXOs, limiting the risk of double-spending attacks.

Fig. 1: Epoch-based execution.

Interference Model. We adopt the Signal-to-Interference-plus-Noise-Ratio (SINR) wireless network model, which captures the network interference in a more realistic and precise manner than a graph-based one [55]. A standard SINR model can be formulated as follows, which states that a message sent by is correctly received by if and only if


where is the received signal power of node from , is the uniform transmit power, is the interference at and is the set of nodes that transmit in the current round, is the ambient noise, is the path-loss exponent, and threshold is determined by hardware. To capture a fine-grained noise, we define , where is the composite noise generated by the environment and adversaries. Assume each node uses a common noise threshold , and the distance between any two nodes is bounded by . We further assume that each node can perform physical carrier sensing. If at least one neighboring node of broadcasts a message, would either receive a message or sense a busy channel. At each slot, a node may either (a) sense an idle channel (the measured signal power is lower than ); (b) receive a message (the measured signal power exceeds and ); or (c) sense a busy channel (the measured signal power exceeds but ). Let be the total received signal power at a node. Then when the node receives a message, the interference plus noise can be calculated by with a known [20, 56, 40, 21, 1].

Epoch-based Execution. As shown in Fig. 1, the BLOWN protocol is executed in disjoint and consecutive time intervals called epochs, and at each epoch no more than one block can be generated. Each epoch consists of two phases with each containing multiple rounds. In , we denote as the -th round in phase one and as the -th round in phase two, with consisting of two slots and having only one slot. Besides, is the length of phase one and is the length of phase two, where is a variable constant determined later.

Adversary. We assume that there exists a group of adversaries who can freely join or leave the network, create identities, or make noises to interfere with any honest node at any time. For simplicity, the group of adversaries can be regarded as a powerful adversary who controls less than 50% wealth of the entire network. can launch jamming attacks. To leave a chance for an honest node to communicate, is ()-bounded at any time interval of length rounds, where and , indicating that the super adversary can jam nonuniformly at most rounds within . Each node maintains a variable

, which is the estimate of

by .

In this paper, we say that event

occurs with high probability (w.h.p.) if for any

, occurs with probability at least , and with moderate probability (w.m.p.) if for any , occurs with probability at least . A summary of all important notations (including the ones from the BLOWN protocol and the protocol analysis) and their semantic meanings is provided in Table I.

Symbol Description
block generated by node in the -th epoch
blockchain locally stored at node
block headers read from
phase one (phase two)
set of all nodes
network size
constant used to determine the length of phase two
counter variable used to record round information
length of of the -th epoch
a transaction
temporary transaction stack of node
’s probability of sending a message
aggregated probability of all nodes
an upper bound of
-th (-th) round of in the -th epoch
as the leader counter of
initial value of generated by Sortition()
time window of the adversary
estimate of by node
deposit of node
proof created by Sortition()
proportion of non-jammed rounds
the parameter to determine the hardness of Sortition
TABLE I: Summary of Notations

4 The BLOWN protocol

In this section, we present the two-phase BLOWN protocol. We first summarize the BLOWN protocol by providing an overview of BLOWN and its construction primitives, and then detail the protocol itself.

4.1 Overview and Utilities of BLOWN

In this subsection, we present an overview on BLOWN, and describe the construction primitives/utilities to more precisely and concisely illustrate the BLOWN protocol.

4.1.1 An Overview on BLOWN

Fig. 2: BLOWN protocol overview.
1:function Sortition(, seed, role, , , )
2:     , = VRF(, seedrole)
3:     /, LeaderCounter(role, , , )
4:     return
5:function VerifySortition(, , , seed, role, , , , )
6:     if VerifyVRF(, , , seedrole)  then
7:         return 0      
8:     /, LeaderCounter(role, , , )
9:     if  then
10:         return 0      
11:     return 1
12:function LeaderCounter(role, , , )
14:     if role is FOLLOWER then
15:         return      
16:     if  then
17:         return      
19:     while  do
21:     return
22:function MSG(, )
25:     return
26:function MSGT(, , )
30:     return
31:function MSGB(, , , , role, , , , )
32:      read from
37:     return
38:function Pack() Pack to form a block
39:     return
40:function Append(, ) append the new block
41:     return
Algorithm 1 Utilities for node

The BLOWN protocol proceeds in epochs, with each constructing no more than one block. Specifically, our protocol has two phases within an epoch, denoted by and as shown in Fig. 2. is responsible for initialization and leader election while is for transaction collection and block finalization. In our design, nodes contend by broadcasting messages on a wireless channel. In response, we establish a robust jamming-resistant channel by introducing an adaptive transmission mechanism, confronting background noise and jamming simultaneously. Such a channel is realized by dynamically adjusting the transmission probability of each node according to its sensed contention in the network. Concretely, we first adopt the Sortition algorithm to assign a weight based on its account balance. Sortition ensures that splitting coins to generate massive identities cannot break our protocol. After initialization, the protocol starts the process of leader election. We utilize the nature of contention in a wireless network to design our proof-of-channel consensus mechanism (PoC). To achieve usability and efficiency, PoC allows nodes to compete on the channel right-of-use to obtain opportunities of proposing blocks rather than rely on extra physical resources or introduce communication overhead. More specifically, upon receiving a message, is decremented. The sole survivor with non-zero at the end of is appointed as the leader. This essentially integrates leader election and channel contention into a single process, namely the phase one of BLOWN. In , the leader is responsible for collecting and verifying transactions, assembling them into a new block, and then broadcasting the block to the whole network. If the new block is valid, it is admitted by all honest nodes.

4.1.2 Utilities

Algorithm 1 lists the following frequently used functions for any node in BLOWN: Sortition(), VerifySortition(), LeaderCounter(), MSG(), MSGT(), MSGB(), Pack(), and Append(). It also presents the following data structures employed by the above functions: transaction , transaction stack , block , block header , blockchain , basic message , transaction message , and block message .

Concretely, we modify the crytographic Sortition algorithm proposed by Algorand[16] to make it suitable for our BLOWN protocol. The Sortition algorithm is based on a verifiable random function (VRF), which takes as inputs a private key , a random seed and a role, and outputs a hash as well as its corresponding proof . There are two types of roles: a FOLLOWER who can only be a follower during an epoch and a LEADER who is a potential leader. Besides, is the accumulated number of coins of all users in the network, is the deposit of node , is the leader counter of the node , and is the probability based on which each coin is used to increment the counter value where determines the hardness. The probability of

follows the binomial distribution

with . To determine , the LeaderCounter(role, , , ) divides into consecutive intervals as for and for . If ’s role is FOLLOWER, ; otherwise, if the normalized hash ( is the hash length) falls in the interval , is returned as the value of the leader counter. The function VerifySortition() intends to check if are valid by calling VerifyVRF() and recomputing LeaderCounter().

Three functions, namely MSG(), MSGT(), and MSGB(), generate messages that can respectively be used for leader election, transaction collection, and block finalization. Specifically, MSG() creates a basic message for leader election in , MSGT() produces a message embodying a transaction, which is sent during the transaction collection process in , and MSGB() outputs a message which contains a generated by the leader , a read from , the current value of the leader counter, and a string used to verify Sortition where is the original value of the leader counter. To reduce communication cost, we send embodied in for a simplified verification. Finally, Pack() is adopted to validate and pack transactions to form a new block, and Append(, ) appends the new block to the local blockchain .

4.2 The BLOWN Protocol Specifications

In a nutshell, BLOWN is a two-phase protocol. As shown respectively in Algorithm 3 and Algorihtm 5, phase is employed for initialization and leader election while phase is for transaction collection and block finalization.

4.2.1 Phase

1:if  decides to send a message based on  then
2:      MSG(, ), broadcasts
4:     if channel is idle then
7:     else
8:         if  receives a message  then
12:if  then
14:     if there is no idle rounds in the past rounds then
15:         ,
Algorithm 2 PoC subroutine
1: Initialization
2:Sortition(, seedrole, , , )
3:, , ,
4: Leader election
5:while TRUE do
6:     if  then As a potential leader
7:          slot one of
8:         run PoC
9:          slot two of
10:         if  broadcasts a message in slot one then
11:               listens on the channel
12:              if  senses an idle channel then
13:                  Goto with run as a leader               
14:         else
15:               MSG(, ), and broadcasts          
16:     else As a follower
17:          slot one of
18:          listens on the channel to receive a message
19:          slot two of
20:         if in slot one receives from and has  then
21:              if  senses an idle channel then
22:                   recognize as the leader
23:                  Goto with run as a follower               
24:         else
25:               MSG(, ), and broadcasts               
Algorithm 3 BLOWN protocol

Let’s examine the details of the BLOWN protocol. Lines 2-3 of Algorithm 3 constitute the initialization process. First, Sortition() takes as inputs , seedrole, , and (see Line 2), and outputs , and , where and are respectively a hash and its corresponding proof, and stands for the initial leader counter. Note that indicates that remains to be a potential leader while indicates that is a follower. Let be the maximum transmission probability, which can be initialized to any small number in . Since the absence of followers might lead to a bad case in which all nodes are potential leaders and simultaneously broadcast messages in slot one111Such a bad case only occurs with a small probability, which is less than , we prevent this from occurring by ensuring that there always exist at least one follower after initialization. A simple approach to achieving this goal is to artificially and randomly add followers (with a FOLLOWER rule) to the network. Second, we set , , , (Line 3 ), where is the probability on which node decides to send a message, and is upper-bounded by , is a counter variable used to record round information, is the estimate of the time window of the adversary by node , is the round counter used in , and is the leader counter variable initialized to . After initialization, proceeds round by round with each containing two slots, and a node ’s activity at each slot depends on its role.

Before proceed any further, we need to explain the PoC subroutine described in Algorithm 2 to adjust , and , the leader counter, transmission probability and adversary’s time window estimate, according to the sensed channel condition at the first slot of each round in . Specifically, with (a potential leader) performs the following actions: it either broadcasts a message with probability (Lines 1-2), where is the signature of , or senses the channel with probability (Lines 3-10). One can see that adapts its in a multiplicative increase or decrease manner by a factor of , where is a small number that is loosely determined by and (see the proof of Theorem 3). Particularly, is multiplicatively increased (Line 5) when the channel is sensed idle or decreased (Line 9) when a message is received222Receving a message indicates the message has a valid signature, and we do not explicitly present the signature verification process for conciseness.. Such a mechanism ensures that honest nodes can cooperatively adjust their transmission probabilities to help reduce contention on the channel. Meanwhile, we decrease by 1 if the channel is idle (Line 6) as the estimate of adversary’s time window seems to be too large when the channel is idle, and decrease by 1 if a neighbor of successfully broadcasts a message (Line 10) as the neighbor seems to have a better chance of being the leader. On the other hand, if the number of rounds in is no less than (Line 12), the estimate of the adversary’s time window, we further check whether or not there is an idle round in the past rounds (Line 14), and if not, is decreased (Line 15) and is increased (Line 16) to further adjust and . One can see that a successful broadcast causes the decrements of the values of the receivers. When , becomes a follower who can only sense the channel in slot one of the next round.

Now we are back to continue explaining Phase of the BLOWN protocol, which contains multiple rounds. At slot one of each round, if is a potential leader, which means , runs the PoC subroutine described in Algorithm 2 (Line 8); otherwise, listens on the channel for message reception (Line 18). At slot two of each round, behaves according to its actions in slot one. If as a potential leader broadcasts a message in slot one and senses an idle channel in slot two, it can set itself as a leader and goto (Lines 10-13); otherwise it broadcasts a message in slot two. A follower recognizes as the leader only when believes is the only transmitter in slot one and senses an idle channel in slot two (Lines 20-23); otherwise transmits in slot two (Line 25). In Theorem 4, we prove that slot two is capable of letting the leader and the followers mutually recognize each other.

At the end of , there should be only one survivor with , who then becomes the leader. Note that denotes the length of , which is used to determine the length of . We will prove in Theorem 4 of Section 5 that Algorithm 3 ensures a successful leader election.

1:if  decides to send a message based on  then
2:      MSGT(, , ), and broadcasts
4:     if channel is idle then
7:     else
8:         if receives a message  then
11:if  then
13:     if there is no idle round in the past rounds then
14:         ,
Algorithm 4 sendTransaction subroutine

4.2.2 Phase

1: Transaction collection
2:while  do
3:     if  then As a leader
4:          listens on the channel to receive a
5:         if receives .tx then
6:              [] =          
7:     else As a follower
8:         run sendTransaction      
10: Block finalization
11:if  then
12:     if  then As a leader
13:         ()
14:         (, )
15:         (, , , , role, , , , ), and broadcasts
16:     else As a follower
17:         if receives && VerifySortition (, seed, , , )  then
18:              Append(, )               
Algorithm 5 BLOWN protocol

Phase of BLOWN performs transaction collection and block finalization, as shown in Algorithm 5. It proceeds by a fixed amount of rounds where each round contains only one slot, and is a constant to directly determine the length of and indirectly the maximum block size, which can be adjusted according to specific implementations. We refer to as the round counter in . If , a leader selected in should listen to the channel to receive signed transaction messages, which are recorded in the stack , while other nodes continuously broadcast signed transaction messages (Lines 2-8). After rounds, the leader serializes all transactions to form a new block denoted by Pack(), and broadcasts the (Lines 12-15). Once receiving a from , a node should append the new block to its local blockchain only if is valid and VerifySortition (, seed, , , ) (Lines 17-18). Note that the sendTransaction subroutine presented in Algorithm 4 is employed by to broadcast transactions and the parameters , , are utilized to ensure jamming-resistant communications as they function in the PoC subroutine shown in Algorithm 2.

5 Protocol Analysis

Protocol is a protocol run by all nodes interacting with the ideal functionalities and . Initialization: Send (, , , , , ) to , which returns (). Next, initialize the remaining local parameters as , , , . Leader election: For each round of during the -th epoch, perform the following (1) or (2) according to the value of : If , run PoC in slot one. If broadcasting a message in slot one, listen on the channel in slot two and if the channel is idle, goto with at the end of slot two; otherwise, send (, ) to , which returns a signed message , i.e., is obtained by querying , then broadcast in slot two. If , listen on the channel in slot one. If receiving a valid from with in slot one, and sensing an idle channel in slot two, recognize as the leader and goto with at the end of slot two; otherwise, generate MSG(, ), send to , which returns , then broadcast in slot two. Note that a valid holds when returns 1 upon being queried with (). Transaction collection: At each round , if , listen on the channel for a possible signed transaction message , add the transaction to the local stack as [] = if receiving and returns 1 when being queried with . If , send MSGT(, , ) to , which returns a signed message , then broadcast . Block finalization: During the round , if , execute () and (, ); then generate (, , , , role, , , , ) and send it to , which returns . If , listen on the channel for a possible block message ; if receiving a valid , which means returns 1 upon being queried with (), and returning 1 upon being queried with (, seed, , , ), execute Append(, ).

Fig. 3: The protocol (hybrid experiment) .

Proving security properties of a complex protocol such as BLOWN is very challenging. Thus we leverage the universally composable (UC) framework proposed by Canetti et al. [6]. The UC framework captures the security of a protocol via emulating an idealized protocol (often referred to as an ideal functionality), which satisfies strong security properties. Then a real protocol specifying concrete implementations is said to be secure if it is indistinguishable from . The main feature of the UC framework is the universal composability that allows one to perform analysis on a complex protocol, whose security properties can be derived from the security of its components.

Protocol LeaderCounter: When activated with input (role, , , ), first initialize . If role is FOLLOWER, output and exit. If role is LEADER, compute ; if falls in , output and exit; otherwise, increase until it satisfies that , then send to and output . Sortition: When activated with input (, seed, role, , , ), first feed (, seedrole) to , which returns (, ); then compute / and input (role, , , ) to LeaderCounter, which returns ; finally, output (). VerifySortition: When activated with input (, , , seed, role, , , , ), first feed (, , , seedrole) to , which returns (, , , seedrole, ). If , output FALSE, which means that verification fails; if , compute / and feed (, ) to LeaderCounter to obtain . Following that, if , output FALSE; otherwise output TRUE, which means that verification succeeds.

Fig. 4: The protocol (hybrid experiment) .

Functionality LeaderCounter: Upon receiving (role, , , ) from some node , verify if role is FOLLOWER. If so, send to ; otherwise, compute . Next if falls in , sends to ; otherwise increase until it satisfies that , then send to . Sortition: Upon receiving (, seed, role, , , ) from some node , send (, seedrole) to the adversary, who returns (, ). If there is no entry (, seedrole, , ) recorded, record (, seedrole, , ); if there is an existing entry (, seedrole, , ) that satisfies and , do nothing. Next compute / and send (role, , , ) to LeaderCounter, which returns . Finally, send () to . If there is an entry (, seedrole, , ) recorded but or , send an error message to . VerifySortition: Upon receiving (, , , seed, role, , , , ), send (, , , seedrole) to the adversary, who returns (, , , seedrole, ). If or there is no entry (, seedrole, , ) recorded, send to , which means that verification fails. If and there is an existing entry (, seedrole, , ), compute / and send (, ) to LeaderCounter, which returns . If , sends 0 to , i.e., verification fails; otherwise send 1 to meaning that verification succeeds.

Fig. 5: The ideal functionality

5.1 UC Composition of BLOWN

We formulate two UC-style protocols (or hybrid experiments), which are presented in Fig. 3 and Fig. 4. The conducts a hybrid experiment for BLOWN using an ideal hybrid functionality where is an ideal digital signature scheme and is an ideal functionality, performing three sortition-related functions as shown in Fig. 5. BLOWN is denoted as , which implements real protocols and . Besides, is a protocol that realizes sortition-related functionalities, consisting of LeaderCounter, Sortition, and VerifySortition. These functionalities are consistent with the corresponding ones specified in Algorithm 1 except that uses an ideal functionality in Sortition and VerifySortition. In contrast, Algorithm 1 adopts a realistic VRF implementation. Let be respectively the adversary, environment, simulator, whose specific meanings should depend on the context. We first show that the following lemma 1 holds for .

Lemma 1.

With the same security parameter , for each probabilistic polynomial-time (PPT) , it holds that the protocol securely realizes under the -hybrid model.


Let be an adversary that interacts with the nodes running under the -hybrid model. We need to construct an ideal simulator such that the view of any environment of an interaction with and is exactly the same as that of an interaction with and . In our construction, the simulator runs (under the name of ) and simulates other possibly involved nodes. Here, the who is attacking the VRF function is identically defined as the one attacking the ideal functionality presented in [12]. is responsible for forwarding messages from and . Besides, performs the following operations:

  1. Simulating value and proof generation: When receives a message (, seedrole) in the ideal process from , it simulates for (under the name of ) the process of generating (Evaluated, , , ), where represents a session id which is not explicitly presented in this paper for simplicity. then forwards (, ) to .

  2. Simulating verification: When receives a message (, , , seedrole) in the ideal process from meaning a verificaiton query is received, it simulates for the process of VRF verification. Once receiving (Verified, , , , ), forwards (, , , seedrole, ) to .

It is straightforward to verify that perfectly simulates the adversary and other components. That is, for any PPT , cannot distinguish between its interaction with and or and . Thus one can draw a conclusion that securely realizes under the -hybrid model. ∎

In the setting of [12], the authors elegantly proved that there exists a realistic implementation of that can securely realize the ideal under the Computational Diffie-Hellman (CDH) assumption in the random oracle model. Therefore with such a secure real-world implementation, our protocol , abbreviated as , is computationally indistinguishable from , and thus securely realizes according to Lemma 1. Then for the analysis of the complicated BLOWN protocol, one can get rid of the repeated reduction proofs by conducting a hybrid experiment , where is the ideal signature scheme presented in [7]. In Section 5.2, we report the salient features that can be realized by with the ideal combinatorial functionalities . Thus we need to show that the real BLOWN protocol ( is a secure EUF-CMA digital signature scheme) and are computationally indistinguishable so that can inherit all features of .

Theorem 1.

With the same security parameter , for each PPT , it holds that there is a PPT such that