CN117176326A

CN117176326A - Bayesian-busy fault tolerance consensus method and system in supply chain traceability scene

Info

Publication number: CN117176326A
Application number: CN202310967873.9A
Authority: CN
Inventors: 陈晶; 何琨; 杜瑞颖; 王超; 粟栗; 吴鸿伟; 吴云坤; 陈华平; 纪胜龙
Original assignee: Wuhan University WHU
Current assignee: Wuhan University WHU
Priority date: 2023-08-02
Filing date: 2023-08-02
Publication date: 2023-12-05

Abstract

The invention discloses a Bayesian and busy-court fault-tolerant consensus method and a system under a supply chain tracing scene. The main node selection rule is based on a consistent hash algorithm and a previous block hash value and combines an average load thought, so that random fair selection of the main node is realized; the network configuration table and the concept of configuration change transaction are newly added in the dynamic network access flow of the node, so that the dynamic property of the network is realized; the optimized protocol mechanism is used for improving the existing protocol mechanism of the PBFT algorithm and mainly comprises the steps of refining the view replacement protocol, proposing a new state synchronization protocol and optimizing the consistency protocol under the condition of no abnormality. The method has the advantages of randomly selecting the master node, supporting the dynamic network, having low communication complexity and the like, and is particularly suitable for supply chain tracing scenes with complex members, strong openness and large node scale.

Description

Bayesian-busy fault tolerance consensus method and system in supply chain traceability scene

Technical Field

The invention belongs to the technical field of information safety, relates to a Bayesian fault-tolerant consensus method and a system, and particularly designs a Bayesian fault-tolerant consensus improvement method and a system under a supply chain tracing scene.

Background

The supply chain refers to a network chain structure composed of members such as raw material suppliers, processors, logistics suppliers, distributors, retailers and the like involved in the commodity production, transportation and sales processes. The supply chain tracing is to record all supply chain data from raw material purchase to consumer purchase by using modern information technology means, so that all circulation links of the commodity are in monitoring. The supply chain traceability system can help consumers to conveniently acquire production and transportation information of commodities, is also beneficial to improving supervision efficiency of related supervision authorities, and can trace back to responsible persons in time.

Blockchain is not a single technology, but a combination of technologies such as P2P network communication, distributed ledger, cryptography, consensus algorithm, intelligent contracts, and the like. Due to the technology, the blockchain has the characteristics of 'non-forging', 'traceability', 'decentralization', and the like, and the long-standing trust problem in a supply chain tracing scene is solved. The blockchain can provide public transparent data records in a supply chain tracing scene, so that a malicious attacker is difficult to tamper with; the method helps consumers and regulatory authorities to acquire all circulation data of commodities and timely trace responsibility; the method realizes the non-trust consensus of multiple enterprises, and enterprises can cooperate and supervise each other.

As the most core component of the blockchain, the consensus algorithm profoundly affects the applicable scenario of the blockchain. Supply chain tracing belongs to one of the typical alliance blockchain application categories, requiring the use of consensus algorithms that do not rely on token mechanisms, but support the bayer fault tolerance. The PoW algorithm, which is suitable for public chains, relies on the token mechanism to encourage competition and consume a great deal of computing power; the Raft algorithm suitable for the private chain does not support the bayer fault tolerance, so none of the above algorithms can be applied to the federation chain. The PBFT algorithm is used as a consensus algorithm with higher consensus efficiency and supporting Bayesian fault tolerance, and is certainly the best choice of a alliance chain. The PBFT algorithm is used for solving the consistency problem in the traditional distributed system at the earliest, optimizes the communication complexity of the original Bayesian fault-tolerant algorithm from an exponential level to a polynomial level, and ensures that the Bayesian node fault-tolerant rate can reach one third of the total number of nodes, thereby basically meeting the requirements on efficiency and fault tolerance in common scenes.

However, the PBFT algorithm cannot be fully adapted to the supply chain traceability scenario. Different from other common alliance chain scenes, the supply chain traceability scene has the characteristics of complex participation members, strong mobility, large scale, wide cross-region and the like. Due to the characteristics, the existing PBFT algorithm has the defects of orderly selection of the main node, poor network dynamic property, rough protocol mechanism, overhigh communication complexity and the like in a supply chain tracing scene, so that the PBFT algorithm cannot be directly migrated to be used as a consensus mechanism of a supply chain tracing blockchain, and the main node selection rule, the network dynamic property, the protocol mechanism and the like of the PBFT algorithm need to be improved in a targeted manner. According to the scheme, on the basis of deeply analyzing the defects of the PBFT algorithm under the supply chain tracing scene, the PBFT algorithm is pertinently improved from multiple angles, so that the improved PBFT algorithm can be more suitable for the supply chain tracing scene.

