A Byzantine Fault Tolerant Consensus Method and System in Supply Chain Traceability

Abstract

The present invention discloses a Byzantine fault-tolerant consensus method and system for supply chain traceability, including master node selection rules, dynamic node entry and exit network processes, and optimized protocol mechanisms. The master node selection rules are based on the consistent hashing algorithm and the hash value of the previous block and combined with the average load concept to achieve random and fair selection of master nodes; the dynamic node entry and exit network process adds the concepts of network configuration table and configuration change transaction to achieve the dynamic nature of the network; the optimized protocol mechanism is used to improve the existing protocol mechanism of the PBFT algorithm, mainly including refining the view replacement protocol, proposing a new state synchronization protocol, and optimizing the consistency protocol under no abnormal conditions. Compared with the original PBFT algorithm, the Byzantine fault-tolerant consensus method provided by the present invention has the advantages of random selection of master nodes, support for dynamic networks, low communication complexity, etc., and is particularly suitable for supply chain traceability scenarios with complex members, strong openness, and large node scale.

Description

Technical Field

[0001] The present invention belongs to the technical field of supply chain traceability, and relates to a Byzantine fault-tolerant consensus method and system, and specifically to a Byzantine fault-tolerant consensus method and system in a supply chain traceability scenario. Background Art

[0002] The supply chain refers to the network of suppliers, processors, logistics providers, distributors, retailers, and other members involved in the production, transportation, and sales of goods. Supply chain traceability utilizes modern information technology to record all supply chain data, from raw material procurement to consumer purchase, enabling monitoring of all links in the product's distribution chain. Supply chain traceability systems can help consumers easily access information about the production and transportation of goods, improve the efficiency of oversight by regulatory agencies, and promptly trace responsibility to those responsible.

[0003] In recent years, the use of blockchain technology for supply chain traceability has gained widespread recognition among scholars. Blockchain is not a single technology, but rather a combination of multiple technologies, including peer-to-peer (P2P) network communication, distributed ledgers, cryptography, consensus algorithms, and smart contracts. These technologies inherently make blockchain unforgeable, traceable, and decentralized, resolving the long-standing trust challenges in supply chain traceability. Blockchain provides transparent data records in supply chain traceability scenarios, making it difficult for malicious attackers to tamper with them. It also enables consumers and regulators to access comprehensive product flow data for timely accountability tracking. It also fosters trustless consensus among multiple enterprises, enabling collaboration and oversight.

[0004] As a core component of blockchain, consensus algorithms profoundly influence its application scenarios. Supply chain traceability is a typical application of consortium blockchains, requiring a consensus algorithm that doesn't rely on token mechanisms but supports Byzantine fault tolerance. Proof-of-Work (PoW) and proof-of-stake (PoS) algorithms, suitable for public chains, rely on token mechanisms to encourage competition, consuming significant computing power. The Raft algorithm, suitable for private chains, lacks Byzantine fault tolerance, making these algorithms inapplicable to consortium chains. The Practical Byzantine Fault Tolerance (PBFT) algorithm, with its high efficiency and Byzantine fault tolerance, is undoubtedly the optimal choice for consortium chains. PBFT was first used to address consistency issues in traditional distributed systems. It reduces the communication complexity of existing Byzantine fault-tolerant algorithms from exponential to polynomial, and can tolerate Byzantine node faults up to one-third of the total number of nodes, essentially meeting the efficiency and fault tolerance requirements of common scenarios.

[0005] However, the PBFT algorithm isn't fully suited for supply chain traceability scenarios. Unlike other common consortium blockchain scenarios, supply chain traceability features complex membership, high liquidity, large scale, and extensive geographical coverage. Due to these characteristics, existing PBFT algorithms in supply chain traceability suffer from shortcomings such as unordered masternode selection, poor network dynamics, crude protocol mechanisms, and excessive communication complexity. Therefore, it's not feasible to directly migrate the PBFT algorithm as the consensus mechanism for supply chain traceability blockchains. Targeted improvements are needed to the algorithm's masternode selection rules, network dynamics, and protocol mechanisms. Summary of the Invention

[0006] In view of the above-mentioned shortcomings of the original practical Byzantine fault-tolerant algorithm and the security and performance requirements for product information traceability in the supply chain scenario, the present invention provides a Byzantine fault-tolerant consensus method and system based on the existing PBFT algorithm, which is random, dynamic, and efficient in the supply chain traceability scenario.

[0007] The technical solution adopted by the method of the present invention is: a Byzantine fault-tolerant consensus method in supply chain traceability, including a master node random selection rule, a node dynamic entry and exit network mechanism and a protocol mechanism;

