WO2022233164A1

WO2022233164A1 - Consensus method for chain-type periodic voting, and storage medium and electronic device

Info

Publication number: WO2022233164A1
Application number: PCT/CN2022/074000
Authority: WO
Inventors: 杨鉴
Original assignee: 杨鉴
Priority date: 2021-05-07
Filing date: 2022-01-26
Publication date: 2022-11-10
Also published as: CN113660299A

Abstract

The present invention relates to the field of blockchains, and in particular, to a consensus method for chain-type periodic voting, and a storage medium and an electronic device. The method comprises: step 1, obtaining a voting right to become a miner; step 2, the miner competing for block output by means of generating a random number, wherein a block output probability is proportional to votes held by the miner; step 3, the miner periodically voting for a block; step 4, selecting a main chain according to a voting result; and step 5, terminating, in the main chain, a block that meets a termination condition, so as to complete a consensus. By means of the present invention, a main chain confirmation process can be effectively combined with a termination process, the complexity of codes is reduced, and the processing efficiency is also improved. In addition, the present invention also has the advantages of low energy consumption of proof of stake, high fault tolerance of a chain-type formula for a network environment, more verification nodes and easier requirements, and the security and flexibility are also guaranteed.

Description

A consensus method, storage medium and electronic device for chain cycle voting

technical field

The invention relates to the field of blockchain, in particular to a consensus method, storage medium and electronic equipment for chain periodic voting.

Background technique

In a distributed currency system, our most basic requirement is only a usable "ledger". Whether all nodes are synchronized immediately is not what we really care about. From this point of view, the requirements of many distributed systems are too strict, similar to Although the PBFT (Practical Byzantine Fault Tolerance)-type consensus protocol realizes the accounting function, the complex interaction between its nodes is too cumbersome, and the message complexity is too high to support more verification nodes. When the network condition is not good, it will reduce the efficiency. The emergence of the proof-of-stake mechanism has actually opened the door to the realization of finality, because the total amount of rights and interests can be counted, so our collective decision-making based on rights and interests may come to an absolute advantage. Theoretically It can be "terminated", and in fact, a final consensus protocol has appeared. However, these finalization solutions are not perfect. For example, although Casper's solution is final, its implementation is still too complicated. There is no need to separate the confirmation main chain from the finalization process, which increases code complexity and reduces efficiency.

SUMMARY OF THE INVENTION

The technical problem to be solved by the present invention is to provide a consensus method, storage medium and electronic device for chain periodic voting.

The technical solution of the present invention to solve the above technical problems is as follows: a consensus method for chain periodic voting, including:

Step 1, get voting rights to become a miner;

Step 2, miners compete to generate blocks by generating random numbers, and the probability of block generation is proportional to the votes held by miners;

Step 3: Miners periodically vote on blocks;

Step 4, select the main chain according to the voting results;

Step 5: In the main chain, the blocks that meet the termination conditions are terminated to complete the consensus.

The beneficial effects of the present invention are: the above-mentioned method effectively combines the confirmation main chain and the finalization process, reduces the complexity of the code, and improves the processing efficiency. In addition, it also has the advantages of proof of rights and interests, low energy consumption, and chain formula to the network environment. High fault tolerance, more validating nodes and more relaxed requirements, in addition to ensuring security and flexibility.

On the basis of the above technical solutions, the present invention can also be improved as follows.

Further, step 1 is specifically:

When the stakeholder chooses to abstain from voting, the abstention record is published. When the stakeholder does not choose to abstain from voting and the first preset condition is met, a vote is generated and the voting right is obtained, and the stakeholder who has obtained the voting right becomes a miner;

Wherein, the first preset condition is:

VRF_Vote Proof＜Account_stakes

Among them, Account_stakes is the account equity, and VRF_Vote Proof is the random number generation function.

The beneficial effect of adopting the above-mentioned further scheme is that the flexibility of the method can be effectively increased by increasing the abstention selection, and in addition, it has the effect of reducing the processing amount and increasing the processing efficiency for the subsequent data processing.

