Block chain consensus method and related equipment

Abstract

The invention discloses a block chain consensus method and related equipment, and belongs to the technical field of computers. The method comprises the steps of determining a plurality of first candidate block chain nodes according to a predicted consensus operation state, predicted by a target time sequence large model, of each block chain node in a current consensus, the predicted consensus operation state including predicted available computing resources and predicted consensus results, and determining a plurality of second candidate block chain nodes according to the predicted consensus operation state; the prediction consensus result is used for indicating whether the block chain node participates in the consensus; determining a plurality of second candidate block chain nodes from the plurality of first candidate block chain nodes by using a mutual competition network iteration model, and dividing the plurality of second candidate block chain nodes into a plurality of mutual competition groups; and performing consensus according to the plurality of mutual competition groups.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of computer, in particular to a blockchain consensus method and related equipment. BACKGROUND

[0002] Blockchain technology is a kind of distributed database architecture that connects data blocks in chronological order and uses cryptography to ensure that they are tamper-proof and unforgeable. It can achieve full transparency, tamper-proofing and traceability of data information without the endorsement of third-party institutions, thereby effectively solving the trust problem. The blockchain consensus mechanism enables multiple nodes in the blockchain system to agree on the validity of data, which is the key to ensuring the safe and reliable operation of the blockchain system. However, due to the network distance and computing power difference between blockchain nodes, traditional methods require all nodes in the system to participate in consensus when generating blocks, which leads to long communication and data synchronization time between blockchain nodes, affecting the consensus efficiency of the blockchain system and further affecting the transaction efficiency. SUMMARY

[0003] Embodiments of the present application provide a blockchain consensus method and related equipment, which can improve the efficiency of blockchain consensus.

[0004] To solve the above technical problems, the present application is implemented as follows: In a first aspect, a blockchain consensus method is provided, the method comprising: determining a plurality of first candidate blockchain nodes according to a predicted consensus running state of each blockchain node in the current consensus corresponding to a target time sequence large model prediction, wherein the predicted consensus running state comprises predicted available computing resources and a predicted consensus result, and the predicted consensus result is used to indicate whether the blockchain node participates in the current consensus; determining a plurality of second candidate blockchain nodes from the plurality of first candidate blockchain nodes using a mutual competition network iteration model, and dividing the plurality of second candidate blockchain nodes into a plurality of mutual competition groups, wherein the mutual competition network iteration model is used to identify abnormal blockchain nodes from the plurality of first candidate blockchain nodes by calculating the similarity between the predicted consensus running state of each first candidate blockchain node and the benchmark consensus running state of a corresponding blockchain consensus benchmark node, and dividing the second candidate blockchain nodes that are not abnormal into the mutual competition group associated with the corresponding blockchain consensus benchmark node; and performing consensus according to a plurality of mutual competition groups.

[0005] Secondly, a blockchain consensus device is provided, comprising: a first determining module, configured to determine multiple first candidate blockchain nodes based on the predicted consensus operating state of each blockchain node in the current consensus according to the target time-series large model, wherein the predicted consensus operating state includes predicted available computing resources and predicted consensus results, and the predicted consensus results are used to indicate whether the blockchain node participates in the current consensus; a second determining module, configured to determine multiple second candidate blockchain nodes from the multiple first candidate blockchain nodes using a mutual competition network iterative model, and to divide the multiple second candidate blockchain nodes into multiple mutual competition groups, wherein the mutual competition network iterative model is used to identify abnormal blockchain nodes from the multiple first candidate blockchain nodes by calculating the similarity between the predicted consensus operating state of each first candidate blockchain node and the benchmark consensus operating state of the corresponding blockchain consensus competition benchmark node, and to divide the non-abnormal second candidate blockchain nodes into the mutual competition group associated with the corresponding blockchain consensus competition benchmark node; and a consensus module, configured to perform consensus based on the multiple mutual competition groups.

[0006] Thirdly, an electronic device is provided, including a processor and a memory, wherein the memory stores a program or instructions executable on the processor, the program or instructions, when executed by the processor, perform the steps of the method described in the first aspect.

[0007] Fourthly, a readable storage medium is provided, on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0008] Fifthly, a computer program product is provided, the computer program product comprising a computer program stored on a non-transitory computer-readable storage medium, the computer program comprising program instructions that, when executed by a computer, cause the computer to perform the steps of the method described in the first aspect.

[0009] In this embodiment, multiple first candidate blockchain nodes are determined by predicting the consensus operation status of each blockchain node in the current consensus based on the target time-series large model. The predicted consensus operation status includes predicted available computing resources and predicted consensus results, which indicate whether a blockchain node should participate in the current consensus. Selecting nodes with better predicted consensus operation status performance as first candidate blockchain nodes improves consensus efficiency and accuracy. Using a competitive network iterative model, multiple second candidate blockchain nodes are determined from the multiple first candidate blockchain nodes and assigned to multiple competitive groups. The competitive network iterative model is used to identify abnormal blockchain nodes from the multiple first candidate blockchain nodes by calculating the similarity between the predicted consensus operation status of each first candidate blockchain node and the benchmark consensus operation status of the corresponding blockchain consensus competition benchmark node. Non-abnormal second candidate blockchain nodes are assigned to the competitive group associated with the corresponding blockchain consensus competition benchmark node. Consensus is then conducted based on the multiple competitive groups. This eliminates nodes with abnormal predicted consensus operation status, significantly reducing the number of participating nodes, significantly improving inter-node communication efficiency and consensus efficiency, and ensuring consensus accuracy while improving consensus efficiency.

