Research on Consensus Algorithm for Intellectual Property Transactions Based on Practical Byzantine Fault Tolerant (PBFT) Algorithm

Abstract

Aiming at the problems of significant communication overheads, the low reliability of primary nodes, and the insufficient dynamic adaptability of traditional consensus algorithms in intellectual property transaction scenarios, an Improved Practical Byzantine Fault Tolerant (IPBFT) algorithm based on the Chord algorithm and entropy weight method is proposed. Firstly, the Chord algorithm is employed to map nodes onto a hash ring, enabling dynamic grouping. Secondly, an entropy-based dynamic reputation model is constructed, quantifying the evaluation of node behaviors and calculating the overall reputation value. A three-level reputation classification mechanism is used to dynamically select primary and supervisory nodes, thereby reducing the probability of Byzantine nodes being elected. Then, a three-phase monitoring strategy for supervisory nodes is developed, which includes collection, review, and blackout. This improves the Raft consensus process, enhancing the detection and fault tolerance against malicious leaders. Finally, a grouped dual-layer consensus architecture is proposed. The lower layer uses an improved Raft algorithm for efficient consensus within groups, while the upper layer uses the PBFT algorithm for cross-group global consistency verification. Experimental findings demonstrate that the IPBFT algorithm is able to balance security, scalability, and consensus efficiency in a dynamic network environment, providing a better consensus solution for intellectual property transactions.

1. Introduction

1.1. Research Background and Significance

In the realm of transactions involving intellectual property (IP), enterprises consider intellectual property rights to be pivotal assets [1], encompassing a range of intellectual property types, including patents, trademarks, and copyrights [2]. With the advancement of science and technology and the trend of globalization, intellectual property trading has become an essential means of cooperation, competition, and innovation among enterprises [3]. Although the intellectual property transaction market is gradually maturing, it also faces a series of challenges [4,5], including traditional intermediary reliance, information asymmetry, and low security. With the immateriality and invisibility of intellectual property rights, buyers and sellers frequently face challenges in accurately evaluating both the value and quality of intellectual property rights, leading to information asymmetry in the transaction process and increasing the transaction risk and uncertainty [6]. In addition, IP transactions involve legal, technical, and business knowledge in specialized areas, and the cost of evaluating, negotiating, and managing the transaction is high [7], making it difficult for small businesses or individual innovators to participate in the IP market. Traditional intermediaries or third-party trust parties play an important role in intellectual property transactions. However, intellectual property transactions involve a large amount of sensitive information and commercial secrets, which may lead to severe economic losses and legal disputes if leaked or tampered with, and it is difficult for the parties to the transaction to have full confidence in the fairness and transparency of the transaction process [8].

The emergence of blockchain technology provides new ideas and possibilities for solving these problems, mainly focusing on three aspects. First, blockchain technology’s decentralized structure removes the need for conventional intermediaries, and the decentralized depository platform can record all the information in the process of application and authorization of intellectual property rights, ensuring the authenticity, integrity, and comparability of intellectual property rights [9]. Second, the immutability and transparency of blockchain technology ensure the reliability and trustworthiness of records in intellectual property transactions [10,11], and the automated transaction mechanism based on smart contracts, where the conditions and details of the transaction can be executed without the intervention of a third party [12], reduces the likelihood of information asymmetry and enhances the transparency and fairness of the transaction [13]. Third, blockchain also incorporates encryption technology [14], which can better ensure confidentiality and safeguard the privacy of transactional data, enhancing security for all involved parties in the transaction [15].

1.2. Related Work

In recent years, research programs have gradually emerged that apply the integration of blockchain technology into intellectual property trading. For instance, Ai S. et al. [16] proposed a blockchain-based IP trading framework, B2IPTS. This framework provides methods for IP registration and cross-blockchain transactions, enabling IP owners and buyers to exchange assets across heterogeneous blockchains without relying on trusted intermediaries through the automatic execution of smart contracts. L. Xiao et al. [17] introduced a blockchain-based copyright protection algorithm for intellectual property. This algorithm incorporates a distributed random embedding mechanism and a position mapping function, allowing traceable mapping of copyright information in IP transactions when they occur on the blockchain. Additionally, by establishing a mathematical model for the secondary matrix transformation of IP circuit transactions, this approach addresses existing inefficiencies in IP copyright protection related to permission management, traceability, and scalability. XIA Yiquun et al. [18] conducted a coupling analysis of blockchain-based IP cloud trading systems. The study proposed an optimization scheme for the trust structure and trust relationships within the trading system. Furthermore, a game-theoretic model for system trust relationships was established to explore node credit strategy selection and parameter sensitivity. ZHOU Yanping et al. [19] designed an IP trading architecture, offering an in-depth analysis of the implementation pathways for various functional modules in IP digital transactions, including identity authentication mechanisms, consensus mechanisms, and on-chain supervision. Moreover, the study proposed policy recommendations to drive the development of blockchain-powered IP transactions. These recommendations include strengthening the top-level design of IP trading, optimizing IP transaction structures, cultivating interdisciplinary blockchain talent, and refining IP transaction supervision models.

