Master node selection method, device, electronic device and storage medium in consensus algorithm
By selecting the main nodes based on the historical blockchain data statistics node reputation points in the blockchain consensus algorithm, the problem of the main nodes being easily attacked under the rotation mechanism is solved, and the performance and security of the consensus algorithm are improved.
Patent Information
- Application Number
- CN202211445712.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-11-18
- Publication Date
- 2025-01-10
- Estimated Expiration
- 2042-11-18
AI Technical Summary
In the existing blockchain consensus algorithm, the master node selected through the rotation mechanism is easily predicted by the attacker, resulting in malicious attacks and affecting the performance of the consensus algorithm.
By obtaining the historical blocks corresponding to the consensus process of the historical rounds of the blockchain cluster, count the reputation points of each node, and selecting the master node based on the reputation points, reducing the probability that the master node is predicted and improving the performance of the consensus algorithm.
Effectively reduce the possibility of a master node being subject to malicious attacks, improve the performance of consensus algorithms, and ensure the reliability and security of the selected master node.
Smart Images

Figure CN115883308B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of blockchain technology, and in particular to a method, device, electronic device and storage medium for selecting a master node in a consensus algorithm. Background Art
[0002] At present, the consensus algorithms used by most blockchains are designed based on master nodes. These consensus algorithms generally determine the master node for each round of consensus process through a rotation mechanism, which gives each node in the cluster an equal chance to become the master node multiple times. However, the master node selected through the rotation mechanism is easy to be predicted by attackers, who can then launch attacks against the master node. Once the master node is maliciously attacked, the blockchain cluster will frequently switch views. During the view switching process, the cluster will temporarily stop the consensus process for the new block, which will greatly affect the performance of the consensus algorithm. Summary of the invention
[0003] In view of this, the embodiments of the present application provide a method, device, electronic device and storage medium for selecting a master node in a consensus algorithm, which can reduce the probability of the master node being successfully predicted, thereby reducing the possibility of the master node being subjected to malicious attacks and improving the performance of the consensus algorithm.
[0004] A first aspect of an embodiment of the present application provides a method for selecting a master node in a consensus algorithm, comprising:
[0005] Obtaining a historical block corresponding to a consensus process of a historical round of a blockchain cluster; wherein the consensus process of the historical round is a consensus process of a set round that has been completed before the consensus process of the current round of the blockchain cluster;
[0006] According to the node proposals and voting information recorded in the historical blocks, the reputation points of each node in the blockchain cluster are obtained by statistics;
[0007] According to the reputation points of the nodes, a master node of the current round of consensus process is selected from the nodes.
[0008] In the embodiment of the present application, when a new round of consensus process of the blockchain cluster begins and a master node needs to be elected, the node proposal and voting information of each node recorded in the historical block corresponding to the consensus process of the historical round will be obtained. Based on this information, the reputation of each node's historical consensus behavior can be evaluated, so as to obtain the reputation points of each node, and finally select the master node from each node according to the reputation points of each node. There is no obvious rule to follow when selecting the master node using this method, so it can reduce the probability of the master node being successfully predicted, thereby reducing the possibility of the master node being attacked maliciously and improving the performance of the consensus algorithm.
[0009] In one implementation of the embodiment of the present application, obtaining the historical blocks corresponding to the consensus process of the historical rounds of the blockchain cluster may include:
[0010] Get the preset number of blocks to obtain and the number of blocks to skip;
[0011] Determine the last block in the historical blocks according to the current block corresponding to the consensus process of the current round and the number of block skips;
[0012] Determine the first block in the historical blocks according to the last block and the block acquisition quantity;
[0013] All blocks between the first block and the last block, the first block, and the last block are determined as the acquired historical blocks.
[0014] Furthermore, determining the last block in the historical blocks according to the current block corresponding to the current round of consensus process and the number of block skips may include:
[0015] Obtaining a first block number corresponding to the current block;
[0016] Subtract the number of block skips from the first block number and then subtract one from the first block number to obtain a second block number;
[0017] Determine the block corresponding to the second block number as the last block;
[0018] Determining the first block in the historical blocks according to the last block and the block acquisition quantity may include:
[0019] Subtract the number of blocks obtained from the second block number and add 1 to obtain a third block number;
[0020] The block corresponding to the third block number is determined as the first block.
[0021] In one implementation of the embodiment of the present application, the node proposal and voting information includes the number of successful proposals, the number of successful votes, and the number of failed proposals of each node; the reputation points of each node in the blockchain cluster are obtained by statistics based on the node proposal and voting information recorded in the historical block, which may include:
[0022] For each block in the historical blocks, the reputation score data corresponding to the block is obtained by statistics according to the number of successful proposals, the number of successful votes and the number of failed proposals of each node recorded in the block; wherein the reputation score data records the reputation score of each node, the reputation score is positively correlated with the number of successful proposals, the reputation score is positively correlated with the number of successful votes, and the reputation score is negatively correlated with the number of failed proposals;
[0023] The reputation score data corresponding to each block in the historical blocks is processed by accumulating the reputation scores differentiated by nodes to obtain the reputation score data corresponding to the current block; wherein the reputation score data records the reputation score obtained by accumulating the reputation scores of each of the nodes, and the current block is the block corresponding to the consensus process of the current round.
[0024] Furthermore, for each block in the historical blocks, the credibility score data corresponding to the block is obtained by counting the number of successful proposals, the number of successful votes, and the number of failed proposals of each node recorded in the block, which may include:
[0025] Searching the target block which is closest to the current block and has corresponding credit score data from the historical blocks;
[0026] For each block in the historical block including the target block and thereafter, the credit score data corresponding to the block is obtained by counting the number of successful proposals, the number of successful votes, and the number of failed proposals of each node recorded in the block;
[0027] The step of performing node-based reputation score accumulation processing on the reputation score data corresponding to each block in the historical blocks to obtain the reputation score data corresponding to the current block may include:
[0028] The reputation score data corresponding to the target block and each subsequent block in the historical block and the reputation score data corresponding to the target block are processed by accumulating the reputation scores differentiated by nodes to obtain the reputation score data corresponding to the current block.
[0029] Furthermore, after selecting the master node of the current round of consensus process from the nodes according to the reputation points of the nodes, the following may also be included:
[0030] Send voting information carrying the credit score data corresponding to the current block to the master node to instruct the master node to store the credit score data corresponding to the current block into the current block.
[0031] In one implementation of the embodiment of the present application, obtaining the historical blocks corresponding to the consensus process of the historical rounds of the blockchain cluster may include:
[0032] When the current round of consensus process begins, determining whether the current round of consensus process requires the election of a master node according to the configuration information of the blockchain cluster;
[0033] If the current round of consensus process requires the election of a master node, the historical blocks corresponding to the historical rounds of consensus process are obtained.
[0034] A second aspect of an embodiment of the present application provides a master node selection device in a consensus algorithm, comprising:
[0035] A historical block acquisition module is used to acquire historical blocks corresponding to the consensus process of the historical rounds of the blockchain cluster; wherein the consensus process of the historical rounds is the consensus process of the set rounds that has been completed before the consensus process of the current round of the blockchain cluster;
[0036] A reputation score statistics module, used to obtain the reputation score of each node in the blockchain cluster based on the node proposal and voting information recorded in the historical block;
[0037] The master node selection module is used to select the master node of the current round of consensus process from the various nodes according to the reputation points of the various nodes.
[0038] A third aspect of an embodiment of the present application 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 computer program, the method for selecting a master node in a consensus algorithm as provided in the first aspect of an embodiment of the present application is implemented.
[0039] The fourth aspect of an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the master node selection method in the consensus algorithm provided in the first aspect of the embodiment of the present application.
[0040] The fifth aspect of the embodiments of the present application provides a computer program product. When the computer program product runs on an electronic device, the electronic device executes the master node selection method in the consensus algorithm provided in the first aspect of the embodiments of the present application.
[0041] It can be understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS
[0042] Figure 1This is a flowchart of a method for selecting a master node in a consensus algorithm provided in an embodiment of the present application;
[0043] Figure 2 This is a schematic diagram of obtaining a historical block provided in an embodiment of the present application;
[0044] Figure 3 It is a structural schematic diagram of a master node selection device in a consensus algorithm provided in an embodiment of the present application;
[0045] Figure 4 It is a schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0046] In the following description, for the purpose of illustration rather than limitation, specific details such as specific system structures, technologies, etc. are proposed, so as to thoroughly understand the embodiments of the present application. However, it should be clear to those skilled in the art that the present application can also be implemented in other embodiments without these specific details. In other cases, the detailed description of well-known systems, devices, circuits and methods is omitted to prevent unnecessary details from hindering the description of the present application. In addition, in the description of the present application specification and the attached claims, the terms "first", "second", "third" etc. are only used to distinguish the description, and cannot be interpreted as indicating or suggesting relative importance.
[0047] At present, the consensus algorithms used by most blockchains are designed based on master nodes. The behavior of the master node is closely related to the performance of the consensus module of the entire system. Once the master node frequently crashes or is attacked maliciously, the blockchain cluster will frequently switch views. During the view switching process, the cluster will temporarily stop the consensus process for new blocks, which will greatly affect the performance of the consensus algorithm. Therefore, in order to minimize the possibility of master node misbehavior, the selected master node should be trusted as much as possible when selecting the master node.
[0048] In view of this, the embodiment of the present application provides a method for selecting a master node in a consensus algorithm, which selects nodes with higher reputation scores as master nodes by setting a reputation evaluation mechanism, which can not only improve the reliability of the selected master nodes, but also reduce the probability of the master nodes being successfully predicted, thereby effectively improving the performance of the consensus algorithm. For more specific technical implementation details of the embodiment of the present application, please refer to the method embodiment described below.
[0049] See also Figure 1 , shows a method for selecting a master node in a consensus algorithm provided in an embodiment of the present application, including:
[0050] 101. Obtain the historical blocks corresponding to the consensus process of the historical rounds of the blockchain cluster;
[0051] It should be understood that the execution subject of the embodiment of the method is each node in the blockchain cluster. If a master node needs to be elected in each round of the consensus process, each node in the blockchain cluster will execute the master node selection method in the consensus algorithm provided in the embodiment of the method, thereby selecting the master node of the current round of the consensus process.
[0052] In each round of consensus process, the master node will store the consensus behavior data of each node in the consensus process (such as node proposals and voting information, etc.) in the block corresponding to the current round of consensus process. In other words, each consensus process corresponds to a block, which records the consensus behavior data of each node in the consensus process.
[0053] The method for selecting the master node in the consensus algorithm provided by the present method embodiment can be mainly divided into three stages: historical tracing, points statistics and master node selection. When the consensus process of the current round of the blockchain cluster needs to elect a master node, the historical tracing stage is first entered. This stage needs to obtain the historical blocks corresponding to the consensus process of the historical round of the blockchain cluster. The consensus process of the historical round here refers to the consensus process of the set round that has been completed before the consensus process of the current round of the blockchain cluster. In the present method embodiment, the credit points of each node are mainly evaluated by the historical behavior performance information of each node in each round of the consensus process (such as the activity and success rate of node proposals and voting, etc.), so it is necessary to obtain the historical blocks corresponding to the consensus process of the historical round to trace this part of information. After the system has been running for a period of time, it is not feasible to trace each historical block from the beginning and affect the performance of the cluster, so a suitable historical window size can be predetermined here. The historical window size can be regarded as the number of historical blocks obtained, that is, the number of corresponding historical rounds. In actual operation, the historical window size can generally be set to dozens (e.g., 30-50) blocks. The specific window size can be determined according to the frequency of block generation by the blockchain cluster. For example, if the frequency of block generation is high, the window size can be set larger, otherwise the window size can be set smaller. For example, assuming that the 60th round of consensus process of the blockchain cluster is currently started, and the historical window size is set to 30 blocks, 30 rounds can be selected from the 1st to 59th rounds of consensus process, and the historical blocks corresponding to the consensus process of the 30 rounds can be obtained, for example, a total of 30 historical blocks corresponding to the 30th to 59th rounds of consensus process.
[0054] In one implementation of the embodiment of the present application, obtaining the historical blocks corresponding to the consensus process of the historical rounds of the blockchain cluster may include:
[0055] (1) When the current round of consensus process begins, determining whether the current round of consensus process requires the election of a master node according to the configuration information of the blockchain cluster;
[0056] (2) If the current round of consensus process requires the election of a master node, then obtain the historical blocks corresponding to the consensus process of the historical round. In fact, not every round of consensus process requires the election of a master node, that is, not every round of consensus process requires the switching of the master node. Generally speaking, if the current master node behaves improperly, the blockchain cluster will switch views, and a master node election is required at this time; or, the need to elect a master node can be determined based on the configuration information set by the blockchain cluster. For example, the system can be configured to conduct a master node election every certain number of blocks (even if the current master node does not behave improperly), and so on. If the current round of consensus process does not require the election of a master node, it is not necessary to perform subsequent steps such as historical tracing, points statistics, and master node selection. Conversely, if the current round of consensus process requires the election of a master node, subsequent steps such as historical tracing, points statistics, and master node selection are performed in sequence.
[0057] In one implementation of the embodiment of the present application, obtaining the historical blocks corresponding to the consensus process of the historical rounds of the blockchain cluster may include:
[0058] (1) Obtaining a preset number of blocks to be acquired and a preset number of blocks to be skipped;
[0059] (2) determining the last block in the historical blocks according to the current block corresponding to the consensus process of the current round and the number of blocks skipped;
[0060] (3) determining the first block in the historical blocks according to the last block and the number of blocks obtained;
[0061] (4) All blocks between the first block and the last block, the first block, and the last block are determined as the acquired historical blocks.
[0062] When obtaining historical blocks, you can first obtain the preset number of blocks to obtain and the number of blocks to skip. The number of blocks to obtain means the number of historical blocks to obtain, which is the size of the historical window mentioned above; the number of blocks to skip can also be called the number of rounds that can be skipped, which means the number of blocks (rounds) to skip when obtaining the previous historical blocks adjacent to the current block.
[0063] The purpose of setting the number of block skips (number of rounds that can be skipped) is to reduce the impact of some backward nodes in the blockchain cluster on the consistency of the master node selection results. For example, assuming that the current round is the 60th round, corresponding to block 60, and the number of block skips set is 2, it means skipping the first two blocks adjacent to block 60, that is, blocks 58 and 59 are skipped, and the final historical blocks obtained are blocks 57 and before. For some backward nodes, they may not be able to obtain the latest blocks 58 and 59 in time. Therefore, if the number of block skips is not set, the historical blocks obtained by normal nodes will include blocks 58 and 59, while the historical blocks obtained by backward nodes will not include blocks 58 and 59, which may lead to inconsistent results of the subsequent score statistics and master node selection of normal nodes and backward nodes. On the contrary, if the number of block skips is set to 2, all nodes (including normal nodes and lagging nodes) will obtain block 57 and previous blocks as historical blocks, thereby ensuring that the subsequent point statistics of all nodes are consistent with the results of the master node selection.
[0064] According to the current block corresponding to the current round of consensus process and the set number of block skips, the last block in the historical blocks to be obtained can be determined; then, according to the determined last block and the set number of blocks to be obtained, the first block in the historical blocks to be obtained can be determined; finally, the first block, the last block, and all blocks between them can be determined as the obtained historical blocks. Obviously, as the consensus rounds continue to proceed and new blocks are continuously submitted, the historical blocks obtained are also updated in different ways.
[0065] Furthermore, determining the last block in the historical blocks according to the current block corresponding to the current round of consensus process and the number of block skips may include:
[0066] (1) Obtaining a first block number corresponding to the current block;
[0067] (2) subtracting the number of block skips from the first block number and then subtracting 1 to obtain a second block number;
[0068] (3) Determine the block corresponding to the second block number as the last block.
[0069] Determining the first block in the historical blocks according to the last block and the block acquisition quantity may include:
[0070] (1) subtracting the number of blocks obtained from the second block number and adding 1 to obtain a third block number;
[0071] (2) Determine the block corresponding to the third block number as the first block.
[0072] For example, assuming that the current block is block 60, the block skip number is 2, and the block acquisition number is 30, the last block in the historical blocks to be acquired can be determined based on block 60 and the block skip number 2. The specific calculation is to subtract the block skip number from the block number of the current block and then subtract one, that is, 60-2-1=57, so that it is determined that the last block in the historical blocks to be acquired is block 57; then, combined with the block acquisition number 30 and the last block, the first block in the historical blocks to be acquired can be determined. The specific calculation is to subtract the block acquisition number from the block number of the last block and then add one, that is, 57-30+1=28, so that it is determined that the first block in the historical blocks to be acquired is block 28; finally, the acquired historical blocks are blocks 28-block 57.
[0073] To more intuitively represent the acquisition process of the above historical blocks, please refer to Figure 2 The schematic diagram of obtaining the historical block is shown in FIG. Figure 2 In the table, the horizontal axis indicates the direction in which the block is updated. The position of the vertical line of the current round indicates the position of the current block. First, the position of the current block is subtracted from the number of block skips to get the position of the last block in the acquired history window. Then, the position of the last block is subtracted from the number of blocks acquired to get the position of the first block in the history window. After determining the first and last blocks in the history window, all blocks contained in the history window are also determined. These blocks are the acquired history blocks. In addition, the blocks in the history window are continuously updated as new blocks are submitted.
[0074] 102. According to the node proposals and voting information recorded in the historical blocks, the reputation points of each node in the blockchain cluster are obtained by statistics;
[0075] After obtaining the historical block (for example Figure 2 After all the blocks in the history window are counted, the reputation points of each node can be obtained based on the node proposals and voting information recorded in the history block. Generally speaking, the higher the proposal / voting success rate and activity of a node, the higher its corresponding reputation points.
[0076] In one implementation of the embodiment of the present application, the node proposal and voting information includes the number of successful proposals, the number of successful votes, and the number of failed proposals of each node; the reputation points of each node in the blockchain cluster are obtained by statistics based on the node proposal and voting information recorded in the historical block, which may include:
[0077] (1) For each block in the historical blocks, the reputation score data corresponding to the block is obtained according to the number of successful proposals, the number of successful votes and the number of failed proposals of each node recorded in the block; wherein the reputation score data records the reputation score of each node, the reputation score is positively correlated with the number of successful proposals, the reputation score is positively correlated with the number of successful votes, and the reputation score is negatively correlated with the number of failed proposals;
[0078] (2) The reputation score data corresponding to each block in the historical blocks is processed by accumulating the reputation scores according to the nodes to obtain the reputation score data corresponding to the current block; wherein the reputation score data records the reputation score obtained by accumulating the reputation scores of each node, and the current block is the block corresponding to the consensus process of the current round.
[0079] Specifically, the node proposal and voting information saved in the block may include the number of successful proposals, the number of successful votes, and the number of failed proposals for each node. In actual operation, several lists can be constructed to save these data, such as the successful proposal number list SuccessAuthorList, the successful vote number list SuccessVoteList, and the failed proposal number list FailedAuthorList. For each block in the acquired historical blocks, the corresponding credit score data of the block can be obtained based on the number of successful proposals, successful votes, and failed proposals of each node recorded in the block. The credit score data records the credit score of each node, which is positively correlated with the number of successful proposals, positively correlated with the number of successful votes, and negatively correlated with the number of failed proposals. For example, in a round of consensus process, if a node fails to successfully complete a proposal, the cluster will record the node's behavior in FailedAuthorList; if a node successfully completes a vote, the cluster will record the node's behavior in SuccessVoteList; if the ratio of a node's failed proposals to successful proposals exceeds a specified threshold, the node's reputation score can be reduced; if the ratio does not exceed the threshold and there have been successful proposals or votes, the node's reputation score can be increased.
[0080] Obviously, each block in the historical block records its own node proposal and voting information, so the reputation score data corresponding to each block can be counted separately, and then all blocks in the historical block are traversed, and the reputation score data corresponding to each block is accumulated by node, and finally the reputation score data corresponding to the current block is obtained. Among them, the reputation score data records the reputation score obtained after the reputation score of each node is accumulated, which can be a reputation score list ReputationScoreList, and the current block is the block corresponding to the consensus process of the current round. For example, assuming that the historical blocks obtained include 10 blocks from block 11 to block 20, the reputation score data corresponding to each block is firstly counted according to the node proposal and voting information of each block, and then the reputation score data of these 10 blocks are accumulated by node, and finally the reputation score data corresponding to the current block is obtained. For a certain node A, the reputation score data of node A recorded in the reputation score data corresponding to the current block is equal to the cumulative value of the reputation score of node A recorded in the reputation score data of the 10 blocks, and so on.
[0081] Furthermore, for each block in the historical blocks, the credibility score data corresponding to the block is obtained by counting the number of successful proposals, the number of successful votes, and the number of failed proposals of each node recorded in the block, which may include:
[0082] (1) searching the historical blocks for a target block that is closest to the current block and has corresponding credit score data;
[0083] (2) For each block in the historical block including the target block and thereafter, the credit score data corresponding to the block is obtained by counting the number of successful proposals, the number of successful votes, and the number of failed proposals of each node recorded in the block.
[0084] The step of performing node-based reputation score accumulation processing on the reputation score data corresponding to each block in the historical blocks to obtain the reputation score data corresponding to the current block may include:
[0085] The reputation score data corresponding to the target block and each subsequent block in the historical block and the reputation score data corresponding to the target block are processed by accumulating the reputation scores differentiated by nodes to obtain the reputation score data corresponding to the current block.
[0086] As mentioned above, not every round of consensus process will switch the master node. Only for the consensus process with master node switching, the credit score statistics and master node selection operations will be performed. In order to reduce the amount of repeated calculations, for each round of consensus process with master node switching, after the corresponding credit score data is obtained by statistics, the master node can store the credit score data in the block corresponding to the current round of consensus process. Exemplarily, if the consensus process of round n does not switch the master node, the corresponding credit score data will not be counted in round n. At this time, only the node proposal and voting information of round n will be recorded in the block of round n. If the consensus process of round n+1 switches the master node, all blockchain nodes will obtain credit score data based on historical block statistics in round n+1. After determining the new master node based on the credit score data, each blockchain node can put the credit score data calculated in the round into the voting information and send the voting information to the new master node. The new master node will record the credit score data and the node proposal and voting information of round n+1 in the block of round n+1. That is, each historical block contains the node proposal and voting information of the corresponding round, but not necessarily the reputation points data.
[0087] In order to avoid repeated counting of credit points, the credit points data can be calculated based on the latest (that is, the closest to the current block) historical block containing credit points data. After traversing and counting all the acquired historical blocks, the credit points data corresponding to the current block can be obtained. Specifically, first, the block closest to the current block and containing the corresponding credit points data is searched from the acquired historical blocks, and the block is represented by the target block; then, for each block in the historical block containing the target block and thereafter, the credit points data corresponding to the block is obtained according to the number of successful proposals, successful votes, and failed proposals recorded in the block; finally, the credit points data corresponding to the target block and the credit points data corresponding to each block in the historical block containing the target block and thereafter are accumulated by nodes to obtain the credit points data corresponding to the current block.
[0088] For example, assuming that the current consensus process is round 12, the current block is block 12, and the historical blocks obtained are blocks 1-10, among which the credit score data is not empty in blocks 3, 5 and 7 (the latest historical blocks with corresponding credit score data), first obtain the credit score data in block 7 (as the target block), then obtain credit score data 7 based on the node proposal and voting information statistics of block 7, obtain credit score data 8 based on the node proposal and voting information statistics of block 8, obtain credit score data 9 based on the node proposal and voting information statistics of block 9, and obtain credit score data 10 based on the node proposal and voting information statistics of block 10, then perform credit score accumulation processing on the credit score data of block 7, credit score data 7, credit score data 8, credit score data 9 and credit score data 10 according to the node proposal and voting information statistics, and obtain the credit score data corresponding to block 12. In this process, the reputation score data of blocks 1 to 6 have been statistically reflected in the reputation score data of block 7, so there is no need to repeat the calculation, thereby avoiding the work of repeatedly counting the reputation score and reducing the amount of calculation. In addition, since the reputation score data of block 7 is not statistically reflected in the reputation score data of block 7, the reputation score data of block 7 needs to be counted and added when calculating the reputation score data of block 12.
[0089] 103. Select a master node for the current round of consensus process from among the nodes based on the reputation points of the nodes.
[0090] After obtaining the credit points of each node in the blockchain cluster under the current round of consensus process, a master node can be selected from these nodes based on the credit points. For example, the node with the highest credit point can be selected as the master node of the current round of consensus process.
[0091] In an implementation of the embodiment of the present application, selecting the master node of the current round of consensus process from each node according to the reputation points of each node in the blockchain may include:
[0092] (1) Find the top N nodes with the highest reputation scores among the nodes, where N is an integer greater than or equal to 1;
[0093] (2) Select the master node from the first N nodes.
[0094] When selecting a master node, firstly, the top N (for example, N=10) nodes with the highest reputation points can be found from all nodes, and then a node can be selected from the N nodes as the master node according to the set rules. For example, a suitable node can be selected from the N nodes as the master node by comprehensively considering factors such as the reputation points of the node, the device performance of the node, and the number of times the node has been elected as the master node.
[0095] Furthermore, after selecting the master node of the current round of consensus process from the nodes according to the reputation points of the nodes, the following may also be included:
[0096] Send voting information carrying the credit score data corresponding to the current block to the master node to instruct the master node to store the credit score data corresponding to the current block into the current block.
[0097] After selecting the master node of the current round of consensus process based on the reputation score, each node can send voting information carrying the reputation score data corresponding to the current block to the master node. The master node will collect the node proposals and voting information of each node in the current round of consensus process, and then store the node proposals and voting information and the reputation score data (these two parts of data can be collectively referred to as reputation score related data) in the block corresponding to the current round of consensus process. With this setting, if the master node switches in the subsequent rounds of consensus process, the reputation score data in the current block can be obtained as a benchmark when calculating the reputation score to reduce the calculation workload.
[0098] In summary, the embodiment of the present application proposes a node reputation evaluation mechanism, which enables the blockchain cluster to evaluate the reputation of each node based on its historical consensus behavior, and select nodes with higher reputation values as master nodes. In addition, the embodiment of the present application can also record the node's reputation-related data on the chain with the help of the original consensus process, so that the replacement process of the master node can be traced and verified, which greatly enhances the security of the system and also improves the system throughput.
[0099] In the embodiment of the present application, when a new round of consensus process of the blockchain cluster begins and a master node needs to be elected, the node proposal and voting information of each node recorded in the historical block corresponding to the consensus process of the historical round will be obtained. Based on this information, the reputation of each node's historical consensus behavior can be evaluated, so as to obtain the reputation points of each node, and finally select the master node from each node according to the reputation points of each node. There is no obvious rule to follow when selecting the master node using this method, so it can reduce the probability of the master node being successfully predicted, thereby reducing the possibility of the master node being attacked maliciously and improving the performance of the consensus algorithm.
[0100] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.
[0101] The above mainly describes a method for selecting a master node in a consensus algorithm. The following will describe a device for selecting a master node in a consensus algorithm.
[0102] See also Figure 3 , an embodiment of a master node selection device in a consensus algorithm in an embodiment of the present application includes:
[0103] The historical block acquisition module 301 is used to acquire the historical blocks corresponding to the consensus process of the historical rounds of the blockchain cluster; wherein the consensus process of the historical rounds is the consensus process of the set rounds that has been completed before the consensus process of the current round of the blockchain cluster;
[0104] A reputation score statistics module 302 is used to obtain the reputation score of each node in the blockchain cluster based on the node proposal and voting information recorded in the historical block;
[0105] The master node selection module 303 is used to select the master node of the current round of consensus process from the various nodes according to the reputation points of the various nodes.
[0106] In one implementation of the embodiment of the present application, the historical block acquisition module may include:
[0107] A block number acquisition unit, used to acquire a preset block acquisition number and a block skip number;
[0108] An end block determination unit, configured to determine the last block in the historical blocks according to the current block corresponding to the current round of consensus process and the number of block skips;
[0109] a starting block determining unit, configured to determine a first block in the historical blocks according to the last block and the block acquisition quantity;
[0110] The historical block determining unit is used to determine all blocks between the first block and the last block, the first block and the last block as the acquired historical blocks.
[0111] Furthermore, the end block determination unit may include:
[0112] A block number obtaining subunit, used to obtain a first block number corresponding to the current block;
[0113] A first block number calculation subunit is used to obtain a second block number by subtracting the block skipping number from the first block number and then subtracting one.
[0114] an end block determination subunit, configured to determine the block corresponding to the second block number as the last block;
[0115] The starting block determination unit may include:
[0116] A second block number calculation subunit is used to obtain a third block number by subtracting the number of acquired blocks from the second block number and then adding 1;
[0117] The starting block determining subunit is used to determine the block corresponding to the third block number as the first block.
[0118] In one implementation of the embodiment of the present application, the node proposal and voting information includes the number of successful proposals, the number of successful votes, and the number of failed proposals of each node; the reputation score statistics module may include:
[0119] A reputation score statistics unit, for each block in the historical blocks, according to the number of successful proposals, the number of successful votes and the number of failed proposals of each node recorded in the block, to obtain the reputation score data corresponding to the block; wherein the reputation score data records the reputation score of each node, the reputation score is positively correlated with the number of successful proposals, the reputation score is positively correlated with the number of successful votes, and the reputation score is negatively correlated with the number of failed proposals;
[0120] The reputation score statistics unit is used to perform node-based reputation score accumulation processing on the reputation score data corresponding to each block in the historical blocks to obtain the reputation score data corresponding to the current block; wherein the reputation score data records the reputation score obtained after the reputation score of each node is accumulated, and the current block is the block corresponding to the consensus process of the current round.
[0121] Furthermore, the reputation score statistics unit may include:
[0122] A target block search subunit, used to search the target block closest to the current block and storing corresponding credit score data from the historical blocks;
[0123] A credit score statistics subunit is used to obtain credit score data corresponding to the target block and each subsequent block in the historical block according to the number of successful proposals, successful votes and failed proposals of each node recorded in the block;
[0124] The credit score statistics unit may include:
[0125] The credit score statistics subunit is used to perform node-based credit score accumulation processing on the credit score data corresponding to the target block and each subsequent block in the historical block and the credit score data corresponding to the target block to obtain the credit score data corresponding to the current block.
[0126] Furthermore, the master node selection device in the consensus algorithm may also include:
[0127] The voting information sending module is used to send voting information carrying the credit score data corresponding to the current block to the master node to instruct the master node to store the credit score data corresponding to the current block into the current block.
[0128] In one implementation of the embodiment of the present application, the historical block acquisition module may include:
[0129] A configuration determination unit, configured to determine whether the current round of consensus process requires the election of a master node according to the configuration information of the blockchain cluster when the current round of consensus process begins;
[0130] A historical block acquisition unit is used to acquire the historical blocks corresponding to the consensus process of the historical round if the consensus process of the current round needs to elect a master node. The embodiment of the present application also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the following Figure 1 The master node selection method in any consensus algorithm represented by .
[0131] The embodiment of the present application also provides a computer program product. When the computer program product is run on an electronic device, the electronic device executes the following Figure 1 The master node selection method in any consensus algorithm represented by .
[0132] Figure 4 is a schematic diagram of an electronic device provided by an embodiment of the present application. Figure 4 As shown, the electronic device 4 of this embodiment includes: a processor 40, a memory 41, and a computer program 42 stored in the memory 41 and executable on the processor 40. When the processor 40 executes the computer program 42, the steps in the embodiments of the master node selection method in each of the above consensus algorithms are implemented, for example Figure 1 Alternatively, when the processor 40 executes the computer program 42, the functions of each module / unit in the above-mentioned device embodiments are realized, for example, Figure 3 Functions of modules 301 to 303 are shown.
[0133] The computer program 42 may be divided into one or more modules / units, which are stored in the memory 41 and executed by the processor 40 to complete the present application. The one or more modules / units may be a series of computer program instruction segments capable of completing specific functions, which are used to describe the execution process of the computer program 42 in the electronic device 4.
[0134] The processor 40 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.
[0135] The memory 41 may be an internal storage unit of the electronic device 4, such as a hard disk or memory of the electronic device 4. The memory 41 may also be an external storage device of the electronic device 4, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device 4. Further, the memory 41 may also include both an internal storage unit and an external storage device of the electronic device 4. The memory 41 is used to store the computer program and other programs and data required by the electronic device 4. The memory 41 may also be used to temporarily store data that has been output or is to be output.
[0136] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.
[0137] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.
[0138] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.
[0139] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.
[0140] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the system embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.
[0141] The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiments of the present application.
[0142] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.
[0143] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.
[0144] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such 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 application, and should all be included in the protection scope of the present application.
Claims
1. A method for selecting a master node in a consensus algorithm, characterized in that: include: Obtaining a historical block corresponding to a consensus process of a historical round of a blockchain cluster; wherein the consensus process of the historical round is a consensus process of a set round that has been completed before the consensus process of the current round of the blockchain cluster; According to the node proposals and voting information recorded in the historical blocks, the reputation points of each node in the blockchain cluster are obtained by statistics; According to the reputation points of the nodes, a master node of the current round of consensus process is selected from the nodes; The step of obtaining the historical blocks corresponding to the consensus process of the historical rounds of the blockchain cluster includes: Get the preset number of blocks to obtain and the number of blocks to skip; Determine the last block in the historical blocks according to the current block corresponding to the consensus process of the current round and the number of block skips; Determine the first block in the historical blocks according to the last block and the block acquisition quantity; All blocks between the first block and the last block, the first block, and the last block are determined as the acquired historical blocks.
2. The method according to claim 1, characterized in that The determining the last block in the historical blocks according to the current block corresponding to the consensus process of the current round and the number of block skips includes: Obtaining a first block number corresponding to the current block; Subtract the number of block skips from the first block number and then subtract one from the first block number to obtain a second block number; Determine the block corresponding to the second block number as the last block; The determining, according to the last block and the block acquisition quantity, the first block in the historical blocks comprises: Subtract the number of blocks obtained from the second block number and add 1 to obtain a third block number; The block corresponding to the third block number is determined as the first block.
3. The method according to claim 1, characterized in that The node proposal and voting information includes the number of successful proposals, the number of successful votes, and the number of failed proposals for each node; The credit score of each node in the blockchain cluster is obtained by counting the node proposals and voting information recorded in the historical blocks, including: For each block in the historical blocks, the reputation score data corresponding to the block is obtained by statistics according to the number of successful proposals, the number of successful votes and the number of failed proposals of each node recorded in the block; wherein the reputation score data records the reputation score of each node, the reputation score is positively correlated with the number of successful proposals, the reputation score is positively correlated with the number of successful votes, and the reputation score is negatively correlated with the number of failed proposals; The reputation score data corresponding to each block in the historical blocks is processed by accumulating the reputation scores differentiated by nodes to obtain the reputation score data corresponding to the current block; wherein the reputation score data records the reputation score obtained by accumulating the reputation scores of each of the nodes, and the current block is the block corresponding to the consensus process of the current round.
4. The method according to claim 3, characterized in that For each block in the historical blocks, the credit score data corresponding to the block is obtained by counting the number of successful proposals, the number of successful votes, and the number of failed proposals of each node recorded in the block, including: Searching the target block which is closest to the current block and has corresponding credit score data from the historical blocks; For each block in the historical block including the target block and thereafter, the credit score data corresponding to the block is obtained by counting the number of successful proposals, the number of successful votes, and the number of failed proposals of each node recorded in the block; The credit score data corresponding to each block in the historical blocks is processed by accumulating the credit scores according to the nodes to obtain the credit score data corresponding to the current block, including: The reputation score data corresponding to the target block and each subsequent block in the historical block and the reputation score data corresponding to the target block are processed by accumulating the reputation scores differentiated by nodes to obtain the reputation score data corresponding to the current block.
5. The method according to claim 4, characterized in that After selecting the master node of the current round of consensus process from the nodes according to the reputation points of the nodes, the method further includes: Send voting information carrying the credit score data corresponding to the current block to the master node to instruct the master node to store the credit score data corresponding to the current block into the current block.
6. The method according to any one of claims 1 to 5, characterized in that: The historical blocks corresponding to the consensus process of the historical rounds of the blockchain cluster are obtained, including: When the current round of consensus process begins, determining whether the current round of consensus process requires the election of a master node according to the configuration information of the blockchain cluster; If the current round of consensus process requires the election of a master node, the historical blocks corresponding to the historical rounds of consensus process are obtained.
7. A master node selection device in a consensus algorithm, characterized in that: include: A historical block acquisition module is used to acquire historical blocks corresponding to the consensus process of the historical rounds of the blockchain cluster; wherein the consensus process of the historical rounds is the consensus process of the set rounds that has been completed before the consensus process of the current round of the blockchain cluster; A reputation score statistics module, used to obtain the reputation score of each node in the blockchain cluster based on the node proposal and voting information recorded in the historical block; A master node selection module, used to select a master node of the current round of consensus process from each node according to the reputation points of each node; Wherein, the historical block acquisition module includes: A block number acquisition unit, used to acquire a preset block acquisition number and a block skip number; An end block determination unit, configured to determine the last block in the historical blocks according to the current block corresponding to the current round of consensus process and the number of block skips; a starting block determining unit, configured to determine a first block in the historical blocks according to the last block and the block acquisition quantity; The historical block determining unit is used to determine all blocks between the first block and the last block, the first block and the last block as the acquired historical blocks.
8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method for selecting a master node in the consensus algorithm according to any one of claims 1 to 6 is implemented.
9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method for selecting a master node in a consensus algorithm as described in any one of claims 1 to 6 is implemented.
Citation Information
Patent Citations
A method for implementing a network scalability block chain
CN109544334A
Blockchain consensus method and storage medium
CN110427433A