An Efficient Permissioned Blockchain Model with Provable Reputation Mechanism

02/17/2020 ∙ by Hongyin Chen, et al. ∙ Shanghai Jiao Tong University Peking University 0

Permissioned blockchain, in which only known nodes are allowed to participate, has been widely used by governments, companies, institutes and so on. We study the case where permissioned blockchain is applied to the field of horizontal strategic alliances to ensure that any participant of the alliance who does not follow the regulation will be detected and punished for his behavior afterward. We propose a general hierarchical model of permissioned blockchain which includes three tiers: providers, collectors, and governors. To utilize the overlap of collectors in gathering transactions from providers, we introduce the reputation as a measure of the reliability of the collectors. With the help of reputation system, governors will not need to check all transactions uploaded by collectors. As a result, our protocol will have a significant improvement in efficiency. Meanwhile, let us denote T to be the number of total transactions. Then the number of mistakes that governors suffer is only asymptotically O(√(T)) when guided by our reputation mechanism, as long as there exists a collector who behaves well. This result implies that our protocol remains high performance. The reputation mechanism also provides incentives for collectors to work honestly. To our knowledge, Our work is the first one to give an analytical result on reputation mechanism in permissioned blockchains. Furthermore, we demonstrate two typical cases where our model can be well applied to.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

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

In recent years, the popularity of blockchain technology increases massively. Combined with traditional techniques, numerous blockchain projects have been implemented in both permissionless and permissioned environments. The most significant difference between permissionless and permissioned blockchains is whether the identity of a participant is acknowledged. Most widely known blockchain schemes, including Bitcoin [30], Ethereum [6], and Litecoin [24], are permissionless architectures. They work in an open ecosystem, where anyone is allowed to join as a validator without authorization. On the other hand, permissioned blockchains are relatively closed and only allow known nodes to access. These structures are practical for governments, companies, and institutes that are regulated.

An application scenario of the permissioned blockchain is the horizontal strategic alliance where multiple companies ally for mutual benefits. Some companies in the same area may ally to reduce competition costs and improve customer service. However, companies in a horizontal strategic alliance may not be fully trustful to each other since each company has its private benefits. Using of permissioned blockchain reduces the need for such reliance thus would fit in such circumstances.

In this paper, we propose a permissioned blockchain model in a hierarchical structure. There are three kinds of nodes: providers, collectors and governors respectively. Providers offer transactions to collectors. After labeling the transactions they received, collectors forward them to governors. Governors are responsible for validating transactions, proposing blocks, and maintaining the ledger. However, due to the efficiency issue, a governor may not check all transactions they receive. Meanwhile, in each round, a leading governor, who is selected via a Proof-of-Stake (PoS) scheme, is in charge of packing transactions in a block and append the block to the end of the ledger.

As with many real-world cases, collectors overlap in gathering transactions from providers. In this sense, it is convenient to apply a reputation mechanism

on the collectors. In our model, each governor maintains a local reputation vector for each collector that reflects the collector’s reliability. Briefly, the vector is composed of three parts. The first part records a collector’s performance on unchecked transactions. Specifically, a governor picks one source for each transaction via this part. The second part shows a collector’s behavior in dealing with checked transactions. The last part reflects whether a collector tends to forge transactions. As the real status of a checked transaction is revealed immediately and a fabricated transaction can be easily discovered with high probability, the last two components of a collector’s reputation are updated in time. For the first part, the reputation is altered when the legality of an unchecked transaction is uncovered, e.g., when a provider argues on the validity of an unchecked transaction.

We use a parameter to tune the proportion of unchecked transactions. The larger is, the less probability a transaction is checked, thus the faster the execution of the protocol would be. In the meantime, when is , we prove that with our reputation mechanism, the governor’s expected amount of mistakes on unchecked transactions is asymptotically the square root of the number of total transactions with overwhelming probability when there exists a well-behaved collector. This result shows that the protocol remains high performance concerning high efficiency. To our knowledge, our work is the first one that gives an analytical result on reputation mechanism in permissioned blockchains. Our reputation mechanism also provides incentives for collectors to work as instructed by relating a collector’s profit with his reputation. In total, our reputation mechanism combines performance, efficiency, and incentives altogether.

We also demonstrate the feasibility of our model by applying it to the case of car-sharing and insurance. In a word, we believe our model solves many issues in the field of designing reputation mechanisms in permissioned blockchains.

The rest of the paper is arranged as the following: Section 2 introduces the background of our model and some related works. In Section 3, we build our model and describe the main protocol. We give a full analysis of our model in Section 4 and apply our model to real-world cases in Section 5. We conclude our work in Section 6.

2 Background and Related Work

2.1 Horizontal Strategic Alliances

The strategic alliance is an agreement between two or more companies to pursue mutual benefits [12]. A vertical strategic alliance [37], like the supply chain, forms as a supplier-producer cooperative relation to enlarging the company’s network to be able to offer a lower price. Some companies in the same areas also establish a strategic alliance for some specific purposes to reduce costs and improve customer service. The strategic alliance above is called a horizontal strategic alliance [38]. A horizontal alliance is usually managed by a team with members from each company and bounded by an agreement giving an equal risk and opportunity.

In a horizontal strategic alliance, companies unite for a common interest. Although they are all trustful that they won’t tolerate actions that may harm the alliance, someone may conceal information for some reason. The alliance members share customers, while they still need an intermediary as a customer acquisition channel. However, intermediaries are not reliable enough that they may deceive companies about customers and transactions. For such a three-tier structure of customers, intermediaries, and companies, customers serve as data providers who generate and provide transactions, intermediaries are a response to collecting, verifying, and submitting transactions. Meanwhile, companies perform reliant governors in this hierarchy.

2.2 Consensus in Permissioned Blockchains