Disclosure of Invention

In view of the above-mentioned drawbacks of the original practical Bayesian fault-tolerant algorithm and the security and performance requirements for tracing commodity information in a supply chain scene, the invention provides a Bayesian fault-tolerant consensus method and system with randomness, dynamic property and high efficiency in the supply chain tracing scene based on the existing PBFT algorithm.

The technical scheme adopted by the method is as follows: a Bayesian-busy fault-tolerant consensus method under a supply chain tracing scene constructs a main node selection rule, which comprises constructing a hash space rule, a node mapping rule in a network configuration table, a previous block hash value mapping rule and a hash position mapping rule, and realizes random fair selection of the main node;

the construction of the hash space rule is based on the annular hash space of the consistent hash algorithm, uses the same hash space size as the IPv4 address, and selects 0-2 ³² Form a hash space, which is sequentially increased clockwise, wherein 0 and 2 are respectively formed ³² A collapsed 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 sequentially map all the nodes in the network configuration table NCT to a certain position in the annular hash space;

the mapping rule of the previous block hash value 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;

and the hash position mapping rule records the master node selection times of each node in a network configuration table, firstly calculates the average selection times of all nodes, and then searches for a corresponding node at the next clockwise adjacent position which is smaller than or equal to the average selection times from the previous block hash value mapping position to obtain the master node.

Preferably, the network configuration table NCT records node information of all the joined networks; each row represents a duplicate node, containing a IP, PK, state, time, note field; the IP field and the PK field respectively represent the IP address and the public key of the node, the State field represents the current State of the node, and the Time field represents the times when the current node is selected as a master node; the Note field indicates remark information for recording the time that the node was added, dropped, status updated, and penalized.

Preferably, a node dynamic network access rule is constructed, and network dynamic property is realized by newly adding a network configuration table NCT and configuring and changing transaction CMT;

the specific implementation method comprises the following steps:

step 1: a node A needing to join the network generates a public and private key and sends the IP address and public key information of the node A to a CA certification authority; the CA certification authority evaluates the legality of the node, and returns a certificate passing the certification to the node A after passing the verification;

step 2: the node A firstly sends a node joining/exiting request to a configuration change intelligent contract, the configuration change intelligent contract generates a configuration change transaction CMT, and the whole network consensus is achieved through a consistency protocol;

step 3: other nodes check the validity of the configuration change transaction CMT and execute the configuration change transaction CMT, the other nodes return the execution result of the configuration change transaction CMT to the node A, and the node A judges whether the network can be added/exited according to the execution result; a node newly joining the network initiates a state synchronization protocol to other nodes to pull the latest state in the current blockchain network; the node that is out of the network requests the CA certification authority to revoke the certificate.

Preferably, the specific implementation of the step 2 comprises the following sub-steps:

step 2.1: node a first sends an NCT-UPDATE message to the configuration change smart contract indicating that itself wants to join/leave the network, including the state information of the current node;

step 2.2: after the configuration change intelligent contract receives the NCT-UPDATE message, checking the node identity and generating a configuration change transaction REQUEST;

step 2.3: after the configuration change transaction REQUEST is generated, the configuration change transaction REQUEST is temporarily cached in a transaction pool, waits for a master node to pack the configuration change transaction REQUEST into a block, and then achieves the whole network consensus through a consistency protocol.

Preferably, the original protocol mechanism is deeply optimized by using a periodic view rotation protocol, an abnormal view replacement protocol, a state synchronization protocol and a consistency protocol;

the periodic view rotation protocol is used for periodically replacing the main node under normal conditions; the abnormal view replacement protocol is used for replacing the main node under the abnormal condition; the state synchronization protocol is used for pulling the latest state from the network by the laggard node; the consistency protocol is used for all nodes to reach the common candidate block.

Preferably, after the new block is generated, all nodes automatically calculate a new master node and send VIEW-CHANGE messages (VIEW CHANGE messages for changing the current master node) to other nodes; when the NEW master node receives the VIEW-CHANGE messages exceeding the rated number, checking and updating the local state, and simultaneously updating the own VIEW number and broadcasting the NEW-VIEW message (the NEW VIEW message indicates that the NEW master node is generated currently) to other nodes by the NEW master node; after a certain node receives the NEW-VIEW message, verifying the correctness of the message and updating the own VIEW number; when the node is overtime and still does not receive the NEW-VIEW message, initiating an abnormal VIEW replacement protocol; the new master node sends an NCT-UPDATE message (network configuration table UPDATE message for updating the network configuration table NCT) to the configuration UPDATE smart contract, updating its own master node selection times.

