Consensus method and system for alliance chain

Abstract

The invention provides an alliance chain-oriented consensus method and system. The method comprises the steps of obtaining a current credit point value and a current credit point growth rate of each node in an alliance chain; selecting nodes in the alliance chain according to the current credit point value, the current credit point growth rate and a verifiable random function to obtain a current consensus node set and a candidate consensus node set; when any consensus node in the current consensus node set receives transaction data, performing view conversion on a current view corresponding to the current consensus node set according to a verification result of the transaction data obtained by verification of any consensus node, the master-slave state of the consensus node sending the transaction data and the candidate consensus node set, obtaining an updated current view; and according to the updated current view, updating the current consensus node set, and based on the updated current consensus node set, performing response operation on the transaction data. According to the method, the consensus efficiency and performance are improved under a large-scale alliance chain.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a consensus method and system for alliance chains. Background Art

[0002] The decentralized nature of the alliance chain can eliminate the single point of failure and data tampering risks in the traditional traceability system, ensuring the security and credibility of the traceability data. By storing the traceability information in an unalterable manner on the alliance chain, a fully traceable, transparent and fair traceability process can be achieved. In addition, the alliance chain can also provide real-time data updates and sharing, speeding up collaboration and response. Therefore, how to achieve an effective alliance chain consensus to improve the performance of the alliance chain and reduce energy consumption and costs to improve the overall performance in the traceability system is an important topic that needs to be studied urgently.

[0003] In related technologies, the Practical Byzantine Fault Tolerance (PBFT) algorithm is usually used to achieve consensus in consortium chains. This method relies on multiple rounds of message passing and complex protocol interactions to reach consensus, which results in a significant decrease in consensus efficiency and performance in consortium chain environments with a large scale of network nodes. Summary of the invention

[0004] The present invention provides a consensus method and system for alliance chains, which are used to solve the defects of low consensus efficiency and performance in the prior art of using practical Byzantine fault-tolerant algorithms to perform consensus on alliance chains, and to improve consensus efficiency and performance.

[0005] The present invention provides a consensus method for alliance chain, including: Get the current credit score value and current credit score growth rate of each node in the alliance chain; According to the current credit score value and the current credit score growth rate, and a verifiable random function, the nodes in the alliance chain are elected to obtain a current consensus node set and a candidate consensus node set; When any consensus node in the current consensus node set receives the transaction data, according to the verification result of the transaction data obtained by the any consensus node, the master-slave status of the consensus node sending the transaction data, and the candidate consensus node set, a view conversion is performed on the current view corresponding to the current consensus node set to obtain an updated current view; According to the updated current view, the current consensus node set is updated, and based on the updated current consensus node set, a response operation is performed on the transaction data.

[0006] According to a consensus method for alliance chain provided by the present invention, the step of obtaining the current credit score value of each node in the alliance chain includes: Calculate the total credit score according to the credit score value of each node in each historical round to obtain the total value of the historical credit score of each node; Calculate the consensus incomplete rate according to the consensus participation record of each node in each historical round to obtain the historical consensus incomplete rate of each node; Calculate the message sending error rate according to the message sending records of each node in each historical round to obtain the historical message sending error rate of each node; Calculate the activity of each node according to the communication records of each node in each historical round to obtain the historical activity of each node; The current credit score value of each node is calculated by combining the historical credit score total value, the historical consensus incomplete rate, the historical message sending error rate and the historical activity.

[0007] According to a consensus method for alliance chain provided by the present invention, the step of obtaining the current credit score growth rate of each node in the alliance chain includes: The credit score growth rate is calculated based on the ratio between the current credit score value of each node and the credit score value of each node in each historical round to obtain the current credit score growth rate of each node.

[0008] According to a consensus method for alliance chain provided by the present invention, the nodes in the alliance chain are elected according to the current credit score value and the current credit score growth rate, and a verifiable random function to obtain a current consensus node set and a candidate consensus node set, including: According to the current credit score value and the current credit score growth rate, nodes in the alliance chain are elected to obtain a set of candidate nodes; Verifying the candidate nodes in the candidate node set according to the verifiable random function; According to the verification result, the candidate nodes in the candidate node set are elected to obtain an initial consensus node set; Sort the nodes according to the current credit score value and node identifier of each consensus node in the initial consensus node set; According to the sorting result, the initial consensus node set is divided into nodes to obtain the current consensus node set and the candidate consensus node set; Among them, the current credit score value of the consensus node in the current consensus node set is higher than the current credit score value of the consensus node in the candidate consensus node set.

[0009] According to a consensus method for alliance chain provided by the present invention, the verification result of the transaction data obtained by verification by any consensus node, the master-slave status of the consensus node sending the transaction data, and the candidate consensus node set, performing view conversion on the current view corresponding to the current consensus node set to obtain an updated current view, including: In the case that any consensus node in the current consensus node set receives the transaction data, if it is determined that the verification result of the transaction data is failed, and the master-slave status of the consensus node sending the transaction data is the master node, a new consensus node is selected from the candidate consensus node set, and a view conversion is performed on the current view to obtain the updated current view.

[0010] According to a consensus method for alliance chain provided by the present invention, the method further includes: If it is determined that the verification result of the transaction data is passed, and the master-slave status of the consensus node sending the transaction data is a slave node, after waiting for the target reply time, the consensus node receiving the transaction data is controlled to forward the transaction data to the consensus master node in the current consensus node set; Determine whether the consensus master node has abnormal behavior or failure according to the verification result of the broadcast information; the broadcast information is generated by the consensus master node according to the transaction data; the verification result of the broadcast information is obtained by verification by each consensus slave node in the current consensus node set; When it is determined that the consensus master node has abnormal behavior or fails, a new consensus node is selected from the candidate consensus node set, and a view conversion is performed on the current view to obtain the updated current view.

[0011] According to a consensus method for alliance chain provided by the present invention, the method further includes: When it is determined that the consensus master node has no abnormal behavior and no failure occurs, verify whether the consensus nodes in the current consensus node set have reached a consensus according to the consensus confirmation message received by each consensus node in the current consensus node set; wherein the consensus confirmation message is sent by each consensus slave node; When it is verified that the consensus nodes in the current consensus node set have not reached a consensus, a new consensus node is selected from the candidate consensus node set, and a view conversion is performed on the current view to obtain the updated current view.

