ST-PBFT: An Optimized PBFT Consensus Algorithm for Intellectual Property Transaction Scenarios

Abstract

For the current Intellectual Property (IP) transaction scenario, consensus nodes need to simultaneously consensus transactions of the same transaction type, resulting in low consensus efficiency, accuracy, and reliability, which seriously hinders the development of intellectual property. Based on the consortium chain, this paper proposes a secure and efficient blockchain-distributed consensus algorithm, ST-PBFT (Shard Transaction Practical Byzantine Fault Tolerance), applied to the IP transaction scenario. The main contributions of ST-PBFT include the following: first, a grouping method based on the principle of consistent hashing is proposed to group consensus nodes, and nodes group consensus, which reduces the complexity of communication. Second, the transaction consensus group can process IP transactions in parallel, which improves the throughput of the algorithm. Third, a node reputation evaluation model is proposed, which can prevent byzantine nodes from being repeatedly elected as primary nodes. The experimental results show that ST-PBFT can significantly improve the consensus efficiency and reliability and reduce consensus latency.

1. Introduction

Since the birth of Bitcoin [1], digital cryptocurrency has developed rapidly and its underlying blockchain technology has been widely studied by scholars. Blockchain technology possesses features such as decentralization, data security, and data immutability [2], which makes it promising for applications in finance, Internet of Things [3], healthcare, and financial transactions.

The technical advantages of blockchain, such as decentralization, immutability, distributed fault tolerance, and anonymity protection, and the core technologies, such as the consensus mechanism, smart contracts, cryptographic algorithms, and the loosely coupled data structure design, can provide technical support for intellectual property rights on-chain confirmation, intellectual property traceability auditing, intellectual property transactions, intellectual property infringement monitoring, and solid evidence.

However, the consensus algorithms in the current blockchain, such as the POW consensus algorithm and POS consensus algorithm, commonly used in public chains, and the PBFT algorithm commonly used in consortium chains, require consensus nodes to simultaneously consensus on transactions of the same transaction type, resulting in low consensus efficiency, accuracy, and reliability, which do not meet the performance requirements of the development of the existing intellectual property transaction scenario and seriously hinder the development of intellectual property.

Thus far, many scholars have conducted in-depth research on the application of blockchain in intellectual property scenarios.

In the literature [4], a blockchain intellectual property protection model based on improved PBFT is proposed, which is mainly based on the improved PBFT consensus mechanism of credit to achieve an efficient, low-consumption, and scalable intellectual property protection method. Pu Songtao [5] proposed the application of blockchain in intellectual property rights confirmation, protection, and transaction. Liu Zongyuan [6] discussed the application of blockchain in digital copyright management and protection from the current situation of the digital copyright industry and the problems of digital copyright protection. Wang Xiaofang [7] discussed the framework of building an intellectual property protection service system based on blockchain by modifying the existing blockchain technology from the perspective of intellectual property protection problems. Ning Mengyue et al. [8] proposed a heterogeneous multi-chain model based on Polkadot and constructed an intellectual property protection scheme that can complete the core business of property rights registration, transfer, and rights maintenance relying on blockchain technology, realizing an intellectual property protection scheme with three major functions: confirmation, authorization, and rights maintenance. Yu Zhengyifan [9] used blockchain technology to build an intellectual property protection model and explored the establishment of a corresponding blockchain technology application system in terms of confirmation, infringement, rights maintenance, transaction, and innovation. For Wang [10], blockchain technology brings new opportunities for the storage and management of information such as intellectual property rights, which does not only allow for the more convenient and transparent management of the life cycle of intellectual property works, including creation, registration, and transaction. Khan [11] et al. proposed a secure and transparent digital content protection and transaction method based on Ethereum and smart contract technology for the prevention of fraud and attacks. Mehta [12] et al. built an image sharing platform based on Ethereum to solve the infringement problem of material, mainly using hash-aware algorithms and smart contracts to perform automatic detection and reject illegal uploads and the reuse of images.

In summary, scholars have analyzed the feasibility of blockchain technology to solve the current problems of intellectual property rights; explored and designed the registration, transaction, deposition, maintenance, and management systems of intellectual property rights based on blockchain technology; and solved the problems of centralized storage, centralized transactions, and intellectual property rights protection existing in traditional intellectual property rights. However, none of them has studied the performance of intellectual property transactions. Moreover, with the popularization and development of blockchain, the performance and scalability of intellectual property rights systems based on blockchain technology become constraints, and there is relatively little research on consensus algorithms for intellectual property transaction scenarios.

