A Reputation Based Hybrid Consensus for E-Commerce Blockchain

Abstract

Blockchain can achieve non-tampering, non-repudiation, consistency and integrity that other data management technologies do not have. Especially in peer-to-peer networks, the decentralized nature of blockchain has drawn tremendous attention from academic and industrial communities. Recently, the field of e-commerce has also begun to realize its important role. Although blockchain technology has many advantages in achieving trust establishment and data sharing among distributed nodes, in order to make it better to be applied in e-commerce, it is necessary to improve the security of transactions and the efficiency of consensus mechanisms. In this paper, we present a reputation based hybrid consensus to solve the problem of transaction security and efficiency. Our scheme integrates the reputation mechanism into transactions and consensus, and any improper behavior of nodes will be reflected in the reputation system and fed back to a new round of transactions and consensus. We implement distributed reputation management and enable users to append new reputation evaluations to the transaction that has previously evaluated. Meanwhile, we demonstrated that the scheme can defend against existing attacks such as selfish mining attacks, double spending attacks and flash attacks. We implement a prototype and the result shows that our scheme is promising.

1 Introduction

Recent advances in blockchain technology have witnessed unprecedented practicability in various tasks e.g., intelligent services, health care, education, social management. The consensus mechanism is the core technology of the blockchain, and mainstream blockchain platforms such as Bitcoin and Ethereum rely on the continuous mining of miners distributed around the world to maintain the normal operation of the system. However, the mining incentive mechanism will lead to the concentration of computing power, which will not only cause 51% attacks but also waste a lot of resources. The security of consensus mechanisms such as proof-of-stake (POS) [7, 14, 24] and delegated proof-of-stake (DPOS) [1], which is not based on computing power, has not been theoretically validly proven. Strong consistency algorithms such as practical Byzantine fault-tolerant algorithms also have disadvantages such as high algorithm complexity and low degree of decentralization. Therefore, to apply blockchain technology to the field of e-commerce, how to design a safe and efficient consensus mechanism is one of the major challenges.

In this paper, we propose a hybrid consensus mechanism and apply it to the e-commerce blockchain. We have put forward the concept of reputation. The purpose of this is that, on the one hand, both parties to the transaction need the reputation system as an important basis for mutual judgment; on the other hand, integrating the reputation mechanism into the consensus can promote the normal operation of the consensus mechanism and made the system more secure.

To summarize, we made the following contributions:

• We introduced the blockchain into the e-commerce system to realize the decentralized management of transactions, so that users can complete transactions without the involvement of trusted third parties. We propose a reputation based hybrid consensus for e-commerce blockchain. We introduce the concept of reputation, and push forward nodes to act legally in both transactions and consensus.

• In our consensus mechanism, we decouple transaction packaging and write transaction lists into the blockchain. Besides, the work of miners is divided into low difficulty microblocks and high difficulty blocks, which effectively prevents the concentration of computing power and ensures the degree of decentralization of the system.

• We use a reputation chain to store, manage, and update reputations. In this way, distributed reputation management is achieved without the need for trusted third parties in traditional reputation systems. In addition, the reputation system also supports users to append new evaluation messages to the transaction that has already evaluated.

• We provide detailed security analysis of our scheme, the analysis shows that our scheme can resist the most attacks. We implement the prototype and evaluate its performance. The experiment result shows that our scheme has high efficiency, that is, it can achieve high throughput, so the scheme is more suitable to the field of e-commerce.

2 Related Work

With the wide application of blockchain technology, the types of consensus mechanisms have also become diverse to accommodate a variety of different application scenarios. In this section, we will give an introduction to the consensus mechanisms in different blockchains.