[0012] The present invention also provides a consensus system for alliance chains, including: Evaluation unit, used to obtain the current credit score value and current credit score growth rate of each node in the alliance chain; An election unit, configured to elect nodes in the alliance chain according to the current credit score value and the current credit score growth rate, and a verifiable random function, to obtain a current consensus node set and a candidate consensus node set; a conversion unit, configured to, when any consensus node in the current consensus node set receives transaction data, perform view conversion on a current view corresponding to the current consensus node set according to a verification result of the transaction data obtained by verification by any consensus node, a master-slave state of the consensus node sending the transaction data, and the candidate consensus node set, so as to obtain an updated current view; The consensus unit is used to update the current consensus node set according to the updated current view, and to respond to the transaction data based on the updated current consensus node set.

[0013] The present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, a consensus method for a consortium chain as described above is implemented.

[0014] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a consensus method for a consortium chain as described in any one of the above.

[0015] The present invention also provides a computer program product, including a computer program, which, when executed by a processor, implements any of the above-mentioned consensus methods for alliance chains.

[0016] The consensus method and system for alliance chain provided by the present invention elects nodes in the alliance chain according to the current credit score value and the current credit score growth rate of each node in the alliance chain and a verifiable random function to obtain a current consensus node set and a candidate consensus node set. When any consensus node in the current consensus node set receives transaction data, the current view corresponding to the current consensus node set is converted according to the verification result of the transaction data obtained by any consensus node, the master-slave state of the consensus node sending the transaction data, and the candidate consensus node set to obtain an updated current view. The current consensus node set is updated according to the updated current view, so as to respond to the transaction data based on the updated current consensus node set. Thus, high throughput can be achieved, that is, a large number of transactions and block confirmations can be processed, and the system has the characteristics of low latency, and can quickly confirm transactions and generate new blocks. It can also save energy and computing resources, reduce operating costs, and improve the efficiency and sustainability of the entire system. Therefore, the method has significant advantages in throughput, latency, fault tolerance, and resource efficiency, ensures consensus efficiency and performance, and provides reliable technical support for traceability applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0018] Figure 1 It is a flow chart of the consensus method for alliance chain provided by the present invention.

[0019] Figure 2 It is a flowchart of the steps of obtaining the current credit score value provided by the present invention.

[0020] Figure 3 It is a schematic diagram of the consistency protocol provided by the present invention.

[0021] Figure 4 It is a schematic diagram comparing the throughput of the consensus method for the alliance chain provided by the present invention with the throughput of the consensus method based on the practical Byzantine fault-tolerant protocol.

[0022] Figure 5 It is a schematic diagram comparing the transaction delay time of the consensus method for the alliance chain provided by the present invention and the transaction delay time of the consensus method based on the practical Byzantine fault-tolerant protocol.

[0023] Figure 6It is a structural diagram of the consensus system for alliance chain provided by the present invention.

[0024] Figure 7 It is a structural schematic diagram of the electronic device provided by the present invention. DETAILED DESCRIPTION

[0025] In order to make the purpose, technical solution and advantages of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with the drawings of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0026] Traceability technology is a technology that tracks and records the source, flow and processing of products or information, and aims to provide traceability and transparency of products or information to ensure their quality, safety and compliance. Traceability technology is widely used in many industries. For example, in the food industry, traceability technology can be used to track the source of raw materials, production process and circulation path of food to ensure the safety and quality of food; in the pharmaceutical industry, traceability technology can track the production, distribution and use of drugs to ensure the compliance and authenticity of drugs; in the agricultural field, traceability technology can be used to track the planting, breeding and processing of agricultural products to ensure the quality, environmental friendliness and sustainability of agricultural products. In addition, traceability technology is also used in electronic products, automobiles and other fields.

[0027] At present, many industries use traceability technology to improve product quality and safety, reduce risks and fraud, and increase consumer trust. With the development of emerging technologies such as blockchain, Internet of Things, and artificial intelligence, traceability technology is constantly innovating and evolving. Many organizations are also promoting the standardization and promotion of traceability technology to establish a more reliable and efficient traceability system. As a blockchain technology with an access mechanism, the application of alliance chain in the field of traceability is developing rapidly. The decentralized nature of the alliance chain can eliminate the single point of failure and data tampering risks in the traditional traceability system, ensuring the security and credibility of the traceability data. By storing the traceability information on the alliance chain in an unalterable manner, a traceability process that is traceable, transparent, and fair can be achieved throughout the process. In addition, the alliance chain can also provide real-time data updates and sharing, and accelerate collaboration and response. However, alliance chain technology also faces some challenges in the field of traceability, such as performance and scalability limitations, high energy consumption, and cost.

[0028] Based on the above reasons, in order to further improve the performance of the alliance chain and reduce energy consumption and costs to improve the overall performance in practical applications, a large number of scholars have optimized and improved the blockchain consensus algorithm used in the traceability scenario to obtain better results. For example, some scholars have proposed a pharmaceutical-practical Byzantine fault-tolerant algorithm (P-PBFT for short) based on PBFT, grouping and credit voting. This algorithm combines the characteristics of the pharmaceutical supply chain, optimizes the consistency protocol in the original algorithm, divides large network nodes into different consensus sets according to the response speed, and forms a group consensus. However, when the scale of the alliance chain network nodes is large, this method is complex to calculate, and the consensus efficiency is significantly reduced, which cannot meet the actual needs of the alliance chain traceability general system. For another example, some scholars have proposed a decentralized security and algorithm performance testing method for applying the improved PFBT algorithm to the logistics transaction system of steel enterprises. However, this method requires multiple rounds of message passing and complex protocol interactions to reach a consensus. These additional communication and computing overheads will affect system performance, especially when the network latency is high or the load is heavy.

[0029] Therefore, the relevant technology adopts the practical Byzantine fault-tolerant algorithm for the consensus of the alliance chain, which leads to a significant decrease in the consensus efficiency and performance in the alliance chain environment with a large scale of network nodes.

[0030] In this regard, this embodiment provides a consensus method for alliance chain, which is a high-performance consensus method for alliance chain traceability scenarios, which can effectively solve the problems of low efficiency, low throughput, high transaction latency and poor security performance existing in related technologies in large-scale scenarios.