2. Related Work

In 1999, Castro and Liskov [13] proposed the PBFT consensus algorithm, which reduced the complexity of the byzantine algorithm from the exponential to polynomial level. At present, the PBFT consensus algorithm is widely used in consortium chains, but with the popularity and development of blockchain, PBFT has problems, such as high communication complexity, poor scalability, and the fact that malicious nodes can be repeatedly elected as primary nodes, leading to consensus failure with the increase in blockchain network nodes. To address these problems, many scholars have researched and improved the PBFT consensus algorithm.

In the existing research, there are three types of improvement directions for the high-communication complexity problem of the PBFT consensus algorithm:

(1)

Using a hierarchical structure to divide consensus nodes into different consensus groups.

(2)

Using aggregated signatures to reduce the number of communications between nodes.

(3)

Replacing all node consensus with representative committee consensus.

First, Li et al. [14] proposed a scalable PBFT-based multi-layer consensus mechanism in their paper, which mainly groups nodes into different layers and restricts the communication within the group; grouping nodes into layers for consensus largely reduces the communication complexity. However, security decreases as the number of layers increases.

Second, Gueta et al. [15] used a collector and threshold signature to reduce the communication complexity to linear, mainly by using a collector to collect the nodes’ voting information and forward the nodes’ voting information to each node through aggregated signatures during the consensus process, avoiding communication between nodes.

Third, Zheng et al. [16] formed a consensus group by electing nodes with high trust and used the consensus group instead of all nodes for consensus. This reduces the communication complexity to a large extent, but the consensus group is too centralized in its setup.

In the existing research, there are three types of improvement directions for the PBFT primary node selection problem:

(1)

Using a reputation model to elect nodes with high reputation values as primary nodes.

(2)

Marking byzantine nodes and restricting byzantine nodes from being elected as primary nodes and allowig the rest of the nodes to be elected as primary nodes in turn.

(3)

Selecting primary nodes randomly via a random algorithm.

First, Lai et al. [17] improved the performance of the algorithm and effectively defended against witch attacks by establishing a reputation model, assigning different discourse rights to nodes according to their reputation values and adding a pre-commitment phase to the PBFT algorithm to reduce the number of communications.

Second, Zhong et al. [18] selected normal nodes to be elected as primary nodes by restricting byzantine nodes from being elected as primary nodes.

Third, Chen et al. [19] randomly selected primary nodes via random parameters.

For different application scenarios, scholars have also carried out a great deal of research; [20] proposed a location-based and scalable G-PBFT consensus algorithm in the application scenario of the Internet of Things. A secure and efficient SG-PBFT consensus algorithm is proposed by [21] in the application scenario of Internet of Vehicles, which improves the consensus efficiency of the algorithm. A more efficient and promising consensus algorithm, SV-PBFT, is proposed by [22] in the energy trading scenario. A multi-stage consensus algorithm of EIoT-PBFT is proposed by [23] in the edge computing scenario of IoT, which greatly improves the consensus efficiency. Finally, [24] proposes IoV-PBFT in the IoV scenario, which can better meet the requirements of the IoV scenario.

3. ST-PBFT

This section will introduce the ST-PBFT algorithm in detail and describe the process of the improved PBFT algorithm.

In this paper, we propose an improved ST-PBFT consensus algorithm for intellectual property trading scenarios, and the overall architecture of the ST-PBFT algorithm is shown in Figure 1. Firstly, the ST-PBFT consensus algorithm divides consensus nodes into four consensus groups and one consensus coordination group according to IP transaction types: patent transaction consensus group, trademark transaction consensus group, copyright transaction consensus group, and other types of transaction consensus group. Second, each transaction consensus group can simultaneously verify the corresponding IP transaction-type transactions and return the results to the consensus coordination group. Then, the consensus coordination group sorts and packages the transactions successfully verified by each transaction shard consensus group into blocks to ensure the consistency of each node block ledger. Finally, the consensus coordination group sends the generated blocks to each transaction shard consensus group for validation, and after the validation is passed, the blocks are added to the local. Meanwhile, the ST-PBFT consensus algorithm designs a reputation model that evaluates the node reputation value based on the consensus behavior of nodes, deducts the reputation value of malicious nodes, and restricts low-reputation-value nodes from being elected as primary nodes.