Preferably, the abnormal VIEW replacement protocol calculates a standby master node as a new master node and broadcasts VIEW-CHANGE messages (VIEW replacement messages for replacing the current master node) to other duplicate nodes when a node detects that the current master node has malicious behavior or has not received a transmitted message after overtime; when the NEW master node receives the VIEW-CHANGE messages exceeding the rated number, the local state is checked and updated, and meanwhile, the NEW master node updates the own VIEW number and broadcasts NEW-VIEW messages (NEW VIEW messages indicate that the NEW master node is generated currently) to other nodes; after a certain node receives the NEW-VIEW message, verifying the correctness of the message and updating the own VIEW number; initiating an abnormal VIEW replacement protocol (which can continue to generate blocks based on selecting a NEW master node when the master node is disconnected or wrongly) when the node has not received the NEW-VIEW message yet after timeout; the new master node sends an NCT-UPDATE message (network configuration table UPDATE message for updating the network configuration table NCT) to the configuration UPDATE smart contract, updating the master node selection number of itself and the state of the old master node.

Preferably, in the state synchronization protocol, a certain laggard node broadcasts a VIEW-FETCH message (VIEW pulling message, used for obtaining the latest VIEW information in the network) to other nodes, and the other nodes send VIEW-REPLY messages to REPLY to the VIEW numbers where the other nodes are located; when the lagging node receives more than rated number of VIEW-REPLY messages with the same VIEW numbers, the VIEW numbers of the lagging node are updated; the laggard node broadcasts a DIGEST-FETCH message (a block data abstract acquisition message for acquiring the abstract of all missing block data) to other nodes, and the other nodes send DIGEST-REPLY messages to REPLY the combined abstract of the missing block information; when the laggard node receives the DIGEST-REPLY messages with the same block abstracts exceeding the rated number, temporarily caching the abstracted information; the laggard node selects one of the nodes to send a BLOCK-FATCH message so as to pull detailed BLOCK data; after receiving the BLOCK-FATCH message, the node sends a BLOCK-REPLY message to the laggard node to REPLY the missing BLOCK information; when the backward node receives the BLOCK-REPLY message matched with the DIGEST-REPLY, the backward node updates the BLOCK data of the backward node and executes the transaction in the BLOCK.

Preferably, the agreement protocol is that the master node selects a plurality of legal transactions in the transaction pool to be packed into candidate blocks and broadcasts PRE-PREPARE messages (PRE-preparation messages used for selecting the transactions to be packed into candidate blocks) to other nodes; after a node receives the PRE-PREPARE message, verifying the correctness of the message and sending a PREPARE-SEND message (a preparation reply message for verifying the reply of the validity of the preparation message) to the master node; broadcasting a PREPARE-CONFIRM message (preparation CONFIRM message, a broadcast message for the main node to SEND to other nodes after receiving 2f preparation reply messages when the main node receives more than rated number of PRE-PREPARE messages, f being the maximum number of Bayesian nodes in the network); after the node receives the PREPARE-CONFIRM message, it verifies the message validity and SENDs a COMMIT-SEND message (block pre-COMMIT message indicating that the current node will execute transactions in the block) to the master node; broadcasting a COMMIT-CONFIRM message (block submission confirmation message used for broadcasting messages sent to other nodes after the master node receives 2f block PRE-submission messages) to other nodes when the master node receives more than rated number of COMMIT-SEND messages matched with the PRE-PREPARE messages, wherein f is the maximum number of Bayesian nodes in the network); after receiving the COMMIT-CONFIRM message, the node verifies the validity of the message and submits the block to a local block chain and sequentially executes transactions in the block; when the node still does not receive the confirmation message of the master node after timeout, the original protocol is immediately restored to broadcast the preparation/commit message (two types of messages of the classical PBFT algorithm) to other nodes.

The system of the invention adopts the technical proposal that: a bayer fault-tolerant consensus system in a supply chain traceability scenario, comprising:

one or more processors;

and the storage device is used for storing one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors realize the Bayesian fault tolerance consensus method under the supply chain tracing scene.

Compared with the prior art, the invention has the advantages and positive effects mainly represented in the following aspects:

(1) The invention provides a new main node selection rule for RDE-BFT algorithm by using a consistent hash algorithm based on a network configuration table and a previous block hash value and combining an average load thought, and can realize random fair selection of main nodes with lower cost under a dynamic network;

(2) The invention designs a set of node network access flow, which can meet the requirement of the supply chain under the source tracing scene for the dynamic network with extremely low cost;