[0031] It should be noted that the consensus method for alliance chain provided in this embodiment is based on a high-performance consensus algorithm for alliance chain traceability scenarios to carry out the network consensus aggregation process of the alliance chain. This method can run on the application platform of the alliance chain used for traceability.

[0032] The method provided in this embodiment can be applied to various transaction scenarios, including but not limited to payment scenarios, digital identity authentication, insurance claims, etc., which are not specifically limited in this embodiment.

[0033] Figure 1 It is a flow chart of the consensus method for alliance chain provided by the present invention; Figure 1 As shown, the consensus method for alliance chain provided in this embodiment includes: step 100, step 200, step 300 and step 400.

[0034] Step 100, obtaining the current credit score value and current credit score growth rate of each node in the alliance chain.

[0035] Among them, the alliance chain contains multiple optional nodes, and the number of nodes can be configured according to actual needs. For example, the number of optional network nodes is set to at least 8, that is, the network node scale N can be greater than or equal to 8, etc. This embodiment does not make specific limitations on this.

[0036] Optionally, in the alliance chain, the current credit score value and the current credit score growth rate of each node can be obtained first to evaluate the credibility and reliability of each node, so as to achieve more effective node election and consensus. The current credit score value and the current credit score growth rate here are the credit score value and credit score growth rate calculated for the current round.

[0037] It should be noted that before the end of each round, the consensus master node of that round will initiate a request to update the credit points and credit point growth rate. The consensus node that receives the request will calculate the new credit points of all nodes in the network based on the local behavior record metadata pool. Then, the proposed consistency protocol is used to reach a consensus to ensure that the new credit points and credit point growth rate are consistent. Once consensus is reached, the master node will write the node information with updated credit points and credit point growth rate into the behavior record table and broadcast it to the entire network. Then it enters the next round of consensus election phase.

[0038] Therefore, the current credit score value and the current credit score growth rate here can be obtained by statistical calculation or dynamic evaluation of the historical data of each historical round of each node in the node behavior record table. The historical data here includes but is not limited to credit score calculation records, consensus participation records, message sending records and communication records, which are not specifically limited in this embodiment.

[0039] Figure 2 is a flow chart of the steps of obtaining the current credit score value provided by the present invention; Figure 2 As shown, in some embodiments, the step of obtaining the current credit score value of each node in the alliance chain in step 100 specifically includes step 110, step 120, step 130, step 140 and step 150.

[0040] Step 110, calculating the total credit score according to the credit score value of each node in each historical round, and obtaining the total value of the historical credit score of each node.

[0041] Optionally, since the calculation of the credit score value of each round of the node is related to the credit score value of the node in the historical round, the total credit score calculation can be performed on the credit score value of each node in each historical round to obtain the total historical credit score value of each node in the current round. The specific calculation formula is as follows: ; in, and It refers to the round number; is the node number, For the Round (current round) node Total historical credit score; It is the influence factor of historical credit score value; Refers to the Round (also known as historical round) node The credit score value, It refers to the historical rounds that can be traced back to the maximum number, that is, the number of historical rounds.

[0042] Step 120, calculating the consensus incomplete rate according to the consensus participation record of each node in each historical round, and obtaining the historical consensus incomplete rate of each node.

[0043] Optionally, the incomplete rate is used as an indicator to evaluate the completion of node consensus, which focuses on the number of times the node fails to successfully complete the consensus due to its own failure. Using the incomplete rate as an indicator, nodes with more completed times can be preferentially selected to participate in the consensus, because the status of these nodes is relatively stable, thereby improving the overall consensus completion rate. Among them, the historical consensus incomplete rate of each node in the current round can be calculated based on the number of times each node failed to complete the consensus in the consensus participation records of each historical round and the total number of times it participated in the consensus. The specific calculation formula is as follows: ; in, For Node The historical consensus non-completion rate; For Node The number of times consensus was not reached in all historical rounds; For Node The total number of consensus participations in all historical rounds.

[0044] Step 130 , calculating the message sending error rate according to the message sending records of each node in each historical round, and obtaining the historical message sending error rate of each node.

[0045] Optionally, for a node, the error rate is mainly used to evaluate its honesty when sending messages. Once a node sends an erroneous message, other nodes can report it. Only after consensus is reached through the consistency protocol will the report be recorded in the system. Among them, the historical message sending error rate of each node is calculated based on the number of times each node sent an error message and was successfully reported in the message sending record of each historical round and the total number of times it participated in the consensus. The specific calculation formula is as follows: ; in, For Node The historical message sending error rate, For Node The number of times error messages were sent and successfully reported in all historical rounds, For Node The total number of consensus participations in all historical rounds.

[0046] Step 140: Calculate the activity of each node according to the communication record of each historical round to obtain the historical activity of each node.

[0047] Optionally, the activity of a node is mainly used to evaluate its activity performance. In the Byzantine consensus process, nodes need to broadcast messages to each other and wait for the verification of the messages. When the activity of the nodes participating in the consensus is low, it may cause other nodes to have to wait for a long time, thus hindering the consensus. Therefore, by introducing this indicator, the chance of nodes with higher activity being selected can be increased, thereby reducing the delay of consensus and improving the success rate of consensus.

[0048] The historical activity of each node can be calculated based on the offline time, network delay time and network access time of each node in the communication records of each historical round. The specific calculation formula is as follows: ; in, For Node The historical activity and is the weight coefficient; , and Node Offline time, network delay time, and network access time in all historical rounds.

[0049] Step 150, combining the historical credit score total value, the historical consensus incomplete rate, the historical message sending error rate and the historical activity, to calculate the current credit score value of each node.

[0050] Optionally, after obtaining the historical total credit score value, historical consensus incomplete rate, historical message sending error rate and historical activity of each node, these parameters can be combined to comprehensively evaluate the performance of the node to obtain the current credit score value of each node. When a node has malicious behavior or failure, the credit score value of the node is updated in time to improve the success rate of consensus. It should be noted that all the above parameters are calculated based on the historical data of the node, so the evaluation results are subjective. This also means that for a given node, all nodes can calculate the same credit score value. Moreover, since these historical evaluation data are stored on the chain in a consensus manner and downloaded by all nodes in the network to update the local metadata pool, they are unchangeable. Therefore, malicious nodes cannot affect the calculation of credit points by simply modifying the historical performance records of the node.