[0010] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0012] Figure 1 This application illustrates a schematic flowchart of a blockchain consensus method provided in an exemplary embodiment. Figure 2 This application illustrates a schematic flowchart of a blockchain consensus method provided in an exemplary embodiment. Figure 3 This application illustrates a schematic flowchart of a blockchain consensus method provided in an exemplary embodiment. Figure 4 This invention provides an exemplary embodiment of a competitive network iterative model, which is illustrated in the following schematic diagram. Figure 5 This illustration shows another architectural diagram of the competitive network iterative model provided in an exemplary embodiment of this application; Figure 6 This application illustrates a schematic flowchart of a blockchain consensus method provided in an exemplary embodiment. Figure 7This application illustrates a schematic flowchart of a blockchain consensus method provided in an exemplary embodiment. Figure 8 This application shows a schematic diagram of a blockchain consensus device provided in an exemplary embodiment. Figure 9 A schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this application is shown. Detailed Implementation

[0013] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0014] To more clearly explain the technical solution of this application, the relevant technologies involved in this application are described below.

[0015] Traditional blockchain consensus mechanisms include , Public blockchain consensus algorithms based on, etc. , The consensus algorithm for consortium blockchains is based on the principle of equality. The following sections explain the consensus algorithms for public blockchains and consortium blockchains respectively: (I) Public Chain Consensus Algorithm by Taking consensus as an example, it uses computing power to compete for the right to record transactions. The specific execution process is as follows: (1) When a user initiates a new transaction, the transaction will be broadcast to the entire network, and all nodes participating in the network will receive the information of the transaction.

[0016] (2) After receiving the transaction information, each node in the network will begin to prepare to package these transactions into a new block, which will become the next link on the blockchain.

[0017] (3) All nodes then begin to calculate an extremely complex problem, namely, to find a value that meets specific conditions. If a node successfully calculates the answer first, it broadcasts the answer along with the newly created block to other nodes in the blockchain network.

[0018] (4) After receiving the new block and its proof of work, other nodes verify the validity and correctness of this information.

[0019] (5) Once a majority of nodes confirm the validity of the block and its proof of work, the block will be officially added to the blockchain and become an immutable part of it.

[0020] (ii) Consortium Blockchain Consensus Algorithm by Taking consensus mechanisms as an example, Through a multi-stage consensus process, it provides [security / security] while ensuring [security / security]. Fault tolerance. The specific execution process is as follows: (1) Request phase: The client sends a request to the master node of the blockchain system. After receiving the request, the master node encapsulates the request, along with the sequence number, the current view number, and its own signature, into a pre-prepared message.

[0021] (2) Pre-preparation phase: The master node broadcasts the pre-preparation message to all replica nodes. After receiving the pre-preparation message, the replica nodes verify the validity of the message (e.g., check if the sequence number is correct, if the signature is valid, etc.). After successful verification, the replica nodes record the message and send a preparation message to all other nodes.

[0022] (3) Preparation phase: Replica nodes wait to receive preparation messages from a majority of nodes. When a replica node receives more than 2 / 3 of the preparation messages, it means that the request has been accepted by a majority of nodes, and the node enters the commit phase.

[0023] (4) Commit phase: A node sends a commit message to all other nodes. When a node receives more than 2 / 3 of the commit messages, it will perform the corresponding operation and update its local state.

[0024] (5) Response Phase: After completing the operation, the replica node sends a response to the client, informing them of the operation result. All replica nodes should send the same result to the client to ensure eventual consistency.

[0025] However, the aforementioned public blockchain consensus algorithms and consortium blockchain consensus algorithms require all nodes within the system to participate in consensus synchronously when generating blocks, resulting in long communication and data synchronization times between blockchain nodes and low consensus efficiency. Therefore, this application provides a blockchain consensus method that can improve consensus efficiency.

[0026] like Figure 1 The diagram illustrates a flowchart of a blockchain consensus method provided in an exemplary embodiment of this application. This method can be executed by an electronic device, which may include a terminal device and a network-side device. In other words, the method can be executed by software or hardware installed on the electronic device, and the method may include the following steps: S110: Based on the predicted consensus operation status of each blockchain node in this consensus according to the target time series large model, determine multiple first candidate blockchain nodes.

[0027] The predicted consensus operation status includes predicted available computing resources and predicted consensus results. The predicted consensus results indicate whether the blockchain node participates in this consensus. Predicted available computing resources can measure the consensus efficiency of the node, and predicted consensus results can measure the accuracy of the node's consensus. The predicted available computing resources may include predicted available CPU resources, predicted available network resources, and predicted available memory resources.

[0028] In this step, the predicted available computing resources and predicted consensus results of all blockchain nodes are evaluated using the target time series large model. The first number of blockchain nodes with the highest available computing resources and predicted consensus results can be selected as the first candidate blockchain nodes.

[0029] S120: Using a competitive network iterative model, determine multiple second candidate blockchain nodes from the multiple first candidate blockchain nodes, and divide the multiple second candidate blockchain nodes into multiple competitive groups.