Compared with permissionless blockchains focusing on public environments where every node may arbitrarily enter or leave the network, permissioned blockchains are operated by known entities. These systems maintain the identity and status of participants. For example, in consortium blockchains, members of a consortium or in business manage a permissioned blockchain network. Meanwhile, in private blockchains, only one trusted entity is in charge of the chain [8].

Various permissioned blockchain schemes have appeared and already been implemented in practice. Up to v0.6 of Hyperledger Fabric [16], a native PBFT [9] is implemented. In the newest version, an execute-order-validate architecture, rather than the traditional order-execute one, was introduced to carry out the modularity of the protocol. Such a design reduces the need for hard-coding the consensus protocol into the platform and enables Fabric to fit into different circumstances [1]. For example, besides the traditional PBFT, BFT-SMaRt [4] is also realized as a consensus module. The latter is now considered as one of the most advanced implementations of BFT available. The core consensus scheme lying in Tendermint Core [11] is a variation of PBFT which also resists

Byzantine nodes. However, Tendermint’s most momentous difference from PBFT is the continuous rotation of the leader. Namely, the leader is changed after every block. R3 Corda 

[10] realizes a Hashed Directed Acyclic Graph (Hash-DAG) instead of a chain. A transaction is only stored by those nodes who are affected by the transaction, that is, a node only stores a part of the Hash-DAG. When implemented with Raft [32], R3 Corda tolerates half of the nodes’ crashing. The protocol is secure with nodes acting arbitrarily when implemented with BFT-SMaRt, as stated before. Quorum [34] supports a consensus scheme known as QuorumChain which specifies never-crash-nor-subvert block-maker nodes who are permitted to propose blocks. The scheme guarantees safety and liveness with arbitrary-fault nodes and one block-maker. (The chain may fork with multiple block-makers.) Other platforms include Ripple [35], Multichain [29], etc..

Besides, beyond traditional BFT algorithms, several fresh consensus models were proposed in recent years, which are considered more suitable for permissioned blockchains. Proof-of-Authority (PoA) [2], as a new family of BFT algorithms, requires fewer message exchanges hence provides better performance. Meanwhile, a new message-based consensus scheme named as Proof-of-Authentication (PoAh) [33] was presented just a few months ago, which is a lightweight and sustainable permissioned blockchain.

2.3 Reputation Mechanisms

Reputation in the Peer-to-Peer (P2P) networks has been studied for decades. As the name suggests, reputation works as a measure of the peer’s reliability and is evaluated according to his historical behaviors. Various topics related to reputation research, such as the systems design [19] [41], security issue [5] [21] and privacy protection [23] [39] have been deeply studied in the literature. In recent years, the emergence and development of blockchain technology bring some new thoughts to the research of reputation. The existing works mainly focus on the following two aspects.

First, because of blockchain’s immutability and decentralization, some researches utilize it as a wonderful tool to establish the reputation system [14] [15] [36]. For example, [17] uses the permissioned blockchain to store the transactional history, which is regarded as the reputation evidence. Then all registered participants’ reputation can be evaluated distributedly. Instead of adopting traditional consensus protocols like Proof-of-Work (PoW) and Proof-of-Stake (PoS) in the process of block generation, the proposed system in  [17] presents a new protocol called Proof-of-Reputation (PoR). The protocol assigns one of the nodes involved in the current block, who has the highest reputation value, to be the leader of the current round. Participants all believe that the node with a higher reputation value could provide better services. As a result of taking full advantage of the reputation, the PoR protocol performs efficiently in the designed system.

Second, some studies have applied the concept of reputation as an incentive to the blockchain applications. Our work falls into this research area.  [31] proposes a reputation-based framework for blockchain systems which use PoW as their consensus protocol, to avoid dishonest mining strategies. In the framework, each node has a public reputation value, representing how well he has so far performed in the system. When the pool manager sends invitations to miners to form his mining pool for the proof-of-work computation, one’s probability to be invited is related to his reputation value. Nodes who are more reputable have a higher chance to be invited into the mining pools and consequently gain more revenue. Since this public reputation system is sustained over time, miners are incentivized to behave honestly to maximize their long-term utility. However, this paper only lists several possible influence factors and analyzes the update of reputation values qualitatively. The concrete forms of update function and probability function are absent. [40]

presents a protocol called CycLedger for the sharding-based blockchain, which introduces the concept of reputation to provide nodes with enough incentive to enter the system. Nodes in the system are required to give opinions on the validity of requested transactions. One’s reputation is computed according to the cosine similarity between his opinions and the consensus results. In this way, the node’s reputation is a good reflection of the honest computational resources he has contributed to the system. By assigning nodes with more computational resources to high-workload positions, the efficiency is further enhanced. Also, as a higher reputation brings more revenue, the protocol attracts nodes to participate actively and honestly in the system.

3 Architecture

3.1 Model Overview

Since our protocol implements a permissioned blockchain, the identities of nodes in the network need to be maintained. Specifically, in our protocol, an Identity Manager (IM) is responsible for recording the members of the chain as well as their roles. Meanwhile, it is in charge of providing nodes credentials that are used for authenticating and authorizing. As a default, an IM should contain all standard Public-Key Infrastructure (PKI) methods and play the role of a Certificate Authority (CA). Concretely, all interactions within the network are authenticated via digital signatures and IM offers each node such a scheme.

In general, the hierarchical model is based on three types of agents:

  • Providers would provide transactions for collectors. They do not need to supply valid transactions, however, they sign on transactions together with the timestamp so that no collector could forge a transaction.

  • Collectors are responsible for collecting, verifying, and uploading transactions. Specifically, after receiving a signed transaction from a provider, a collector would check it and label it. For each transaction, a collector can label either or , for which implies that the transaction is considered to be valid and otherwise. After a while, collectors would submit the transactions with their corresponding labels and their signatures to governors (both valid and invalid ones).

  • Governors maintain the state of the network and are responsible for the chain. For each of them, the main goal is to perceive as many authenticated transactions as possible. However, governors are not fully trustful to each other. For example, some transactions may harm a governor, thus he is incentivized to conceal these transactions to his collaborators. If a governor is elected as the leader of a round, he will be in charge of collecting all transactions and proposing them in the corresponding block.