In investigating the blockchain-based application system in intellectual property transactions, S. Li et al. [20] utilizes blockchain technology to design a knowledge property transaction system for the Web-EDA platform, achieving trust and transactions between owners of intellectual property and their users. A detailed description of the structure of the intellectual property transaction system is provided, and a blockchain wallet has been developed for the Web-EDA platform. Lim Wei Ming Shawn et al. [21] developed a seamless web platform based on blockchain technology to document evidence of copyrighted information in a tamper-resistant manner by using the Proof of Existence (PoE) framework of Ethereum smart contracts with timestamps as proof that all its transactions exist via smart contracts. Hu J. et al. [22] proposed a patent registration, storage, and trading system that implements access control with different permissions through smart contracts and ensures data privacy protection by integrating asymmetric encryption. However, the system has not yet been deployed on a real blockchain network, and no detailed consensus scheme has been provided. Xu Z. et al. [23] proposed a full-process copyright protection system, which implements automatic confirmation and transaction of copyrights through smart contracts, and the system utilizes a sequence of cryptographic algorithms to ensure its security. Li Xiangyang et al. [24] proposed and implemented a blockchain-based intellectual property trading platform, BIPTP, which achieves precise transaction matching through smart contracts and supports multi-party customized transfer and revenue distribution contracts. Qian Hong et al. [25] designed a technology achievement trading platform based on a consortium blockchain, which theoretically supports the transformation of patent achievements. However, the proposed solution does not take into account issues such as identity privacy leakage.

In summary, the existing literature establishes the theoretical basis for conducting research on blockchain applications in intellectual property transactions, but most of the existing research has explored the utilization of smart contracts in transactions involving intellectual property, data privacy protection, and transaction structure design, and the exploration of the improvement of consensus mechanism in intellectual property transactions is still relatively limited. The consensus mechanism is the core to guarantee the security and trustworthiness of the blockchain system, and the PBFT algorithm can maintain system consistency even in the presence of malicious nodes, making it a key research focus [26,27]. In the field of intellectual property transactions, the PBFT algorithm’s efficient consensus capability helps reduce trust costs, enhance transaction security and transparency, and ensure reliable circulation and proof of IP assets, showing great application potential. However, there are some limitations of the PBFT algorithm in practical intellectual property transaction applications, such as high network communication delay and the existence of malicious node attacks. Enhancements are necessary for the PBFT algorithm to enhance the efficiency and security of transactions involving intellectual property. In this paper, we propose an improved PBFT optimization scheme to solve the problem in consensus-oriented intellectual property transactions.

2. Related Knowledge

2.1. PBFT Consensus Algorithm

The PBFT algorithm is a consensus protocol designed for distributed systems, particularly suitable for scenarios with high reliability and security requirements. The core idea is to achieve system correctness while tolerating a certain proportion of malicious nodes through communication and voting mechanisms among nodes. The PBFT algorithm offers strong fault tolerance, capable of withstanding up to one-third of node failures or malicious behaviors. By requiring more than two-thirds of nodes to agree and confirm each operation, the algorithm ensures that the system remains consistent and correct even when some nodes are attacked or fail.

The operation of the PBFT algorithm consists of three main phases: the Pre-prepare phase, the Prepare phase, and the Commit phase. Each phase requires participant nodes to exchange messages and reach consensus to ensure that every operation is validated and ultimately committed to the system.

Pre-prepare Phase: In the PBFT algorithm, a primary node is first selected. The primary node’s main responsibility is to receive client requests and convert them into proposal information. This proposal, along with its content and corresponding hash value, is broadcast to all other nodes, notifying them to enter the Prepare phase.

Prepare Phase: Nodes that receive the Pre-prepare message validate the request to ensure that the proposal meets the protocol’s requirements. After validation, the node broadcasts a Prepare message to the other nodes, indicating readiness to accept the proposal. A node must collect more than two-thirds of the Prepare messages before proceeding to the next phase.

Commit Phase: Once a node has gathered sufficient Prepare responses, it sends a Commit message to other nodes, indicating that the proposal is ready for formal confirmation and system state update. When a node receives Commit confirmations from more than two-thirds of the nodes, it writes the proposal into the ledger and notifies the other nodes.

2.2. Raft Consensus Algorithm

The Raft consensus algorithm is an efficient consistency protocol designed for distributed systems, primarily aimed at ensuring data consistency in such systems. By simplifying traditional consensus mechanisms, Raft provides a more straightforward and efficient implementation. The core idea of Raft is to coordinate the replication and consistency maintenance of data across nodes in the cluster through leader election.

In the Raft algorithm, nodes are categorized into three roles: leader, follower, and candidate. Each node performs its respective duties based on its role: the leader is responsible for receiving and processing client requests and synchronizing the log data of all replica nodes; followers passively receive and store logs; candidates initiate the election process in the event of a leader failure to ensure the continued operation of the system. The workflow of the Raft algorithm can be summarized in the following key steps.

Leader Election: When the leader fails or a network partition occurs, candidate nodes initiate an election to elect a new leader through voting. Raft reduces election conflicts and delays by using a randomized election timeout.

Heartbeat Mechanism: The leader periodically sends heartbeat signals to followers to maintain its leadership and prevent unnecessary elections, ensuring the stable operation of the system.

Safety Guarantees: Raft ensures the consistency of log entries by guaranteeing that once a log entry is committed, it will be consistent across all nodes, preventing data inconsistency issues.

2.3. Chord Algorithm

The Chord algorithm is a Distributed Hash Table (DHT)-based algorithm designed for efficient node location in decentralized systems. It provides a consistent and scalable method for distributing data across a large number of nodes and is widely used in distributed storage systems and peer-to-peer networks. The Chord algorithm ensures that the system maintains performance even as nodes dynamically join and leave.

The core idea of Chord is to map each node and data item to a circular identifier space. Each node is assigned a unique identifier (ID), and each data item is assigned an ID based on the hash value of its key. The node responsible for storing a given data item is the one whose ID is closest to the data item’s ID. The main features of the Chord algorithm include the following:

Ring Structure: Chord organizes nodes into a logical ring, where each node is assigned a position on the ring based on its identifier. This structure enables efficient routing and scalability.