[0030] The mutual competition network iterative model is used to identify abnormal blockchain nodes from the plurality of first candidate blockchain nodes by calculating the similarity between the predicted consensus operating state of each first candidate blockchain node and the benchmark consensus operating state of the corresponding blockchain consensus competition benchmark node, and to assign non-abnormal second candidate blockchain nodes to the mutual competition group associated with the corresponding blockchain consensus competition benchmark node.

[0031] Understandably, the blockchain consensus competition benchmark node is the base point used to evaluate the predicted consensus operating state of the first candidate blockchain node. In this step, based on the predicted consensus operating state corresponding to each first candidate blockchain node, a mutual competition network iterative model is constructed, and a blockchain consensus competition benchmark node is set to eliminate the first candidate blockchain node with abnormal operating state, and to divide the non-abnormal second candidate blockchain node into a mutual competition group with high similarity.

[0032] S130: Consensus is reached based on multiple competing groups.

[0033] The consensus method can include intra-group consensus and inter-group consensus. Intra-group consensus occurs within each competing group. Specifically, within each competing group, when a node receives more than a third number of preparation messages, the consensus for that group is considered complete. Consensus is considered complete when the number of competing groups with completed consensus exceeds a fourth number. For example, the third number can be two-thirds of the total number of nodes in the competing group, and the fourth number can be two-thirds of the total number of competing groups. Inter-group consensus can employ cross-consensus verification.

[0034] In this embodiment, multiple first candidate blockchain nodes are determined by predicting the consensus operation status of each blockchain node in the current consensus based on the target time-series large model. The predicted consensus operation status includes predicted available computing resources and predicted consensus results, which indicate whether a blockchain node should participate in the current consensus. Selecting nodes with better predicted consensus operation status performance as first candidate blockchain nodes improves consensus efficiency and accuracy. Using a competitive network iterative model, multiple second candidate blockchain nodes are determined from the multiple first candidate blockchain nodes and assigned to multiple competitive groups. The competitive network iterative model is used to identify abnormal blockchain nodes from the multiple first candidate blockchain nodes by calculating the similarity between the predicted consensus operation status of each first candidate blockchain node and the benchmark consensus operation status of the corresponding blockchain consensus competition benchmark node. Non-abnormal second candidate blockchain nodes are assigned to the competitive group associated with the corresponding blockchain consensus competition benchmark node. Consensus is then conducted based on the multiple competitive groups. This eliminates nodes with abnormal predicted consensus operation status, significantly reducing the number of participating nodes, significantly improving inter-node communication efficiency and consensus efficiency, and ensuring consensus accuracy while improving consensus efficiency.

[0035] In some embodiments, such as Figure 2 As shown, before determining multiple first candidate blockchain nodes based on the consensus operation status of each blockchain node predicted by the target time-series large model in this consensus, the method further includes the following steps: S102: Obtain the basic time series model.

[0036] The model parameters of the basic time series large model include basic parameters.

[0037] S104: Based on the aforementioned basic time series model, construct the target time series model.

[0038] The model parameters of the target time series model include basic parameters and fine-tuning parameters for blockchain consensus scenarios.

[0039] S106: Based on the historical consensus operation status of each blockchain node in at least one historical consensus, fine-tune the blockchain consensus scenario fine-tuning parameters of the target time-series large model.

[0040] The historical consensus operation status includes historical available computing resources and historical consensus results. The historical available computing resources include historical available CPU resources, historical available network resources, and historical available memory resources. The historical consensus results are used to indicate whether the blockchain node participates in this consensus.

[0041] It is understandable that while the basic time-series model possesses a certain generalization ability, its time-series prediction capability in blockchain node consensus scenarios can be further optimized. In this embodiment, under the scenario of predicting the consensus operation state of blockchain nodes, the parameters of the original basic time-series model are frozen, and fine-tuning parameters for the blockchain consensus scenario are added. The difference parameter matrix is ​​calculated using backpropagation, and the blockchain consensus scenario time-series model, i.e., the target time-series model, is fine-tuned. For example, as shown in Table 1, the historical consensus operation state corresponding to each blockchain node in at least one historical consensus is represented.

[0042]

[0043] Taking blockchain node 1 consensus 1 (4, 100, 2, 1) as an example, "4" indicates that the historical available CPU resources of node 1 are 4 cores; "100" indicates that the historical available network resources of the node are 100M; "2" indicates that the historical available memory resources of the node are 2G; "1" indicates the historical consensus result, which includes consensus correct and consensus incorrect. Consensus correct means that the node participated in the current consensus, and consensus failure means that the node did not participate in the current consensus.

[0044] During the fine-tuning process, while keeping the basic parameters of the target time-series model unchanged, new fine-tuning parameters for the blockchain consensus scenario are added. , making ,in, To incorporate the fine-tuned parameters based on the blockchain node's operational status, These are the parameters of the original large-scale model. Based on the above principles, optimizing the parameters of the target time-series large-scale model in the scenario of predicting the consensus operation state of blockchain nodes can include the following fine-tuning process: (1) Assume the parameters of the basic time series large model are For one Matrix, preserving the original large model parameters Without changing the core parameters, fine-tune the parameters for blockchain consensus scenarios. , making .

[0045] (2) To further improve fine-tuning efficiency and save computing resources, Decompose into a low-rank matrix. The decomposition means that two smaller ones are needed. To represent larger matrices .use The number of rows and same, The number of columns and Similarly, the above matrix decomposition is denoted as a fine-tuning parameter string. .