Further, step 4 is specifically:

Priority is compared for each branch chain according to weight, and the branch chain with the highest priority is used as the main chain;

Wherein, the weight is: the total number of votes obtained by the root node of a branch chain, all child nodes of the root node, and grandchild nodes of the root node;

The priority comparison is specifically:

Starting from the blocks common to the branch chains, the weight sums of the respective branch chains are calculated respectively, and the one with the highest weight sum is given priority.

Further, step 5 is specifically:

On the basis that the voting chain is not interrupted, the root node block of the branch chain that obtains more than two-thirds of the total votes is terminated as the final block, and the chain where the final block is located is the final chain to complete the consensus;

Wherein, the uninterrupted voting chain is specifically:

A miner's M-th voted block to N-th voted block contains at least one final block, wherein the miner's M-th vote to the miner's N-th vote are connected in sequence, N≥2, M≤ N.

Further, step 5 also includes:

Based on the termination condition, determine whether there is a key fork in the first preset period;

Among them, the termination condition is specifically: the block that satisfies the continuous voting interval of no more than n cycles has the voting weight;

The first preset period is:

n+1 periods, n is a positive integer;

The key forks are as follows:

A fork that cannot continue to terminate.

Further, step 5 also includes:

When the finalization chain is disconnected, return the source block of the next voting block to the retracement point block obtained through the backtracking algorithm;

Among them, the source block is the last voted block connected to the current vote.

Further, the retracement point block obtained by the backtracking algorithm is specifically:

The backtracking algorithm is specifically:

Count the number of votes obtained on the blockchain where the block is located in the first preset period before the current block, obtain the first total number of votes, and determine whether the first total number of votes is greater than two-thirds of the total number of votes , if it is, then the estoppel period I=0, if not, then retrospect the vote of the height h of the current block to the position of height h-1, recalculate the total number of the first votes, and judge the total number of the first votes Whether it is greater than two-thirds of the total number of votes, if so, the estoppel period I = 1, if not, merge the votes backdated to the height h-1 with the votes of the height h-1, backtracked to the height h For the position of -2, repeat the above process until the total number of first votes is greater than two-thirds of the total number of votes, and the estoppel period I=i is obtained, where i is the number of backtracking;

The retracement point block is specifically:

Blocks with height h-I.

Further, step 5 further includes: within the estoppel period, the termination block is withdrawn to the withdrawal point block.

Another technical solution of the present invention to solve the above-mentioned technical problem is as follows: a storage medium, in which instructions are stored, and when a computer reads the instructions, the computer is made to execute any one of claims 1 to 8. A consensus method for chained periodic voting.

Another technical solution of the present invention to solve the above technical problem is as follows: an electronic device, comprising a memory, a processor and a program stored on the memory and running on the processor, the processor executes the program A consensus method for chained periodic voting as described in any one of claims 1 to 8 is realized.

Description of drawings

FIG. 1 is a schematic flowchart of an embodiment of a consensus method for chained periodic voting according to the present invention;

FIG. 2 is a schematic diagram of branch weight calculation provided by an embodiment of a consensus method for chained periodic voting according to the present invention;

FIG. 3 is a schematic diagram of a block generation empty window provided by an embodiment of a consensus method for chain periodic voting according to the present invention;

4 is a schematic diagram of a miner voting chain provided by an embodiment of a consensus method for chained periodic voting according to the present invention;

FIG. 5 is a schematic diagram of active voting provided by an embodiment of a consensus method for chained periodic voting according to the present invention;

FIG. 6 is a schematic diagram of security provided by an embodiment of a consensus method for chained periodic voting according to the present invention;

FIG. 7 is a schematic diagram of termination conditions provided by an embodiment of a consensus method for chained periodic voting according to the present invention;

FIG. 8 is a schematic diagram of a bifurcation provided by an embodiment of a consensus method for chained periodic voting according to the present invention;