Execution of the protocol is partitioned into rounds. There are three phases in each round:

  • Collecting. A transaction offered by a single provider is sent to several collectors.

  • Uploading. Collectors label the received transactions and pack them. These labeled transactions are then uploaded to the governors.

  • Processing. Finally, the governors judge part of the transactions and record those valid ones as well as the unchecked ones in a new block, and append it to the ledger.

As we are dealing with permissioned circumstances, we assume that the system is synchronous. (i.e. There is a known upper bound on processing delays, message transmission delays, each node is equipped with a local physical clock and there is an upper bound on the rate at which any local clock deviates from a global real-time clock [7].) We note that a provider is linked with multiple collectors. Since different collectors may provide different results of the same transaction and some of them may behave maliciously, e.g. reporting different results to different governors or concealing some transactions, governors need to reach a consensus on the recorded transactions in the processing phase. To reduce the cost of evaluating invalid transactions repeatedly, reputation is applied to each collector. Intuitively, a collector’s reputation is a symbol of his reliability. Reputation is also deemed as an incentive mechanism in our protocol.

As a default, a governor has connection with all collectors, however, in real cases, a governor may only perceive partial information. Under such conditions, the structure of the network can be adjusted. For simplicity, we suppose each collector is linked with the same amount of providers, similar for providers. However, we point out that the condition is only for the need of a clear description, i.e., the model can be easily extended to general cases.

We give the following notations to formalize the hierarchy of the model. An illustration of the model can be seen in Figure 1.

Figure 1: Hierarchical model of the network
  • Denote the set of providers by ;

  • Denote the set of collectors by ;

  • Denote the set of governors by ;

  • Suppose each provider submits his transactions to collectors and each collector receives transactions from providers. One can derive that .

  • Suppose each governor maintains a list of reputation values for these collectors . Note that a governor uses a vector to reflect his trust on a collector. Details on the vector will be discussed later.

In each round, a block is appended to the end of a ledger. The block contains transactions signed by the corresponding providers together with their corresponding labels. Note that any block in the ledger is tamper-proof by containing the hash of the previous block in the current one. Moreover, each block has a serial number. The blocks in the chain have one-by-one increasing serial numbers. Formally, a block can be written as , where is the serial number, is the list of signed transactions with labels and is the hash value. Here, is the amount for transactions concluded in the block. There is a universal upper bound on .

For any provider, he can execute an operation to broadcast to the collectors he is linked with. should contain a transaction payload, the current timestamp, as well as the provider’s signature on them, to prevent a collector from fabricating one. Meanwhile, when noticing that a valid transaction is regarded as invalid in block with serial number , he can invoke so that governors will re-evaluate the transaction. If is proved to be valid, then it will be contained in a later block. However, the latency of arguing on a transaction should be no more than transactions, or rounds.

For any collector, he can execute an operation to disseminate to all governors that are in connection with him. should contain a transaction payload, a timestamp, a recorded provider’s signature, a label (e.g. valid or invalid), and the collector’s signature on all of them.

For any governor, he can execute an operation to broadcast to all other governors.

To validate the authenticity of a message , one can invoke in which is the node he receives from. The function will return a when is not sent by (by verifying the signature on ). Meanwhile, if is a collector, the function also returns if does not contain a signature by a provider with which is linked. In other cases, the function returns . Moreover, a node can use to check whether is valid or not.

For each node, he can call to receive the block with serial number . Resembling Hyperledger Fabric [1], our protocol is designed to satisfy the following properties:

  • Agreement: For any two blocks and retrieved with the same serial number , ;

  • Chain Integrity: For any two blocks and , if is retrieved with serial number while is with serial number , then the hash value contained in satisfies , where is a public collision-resistant hash function (CRHF).

  • No Skipping: Once a block with the serial number is retrieved by a node, then blocks with all previous serial numbers (i.e., ) are already retrieved before.

  • Almost No Creation: When an honest node perceives when retrieving a block , then excluding negligible probability of , has been broadcast both via and previously. Here is the security parameter of the protocol.

  • Validity: If an honest and active provider broadcasts a valid transaction , then will appear in a block eventually. Here we call a node active only when he retrieves every block and invokes whenever he finds that some valid transaction he broadcasts is labeled as invalid in a block.

We note that the first four properties are for the safety of the protocol and the last one is for the liveness.

3.2 Collecting Phase

In this phase, data providers will offer transactions to collectors.

Specifically, each data provider generates some transactions, signs on them together with the timestamp to achieve , and then broadcasts them to the collectors he is in connection with by invoking . should implement an atomic broadcast(i.e. total-order broadcast [7]) scheme to prevent the collectors from being confused about the order of these transactions.

3.3 Uploading Phase

In this phase, collectors would process transactions from data providers. Once receiving a transaction, collectors will check the authenticity of the transaction, validate the transaction, and give it a label of or to show the transaction is valid or invalid. Then, for each transaction with its label signed, , the collector would operate to disseminate to all governors he connects to. As above, to reduce unnecessary inconvenience for governors, should implement an atomic broadcast. Concretely, once a collector receives a transaction from data provider , operates . If a is returned, then would simply discard . Otherwise, would check , output a label, sign on them and broadcast it to governors. Algorithm 1 reflecting this step is shown below.

1:procedure Transactions_Uploading For collector
2:     upon  do
3:         if  then
4:              
5:              
6:              invoke               
Algorithm 1 Transactions Uploading

3.4 Processing Phase

In this phase, governors will judge part of the uploaded transactions, record valid and unchecked transactions in a new block, and append the block to the ledger. Then the governors will update the reputation of collectors. Specifically, for a governor , the reputation of collector , , is a -length vector . Here, are the providers that is linked with. The first entries record ’s performance on labeling transactions that are not validated by the governor. reflects ’s behavior on marking transactions that are checked by the governor, and indicates if tries to forge transactions. We introduce three parameters in this phase. is a parameter used for tuning the efficiency of the protocol, are two parameters used when distributing rewards among collectors.