Proof of Work (POW) is the earliest consensus mechanism in the blockchain field, it serves the bitcoin network proposed by Nakamoto [10, 19]. The work here refers to the process of computer computing calculating a random number. Within a certain period of time, the difficulty of finding a random number is certain, which means that it takes a certain amount of work to get this random number. The node that first obtains this random number is responsible for packing the transactions to the block, adding the new block to the existing blockchain, and broadcasting it to the entire network, other nodes perform verification and synchronization. In the case of POS, the system allocates the corresponding accounting rights according to the product of the number of tokens held by the node and the time. In DPOS, the person who owns the token votes to a fixed node, and these nodes act as agents to exercise the right to record. These voting-recognized representatives obtain billing rights in turn according to certain algorithms. PBFT is a fault-tolerant algorithm for Byzantine generals [16, 18], it is a state machine that requires all nodes to jointly maintain a state, and all nodes take the same action. The Paxo mechanism without considering Byzantine faults [15] and Raft mechanism [20] belong to the same type of consensus mechanism. There are also some problems with these common consensus mechanisms, such as the waste of the computing power of the PoW mechanism, the interest of the PoS mechanism is easy to concentrate on the top layer, and the efficiency of the PBFT in the network with a large number of nodes that are constantly changing dynamically, etc.

Therefore, in recent years, scholars have been proposing new consensus mechanisms. Ouroboros [13] is the first blockchain protocol based on PoS with strong security guarantees, which has an efficiency advantage over a blockchain of physical resource proofs (such as PoW). Given this mechanism, honest behavior is an approximate Nash equilibrium, which can invalidate selfish mining attacks. Snow White [4] addresses the dynamic distribution of stake owners and uses corruption delay mechanisms to ensure security. Algorand [6] provides a distributed ledger that follows the Byzantine protocol, and each block resists adaptive corruption. Fruitchain [23] provides a reward mechanism and approximate Nash equilibrium proof for PoW-based blockchains.

Integrating identity and reputation into the consensus mechanism is a new direction. Proof of authority (PoA) is a reputation-based consistency algorithm that introduces practical and effective solutions for blockchain networks, especially private blockchains. The mechanism was proposed in 2017 by Ethereum co-founder Gavin Wood [2]. PoA uses the value of the identity, which means that the verifier of the block does not depend on the cryptocurrency of the mortgage but on the reputation of the individual. The PoA mechanism relies on a limited number of block validators, making it a highly scalable system. Blocks and transactions are verified by participants pre-approved by the system administrator. RepuCoin [25], developed by the University of Luxembourg’s Interdisciplinary Centre for Security, Reliability and Trust, uses the concept of online reputation to defend against 51% of attacks. Gai et al. present a reputation-based consensus protocol called Proof of Reputation (PoR) [9], which guarantees the reliability and integrity of transaction outcomes in an efficient way.

However, the existing research results have not yet applied a sound reputation system on the e-commerce blockchain, and these consensus mechanisms or systems based on reputation do not consider the behavior of users in the transaction process, such as users do not comply with or deliberately destroy the transaction rules. Therefore, this paper combines consensus with actual transactions through a reputation mechanism, and proposes a reputation-based consensus mechanism suitable for the application scenarios of e-commerce.

3 Notations and Security Definitions

In this section, we will introduce some notations and the security definition in the scheme.

3.1 Notations

Towards to formalize our consensus mechanism and blockchain system, we first define some basic concepts and notations.

User. In our scheme, the public key $pk_j$ is used to mark the user j. $pk_j$ is public, but its corresponding $sk_j$ is owned only by user j.

In the scheme, there are also some special users. The consensus group members reach a consensus on the transaction list. Each round has a leader who packs transactions in the network and initiates consensus. Miners generate corresponding blocks by solving puzzles of different difficulty. From the perspective of application scenarios of transactions, users are also divided into service providers and purchasers.