(3) The invention refines, simplifies and optimizes the existing protocol mechanism, and overcomes the defects of rough protocol mechanism and high communication complexity of the PBFT algorithm under the supply chain tracing scene.

Drawings

The following examples, as well as specific embodiments, are used to further illustrate the technical solutions herein. In addition, in the course of describing the technical solutions, some drawings are also used. Other figures and the intent of the present invention can be derived from these figures without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a method according to an embodiment of the present invention.

Fig. 2 is a cycle chart of operation of an embodiment of the present invention.

Fig. 3 is a scheme execution flow during a master node period in an embodiment of the present invention.

Fig. 4 is a schematic diagram of a master node selection rule module according to an embodiment of the present invention.

Fig. 5 is a schematic diagram of a node joining a network by dynamically entering and exiting a network module according to an embodiment of the present invention.

Fig. 6 is a schematic diagram of a node exiting a network by dynamically entering and exiting a network module according to an embodiment of the present invention.

Fig. 7 is a schematic diagram of a periodic view rotation protocol of the protocol mechanism optimization module in an embodiment of the present invention.

Fig. 8 is a schematic diagram of a state synchronization protocol of a protocol mechanism optimization module in an embodiment of the present invention.

Detailed Description

For the purpose of facilitating understanding and practicing the invention by those of ordinary skill in the art, reference will now be made in detail to the present invention, examples of which are illustrated in the accompanying drawings and examples, it being understood that the examples described herein are for the purpose of illustration and explanation only and are not intended to be limiting.

The invention provides a Bayesian-preemption fault tolerance improvement method under a supply chain tracing scene, which comprises a main node selection rule, a node dynamic network access flow and an optimized protocol mechanism. The master node selection rule of the embodiment is based on a consistent hash algorithm and a previous block hash value and combines an average load idea, and is used for selecting a unique master node from all copy nodes, the master node can receive transactions and package out blocks, and compared with the original master node selection rule of a PBFT algorithm, the module can realize random fair selection of the master node under a dynamic network.

The node dynamic network access flow of the embodiment is used for realizing the dynamic joining and exiting of the node in a continuous running state, provides a concept of a network configuration table and configuration change transaction, can timely know the number information of all network nodes and inform the all network nodes when the node enters and exits, and realizes the dynamic property of the network;

the optimized protocol mechanism of the embodiment is used for improving the existing protocol mechanism of the PBFT algorithm, and mainly comprises the steps of refining the view replacement protocol, proposing a new state synchronization protocol and optimizing the consistency protocol under the condition of no abnormality. The periodic view rotation protocol is used for periodically replacing the master node under normal conditions; the abnormal view replacement protocol is used for replacing the main node under abnormal conditions; the state synchronization protocol is used for pulling the latest state from the network by the laggard node; the consistency protocol is used for all nodes to reach a consensus on the candidate blocks.

Please refer to fig. 1, fig. 2 and fig. 3, the present invention provides a bayer trails fault-tolerant consensus method under a supply chain tracing scene, which includes constructing a master node selection rule, a node dynamic network access rule and a protocol mechanism optimization rule.

In one embodiment, please refer to fig. 4, the specific process of constructing the master node selection rule includes the following steps:

step A1: selecting 0 to 2 ³² Form a hash space, wherein 0 and 2 ³² Overlapping;

step A2: let H ₁ (x)＝x％2 ³² And using the node IP address as x, and sequentially mapping all nodes in the network configuration table NCT to a certain position in the hash space. Suppose a Node _i Is IP address _i The mapped position is Hash _i The mapping formula is defined as follows:

Hash _i ＝IP _i mod2 ³² ；

step A3: let H ₂ (x)＝H ₁ (x)＝x％2 ³² The previous chunk hash value is mapped as x into the hash space. Assuming that the Hash value of the previous block is PreBlockHash, the mapped position is Hash, and the mapping formula is defined as follows:

Hash＝PreBlockHashmod2 ³² ；

step A4: setting a Time field in the network configuration table to indicate the number of times the row of nodes has selected the master node; then calculating average selection times avg of each node, and searching for the next clockwise adjacent position Hash less than or equal to avg from the Hash _p Corresponding Node _p Namely the master node.