[0008] The master node is randomly selected according to the rule, and a unique master node is selected from all replica nodes. The master node can receive transactions and package blocks;

[0009] The dynamic node entry and exit mechanism uses the Network Configuration Table (NCT) and the Configuration Change Transaction (CMT) to enable dynamic node entry and exit in a continuously running state. When a node A that needs to join the network generates public and private keys and sends them to the certification authority (CA), the certification authority (CA) returns a certificate to the node. Node A first sends a node entry / exit request to the Configuration Change Smart Contract (CMSC). The Configuration Change Smart Contract (CMSC) generates a Configuration Change Transaction (CMT), and a consensus is reached across the entire network through a consensus protocol. Node A checks the legitimacy of the Configuration Change Transaction (CMT) and executes it. The execution result of the Configuration Change Transaction (CMT) is returned to Node A, and the node determines whether it can join or exit the network based on the execution result.

[0010] The Network Configuration Table (NCT) records information about all nodes that have joined the network, including IP addresses, public keys, node status, the number of times a master node has been elected, and related notes.

[0011] The configuration change transaction (CMT) carries identifying information, which allows all nodes to identify this special transaction and update their local network configuration table according to the transaction content.

[0012] The protocol mechanism includes four protocols: a periodic view rotation protocol for regularly replacing the master node under normal circumstances, an abnormal view replacement protocol for replacing the master node under abnormal circumstances, a state synchronization protocol for lagging nodes to pull the latest state from the network, and a consistency protocol for all nodes to reach consensus on candidate blocks.

[0013] The technical solution adopted by the system of the present invention is: a Byzantine fault-tolerant consensus system for supply chain traceability, comprising:

[0014] one or more processors;

[0015] A storage device is used to store one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the Byzantine fault-tolerant consensus method in the supply chain traceability.

[0016] The beneficial effects of the present invention include:

[0017] (1) Compared with the original master node selection rule of the PBFT algorithm, the node selection rule of the present invention can achieve random and fair selection of master nodes in a dynamic network.

[0018] (2) The node dynamic entry and exit mechanism of the present invention additionally designs a new data structure - Network Configuration Table (NCT) to help nodes accurately obtain node quantity information; at the same time, based on the Configuration Change Smart Contract (CMSC), a supporting update method of NCT - Configuration Change Transaction (CMT) is designed, which can realize the dynamic entry and exit of nodes in the network with extremely low overhead.

[0019] (3) The existing view rotation protocol of the PBFT algorithm is triggered only when the master node goes offline or engages in malicious behavior. Master node replacement is infrequent, which not only exacerbates centralization but also increases unfairness between nodes. The periodic view rotation protocol provided by the present invention implements regular rotation of master nodes to ensure fairness. At the same time, the protocol also simplifies the message format of the original view rotation protocol and reduces communication complexity.

[0020] (4) To ensure consensus progress and user experience, the present invention provides an abnormal view replacement protocol. When the master node is offline or acts maliciously, the corresponding backup master node will be enabled to continue generating blocks. At the same time, the protocol will strictly distinguish between offline anomalies and malicious anomalies, punish the malicious behavior of the master node, and the malicious node will never be elected as the master node again.

[0021] (5) Nodes in the network often experience downtime, disconnection, delays, and other failures. These failures often lead to inconsistent blockchain states between nodes. The present invention provides a state synchronization protocol based on view number, block number, and block hash value. When a node is in a lagging state such as just joining the network, disconnecting and restarting, the protocol can be actively triggered to pull the latest state of the blockchain network.

[0022] (6) This invention draws on the collector concept to provide an optimistic consensus protocol in the blockchain scenario, which simplifies the message format and reduces the communication complexity of the consensus protocol under normal circumstances. This protocol changes the message transmission method in the prepare and commit phases. Instead of broadcasting messages to the entire network, all nodes unicast messages only to the master node, which collects the prepare / commit messages on behalf of all nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 It is an operation cycle diagram of the present invention.

[0024] Figure 2 This is the solution execution process of the present invention within the term of a master node.

[0025] Figure 3 This is a schematic diagram of the master node selection rule module in an embodiment of the present invention.

[0026] Figure 4 This is a schematic diagram of a node joining a network in which a node dynamically enters and exits a network module in an embodiment of the present invention.

[0027] Figure 5 This is a schematic diagram of a node exiting a network when a node dynamically enters and exits a network module in an embodiment of the present invention.

[0028] Figure 6 This is a schematic diagram of the periodic view rotation protocol of the protocol mechanism optimization module in an embodiment of the present invention.