Transaction. In a transaction, the purchaser i first needs to send a service requirement to the service provider j. We define it as: $ServiceRequirement_{ij} = (pk_i, pk_j, Req, H(Req'), \sigma _i)$. where pk is the public key of the purchaser, $pk'$ is the service provider’s public key, Req is the specific service requirement, where the part involving sensitive information is represented by $H(Req')$, and $\sigma$ is the purchaser’s signature of the above information. After the service provider receives the requirement message, it provides the corresponding service to the purchaser, and then sends a response message to the purchaser: $ServiceResponse_{ij} = (ServiceRequirement_{ij}, Res, H(Res'), \sigma _j)$. After receiving the message and corresponding service, the purchaser adds the service result (the service result is 1 if the transaction is completed, otherwise 0) to the response message, signs it and publishes it to the blockchain network: $Service_{ij} = (ServiceResponse_{ij}, result, \sigma _i)$, this process can be expressed as Fig. 1.

There are some special transaction forms such as reputation transactions and reputation modification transactions, the specific structure of which will be introduced later.

A Transaction List is a collection of transactions of the same type. It is determined after the consensus group has reached a consensus, and it has an order. Therefore, in addition to the transactions in the network over a period of time, the transaction list also needs to include a serial number, the hash value of the previous transaction list, and the signatures of the consensus group members $\sigma _T$.

Fig. 1.

The transaction generation process.

MicroBlock. Each MicroBlock corresponds to a transaction list, which is a block with lower mining difficulty. The existence of MicroBlock is to enable miners to receive certain rewards without having to aggregate a large amount of computing power, thereby preventing selfish mining. The main structure of Microblock is:

$$MicroBlock = (recent\_block\_hash, tran\_serial\_num, tranList\_hash, Nonce)$$

where $recent\_block\_hash$ is the hash value of the latest block on the current blockchain, $tran\_serial\_num$ is the serial number of the transaction list contained in the MicroBlock, and $tranList\_hash$ is its hash value. Nonce is the solution to the puzzle.

Block. Block is similar to the structure in the Bitcoin system, and miners need to solve a puzzle to mine blocks. The difficulty of this puzzle is higher than that of MicroBlock. The main structure of a block is as follows:

$$Block = (prev\_block\_hash, {MicroBlock}, Nonce)$$

where $prev\_block\_hash$ is the hash value of the previous block, MicroBlock is the collection of MicroBlocks contained in the Block, and Nonce is the puzzle solution.

3.2 Security Definitions

In the scheme discussed in this paper, we follow the security assumptions of hybrid consensus mentioned in [21]. On the network side, the system is not a fully synchronized network, so in some cases messages on the network may be lost, duplicated, delayed, or out of order. We assume that messages are delivered within a certain time t. And the nodes in the system are independent, and the failure of one node will not cause the failure of other nodes.

We assume that there is a malicious adversary A in the system, and the computing power of adversary A is limited. For example, it cannot crack the encryption algorithm, forge the digital signature of a node, or recover the message content from the hash data. Adversary A cannot delay normal nodes indefinitely.

Fig. 2.

The blockchain protocol.

Adversary A can manipulate multiple failed nodes, however, in the system, we assume that when there are f malicious nodes or failed nodes, then at least $2f + 1$ normal nodes must be guaranteed in the system. Only in this way can the security and liveness of the system in the consensus mechanism be guaranteed, and there will be no indefinite delay.

4 The Proposed Consensus Mechanism

In this section, we will introduce the main processes of the hybrid consensus mechanism. The consensus mechanism we propose is mainly divided into three stages, namely transaction packaging, microblock mining and block mining. Figure 2 describes the general flow of these three phases. We will describe it in detail below.

4.1 Transaction Packaging

The transaction packing phase loads the messages in the network into the transaction list in the recent period. Transaction packaging is done by members of the consensus group that are dynamically selected in each round. Members of the consensus group are some of the nodes with the highest reputation scores. The calculation of consensus reputation will be described in detail later. Our scheme will select the leader with a $\dfrac{1}{|G|}$ probability among the members of the consensus group G with the highest reputation score, where $\dfrac{1}{|G|}$ is the number of consensus group members. The specific selection method of the r-th transaction list’s leader $l_r$ is as follows:

$$\begin{aligned} seed_r&\longleftarrow H(TransactionList_{r-1})\\ i&\longleftarrow seed_r \ mod \ |G|\\ l_r&\longleftarrow G_i \end{aligned}$$

The leader is responsible for packaging the messages and initiating consensus. It first sends the following messages to the members of the consensus group of this round: $(pk_{l_r},TransactionList_r,SIG_{l_r}(TransactionList_r))$, after receiving the message, other consensus group members first check whether the sender is the leader of the current round, and if so, check whether the transaction list and its signature are legal. If all are legal, other nodes sign the message and broadcast to the consensus group. After a period of time, if members of the consensus group receive 2f messages that are the same as themselves, they send a commit message to the consensus group. After a while, if members of the consensus group receive $2f + 1$ commit messages, they will publish the transaction list. The form of the pinned transaction list is shown in Fig. 3.

Fig. 3.

The pinned transaction list structure.

The message list contains transaction messages published in the network over a period of time. When the leader packages it into a transaction list, it needs to add a serial number and the hash value of the previous pinned transaction list. After consensus is finally reached, members of the consensus group will attach their signature certificate to the transaction list to prove its validity.

4.2 MicroBlock Mining

In cryptocurrency systems such as Bitcoin, people have been worried about the concentration of computing power for a long time due to the existence of mining pools. Large mining pools and mining pool alliances composed of stakeholders may have close to or even exceed 51% of the computing power.

To solve this problem, we introduced MicroBlock. Each MicroBlock contains a transaction list. In addition, because MicroBlock can be mined out of order, it also needs to contain the serial number of the transaction list to restore the order of transactions. The mining difficulty of MicroBlock is relatively low, and it can be adjusted according to the operating status of the system. We hope that its mining interval is close to the consensus time of a transaction list. MicroBlock’s puzzle is defined as follows:

$$H(prev\_block, recent\_block, Microblock\_set, tranList, Nonce) <target_m$$

where $prev\_block$ is the hash value of the previous Block on the current blockchain, although Microblock mining does not need to pay attention to it, in order to ensure that the miners solve the same puzzles as mining Blocks (but the difficulty is different), it needs to be added to the puzzle.$Microblock\_set$ represents the MicroBlocks contained in the Block. Like the former, it only plays a practical role in Block mining. $recent\_block$ is the Block on which this MicroBlock mining is based. It can be any Block within a period of time. The tranList is the hash value of the transaction list included in the MicroBlock. It is worth noting that it should also contain the serial number of the transaction list. In the end, Nonce is a solution to the puzzle, and the miner obtains the corresponding reward by finding Nonce.

When several MicroBlocks are mined at the same time, in this solution, the solution we choose is to choose the one with the smallest hash value.

4.3 Block Mining

Block mining is similar to the PoW-based mechanism in Bitcoin. In this scheme, the mining puzzle is defined as:

$$H(prev\_block, recent\_block, Microblock\_set, tranList, Nonce) <target$$

The mining difficulty target is higher than MicroBlock’s mining difficulty $target_m$, and it can also be adjusted during the system operation. Similar to MicroBlock, there are some things that Block does not care about in the puzzle of mining Blocks, such as $recent\_block$ and tranList. These are all related to mining MicroBlock. The former represents one of the most recent blocks that MicroBlock is attached to, and the latter records the transaction list stored in MicroBlock. $prev\_block$ is the hash of the previous Block, $Microblock\_set$ is the MicroBlocks included in the Block. A Block will contain multiple MicroBlocks. Block miners will pack as many MicroBlocks as possible to get more rewards.

4.4 Reputation System and Reward System

Reputation System. In this section, we mainly deal with the change of reputation in the consensus process. In addition, in the process of transactions, there will be changes in the transaction reputation, which we will discuss in detail in the next section.

Reputation feedback management can ensure the security of a decentralized system. Therefore, in our solution, reputation scores, as well as computing power, have become the key for miners to gain power in consensus mechanisms. We represent the reputation score of node i in the consensus as $R_i$. For the convenience of description, we show the notations used in the reputation system in Table 1, and reputation R is calculated according to Algorithm 1.

Table 1. The notations in reputation system

The consensus reputation of a node is determined by two factors: its activity and honesty. The activity of node i is mainly determined by three factors, which are the number of times a Block is mined by node i, the number of times a MicroBlock is mined by node i, and the number of times it becomes a leader. In addition, some nodes will have a high initial reputation, which depends on the specific scenarios of transactions in the real world. In the initial stage of the system, these nodes will play a key role in the consensus mechanism, but as the system runs, the node’s reputation will be more affected by its behavior.

The honesty of a node depends on the legitimacy of its behavior. We define the following behaviors of nodes as improper behaviors:

• Nodes provide conflicting transactions when they act as leaders;

• Nodes as members of the consensus group submit messages that conflict with most members;

• Nodes do not include the correct information after mining Blocks or MicroBlocks.

When nodes have one of these behaviors, their honesty decreases. The selection of the consensus group in our consensus mechanism is to sort the node’s reputation value R and select the highest $\vert G \vert$ nodes to participate in transaction packaging. Such a mechanism can encourage nodes to properly perform their work, thereby improving their reputation scores and obtaining more rewards.

Reward System. The reward mechanism is the core of the blockchain system and the largest source of power for the system’s sustainable development. In our reward system, the main source is transaction fees and there are three types of nodes that receive rewards: leaders, block miners and microblock miners. For each final block, there is one block miner and multiple microblock miners and leaders. This is due to the structure of the block. A block contains multiple microblocks, and a microblock contains a transaction list.

Our reward system allocates transaction fees in the following way: For each transaction list, the leader of the transaction list, the miner of the microblock with this list, and the miner of the block where this microblock was eventually placed are divided equally the sum of transaction fees. That is, each node gets a third of the transaction fees. Such a reward system can prompt the leader to pack as many transactions as possible into the transaction list to get more rewards, and the same is true for block miners, who will be more inclined to put more microblocks into blocks. In addition, block miners will receive more rewards than microblocks, which is proportional to the computing power they pay.

The reward system and the reputation system have a mutually reinforcing role, because a node with the correct behavior can not only receive a reward for transaction fees, but also accumulate a higher reputation score, and increasing the reputation score can also increase the probability that the node will enter the consensus group and be selected as a leader.

5 The Reputation Chain

In this section, we will describe the management and storage of reputation in the transaction stage. We store the reputation scores in the transaction separately in the reputation chain, so that different nodes can choose the synchronized data according to their needs.

5.1 Reputation Storage and Management

In a transaction scenario, both parties to a transaction need a reputation system as an important basis for mutual evaluation. Therefore, we propose the concept of a reputation chain to perform distributed management of reputation evaluation in user transactions. In the reputation chain, there are two forms of reputation transactions, namely reputation publication transactions and additional reputation transactions.

After the node completes a transaction, it needs to evaluate the transaction. This type of message has the form:

$$repu\_pub = (pk_i, pk_j, tran\_location, tran\_hash, m_{pub},\sigma )$$

Fig. 4.

The reputation chain structure.

where $pk_i$ and $pk_j$ are the public keys of the purchaser and the service provider respectively. $tran\_location$ is the position of the transaction corresponding to this reputation evaluation message in the transaction blockchain, and $tran\_hash$ is the hash of the transaction. $m_{pub}$ is the content of reputation evaluation, $\sigma$ is the publisher’s signature on this message.

If the purchaser wants to publish additional reputation evaluation message after it has been submitted, the purchaser needs to generate a reputation modification message, which has the following structure:

$$repu\_extra = (pk_i, pk_j, tran\_location, tran\_hash, m_{extra},\sigma ')$$

The first four elements of the $repu\_extra$ message are the same as the $repu\_pub$, and they represent the same meaning. $m_{extra}$ is the new content of the additional reputation evaluation message, and $\sigma '$ is its signature on the message.

Figure 4 shows the structure of the reputation chain and its relationship with the original blockchain. Each of these blocks in the reputation chain is similar to $RepuBlock_r$, and contains two types of messages. The reputation evaluation message corresponds to a transaction in the original blockchain. The leader described in Sect. 4 is responsible for packaging transactions of the reputation chain and reaching a consensus within the consensus group.

5.2 Reputation and Additional Reputation Publication

Our scheme provides the ability to publish reputation evaluation message and additional reputation message to the same transaction and implements it using a linkable ring signature algorithm [12, 17]. Before publishing reputation evaluation messages, nodes sign them in the following way:

• [Setup] Choose a cyclic additive group $\mathbb {G}$ which generator is p and a multiplicative group $\mathbb {G}_1$ of a large prime q. The bilinear pairing is $e:\mathbb {G}\times \mathbb {G}\rightarrow \mathbb {G}_1$. Let H and $H'$ be the hash function, $H:\{0,1\}^*\rightarrow \mathbb {G}$ and $H':\{0,1\}^*\rightarrow \mathbb {Z}_q$. Randomly choose $t \in mathbb{Z}_q$, $s \in mathbb{Z}_q^*$ and $A \in \mathbb {G}$, every legal user has an ID and let $S_{ID}=sH_i(ID)$ be the user’s private key, its public key is given by $H'(ID)$, let $P_{pub}=sP$, $L=\{ID_i\}$. Compute $P' = tP$, $c_{k+1}=H(L \parallel m\parallel e(A,P) \parallel e(A,P))$.

• [Generate ring sequence] For $i = k+1,...,n-1,0,1,...,k-1$ (the value of i modulo n), choose $R_i,T_i \in \mathbb {G}$ randomly, and compute $c_{i+1}=H(L \parallel m \parallel e(R_i,P)e(H'(ID_i),P_{pub}) \parallel e(T_i,P)e(c_iH'(ID_i),P'))$.

• [Forming the ring] Let $R_k=A-c_kS_{ID_k}$ and $T_k=A-c_ktH'(ID_k)$.

• [Signing] the signature for m is $\sigma = (P',c_0,R_0,...,R_{n-1},T_0,...,T_{n-1}).$

• [Verification] Given $(P',c_0,R_0,...,R_{n-1},T_0,...,T_{n-1})$, m and L, compute $c_{i+1}=H(L \parallel m \parallel e(R_i,P),e(c_iH'(ID_i),P_{pub}) \parallel e(T_i,P)e(c_iH'(ID_i),P'))$. Accept if $c_n = c_0$, otherwise reject.

Table 2. Attack resilience

When the user needs to publish additional reputation evaluation information, he uses the same t as in the original message signature to front the new reputation evaluation message. Only from the same t, we can get the same $P'$ as the original signature. When verifying the signature, a signature with the same $P'$ is the additional message corresponding to the original message. If $t'$ other than t is used for signing, the correctness of the signature algorithm cannot be guaranteed in the step of forming the ring. For non-signers, solving t is a discrete logarithm problem.

6 Security and Performance Analysis

In this section, we first analyze the security of the scheme, prove that our scheme can resist the existing attacks, and then we describe the efficiency of the scheme.

6.1 Security Analysis

Towards the current attacks, we give the security analysis for our consensus mechanism in this section and compared them with existing systems. The result is shown in Table 2.

Security Under Selfish Mining Attacks. Selfish mining [8] is mainly achieved by detaining blocks and delaying the time of publishing blocks. The purpose of selfish mining is not to destroy the blockchain network of cryptocurrencies, but to obtain greater profits. Because the threshold of attack is relatively low and the profit is high, theoretically this kind of attack is easy to appear. In the consensus mechanism described in this paper, miners are only responsible for putting as many microblocks containing transaction lists into the block as possible, and the block containing the most microblocks is the main chain. Therefore, miners can only publish the blocks they mine as soon as possible to get the maximum benefit, it cannot mine the block and not publish it, because doing so does nothing to the miners.

Security Under Double Spending Attacks. In traditional transactions, because there is a centralized institution such as a bank, there is no double spending problem: each payment will be deducted from your bank account, and all details are available in the bank recording. However, in blockchain systems such as Bitcoin, there is a danger of double spending [11, 22] when a transaction occurs because there is no guarantee from a centralized institution such as a bank. In our scheme, transaction packaging and publishing to the final blockchain are completed by different nodes, and miners cannot change the content in the transaction list, because the consensus is reached by the consensus group and each list has a signature of the consensus group. Miners can only put the complete transaction list into the microblock, and then put multiple microblocks into the block of the final blockchain. In this way, our scheme can resist double spending attacks.

Security Under Flash Attacks. In flash attacks [5], an attacker can obtain a large amount of computing power temporarily to launch an attack on a blockchain system. This attack can break its security assumptions in the traditional proof-of-work mechanism. But in our system, flash attacks cannot be implemented. Because the transaction list is packaged with high-reputation nodes, and the mining of microblocks does not require too much computing power, so even if the adversary can temporarily have a large amount of computing power, he can only mine more blocks, and cannot pose a threat to the transaction blockchain.

6.2 Performance Analysis

For our prototype, we built an experimental network and implemented our protocol. We deploy the nodes on client machines with Intel i7-4600U 2.70 GHz CPU, and 16 GB RAM. In the experiment we set up 1000 nodes, each node has a bandwidth of 20 Mbps.

Fig. 5.

Throughput of the scheme.

Figure 5 compares our scheme with Bitcoin, ByzCoin and Hyperledger Fabric [3] in terms of throughput in different block sizes of 0.5 MB, 1 MB, 2 MB and 4 MB. The Bitcoin system is the most commonly used blockchain system, and it uses a proof-of-work consensus mechanism. However, due to its throughput limitations, it is difficult to use in the field of e-commerce. In ByzCoin, the set of witnesses is dynamically formed, a new leader is elected each time a new key block is created, and the set of transactions can be committed every few seconds if a sufficient number of witnesses have collectively signed it. Hyperledger Fabric is the one with higher performance in the current blockchain system, but its degree of centralization is high, and the chain is limited to members of the alliance.

We can see that the throughput of the Bitcoin system is 2 TPS, 3 TPS, 7 TPS, 14 TPS under different block sizes, the ByzCoin system is 105 TPS, 205 TPS, 287 TPS and 428 TPS respectively. Hyperledger Fabric’s throughput is approximately 2785 TPS, 2940 TPS, 3185 TPS and 3285 TPS respectively, which is a blockchain system that is advantageous in terms of throughput. In Our scheme, when the block size is 0.5 MB, the throughput is about 1200 TPS. When the block size is 1MB, its throughput is close to 2000 TPS and when the block sizes are 2 MB and 4 MB, the throughput exceeds 4000 TPS and 7000 TPS, respectively.

Through the experimental results, it can be seen that our scheme has a high throughput and is suitable for transaction scenarios.

7 Conclusion

In this paper, we design a reputation based consensus mechanism with high security and efficiency for e-commerce blockchain. In the proposed scheme, we have established a reputation mechanism to supervise the legal behavior of nodes in terms of consensus and transactions. We use the reputation chain to implement distributed storage of reputation, and enable users to publish multiple reputation evaluation information for a transaction. Besides, the scheme decouples the transaction serialization and writes it into the blockchain, adding microblocks prevents the concentration of computing power and increases fairness. The results of the security and performance analysis demonstrate that the proposed scheme can be well adapted to the application scenarios of transaction.