[0046] (3) Based on the historical consensus operation state of each blockchain node in at least one historical consensus, and taking the historical consensus operation state of a certain blockchain node in any given time as the dependent variable, the previous... The historical consensus operation state of this blockchain node is used as the independent variable for training. First, the first fine-tuning is performed, calculating... , Due to the original All parameters are known; by using backpropagation iteration, the following can be obtained. , Matrix, at this time parameters Secondly, through the above method, a second fine-tuning iteration is performed to make... Finally, the above method is used to iterate continuously until the error is small enough to calculate the new parameters. .

[0047] In this embodiment, fine-tuning the target time series model in a blockchain consensus scenario can improve the accuracy of model prediction in vertical blockchain consensus scenarios while maintaining the generalization ability of the original basic time series model.

[0048] In some embodiments, determining multiple first candidate blockchain nodes based on the predicted consensus running state of each blockchain node in the current consensus according to the target time-series large model includes: for each blockchain node, inputting the historical consensus running state of the blockchain node corresponding to the historical h consensuses into the target time-series large model to obtain the predicted consensus running state output by the target time-series large model in the current consensus, wherein the predicted available computing resources include predicted available CPU resources, predicted available network resources, and predicted available memory resources, and h is an integer greater than 0; sorting the predicted consensus running states from high to low as indicators, and determining the first first number of blockchain nodes as first candidate blockchain nodes.

[0049] In some embodiments, the step of inputting the historical consensus operation status of the blockchain node corresponding to h previous consensuses into the target time-series large model to obtain the predicted consensus operation status output by the target time-series large model for the current consensus may include: evaluating the consensus efficiency and consensus accuracy of the blockchain node using the target time-series large model based on the historical consensus operation status of the blockchain node corresponding to h previous consensuses; and determining the predicted consensus operation status of each blockchain node for the current consensus based on the consensus efficiency and consensus accuracy corresponding to each blockchain node. Consensus efficiency is determined based on the computing power, memory, network, and other resources of the consensus node; consensus accuracy is based on the security of the consensus node, whether it has been tampered with, and can be evaluated by referring to the node's historical participation in consensus accuracy. It is understood that by using the target time-series large model to evaluate the computing power and security performance of all blockchain nodes, obtaining predicted available computing resources and predicted consensus results, and selecting the first number of blockchain nodes with the highest predicted available computing resources and predicted consensus results as the first candidate blockchain nodes. For example, the first number can be one-third of the total number of blockchain nodes. It should be noted that this application embodiment does not specifically limit the first number and can set it according to actual conditions.

[0050] In this embodiment, by using a target time series model, a first number of nodes with excellent consensus efficiency and accuracy are selected to participate in the consensus, thus simultaneously ensuring both consensus efficiency and accuracy.

[0051] In some embodiments, such as Figure 3 As shown, before determining multiple second candidate blockchain nodes from the multiple first candidate blockchain nodes using the mutual competition network iterative model, and dividing the multiple second candidate blockchain nodes into multiple mutual competition groups, the method further includes the following steps: S212: Construct the iterative model of the mutually competing network.

[0052] The mutual competition network iterative model includes an input layer, a competition layer, and a blockchain mutual competition layer. The input layer includes the plurality of first candidate blockchain nodes, the competition layer includes the plurality of blockchain consensus competition benchmark nodes, and the blockchain mutual competition layer includes the plurality of mutual competition groups. Each first candidate blockchain node corresponds to at least one of the blockchain consensus competition benchmark nodes, and each blockchain consensus competition benchmark node is associated with one of the mutual competition groups.

[0053] In the embodiments of this application, each first candidate blockchain node may correspond to each blockchain consensus competition benchmark node; or, multiple first candidate blockchain nodes may be divided into multiple groups, with each group corresponding to one blockchain consensus competition benchmark node, i.e., each first candidate blockchain node corresponds to one blockchain consensus competition benchmark node; or, each first candidate blockchain node may be divided into multiple groups, so that each first candidate blockchain node corresponds to at least one blockchain consensus competition benchmark node. For example, as... Figure 4 As shown, there are z first candidate blockchain nodes, where each first candidate blockchain node corresponds to each blockchain consensus competition benchmark node. For example, as... Figure 5 As shown, there are z first candidate blockchain nodes. These z first candidate blockchain nodes are divided into K competing groups, that is, each first candidate blockchain node corresponds to a blockchain consensus competition benchmark node.

[0054] In some embodiments, The range of values ​​can be .

[0055] S214: Initialize the benchmark consensus running state corresponding to each of the blockchain consensus competition benchmark nodes.

[0056] For example, the first The benchmark consensus operation status corresponding to each blockchain consensus competition benchmark node is as follows: ,in, Indicates the benchmark node for blockchain consensus competition Initial available CPU resources Indicates the benchmark node for blockchain consensus competition Initial available memory resources, Indicates the benchmark node for blockchain consensus competition Initial available network resources, Indicates the benchmark node for blockchain consensus competition The initial consensus result.

[0057] S216: Based on the predicted consensus running state of each of the first candidate blockchain nodes in this consensus, iteratively update the benchmark consensus running state corresponding to each blockchain consensus competition benchmark node until the stopping condition is met.