[0051] In the process of calculating the credit score value, since the influence of various parameters on the overall credit score value is different, their influence can be adjusted by setting the weight factors of the above parameters. Accordingly, the current credit score value of each node in the current round can be calculated by the following formula: ; in, For Node Current credit value, , , and They are the weight coefficients corresponding to the total value of historical credit points, historical consensus incomplete rate, historical message sending error rate and historical activity. , , and The specific value can be set according to actual needs, such as , , and Set to 0.2, 0.3, 0.2, 0.3 respectively.

[0052] Therefore, by configuring corresponding weights for each parameter, the evaluation of a node focuses more on the comprehensive behavioral performance of the node itself rather than a certain performance of the node, which can effectively improve the accuracy of node performance evaluation.

[0053] For example, in some embodiments, the step of obtaining the current credit score growth rate of each node in the alliance chain in step 100 specifically includes: The credit score growth rate is calculated based on the ratio between the current credit score value of each node and the credit score value of each node in each historical round to obtain the current credit score growth rate of each node.

[0054] Optionally, the current credit score growth rate of each node is used to evaluate the performance of the node. By calculating the credit score growth rate, it is possible to understand the development of the node after joining the alliance chain, and to incentivize the node to take good behavior to keep the credit score growing rapidly. The high and low credit score growth rates reflect the differences in the health of the nodes. Nodes newly joining the alliance chain system will be given an initial credit score growth rate. Here, the credit score growth rate of the nodes newly joining the alliance chain system can be initialized to 50%, which can be determined according to actual needs; subsequently, according to the changes in the node's credit score, its credit score growth rate will be adjusted accordingly. Specifically, the following formula can be used to dynamically calculate the current credit score growth rate of all nodes in the network: ; in, is the current credit score growth rate of each node; For the Round (current round) node Current credit value of For the front Round Node Historical credit score value.

[0055] Step 200, electing nodes in the alliance chain according to the current credit score value and the current credit score growth rate, and a verifiable random function, to obtain a current consensus node set and a candidate consensus node set.

[0056] After dynamically estimating the current credit score value and the current credit score growth rate of each node based on step 100, the current credit score value and the current credit score growth rate of each node, as well as the verifiable random function, can be combined to elect nodes in the alliance chain to form a current consensus node set that can directly participate in the consensus in the current round, and a candidate consensus node set that serves as a candidate consensus node in the current round.

[0057] Exemplarily, during the election process, the election authority of a node depends on the current credit score value of each node and the difference in the current credit score growth rate. In order to ensure the efficiency and security of the system, a verifiable random function (VRF) is used to randomly sample nodes with election authority to form an initial consensus node set. The initial consensus node set is ranked according to the credit score value and divided into a current consensus node set and a candidate consensus node set. The verifiable random function VRF accepts a specific random number seed input seed and the private key priv_key of the node, and outputs a random number randNum and nodeProof. The verifier can use the output randNum, nodeProof and the input seed seed to verify the authenticity and reliability of the random number. Therefore, a threshold w can be defined for the randNum output by the VRF, stipulating that when the random number seed is greater than or equal to the threshold, the node can become part of the initial consensus node set. The definition of the threshold is mainly used to adjust the difficulty of node election to meet system requirements.

[0058] In some embodiments, step 200 specifically includes: According to the current credit score value and the current credit score growth rate, nodes in the alliance chain are elected to obtain a set of candidate nodes; Verifying the candidate nodes in the candidate node set according to the verifiable random function; According to the verification result, the candidate nodes in the candidate node set are elected to obtain an initial consensus node set; Sort the nodes according to the current credit score value and node identifier of each consensus node in the initial consensus node set; According to the sorting result, the initial consensus node set is divided into nodes to obtain the current consensus node set and the candidate consensus node set; Among them, the current credit score value of the consensus node in the current consensus node set is higher than the current credit score value of the consensus node in the candidate consensus node set.

[0059] Optionally, step 200 may be decomposed into step 210 , step 220 , step 230 , step 240 , step 250 and step 260 in detail.

[0060] Step 210, based on the current credit score value and the current credit score growth rate, the nodes in the alliance chain are verified for election authority, and nodes with election authority are selected to form a set of candidate nodes.

[0061] Step 220, in the last round of consensus of the previous iteration, the consensus master node uses a pseudo-random number generator (PRNG) to generate a random number seed based on the hash value of the previous block, and adds the seed to the currently generated block. Therefore, the random number seed can be observed by all nodes in the alliance chain and the entire network.

[0062] Step 230: For any node X in the candidate node set, the VRF verification function is used to calculate a random number randNum based on the seed, and check whether the random number is less than a preset threshold. w , to determine whether node X belongs to the initial consensus node set. If node X meets the conditions, it will broadcast a connection request and wait for other consensus nodes to initiate connection requests within the waiting time waittime to join the initial consensus node set. and proof The specific calculation formula is as follows: ; ; in, is the private key, Is the random number seed.

[0063] In some embodiments, the threshold for node election w It can be configured according to actual needs, such as setting the threshold w Set to 0.37 magnitude.

[0064] Step 240, when other nodes Y receive the connection request, they can to verify its validity. If it is proven to be valid, continue with the subsequent steps; otherwise, terminate the connection request.

[0065] In step 250, other nodes Y will use the public key priv_key, random number seed seed and nodeProof of node X to verify node X. If the verification fails, node Y can send a report request to the entire network and record the behavior of node X in the behavior record table. If the verification passes and node X is also part of the initial consensus node set, node Y can send a connection request to node X to complete the connection, thereby adding node X to the initial consensus node set. The specific formula for the verification calculation is as follows: ; Step 260, after the consensus nodes complete the connection, sort the nodes according to the identification ID of each node in the initial consensus node set obtained by the election and the current credit score value of each node in the behavior record table, that is, sort the identification ID of each node in the order of the current credit score value from high to low to obtain the sorting result of each node in the initial consensus node set; and according to the sorting result, select multiple nodes with the top ranking to form the current consensus node set; and construct the remaining multiple nodes to form a candidate consensus node set. For example, the top 85% of the nodes can be selected to form the current consensus node set, and the bottom 15% of the nodes can be constructed to form the candidate consensus node set. The nodes in the candidate consensus node set here are the candidate nodes of the current consensus node set, that is, when a consensus node in the current consensus node set fails or the node actively exits, the candidate consensus nodes in the candidate consensus node set can be quickly selected as replacement nodes for the failed consensus nodes to ensure the stability and reliability of the system.