FIG. 9 is a schematic diagram of forward movement provided by an embodiment of a consensus method for chained periodic voting according to the present invention.

Detailed ways

The principles and features of the present invention are described below, and the examples are only used to explain the present invention, but not to limit the scope of the present invention.

As shown in Figure 1, a consensus method for chained periodic voting includes:

Step 1, get voting rights to become a miner;

Step 3: Miners periodically vote on blocks;

Step 4, select the main chain according to the voting results;

In some possible implementations, the above method effectively combines the confirmation main chain and the finalization process, and reduces the complexity of the code and improves the processing efficiency. In addition, it also has the proof of stake, low energy consumption, and chain formula to the network. The environment is highly fault-tolerant, with more validating nodes and more relaxed requirements, in addition to ensuring security and flexibility.

It should be noted that stakeholders generate votes according to the amount of equity they hold, obtain voting qualifications, and become miners. Miners generate blocks according to the number of votes and receive rewards. Miners periodically vote on blocks, and then they will receive The branch with the most votes is identified as the main chain. When the voting result satisfies certain conditions, it can be determined that the result cannot be changed under certain assumptions (2/3 nodes are honest), which is called the end of the block, and the branch that has been terminated is the final In the main chain, the finalized block data is the final data.

In addition, in step 2, the stakeholder becomes a miner and begins to participate in the creation and maintenance of the blockchain. In order to obtain rewards, miners need to compete with each other for the right to create blocks:

The miner node performs a random operation with the account private key based on constants (timestamp, block hash value, etc.), expecting the result to reach a certain goal and meet the block production requirements, which is recorded as: Block_Pr oof<t arg et*votes*efficiency, Among them, target is the target, efficiency represents the block production efficiency, which is affected by various factors, votes is the number of votes currently used by miners, and the block production efficiency is determined as: the closer the target voting block is to the current chain, the correctness of the vote. The higher the value, the higher the efficiency of the block generation; the less the total number of correct votes of the target voting block at this height, the higher the importance of each correct vote of the target voting block, the higher the efficiency of the block generation; when After reaching the block production requirements, the miner node will package the transaction and voting information he received to generate a block and publish it to the network.

In step 3, as with all chain consensus, deciding which branch becomes the main chain is the most important step in the consensus process. In this process, miners determine the main chain by voting on each branch. In order to determine the main chain, miner nodes periodically (usually in minutes) sign the current main chain top block address and publish it to the network, called voting, and the voting records will be packaged into blocks like transactions.

In addition, the present invention also includes rewards, punishments and optimization. For users who violate the rules, such as those who violate the voting rules mentioned above and the abstention rules described in the next section, if they are punished, they will also be punished. Reward users who submit evidence of violations. This requires the user to deposit (or lock) a part of the "deposit" before performing the corresponding operation. As the funds for punishment and reward, this part of the funds will be released after being locked for a period of time. The amount of deposit a user puts in is proportional to the number of votes or stake he gets.

The "block hash value" used in calculating voting qualifications can be optimized: because users with small stakes may not be able to obtain voting qualifications for a long time, if they need to be based on the information of the current block at all times Trying to generate votes as a constant adds unnecessary overhead. Therefore, the mth block information before the current block will be used instead (several hours ago), so that users can know that they are eligible to vote several hours in advance, and only need to centrally calculate it every several hours in the future. That's it. But in order to prevent the transfer of funds to gain a competitive advantage, it must be stipulated that the transferred currency must be m blocks before it can be used as a stake to generate votes.

For users who have small rights and do not want to spend too much money to participate in mining, they can also issue "abstention" registration. Although this cannot directly participate in system maintenance, it can provide a more accurate number of active votes and speed up the finalization. process and make a certain contribution to the stability of the system. For such abstaining registrations, a small reward (proportional to the amount of stake) can be given, but these abstaining stakeholders are penalized if they are shown to have participated in the voting activity.