Node Lookup: Chord uses a consistent hashing mechanism to map data to nodes. When nodes join or leave the system, only a small number of data items need to be redistributed. Nodes can efficiently locate the node responsible for a data item by making logarithmic hops on the ring.

Successor List: To ensure fault tolerance and efficient lookups, each node maintains a successor list. This allows the system to recover quickly in the event of node failures or network partitions.

3. IPBFT Algorithm Design

3.1. The Overall Design of the Algorithm

In order to provide a more efficient and secure Byzantine fault-tolerant algorithm that combines the security of PBFT with the advantages of high consensus efficiency of Raft, a practical Byzantine fault-tolerant algorithm (IPBFT) based on the Chord algorithm with entropy weight method improvement is proposed. The overall framework of the algorithm is shown in Figure 1. The consensus mechanism is composed of four modules, namely, Module 1, the node dynamic grouping strategy; Module 2, the credibility mechanism scoring strategy; Module 3, the monitoring strategy for supervisory nodes; and Module 4, the grouped dual-layer consensus.

Firstly, the dynamic node grouping strategy in Execution Module 1 is implemented. Using the Chord algorithm, all consensus-participating nodes are mapped onto a virtual hash ring and grouped accordingly. Each node is evenly assigned to a group based on its hash value. These groups then participate in the verification and confirmation processes of intellectual property transactions. Through the distribution of the hash ring, the system is able to ensure a high degree of randomness and uniformity in the distribution among nodes, avoiding the problems of human control and uneven loading of nodes. In addition, the dynamic node adjustment mechanism allows nodes to join or leave the network as needed during operation. The Chord algorithm maintains the stability of the network structure by minimizing data redistribution and group reconfiguration within the hash ring, ensuring that the addition or removal of nodes does not cause significant disruptions to the overall topology. This dynamism ensures that during intellectual property transactions, whether it is the addition of new counterparties, supervisory nodes, or nodes that fail to exit, the transition can be smooth and will not disrupt the normal functioning of the entire PBFT consensus process, providing a highly adaptive network structure that is able to maintain low resource consumption and high response speed in the face of frequent changes in the nodes.

Secondly, Execution Module 2 implements a reputation mechanism scoring strategy. By quantifying the historical behavior of consensus nodes using the entropy weighting method, the corresponding weights are determined to construct a dynamic reputation model that differentiates honest nodes from malicious ones. Node reputation values are calculated based on each node’s performance in the consensus process, and a main node is selected from the high-reputation nodes to reduce the probability of malicious actions and improve consensus efficiency.

Nodes in each group are categorized into three reputation levels based on their reputation values. The first-level main node candidate list consists of the top H high-reputation nodes in the group, including the main node and supervisor nodes. The main node has the highest reputation and also serves as the supervisor of the group, while the remaining H-1 nodes serve as supervisor nodes, responsible for managing internal changes and ensuring consensus synchronization. The second level consists of ordinary nodes, and the third level consists of malicious nodes. The consensus node cluster of the system is formed by nodes from the first and second levels within each group, working together to complete the block consensus process.

Then, the Module 3 supervision strategy is executed. Introducing supervisory nodes can improve Raft’s ability to resist Byzantine malicious nodes, which significantly improves its security. The supervisory node conducts a three-step screening process consisting of data collection, behavior review, and blacklisting to identify potential malicious actions by the Raft leader. This process allows for the timely detection of behaviors such as sending false information, initiating malicious requests, or deliberately blocking messages. Once such actions are discovered, a leader re-election mechanism is triggered to replace the Raft leader within the group, thereby ensuring the security and reliability of the consensus process.

Finally, through the grouped dual-layer consensus of Module 4, the communication complexity of the system is reduced. The lower network nodes of the IPBFT algorithm are mutually independent consensus groups, each of which has a supervisory node and a number of ordinary nodes. After the upper layer primary node receives the transaction request submitted by the client, it only needs to broadcast the transaction message to the supervisory node within each group for inter-group PBFT consensus and then reply to the final verification result to the supervisory node after consensus is reached. The supervisory node brings the message to the group for intra-group consensus, i.e., the supervisory nodes and group member nodes of each group establish a committee among themselves through the use of the Raft consensus algorithm to complete the lower layer consensus. The network architecture of the IPBFT algorithm is shown in Figure 2.

3.2. Node Dynamic Grouping Strategy

Given the unique nature of intellectual property transactions, the transactions involve the transfer of an extensive quantity of assets, sensitive information, and rights, so it is crucial to ensure the security, transparency, and efficiency of the transaction process. To address the challenges posed by the dynamic joining and exiting of nodes, the Chord algorithm is employed to group intellectual property transaction consensus nodes using a hash ring mechanism. After receiving the transaction request, the primary node broadcasts the transaction information to the supervisory nodes of each group for inter-group PBFT consensus. Then, the supervisory nodes perform parallel Raft consensus within their respective groups to achieve final consensus. This reduces the overall consensus time for intellectual property transactions, providing a more efficient consensus mechanism for IP trading. During the node grouping process, both nodes and data items are mapped onto a hash ring, with the position of each node on the ring determined by its hash value. The pseudo-code for grouping nodes based on Chord’s algorithm is shown in Algorithm 1. The node initialization and grouping process is as follows:

(1) To ensure the security and fault tolerance of the intellectual property trading system, it is essential to determine the total number of node groups involved in the consensus process, n, along with the minimum number of nodes required within each group, x.

(2) The SHA-256 hash function is employed to compute a unique hash value $h_i$ for each node, where $h_i$ = Hash(${node}_i$). This ensures the uniform distribution of nodes over the Chord hash ring and binds each node to its identity.