[0058] In some embodiments, the step of iteratively updating the benchmark consensus running state corresponding to each blockchain consensus competition benchmark node until the stopping condition is met, based on the predicted consensus running state of each first candidate blockchain node in this consensus, includes: calculating the similarity between the predicted consensus running state of each first candidate blockchain node and the benchmark consensus running state of each corresponding blockchain consensus competition benchmark node; for each first candidate blockchain node, selecting the blockchain consensus competition benchmark node with the highest similarity as the winning node, and adjusting the benchmark consensus running state corresponding to the winning node based on the predicted consensus running state of the first candidate blockchain node.

[0059] For example, setting the first Predicted operating status of each node for ,in Indicates the predicted available CPU resources. Indicates the predicted available memory resources. This indicates the predicted available network resources. This indicates the predicted consensus outcome. The operating status of each node can be represented by a matrix:

[0060] Blockchain consensus competition benchmark node is One, initialize the competition layer The normalized matrix of the blockchain consensus competition benchmark nodes is as follows:

[0061] in, For the competitive layer The benchmark consensus operation status corresponding to the benchmark node in the blockchain consensus competition. For the first The predicted consensus operation status of each node. Calculate the first candidate blockchain node. and the The similarity of the benchmark nodes competing for consensus in the blockchain, where the similarity can be cosine similarity, Euclidean distance, etc.

[0062] Specifically, the closer the cosine similarity is to 1, the more similar the first candidate blockchain node is to the benchmark node in the blockchain consensus competition. The similarity between the predicted consensus operating state of the first candidate blockchain node and the benchmark consensus operating state of each corresponding benchmark node is calculated to obtain the most similar winning node in the competition. Due to the winning node in the competition The node most similar to the first candidate blockchain node needs to be dynamically adjusted to win the competition. , making The adjustment should be made towards the predicted consensus running state of the first candidate blockchain node, and the adjustment rule can be:

[0063] in, To compete for the winning node Updated baseline consensus status. To compete for the winning node The baseline consensus status before the update Indicates the first The predicted consensus operation status of the first candidate blockchain nodes For weights.

[0064] Through the above steps, the predicted consensus operating state of each first candidate blockchain node is iterated sequentially, updating the baseline consensus operating state of the blockchain consensus competition benchmark node in the competition layer. This causes the baseline consensus operating state of the blockchain consensus competition benchmark node to move towards the center of the competition group. To optimize the blockchain consensus competition benchmark node in the competition layer, the iteration continues until the iterative change of the blockchain consensus competition benchmark node in the competition layer approaches 0. At this point, the iteration stops, and the baseline consensus operating state of the blockchain consensus competition benchmark node corresponding to each competition group is obtained.

[0065] In some embodiments, the step of using a competitive network iterative model to determine multiple second candidate blockchain nodes from the multiple first candidate blockchain nodes and dividing the multiple second candidate blockchain nodes into multiple competitive groups includes: for each blockchain consensus competition benchmark node, calculating the similarity between the predicted consensus operating state of each corresponding first candidate blockchain node and the benchmark consensus operating state of the blockchain consensus competition benchmark node, and designating the first candidate blockchain nodes with similarity greater than a preset threshold as second candidate blockchain nodes and dividing them into the competitive group corresponding to the blockchain consensus competition benchmark node.

[0066] Understandably, this method minimizes the differences between nodes within the same competitive group and maximizes the differences between groups. When the similarity between a first-candidate node and its corresponding blockchain consensus benchmark node is less than the target threshold, it indicates that the predicted consensus operation state of the first-candidate node differs significantly from the operation states of all other nodes. It is identified as an abnormal node and does not participate in consensus, thus improving consensus efficiency and accuracy.

[0067] In some embodiments, such asFigure 6 As shown, reaching consensus based on multiple competing groups may include the following steps: S132: Determine the consensus initiator corresponding to each of the aforementioned competing groups.

[0068] The consensus initiator is the second candidate blockchain node with the highest similarity.

[0069] S134: If the consensus initiators of all the competing groups initiate this consensus at the same time, in response to the number of participating nodes of this consensus corresponding to any of the competing groups being greater than the second number, consensus is determined to be completed.

[0070] The plurality of second candidate blockchain nodes includes the participating nodes, and the second number is one-half of the total number of the second candidate blockchain nodes.

[0071] Understandably, the node with the highest similarity to the corresponding blockchain consensus benchmark node in each competitive group is designated as the consensus initiator for each competitive group. Consensus initiators in each competitive group initiate consensus simultaneously. When a consensus initiator in a competitive group initiates consensus, the consensus is completed when the consensus pass rate of nodes in other competitive groups exceeds the second highest number.

[0072] Based on the above embodiments, an exemplary embodiment of this application also provides another schematic diagram of a blockchain consensus method, such as... Figure 7 As shown, the method may include the following steps: S710: Fine-tunes the large-scale blockchain consensus scenario model, obtains the predicted consensus operation status by predicting the consensus efficiency and accuracy of nodes, and selects the first candidate node.