Since there is no transaction fee rewarded to the block generator for the miner's registration record, in order to motivate the miner to pack them into the block, we need to adjust the efficiency parameter efficiency according to the number of registration records in the generated block, thus affecting the miner's next block generation speed, so that the more registration records are packaged, the better. The standard value of this quantity should be adjusted at regular intervals.

If the block generation rate is set to be fast, resulting in frequent occurrence of short forks, you may wish to set the default estoppel period directly to 1 or 2, and the default endpoint will also be delayed by 1-2 blocks accordingly, which can reduce the number of long forks. to make the system run more smoothly.

Preferably, in any of the above embodiments, step 1 is specifically:

Wherein, the first preset condition is:

VRF_Vote Proof＜Account_stakes

In some possible implementations, the flexibility of the method can be effectively increased by adding abstention options, and in addition, the processing of subsequent data has the effect of reducing the amount of processing and increasing the processing efficiency.

It should be noted that the stakeholder uses the account private key to perform a random number operation according to the current constants (block hash value, timestamp, etc.), and then compares it with the number of stakes held by the account, and those who meet the requirements are eligible to vote. This process is recorded as: VRF_Vote Proof<Account_stakes, where Account_stakes represents account equity, the larger it is, the higher the possibility of meeting this condition, thus achieving the purpose of generating votes based on equity. Stakeholders who meet the voting qualifications can generate a vote, publish it on the network, and register as a miner (or voter). The registration record and transaction record need to be packaged into the block. The validity period of each vote is the time period between the current block (valued by the hash value constant) and several blocks after it, usually in hours, so as not to cause users to operate too frequently.

The introduction of voting qualification is to be able to reduce and flexibly control the number of validating nodes, so that different projects can balance between security and response speed. By controlling the difficulty of getting votes, we can keep the total number of votes in the system around what is needed. According to the probability, the more the total number of votes set, the closer the actual number of votes to the ideal number, the more reliable the various voting results we conduct based on the total number of votes, but the more votes, the more voting nodes, and the consensus The slower the speed, which needs to be weighed according to different needs.

Preferably, in any of the above embodiments, step 4 is specifically:

The priority comparison is specifically:

To be clear, in the protocol, branches are prioritized not by their length, but by their "weight". The "weight" here is not equal to the number of blocks, but equal to the number of votes a block gets. Definition: The weight of a branch is equal to the total number of votes received by its root node and all its descendant nodes. In this calculation method, the two chains should start from their common ancestor when comparing the priorities, and calculate the weights of the two branches to which they belong respectively, and the heavier one takes precedence. In order to find the main chain, we need to compare the currently existing competing branches one by one and find the chain with the highest priority, as shown in Figure 2. In the branch structure shown in the figure, the chain with the highest priority is r→b.