In one embodiment, the network configuration table NCT in step A2 is an auxiliary structure specifically designed for implementing network dynamics, and the table records node information of all the joined networks. Each row represents a duplicate node and contains fields IP, PK, state, time, note, etc. The IP field and the PK field respectively represent the IP address and the public key of the node, the State field represents the current State of the node, and the node has three states of ACTIVE, OFFLINE and EVIL, and the ACTIVE represents that the node is in a normal State; ofline indicates that the node is in a dropped exception state (which state may revert to ACTIVE state after the node reconnects); EVIL indicates that the node has developed a malicious behavior anomaly, is in a punished state, and cannot continue to be selected as a master node (the state cannot be changed). The Time field indicates the number of times the current node has been selected as the master node, the Note field indicates remark information, and the Time the node joins, drops, status updates, and is penalized is recorded. The structure has corresponding copies at all nodes and can be considered as part of the blockchain state. The network configuration table is used for achieving the consensus of the whole network for the number and the state of the nodes, and all changes to the structure are required to be carried out through configuration change transactions.

Referring to fig. 5 and 6, in one embodiment, the method for constructing a node to dynamically enter and exit the network includes the following steps:

step B1: node key management, node _x A pair of public key pub and private key pri is generated and sent to the CA, and the CA evaluates and returns a certificate cert passing authentication to the node.

Step B1.1: node _x First, a pair of public key pub and private key pri are generated, information such as own IP address, public key pub and the like is sent to a CA certification authority, and the private key pri is reserved.

Step B1.2: after receiving the application sent by the node, the CA evaluates the validity of the node according to the information; after the CA verification and audit are completed, the digital certificate cert is responded to the application node.

Step B2: node requests to join/leave network, node _x Firstly, a NODE joining NODE-JOIN/exiting NODE-EXIT REQUEST is sent to a configuration change intelligent contract CMSC, the configuration change intelligent contract generates a configuration change transaction REQUEST and temporarily caches the REQUEST into a transaction pool, and after the REQUEST is packed into a block by a master NODE, the REQUEST is agreed to achieve the whole network consensus.

Step B2.1: node _x Send to CMSC<NCT-UPDATE,T,t,C,IP _x >A message indicating that itself wants to JOIN the network, where T is the configuration change type (here, NODE JOIN, i.e., t=node-JOIN), T is a timestamp, C is a NODE _x Node information (including IP address, public key, notes, etc., and status, master node select times, etc.).

Step B2.2: when the configuration change intelligent contract CMSC receives nct-update message, it checks Node _x Identity of (c); generating a configuration change transaction request after verification<REQUEST,ID,O,t,s>Where s is the address of the CMSC, ID is the identity of the configuration change transaction (id=cmt), and O is the transaction body.

Step B2.3: after the configuration change transaction is generated, the configuration change transaction is temporarily cached in a transaction pool, waits for a master node to package the configuration change transaction into a block, and then achieves the whole network consensus through a consistency protocol.

Step B3: responding to the request result, node _i Will recognize the configuration change transaction and check the legitimacy of transaction body O, after the check is passed, node _i Will add/delete a related Node in NCT according to the information in O _x Is a record of (2); when Node _x Receiving f+1And after the result is effectively responded, a state synchronization protocol is initiated to other nodes/the network is exited.

Step B3.1: node in trade execution _i Will recognize the configuration change transaction and check the legitimacy of transaction body O, i.e. check Node _x Whether IP and PK of (a) are already present in NCT (preventing malicious nodes from joining the network again with new identities); after passing the check, node _i Will add/delete a related Node in NCT according to the information in O _x Is recorded in the database. Then Node _i To Node _x Transmitting a successful response, and joining the network in a response format of<NODE-JOIN-REPLY,v,t,r,n>The response format of exiting the network is as follows<NODE-EXIT-REPLY,v,t,r,n>Wherein r represents an execution result, and n is the number of active nodes in the network configuration table.

Step B3.2: when Node _x Receiving f+1After effective NODE-JOIN-REPLY/NODE-EXIT-REPLY response, when a NODE newly JOINs, a state synchronization protocol is initiated to other NODEs to pull the latest state in the current blockchain network; when the node exits, it will request the CA to revoke the certificate and exit the network.

Please refer to fig. 7 and fig. 8, the protocol mechanism optimization rule constructed in the present embodiment is that the original protocol mechanism is deeply optimized by using a periodic view rotation protocol, an abnormal view replacement protocol, a state synchronization protocol and a consistency protocol;

in the embodiment, the periodic view rotation protocol realizes the periodic rotation of the master node and ensures fairness; meanwhile, the protocol also simplifies the message format of the original view replacement protocol and reduces the communication complexity. It should be noted that, in order to distinguish between messages of the periodic view rotation protocol and messages of the abnormal view replacement protocol in the network, the messages of the protocols carry an identification field id=cyclic.

In one embodiment, the periodic view rotation protocol, the specific process includes the steps of:

step C1.1: after the new block is generated, node _i Will automatically calculate the new master Node according to algorithm 1 _p And to Node _p Transmitting<VIEW-CHANGE,ID,v+1,h,PreBlockHash,IP _i >The message, wherein ID is an identification field, v+1 is a new view number, and h is the latest block height.

Step C1.2: when Node _p When receiving 2f valid VIEW-CHANGE messages (message valid means having the same ID, v+1, h, and PreBlockHash), it will check its own status; if the local block height is found to be smaller than h or the latest block hash value is different from PreBlockHash, a state synchronization protocol is initiated to update the local state. When in the latest state, node _p The view number v+1 of the self is updated and broadcast to other nodes<NEW-VIEW,ID,v+1,h,PreBlockHash,O,IP _p >Messages, where O is a set of 2f+1 VIEW-CHANGE messages (also including self-generated VIEW-CHANGE messages).

Step C1.3: when Node _i After receiving the NEW-VIEW message, the correctness of the message is verified (the message is exactly that the ID, v+1, h, preBlockHash are all correct and 2f+1 VIEW-CHANGE messages in O are all valid); after passing the verification, node _i The own view number v +1 is updated. Otherwise, when Node _i The NEW-VIEW message is not received yet over time, and an abnormal VIEW replacement protocol may be initiated.

Step C1.4: node _p Send to CMSC<NCT-UPDATE,T,t,C,IP _p >The message adds 1 to its own Time field.

In order to ensure consensus progress and user experience, the embodiment designs an abnormal view replacement protocol, and when a main node is disconnected or wrongly used, a corresponding standby main node is started to continue to generate blocks; meanwhile, the protocol can strictly distinguish between offline anomalies and wrongly anomalies, punish malicious behaviors of the master node, and the wrongly nodes can never select the master node again.

In one embodiment, the abnormal view replacement protocol, the specific process includes the steps of:

step C2.1: when a node detects that the current master node has malicious behavior or has not received the transmitted message after timeout, it calculates the standby master node as a new master node according to claim 2 and broadcasts a VIEW-CHANGE message to other duplicate nodes.

Step C2.2: when the NEW master node receives the VIEW-CHANGE messages exceeding the rated number, the local state is checked and updated, and meanwhile, the NEW master node updates the own VIEW number and broadcasts the NEW-VIEW messages to other nodes.

Step C2.3: when a certain node receives the NEW-VIEW message, the correctness of the message is verified and the VIEW number of the node is updated; when the node times out and still does not receive the NEW-VIEW message, an abnormal VIEW replacement protocol is initiated.

Step C2.4: the new master node sends NCT-UPDATE information to the configuration UPDATE intelligent contract, and UPDATEs the master node selection times of the new master node and the state of the old master node.

The nodes in the network can often go down, break down, delay and other faults. These failures result in frequent inconsistencies in blockchain states between nodes, and state synchronization protocols based on view numbers, chunk numbers, and chunk hash values are redesigned in this embodiment. When the node is in a laggard state such as just joining the network, restarting when dropped, etc., the protocol can be actively triggered to pull the latest state in the blockchain network.

In one embodiment, the state synchronization protocol, the specific process includes the steps of:

step C3.1: node _x Broadcast to other nodes<VIEW-FETCH,IP _x >The method comprises the steps of obtaining latest view information in a network through a message; when Node _i After receiving the VIEW-FETCH message, the Node will be sent with _x Transmitting<VIEW-REPLY,v′,n,IP _i >Replying the number v' of the view in which the user is located; when Node _x Received f+1 have the same view number v 'and v'When the VIEW-REPLY message is larger than v, the VIEW number of the viewer is updated to v'.

Step C3.2: node _x Broadcast to other nodes<DIGEST-FETCH,v′,h,IP _x >Acquiring abstracts of all missing block data; when Node _i After receiving the DIGEST-FETCH message, checking whether v' is consistent with the own view number; after passing the inspection, the Node is oriented to _x Transmitting<DIGEST-REPLY,v′,h,H,d,IP _i >Wherein H is Node _i The latest block number (H>h) D is the combined digest of all block information numbered between h+1 and H.

Step C3.3: when Node _x After receiving f+1 DIGEST-REPLY messages with the same H and d, selecting one Node _j Transmitting<BLOCK-FATCH,v′,h,H,IP _x >To pull detailed block data; when Node _j After receiving the BLOCK-FATCH message, the Node is sent with _x Transmitting<BLOCK-REPLY,v′,h,H,￡,d,IP _j >Wherein ≡contains all the block information of h+1 to H.

Step C3.4: when Node _x Upon receiving the BLOCK-REPLY message matching the DIGEST-REPLY, the BLOCK data is updated according to ≡and transactions in the BLOCK are performed.