[0066] The method provided in this embodiment can effectively elect stable and reliable consensus nodes by comprehensively considering credit points, growth rate and verifiable random function to select nodes, and divide nodes according to ranking, so as to effectively improve the stability, reliability and consensus efficiency of the system.

[0067] Step 300, when any consensus node in the current consensus node set receives transaction data, based on the verification result of the transaction data obtained by any consensus node, the master-slave status of the consensus node sending the transaction data, and the candidate consensus node set, a view conversion is performed on the current view corresponding to the current consensus node set to obtain an updated current view.

[0068] Figure 3 is a schematic diagram of the consistency protocol provided by the present invention; Figure 3 As shown in the figure, node C represents the client, node 0 represents the master node, nodes 1 and 2 represent normal slave nodes, and node 3 is a malicious slave node, also called a Byzantine node. In the process of protocol consistency, it is necessary to ensure that the system can still run correctly and reach consensus when there are malicious nodes (i.e. Byzantine nodes) in the network.

[0069] Therefore, in order to ensure that the system can still run correctly and reach consensus when there are malicious nodes (i.e. Byzantine nodes) in the current consensus node set, that is, to implement an effective Byzantine consistency protocol and solve the communication overhead problem existing in many current consensus algorithms, when any consensus node in the current consensus node set receives transaction data, the network consensus process can be started, and according to the verification result of the transaction data obtained by the consensus node during the consensus process and the master-slave status of the consensus node that sends the transaction data, it is determined whether there are nodes with faults and abnormal behaviors during the consensus process, so that when there are nodes with faults or abnormal behaviors, the candidate consensus node set is jointly triggered to switch the view of the current view corresponding to the current consensus node set to obtain a new current view.

[0070] For example, in some embodiments, step 300 specifically includes: When any consensus node in the current consensus node set receives the transaction data, if it is determined that the verification result of the transaction data is not verified, and the master-slave state of the consensus node sending the transaction data is the master node, a new consensus node is selected from the candidate consensus node set, and the current view is converted to obtain the updated current view; If it is determined that the verification result of the transaction data is passed, and the master-slave status of the consensus node sending the transaction data is a slave node, after waiting for the target reply time, the consensus node receiving the transaction data is controlled to forward the transaction data to the consensus master node in the current consensus node set; Determine whether the consensus master node has abnormal behavior or failure according to the verification result of the broadcast information; the broadcast information is generated by the consensus master node according to the transaction data; the verification result of the broadcast information is obtained by verification by each consensus slave node in the current consensus node set; When it is determined that the consensus master node has abnormal behavior or fails, a new consensus node is selected from the candidate consensus node set, and a view conversion is performed on the current view to obtain the updated current view; When it is determined that the consensus master node has no abnormal behavior and no failure occurs, verify whether the consensus nodes in the current consensus node set have reached a consensus according to the consensus confirmation message received by the consensus master node; wherein the consensus confirmation message is sent by each of the consensus slave nodes; When it is verified that the consensus nodes in the current consensus node set have not reached a consensus, a new consensus node is selected from the candidate consensus node set, and a view conversion is performed on the current view to obtain the updated current view.

[0071] Optionally, step 300 specifically includes step 310 , step 320 , step 330 , step 340 , step 350 , step 360 and step 370 .

[0072] Step 310, after selecting the current consensus node set, initialize the view according to the current consensus node set to obtain the current view corresponding to the current consensus node set. And according to the current view, elect the consensus master node corresponding to the current view according to the master node election algorithm, that is, the number of the consensus master node in the current consensus node set. , the formula is as follows: ; in, Indicates the height of the current block. Encode the view; The maximum number of failed nodes allowed by the system. In each round (referred to as round), a block will be generated, and the view number is view+1, and the consensus master node will be replaced accordingly.

[0073] Step 320, when the transaction initiator in the system initiates the transaction data, the transaction initiator will use the private key to sign the transaction data and then broadcast it to the entire network. The format of the transaction data message can be <<CRQUEST,TIMESTAMP, DATA, ABSTRACT, CLIENT> , SIGNATUREi>. Among them, CRQUEST is the message prefix, which is used to indicate the type or purpose of the message; TIMESTAMP is the timestamp, DATA is the transaction data, ABSTRACT is the summary of the transaction data, CLIENT is the identifier of the transaction initiator (or client), and SIGNATUREi is the signature of the initiator.

[0074] Step 330, when any node receives the transaction data, first determine whether it is a consensus node in the current consensus node set. If it is not a consensus node in the current consensus node set, forward the transaction to any consensus node in the current consensus node set. If it is determined that any consensus node in the current consensus node set receives the transaction data, the consensus node verifies the legitimacy of the transaction data to obtain the verification result of the transaction data. If the verification result is that the transaction data passes the verification, that is, the transaction data is legal, then the node begins to prepare to build the current block. If the verification result is that the transaction data fails to pass the verification, that is, the transaction data is illegal (such as signature mismatch, data format error, etc.), the node will directly discard the transaction and determine whether the master-slave status of the consensus node that sent the transaction data is the master node. If it is further determined that the transaction information is sent by the consensus master node, it is determined that the consensus master node has abnormal behavior. At this time, the view replacement protocol can be quickly started to select a new consensus node from the candidate consensus node set to replace the consensus node with abnormal behavior in the current consensus node set without checking the message content to ensure the normal operation and security of the system. It should be noted that the view change protocol follows the steps in the PBFT consensus, but the new consensus node elected is selected from the set of candidate consensus nodes.

[0075] Step 340, after determining that the verification result of the transaction data is verified, and the master-slave state of the consensus node sending the transaction data is a slave node, after waiting for the target reply time waittime, the consensus node receiving the transaction data is controlled to forward the transaction data in the form of a request message to the consensus master node in the current consensus node set, so that the consensus master node processes the request message corresponding to the transaction data and determines whether the message currently being processed is legal. If the message is legal, the consensus master node p will broadcast a consensus preparation message (also called a broadcast message) to each consensus slave node. The format of the message can be <<PPREPARE, HEIGHT, VIEW, t, d, m(d)> , SIGNATUREp>. PPREPARE is the identifier or prefix of the message, which is used to indicate the type or purpose of the message; HEIGHT represents the height of the current block plus 1, VIEW represents the view number, t represents the timestamp, d represents the transaction data; m(d) is the summary of the transaction data, and SIGNATUREp represents the signature of the consensus master node p.