(3) Based on the hash values, nodes are evenly assigned to n groups. A node with hash value $h_i$ is allocated to group $G_i$, where $G_i=h_{i}modn$. Each group contains an equal number of nodes, and the randomness of the hash function enhances the unpredictability and resistance to attacks of the grouping process.

(4) To ensure an even distribution of ${node}_i$ in the hash ring, the standard hash function, SHA-256, is used to compute a hash value $h_i$ = Hash(${node}_i$) for each node. With this hash value, the node will have a unique mapped position on Chord’s hash ring, uniquely bound to the node’s identity, ensuring an even distribution of nodes.

(5) Through the mapping on the hash ring, nodes will be evenly distributed into n groups. Specifically, node $h_i$ will be assigned to the $G_i$ group, where $G_i$ is determined by the position on the hash ring. By calculating $h_i$% n, nodes will be evenly distributed into n groupings. Each group contains an equal number of nodes, and the randomness and unpredictability of the grouping can be ensured by the distribution of the hash values.

(6) Adjustment of the grouping results is necessary to prevent certain groups from being overloaded. After the nodes are assigned to the groups, the system needs to verify that the quantity of nodes within each group meets the minimum number of nodes x requirement. If the number of nodes in some groups is insufficient, the system can supplement the insufficient groups by migrating nodes from other groups or reassigning nodes.

(7) Finally, the verified and adjusted grouping result $G=\left\{G_1,G_2,G_3,\dots G_n\right\}$ is returned. Each $G_i$ grouping contains a certain number of nodes, which satisfies the requirements of load balancing and the minimum number of nodes. With this grouping scheme, PBFT consensus is able to ensure efficient consensus while maximizing the fault tolerance and availability of the system.

Algorithm 1: Grouping of nodes based on Chord’s algorithm

Input: Set of nodes Node, number of groups n, minimum number of nodes in each group x.

$\mathrm{Output}:\mathrm{Grouping}\mathrm{result}\mathrm{G}=\left\{{\mathrm{G}}_1,{\mathrm{G}}_2,{\mathrm{G}}_3,\dots {\mathrm{G}}_{\mathrm{n}}\right\}$

1: initialization;

$2:\mathrm{for}\mathrm{all}{\mathrm{n}\mathrm{o}\mathrm{d}\mathrm{e}}_{\mathrm{i}}$$\mathrm{such}\mathrm{that}{\mathrm{n}\mathrm{o}\mathrm{d}\mathrm{e}}_{\mathrm{i}}$$\in$ node do

$3:\hspace{1em}\hspace{1em}{\mathrm{h}}_{\mathrm{i}}$←Hash();

4: end for

5: for each i do

$6:\hspace{1em}\hspace{1em}\mathrm{Map}{\mathrm{h}}_{\mathrm{i}}$ to the hash ring;

7: end for

$8:\mathrm{G}\leftarrow \left\{{\mathrm{G}}_1,{\mathrm{G}}_2,{\mathrm{G}}_3,\dots {\mathrm{G}}_{\mathrm{n}}\right\}$;

9: verify the results of each group;

10: return G.

When the nodes change dynamically, due to the Chord algorithm for grouping the nodes, it is only necessary to change the node mapping relationship within a certain grouping on the hash ring, and it is not necessary to restart the blockchain network, which enables the system to adopt a dynamic network structure. The process of dynamic joining of nodes is shown in Figure 3. Replica-new nodes that have been authorized in the mapping phase first map out their position on the hash ring through hash operations to determine the proposed corresponding grouping number. The node Replica-new in the application phase sends a join request JoinRequest message to the group supervisory node, including the node’s signature information and timestamp content. Upon the group’s supervisory node receiving the JoinRequest request sent by the node Replica-new in the verification phase, its identity is first verified. Then, it broadcasts the JoinRequest message to its subgroup after it passes the verification. The members of the group vote on the message and send the signed voting result to the group supervisory node. When the supervisory node in the group receives more than half of the votes from the members of the group agreeing to join the subgroup, the group reaches a unanimous agreement on the JoinRequest of this node and agrees that the node Replica-new joins the subgroup. Finally, in the confirmation phase, the supervisory node of the group in which node Replica-new is located sends a node to join JoinConfirm message to node Replica-new as well as to the supervisory nodes of the remaining groups. The supervisory nodes of the remaining subgroups receive the JoinConfirm message and broadcast it to their subgroups. At this point, the nodes of the whole network reach a consensus on the joining of node Replica-new, and each node updates the total quantity of system nodes N and a list of nodes across the entire network.

The node dynamic exit process is shown in Figure 4.

Application Phase: When node Replica-exit needs to exit the network, it submits ExitRequest to the group’s supervisory node; if the exiting node is a supervisory node, it can only apply for exiting the network after the supervisory node of the group is re-selected. In the verification phase, when the supervisory node in the group receives the ExitRequest request sent by the node Replica-exit, it verifies the message and broadcasts the ExitRequest message to its subgroup after it passes the verification. The members of the group vote on the message and send the signed vote result to the group supervisory node. When the supervisory node in the group receives more than half of the votes agreeing to exit the group, the group reaches a consensus on the node’s ExitRequest and agrees to its exit from the group.

Exit Phase: When the supervisory node of the group in which the node Replica-exit is located sends a node exit ExitConfirm message to the node Replica-exit as well as to the supervisory nodes of the rest of the group. The supervisory nodes of the remaining subgroups broadcast the ExitConfirm message to their subgroups. At this point, the nodes of the whole network reach a consensus on the exit of node Replica-exit and complete the deletion of the node, and each node updates the total quantity of system nodes N and the list of nodes in the whole network. If the exit of a node causes the count of nodes within the group to be less than the lower threshold, it needs to be regrouped according to the grouping rules, and the node list information of the group in which each node is located needs to be updated.