Suppose an IP transaction scenario as shown in Figure 2, in which two parties trade for a patent right, and, after successful negotiation, they construct a transaction request through a smart contract based on the transaction details, accounts of both parties, transaction amount, and other information to send to the blockchain network for consensus. Then, the blockchain network performs consensus on this patent right transaction and feeds the result to both parties of the IP transaction. Among them, the consensus process of the IP transaction by the ST-PBFT consensus algorithm in the blockchain network is divided into three parts: the transaction shard consensus group verifies the transaction, the consensus coordination group sorts the packaged blocks, and the transaction shard consensus group verifies the new blocks.

Among them, the flow chart of the transaction shard consensus group validation is as shown in Figure 3. The transaction shard consensus group receives the client request from the consensus coordination group, validates the transaction within this group, and sends the result to the consensus coordination group after successful validation. The flow chart of sorting and packaging transactions and verifying blocks is shown in Figure 4. The consensus coordination group sorts and packages the successfully verified transactions to generate blocks and sends the blocks to the primary node of each transaction shard consensus group for verification. $f_1$ represents the maximum number of byzantine nodes that can be tolerated in the transaction shard consensus group. $f_2$ represents the maximum number of byzantine nodes that can be tolerated in the coordination group.

3.1. Layered Sharding Formation

(1)

Registration stage. A consortium chain implements the access mechanism through the CA (Certification Authority) center. When nodes want to join the consortium chain, they need to audit and verify the identity of the nodes and issue certificates to nodes after the verification is passed.

(2)

Sharding stage. The ST-PBFT consensus algorithm needs to group and shard the nodes before consensus. In order to ensure the security of slicing, this paper uses the consistent hash principle, firstly, by hashing the unique identity of consensus nodes to generate the corresponding hash value for each node. Secondly, the consensus nodes are sorted from largest to smallest according to the hash value. Finally, the nodes are sorted into five different groups according to the order of the nodes. The specific slicing algorithm is shown in Algorithm 1. The notations in the shard algorithm are explained in

Table 1. Layered sharding formation notations.

Symbol	Representative Meaning
$\mathrm{PK}(N_i$)	The public key of node i
SN	The number of shards
Node Set	The set of all nodes
$S_i$	The shard of i
$\mathrm{H}(N_i$)	Hash value of node i
N	The total number of node
$\mathrm{Sort}\left(\mathrm{H}\right(N_i$))	$\mathrm{Sort} \mathrm{H}(N_i$) from smallest to largest
Res	The result of the node hash value sorting
Res(j)	The node in the j th position

.

Algorithm 1 Pseudo-Code of the Node Shard

Input:$\mathrm{Node} \mathrm{Set}, \mathrm{PK}(N_i$), shard number

Output: Node Shard Result

1: n ← Length(Node Set)

2: for i = 1 ← n do

3: $\mathrm{H}(N_i$$) \leftarrow \mathrm{SHA}256(\mathrm{PK}\left(N_i\right))$

4: end for

5: $\mathrm{Res} \leftarrow \mathrm{Sort}\left(\mathrm{H}\right(N_i\left)\right)$

6: for j = 1 ←n do

7: X ← j%5

8:  if X = 0 then

9:   Res (j) belong to coordination

10:   elseif x = 1 then

11:    Res (j) belong to shard 1

12:   elseif x = 2 then

13:    Res (j) belong to shard 2

14:   elseif x = 3 then

15:    Res (j) belong to shard 3

16:   elseif x = 4 then

17:    Res (j) belong to shard 4

18:   end if

19: end for

20: END

3.2. ST-PBFT Consensus Trading Consensus Process

The consensus process of the ST-PBFT consensus algorithm is shown in Figure 5. The client initiates a transaction request and the consensus group of each transaction shard verifies the legitimacy of the transaction. Then, the consensus coordination group collects the successfully verified transactions and sorts and packages the transactions into blocks. Then, it sends the generated blocks to each transaction shard consensus group for verification. The process is shown below.

Request phase: In this phase, the client initiates a transaction request and the consensus coordination group sends it to the corresponding consensus group according to the transaction type of the client’s transaction request. For example, the client initiates a patent transaction request and the consensus coordination group sends the patent transaction request to the patent transaction consensus group.

Validate transaction phase: In this phase, the consensus group receives the transaction request from the consensus coordination group and validates the IP transaction request within the group. For example, if the patent consensus group receives a patent transaction request from the consensus coordination group, the patent consensus group starts to validate this patent transaction request within the group and sends it to the consensus coordination group after it passes the validation.