3.4.1 Transaction Screening

In this step, a governor will collect all the transactions in this round and output a list of transactions that have been verified to be valid or not verified.

For simplicity, in the description of this step, we only consider authenticated transactions. In fact, those forged transactions can be discovered easily. Assume a transaction proposed by is broadcast to a group of collectors and their reputations w.r.t are respectively before comes in.

Suppose receives copies of , each with an attached valid bit from different collectors who belong to the set . Here , since some collectors might simply discard this transaction instead of uploading it in the uploading phase. Denote as the sum of reputation of collectors who labeled as valid, invalid and missed uploading respectively.

chooses a collector randomly among those who reported with the probability proportional to his current reputation with respect to . If the valid bit of the chosen transaction is , verifies it. Otherwise, verifies it with probability . Here, is the probability that the collector is chosen. Concretely, where is the collector’s reputation on . Recall that is a parameter used for tuning the efficiency of the protocol. The larger is, the faster the protocol executes, yet the lower the correctness of the governor is.

For each transaction that is verified by , discards it if the validation result is invalid. He outputs all the transactions that are proved to be valid, as well as those transactions that have not yet been verified together with their valid bits with a label . Algorithm 2 shows the execution of the step.

1:procedure Transactions_Screening For governor
2:     upon  do
3:         if  then
4:              
5:              if  then
6:                   start timing               
7:              
8:         else
9:              invoke Update reputation with case number 1               
10:     
11:     upon  do timing is ended
12:         
13:         
14:         
15:         for all collectors  do
16:              
17:                        
18:         draw a collector who reported with probability vector
19:         if  labeled on  then
20:              if  then
21:                   is the current block
22:                  invoke update reputation with case number 2               
23:         else labeled on
24:              toss a 0-1 coin
25:              if the coin returns 1 then
26:                  if  then
27:                        is the current block
28:                       invoke
29:                  else
30:                       invoke                   
31:              else the coin returns 0
32:                                               
33:     
34:     upon  do
35:         
36:         if  then
37:              
38:                        
39:         invoke update reputation with case number 3      
Algorithm 2 Transactions Screening

The function returns the original transaction and the collector’s label on it. Moreover, due to the synchrony of the system as well as the property of the atomic broadcast, we may assume that for any transaction , the interval that the governor receives the first and the last report on is within . The function starts a timing for which will last for time and will invoke when the timing comes to an end. is used to append the latter argument to the end of .

3.4.2 Reputation Updating

For each transaction with an illegal signature, decreases the last entry of the uploader’s reputation with . That is, assume this transaction is uploaded by , then decreases by .

For each transaction that has been validated by the governor, increases the -th entry of reputation of each collector that labeled this transaction correctly. For example, if transaction is verified by to be invalid, then of each collector that labeled with will be increased by . In the meantime, those who reported the opposite label will receive a loss of in the respective entry of their reputations.

For each transaction that has not been verified, will not update reputations relative to it until other evidence proves its validity. (e.g., a provider argues on an unchecked transaction.) Then, each collector’s reputation relative to it will be multiplied by , or , if he labeled correctly, incorrectly or simply discarded respectively. Specifically, assume was collected from provider , then for each collector , if he labeled correctly, would not change ; if he labeled incorrectly, would multiply by ; if he discarded , would multiply by .

The choice of and should satisfies the following inequalities:

where

Here, represents the sum of reputations whose owners labeled rightly, and represents the sum of reputations whose owners labeled wrongly. Specifically, when is proved to be , , , vice versa. Intuitively, when we assume that a mislabeling will cause a loss of to the governor, represents the expected loss of the governor when is unchecked according to Algorithm 2. Readers may notice that is not a fixed value. Despite of that, we claim that for each and , such a exists. In practice, can be chosen as and can be chosen as

Algorithm 3 shows a pseudo-code of the description above. Here, returns the rank of in the set of collectors while returns collector ’s label on transaction .

1:procedure Transactions_Uploading(cn, cl, tx, status) For governor and provider
2:     if  then case number = 1
3:         
4:     else if  then case number = 2
5:         for  do
6:              if  then
7:                  if  then
8:                       
9:                  else
10:                                                                 
11:     else case number = 3
12:         if  then
13:              
14:              
15:         else
16:              
17:                        
18:         
19:         
20:         for  do
21:              if  then
22:                  if  then
23:                                          
24:              else
25:                                               
Algorithm 3 Reputation Updating

3.4.3 Consensus Reaching

A leader is elected in the set of governors each round. The leader selection with governors is under the setting of Proof-of-Stake (PoS), in which the probability that a governor is selected as the leader is proportional to his stake.

Specifically, suppose a governor is with units of stake. In practice, the stake can be money or any reliable form of asset. In round , calculates and broadcasts a hash value with the proof on his own via a Verifiable Random Function (VRF) [27] scheme for each unit of stake. Concretely, for the -th stake unit of , computes

and disseminates them to all other governors by invoking . Again, implements an atomic broadcast primitive.

When a governor receives all the hash value from other governors, he first validates the proof to check whether the hash value is correct. If the verification is passed, the owner of the stake unit with the least hash value becomes the leading governor of this round.

We mentioned that such a design is much unsecured in permissionless settings as the leader of a round is predictable. Self-election mechanisms in permissionless blockchains are much more complicated [18] [22] [13] [3]. However, in a permissioned environment, we may assume that these governors will not perform malicious behaviors rather than hiding transactions. In other words, there is no motivation for them to damage the chain. In this sense, as the VRF scheme ensures pseudorandomness of the hash value, our leader-electing mechanism guarantees pseudorandomness as well, i.e., the probability that a governor is elected as the leader is proportional to the amount of stake he owns.