In the embodiment, an optimistic consistency protocol is designed by referring to the thought of a collector in a blockchain scene, so that the message format is simplified and the communication complexity of the consistency protocol under normal conditions is reduced. The protocol changes the messaging mode of the preparation phase and the submission phase, all nodes do not broadcast messages to the whole network any more, but only unicast messages to the master node, and the master node replaces all nodes to collect the preparation/commit messages.

In one embodiment, the coherence protocol comprises the steps of:

step C4.1: the master node selects a plurality of legal transactions in the transaction pool to be packed into candidate blocks and broadcasts PRE-PREPARE messages to other nodes.

Step C4.2: when a node receives the PRE-PREPARE message, the message correctness is verified and a PREPARE-SEND message is sent to the master node; the PREPARE-CONFIRM message is broadcast to other nodes when the master node receives more than the nominal number of PRE-PREPARE-SEND messages that match the PRE-PREPARE messages.

Step C4.3: after the node receives the PREPARE-CONFIRM message, the node verifies the validity of the message and SENDs a COMMIT-SEND message to the master node; the COMMIT-CONFIRM message is broadcast to other nodes when the master node receives more than the nominal number of COMMIT-SEND messages that match the PRE-PREPARE message.

Step C4.4: when the node receives the COMMIT-CONFIRM message, it verifies the message validity and submits the block to the local block chain and performs transactions in the block in sequence.

Step C4.5: when the node still does not receive the confirmation message of the master node after the timeout in the step C4.3 or C4.4, the node immediately returns to the original protocol to broadcast the preparation/commit message to other nodes.

The invention also provides a Bayesian and busy family fault tolerance consensus system under a supply chain tracing scene, which comprises the following steps:

one or more processors;

The invention can provide the following conditions in a supply chain tracing scene:

1. random fairness selected by the master node: the invention provides a new main node selection rule for RDE-BFT algorithm by using a consistent hash algorithm based on a network configuration table and a previous block hash value and combining an average load thought, and can realize random fair selection of main nodes with lower cost under a dynamic network;

2. network dynamics: the invention adds the concept of network configuration table and configuration change transaction, designs a set of processes of nodes entering and exiting the network based on the network configuration table and the configuration change transaction, and realizes the dynamic property of the network;

3. efficiency of protocol mechanism: the invention optimizes the existing protocol mechanism of the PBFT algorithm, and mainly comprises the steps of refining the view replacement protocol into a periodic rotation protocol and an abnormal replacement protocol, designing a state synchronization protocol for a state-lagged node, and reducing the communication complexity of a consistency protocol under normal conditions based on a collector idea.

Compared with the original PBFT algorithm, the Bayesian fault tolerance method provided by the invention has the advantages of randomly selecting the main node, supporting the dynamic network, having low communication complexity and the like, and is particularly suitable for supply chain tracing scenes with complex members, strong openness and large node scale.

The invention can provide a safe, efficient and telescopic Bayesian fault-tolerant method for users in more fields of supply chain tracing, supply chain finance and the like.

It should be understood that the foregoing description of the preferred embodiments is not intended to limit the scope of the invention, but rather to limit the scope of the claims, and that those skilled in the art can make substitutions or modifications without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A Bayesian and busy family fault tolerance consensus method under a supply chain tracing scene is characterized in that: constructing a main node selection rule, wherein the main node selection rule comprises a hash space rule, a node mapping rule in a network configuration table, a previous block hash value mapping rule and a hash position mapping rule, so that random fair selection of the main node is realized;

2. The method for fault-tolerant consensus of byesting in a supply chain traceability scenario according to claim 1, wherein the method comprises the following steps: the network configuration table NCT records node information of all the added networks; each row represents a duplicate node, containing a IP, PK, state, time, note field; the IP field and the PK field respectively represent the IP address and the public key of the node, the State field represents the current State of the node, and the Time field represents the times when the current node is selected as a master node; the Note field indicates remark information for recording the time that the node was added, dropped, status updated, and penalized.

3. The method for fault-tolerant consensus of byesting in a supply chain traceability scenario according to claim 1, wherein the method comprises the following steps: the node dynamic network access rule is constructed, and the network dynamic property is realized by newly adding a network configuration table NCT and configuring and changing a transaction CMT;

the specific implementation method comprises the following steps:

4. A method for fault tolerant consensus of byesting in a supply chain traceability scenario according to claim 3 and characterized by: the specific implementation of the step 2 comprises the following sub-steps:

5. The method for fault-tolerant consensus of bayer process in supply chain traceability scenarios according to any one of claims 1 to 4, wherein the method is characterized by: the original protocol mechanism is deeply optimized by utilizing a periodic view rotation protocol, an abnormal view replacement protocol, a state synchronization protocol and a consistency protocol;

