Introduction
Peer-to-Peer (P2P) applications are featured by distributed architectures that partition tasks or work loads between peers without a trusted authority. Peers self-organize and collaborate in certain tasks such as forwarding files, delivering messages, or uploading data. Example P2P applications include mobile data offloading that allows mobile users to cooperatively deliver cellular network data by exploiting complementary network technologies (e.g., WiFi and femtocell) [1], Delay Tolerant Social Network (DTSN) [2] where users opportunistically forward messages for others that share common interests by following a store-carry-forward mechanism, and mobile crowdsensing in which smartphone users collaboratively upload data for the purpose of reducing energy consumption and mobile data cost [3].
The effectiveness of data transfer, packet forwarding, or data collection in the P2P applications mentioned above relies on the cooperation of mobile users. As data transmissions in such P2P applications often happen in an opportunistic manner, uncooperative behaviors would lead to low delivery success ratio and long delivery latency. On the other hand, autonomous mobile users may exhibit selfish behaviors, refusing to cooperate in data transmissions for the concerns on energy and bandwidth consumption. Therefore the participating users should be provided with enough rewards for cooperation. However, the properties of P2P applications bring challenges into the design of an incentive mechanism [4], [5]. First, most P2P applications exploit opportunistic connections among mobile users without knowing who will be the next hop and how many users will get involved; thus it is hard to know who will get rewarded and how many rewards shall be paid. Second, in a distributed environment, users may not believe that they can get their rewards as there is no pre-established trust between each other. Moreover, the uncontrolled environment may lead to some disorders in an incentive system. Finally, users may have different valuations on consumed resources and different requirements on the returns.
Many incentive mechanisms have been proposed and implemented, including the reputation systems, the Tit-for-Tat schemes, and the credit based approaches. A reputation system [6], [7] can help a user identify uncooperative peers by monitoring the behaviors of its neighbors during data transmissions and propagating the uncooperative reputation throughout the network. Such systems generally lack the considerations on a formal specification and analysis of the incentive types and on how to define the reputation of a new user. Tit-for-Tat schemes [8], [9] stimulate mobile users to cooperate by exchanging equal services among them based on what contributions they have done for others. Each user receives as much service as it has done for its neighbors based on its history behavior. These schemes are restricted to applications with long session durations that can provide many opportunities for reciprocation between pairs of users. Another challenge of Tit-for-Tat is its hardness of meeting the different service requirements of the users. Credit based approaches [10], [11] provide incentives by paying the cooperative users certain amount of credit or virtual money. Such approaches could be the most promising due to their explicit and flexible incentive methods; nevertheless, most credit based incentive schemes either rely on a central trusted authority or do not give an explicit digital currency system that is provably secure, leading to possible system collapses.
Blockchain is a decentralized digital ledger of economic transactions that can be programmed to record not just financial transactions, and it has the advantages of transparency, security and speed [12]–[14]. Blockchain-based cryptocurrencies have recently gained a noticeable popularity, and their current market capitalization is over $566 billion. The security of Blockchain depends on a majority of the computing power instead of a central authority, thus eliminating the risks of one taking control over the system, generating inflation, or completely shutting down the system. In this paper, we exploit Blockchain transactions to incentivize users to cooperate in P2P applications.
The basic idea of our incentive scheme is to employ Blockchain transactions to reward those intermediate nodes that contribute to a successful delivery from the sender to the receiver. If an intermediate node helps transmit the data, the next-hop node sends it a signed acknowledgement which is used as a proof of getting the rewards. The miners in the Blockchain P2P system are in charge of verifying whether there is a successful delivery from the sender to the receiver, and examining the validity of the signed acknowledgements provided by the cooperative intermediate nodes in a successful delivery. The Blockchain P2P system is an independent system from P2P applications, the transactions generated in P2P applications will send to the miners in the Blockchain P2P system for the verification. This brings another concern: if a miner can see the content of a signed acknowledgement, she can disguise as a cooperative intermediate node to get the payment. To overcome this problem, we extend the Blockchain transaction syntax to support a secure validation of the acknowledgement by using commutative encryptions. We also propose a pricing strategy to defend the possible attacks resulted from selfish users and to prevent their collusion.
The major contributions of the paper are summarized as follows:
We design a Blockchain-based truthful incentive mechanism that can meet the diverse requirements of users in dynamic and distributed P2P environments.
We introduce a secure validation method to keep the to-be-verified content secret from the miners in the Blockchian P2P system.
We propose a pricing strategy to prevent selfish users from exhibiting selfish actions and to defend the collusion attacks resulted from them.
We further employ a game theoretical analysis and simulation study to demonstrate the security and efficiency of our incentive mechanism.
The remainder of the paper is structured as follows. Section II outlines the related work. In Section III, we introduce the Blockchain P2P system and the basic cryptographic primitives employed in this paper. Our incentive scheme is detailed in Section IV, followed by a comprehensive security analysis and evaluation in Section V. The paper is concluded in Section VI.
Related Work
The incentive schemes for P2P applications fall into three categories: Reputation, Barter (Tit-for-Tat), and Credit (virtual money).
A. Reputation-Based Approaches
In a reputation system [6], [7], [15], [16], each user is given a score that can be interpreted as the probability of an entity behaving honestly. Such a system provides us with information regarding the honesty of the peers, therefore can be utilized to identify misbehaving users. For example, a watchdog is used by a user in [16] to monitor the behavior of each neighbor to make sure that the neighbor forwards others’ data. If misbehaviors are detected, the user broadcasts the uncooperative reputation of the neighbor to other users in the network. Burak et al. [15] combined centralized reputation-based evaluation with collaborative reputation values based on votes. Reputation systems generally suffer from the following drawbacks: i) no formal specification and analysis of the types of the incentives is provided [10]; ii) the possibility of selfish users colluding with each other to maximize their welfare is generally ignored; and iii) the reputation-based approaches are known to be vulnerable to Sybil attacks [17] and whitewashing attacks [18].
B. Tit-for-Tat Schemes
Barter (Tit-for-Tat) based schemes [8], [9], [19] stimulate mobile users to cooperate by exchanging equal services based on what contributions they have done for others. In [8], Buttyan et al. proposed the use of pair-wise Tit-for-Tat (TFT) as an incentive mechanism for DTNs, in which each user estimates the contribution levels of its neighbors based on their behaviors in history, and then forwards as much traffic to its neighbors in accordance with their contribution levels. Parisa et al. [9] used the T-Chain incentive mechanism to discourage free-riding in video streaming applications. Tit-for-Tat schemes are restricted to applications with long session durations that can provide many opportunities for reciprocation between pairs of users [20]. Another challenge of Tit-for-Tat is its hardness to meet the different service requirements of the users.
C. Credit-Based Schemes
In Credit based systems [10], [11], [21]–[24], a central authority assigns certain virtual money to each user. When a user needs others’ help (for example, to forward a message), it should pay the helper certain amount of virtual money. As the amounts of payments rely on the reports of the users, a selfish user may attempt to cheat the system to maximize its expected welfare. For example, a selfish node may withhold its acknowledgement, or collude with other nodes to forge acknowledgements, if such actions can maximize its welfare. Some effort has been made to counter such cheating behaviors. Zhong et al. [10] proposed a cheat-proof, credit-based system for stimulating cooperation among selfish nodes in mobile ad hoc networks. Felegyhazi et al. [25] and Zhang et al. [11] developed game theory frameworks based on the use of pricing strategies. These schemes assume that a routing path between the sender and the receiver is determined before data transmission occurs. Without knowing who will be the next hop and how many users will get involved, it is hard to know who will get rewarded and how many rewards shall be paid.
Other related credit-based schemes include [22] and [21]. Zhu et al. [22] proposed a layered incentive scheme for dynamic routing in DTNs. In this scheme, the sender first generates a base-layer message containing the payment policy. Then each of the intermediate nodes who agrees with the payment policy generates a new layer based on the previous layer by appending a non-forged digital signature. After receiving all the collected layered messages, the last intermediate node sends them to a trusted center, i.e., a bank, for validation and payment assignment according to the payment policy. Obviously, this mechanism emphasizes the generation and verification of the secure layered messages but does not involve a detailed pricing strategy. Chen and Chan [21] presented a pricing strategy running on top of a given DTN routing module, which works by setting the sender’s payment and the intermediate nodes’ rewards to ensure that selfish actions do not result in larger rewards. Bogliolo et al. [26] investigated the combined use of credit and reputation-based schemes to establish ad-hoc connections. We notice that all the credit based incentive schemes rely on central trusted authorities that do not exist in P2P applications. Furthermore, no explicit virtual digital currency system that is provably secure was proposed by any credit based system. Nevertheless, lacking a secure currency system could result in a collapsed incentive mechanism, just like the economy could break down if the banking system is not secure or is out of control.
Our incentive scheme is inspired by the existing research, but is very different. It is based on the Bitcoin system whose security is directly dependent on the majority of the computing power. We propose a secure validation approach carried out by the miners in the Bitcoin system instead of a trusted third authority, and a pricing strategy for the secure Bitcoin system to defend against selfish actions and prevent collusion attacks resulted from selfish users. Compared with the existing ones, our scheme does not rely on a trusted third authority but it can incentivize each node in P2P applications to honestly follow the designed protocol.
Preliminaries and the Threat Model
A. Blockchain P2P System
Since Bitcoin [27] came out in 2008, its underlying technique, blockchain has attracted lots of attentions from academia and industry. Many versions of Blockchain were released as open-source softwares [12], [27], [28]. Compared with other payment systems, Blockchain is peer-to-peer, i.e. users can transact directly without a trusted authority. Each transaction in Blockchain involves a sender
A typical transaction works for the money transfer as follows: (1)
Deposit protocols [31]–[33] have been implemented by exploiting the Blockchain P2P system, in which each user is required to initially put aside a certain amount of money, which will be paid back to the user once he/she honestly follows the protocol; otherwise the deposit is given to the other parties and compensates them for the fact that the protocol terminates prematurely. The design philosophy and features of Blockchain make it an attractive way to address the incentive challenges in peer-to-peer networks that lack trusted third parties.
B. Commutative Encryption
In this work, we employ commutative encryption as one of the basic cryptographic primitives. A commutative encryption function [34] is a family of bijections \begin{equation*} f_{a}(f_{b}(m))=f_{b}(f_{a}(m)) \end{equation*}
C. Threat Model and Assumptions
Fig. 2 illustrates a typical architecture of P2P applications. The system consists of senders, intermediate nodes, and receivers. Senders transmit certain files, messages, or the sensed data to the receivers with the help of the intermediate nodes. The numbers of senders and receivers are different in different P2P applications. For example, there are 1 sender and
Data transmissions in P2P applications rely on the cooperation between intermediate nodes. To incentivize the cooperations, senders give certain rewards to the nodes that help transmit the data. In this work, we assume that nodes are selfish but would take a rational decision to maximize their profit. Specially, each node may launch the following attacks:
Refusing to Pay: A sender can refuse to pay back the intermediate nodes when the data are successfully delivered to the receiver.
Denying Attack: The intermediate nodes or the receiver can deny that they have received the data from other nodes, which could prevent others from getting rewarded.
Extending/Shortenning the Path: The intermediate node can extend or shorten the path to get more reward from the sender.
Collusion Attack: Nodes can collude with each other to maximize their profit. In this work, we only consider the collusion among intermediate nodes or between an intermediate node and the receiver. We shall address the case where the sender colludes with the receiver in our future work by considering reputation based inventive systems.
Blockchain Based Truthful Incentive Mechanism
In our model, we employ the idea of credit based incentives to motivate intermediate nodes to cooperate. In a credit based scheme, incentive can be considered as a transaction. When discussing a transaction, we should figure out the following questions: (1) who pays who; (2) how to pay the bill; (2) how much the payer should pay; and (4) how to guarantee that the transaction is secure.
A. Who Pays Who?
When a sender wants to transmit a certain message to a receiver, there exist three different options to pay back the intermediate nodes. The first option is to let the receiver give rewards to all the intermediate nodes; but this approach allows malicious nodes to get high rewards by sending many fake messages. The second option is to give the rewards by both the sender and the receiver, which could suffer the same problem as the first option since the sender can collude with the intermediate nodes. The third option is for the sender to pay back the intermediate nodes when it figures out that the message is successfully delivered to the receiver, which is adopted by this work.
Another relevant question we need to answer is who should get the rewards. In this study, we choose to award only those nodes that contribute to a successful delivery, which means that an intermediate node cannot get a reward if the receiver does not receive the message correctly. To identify the intermediate nodes who help forward the message, the node in the next hop is required to send a signed acknowledgement back. Because a node is considered cooperative if and only if the node has a signed acknowledgement from its successor, it is important for an intermediate node to stimulate its successor by paying certain money to its successor for sending the signed acknowledgement.
B. How to Pay the Bill?
As mentioned before, intermediate nodes should be motivated to cooperate in a dynamic and distributed environment. In particular, a sender knows the receiver, but it does not know the route to the receiver. The sender should give rewards to the intermediate nodes who help transmit the message. Cooperative nodes can be divided into two types: negative cooperative nodes who help transmit the data but the receiver fails to receive the data, and positive cooperative nodes who help transmit the data and the receiver does successfully receive the data. In our consideration, the sender only pays back the positive cooperative nodes.
In our model, the sender employs the Blockchain P2P system to pay back the positive cooperative nodes. The workflow of the payment consists of three steps. In the first step, the sender publicizes a transmission task and makes a certain deposit that is used to pay back the positive cooperative nodes. In the second step, the sender transmits data to the receiver by opportunistic connections. In the last step, the positive cooperative nodes get their payments. For simplicity, we first discuss the case with only one positive cooperative node; then extend our scheme to the multiple positive cooperative node case.
1) One Positive Cooperative Node
Suppose that a sender
Publishing a Transmission Task: When
wants to transmit data toA , it first generates two random numbersE andR_{1} , whereR_{2} is used to prove that the node in the next hop receives the data correctly, andR_{1} is used to prove that the receiver gets the data successfully.R_{2} keepsA andR_{1} secret, and publishesR_{2} ,{h_{1}} = {E_{P{K_{A}}}}({R_{1}}) . Then{h_{2}} = H({R_{2}}) makes a deposit to commit that it will give rewards toA ifB successfully transmits the data to the receiverB .E constructs a transactionA as shown in Fig. 3.Deposi{t_{A}} Data Transmission: As illustrated in Fig. 4,
first sends the messageA to nodem||{E_{P{K_{E}}}}({R_{2}})||\sigma ||Si{g_{S{K_{A}}}}({R_{1}}) , whereB is a signature on{\sigma } . At the same time,H(m)||{E_{P{K_{E}}}}({R_{2}}) constructs a transactionA and broadcasts it to other nodes in the Blockchain P2P network for validation. Then,Paymen{t_{A \to B}} sends the messageB to the receiverm||{E_{P{K_{E}}}}({R_{2}})||{\sigma } , constructs a transactionE and broadcasts it to the Blockchain P2P network. Finally,Paymen{t_{B \to E}} receives the message, verifies the signatureE , and sends{\sigma } a signed acknowledgementB , which is encrypted by{E_{P{K_{E}}}}(Si{g_{S{K_{E}}}}(AC{K_{E}})) ’s public keyB . Note that the transactionsPK_{B} andPaymen{t_{A \to B}} represent a commitment that coins will be transferred only after the miners have verified them. The transactions in the data transmission are illustrated in Fig. 5.Paymen{t_{B \to E}} Obtaining the Payments: To redeem the rewards,
andB provide miners withE and\{{E_{P{K_{B}}}}({ACK_{E}}),{E_{P{K_{B}}}}({R_{1}})\} , respectively. Then, the miners validate the transactions.\{R_{2},{E_{P{K_{E}}}}({ACK_{E}})\} andB can get the rewards if and only if the following conditions are satisfied: (a)E can provide the random numberE , which is verified byR_{2} \begin{equation*} H(R_{2})=h_{2}; \end{equation*} View Source\begin{equation*} H(R_{2})=h_{2}; \end{equation*}
can provide the random numberB , which is verified byR_{1} \begin{equation*} {E_{P{K_{B}}}}({h_{1}}) = {E_{P{K_{A}}}}({E_{P{K_{B}}}}(R_{1})); \end{equation*} View Source\begin{equation*} {E_{P{K_{B}}}}({h_{1}}) = {E_{P{K_{A}}}}({E_{P{K_{B}}}}(R_{1})); \end{equation*}
can provide the correct signed acknowledgement, which is verified byB \begin{equation*} {E_{P{K_{B}}}}({E_{P{K_{E}}}}(AC{K_{E}})) = {E_{P{K_{E}}}}({E_{P{K_{B}}}}(AC{K_{E}})). \end{equation*} View Source\begin{equation*} {E_{P{K_{B}}}}({E_{P{K_{E}}}}(AC{K_{E}})) = {E_{P{K_{E}}}}({E_{P{K_{B}}}}(AC{K_{E}})). \end{equation*}
2) Multiple Positive Cooperative Nodes
In this section, we extend our scheme to a more complex case where there are multiple positive cooperative nodes. Suppose that a sender
Publishing a Transmission Task:
announces a taskA and generates two random numbersA\! \to \! E:m andR_{1} that should be kept secret. ThenR_{2} makes a deposit to commit that it will give the rewards to the positive cooperative nodes if the message is successfully delivered to the receiverA ; otherwiseE would get the deposit back. The transcript of the transaction is shown in Fig. 6.A Data Transmission: The process of the data transmission from
toA is illustrated in Fig. 7.E first sends the messageA tom||{E_{P{K_{E}}}}({R_{2}})||\sigma ||Si{g_{S{K_{A}}}}({R_{1}}) , and constructs a transactionB . Then,Paymen{t_{A \to B}} ,B , andC helpD transmit the messageA to the receiverm||{E_{P{K_{E}}}}({R_{2}})||{\sigma } , and construct transactionsE ,Paymen{t_{B \to C}} , andPaymen{t_{C \to D}} , respectively.Paymen{t_{D \to E}} ,C , andD send the signed encrypted acknowledgement back toE ,B , andC , respectively. Note that the transactionsD ,Paymen{t_{A \to B}} ,Paymen{t_{B \to C}} , andPaymen{t_{C \to D}} represent a commitment that coins will be transferred only after the miners have verified them. The Blockchain transactions in the data transmission are illustrated in Fig. 8.Paymen{t_{D \to E}} Obtaining the Payments: After the data is successfully delivered to the receiver, all the positive cooperative nodes should get the rewards by providing the miners with the proofs that they did help transmit the data. To be more specific,
providesB ;\{{E_{P{K_{B}}}}({R_{1}}),{E_{P{K_{B}}}}({ACK_{C}}),PK_{A},PK_{C}\} providesC ;\{{E_{P{K_{C}}}}({ACK_{C}}),{E_{P{K_{C}}}}({ACK_{D}}),PK_{D}\} providesD ; and\{{E_{P{K_{D}}}}({ACK_{D}}),{E_{P{K_{D}}}}({ACK_{E}}),PK_{E}\} providesE . The transactions are considered to be valid if and only if the following conditions are satisfied: (a)\{R_{2},{E_{P{K_{E}}}}({ACK_{E}})\} can provide the random numberE , which is verified byR_{2} \begin{equation*} H(R_{2})=h_{2}; \end{equation*} View Source\begin{equation*} H(R_{2})=h_{2}; \end{equation*}
There is a route from
toA , and the route can be determined by the transaction chain fromE toA , as shown in Fig. 9.E can provide the random numberB , which can be verified byR_{1} \begin{equation*} {E_{P{K_{B}}}}({h_{1}}) = {E_{P{K_{A}}}}({E_{P{K_{B}}}}(R_{1})); \end{equation*} View Source\begin{equation*} {E_{P{K_{B}}}}({h_{1}}) = {E_{P{K_{A}}}}({E_{P{K_{B}}}}(R_{1})); \end{equation*}
can provide the correct signed acknowledgements, which are verified byB,C,D \begin{align*} {E_{P{K_{B}}}}({E_{P{K_{C}}}}(AC{K_{C}}))=&{E_{P{K_{C}}}}({E_{P{K_{B}}}}(AC{K_{C}})),\\ {E_{P{K_{C}}}}({E_{P{K_{D}}}}(AC{K_{D}}))=&{E_{P{K_{D}}}}({E_{P{K_{C}}}}(AC{K_{D}})),\\ {E_{P{K_{D}}}}({E_{P{K_{E}}}}(AC{K_{E}}))=&{E_{P{K_{E}}}}({E_{P{K_{D}}}}(AC{K_{E}})). \end{align*} View Source\begin{align*} {E_{P{K_{B}}}}({E_{P{K_{C}}}}(AC{K_{C}}))=&{E_{P{K_{C}}}}({E_{P{K_{B}}}}(AC{K_{C}})),\\ {E_{P{K_{C}}}}({E_{P{K_{D}}}}(AC{K_{D}}))=&{E_{P{K_{D}}}}({E_{P{K_{C}}}}(AC{K_{D}})),\\ {E_{P{K_{D}}}}({E_{P{K_{E}}}}(AC{K_{E}}))=&{E_{P{K_{E}}}}({E_{P{K_{D}}}}(AC{K_{E}})). \end{align*}
C. How Much Should the Payers Pay?
A sender should determine the payment to the positive cooperative nodes for their help to transmit its data, and each positive cooperative node needs to determine the payment to its successor for sending the signed acknowledgement. Instead of considering the two components separately, we consider the final payment to the positive cooperative nodes and the receiver. Without loss of generality, we assume that \begin{equation*} {p_{i}}=\!\begin{cases} \alpha /{2^{n - 1}}, & {\mbox {if }} i\in P, \\ \beta, & {\mbox {if }} i=E,\\ 0,& {\mbox {otherwise. }} \end{cases} \end{equation*}
Note that in our implementation,
D. Is it Secure?
1) Cheating Behaviors of the Participants
Since selfish mobile nodes always try to maximize their utilities, they may cheat. For example, they can act as a miner to get more information from the Blockchain transactions and then launch sophisticated attacks. In particular, a receiver may have one of the three selfish actions: i) it does not send back a signed acknowledgement to its previous node or just simply sends the acknowledge to others; ii) it does not provide the validation information or provides a bogus validation information; and iii.a) it does not receive the data but falsely claims that it has received the data. An intermediate node can have another cheating behavior except the first two selfish actions mentioned above: iii.b) it does not help with transmitting the data but falsely claims that it has transmitted the data.
Note that any of the selfish actions mentioned above can be further complicated by the collusion of two or more nodes. We assume that collusion only occurs between neighbors. This is a reasonable assumption in opportunistic transmissions because a node hardly gets in contact with a non-neighbor node. Moreover, we can add a lock-time into each payment transaction, which makes it more difficult for a node to contact its non-neighbors. We consider two kinds of collusion attacks:
A receiver colludes with its neighbors. The receiver and its neighbors can forge a bogus path from the sender to the receiver. For example, suppose that the true path is
. After receiving the data fromA \to B \to C \to D \to E ,D does not send the signed acknowledgement toE , or it does not provide the validation information. Instead,D chooses some nodes from its neighbors to create a bogus path, i.e.,E .A \to E_{1} \to E_{2} \to E_{3} \to E An intermediate node colludes with its neighbors. The intermediate node collude with its neighbors to extend or shorten the path. As shown in Fig. 10,
can choose some nodes from its neighbors to create a bogus pathB , orA \to B \to B_{1} \to B_{2} \to B_{3} \to C \to D \to E colludes withB to shorten the path to obtain a new pathC .A \to B \to D \to E
2) Data-Transmission Game
To study the security of our incentive mechanism, we employ a static game to analyze the cooperative behaviors of the intermediate nodes. Through the Nash equilibrium results of the game, we can obtain the best strategies of the players under different pricing strategies. By setting a suitable pricing strategy, we can guarantee the security of our incentive mechanism against the selfish behaviors of the users and the collusion attacks. The model of the data-transmission game is described as follows.
a: Players
This game has
b: Strategies
Each player
c: Utilities
Player \begin{equation*} {u_{i}} = {\begin{cases} \alpha /{2^{n - 1}} - {c_{i}}, & i \in P ~{\mbox {and }} {s_{i}} = Honest,\\ \beta - {c_{E}}, & i = E ~{\mbox {and }}{s_{i}} = Honest,\\ 0, & i \in P ~{\mbox {and }} {s_{i}} = Selfish,\\ 0, & i = E ~{\mbox {and }}{s_{i}} = Selfish. \end{cases}} \end{equation*}
When player
Definition 1:
The best response strategy for a player is a strategy that brings the maximum expected utility to itself, regardless of the strategies of all other players.
To meet the security requirement, we need to design an incentive mechanism to discourage playing selfishly. In other words, we should make sure that
Definition 2:
An incentive mechanism is receiver-collusion-resistant if the receiver and any group of its colluding neighbors cannot increase the expected sum of their utilities by using any strategy profile other than the one in which everybody plays honestly.
Definition 3:
An incentive mechanism is intermediate-node-collusion-resistant, if any group of colluding intermediate nodes cannot increase the expected sum of their utilities by using any strategy profile other than the one in which everybody plays honestly.
Definition 4:
An incentive mechanism is secure if
Security Analysis and Utility Evaluation
A. Security Analysis Without Collusion Attacks
Theorem 1:
In the data-transmission game,
Proof:
When player \begin{equation*} {u_{i}} = {\begin{cases} \alpha /{2^{n - 1}} - {c_{i}}, & i \in P,\\ \beta - {c_{E}}, & i = E. \end{cases}} \end{equation*}
(orE ) does not send the acknowledgement to its previous nodeP_{i} (P_{n} ) or simply sends it to another node. IfP_{i-1} (E ) does not sendP_{i} ({E_{P{K_{n}}}}(Si{g_{S{K_{E}}}}(AC{K_{E}})) ) to{E_{P{K_{i-1}}}}(Si{g_{S{K_{i}}}}(AC{K_{i}})) (P_{n} ),P_{i-1} (P_{n} ) will not provide the validation information; thusP_{i-1} (E ) can not get the payment from the transactionP_{i} (Paymen{t_{P_{n} \to E}} ). IfPaymen{t_{{P_{i-1}} \to P_{i}}} (E ) sends the acknowledgement to another node, the node can not provide the validation information ofP_{i} (P_{n} ) becauseP_{i-1} (P_{n} ) keeps its acknowledgement secret by encryption, i.e.,P_{i-1} ({E_{P{K_{n}}}}(AC{K_{n}}) ). Thus,{E_{P{K_{i-1}}}}(AC{K_{i-1}}) (E ) can not get the payment.P_{i} (orE ) does not provide validation information or provides a bogus validation information. IfP_{i} (E ) does not provide the validation information,P_{i} (E ) can not get the payment fromP_{i} (Paymen{t_{P_{n} \to E}} ). IfPaymen{t_{{P_{i-1}} \to P_{i}}} (E ) provides a bogus validation information, the transactionsP_{i} (Paymen{t_{A \to {P_{1}}}} ) andPaymen{t_{{P_{i - 2}} \to {P_{i-1}}}} (Paymen{t_{{P_{n - 1}} \to {P_{n}}}} ) can not be verified. Thus,Paymen{t_{{P_{i - 1}} \to {P_{i}}}} (E ) can not get the payment.P_{i} (orE ) does not receive the data but falsely claims that it has received the data. IfP_{i} (E ) does not receive the data,P_{i} can not provideE , then the transactionR_{1} can not be verified. ThusPaymen{t_{A \to {P_{1}}}} (E ) can not get the payment. In addition, if the data is important toP_{i} , cheating will damage its benefit.E
As
B. Security Analysis With Collusion Attacks
We first consider the case when
Theorem 2:
Our incentive mechanism is receiver-collusion-resistant if
Proof:
We first consider the case with one conspired node; then we extend to the case of multiple conspired nodes.
Case 1:
Suppose
is a collusion group.G=\{E,E_{1}\} forges a bogus path with one positive cooperative node, i.e.,G . LetA \to E_{1} \to E denote the expected sum of the utility ofE(u_{G}) . Our goal is to show thatG \begin{equation*} E(u_{G})\le u_{E}. \end{equation*} View Source\begin{equation*} E(u_{G})\le u_{E}. \end{equation*}
If
getsE_{1} ,R_{1} andE can get the payment fromE_{1} , which means thatA has encountered bothE_{1} andE (with a probability ofA ). The expected sum of the payment ofq^{2} isG . Considering the cost ofp_{G} = {q^{2}}(\alpha + \beta) + (1 - {q^{2}})\beta ={q^{2}}\alpha +\beta to provide the validation information and to communicate withE_{1} , we have the expected sum of the utility ofE to beG . Thus we obtainu_{G}={q^{2}}\alpha +\beta -\beta -c_{E}= {q^{2}}\alpha -c_{E} .{u_{G}}={q^{2}}\alpha -c_{E}<\beta -c_{E}=u_{E} Case 2:
Suppose
is a collusion group.G=\{E,E_{1}, \ldots,E_{n}\} forges a bogus path with multiple positive cooperative nodes, i.e.,G . LetA \to E_{1} \to \cdots \to E_{n} \to E denote the expected sum of the utility ofE(u_{G}) . Our goal is to show thatG \begin{equation*} E(u_{G})\le u_{E}. \end{equation*} View Source\begin{equation*} E(u_{G})\le u_{E}. \end{equation*}
When
encounter each other,(A,E_{1}),(E_{1},E2),\ldots,(E_{n},E) gets the payment. The expected sum of the payment ofG isG Deducting the cost of\begin{align*} p_{G}=&{q^{n + 1}}(n\alpha /{2^{n - 1}} + \beta) + (1 - {q^{n + 1}})\beta \\=&{q^{n + 1}}n\alpha /{2^{n - 1}} + \beta. \end{align*} View Source\begin{align*} p_{G}=&{q^{n + 1}}(n\alpha /{2^{n - 1}} + \beta) + (1 - {q^{n + 1}})\beta \\=&{q^{n + 1}}n\alpha /{2^{n - 1}} + \beta. \end{align*}
, we have the expected sum of the utility ofG :G As\begin{equation*} u_{G} = {q^{n + 1}}n\alpha /{2^{n - 1}} + \beta - n\beta -c_{E}. \end{equation*} View Source\begin{equation*} u_{G} = {q^{n + 1}}n\alpha /{2^{n - 1}} + \beta - n\beta -c_{E}. \end{equation*}
, we have\alpha < \beta /{q^{2}} \begin{align*} {u_{G}}=&{q^{n + 1}}n\alpha /{2^{n - 1}} + \beta - n\beta -c_{E} \\<&\frac {{{q^{n + 1}}n\beta }}{{{2^{n - 1}}{q^{2}}}} - n\beta + \beta -c_{E} \\=&({q^{n - 1}}/{2^{n - 1}} - 1)n\beta + \beta -c_{E} \\<&\beta -c_{E}=u_{E}. \end{align*} View Source\begin{align*} {u_{G}}=&{q^{n + 1}}n\alpha /{2^{n - 1}} + \beta - n\beta -c_{E} \\<&\frac {{{q^{n + 1}}n\beta }}{{{2^{n - 1}}{q^{2}}}} - n\beta + \beta -c_{E} \\=&({q^{n - 1}}/{2^{n - 1}} - 1)n\beta + \beta -c_{E} \\<&\beta -c_{E}=u_{E}. \end{align*}
Therefore, if
Theorem 3:
Our incentive mechanism is intermediate-node-collusion-resistant.
Proof:
An intermediate node can collude with its neighbors to extend or shorten the path.
Case 1:
An intermediate node colludes with its neighbors to extend the path. We first Consider the case with one positive cooperative node
. LetA \to B \to E be the collusion group.G=\{B,B_{1},\ldots,B_{n}\} extends the path toG . LetA \to B \to B_{1} \to \cdots \to B_{n} \to E denote the expected sum of utility ofE(u_{G}) . Our goal is to show thatG where\begin{equation*} E(u_{G}) \le u_{B}, \end{equation*} View Source\begin{equation*} E(u_{G}) \le u_{B}, \end{equation*}
is the utility ofu_{B} to play honestly. AsB indeed helpedB transmit data toA , it can get all the needed validation information fromE andA , which means thatE can always launch a successful collusion attack. According to our pricing scheme, we haveB Let\begin{align*} E(u_{G})=&(n + 1)\alpha /{2^{n}} - {c_{B}}; \\ {u_{B}}=&\alpha - {c_{B}}. \end{align*} View Source\begin{align*} E(u_{G})=&(n + 1)\alpha /{2^{n}} - {c_{B}}; \\ {u_{B}}=&\alpha - {c_{B}}. \end{align*}
. We havef(x) = (x + 1)/{2^{x}},\;x \ge 1 . Thus,f'(x) = {2^{ - x}}(1 - (1 + x)x) < 0 is a monotonically decreasing function. Accordingly we havef(x) . It is easy to see thatf(n) < f(n - 1) < \ldots < f(1) Now we consider the case with multiple positive cooperative nodes. Let\begin{equation*} E(u_{G}) = (n + 1)\alpha /{2^{n}} - {c_{B}} <\alpha - {c_{B}}=u_{B}. \end{equation*} View Source\begin{equation*} E(u_{G}) = (n + 1)\alpha /{2^{n}} - {c_{B}} <\alpha - {c_{B}}=u_{B}. \end{equation*}
. We can deduce thatu_{B}=\alpha ' - {c_{B}} \begin{equation*} E(u_{G}) = (n + 1)\alpha ' /{2^{n}} - {c_{B}} <\alpha ' - {c_{B}}=u_{B}. \end{equation*} View Source\begin{equation*} E(u_{G}) = (n + 1)\alpha ' /{2^{n}} - {c_{B}} <\alpha ' - {c_{B}}=u_{B}. \end{equation*}
Case 2
An intermediate node colludes with its neighbors to shorten the path
. LetA \to P_{1} \to \cdots \to P_{i} \to P_{i+1} \to \cdots \to P_{n} \to E be a collusion group. ThenG=\{P_{i},P_{i+1}\} shortens the path toG . LetA \to P_{1} \to \cdots \to P_{i} \to P_{i+2} \to \cdots \to P_{n} \to E denote the expected sum of the utility ofE(u_{G}) . Our goal is to show thatG where\begin{equation*} E(u_{G}) \le u_{P_{i}}+u_{P_{i+1}}, \end{equation*} View Source\begin{equation*} E(u_{G}) \le u_{P_{i}}+u_{P_{i+1}}, \end{equation*}
andu_{P_{i}} are respectively the utilities ofu_{P_{i+1}} andP_{i} to play honestly. AsP_{i+1} andP_{i} indeed helped transmit the data, they can get all the needed validation information. Thus they can launch a successful collusion attack. According to our pricing scheme, we haveP_{i+1} It is easy to see that\begin{align*} E({u_{G}})=&\alpha /{2^{n - 2}} - {c_{P_{i}}} - {c_{{P_{i + 1}}}}; \\ {u_{P_{i}}}=&\alpha /{2^{n - 1}} - {c_{P_{i}}}; \\ {u_{{P_{i + 1}}}}=&\alpha /{2^{n - 1}} - {c_{{P_{i + 1}}}}. \end{align*} View Source\begin{align*} E({u_{G}})=&\alpha /{2^{n - 2}} - {c_{P_{i}}} - {c_{{P_{i + 1}}}}; \\ {u_{P_{i}}}=&\alpha /{2^{n - 1}} - {c_{P_{i}}}; \\ {u_{{P_{i + 1}}}}=&\alpha /{2^{n - 1}} - {c_{{P_{i + 1}}}}. \end{align*}
\begin{equation*} E(u_{G}) = u_{P_{i}}+u_{P_{i+1}}. \end{equation*} View Source\begin{equation*} E(u_{G}) = u_{P_{i}}+u_{P_{i+1}}. \end{equation*}
Therefore, our incentive mechanism is intermediate-node-collusion-resistant.
The three theorems together prove the following theorem.
Theorem 4:
Our incentive mechanism is secure if
C. Evaluation
1) Overhead
We employ a laptop computer with an Intel Core i7-2640M Processor (4MB Cache, up to 2.8GHz) to implement a prototype of our system using the Crypto++5.62 library and consider a path of 5 hops, to evaluate the overhead of our incentive mechanism. The OS of the laptop is Windows 10 Pro 64. The length of a message payload is 1024 bytes, and the message digest function is MD-5. We consider three commutative encryption schemes: ElGamal with a modulus of 1024 bits, RSA with a modulus of 1024 bits, and RSA with a modulus of 3072 bits.
We first evaluate the CPU processing time. In our incentive system, the major processing overhead is the R2 encryption operation, the message and R1 signing operations, and the transaction generating operation by the sender, the ACK signing and encryption operation (or the R1 decryption operation) and the transaction generating operation by each intermediate node, the message verification operation, the R2 decryption operation, and the ACK signing and encryption operation by the receiver, and the verification operation by the miners. The columns of Table 1 report the CPU processing time of the sender, an intermediate node (average), the receiver, and a miner. We observe that RSA has a much smaller overhead. Therefore if reducing overhead is the major objective, RSA is a better implementation choice. Compared with the scheme proposed by Zhu et al. [22], the CPU processing time of the sender in our approach is slightly larger, the average CPU processing time of the intermediate node is slightly smaller, and the CPU processing time of the receiver is smaller.
We next evaluate the bandwidth and storage requirements. Compared with the opportunistic routing protocols introduced in [37] and [38] but without any incentive mechanism, the major increased message overhead includes the encrypted R2, the signed R1, and the signed and encrypted ACK. For ElGamal and RSA with a modulus of 1024 bits, the encrypted R2 takes about 128 bytes, the signed R1 takes about 128 bytes, the signed and encrypted ACK takes about 128 bytes; for RSA 3074 bits, the encrypted R2 takes about 384 bytes, the signed R1 takes about 384 bytes, and the signed and encrypted ACK takes about 384 bytes. The storage requirement for the Blockchain transactions is analyzed as follows. For RSA 1024 and ElGamal 1024, each transaction requires at least 1 byte for the previous transaction reference, 128 bytes for the in-script, 1 byte for the Bitcoin value, and 128 bytes for out-script; adding up together we get 258 bytes for a minimum-sized Bitcoin transaction. For RSA 3074, each transaction requires 384 bytes for the in-script and 384 byes for the out-script, resulting in a 770-byte minimum-sized Bicoin transaction. Note that the process of miners verifying the transactions does not affect the cost of the routing protocols, and the throughput of processing the transaction is determined by Blockchain consensus algorithm [12].
2) Utility Evaluation
In this section we evaluate the utilities of the players under different strategies. We set
a: Utility of a Positive Cooperative Node
Fig. 12 shows the impact of the number of positive cooperative nodes and the playing strategies on the utility of a positive cooperative node. We observe that the node’s utility indeed demonstrates diminishing returns when the number of positive cooperative nodes increases. Extending the length of the path (
b: Utility of the receiver
Fig. 12 shows the impact of the encounter probability and the playing strategies on the utility of
Conclusion and Future Research
In this paper, we propose a Blockchain based incentive mechanism that can meet the diverse requirements in a dynamic and distributed P2P environment. In our incentive mechanism, intermediate nodes who contribute to a successful delivery can obtain rewards from Blockchain transactions. The transactions are verified by the miners in a secure way by using commutative encryptions. A pricing strategy is proposed to guarantee the security of our incentive mechanism. We also employ a static game model to demonstrate the security strength of our incentive mechanism.
In our future research, we will consider the issue of a sender colluding with its receiver. One possible solution is to introduce reputation into our incentive scheme. In this reputation based incentive scheme, the collusion group of the sender and the receiver will be put into a blacklist by the accusation of the intermediate nodes. We also will consider the contradiction of incentive and privacy in our scheme. We will bring certain cryptographic extensions such as zero-knowledge proof and blind signature to Blockchain for achieving fully anonymous currency transactions.