After the leading governor of round , , finishes creating the transaction list , he will lay the new serial number , , and the hash of the previous block in order to create a new block . The block will then broadcast to all governors via .

When a block is proposed, all valid transactions contained in will be executed. A constant proportion of the profit gained by executing these transactions will be allotted to the collectors according to their reputations. Concretely, collector ’s revenue would be in proportion with , where and are two parameters such that .

Besides, when stakes are transformed among governors, governors related to the transaction should broadcast the signed transaction to all governors. The current leader would then present a stake-transform block at the end of the round via the following 3-step consensus protocol:

  1. Denote the state after the transforming as , which can be obtained by combining the previous stake state and the transactions the leader received this round. would then invoke to broadcast to all governors.

  2. When a non-leading governor delivers the message from the leader, he should verify the message by checking the signature and check the consistency of with the transactions he received. If the message is authenticated and satisfies consistency, he will then send his signature on back to the leader. However, when the message cannot pass the verification, the governor should broadcast the evidence to other governors to expel the current leader. Readers can refer to [40] for details in expelling a leader.

  3. Finally, when the leading governor collects signatures from all governors, he will pack the and the signatures in the block, and broadcast it to all governors.

4 Analysis

In this section, we prove that our protocol satisfies the properties mentioned in 3.1. Meanwhile, we analyze the efficiency of our protocol by discussing the complexity in block generation and the reputation mechanism. Also, we make a discussion on the incentives that the reputation mechanism provides.

4.1 An Analysis of Consensus Reaching

In the consensus reaching process, we use Verifiable random function (VRF) scheme within governors to select a leader pseudorandomly. As governors are believed with no motivation to damage the consistency of the chain, blocks are proposed safely. Thus, every governor adopts the same block in each round, which derives the , and properties of our protocol. Meanwhile, contributed by the uploading phase, every transaction packed in the block must be labeled by at least one collector. At the same time, the collector cannot forge transactions without a provider’s public key except with negligible probability of the security parameter . As a result, the property of can be pledged. Finally, if a transaction sent by an active provider is valid indeed yet was labeled and in the block, governors will immediately verify this transaction upon receiving an request, and this transaction will appear in a following block. Thus, the property of is ensured in our model.

To reach consensus on an ordinary block which contains transactions offered by governors, an communication complexity emerges. Meanwhile, to generate a stake-transform block, governors should broadcast a transaction message to each other, which causes a communication complexity of . However, recall that in the permissioned blockchain scheme, the number of governors is much less than the number of providers and collectors. So, the complexity of consensus is not the main efficiency problem that may be suffered from this scheme.

4.2 An Analysis of the Reputation Mechanism

As stated in the protocol, consider a governor and a collector , the reputation vector can be unfolded as . The first entries represent the reputation on unchecked transactions which reflects on the screening probability. The -th entry shows the collector’s correctness of labeling transactions, and the last entry is for the reputation on the frequency of forging transactions.

To show the high efficiency of the first components of a collector’s reputation, we give the following theorem.

Consider a group of collectors who oversee the same provider . Suppose the real states of transactions provided by are revealed sometime after they appeared in the ledger and is not too large. Let be the accumulated expected loss on these transactions for the governor, and be the accumulated loss for the best-behaving collector on these transactions, with a suitably-chosen , we have

Proof.

The theorem is an extension of the result for the Randomized Weighted Majority (RWM) Algorithm in the problem of learning with expert advice [28]. We use the potential method to prove the theorem.

Recall that, for the -th transaction that remains unverified when packed into the block, the expected loss for the governor on this transaction should be:

as for the transaction, the governor simply marks it as invalid in the block. Here, denotes the sum of reputations of those collectors that made the correct judgment for the -th transaction, denotes the sum of reputations of collectors who failed to make a judgment, and denotes the sum of reputations of collectors in the other case, as stated before.

Let be the sum of reputation of all collectors who processed this transaction. We derive that

The last inequality holds due to is positive and the choice of :

As , we have

To give a lower bound on , assume be the reputation of the collector with accumulated loss for the transactions, as

holds for each , we derive that

Combining the lower bound and upper bound for , we establish that

The last inequality holds as for each . By applying logarithm to both sides of the inequality and due to for each in , we have

We note that for . Thus, in this interval, we obtain that

When holds, we derive that

When , the condition holds when , which is realistic. ∎

Notice that , thus the result we achieved is meaningful.

In our protocol, an honest provider can argue with the governor when he found any of his transactions marked invalid in the block. However, the latency should be no more than unchecked transactions, i.e., the real state of a transaction which is marked invalid and unchecked can only be retrieved before it is "buried" by no more than transactions with the same state. Every unchecked transaction exceeding this limit will be regarded as invalid permanently. Equivalently, the loss of the group of collectors on a specific transaction can be obtained within transactions’ latency.

Readers may be confused about the result proved above when considering latency, however, we claim that only a latency on the updating of reputation is induced. To show this, consider the first unchecked invalid transactions. These transactions are sampled with a never-updated reputation in the worst case. However, before the -th unchecked transaction is picked up, the real status of the first one has already arrived, which will cause a renewal on the collectors’ reputation. In this sense, when the -th unchecked transaction is stored into a block, the reputation has already been updated by times.

Notice that a governor only takes losses in those unchecked transactions as once a transaction is validated, the authentic status will be perceived, thus will cause no damage to the governor. To derive an overall result on a collector’s loss, we calculate the probability that a transaction is unchecked in the following lemma. For any transaction , the probability that is unchecked is no more than .

Proof.

Recall that is the parameter used to tune the probability of checking a transaction when it is thought as invalid. To prove the lemma, we compute the probability that a transaction provided by is validated.

Consider a governor . Suppose is broadcast by to collectors whose reputations w.r.t are respectively before comes in. Denote as the sum of reputation of collectors who labeled as valid, invalid and missed uploading respectively. Then, for the probability that is checked, , we have:

Thus, for any transaction , the probability that is unchecked is no more than . ∎

By applying Hoeffding’s Inequality [20], we give the following theorem:

Suppose transactions enter the network in total, then for any , the following inequality holds:

Proof.

A direct application of Hoeffding’s inequality can achieve the given theorem. ∎

Combining Theorem 4.2 and Theorem 4.2, we achieve our core theorem: Suppose transactions enter the network totally and is not too large. For all unchecked transactions provided by a fixed provider, suppose there is a collector whose accumulated loss on these transactions is , then for any , with probability no less than , the accumulated expected loss for the governor on this provider satisfies:

Proof.

The theorem follows directly by combining Theorem 4.2 and Theorem 4.2. ∎

Thus, if for any provider, there is a collector who behaves well, then the performance of the governor is guaranteed.

A considerable benefit of introducing reputation into our protocol is that we can provide incentives for collectors to behave honestly via the reputation system. In general, as nodes in a permissioned system have a sufficient amount of computation resources to complete the given task, we hope a collector’s reputation be a good measurement of his reliability and honesty.

Note that the safety of the protocol is already demonstrated in the previous subsection via the first four properties. Typically, to damage the efficiency of our protocol, there are three classes of misbehavior that a collector may commit: (1) to misreport the correct status (valid or invalid) of a transaction, (2) fail to report a transaction he receives from a provider, and (3) to forge a transaction and report it to the governor.

To simplify the discussion, we consider a provider with all collectors he is linked with as well as a governor who is in connection with all these collectors. In this sense, a collector’s reputation is composed of three parts, reputation on unchecked transactions, reputation on checked transactions, and reputation on forging transactions.

For a transaction, if a collector reports the opposite label or simply fail to report it, there are two cases:

  • The transaction is checked by the governor. In this case, the misguiding collector will immediately suffer a loss on the second component of his reputation. A misreporting will lead to a higher cut on the reputation than concealing.

  • The transaction is unchecked by the governor. In this case, the real status of the transaction is revealed within a time-bound. Collectors who missed to report or uploaded opposite labels will receive a corresponding discount on the first component of the reputation.

For those who try to forge a transaction, due to the security of the digital signature scheme, there is only with negligible probability of to trump up a never-occurred transaction. A malicious collector cannot simply replicate a transaction as well since the transaction is signed together with the timestamp. In all, any fabricating behavior will be detected by the governor except a negligible probability of . Once such behavior is noticed, a loss on the third component of reputation will severely reduce the revenue of the criminal.

Note that a collector’s reputation directly reflects on his revenue. Specifically, when is the leading governor of a round, collector ’s profit will be in proportion to the product . Thus, the more unreliable is, the less will be, as , the smaller the product will be, and less profit will gain. In this sense, our reputation mechanism provides high incentives for collectors to follow the instructions.

5 Applications and Use Cases

There are two distinct advantages of our model when it is put into practice. Our model suits well in circumstances where governors may be trustful yet selfish as a public ledger is maintained. In the meanwhile, the reputation mechanism helps us pick out those collectors with high reliability. In this sense, the high efficiency of collecting transactions can be realized. In this section, we will show that our model can be well applied in the field of car-sharing and insurance.

5.1 Car-sharing

Car-sharing is one of the biggest markets in today‘s sharing economy. In traditional car-sharing markets, users firstly submit ride requests to the scheduler, who decides whether to accept this request or not and assigns which server (car) to pick them up. This online scheduling problem has been solved in [25] [26]. However, the situation in the car-sharing market has changed a lot recently. In the past, different car-sharing companies competing with others, but now more of them start merging and allying with others. As a result, some new issues arise. Using the collaboration of Uber and Didi as an example, although they have the same stockholders now, they still have to maintain two platforms and need to serve segregated users after merging. Under these circumstances, how to integrate the resources effectively is a big challenge. Besides, the incident of driver killing passenger caused an extremely bad social impact in history, which shows the importance of security problems in the car-sharing.

The blockchain model we presented in this paper can solve the above problems. In our model, the user acts as the provider whose requests and payments are presented as transactions. Different from sending to platforms traditionally, users deliver transactions directly to some drivers in our model, who take the roles of the collector in this scheme. When receiving a transaction from a user, the driver labels the transaction if he is willing to provide the services and labels otherwise. After that, drivers deliver these labeled transactions to schedulers, who play as governors in our system. The schedulers have to decide immediately which driver should serve the user according to their states, locations, and reputations. Finally, a leader is selected from schedulers and the block including both assigned and unassigned requests is broadcast in the system, and every user and driver can operate according to this block. For unassigned requests, the schedulers should send them to drivers again later.

Comparing with traditional structure, our model has several advantages for the car-sharing issue. First of all, in our model companies don’t need to build a new platform when merging. Besides, the security and traceability provided from blockchains can prevent the occurrence of driver murder, which is also really important for the nowadays car-sharing market. Finally, the reputation system we present can discover some untruthful or dishonest drivers, helping platforms make a better arrangement.

5.2 Insurance

In the insurance industry, insurance companies offer various insurance policies to the public. A person, known as the potential policyholder, tends to buy proper insurance according to his own needs. Besides, there is a third party called independent agent, who is responsible for selling insurance policies provided by different insurance companies. In general, the independent agent collects a policyholder’s requirements and personal information, and help him buy certain insurance. Then the independent agent would receive rewards for the policy that he sells.

Take health insurance, for example. More and more people buy critical illness insurance for financial protection in case of an emergency. Specifically, the independent agents need to investigate all listed factors in the policies and then submit a summary to the companies. Those factors, such as age, gender, smoking status, past medical history, family history, and alcohol consumption, are used to estimate the potential policyholder’s risk of having serious illnesses. Here, we say "potential" because the policies have some limitations on the policyholder. A person may be rejected because of his past medical history. Thus, a potential policyholder may hide some records or provide false information. On the other hand, as the independent agent’s revenue is closely related to the policies he sells, he would try his best to avoid the possible rejection. When receiving a commission from a person, the independent agent may submit an incorrect survey to the companies, to help the potential policyholder get insured successfully. Of course, those misbehaviors could be detected by the companies.