[0076] In step 350, after receiving the broadcast information, i.e., the preparation message, sent by the consensus master node, each consensus slave node will verify the broadcast information to determine whether the consensus master node has abnormal behavior (such as malicious behavior) or failure based on the verification information. In the case of determining that the consensus master node has abnormal behavior or failure, the consensus slave node will initiate a view conversion request to select a new consensus node from the candidate consensus node set, perform view conversion on the current view, obtain an updated current view, and record the identifier of the consensus master node in the node behavior table.

[0077] Step 360: When it is determined that the consensus master node has no abnormal behavior and no failure has occurred, the consensus slave node will broadcast a consensus confirmation message to the consensus master node. The format of the confirmation message is <<PRCOMMIT,VIEW,TIMESTAMP,ABSTRACT,SN,VALID> ,SIGNATUREi>. Among them, PRCOMMIT is the identifier or prefix of the message, which is used to indicate the type or purpose of the message; VIEW represents the view number; TIMESTAMP is the timestamp; ABSTRACT is the summary; SN is the sequence number; VALID / INVALID: represents the validity judgment of the message by node i, that is, the valid flag / invalid flag; SIGNATUREi represents the signature of node i, which can effectively ensure the integrity, sequence, identity authentication and tamper-proof of the information.

[0078] Step 370, based on the consensus confirmation message received by each consensus node in the current consensus node set, verify whether the consensus nodes in the current consensus node set have reached a consensus. For example, when all consensus nodes receive 2f+1 identical confirmation messages, it is determined that a consensus has been reached. At this time, the request sent by the client can be executed, a reply can be sent to the client, and the block can be published, and the view number can be increased to v+1. Otherwise, it is determined that the consensus nodes in the current consensus node set have not reached a consensus. At this time, a new consensus node needs to be selected from the candidate consensus node set, the view switching process is executed for the current view, and the identifiers of the nodes that have not reached a consensus are recorded in the node behavior table.

[0079] In summary, the method provided in this embodiment updates the view through a consistency protocol in the presence of malicious nodes (Byzantine nodes) so that the system can still operate correctly and reach a consensus, while effectively reducing the communication overhead in the consensus process and improving consensus efficiency and security.

[0080] Step 400: updating the current consensus node set according to the updated current view; and performing a response operation on the transaction data based on the updated current consensus node set.

[0081] After obtaining the updated current view, the abnormal consensus nodes in the current consensus node set can be removed, and new consensus nodes selected from the candidate consensus node set can be added to obtain the updated current consensus node set. Based on the updated current view, the consensus master node and consensus slave node in the updated current consensus node set are re-determined, and the transaction data is processed through the consensus algorithm based on the re-determined consensus master node and consensus slave node, and the response information is replied to the client. The format of the response information here can be <<FINREPLY,CLIENT,TIMESTAMP,ABSTRACT, NODENUM, VALID> , SIGNATUREp>. Among them, FINREPLY is an identifier or prefix used to indicate the type or purpose of the message; CLIENT represents the initiator of the transaction data, that is, the client identifier; TIMESTAMP represents the timestamp; ABSTRACT represents the summary; NODENUM represents the number of consensus nodes; VALID represents the validity judgment result; SIGNATUREp sends the message indicating the signature of the consensus master node p.

[0082] The method provided in this embodiment elects nodes in the alliance chain according to the current credit score value and the current credit score growth rate of each node in the alliance chain, and a verifiable random function, to obtain a current consensus node set and a candidate consensus node set, and when any consensus node in the current consensus node set receives transaction data, the current view corresponding to the current consensus node set is converted according to the verification result of the transaction data obtained by any consensus node, the master-slave state of the consensus node that sends the transaction data, and the candidate consensus node set to obtain an updated current view, and the current consensus node set is updated according to the updated current view, so as to respond to the transaction data based on the updated current consensus node set, thereby achieving high throughput, that is, being able to process a large number of transactions and block confirmations, and having the characteristics of low latency, being able to quickly confirm transactions and generate new blocks, and being able to save energy and computing resources, reduce operating costs, and improve the efficiency and sustainability of the entire system, thereby making the method have significant advantages in terms of throughput, latency, fault tolerance, and resource efficiency, ensuring consensus efficiency and performance, and providing reliable technical support for traceability applications.

[0083] The following specific simulation comparative experiments are used to verify the effectiveness of the method provided in this embodiment.

[0084] In the simulation verification, the number of nodes in the alliance chain is increased from 100 to 700. The performance of the method provided in this embodiment is observed and verified by comparing the method provided in this embodiment with the practical Byzantine fault tolerance algorithm; in the comparison process, the throughput and delay of the formula algorithm are focused on as two performance indicators, and 20 repeated experiments are conducted to collect corresponding experimental data, each time 200 request messages are sent, and the average of 20 experimental results is taken as the final result.

[0085] Figure 4 is a schematic diagram comparing the throughput of the consensus method for alliance chain provided by the present invention with the throughput of the consensus method based on the practical Byzantine fault-tolerant protocol; Figure 4 As shown in the figure, the value on the horizontal axis represents the number of nodes in the alliance chain network, and the value on the vertical axis represents the throughput of the algorithm. Figure 4 It can be observed that the solid line is the throughput curve obtained by solving the problem of the high-performance consensus algorithm for alliance chain traceability scenarios proposed in this invention, and the dotted line is the throughput curve obtained by the practical Byzantine protocol fault-tolerant algorithm. Figure 4 It can be concluded from the experimental results that when the number of nodes is only 100, the throughput of the two algorithms is almost the same, and the difference in transaction volume is less than 100 per second. However, as the number of nodes increases and the network scale expands, the throughput of the practical Byzantine fault-tolerant algorithm decreases rapidly, and the rate of decrease of the method provided in this embodiment is relatively slow, which leads to an increasing difference in the throughput of the two algorithms. When the network scale is 700 nodes, the throughput obtained by the method provided in this embodiment is nearly 200 higher than that of the practical Byzantine fault-tolerant algorithm. These comparison results effectively prove that the method provided in this embodiment can significantly improve the throughput performance of the alliance chain network in the alliance chain traceability scenario.