[0029] Figure 7 This is a schematic diagram of the state synchronization protocol of the protocol mechanism optimization module in an embodiment of the present invention. DETAILED DESCRIPTION

[0030] In order to facilitate the understanding and implementation of the present invention by those skilled in the art, the present invention is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the implementation examples described herein are only used to illustrate and explain the present invention and are not used to limit the present invention.

[0031] Based on an in-depth analysis of the shortcomings of the PBFT algorithm in supply chain traceability scenarios, this paper makes targeted improvements to the PBFT algorithm from multiple perspectives, making the improved PBFT algorithm more suitable for supply chain traceability scenarios.

[0032] Please see Figure 1 and Figure 2 ,The present invention provides a Byzantine fault-tolerant consensus method for supply chain traceability, including a master node random selection rule, a node dynamic entry and exit network mechanism, and a protocol mechanism;

[0033] The random master node selection rule of this embodiment selects a unique master node from all replica nodes. The master node receives transactions and packages blocks. Compared with the original master node selection rule of the PBFT algorithm, it can achieve random and fair master node selection in a dynamic network.

[0034] The dynamic node entry and exit mechanism of this embodiment uses the Network Configuration Table (NCT) and Configuration Change Transaction (CMT) to enable dynamic node entry and exit during continuous operation. This mechanism introduces the concepts of the Network Configuration Table and Configuration Change Transaction (CMT), enabling timely information on the number of nodes in the entire network and notification of node entry and exit. When a node A that wishes to join the network generates public and private keys and sends them to the certification authority (CA), the CA returns a certified certificate to the node. Node A first sends a node entry / exit request to the Configuration Change Smart Contract (CMSC). The CMSC generates a Configuration Change Transaction (CMT), and a consensus is reached across the entire network through a consensus protocol. Node A then verifies the legitimacy of the Configuration Change Transaction (CMT) and executes it. The CMT execution result is returned to Node A, and the node then determines whether to join or exit the network based on the execution result.

[0035] The Network Configuration Table (NCT) of this embodiment is an auxiliary structure designed specifically to achieve network dynamics. This table records information about all nodes that have joined the network, including IP addresses, public keys, node status, the number of times a master node has been elected, and related notes. This structure has corresponding copies on all nodes and can be considered an integral part of the blockchain state.

[0036] The configuration change transaction (CMT) in this embodiment is a special transaction type issued by a smart contract for updating the network configuration table. The configuration change transaction carries identifying information, allowing all nodes to identify this special transaction and update their local network configuration table based on the transaction content.

[0037] The protocol mechanism of this embodiment improves the original protocol mechanism of the PBFT algorithm and includes four protocols: a periodic view rotation protocol for regularly replacing the master node under normal circumstances, an abnormal view replacement protocol for replacing the master node under abnormal circumstances, a state synchronization protocol for lagging nodes to pull the latest state from the network, and a consistency protocol for all nodes to reach consensus on candidate blocks.

[0038] Please see Figure 3,The master node selection rules of this embodiment include constructing a hash space, a node mapping rule in the network configuration table, a previous block hash value mapping rule, and a hash position mapping rule;

[0039] The specific process includes the following steps:

[0040] Step A1: Select 0 to 2 32 The hash positions of compose a hash space where 0 and 2 32 coincide;

[0041] Step A2: Let H1(x) = x% 2 32 And use the node IP address as x, and map all nodes in the network configuration table NCT to a certain position in the hash space in sequence. Assume that a node Node i The IP address is IP i , the mapped position is Hash i , the mapping formula is defined as follows:

[0042] Hash i =IP i mod2 32 ;

[0043] Step A3: Let H2(x)=H1(x)=x%2 32 , map the previous block hash value as x to the hash space. Assuming the previous block hash value is PreBlockHash, the position after mapping is Hash, the mapping formula is defined as follows:

[0044] Hash=PreBlockHash mod2 32 :

[0045] Step A4: Set a Time field in the network configuration table to indicate the number of times the node in this row has been elected as the master node; then calculate the average number of times each node has been elected, and then start from the Hash to find the next clockwise adjacent position Hash that is less than or equal to avg. p , its corresponding node Node p That is the master node.

[0046] Please see Figure 4 and Figure 5In this embodiment, the dynamic node entry and exit mechanism is as follows: When a node A that needs to join the network generates public and private keys and sends them to the certification authority (CA), the certification authority (CA) returns a certificate that has been authenticated to the node. Node A first sends a node join / exit request to the configuration change smart contract (CMSC). The configuration change smart contract (CMSC) generates a configuration change transaction (CMT), and a consensus is reached across the entire network through a consensus protocol. Node A checks the legitimacy of the configuration change transaction (CMT) and executes it. The execution result of the configuration change transaction (CMT) is returned to node A, and the node determines whether it can join / exit the network based on the execution result.