Sorting and packaging phase: In this phase, the consensus coordination group sorts the validated IP transaction requests, packages them into blocks, and sends the generated blocks to each transaction shard consensus group for validation. For example, the consensus coordination group receives four transaction requests that are successfully validated by each transaction consensus group; the consensus coordination group sorts these four messages and generates a block. Then, it sends this block to each transaction consensus group for validation.

Validate block phase: In this phase, each transaction consensus group validates the block generated by the coordination consensus group and adds the block to the local ledger after successful validation.

3.2.1. Transaction Shard Consensus Group Consensus Process

The consensus process of the transaction consensus group is shown in Figure 6. The consensus of the transaction consensus group over the transaction is mainly divided into the pre-prepare phase, confirm phase, and reply phase. The specific consensus steps of each phase are as follows.

Pre-prepare phase: In this phase, the primary node of the transaction consensus group verifies the transaction request information sent by the consensus coordination group and constructs a pre-prepare message after the verification is passed. Then, it sends the pre-prepare message to other consensus nodes in the group. For example, the patent transaction consensus group receives a patent transaction request message from the consensus coordination group, and verifies the patent transaction request message. After the verification is successful, it constructs a pre-prepare message and sends the pre-prepare message to the consensus nodes in the group.

Commit phase: In this phase, the nodes in the transaction shard consensus group receive the pre-prepare message from the primary node, verify the pre-prepare message, and send a commit message to the consensus nodes in the group after the verification is passed. For example, a node in the patent transaction consensus group receives a pre-prepare message from the primary node in the group, verifies whether the pre-prepare message is correct, and sends a commit message to the other consensus nodes in the group after the verification is successful.

Reply phase: In this phase, the nodes in the transaction consensus group receive a $2f_1+1$ commit message and send the information of the transaction request with successful verification to the consensus coordination group. $f_1$ represents the maximum number of byzantine nodes that can be tolerated in the transaction shard consensus group.

3.2.2. Coordination Group Consensus Process

The consensus process of the consensus coordination group is shown in Figure 7. The consensus coordination group consensus over the transaction is mainly divided into the pre-prepare phase, prepare phase, commit phase, and distribution block phase. The specific consensus steps in each phase are as follows.

Pre-prepare phase: In this phase, the primary node of the consensus coordination group receives the transaction information verified successfully by the consensus group of each transaction group, sorts the transaction information, constructs a pre-prepare message, and sends it to the consensus nodes in the group.

Prepare phase: In this phase, the nodes in the consensus coordination group receive the pre-prepare message from the primary node, and verify whether the pre-prepare message is correct. After the verification is successful, they construct the pre-prepare message and send the pre-prepare message to other nodes in the group.

Commit phase: In this phase, the nodes in the consensus coordination group receive the prepare message from other nodes and verify whether the prepare message is correct. When nodes receive the $2f_2$ correct prepare message, they construct the commit message and send the commit message to the other nodes in the group. Here, $2f_2$ represents the maximum number of byzantine nodes that can be tolerated in the coordination group.

Distribute block phase: In this phase, the nodes in the consensus coordination group receive commit messages from other nodes, and verify whether the commit message is correct. When nodes receive the $2f_2$ correct commit message, they construct a block based on the current round of consensus messages and send the block to other transaction shard consensus groups for verification.

3.2.3. Validate the Block Process

The transaction shard consensus group verifies the block process as shown in Figure 8, which is mainly divided into the receive block phase, commit phase, and reply phase. The specific consensus steps in each phase are as follows.

Receive block phase: In this phase, each transaction shard consensus group primary node receives the new block generated by the consensus coordination group.

Commit phase: In this phase, each transaction shard consensus group node verifies whether the transaction information in the new block is correct. If it is correct, the node sends a commit message to the other transaction shard consensus group.

Reply phase: In this phase, if the primary node of the transaction shard consensus group receives three commit messages from the other transaction shard consensus group, it adds the block to the local ledger and sends the signature and block to the nodes in this transaction shard consensus group to synchronize the block. At the same time, it sends the block verification message to the consensus coordination group.

3.3. Reputation Model

In the traditional PBFT algorithm, view switching is used to ensure algorithm activity, but byzantine nodes and faulty nodes are not handled. In the traditional PBFT consensus algorithm, primary node election is performed according to formula (1), resulting in byzantine nodes that can be repeatedly elected as primary nodes. $v$ represents the view number, $N$ represents the number of nodes, and $p$ represents the node number.

$$p=v mod N$$

(1)