Our proposed model can be applied to this scenario. The potential policyholder, who would like to buy certain insurance, is the provider in our model. He needs to prepare some materials according to the policy. We regard these materials as transactions. The potential policyholder uses his secret key to sign each transaction and provides them to several independent agents, who take the role of collectors. After receiving a set of transactions, the independent agent verifies each of them. He labels +1 for the valid transactions while -1 for invalid ones. Then, he summarizes the transaction information, fills out a survey, makes a digital signature and submits the labeled transactions and survey to the insurance companies. In this context, all insurance companies act as governors. A leader will be selected to store all received into the block. Sooner or later, they may check the materials and surveys with a certain probability.

The immutability of blockchain ensures that all participants’ behaviors will be permanently recorded, in the form of reputations in our model. If the potential policyholder provides false evidence, he cannot deny the facts because of his signature. Likewise, if an independent agent makes wrong judgments on the evidence, or fills out inconsistent information in the survey, he would also be found out.

6 Conclusion

In this work, we propose a permissioned blockchain model for the setting of horizontal strategic alliances, where several companies ally for mutual benefits. The hierarchical model contains three types of nodes, namely, providers, collectors, and governors. They are abstracted from the real world and have their respective tasks: providers send transactions to collectors; collectors label the validity of received transactions, and then forward them to governors; governors pack the transactions into generated blocks. Owing to the overlap of transactions that collectors receive from providers, we introduce the concept of reputation to reflect the collectors’ reliability. Each governor maintains a local reputation list for all collectors according to the transactions and labels they submit, and utilizes the reputation to decide the verification probability for transactions with an invalid label. We prove that, as long as there is a well-behaved collector, the expected amount of mistakes that governors suffer when guided by our reputation mechanism is only asymptotically the square root of the number of total transactions with overwhelming probability. Meanwhile, the collector’s revenue is closely related to his reputation. In a word, with the help of the reputation mechanism, our protocol has high efficiency, great performance, and good incentives. Furthermore, we apply our model to two real settings, including the car-sharing market and insurance industry.