[0047] The specific process includes the following steps:

[0048] Step B1: Node key management, Node x First, a pair of public key pub and private key pri is generated and sent to the CA. After the CA evaluates and passes, a certified certificate cert is returned to the node.

[0049] Step B1.1: Node x First, generate a pair of public key pub and private key pri, send your IP address, public key pub and other information to the CA certification agency, and keep the private key pri yourself.

[0050] Step B1.2: After receiving the application from the node, the CA will evaluate the legitimacy of the node based on the information provided. After the CA completes the verification and review, it will respond with the digital certificate cert to the requesting node.

[0051] Step B2: Node requests to join / exit the network, x First, a node join / exit request is sent to the configuration change smart contract CMSC. The configuration change smart contract generates a configuration change transaction REQUEST and temporarily caches it in the transaction pool, waiting for the master node to package it into a block and reach a network-wide consensus through the consistency protocol.

[0052] Step B2.1: Node x Send <NCT-UPDATE, T, t, C, IP to CMSC x > message, indicating that you want to join the network, where T is the configuration change type (here it is node joining, that is, T = NODE-JOIN), t is the timestamp, and C is the Node x Node information (including mandatory items such as IP address, public key, remarks, and optional items such as status and number of times the master node was elected). Among them, NCT-UPDAT indicates the network configuration table update message, IP x Represents Node x The IP address of the server.

[0053] Step B2.2: When the CMSC receives the NCT-UPDATE message, it will check the Node x After verification, a configuration change transaction request <REQUEST, ID, O, t, s> is generated, where s is the address of the CMSC, ID is the identifier of the configuration change transaction (ID = cmt), and O is the transaction body.

[0054] Step B2.3: After the configuration change transaction is generated, it will be temporarily cached in the transaction pool, waiting for the master node to package it into the block, and then reach a network-wide consensus through the consistency protocol.

[0055] Step B3: Response request result, Node i The configuration change transaction will be identified and the validity of the transaction body O will be checked. After the check is passed, Node i According to the information in O, a node will be added / deleted in NCT. x Records; when Node x Received After a valid response result, a state synchronization protocol will be initiated to other nodes / exit the network; n is the number of active nodes in the network configuration table.

[0056] Step B3.1: When the transaction is executed, Node i It will identify the configuration change transaction and check the legitimacy of the transaction body O, that is, check the Node x Check whether the IP and PK of the node already exist in NCT (to prevent malicious nodes from joining the network again with a new identity); after the check is passed, Node i According to the information in O, a node will be added / deleted in NCT. x Then, Node i To Node x Send a successful response. The response format for joining the network is <NODE-JOIN-REPLY, v, t, r, n>, and the response format for exiting the network is <NODE-EXIT-REPLY, v, t, r, n>, where r represents the execution result and n is the number of active nodes in the network configuration table. v is the view on the node, and NODE-EXIT-REPLY is the node exit response message.

[0057] Step B3.2: When Nodex receives f+1 After a valid NODE-JOIN-REPLY / NODE-EXIT-REPLY response, when a new node joins, it will initiate a state synchronization protocol with other nodes to pull the latest status of the current blockchain network; when a node exits, it will request the CA to revoke the certificate and exit the network.

[0058] Please see Figure 6 and Figure 7 The protocol mechanism of this embodiment improves the original protocol mechanism of the PBFT algorithm and includes four protocols: the periodic view rotation protocol is used to regularly replace the master node under normal circumstances, the abnormal view replacement protocol is used to replace the master node under abnormal circumstances, the state synchronization protocol is used for lagging nodes to pull the latest state from the network, and the consistency protocol is used for all nodes to reach a consensus on the candidate blocks.

[0059] The cyclical view rotation protocol of this embodiment implements regular rotation of the master node, ensuring fairness. It also simplifies the message format of the existing view rotation protocol and reduces communication complexity. It should be noted that to distinguish messages from the cyclical view rotation protocol and the anomalous view rotation protocol on the network, the message body of this protocol contains an identification field, ID=cyclic.

[0060] The specific implementation includes the following steps:

[0061] Step C1.1: After a new block is generated, Nodei will automatically calculate the new master node Node according to Algorithm 1. p , and to Node p Send <VIEW-CHANGE, ID, v+1, h, PreBlockHash, IP i > message, where ID is the identification field, v+1 is the new view number, and h is the latest block height; the VIEW-CHANGE message represents a view update message, which is used to indicate to other nodes that the current node needs to update its view. IP i Represents Node i The IP address of the server.