There are still some problems to be solved in the voting process. The first is to ensure that miners have enough enthusiasm to vote. This can be used to motivate miners by linking the "correctness" of voting with the efficiency of block production: according to "voting last cycle" ( Greater than or equal to one cycle, less than two cycles ago, the distance from the current chain (explained later) to determine the current block generation efficiency. This brings the following two problems: when a fork occurs, if miners choose to vote for the more stable blocks before the fork in order to pursue the correctness of the vote, it will affect the speed of system stability; or miners choose to postpone voting , the strategy of voting after the fork has a clear victory or defeat will also affect the speed of system stability. For these two issues, we first slightly modified the original cycle voting rules. The previous rule was that "the interval between voting targets cannot be less than the length of one cycle", and now we add "record the voting block in the current chain and the next one." The voting target interval cannot be less than the length of a period-1". According to the new rules, whenever a miner votes for an earlier block, or postpones the vote, the interval between this vote and the last vote will be greater than one cycle, and an empty window will appear where it exceeds one cycle. When the "previous 2 cycles -1" of the block is within this empty window, the miner's "last cycle vote" at this block position does not exist, so its correctness is zero and the block cannot be produced. For example: As shown in Figure 3, the current miner has an empty window at the position of block a, which results in the block position of block b, which is 2 cycles after a, and cannot produce blocks.

Therefore, in order to minimize this kind of empty window, miners should choose to vote as early as possible and vote for the top block. Secondly, use the method of linking the "importance" of voting with the efficiency of block production, and use the judgment of "the less the total number of correct votes, the higher the importance of one's own vote", to make the miners vote dispersed after the fork. votes at times have higher value. That is, voting needs to satisfy:

The interval between every two votes of miners must be greater than or equal to one voting cycle, otherwise they will be punished;

Each miner's vote on the current chain is recorded and the distance from the target of the next vote must be greater than or equal to the length of one voting cycle -1, otherwise it will also be punished;

The miner's block-producing efficiency parameter efficiency in the current chain is affected by the "correctness" of his voting in the previous cycle (1 cycle ≤ distance from the current position < 2 cycles), specifically: the closer the voting target block is to the current chain ( The lower the number of descendants after the fork), the higher the correctness and the higher the efficiency of block generation, and vice versa, the voting for the target on the current chain is called "correct" voting;

The miner's block production efficiency parameter efficiency in the current chain is affected by the "importance" of his correct votes in the previous cycle (same as above), specifically: the less the total number of correct votes for the voting target at this height, the higher the importance of a single correct vote. , the higher the block generation efficiency, the lower the vice versa;

There is an information integrity problem here, that is, whether the data stored in a chain can contain complete voting and branch information. If possible, it can not only simplify the algorithm for comparing priorities, but also provide support for the subsequent "finalization". More importantly, the consensus process has a complete record, which ensures the objectivity and verifiability of the system. To discuss this, we need to see whether miners have enough reason to package all the voting information, after all, voting does not provide fees.

So there are two cases:

For votes pointing to this chain, miners will naturally save as many blocks as possible to ensure the competitiveness of their own chain;

For votes pointing to other chains, first of all, recording them does not increase the competitiveness of the other chain, because the chain they point to is also recorded, on the contrary these votes are likely to help oneself when comparing between larger branches win. Secondly, for block miners, if the wrong vote of a certain miner is recorded, it will reduce the efficiency of the miner to generate blocks in this chain, thereby increasing the probability of successful block generation. Although it is only a small incentive, but It is also enough to prompt miners to record these uncomplicated voting information. At the same time, each block will try to refer to the blocks (block headers) of these other branches to support the collected voting records, thus completing the block tree.

Preferably, in any of the above embodiments, step 5 is specifically:

Wherein, the uninterrupted voting chain is specifically:

It should be noted that the finalization process of chain consensus does not require multiple rounds of voting to maintain a strict synchronization state between nodes, unlike BFT-type protocols. When a consensus is reached in the first round of voting, we only need to ensure that this consensus is unique, and do not need to care whether all nodes have received the voting results, so ideally only one round of voting is needed to complete the finalization. However, in order to ensure that the finalized chain does not conflict (security), and at the same time to allow voters to have the opportunity to modify their votes to prevent falling into a situation that can never be finalized (liveness), the situation becomes more complicated, and it is necessary to add new voting rules and postpone the closing time.

According to the mechanism of periodic voting and the premise that dishonest users do not exceed 1/3, we can determine that as long as a branch has obtained more than 2/3 of the votes in a cycle, then this branch should have no competitors and can be end. But to ensure that all finalized branches do not conflict with each other, i.e. security, we need to have a continuous chain of finalizations starting from the genesis block. This requires that the votes of the voters can also be coherent. For this reason, we have modified the voting rules just now and added to the original rules:

Each vote needs to be connected forward to his previous vote, called "source". A vote that does not connect to a source is called a "passive vote", which acts as a correction to a wrong vote and has no weight, but can be used as a source by subsequent votes. Passive voting can appear in the same cycle as sourced voting, but it also needs to abide by the previous voting rules, otherwise it will also be punished;

The genesis block is the first finalized block, which can be used as a source by subsequent votes without violating other rules;

The vote whose source is located in the final block is called "rooted vote". Only the "rooted vote" has weight and correctness, thus generating subsequent final blocks progressively. All ancestor blocks before the final block are also regarded as finalized. . "Rooted voting" can be passed backwards; as shown in Figure 4, solid blocks indicate terminated blocks, light solid lines indicate rooted voting, and dark dashed lines indicate rootless voting. So his voting chain was broken. As shown in Figure 5, continuing the situation in Figure 4, when node b becomes the final block, the vote behind the voter becomes a rooted vote, and the voting chain is reconnected. The principle of ensuring that votes do not conflict is very simple: because each vote of a voter can only be connected to his previous vote, if there are conflicting votes, they cannot be kept end-to-end on a chain, and the voting chain will not conflict. Since the voting chains of a single voter will not conflict, the endpoints generated based on the continuous voting chain will not conflict, thus ensuring security. As shown in Figure 6, only a continuous voting chain can finalize blocks.

Preferably, in any of the above embodiments, step 5 further includes:

The first preset period is:

n+1 periods, n is a positive integer;

The key forks are as follows:

A fork that cannot continue to terminate.

It should be noted that after a fork occurs, it is very likely that more than 1/3 of the votes will be cast to the wrong branch. Once this happens, the finalization chain will be broken and cannot be recovered. Therefore, it is more complicated to ensure liveness: first, we must be able to detect this situation - called "critical fork"; then allow the source of the next vote to go back from the current voting position to the fork, and give the voter A space for repentance, so that they can correct their previous decisions in time and return to the main chain; finally, the final position is also postponed to the fork.

To be able to detect key forks, some adjustments have to be made to the finalization condition. The previous condition was that a branch "receives more than 2/3 of the total number of votes within a voting cycle" to "receives more than 2/3 of the total number of votes within a voting cycle" 2/3 of the votes, and the voting targets of these votes are less than two cycles away from the source", in other words, the branch elected by consecutive votes (less than two cycles apart) can be terminated. This termination condition concentrates all the sources of votes that can generate termination within the range of two cycles before the termination point, so that it is only necessary to check in this range to see if there are enough votes, as shown in Figure 7 , the voting target that satisfies the termination condition of block b is concentrated on the 1-cycle long branch where b is a more node, and the source is concentrated on the 2-cycle long chain before a.

Preferably, in any of the above embodiments, step 5 further includes:

Preferably, in any of the above embodiments, the setback point block obtained by the backtracking algorithm is specifically:

The backtracking algorithm is specifically:

The retracement point block is specifically:

Blocks with height h-I.

It should be noted that, after detecting the key fork, we use a backtracking algorithm to find the fork point and its corresponding estoppel period:

When a block a of height h is generated, we use a natural number I to represent the temporary "retroversion period" at the position of a. The block of height h-I is called the temporary "retracement point", and the retraction point is usually equivalent to a fork. point. The value of I is based on the following calculation results:

1) When the number of votes obtained on the chain before a (including a) in the two voting cycles exceeds 2/3 of the total votes, I=0, and the same voter only counts the last vote;