[0086] Figure 5 Schematic diagram comparing the transaction delay time of the consensus method for alliance chain provided by the present invention and the transaction delay time of the consensus method based on the practical Byzantine fault tolerance protocol. Figure 5 As shown in the figure, the value on the horizontal axis represents the number of nodes in the alliance chain network, and the value on the vertical axis represents the transaction delay of the algorithm. Figure 5 It can be seen that the black color represents the transaction delay obtained by solving the problem of the high-performance consensus algorithm for alliance chain traceability scenarios proposed by the present invention, and the gray color represents the transaction delay obtained by the practical Byzantine agreement fault-tolerant algorithm. Figure 5It can be concluded from the experimental results that the scale of the alliance chain network has gradually expanded from 100 nodes to 700 nodes, and the transaction delay of the method provided in this embodiment is always about 40% lower than that of the practical Byzantine protocol fault tolerance algorithm. This not only shows that the method provided in this embodiment can significantly improve the throughput performance of the alliance chain network in the alliance chain traceability scenario, but also shows that the performance of the method provided in this embodiment has good stability in different scales.

[0087] In summary, the results of a series of experiments have proved that the high-performance consensus algorithm for alliance chain traceability scenarios proposed in this application has a throughput value that is at least 10.26% higher than the practical Byzantine fault-tolerant protocol in the current solution, and the transaction delay can be at least 42.96% lower.

[0088] Therefore, the method proposed in this application can effectively optimize the throughput and latency of alliance chain applications for traceability scenarios, and has good prospects for promotion. And the method is all run on the alliance chain traceability platform side, with the goal of effectively improving the efficiency, security and comprehensive performance of alliance chain applications, and providing a comprehensive performance efficient and reliable consensus cohesion method for the application of alliance chain in the traceability industry, with the advantages of clear steps, simple operation, high efficiency, safety and energy saving, strong robustness, etc., thereby effectively improving the comprehensive processing efficiency and performance of the alliance chain network, and effectively helping to build economical, efficient and practical alliance chain scenario applications.

[0089] The following is a description of the alliance chain-oriented consensus system provided by the present invention. The alliance chain-oriented consensus system described below and the alliance chain-oriented consensus method described above can refer to each other.

[0090] Figure 6 It is a schematic diagram of the structure of the consensus system for alliance chain provided by the present invention; Figure 6 As shown, the system includes: The evaluation unit 610 is used to obtain the current credit score value and the current credit score growth rate of each node in the alliance chain; The election unit 620 is used to elect nodes in the alliance chain according to the current credit score value and the current credit score growth rate, and a verifiable random function to obtain a current consensus node set and a candidate consensus node set; The conversion unit 630 is used to perform view conversion on the current view corresponding to the current consensus node set according to the verification result of the transaction data obtained by the any consensus node, the master-slave state of the consensus node sending the transaction data, and the candidate consensus node set, to obtain an updated current view when any consensus node in the current consensus node set receives the transaction data; The consensus unit 640 is used to update the current consensus node set according to the updated current view, and to respond to the transaction data based on the updated current consensus node set.

[0091] The system provided in this embodiment elects nodes in the alliance chain according to the current credit score value and the current credit score growth rate of each node in the alliance chain and a verifiable random function to obtain a current consensus node set and a candidate consensus node set. When any consensus node in the current consensus node set receives transaction data, the system performs view conversion on the current view corresponding to the current consensus node set according to the verification result of the transaction data obtained by any consensus node, the master-slave state of the consensus node that sends the transaction data, and the candidate consensus node set to obtain an updated current view. The system updates the current consensus node set according to the updated current view, so as to respond to the transaction data based on the updated current consensus node set. This can achieve high throughput, that is, it can process a large number of transactions and block confirmations, and has the characteristics of low latency, can quickly confirm transactions and generate new blocks, and can also save energy and computing resources, reduce operating costs, and improve the efficiency and sustainability of the entire system. This method has significant advantages in terms of throughput, latency, fault tolerance, and resource efficiency, ensures consensus efficiency and performance, and provides reliable technical support for traceability applications.

[0092] The system provided by the present invention is used to execute the above-mentioned method embodiments. Please refer to the above-mentioned embodiments for the specific processes and detailed contents, which will not be repeated here.

[0093] Figure 7 An example of a physical structure diagram of an electronic device is shown in FIG. Figure 7As shown, the electronic device may include: a processor (processor) 710 , a communication interface (Communications Interface) 720 , a memory (memory) 730 and a communication bus 740 , wherein the processor 710 , the communication interface 720 , and the memory 730 communicate with each other through the communication bus 740 . The processor 710 can call the logic instructions in the memory 730 to execute a consensus method for the alliance chain, which includes: obtaining the current credit score value and the current credit score growth rate of each node in the alliance chain; electing the nodes in the alliance chain according to the current credit score value and the current credit score growth rate, and a verifiable random function, to obtain a current consensus node set and a candidate consensus node set; when any consensus node in the current consensus node set receives transaction data, according to the verification result of the transaction data obtained by any consensus node, the master-slave status of the consensus node sending the transaction data, and the candidate consensus node set, performing a view conversion on the current view corresponding to the current consensus node set to obtain an updated current view; according to the updated current view, updating the current consensus node set, and responding to the transaction data based on the updated current consensus node set.

[0094] In addition, the logic instructions in the above-mentioned memory 730 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0095] On the other hand, the present invention also provides a computer program product, which includes a computer program, which can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the consensus method for the alliance chain provided by the above methods, which method includes: obtaining the current credit score value and the current credit score growth rate of each node in the alliance chain; electing the nodes in the alliance chain according to the current credit score value and the current credit score growth rate, and a verifiable random function, to obtain a current consensus node set and a candidate consensus node set; when any consensus node in the current consensus node set receives transaction data, according to the verification result of the transaction data obtained by any consensus node, the master-slave status of the consensus node sending the transaction data, and the candidate consensus node set, the current view corresponding to the current consensus node set is converted to obtain an updated current view; according to the updated current view, the current consensus node set is updated, and based on the updated current consensus node set, a response operation is performed on the transaction data.