[0062] Step C1.2: When Node p When it receives 2f valid VIEW-CHANGE messages (a valid message means it has the same ID, v+1, h, and PreBlockHash), it will check its own status; if it finds that the local block height is less than h or the latest block hash value is different from PreBlockHash, it will initiate a state synchronization protocol to update the local status. p It will update its own view number to v+1 and broadcast to other nodes <NEW-VIEW, ID, v+1, h, PreBlockHash, O, IP p > message, where O is a set of 2f+1 view-change messages (including the view-change messages generated by itself); among them, NEW-VIEW indicates that the master node generates a new view message, which is used to update the views on other nodes.

[0063] Step C1.3: When Node i After receiving the NEW-VIEW message, the correctness of the message will be verified (the correct message means that the ID, v+1, h, and PreBlockHash are correct and the 2f+1 VIEW-CHANGE messages in O are valid); after the verification is passed, Node i Will update its own view number to v+1. Otherwise, when Node i If the NEW-VIEW message is not received within the timeout period, an abnormal view change protocol will be initiated.

[0064] Step C1.4: Node p Send <NCT-UPDATE, T, t, C, IP to CMSC p > message, add 1 to its own Time field. p Represents Node p The IP address of the server.

[0065] In this embodiment of the abnormal view rotation protocol, when a master node goes offline or behaves maliciously, the corresponding backup master node is activated to continue producing blocks. At the same time, the protocol strictly distinguishes between offline anomalies and malicious anomalies, penalizing malicious master node behavior and permanently excluding malicious nodes from being re-elected as master nodes. Similar to the periodic view rotation protocol, the message body of this protocol also carries the identification field ID=evil / offiine, indicating malicious anomalies and offline anomalies, respectively.

[0066] The specific implementation includes the following steps:

[0067] Step C2.1: When Node i Detect the current master node Node q Malicious behavior occurs or the Node is not received after timeout. q The message sent will select the backup master node Node p For the new master node; Node i Broadcast to other replica nodes <VIEW-CHANGE, ID, v+1, h, PreBlockHash, IP p , IP i > message, where ID is the identification field (needs to be set based on whether the master node is malicious or offline, i.e. ID = evil / offline);

[0068] Step C2.2: When Node p Receive 2f valid VIEW-CHANGE messages (a valid message means it has the same ID, v+1, h, PreBlockHash and IP p), it checks and updates the local state; when it is in the latest state, Node p It will update its own view number to v+1 and broadcast to other nodes <NEW-VIEW, ID, v+1, h, PreBlockHash, O, IP p > News.

[0069] Step C2.3: When Node i After receiving the NEW-VIEW message, the correctness of the message will be verified (the correct message means that the ID, v+1, h, and PreBlockHash are correct and the 2f+1 VIEW-CHANGE messages in O are valid); after the verification is passed, Node i Will update its own view number to v+1. Otherwise, when Node i If the NEW-VIEW message is not received within the timeout period, an abnormal view change protocol will be initiated.

[0070] Step C2.4: Node p Will initiate two <NCT-UPDATE, T, t, C, IP to CMSC p > message, according to the identification field ID, the old master node Node q The State field of the node is updated to EVIL (a node with the EVIL state cannot continue to be elected as a master node) or OFFLINE, and its Time field is increased by 1. OFFLINE indicates that the node is offline.

[0071] The state synchronization protocol based on view number, block number and block hash value in this embodiment can be triggered to pull the latest state of the blockchain network when the node is in a lagging state such as just joining the network, disconnecting and restarting.

[0072] The specific implementation includes the following steps:

[0073] Step C3.1: Node x Broadcast to other nodes <VIEW-FETCH, IP x >Message, get the latest view information in the network; when Node i After receiving the VIEW-FETCH message, it will send a x Send <VIEW-REPLY, v′, n, IP i >Reply to the number v' of the view in which it is located; when Node xUpon receiving f+1 VIEW-REPLY messages with the same view number v′, where v′ is greater than v, the node updates its own view number to v′. A VIEW-FETCH message represents a latest view pull message, used to pull the latest view in the current network; a VIEW-REPLY message is used to reply to the latest view information known to the current node.

[0074] Step C3.2: Node x Broadcast to other nodes <DIGEST-FETCH, v′, h, IP x >, get the summary of all missing block data; when Node i After receiving the DIGEST-FETCH message, it checks whether v' is consistent with its own view number; if the check passes, it sends a message to Node x Send <DIGEST-REPLY,v′,h,H,d,IP i >, where H is Node i The DIGEST-FETCH message is a message that pulls the digest of missing block data, and is used to pull the digest of missing block data. The DIGEST-REPLY message is used to reply to a message that pulls the digest of missing block data.