3.3. Credibility Mechanism Scoring Strategy

In the PBFT algorithm design, the selection of the primary node involves rotating consensus nodes within the network, ensuring each takes turns serving as the primary. This selection of the primary node is a problem that does not deal with the Byzantine nodes and faulty nodes, resulting in the selection process for the primary node not necessarily being the node that performs well during the consensus process. The Byzantine nodes can be repeatedly elected as the primary node, and the election of Byzantine as the primary node will inevitably lead to the failure of the consensus, which will significantly affect the consensus efficiency of the algorithm. In addition, if the leader in the Raft algorithm is a Byzantine node and transmits deceptive information to the followers, it will affect the consistency of the consensus process. For the possible Byzantine node problem in the consensus process, combining the entropy weight method to design the reputation mechanism scoring strategy, the nodes are organized into four types: primary nodes, supervisory nodes, ordinary nodes, and malicious nodes. As shown in Figure 5, the nodes are divided into three reputation levels.

Among them, the first level is the candidate list of primary nodes, consisting of the first H high-reputation-value nodes, the global primary node possessing the highest reputation score, and only one primary node in each consensus round. If the primary node goes down or commits an evil act during the consensus process, it is punished for its reputation. It triggers the view-switching protocol to select a new primary node. The reputation level to which it belongs is re-determined after the failed primary node’s reputation value is updated. Supervisory nodes are set up in each subgroup, which is mainly responsible for dealing with the dynamic joining or exiting of nodes in the corresponding subset, the dynamic updating of node reputation values, and the synchronization of consensus results to malicious nodes. In addition, the supervisory node in the group where the primary node is located is assumed by the primary node. Suppose the supervisory node of a subgroup is down or has malicious behavior. In that case, the node exhibiting the highest reputation score and the node exhibiting the highest reputation score in the candidate list of primary nodes of the group is selected as the new supervisory node. The second level is ordinary nodes, where the ordinary nodes and the nodes within the primary node candidate list act as a cluster of consensus nodes and participate in the consensus process to guarantee the consistency of the system data. Nodes in the primary node candidate list may have a reduced reputation value due to malicious behavior and will be classified into the ordinary node level if the reduced reputation value is not within the ranking of the top H high reputation values of the grouping but is higher than the reputation threshold of the malicious node level. When the node reputation value is too low, it will be considered a malicious node and enter into the third level, which is not allowed to take part in the consensus mechanism and is limited to synchronizing the final consensus result locally.

A multi-indicator weighting method, entropy weighting, is used to quantitatively assess the historical behaviors of consensus nodes during the consensus procedure in intellectual property transactions and to determine their corresponding weights in order to more objectively formulate rewards and punishments to more effectively reward nodes that comply with the rules and participate honestly, as well as to punish nodes that intentionally violate the rules and disrupt the order of the transaction. In intellectual property transactions, honest behaviors may include correctly reviewing transactions, accurate identity verification, and compliance with legal rules. Suppose there are m metrics for evaluating n consensus nodes. Based on the defined evaluation metrics, collect the values of each node on each metric to construct the evaluation matrix of node honest behavior metrics. Each row in the evaluation matrix X denotes a consensus node, and each column represents an evaluation indicator.

$$X=\left(\begin{array}{cccc}{x}_{11}& x_{12}& \cdots & x_{1m}\\ x_{21}& x_{22}& \cdots & x_{2m}\\ ⋮& ⋮& \ddots & ⋮\\ x_{n1}& x_{n2}& \cdots & x_{nm}\end{array}\right)$$

(1)

where $X_{ij}$ denotes the value of the ith consensus node under the jth metric.

Each column in the above evaluation matrix is normalized for the extremes and normalized using the critical value method to find each column’s maximum and minimum values, subtracting the minimum value from every element and then dividing by the range defined by the maximum and minimum values to obtain the normalized matrix. This is shown in Equation (2) of the calculation.

$$z_{ij}={\displaystyle \frac{x_{ij}-\min (x_j)}{\max (x_j)-\min (x_j)}}$$

(2)

where min($X_i$) and max($X_j$) are the minimum and maximum values of the jth indicator, respectively.

Calculate the weight of each indicator as shown in Equation (3).

$$p_{ij}={\displaystyle \frac{z_{ij}}{{\displaystyle \sum _{i=1}^n{z}_{ij}}}}$$

(3)

where $p_{ij}$ is the proportion of the ith consensus node under the jth indicator, which indicates the relative weight of the node in the indicator. $z_{ij}$ represents the normalized value of the ith consensus node under the jth indicator.

Then, calculate the information entropy of each indicator. The information entropy is shown in Equation (4).

$$E_j=-{\displaystyle \sum _{j=1}^n{p}_{ij}\log (p_{ij})}$$

(4)

where $E_j$ denotes the information entropy of indicator j, and $p_{ij}$ is the proportion of the ith consensus node under the jth indicator. Then, the weight $w_j$ of each indicator is calculated based on the proportion of information entropy to the total information entropy, as in Equation (5). The behaviors can be ranked according to the weights, and the smaller the information entropy, the larger the weight.

$$w_j={\displaystyle \frac{1-E_j}{{\displaystyle \sum _{i=1}^n(1-E_j)}}}$$

(5)

The behaviors are then classified into different levels based on the equal-frequency grouping method to create a table of rewarded behaviors, as shown in

Table 1. Rewarding behavior rating scale.