[0096] On the other hand, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to execute the consensus method for the alliance chain provided by the above-mentioned methods, the method comprising: obtaining the current credit score value and the current credit score growth rate of each node in the alliance chain; electing the nodes in the alliance chain according to the current credit score value and the current credit score growth rate, and a verifiable random function, to obtain a current consensus node set and a candidate consensus node set; when any consensus node in the current consensus node set receives transaction data, performing a view conversion on the current view corresponding to the current consensus node set according to the verification result of the transaction data obtained by verification by any consensus node, the master-slave status of the consensus node sending the transaction data, and the candidate consensus node set, to obtain an updated current view; updating the current consensus node set according to the updated current view, and performing a response operation on the transaction data based on the updated current consensus node set.

[0097] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, i.e., they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Those of ordinary skill in the art may understand and implement it without creative effort.

[0098] Through the description of the above implementation modes, those skilled in the art can clearly understand that each implementation mode can be implemented by means of software plus a necessary general hardware platform, or of course by hardware. Based on such an understanding, the above technical solution can essentially or in other words be embodied in the form of a software product that contributes to the prior art. The computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods of each embodiment or some parts of the embodiment.

[0099] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A consensus method for alliance chain, characterized in that: include: Get the current credit score value and current credit score growth rate of each node in the alliance chain; According to the current credit score value and the current credit score growth rate, and a verifiable random function, the nodes in the alliance chain are elected to obtain a current consensus node set and a candidate consensus node set; When any consensus node in the current consensus node set receives the transaction data, according to the verification result of the transaction data obtained by the any consensus node, the master-slave status of the consensus node sending the transaction data, and the candidate consensus node set, a view conversion is performed on the current view corresponding to the current consensus node set to obtain an updated current view; According to the updated current view, the current consensus node set is updated, and based on the updated current consensus node set, a response operation is performed on the transaction data.

2. The consensus method for alliance chain according to claim 1 is characterized in that: The steps of obtaining the current credit score value of each node in the alliance chain include: Calculate the total credit score according to the credit score value of each node in each historical round to obtain the total value of the historical credit score of each node; Calculate the consensus incomplete rate according to the consensus participation record of each node in each historical round to obtain the historical consensus incomplete rate of each node; Calculate the message sending error rate according to the message sending records of each node in each historical round to obtain the historical message sending error rate of each node; Calculate the activity of each node according to the communication records of each node in each historical round to obtain the historical activity of each node; The current credit score value of each node is calculated by combining the historical credit score total value, the historical consensus incomplete rate, the historical message sending error rate and the historical activity.

3. The consensus method for alliance chain according to claim 1 is characterized in that: The steps of obtaining the current credit score growth rate of each node in the alliance chain include: The credit score growth rate is calculated based on the ratio between the current credit score value of each node and the credit score value of each node in each historical round to obtain the current credit score growth rate of each node.

4. The consensus method for alliance chain according to any one of claims 1 to 3, characterized in that: The nodes in the alliance chain are elected according to the current credit score value and the current credit score growth rate, and a verifiable random function to obtain a current consensus node set and a candidate consensus node set, including: According to the current credit score value and the current credit score growth rate, nodes in the alliance chain are elected to obtain a set of candidate nodes; Verifying the candidate nodes in the candidate node set according to the verifiable random function; According to the verification result, the candidate nodes in the candidate node set are elected to obtain an initial consensus node set; Sort the nodes according to the current credit score value and node identifier of each consensus node in the initial consensus node set; According to the sorting result, the initial consensus node set is divided into nodes to obtain the current consensus node set and the candidate consensus node set; Among them, the current credit score value of the consensus node in the current consensus node set is higher than the current credit score value of the consensus node in the candidate consensus node set.

5. The consensus method for alliance chain according to any one of claims 1 to 3, characterized in that: The method further comprises: performing view conversion on a current view corresponding to the current consensus node set according to the verification result of the transaction data obtained by verification of any consensus node, the master-slave status of the consensus node sending the transaction data, and the candidate consensus node set to obtain an updated current view, including: In the case that any consensus node in the current consensus node set receives the transaction data, if it is determined that the verification result of the transaction data is failed, and the master-slave status of the consensus node sending the transaction data is the master node, a new consensus node is selected from the candidate consensus node set, and a view conversion is performed on the current view to obtain the updated current view.

6. The consensus method for alliance chain according to claim 5 is characterized in that: The method further comprises: If it is determined that the verification result of the transaction data is passed, and the master-slave status of the consensus node sending the transaction data is a slave node, after waiting for the target reply time, the consensus node receiving the transaction data is controlled to forward the transaction data to the consensus master node in the current consensus node set; Determine whether the consensus master node has abnormal behavior or failure according to the verification result of the broadcast information; the broadcast information is generated by the consensus master node according to the transaction data; the verification result of the broadcast information is obtained by verification by each consensus slave node in the current consensus node set; When it is determined that the consensus master node has abnormal behavior or fails, a new consensus node is selected from the candidate consensus node set, and a view conversion is performed on the current view to obtain the updated current view.

7. The consensus method for alliance chain according to claim 6 is characterized in that: The method further comprises: When it is determined that the consensus master node has no abnormal behavior and no failure occurs, verify whether the consensus nodes in the current consensus node set have reached a consensus according to the consensus confirmation message received by each consensus node in the current consensus node set; wherein the consensus confirmation message is sent by each consensus slave node; When it is verified that the consensus nodes in the current consensus node set have not reached a consensus, a new consensus node is selected from the candidate consensus node set, and a view conversion is performed on the current view to obtain the updated current view.

8. A consensus system for alliance chain, characterized by: include: Evaluation unit, used to obtain the current credit score value and current credit score growth rate of each node in the alliance chain; An election unit, configured to elect nodes in the alliance chain according to the current credit score value and the current credit score growth rate, and a verifiable random function, to obtain a current consensus node set and a candidate consensus node set; a conversion unit, configured to, when any consensus node in the current consensus node set receives transaction data, perform view conversion on a current view corresponding to the current consensus node set according to a verification result of the transaction data obtained by verification by any consensus node, a master-slave state of the consensus node sending the transaction data, and the candidate consensus node set, so as to obtain an updated current view; The consensus unit is used to update the current consensus node set according to the updated current view, and to respond to the transaction data based on the updated current consensus node set.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the consensus method for the alliance chain as described in any one of claims 1 to 7 is implemented.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the consensus method for the alliance chain as described in any one of claims 1 to 7 is implemented.

Images