[0075] Step C3.3: When Node x After receiving f+1 DIGEST-REPLY messages with the same H and d, select one of the nodes Node j Send <BLOCK-FATCH, v′, h, H, IP x >, to pull detailed block data; when Node j After receiving the BLOCK-FATCH message, x Send <BLOCK-REPLY,v′,h,H,£,d,IP j >, where ￡ contains all block information from h+1 to H. The BLOCK-FATCH message represents a missing block data pull message, used to completely pull the missing block data; the BLOCK-REPLY message is used to reply to the missing block data pull message.

[0076] Step C3.4: When Node x After receiving the BLOCK-REPLY message that matches the digest-reply, the block data will be updated according to £ and the transactions in the block will be executed.

[0077] This embodiment draws on the collector concept in the blockchain scenario and provides an optimistic consistency protocol, which simplifies the message format and reduces the communication complexity of the consistency protocol under normal circumstances.

[0078] The specific implementation includes the following steps:

[0079] Step C4.1: Master Node p Select several legal transactions in the transaction pool, package them into candidate blocks and broadcast them to other nodes << PRE-PREPARE, v, h, BlockHash, IP p >, B> message, where h is the height of the candidate block, BlockHash is the hash value of the candidate block, and B is the candidate block.

[0080] Step C4.2: When Node i After receiving the PRE-PREPARE message, it will verify the correctness of v, h, BlockHash and B in the message; after the verification is passed, Node i To Node p Send<PREPARE-SEND,v,h,BlockHash,IP i >Message; When Node p When receiving 2f PREPARE-SEND messages that match the PRE-PREPARE message (v, h and BlockHash are the same), it will broadcast to other nodes <PREPARE-CONFIRM, O1, IP p > message, where O1 is a set of 2f PREPARE messages. The PREPARE-SEND message represents a block preparation message sent to the master node, and the PREPARE-CONFIRM message represents a block validity confirmation message from the master node.

[0081] Step C4.3: When Node i After receiving the PREPARE-CONFIRM message, it will verify the validity of the message (the message validity means that the 2f PREPARE messages in O1 are valid); after the verification is passed, Node i To Node p Send<COMMIT-SEND,v,h,BlockHash,IP i >Message; When Node p When receiving 2f COMMIT-SEND messages that match the PRE-PREPARE message, it will broadcast <COMMIT-CONFIRM, O2, IP to other nodes p> message, where O2 is a set of 2f COMMIT messages. The COMMIT-SEND message represents the block submission message sent to the master node; the COMMIT-CONFIRM message represents the master node block submission confirmation message.

[0082] Step C4.4: When Node i After receiving the COMMIT-CONFIRM message, the validity of the message will be verified (a valid message means that all 2f COMMIT messages in O2 are valid); after the verification is passed, the block can be submitted to the local blockchain and the transactions in the block can be executed in sequence, and a response will be returned after the execution is completed.

[0083] Step C4.5: When Node i If the master node still has not received a confirmation message after the timeout of step 4.2 or 4.3 above, the original protocol will be immediately restored to broadcast PREPARE / COMMIT messages to other nodes.

[0084] In the supply chain traceability scenario, the present invention can provide:

[0085] 1. Random Fairness of Masternode Selection: This paper proposes a new masternode selection rule for the RDE-BFT algorithm by using a consistent hashing algorithm based on the network configuration table and the hash value of the previous block, combined with the idea of average load. This can achieve random and fair masternode selection at a low cost in dynamic networks.

[0086] 2. Network dynamism: This invention adds the concepts of network configuration table and configuration change transaction and designs a set of processes for nodes to enter and exit the network based on these two concepts, thus achieving network dynamism.

[0087] 3. Efficiency of the protocol mechanism: This paper optimizes the existing protocol mechanism of the PBFT algorithm, mainly including refining the view change protocol into a periodic rotation protocol and an abnormal change protocol, designing a state synchronization protocol for lagging nodes, and reducing the communication complexity of the consensus protocol under normal circumstances based on the collector concept.

[0088] This invention can provide users with a safe, efficient, and scalable Byzantine fault-tolerant method in more fields such as supply chain traceability and supply chain finance.

[0089] Compared with the prior art, the present invention is innovative in the following aspects:

[0090] (1) This paper proposes a new master node selection rule for the RDE-BFT algorithm using a consistent hashing algorithm based on a network configuration table and the hash value of the previous block, combined with the idea of average load. This rule can achieve random and fair selection of master nodes at a low cost in a dynamic network.