References

  • [1] Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, Srinivasan Muralidharan, Chet Murthy, Binh Nguyen, Manish Sethi, Gari Singh, Keith Smith, Alessandro Sorniotti, Chrysoula Stathakopoulou, Marko Vukolic, Sharon Weed Cocco, and Jason Yellick. Hyperledger fabric: a distributed operating system for permissioned blockchains. In Proceedings of the Thirteenth EuroSys Conference, EuroSys 2018, Porto, Portugal, April 23-26, 2018, pages 30:1–30:15, 2018.
  • [2] Stefano De Angelis, Leonardo Aniello, Roberto Baldoni, Federico Lombardi, Andrea Margheri, and Vladimiro Sassone. Pbft vs proof-of-authority: Applying the cap theorem to permissioned blockchain. In Second Italian Conference on Cyber Security, ITASEC2018 2018, Milan, Italy, June 6-9, 2018, 2018.
  • [3] Iddo Bentov, Rafael Pass, and Elaine Shi. Snow white: Provably secure proofs of stake. IACR Cryptology ePrint Archive, 2016:919, 2016.
  • [4] BFT-SMaRt. https://github.com/bft-smart/library.
  • [5] Sonja Buchegger and Jean-Yves Le Boudec. A robust reputation system for mobile ad-hoc networks. Technical report, 2003.
  • [6] Vitalik Buterin et al. A next-generation smart contract and decentralized application platform. white paper, 3(37), 2014.
  • [7] Christian Cachin, Rachid Guerraoui, and Luís Rodrigues. Introduction to reliable and secure distributed programming. Springer Science & Business Media, 2nd edition, 2011.
  • [8] Christian Cachin and Marko Vukolic. Blockchain consensus protocols in the wild. CoRR, abs/1707.01873, 2017. URL: http://arxiv.org/abs/1707.01873, arXiv:1707.01873.
  • [9] Miguel Castro and Barbara Liskov. Practical byzantine fault tolerance and proactive recovery. ACM Trans. Comput. Syst., 20(4):398–461, 2002.
  • [10] Corda. https://github.com/corda/corda.
  • [11] Tendermint Core. https://github.com/tendermint/tendermint.
  • [12] David W Cravens, Shannon H Shipp, and Karen S Cravens. Analysis of co-operative interorganizational relationships, strategic alliance formation, and strategic alliance effectiveness. Journal of Strategic Marketing, 1(1):55–70, 1993.
  • [13] Bernardo David, Peter Gazi, Aggelos Kiayias, and Alexander Russell. Ouroboros praos: An adaptively-secure, semi-synchronous proof-of-stake blockchain. In Advances in Cryptology - EUROCRYPT 2018 - 37th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Tel Aviv, Israel, April 29 - May 3, 2018 Proceedings, Part II, pages 66–98, 2018.
  • [14] Richard Dennis and Gareth Owen. Rep on the block: A next generation reputation system based on the blockchain. In 10th International Conference for Internet Technology and Secured Transactions, ICITST 2015, London, United Kingdom, December 14-16, 2015, pages 131–138. IEEE, 2015.
  • [15] Richard Dennis and Gareth Owenson. Rep on the roll: a peer to peer reputation system based on a rolling blockchain. International Journal for Digital Society, 7(1):1123–1134, 2016.
  • [16] HyperLedger Fabric. https://github.com/hyperledger/fabric.
  • [17] Fangyu Gai, Baosheng Wang, Wenping Deng, and Wei Peng. Proof of reputation: A reputation-based consensus protocol for peer-to-peer network. In Jian Pei, Yannis Manolopoulos, Shazia W. Sadiq, and Jianxin Li, editors, Database Systems for Advanced Applications - 23rd International Conference, DASFAA 2018, Gold Coast, QLD, Australia, May 21-24, 2018, Proceedings, Part II, volume 10828 of Lecture Notes in Computer Science, pages 666–681. Springer, 2018.
  • [18] Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich. Algorand: Scaling byzantine agreements for cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles, Shanghai, China, October 28-31, 2017, pages 51–68, 2017.
  • [19] Minaxi Gupta, Paul Judge, and Mostafa H. Ammar. A reputation system for peer-to-peer networks. In Christos Papadopoulos and Kevin C. Almeroth, editors, Network and Operating System Support for Digital Audio and Video, 13th International Workshop, NOSSDAV 2003, Monterey, CA, USA, June 1-3, 2003, Proceedings, pages 144–152. ACM, 2003.
  • [20] Wassily Hoeffding.

    Probability inequalities for sums of bounded random variables.

    In The Collected Works of Wassily Hoeffding, pages 409–426. Springer, 1994.
  • [21] Kevin J. Hoffman, David Zage, and Cristina Nita-Rotaru. A survey of attack and defense techniques for reputation systems. ACM Comput. Surv., 42(1):1:1–1:31, 2009.
  • [22] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov. Ouroboros: A provably secure proof-of-stake blockchain protocol. In Advances in Cryptology - CRYPTO 2017 - 37th Annual International Cryptology Conference, Santa Barbara, CA, USA, August 20-24, 2017, Proceedings, Part I, pages 357–388, 2017.
  • [23] Michael Kinateder and Siani Pearson. A privacy-enhanced peer-to-peer reputation system. In Kurt Bauknecht, A Min Tjoa, and Gerald Quirchmayr, editors, E-Commerce and Web Technologies, 4th International Conference, EC-Web, Prague, Czech Republic, September 2-5, 2003, Proceedings, volume 2738 of Lecture Notes in Computer Science, pages 206–215. Springer, 2003.
  • [24] Litecoin. https://litecoin.org/.
  • [25] Kelin Luo, Thomas Erlebach, and Yinfeng Xu. Car-sharing between two locations: Online scheduling with flexible advance bookings. In Computing and Combinatorics - 24th International Conference, COCOON 2018, Qing Dao, China, July 2-4, 2018, Proceedings, pages 242–254, 2018.
  • [26] Kelin Luo, Thomas Erlebach, and Yinfeng Xu. Online scheduling of car-sharing requests between two locations with many cars and flexible advance bookings. In 29th International Symposium on Algorithms and Computation, ISAAC 2018, December 16-19, 2018, Jiaoxi, Yilan, Taiwan, pages 64:1–64:13, 2018.
  • [27] Silvio Micali, Michael O. Rabin, and Salil P. Vadhan. Verifiable random functions. In 40th Annual Symposium on Foundations of Computer Science, FOCS ’99, 17-18 October, 1999, New York, NY, USA, pages 120–130, 1999.
  • [28] Mehryar Mohri, Afshin Rostamizadeh, and Ameet Talwalkar.

    Foundations of Machine Learning

    .
    The MIT Press, 2nd edition, 2018.
  • [29] MultiChain. https://github.com/MultiChain/multichain.
  • [30] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. Technical report, Manubot, 2019.
  • [31] Mehrdad Nojoumian, Arash Golchubian, Laurent Njilla, Kevin Kwiat, and Charles Kamhoua. Incentivizing blockchain miners to avoid dishonest mining strategies by a reputation-based paradigm. In Science and Information Conference, pages 1118–1134. Springer, 2018.
  • [32] Diego Ongaro and John K. Ousterhout. In search of an understandable consensus algorithm. In 2014 USENIX Annual Technical Conference, USENIX ATC ’14, Philadelphia, PA, USA, June 19-20, 2014, pages 305–319, 2014.
  • [33] Deepak Puthal, Saraju P. Mohanty, Venkata P. Yanambaka, and Elias Kougianos. Poah: A novel consensus algorithm for fast scalable private blockchain for large-scale iot frameworks. CoRR, abs/2001.07297, 2020. URL: https://arxiv.org/abs/2001.07297.
  • [34] Quorum. https://github.com/jpmorganchase/quorum.
  • [35] Ripple. https://github.com/ripple.
  • [36] Alexander Schaub, Rémi Bazin, Omar Hasan, and Lionel Brunie. A trustless privacy-preserving reputation system. In Jaap-Henk Hoepman and Stefan Katzenbeisser, editors, ICT Systems Security and Privacy Protection - 31st IFIP TC 11 International Conference, SEC 2016, Ghent, Belgium, May 30 - June 1, 2016, Proceedings, volume 471 of IFIP Advances in Information and Communication Technology, pages 398–411. Springer, 2016.
  • [37] Thomas L Sporleder. Assessing vertical strategic alliances by agribusiness. Canadian Journal of Agricultural Economics/Revue canadienne d’agroeconomie, 42(4):533–540, 1994.
  • [38] European Union. Commission notice: guidelines on the applicability of article 81 of the ec treaty to horizontal cooperation agreements. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.C_.2001.003.01.0002.01.ENG.
  • [39] Yingjie Wang, Zhipeng Cai, Guisheng Yin, Yang Gao, Xiangrong Tong, and Guanying Wu. An incentive mechanism with privacy protection in mobile crowdsourcing systems. Computer Networks, 102:157–171, 2016.
  • [40] Mengqian Zhang, Jichen Li, Zhaohua Chen, Hongyin Chen, and Xiaotie Deng. Cycledger: A scalable and secure parallel protocol for distributed ledger via sharding. CoRR, abs/2001.06778, 2020. URL: https://arxiv.org/abs/2001.06778.
  • [41] Runfang Zhou and Kai Hwang. Powertrust: A robust and scalable reputation system for trusted peer-to-peer computing. IEEE Trans. Parallel Distrib. Syst., 18(4):460–473, 2007.