[0073] It is understandable that blockchain node performance includes consensus efficiency and consensus accuracy. Consensus efficiency mainly depends on the node's computing power, memory, and network, while consensus accuracy relies primarily on the node's security, specifically whether it has been tampered with. The node's security performance can be assessed by referring to its historical consensus accuracy. As the number of consensus cycles increases, the node's computing power, memory, network, and consensus accuracy exhibit trend changes. Therefore, based on the node's historical operating status, a target time-series model can be used to predict the next consensus node's operating status. The basic target time-series model covers a wide range of fields, including finance and economics, and has the advantage of strong generalization ability. It can be implemented based on... Time to The node state at time t, prediction The basic target time-series model, while possessing some generalization ability, still has room for improvement in its time-series prediction capabilities within blockchain node consensus scenarios. Therefore, in the blockchain node operational status prediction scenario, fine-tuning is performed based on historical operational samples of blockchain nodes to improve model accuracy in blockchain node consensus scenarios. Once the fine-tuned model is generated, each blockchain node utilizes it, based on historical data... Secondary use Based on network, memory, and participation in each consensus iteration, the available nodes for the next consensus iteration can be determined using a fine-tuned target time-series model. The method considers network, memory, and consensus results, selecting the top half of nodes with high consensus efficiency and accuracy to participate in the consensus process. Since the number of participating nodes is reduced and the consensus accuracy is high, this method can improve the efficiency of blockchain consensus.

[0074] S720: Construct a competitive network iterative model to eliminate abnormal blockchain nodes.

[0075] Understandably, by fine-tuning the target time-series model and selecting a majority of nodes with excellent consensus efficiency and accuracy to participate in consensus, both efficiency and accuracy can be balanced. Based on the first candidate blockchain nodes selected from S710, a competitive network iterative model is constructed among the nodes to calculate the blockchain consensus competition benchmark node. The benchmark node is then used to further eliminate nodes with available computing power and abnormal consensus results, thereby improving consensus efficiency and accuracy.

[0076] S730: Blockchain competition groups cross-validate to achieve consensus.

[0077] Understandably, based on the selection of nodes in the competitive groups by S720, the node with the highest cosine similarity to the blockchain consensus benchmark node in each competitive group is selected as the consensus initiator of each competitive group. The consensus initiating nodes in each competitive group initiate consensus simultaneously. When the consensus initiator of a certain competitive group initiates consensus, the consensus is completed when the consensus pass rate of the nodes in other competitive groups exceeds half first.

[0078] In this embodiment, firstly, the basic target time-series model for the blockchain consensus scenario is fine-tuned. This model is used to evaluate the computing power and security performance of all blockchain nodes. Computing power measures the consensus efficiency of a node, while security performance measures the accuracy of the consensus. Nodes with higher consensus efficiency and accuracy are selected as the first-stage node filter. Secondly, based on the predicted consensus efficiency and accuracy, all nodes construct a mutually competitive network iterative model to calculate the benchmark node for blockchain consensus competition. Nodes are then assigned to mutually competitive groups with high cosine similarity, and nodes with abnormal operating states are eliminated. Finally, cross-consensus verification is performed between the mutually competitive groups. When a node's consensus verification pass rate exceeds half, consensus is achieved. Through this method, utilizing the target time-series model and the mutually competitive network iterative model, the number of nodes participating in consensus is significantly reduced, while the communication efficiency between nodes and the consensus efficiency are significantly improved.

[0079] Figure 8 This application provides a schematic diagram of the structure of a blockchain consensus device according to an embodiment of the present application. Figure 8 As shown, the blockchain consensus device 800 may include: a first determining module 810, a second determining module 820, and a consensus module 830.

[0080] In this embodiment, the first determining module 810 is used to determine multiple first candidate blockchain nodes based on the predicted consensus running state of each blockchain node in the current consensus according to the target time series large model. The predicted consensus running state includes predicted available computing resources and predicted consensus results, and the predicted consensus results are used to indicate whether the blockchain node participates in the current consensus. The second determining module 820 is used to determine multiple second candidate blockchain nodes from the multiple first candidate blockchain nodes using a mutual competition network iterative model, and to divide the multiple second candidate blockchain nodes into multiple mutual competition groups. The mutual competition network iterative model is used to identify abnormal blockchain nodes from the multiple first candidate blockchain nodes by calculating the similarity between the predicted consensus running state of each first candidate blockchain node and the benchmark consensus running state of the corresponding blockchain consensus competition benchmark node, and to divide the non-abnormal second candidate blockchain nodes into the mutual competition group associated with the corresponding blockchain consensus competition benchmark node. The consensus module 830 is used to perform consensus based on the multiple mutual competition groups.

[0081] In some embodiments, the blockchain consensus device 800 may further include a training module, configured to: acquire a basic time-series large model, wherein the model parameters of the basic time-series large model include basic parameters; construct a target time-series large model based on the basic time-series large model, wherein the model parameters of the target time-series large model include the basic parameters and blockchain consensus scenario fine-tuning parameters; and fine-tune the blockchain consensus scenario fine-tuning parameters of the target time-series large model based on the historical consensus running state corresponding to each blockchain node in at least one historical consensus, wherein the historical consensus running state includes historical available computing resources and historical consensus results, the historical available computing resources include historical available CPU resources, historical available network resources, and historical available memory resources, and the historical consensus results are used to indicate whether the blockchain node participates in this consensus.

[0082] In some embodiments, the first determining module 810 is specifically configured to: for each blockchain node, input the historical consensus running state of the blockchain node corresponding to the historical h consensuses into the target time series large model to obtain the predicted consensus running state output by the target time series large model corresponding to the current consensus, wherein the predicted available computing resources include predicted available CPU resources, predicted available network resources, and predicted available memory resources, and h is an integer greater than 0; sort the predicted consensus running states as indicators from high to low, and determine the first number of blockchain nodes as the first candidate blockchain nodes.