[0091] (2) This invention designs a set of processes for nodes to enter and exit the network, which can meet the demand for dynamic networks in supply chain traceability scenarios at a very low cost;

[0092] (3) The present invention refines, simplifies and optimizes the existing protocol mechanism, overcoming the shortcomings of the rough PBFT algorithm protocol mechanism and excessive communication complexity in the supply chain traceability scenario.

[0093] It should be understood that parts not elaborated in detail in this specification belong to the prior art.

[0094] It should be understood that the above description of the preferred embodiment is relatively detailed and cannot be regarded as limiting the scope of protection of the patent of the present invention. Under the guidance of the present invention, ordinary technicians in this field can also make substitutions or modifications without departing from the scope of protection of the claims of the present invention, which all fall within the scope of protection of the present invention. The scope of protection requested by the present invention shall be based on the attached claims.

Claims

1. A Byzantine fault-tolerant consensus method for supply chain traceability, characterized by: Including the random selection rules of the master node, the dynamic entry and exit mechanism of the node in the network and the protocol mechanism; The master node is randomly selected according to the rule, and a unique master node is selected from all replica nodes. The master node can receive transactions and package blocks; The dynamic node entry and exit mechanism in the network uses the Network Configuration Table (NCT) and Configuration Change Transaction (CMT) to achieve dynamic node entry and exit in a continuous operation state. When a node A that needs to join the network generates a public and private key and sends it to the certification authority CA, the certification authority CA returns a certificate that has passed the certification to the node; Node A first sends a node join / exit request to the configuration change smart contract CMSC. The configuration change smart contract CMSC generates a configuration change transaction CMT, and reaches a network-wide consensus through a consensus protocol. Node A checks the legitimacy of the configuration change transaction CMT and executes it. The execution result of the configuration change transaction CMT is returned to Node A, and the node determines whether it can join / exit the network based on the execution result. The Network Configuration Table (NCT) records information about all nodes that have joined the network, including IP addresses, public keys, node status, the number of times a master node has been elected, and related notes. The configuration change transaction (CMT) carries identifying information, which allows all nodes to identify this special transaction and update their local network configuration table according to the transaction content. The protocol mechanism includes four protocols: a periodic view rotation protocol for regularly replacing the master node under normal circumstances, an abnormal view replacement protocol for replacing the master node under abnormal circumstances, a state synchronization protocol for lagging nodes to pull the latest state from the network, and a consistency protocol for all nodes to reach consensus on candidate blocks.

2. The Byzantine fault-tolerant consensus method for supply chain traceability according to claim 1 is characterized by: The master node selection rules include constructing a hash space, node mapping rules in the network configuration table, previous block hash value mapping rules, and hash position mapping rules; The constructed hash space is based on the ring hash space of the consistent hashing algorithm, and uses the same hash space size as the IPv4 address, selecting 0 to 2 32 The hash positions of the hash space form a hash space, which increases clockwise, where 0 and 2 32 is the overlapping position; The node mapping rule in the network configuration table selects the IPv4 address of the node as the unique identification information of the node, and selects a fixed mapping formula to map all nodes in the network configuration table NCT to a certain position in the ring hash space in sequence; The previous block hash value mapping rule selects the same mapping formula as the node mapping rule in the network configuration table to map the previous block hash value to a certain position in the annular hash space; The hash position mapping rule records the number of times each node is elected as the master node in the network configuration table. First, the average number of times each node is elected is calculated. Then, starting from the hash value mapping position of the previous block, the corresponding node at the next clockwise position with a number of elections less than or equal to the average number of elections is searched for as the master node.

3. The Byzantine fault-tolerant consensus method for supply chain traceability according to claim 1 is characterized by: When a node A that needs to join the network generates a public and private key and sends it to the certification authority CA, the certification authority CA returns a certified certificate to the node; node A first generates a pair of public and private keys, sends its own IP address and public key information to the certification authority CA, and retains the private key; after receiving the application from node A, the certification authority CA evaluates the legitimacy of node A; after the certification authority CA completes the verification and review, it responds to the applicant node A with a digital certificate.

4. The Byzantine fault-tolerant consensus method for supply chain traceability according to claim 1 is characterized by: Node A first sends a node join / exit request to the configuration change smart contract CMSC, which generates a configuration change transaction CMT, and reaches a network-wide consensus through a consensus protocol. Node A first sends an NCT-UPDATE message to the configuration change smart contract CMSC, indicating that it wants to join / exit the network, which contains status information about the current node A. When CMSC receives the NCT-UPDATE message, it verifies the identity of node A and generates a configuration change transaction CMT request REQUEST. After the configuration change transaction CMT is generated, it will be temporarily cached in the transaction pool, waiting for the master node to package it into a block, and then reach a network-wide consensus through a consensus protocol.