Level	Behaviors	Level	Behaviors
1	${\mathrm{B}}_3$$,{\mathrm{B}}_5$	3	${\mathrm{B}}_1$$,{\mathrm{B}}_2$
2	${\mathrm{B}}_4$$,{\mathrm{B}}_7$	4	${\mathrm{B}}_6$$,{\mathrm{B}}_8$

. The greater the weight, the greater the integrity level of the indicator and the greater the reward value acquired. When a node performs well, its reputation value will be improved, which motivates the node to comply with the rules, improve the service quality, and promote the healthy development of the network. After a round of consensus, the behavioral information is converted into corresponding reward records. For example, a node will probably receive three rewards at the first integrity level, one at the second integrity level, and two at the third integrity level.

In IP transactions, malicious behavior may include maliciously altering, modifying, or deleting IP transaction information, stealing IP transaction data, and using false identities for authentication. The honest behavior of nodes is associated with the factors for efficient and normal operation of the blockchain, and malicious behavior should be established in the same way as described above. Based on the different types and severity of malicious behaviors, a table of punitive behaviors is established by determining the weights through the entropy weighting method. When a node performs poorly, its reputation value decreases, effectively preventing fraudulent behaviors and maintaining the security and trustworthiness of IP transactions. Then, the comprehensive value of node i is calculated based on the total reward value obtained by the node and the total punishment value received, as shown in Equation (6).

$$S_i=Max(S_{init}^i+{\displaystyle \sum _{L=1}{V}_{reward}^L\times n_{reward}^L}-{\displaystyle \sum _{L=1}{V}_{punish}^L\times n_{punish}^L},0)$$

(6)

where $S_{init}^i$ denotes the initial reputation value of node i, $n_{reward}^L$ denotes the count of honest behaviors at level L, $V_{reward}^L$ denotes the reward value of honesty level L, $n_{punish}^L$ denotes the count of malicious behaviors at level L, and $V_{punish}^L$ denotes the punishment value of maliciousness level L.

When each round of consensus is over, the composite node’s value is updated, and the role held by the node is redefined based on the new composite value. The composite value determines the trustworthiness of the node; the larger the composite value, the more trustworthy the node is.

3.4. Monitoring Strategy for Supervisory Nodes

Raft is a strong-leader consensus algorithm where the leader has a strong position and sends an acknowledgment message to all nodes upon receiving responses from a majority of the followers, successfully committing the block to the chain. In the event that the leader node behaves maliciously and transmits misleading messages to the followers, it poses a threat to the coherence of the consensus procedure. This problem is solved by introducing a supervisory node, which enhances the security of the consensus mechanism.

When a supervisory node is detected to exhibit malicious behavior, the system activates a corresponding response mechanism. First, the node’s reputation score is reduced based on behavior analysis, and if it falls below a defined threshold, the node is disqualified from participating in supervisory elections in subsequent consensus rounds. Second, to ensure the continuity and stability of the supervisory mechanism, the system automatically selects a standby node with a higher reputation score as a replacement, maintaining uninterrupted supervisory functionality.

In the lower consensus network, the supervisory nodes and group member nodes use the Raft consensus algorithm to form a committee, and the supervisor node oversees the leader’s actions within the committee. In the monitoring strategy of the supervisory node, to prevent the supervisory node’s exposure from facilitating malicious manipulation by the leader, the supervisory node should join the system anonymously. At the same time, to ensure effective supervision, the supervisory node refrains from engaging in leader election and only surfaces as a follower to participate in the Raft consensus of this group. The supervisory node, upon receiving messages from different followers, compares and confirms the messages to ensure that there are no malicious nodes, and then they can broadcast the log messages to the committee nodes. Supervision of a node by a supervisory node can be structured into the following three steps:

(1)

Collection

In the lower committee Raft consensus phase, the supervisory node first gathers transaction messages transmitted from the leader to the follower; if any follower node fails to receive the heartbeat message within the timeout period, it will report the leader anomaly to the supervisory node. When the supervisory node receives anomaly reports regarding the leader node from a majority of nodes, it initiates a review of the leader.

(2)

Review

After gathering transaction messages transmitted by the leader to the followers, the supervisory node reviews whether they are consistent with the transaction messages received by itself. If the verification process is successful for the supervisory node, it can prove that the leader sends consistent messages to the committee and has no fraudulent behavior toward the committee. If the supervisory node detects inconsistent receipt of log messages by the follower, it concludes the leader node’s behavior is maliciously Byzantine.

(3)

Blackout

After the supervisory node determines that the leader node is a malicious Byzantine node, it will send a <del,$S_i$,term> message to the committee in order to request that the leader status of the node be struck off and trigger the leader election process. Where del is the message identity, $S_i$ is the supervisory node count, and term is the leadership tenure in the current group. The committee removes the leader status of the node based on the message from the supervising node.

3.5. IPBFT Algorithm Consensus Process

In the IPBFT consensus algorithm, there is a two-tier consensus mechanism, where the lower layer consensus network is a mutually independent group, each of which consists of a committee of one supervisory node and a number of group member nodes to perform the improved Raft consensus. The supervisory nodes of each group together constitute the upper-level consensus network for PBFT consensus.

Firstly, the client node forwards an intellectual property transaction request message to the primary node, which acts as a forwarding node to send this intellectual property transaction request message to the supervisory node of each of the remaining consensus groups, and PBFT communication is performed among the groups to reach consensus. The primary node sends a Pre-prepare message <Pre-prepare,v,n,p,d,m> to the other secondary nodes. The Pre-prepare message identifies the view number v that it is currently in, the order of the transaction, i.e., the sequence number n, the primary node identifier p, the intellectual property transaction message m sent by the client, and a message digest of m, d. Subsequent to the reception of the Pre-prepare message, the PBFT secondary node will perform a message verification check, and if it is legitimate, all secondary nodes will broadcast their signed message < <Prepare,v,n,p,d,m>, i> to all nodes except themselves, where i is the node number. When the supervising node retrieves the Prepare message from more than 2f nodes and verifies the confirmation, it will bring the message into the group for intra-group consensus. The intra-group consensus process is shown in Figure 6.