[0083] In some embodiments, the blockchain consensus device 800 may further include a construction module for: constructing the inter-competitive network iterative model, wherein the inter-competitive network iterative model includes an input layer, a competition layer, and a blockchain inter-competitive layer; the input layer includes the plurality of first candidate blockchain nodes; the competition layer includes a plurality of blockchain consensus competition benchmark nodes; the blockchain inter-competitive layer includes a plurality of inter-competitive groups; each first candidate blockchain node corresponds to at least one blockchain consensus competition benchmark node; and each blockchain consensus competition benchmark node is associated with one of the inter-competitive groups; initializes the benchmark consensus running state corresponding to each blockchain consensus competition benchmark node; and iteratively updates the benchmark consensus running state corresponding to each blockchain consensus competition benchmark node until a stopping condition is met, based on the predicted consensus running state of each first candidate blockchain node in this consensus.

[0084] In some embodiments, the construction module is further configured to: calculate the similarity between the predicted consensus running state of each first candidate blockchain node and the benchmark consensus running state of the corresponding blockchain consensus competition benchmark node; for each blockchain consensus competition benchmark node, select the first candidate blockchain node with the highest similarity as the winning node; and for each blockchain consensus competition benchmark node, adjust the benchmark consensus running state corresponding to the winning node based on the predicted consensus running state of the winning node.

[0085] In some embodiments, the second determining module 820 is specifically used to: for each blockchain consensus competition benchmark node, calculate the similarity between the predicted consensus running state of each corresponding first candidate blockchain node and the benchmark consensus running state of the blockchain consensus competition benchmark node, and assign the first candidate blockchain node with the similarity greater than a preset threshold as the second candidate blockchain node and classify it into the mutual competition group corresponding to the blockchain consensus competition benchmark node.

[0086] In some embodiments, the consensus module 830 is specifically configured to: determine the consensus initiator corresponding to each of the competing groups, wherein the consensus initiator is the second candidate blockchain node with the highest similarity; and, in the case that the consensus initiators corresponding to all the competing groups simultaneously initiate this consensus, determine that consensus is completed in response to the number of participating nodes in this consensus corresponding to any of the competing groups being greater than a second number, wherein the plurality of second candidate blockchain nodes includes the participating nodes, and the second number is half of the total number of the second candidate blockchain nodes.

[0087] The blockchain consensus device provided in this application embodiment can achieve... Figures 1-7 The various processes implemented in the method embodiments shown will not be described again here to avoid repetition.

[0088] The blockchain consensus device in this application embodiment can be a device, or it can be a component, integrated circuit, or chip in an electronic device. This application embodiment does not impose specific limitations.

[0089] One blockchain consensus device in this application embodiment can be a device with an operating system. The operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system.

[0090] like Figure 9As shown, this application embodiment also provides an electronic device 900, including a processor 910 and a memory 920. The memory 920 stores a program or instructions that can run on the processor 910. When the program or instructions are executed by the processor 910, they implement the above-mentioned... Figures 1 to 7 The various processes in the illustrated embodiments can achieve the same technical effect, and will not be described again here to avoid repetition.

[0091] This application embodiment also provides a readable storage medium storing a program or instructions, which, when executed by a processor, implement the above-described functionality. Figures 1 to 7 The various processes in the illustrated embodiments can achieve the same technical effect, and will not be described again here to avoid repetition.

[0092] The processor mentioned above is the processor in the terminal described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk. In some examples, the readable storage medium may be a non-transient readable storage medium.

[0093] This application embodiment also provides a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the above. Figures 1 to 7 The various processes in the illustrated embodiments can achieve the same technical effect, and will not be described again here to avoid repetition.

[0094] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0095] This application embodiment also provides a computer program / program product, the computer program product including a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the above-described actions. Figures 1 to 7 The various processes in the illustrated embodiments can achieve the same technical effect, and will not be described again here to avoid repetition.

[0096] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0097] From the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of computer software products plus necessary general-purpose hardware platforms, and of course, they can also be implemented by hardware. The computer software product is stored in a storage medium (such as ROM, RAM, magnetic disk, optical disk, etc.) and includes several instructions to cause the terminal or network-side device to execute the methods described in the various embodiments of this application.

[0098] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other implementations under the guidance of this application without departing from the spirit and scope of the claims. All of these implementations are within the protection scope of this application.

Claims

1. A blockchain consensus method, characterized in that, The method comprises: determining a plurality of first candidate blockchain nodes according to a predicted consensus running state of each blockchain node corresponding to the current consensus predicted by a target timing large model, wherein the predicted consensus running state comprises predicted available computing resources and a predicted consensus result, and the predicted consensus result is used to indicate whether the blockchain node participates in the current consensus; determining a plurality of second candidate blockchain nodes from the plurality of first candidate blockchain nodes by using a mutual competition network iteration model, and dividing the plurality of second candidate blockchain nodes into a plurality of mutual competition groups, wherein the mutual competition network iteration model is used to identify an abnormal blockchain node from the plurality of first candidate blockchain nodes by calculating the similarity between the predicted consensus running state of each first candidate blockchain node and the benchmark consensus running state of a corresponding blockchain consensus benchmark node, and dividing the second candidate blockchain nodes that are not abnormal into the mutual competition group associated with the corresponding blockchain consensus benchmark node; performing consensus according to the plurality of mutual competition groups.