Therefore, this paper designs a reputation model to evaluate node reputation. The steps are as follows. First, initialize the node reputation value, and set the initial value for each node as 20. Second, record the nodes that have abnormal behavior in the consensus process. Third, update the node reputation value according to the node behavior after the consensus. When the primary node needs to be switched, a node with a high reputation value is selected as the primary node.

The reputation value update process is shown in Figure 9. After the consensus ends, the node reputation value is updated according to the node behavior. When the primary node needs to be switched, the malicious nodes are avoided by selecting a node with a high reputation value as the primary node.

4. ST-PBFT Experiment Analysis

In this section, we conducted simulation experiments on Ali Cloud servers to build a consortium blockchain network based on the Hyperledger Fabric framework, using docker containers to simulate blockchain nodes. In this paper, we evaluate the ST-PBFT algorithm in terms of communication complexity, throughput, and transaction latency. In order to eliminate the interference of the network and other factors, we chose to initiate 200 transaction requests and record their TPS and the average delay in transaction latency.

4.1. Communication Complexity Comparison

In this paper, we calculate the number of communications required to complete a consensus without primary node switching in different algorithms. As shown in Figure 10, this paper compares the communication complexity of the ST-PBFT consensus algorithm, PBFT consensus algorithm, G-PBFT [20] algorithm, and SG-PBFT algorithm. With the increase in consensus nodes in the blockchain network, the communication times of all three consensus algorithms increase, but the ST-PBFT proposed in this paper has the smallest number of communication times required to complete a consensus. The advantage of the ST-PBFT algorithm becomes more and more obvious with more consensus nodes.

4.2. TPS Throughput Test

To evaluate the performance of the proposed ST-PBFT algorithm, we conduct simulation experiments on a cloud server. In this paper, we build a consortium chain network based on the Hyperledger Fabric framework and use docker containers to represent single nodes. We compare the proposed algorithm with consensus algorithms such as Raft and PBFT. In this paper, we use caliper to test the performance of the network, and we use transactions per second (TPS) as the processing power.

The current consensus algorithms that come with the Fabric framework are Solo and Raft. We have modified the consensus module in Fabric to add the PBFT consensus algorithm. In the experiment, for the ST-PBFT consensus algorithm, we use the peer node in Fabric to simulate the transaction shard consensus group node and the orderer node to simulate the coordination consensus group node; for Raft and the PBFT consensus algorithm, we directly configure the orderer node to run Raft and the PBFT consensus algorithm.

As shown in Figure 11, the throughput of the ST-PBFT consensus algorithm is higher than that of RAFT and PBFT for the same number of nodes, while the throughput of all three consensus algorithms is decreasing with the increase in the number of nodes, but the performance of ST-PBFT is better.

4.3. Transaction Latency Analysis

Transaction latency is the time required from the initiation of a transaction request by a client node to the completion of consensus. In this paper, we tested three algorithms to use caliper to initiate 200 transactions with different numbers of nodes and took the average value as the experimental data. From Figure 12, it can be seen that the transaction latency of ST-PBFT is significantly lower than that of PBFT and Raft, and the transaction latency of all three algorithms tends to increase as the number of nodes increases, but ST-PBFT still shows better performance.

5. Conclusions and Outlook

In this paper, we propose a secure and efficient blockchain-distributed consensus algorithm, ST-PBFT (Shard Transaction PBFT), which is used to solve the problems of rapidly increasing communication complexity with increasing number of nodes, consensus failure due to byzantine nodes elected as primary nodes, and poor scalability in the consensus process of traditional practical byzantine algorithms in intellectual property trading scenarios. First, the ST-PBFT consensus algorithm groups the consensus nodes according to the type of IP transactions, and each transaction consensus group can process consensus requests simultaneously, which can significantly improve the consensus efficiency. Second, the coordination group sorts and packages the consensus requests verified by each transaction consensus group, which ensures the consistency of each node’s block ledger. Finally, the reputation model is introduced to evaluate the node reputation value based on the node behavior during the consensus process and select the node with a high reputation value to be elected as the primary node, so as to improve the reliability of the primary node and reduce the view-switching frequency. The experimental results show that the ST-PBFT consensus algorithm performs well, improves the performance, and reduces the communication complexity, and it could be more suitable for IP transaction scenarios. In addition, in order to ensure security, the ST-PBFT algorithm requires three-stage communication between consensus groups, which increases the demand for bandwidth and storage. Therefore, we will further consider optimizing the algorithm by aggregating signatures in our future research to ensure that the scaling performance of the network remains outstanding, which will significantly improve the performance of our algorithm.