2) When the above number of votes is less than or equal to 2/3 of the total votes, all the votes with the target height of h are backtracked to the height h-1, and then all the votes with the target height of h-1 are backtracked forward to h-2, By analogy, when backtracking to height h-i, the condition 1) is satisfied, then n=I, since most of the votes for the block with height h are stored in the block with height h+1, so the above work In fact, it is done when the next block a' of a is generated, and the corresponding I value is also stored in a', but this does not affect the implementation of the algorithm, because a' must be early when n is used. generated. Further, "all votes targeted at height h" can be improved to "all votes saved at height h+1" and so on, so that those votes that were not recorded or delayed in the first time can be released. Calculate in.

3) The height of the temporary retracement point at position a cannot be lower than the height of the temporary retracement point 2 cycles before a; as shown in Figure 8, when more than one third of the votes fork at A, and the network happens to be here The worst case is when a fault occurs when all the voting information is lost, and it takes a detection length of time to detect the fork.

4) The actual retracement point of position a is taken from the earliest temporary retracement point in 2 cycles after position a (including a), and the actual reversal period I also comes from this; therefore, in the worst case, a block It needs to wait 2 cycles after it is generated before it can be terminated. But normally, as long as a chain after the block gets 2/3 of the votes before these 2 epochs, there will be no retracement point before it and can be terminated immediately.