2. The method of claim 1, wherein, Before the determining of the plurality of first candidate blockchain nodes according to the consensus running state of each blockchain node corresponding to the current consensus predicted by the target timing large model, the method further comprises: obtaining a basic timing large model, wherein the model parameters of the basic timing large model comprise basic parameters; constructing the target timing large model based on the basic timing large model, wherein the model parameters of the target timing large model comprise the basic parameters and blockchain consensus scene fine-tuning parameters; fine-tuning the blockchain consensus scene fine-tuning parameters of the target timing large model based on the corresponding historical consensus running state of each blockchain node in at least one historical consensus, wherein the historical consensus running state comprises historical available computing resources and a historical consensus result, the historical available computing resources comprise historical available CPU resources, historical available network resources and historical available memory resources, and the historical consensus result is used to indicate whether the blockchain node participates in the current consensus.

3. The method of claim 1, wherein, The determining of the plurality of first candidate blockchain nodes according to the predicted consensus running state of each blockchain node corresponding to the current consensus predicted by the target timing large model comprises: for each blockchain node, inputting the historical consensus running state of the blockchain node corresponding to h historical consensuses into the target timing large model to obtain the predicted consensus running state of the current consensus output by the target timing large model, wherein the predicted available computing resources comprise predicted available CPU resources, predicted available network resources and predicted available memory resources, and h is an integer greater than 0; ranking the predicted consensus running state as an index from high to low to determine the first quantity of blockchain nodes as first candidate blockchain nodes.

4. The method of claim 1, wherein, Before the determining of the plurality of second candidate blockchain nodes from the plurality of first candidate blockchain nodes by using the mutual competition network iteration model and the dividing of the plurality of second candidate blockchain nodes into the plurality of mutual competition groups, the method further comprises: constructing the mutual competition network iteration model, wherein the mutual competition network iteration model comprises an input layer, a competition layer and a blockchain mutual competition layer, the input layer comprises the plurality of first candidate blockchain nodes, the competition layer comprises a plurality of blockchain consensus competition benchmark nodes, and the blockchain mutual competition layer comprises a plurality of mutual competition groups, each of the first candidate blockchain nodes corresponds to at least one of the blockchain consensus competition benchmark nodes, and each of the blockchain consensus competition benchmark nodes is associated with one of the mutual competition groups; initializing a benchmark consensus running state corresponding to each of the blockchain consensus competition benchmark nodes; iteratively updating the benchmark consensus running state corresponding to each of the blockchain consensus competition benchmark nodes according to a predicted consensus running state of each of the first candidate blockchain nodes corresponding to this consensus until a stop condition is met.

5. The method of claim 4, wherein, The iteratively updating the benchmark consensus running state corresponding to each of the blockchain consensus competition benchmark nodes according to a predicted consensus running state of each of the first candidate blockchain nodes corresponding to this consensus until a stop condition is met comprises: calculating a similarity between the predicted consensus running state of each of the first candidate blockchain nodes and the benchmark consensus running state of the corresponding blockchain consensus competition benchmark node, respectively; for each of the blockchain consensus competition benchmark nodes, taking the first candidate blockchain node with the largest corresponding similarity as a competition winning node; for each of the blockchain consensus competition benchmark nodes, adjusting the benchmark consensus running state corresponding to the blockchain consensus competition benchmark node based on the predicted consensus running state corresponding to the competition winning node.

6. The method of claim 1, wherein, The determining a plurality of second candidate blockchain nodes from the plurality of first candidate blockchain nodes and dividing the plurality of second candidate blockchain nodes into a plurality of mutual competition groups by using the mutual competition network iteration model comprises: for each of the blockchain consensus competition benchmark nodes, calculating a similarity between the predicted consensus running state of each of the corresponding first candidate blockchain nodes and the benchmark consensus running state of the blockchain consensus competition benchmark node, respectively, taking the first candidate blockchain node with a similarity greater than a preset threshold as the second candidate blockchain node, and dividing the second candidate blockchain node into the mutual competition group corresponding to the blockchain consensus competition benchmark node.

7. The method of claim 1, wherein, The consensus according to a plurality of mutual competition groups comprises: determining a consensus initiator corresponding to each of the mutual competition groups, wherein the consensus initiator is the second candidate blockchain node with the largest similarity; in the case that the consensus initiators corresponding to all the mutual competition groups initiate this consensus at the same time, determining that the consensus is completed in response to the number of participating nodes of this consensus corresponding to any of the mutual competition groups being greater than a second number, wherein the plurality of second candidate blockchain nodes comprise the participating nodes, and the second number is half of the total number of the second candidate blockchain nodes.

8. An electronic device, comprising: A computer program product comprising a program of instructions executable by a computer to implement the steps of the blockchain consensus method of any one of claims 1-7.

9. A readable storage medium, characterized by, A readable storage medium having stored thereon a program or instructions, the program or instructions being executable by a processor to implement the steps of the blockchain consensus method of any one of claims 1-7.

10. A computer program product, characterised in that, The computer program product comprises program instructions, when the program instructions are executed by a computer, the computer is executed to implement the steps of the blockchain consensus method of any one of claims 1-7.

Images