5. The Byzantine fault-tolerant consensus method for supply chain traceability according to claim 1 is characterized by: Node A checks the legitimacy of the configuration change transaction (CMT) and executes it, returning the execution result of the configuration change transaction (CMT) to Node A. Node A then determines whether it can join or exit the network based on the execution result. Node A identifies the configuration change transaction (CMT) and checks the legitimacy of the transaction body. If the check passes, it executes the transaction based on the transaction body. After the node completes the transaction, it returns the execution result to the node. The newly joined node initiates a state synchronization protocol with other nodes to pull the latest state of the current blockchain network. The node that exits the network requests the certification authority CA to revoke its certificate.

6. The Byzantine fault-tolerant consensus method for supply chain traceability according to claim 1 is characterized by: The periodic view rotation protocol is as follows: after a new block is generated, all nodes automatically calculate a new master node according to the master node selection rules and send VIEW-CHANGE messages to other nodes. When the new master node receives more than the specified number of VIEW-CHANGE messages, it checks and updates its local state, updates its own view number, and broadcasts NEW-VIEW messages to other nodes. When a node receives the NEW-VIEW message, it verifies the message's correctness and updates its own view number. If a node still does not receive the NEW-VIEW message after a timeout, it initiates the abnormal view change protocol. The new master node sends an NCT-UPDATE message to the configuration update smart contract to update its own master node election count.

7. The Byzantine fault-tolerant consensus method for supply chain traceability according to claim 1, characterized in that: The abnormal view change protocol is that when a node detects that the current master node has engaged in malicious behavior or has not received a message after a timeout, it will calculate a backup master node as the new master node according to the master node selection rule and broadcast a VIEW-CHANGE message to other replica nodes. When the new master node receives more than the specified number of VIEW-CHANGE messages, it checks and updates its local state, updates its own view number, and broadcasts a NEW-VIEW message VIEW-CHANGE to other nodes. When a node receives the NEW-VIEW message, it verifies the correctness of the message and updates its own view number. If the node still does not receive the NEW-VIEW message after a timeout, the abnormal view change protocol is initiated. The new master node sends an NCT-UPDATE message to the configuration update smart contract to update its own master node election count and the status of the old master node.

8. The Byzantine fault-tolerant consensus method for supply chain traceability according to claim 1, characterized in that: The state synchronization protocol is that a lagging node broadcasts a VIEW-FETCH message to other nodes, and the other nodes send VIEW-REPLY messages to reply with their own view numbers. When the lagging node receives more than a specified number of VIEW-REPLY messages with the same view number, it updates its own view number. The lagging node broadcasts a DIGEST-FETCH message to other nodes, and the other nodes send DIGEST-REPLY messages to reply with a combined digest of missing block information. When the lagging node receives more than a specified number of DIGEST-REPLY messages with the same block digest, it temporarily caches the digest information. The lagging node selects one of the above nodes to send a BLOCK-FATCH message to pull detailed block data. When the node receives a block-fetch message, it sends a BLOCK-REPLY message to the lagging node to reply with the missing block information. When the lagging node receives a BLOCK-REPLY message that matches the DIGEST-REPLY, it updates its own block data and executes transactions in the block.

9. The Byzantine fault-tolerant consensus method for supply chain traceability according to any one of claims 1 to 8, characterized in that: The consensus protocol is that the master node selects several legal transactions from the transaction pool, packages them into candidate blocks, and broadcasts a PRE-PREPARE message to other nodes. When a node receives the PRE-PREPARE message, it verifies the correctness of the message and sends a PREPARE-SEND message to the master node. When the master node receives more than a specified number of PREPARE-SEND messages that match the PRE-PREPARE message, it broadcasts a PREPARE-CONFIRM message to other nodes. When a node receives the PREPARE-CONFIRM message, it verifies the validity of the message and sends a COMMIT-SEND message to the master node. When the master node receives more than a specified number of COMMIT-SEND messages that match the PRE-PREPARE message, it broadcasts a COMMIT-CONFIRM message to other nodes. When a node receives the COMMIT-CONFIRM message, it verifies the validity of the message and submits the block to the local blockchain and executes the transactions in the block in order. If a node still does not receive a confirmation message from the master node after a timeout in the above two types of judgments, it immediately reverts to the original protocol and broadcasts a PREPARE-CONFIRM message to other nodes.

10. A Byzantine fault-tolerant consensus system for supply chain traceability, characterized by: include: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the one or more processors to implement the Byzantine fault-tolerant consensus method in supply chain traceability as described in any one of claims 1 to 9.

Images