In the Raft consensus phase within each subgroup, group member nodes and supervisor nodes together form a committee. Supervisory nodes exist anonymously for receiving and copying transaction data, do not engage directly in the leader selection, and ostensibly follow the leader as a follower in the Raft consensus. Firstly, the leader election is triggered, and each node will start to become a follower and transmit a voting request to other included nodes. The leader broadcasts the message to all nodes in the group. The group member node receives the message, verifies the confirmation, and sends a confirmation message to the group leader node and the supervisor node. The supervisor node receives the confirmation message sent by more than 3/4n nodes, and the leader receives the acknowledgment message dispatched by more than 1/2n nodes (n is the total count of the group member nodes in the group). Then, it proceeds to the next stage. Otherwise, the consensus is considered invalid for this round. Supervisory nodes review the leader node. The review then passes, continues to complete the consensus, and the leader uploads the message to the chain and returns to the upper-layer network; the review fails, the leader re-selection mechanism is carried out, and the group Raft consensus is carried out again.

Finally, the PBFT consensus primary node transmits a response message to the client. The specific consensus flow of the IPBFT algorithm is shown in Figure 7.

4. Results

To assess the efficacy of the algorithm, the environment of multi-node participation in the IP trading network is simulated by listening to several different TCP ports on the same device. This section evaluates the PBFT consensus algorithm with respect to communication complexity, consensus delay, and throughput. The specific parameter settings in the experiment are as follows: the weight for transaction accuracy is 30%, which measures the correctness of the node in verifying and recording transactions; the weight for fraud detection is 40%, which evaluates the node’s ability to prevent fraudulent transactions; the weight for response time is 30%, which reflects the node’s processing speed after receiving a transaction request, ensuring the timeliness of the transaction. The experimental configuration is shown in

Table 2. Experimental configuration.

Software	Configure
Programming language	Python Golang 1.20.4
Server operating system	Windows 10
Experimental configuration	Intel (R) Core (TM) i7-8565U CPU @ 1.80 GHz

.

4.1. Communication Complexity Analysis

For the entire IP trading network, a higher total communication volume is required to achieve consensus, which increases the likelihood of network congestion and performance degradation. Consequently, it is essential to measure the communication overhead associated with each individual consensus. The communication overhead associated with a single consensus instance of the IPBFT algorithm is analyzed and compared against the traditional PBFT algorithm as outlined below. Assume that the number of groups in the blockchain is K and the nodes count within each group is n, so the total nodes count in the system is N = K × n.

Single PBFT algorithm communication overhead: nodes complete one PBFT consensus process. Pre-prepare phase carries out N $-$ 1 communications; the Prepare phase carries out (N $-$ 1) $\times$ (N $-$ 1) communications; the Commit phase carries out N $\times$ (N $-$ 1) communications. Therefore, the communication overhead involved in achieving a single consensus among nodes in the PBFT algorithm is shown in Equation (7).

$$N_1=(N-1)+(N-1)\times (N-1)+N\times (N-1)=2N^2-2N$$

(7)

The number of communications for a single IPBFT consensus process is designed on the basis of PBFT and Raft, assuming that the count of nodes involved in the consensus is N and the count of groupings in the blockchain is K. The IPBFT consensus algorithm performs a single consensus, and the count of communications for performing the PBFT consensus between the supervisory nodes of the K groupings in the upper-layer consensus network is 2${\mathrm{K}}^2-2\mathrm{K}$. In the lower-layer consensus network, the supervisory nodes and their group member nodes form a committee with N/K nodes to perform Raft consensus. The leader within each group first broadcasts a message to the supervisor node and the follower, and the count of communications is N/K $-$ 1 times; the follower returns the processing message to the leader and the supervisor node, and the count of communications is 2(N/K $-$ 2); finally, the supervisor node reviews the leader’s processing message, and the number of communications is 2. Therefore, the total number of communications for a single IPBFT consensus process is shown in Equation (8).

$$N_2=2K^2-2K+K\times \left[({\displaystyle \frac{N}{K}}-1)+2\times ({\displaystyle \frac{N}{K}}-2)+2\right]=2K^2-5K+3N$$

(8)

The communication overhead associated with both consensus algorithms is calculated according to Equations (7) and (8), and a graph of the trend of the communication overhead of each algorithm is based on the calculation results. Figure 8 compares the number of single consensus times of the PBFT consensus algorithm and IPBFT consensus algorithm across varying node counts, demonstrating that the IPBFT consensus algorithm categorizes the nodes into five groups, seven groups, and ten groups. When the node count remains constant, the IPBFT consensus algorithm exhibits lower communication overhead compared to the PBFT consensus algorithm. At a node count of 65, the communication overhead is 8320 for the PBFT algorithm and 220 for the IPBFT consensus algorithm, which divides the nodes into five groups, which is a significant decrease in communication overhead. With an increasing count of nodes involved in the consensus process within the system, both algorithms’ communication overheads gradually increase, but the IPBFT algorithm continues to demonstrate a lower communication overhead compared to the PBFT algorithm.

4.2. Throughput Analysis