Preferably, in any of the above embodiments, step 5 further includes: within the estoppel period, the end block is withdrawn to the withdrawal point block.

It should be noted that after the estoppel period is obtained, the process of voting withdrawal and block finalization is as follows:

Each vote of a miner can only use the target of his last vote or the block within I steps back (including I) as the source. The value of I is taken from the height of the target of this miner's last vote, and the actual retrogress period of the relevant chain. I, Miners who violate this rule will be punished, as shown in Figure 9, with estoppel period, vote withdrawal and endpoint advance. "The height of the last voting target" can be improved to "the last voting was at the position of the height -1 saved in this chain", which corresponds to the improvement of Article 2) of the backtracking algorithm; "This rule is violated on the relevant chain" in The "relevant chain" refers to the chain where the source and target in the voting record are located respectively. When the source and target of the vote are not on the same chain, the actual estoppel period at the source height on the two chains is obtained respectively, and then the shorter one is taken. one of.

Counting from the root, when a branch gets more than 2/3 of the total votes of the system within a voting cycle, and the distance between the source and the target in the voting records of these votes is less than 2 voting cycles, the end is satisfied. condition, but the final block is not necessarily the root node b of the branch, but the actual retracement point B at b.

According to this method, under normal (ideal) conditions, the I value is 0, which can be completed in about 2/3 of the voting cycle after the block is generated. Occasionally, some serious forks may continue for several days. period, but the overall time must be much less than two periods. In some cases where the network conditions are very poor or the voting is particularly scattered due to an attack, the fork can be detected in advance and the termination is delayed, the voting requirements are relaxed, the fault tolerance rate of the system is improved, and the system can be prevented from being swayed from side to side to extend the length of the fork. inactive due to malicious attacks. The branch weight calculation method mentioned by the way - instead of only counting the last vote like the LMD (Latest Message Driven) scheme, it is relatively troublesome to count each vote and vote on a periodic basis, also because doing so is right Such attacks have strong resistance.

A storage medium storing instructions, when a computer reads the instructions, the computer is made to execute a consensus method for chained periodic voting as described in any of the above.

An electronic device, comprising a memory, a processor and a program stored on the memory and running on the processor, the processor implements a chain type as described in any of the above when the processor executes the program Consensus method for periodic voting.

The reader should understand that in the description of this specification, reference to the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples", etc., is intended to incorporate the embodiment or example. A particular feature, structure, material, or characteristic described is included in at least one embodiment or example of the present invention. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and combine the different embodiments or examples described in this specification, as well as the features of the different embodiments or examples, without contradicting each other.

In the several embodiments provided in this application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the method embodiments described above are only illustrative. For example, the division of steps is only a logical function division. In actual implementation, there may be other division methods. For example, multiple steps may be combined or integrated into another A step, or some feature, can be ignored, or not performed.

If the above method 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 technical solution of the present invention is essentially or a part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium , including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes: U disk, removable hard disk, Read-Only Memory (ROM, Read-Only Memory), Random Access Memory (RAM, Random Access Memory), magnetic disk or optical disk and other media that can store program codes.

The above are only specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily think of various equivalent modifications or modifications within the technical scope disclosed by the present invention. Replacement, these modifications or replacements should all be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention should be subject to the protection scope of the claims.

Claims

A consensus method for chain cycle voting, characterized in that it includes:

Step 1, get voting rights to become a miner;

Step 2, miners compete to generate blocks by generating random numbers, and the probability of block generation is proportional to the votes held by miners;

Step 3: Miners periodically vote on blocks;

Step 4, select the main chain according to the voting results;

Step 5: In the main chain, the blocks that meet the termination conditions are terminated to complete the consensus.
A consensus method for chained periodic voting according to claim 1, wherein step 1 is specifically:

When the stakeholder chooses to abstain from voting, the abstention record is published. When the stakeholder does not choose to abstain from voting and the first preset condition is met, a vote is generated and the voting right is obtained, and the stakeholder who has obtained the voting right becomes a miner;

Wherein, the first preset condition is:

VRF_VoteProof < Account_stakes

Among them, Account_stakes is the account equity, and VRF_VoteProof is the random number generation function.
A consensus method for chain periodic voting according to claim 1, wherein step 4 is specifically:

Priority is compared for each branch chain according to weight, and the branch chain with the highest priority is used as the main chain;

Wherein, the weight is: the total number of votes obtained by the root node of a branch chain, all child nodes of the root node, and grandchild nodes of the root node;

The priority comparison is specifically:

Starting from the blocks common to the branch chains, the weight sums of the respective branch chains are calculated respectively, and the one with the highest weight sum is given priority.
The consensus method for chain periodic voting according to claim 1, wherein step 5 is specifically:

On the basis that the voting chain is not interrupted, the root node block of the branch chain that obtains more than two-thirds of the total votes is terminated as the final block, and the chain where the final block is located is the final chain to complete the consensus;

Wherein, the uninterrupted voting chain is specifically:

A miner's M-th voted block to N-th voted block contains at least one final block, wherein the miner's M-th vote to the miner's N-th vote are connected in sequence, N≥2, M≤ N.
The consensus method for chain periodic voting according to claim 4, wherein step 5 further comprises:

Based on the termination condition, determine whether there is a key fork in the first preset period;

Among them, the termination condition is specifically: the block that satisfies the continuous voting interval of no more than n cycles has the voting weight;

The first preset period is:

n+1 periods, n is a positive integer;

The key forks are as follows:

A fork that cannot continue to terminate.
A consensus method for chained periodic voting according to claim 5, wherein step 5 further comprises:

When the finalization chain is disconnected, return the source block of the next voting block to the retracement point block obtained through the backtracking algorithm;

Among them, the source block is the last voted block connected to the current vote.
A consensus method for chain periodic voting according to claim 6, characterized in that the retracement point block obtained by the backtracking algorithm is specifically:

The backtracking algorithm is specifically:

Count the number of votes obtained on the blockchain where the block is located in the first preset period before the current block, obtain the first total number of votes, and determine whether the first total number of votes is greater than two-thirds of the total number of votes , if it is, then the estoppel period I=0, if not, then retrospect the vote of the height h of the current block to the position of height h-1, recalculate the total number of the first votes, and judge the total number of the first votes Whether it is greater than two-thirds of the total number of votes, if so, the estoppel period I = 1, if not, merge the votes backdated to the height h-1 with the votes of the height h-1, backtracked to the height h For the position of -2, repeat the above process until the total number of first votes is greater than two-thirds of the total number of votes, and the estoppel period I=i is obtained, where i is the number of backtracking;

The retracement point block is specifically:

Blocks with height h-I.
The consensus method for chain periodic voting according to claim 7, wherein step 5 further comprises: within the estoppel period, the end block is withdrawn to the withdrawal point block.
A storage medium, wherein an instruction is stored in the storage medium, and when a computer reads the instruction, the computer is made to execute a chain cycle according to any one of claims 1 to 8 Consensus method for voting.
An electronic device, comprising a memory, a processor, and a program stored on the memory and running on the processor, characterized in that, when the processor executes the program, any one of claims 1 to 8 is implemented A consensus method for chained periodic voting described in item .