6. The method for fault-tolerant consensus of byesting in a supply chain traceability scenario of claim 5, wherein: after the new block is generated, all nodes automatically calculate a new master node and send VIEW CHANGE messages VIEW-CHANGE to other nodes according to the periodic VIEW rotation protocol; when the NEW master node receives the VIEW-CHANGE messages exceeding the rated number, checking and updating the local state, and simultaneously updating the own VIEW number and broadcasting NEW VIEW messages NEW-VIEW to other nodes by the NEW master node; after a certain node receives the NEW-VIEW message, verifying the correctness of the message and updating the own VIEW number; when the node is overtime and still does not receive the NEW-VIEW message, initiating an abnormal VIEW replacement protocol; the new master node sends a network configuration table UPDATE message NCT-UPDATE to the configuration UPDATE intelligent contract to UPDATE the own master node selection times.

7. The method for fault-tolerant consensus of byesting in a supply chain traceability scenario of claim 5, wherein: when a node detects that the current master node has malicious behaviors or does not receive a sent message after overtime, the abnormal VIEW replacement protocol calculates that the standby master node is used as a new master node and broadcasts a VIEW replacement message VIEW-CHANGE to other copy nodes; when the NEW master node receives the VIEW-CHANGE messages exceeding the rated number, the local state is checked and updated, and meanwhile, the NEW master node updates the own VIEW number and broadcasts NEW VIEW messages NEW-VIEW to other nodes; after a certain node receives the NEW-VIEW message, verifying the correctness of the message and updating the own VIEW number; when the node is overtime and still does not receive the NEW-VIEW message, initiating an abnormal VIEW replacement protocol; the new master node sends a network configuration table UPDATE message NCT-UPDATE to the configuration UPDATE intelligent contract to UPDATE the master node selection times of the new master node and the state of the old master node.

8. The method for fault-tolerant consensus of byesting in a supply chain traceability scenario of claim 5, wherein: the state synchronization protocol is that a certain backward node broadcasts a VIEW pulling message VIEW-FETCH to other nodes, and the other nodes send VIEW numbers where VIEW-REPLY messages REPLY to themselves; when the lagging node receives more than rated number of VIEW-REPLY messages with the same VIEW numbers, the VIEW numbers of the lagging node are updated; the lagging node broadcasts a block data abstract acquisition message DIGEST-FETCH to other nodes, and the other nodes send DIGEST-REPLY messages to REPLY the combined abstract of the missing block information; when the laggard node receives the DIGEST-REPLY messages with the same block abstracts exceeding the rated number, temporarily caching the abstracted information; the laggard node selects one of the nodes to send a BLOCK-FATCH message so as to pull detailed BLOCK data; after receiving the BLOCK-FATCH message, the node sends a BLOCK-REPLY message to the laggard node to REPLY the missing BLOCK information; when the backward node receives the BLOCK-REPLY message matched with the DIGEST-REPLY, the backward node updates the BLOCK data of the backward node and executes the transaction in the BLOCK.

9. The method for fault-tolerant consensus of byesting in a supply chain traceability scenario of claim 5, wherein: the agreement protocol, the master node chooses several legal transactions in the transaction pool to pack into candidate blocks and broadcasts the PRE-preparation message PRE-PREPARE to other nodes; after a node receives the PRE-PREPARE message, verifying the correctness of the message and sending a PRE-PREPARE-SEND message to the master node; broadcasting a preparation confirmation message PREPARE-CONFIRM to other nodes when the master node receives more than the rated number of PRE-PREPARE messages matched with the PRE-PREPARE messages; after the node receives the PREPARE-CONFIRM message, verifying the validity of the message and sending a block pre-COMMIT message COMMIT-SEND to the master node; submitting confirmation messages COMMIT-CONFIRM to other node broadcast blocks when the master node receives more than rated number of COMMIT-SEND messages matched with the PRE-PREPARE messages; after receiving the COMMIT-CONFIRM message, the node verifies the validity of the message and submits the block to a local block chain and sequentially executes transactions in the block; when the node still does not receive the confirmation message of the master node after timeout, the original protocol is immediately restored to broadcast two types of message preparation/commit messages of the classical PBFT algorithm to other nodes.

10. The Bayesian and busy family fault tolerance consensus system in a supply chain tracing scene is characterized by comprising:

one or more processors;

storage means for storing one or more programs which, when executed by the one or more processors, cause the one or more processors to implement the method of bartholinitia fault tolerance consensus in a supply chain traceability scenario according to any of claims 1 to 9.