The throughput denotes the count at which transactions are processed by the system within a unit timeframe, which is commonly used in blockchain systems to calculate the transaction completion count per second (transaction per second, TPS). Assuming that the block can process ${\mathrm{t}\mathrm{r}\mathrm{a}\mathrm{n}\mathrm{s}\mathrm{a}\mathrm{c}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}}_{∆\mathrm{t}}$ transactions in the ∆t block time, the throughput calculation formula is as in Equation (9). It is analyzed that the node counts in the system will significantly impact the throughput. Also, the transaction counts contained in the block have a significant impact on the throughput.

$$TPS={\displaystyle \frac{transaction\Delta t}{\Delta t}}$$

(9)

Assuming that each block contains the same number of transactions, conduct multiple experiments to test the IPBFT throughput, with the average value being considered as the final test result, which is in comparison to the conventional PBFT algorithm to analyze the impact of changing only the nodes in the system on the throughput when the transaction count within the block remains unchanged. As shown in Figure 9, as the quantity of consensus nodes involved in the system rises, the throughput of both algorithms declines. However, the throughput of the IPBFT algorithm still has a stronger advantage compared to the traditional PBFT algorithm. The TPS of the IPBFT algorithm is also different when the number of groups is K = 5, 7, and 10 and still retains a certain amount of throughput in the usage environment with more nodes, which again proves that the IPBFT algorithm has strong robustness and stability.

Assuming that the node count within the system must remain uniform, the count of transactions to be handled in the block must be changed. Since the block’s capacity to handle transactions within each time is limited, if the number of transactions to be processed in the block continues to increase even after the maximum threshold that the block can process is exceeded, the burden on the block to process transactions increases, and the algorithm’s throughput slowly decreases. As shown in Figure 10, when the transaction volume to be processed within every block is lower than the maximum threshold, the IPBFT algorithm’s throughput is still in an upward trend as the number of transactions increases. When the highest threshold of block processing transactions is reached, the IPBFT throughput also reaches the highest, which is 3.5 times the throughput of the traditional PBFT algorithm. After the threshold is reached, if the transaction volume to be processed in the block continues to increase, the throughput of both algorithms decreases. However, the IPBFT algorithm achieves a superior throughput compared to the PBFT algorithm.

4.3. Latency Analysis

Consensus latency is the total time required for a client to initiate a request until that request is acknowledged on the chain and is a key performance indicator in the study of consensus algorithms. In the completion of a consensus by a node in the system, it is assumed that the client initiates a request at the moment of ${\mathrm{T}}_{\mathrm{r}\mathrm{e}\mathrm{q}\mathrm{u}\mathrm{e}\mathrm{s}\mathrm{t}}$ and receives a reply message at the moment of ${\mathrm{T}}_{\mathrm{r}\mathrm{e}\mathrm{p}\mathrm{l}\mathrm{y}}$. As a result, the formula for the consensus delay is shown in Equation (10).

$$DelayTime=T_{reply}-T_{requst}$$

(10)

In order to control the experimental error, several consensus delay tests were conducted, and the average value was used as the final experimental result. This experimental result is in contrast to the conventional PBFT algorithm to analyze the change of consensus delay of the IPBFT algorithm in different scenarios. Figure 11 presents the experimental findings.

Evidently, the consensus latency of both algorithms increases gradually as more consensus nodes participate in the system, but the IPBFT algorithm grows more gently. In contrast, the consensus latency of the traditional PBFT algorithm exhibits exponential growth as the node counts in the system increase. Simultaneously, with the rise in the node counts in the system, with the aim of ensuring that the number of clustering groups remains unchanged, only expanding the node count within each sub-consensus group will increase the count of nodes involved in the PBFT consensus, which in turn will cause an increase in the consensus delay. Guarantee that the node count in each consensus group remains unchanged and that only increasing the number of subgroups will cause a certain rise in the consensus delay. However, under the condition that the same count of nodes within the system, the consensus delay of the IPBFT algorithm is still much smaller than that of the PBFT algorithm. Therefore, the IPBFT algorithm is able to effectively reduce the consensus delay in the network environment where large-scale nodes participate in the consensus due to the improvement of clustering efficiency through its dynamic grouping strategy and the consensus characteristics of the two-level consensus mechanism.

5. Conclusions and Outlook

To address the issues of communication complexity, consensus delay, and limited throughput in the traditional PBFT algorithm, this paper proposes an Improved Practical Byzantine Fault Tolerance algorithm, IPBFT, based on the Chord algorithm and the entropy weight method. Through the dynamic grouping strategy of nodes, the scoring strategy of the reputation mechanism, the supervisory strategy of supervisory nodes, and the grouping two-layer consensus mechanism, the IPBFT algorithm significantly improves the consensus efficiency while guaranteeing security and fault tolerance. The dynamic grouping of nodes based on the Chord algorithm ensures the randomness and uniformity of node allocation. The dynamic reputation model constructed by the entropy weight method can effectively distinguish honest nodes from malicious nodes. The introduction of supervisory nodes enhances the detection and prevention ability of Byzantine nodes and ensures the safeguarding of the consensus process. The grouped two-layer consensus mechanism combines the security of the PBFT algorithm with the efficient consensus mechanism of Raft, which not only minimizes the communication overhead within the system but also improves the parallel processing ability of consensus so that the IPBFT algorithm can still maintain a high performance in a large-scale node environment. The experimental results demonstrate that the IPBFT consensus algorithm exhibits reduced communication complexity, enhanced consensus efficiency, and better throughput capability, and it is better suited for the environment of intellectual property transactions with many nodes in a complex network environment.

Intellectual property transactions often involve multi-chain collaboration, and in the future, it will continue to be necessary to study the compatibility of the IPBFT algorithm in cross-chain scenarios to cope with complex and changing practical needs.