Consensus method and system for resisting recombination attack

Abstract

The invention provides an anti-recombination attack consensus method and system, and the method comprises the steps: carrying out the random leader election from verifiers through employing a verifiable random function constructed by a chain type random seed in each consensus process; the selected leader generates blocks, each verifier verifies the blocks after receiving the blocks of the round, and if the verification is passed, the corresponding blocks are sequentially put into a voting waiting sequence; each verifier obtains a voting waiting sequence and preferentially votes to the block with the minimum random binary hash sequence; and iteratively performing multiple rounds of voting, if the leader collects effective votes with a satisfactory number, generating a proof of a previous block and putting the proof into the block, and when two continuous blocks obtain the proof, reaching a final determined state. According to the method, chain recombination attacks can be resisted, it can be guaranteed that the block outlet sequence cannot be predicted, and meanwhile the leader election probability can be stable so as to reduce the block recombination rate.

Description

TECHNICAL FIELD

[0001] The present application belongs to the field of blockchain consensus, and particularly relates to a consensus method and system resisting reorganization attacks. BACKGROUND

[0002] The statements in this section merely provide background information related to the present application and do not necessarily constitute the prior art.

[0003] With the wide application of blockchain technology, the distributed consensus algorithm as the core mechanism of the security and availability of the blockchain system is widely studied. The current mainstream consensus mechanisms include Proof of Work (PoW), Proof of Stake (PoS) and its variants, such as Nakamoto consensus, Casper, Ouroboros, etc. In these consensus algorithms, the growth of the chain is realized by continuously appending new blocks, and the producers of the blocks (i.e. miners or validators) produce and broadcast blocks in the system according to certain probability or rules.

[0004] However, in many existing consensus mechanisms, the order of block producers has a certain predictability, which leads to the system being vulnerable to chain reorganization attacks (Reorg Attack). Chain reorganization attack is a type of attack that replaces the confirmed blocks on the main chain by constructing a competing chain (fork). Attackers initiate reorganization attacks by predicting block order, tamper with cross-chain transaction status (such as forging asset lock / release instructions), and cause cross-chain bridge smart contracts to execute incorrect operations. This attack can lead to event rollback, double spending, and contract state inconsistency, etc.

[0005] The current consensus algorithm has the following defects due to the above attacks: (1) The block order is predictable, and chain reorganization attacks are easy to occur, and cross-chain transaction status is easy to be tampered with; (2) The traditional leader selection scheme is mostly a probabilistic selection scheme, and the probability of no validator exceeding the threshold in a single round is relatively large, and if the election fails, the round is empty, which affects the continuity and performance of the consensus; (3) The random leader selection probability cannot be dynamically adjusted when the network fluctuates or the nodes are unstable or the security requirements are different, and lacks robustness. SUMMARY

[0006] In order to solve the above problems, the present application proposes a consensus method and system resisting reorganization attacks, which can resist chain reorganization attacks, ensure that the block order cannot be predicted, and stabilize the leader election probability to reduce the block reorganization rate.

[0007] According to some embodiments, the present application adopts the following technical solutions: A consensus method against recombination attack, comprising the following steps: In each round of consensus process, a verifiable random function constructed by chain random seed is used to conduct random leader election from verifiers; The elected leader generates a block, and each verifier receives the block of this round and verifies it, and if the verification is passed, the corresponding block is sequentially put into a voting waiting sequence; Each verifier obtains the voting waiting sequence and votes preferentially for the block with the smallest value in the random binary hash sequence; Iterative multi-round voting is performed, and if the leader collects a sufficient number of valid votes, the proof of the previous block is generated and put into the block, and when the consecutive two blocks obtain the proof, the final determination state is reached.

[0008] As an optional implementation, before consensus, it is assumed that the system has N nodes in total, has no more than f Byzantine attackers, and satisfies N≥3f+1; and an initial random seed is set , which is generated randomly or by trusted setting.

[0009] As an optional implementation, the process of random leader election from verifiers using a verifiable random function constructed by a chain random seed includes: Generating a verifiable random function key; Each verifier uses the random seed as input and performs verifiable random function calculation based on the verifiable random function key; Each verifier locally generates a hash value and proof using the verifiable random function calculation method , the hash value is regarded as an integer, and the hash value is converted to a floating-point number [0, 1) , by comparing the floating-point number with the leader selection probability to determine whether it is selected as the leader, and if it is less than the leader selection probability

[0010] , it is selected as the leader, and the output of the verifiable random function is encapsulated in the extra field of the block header and published with the block.As an alternative implementation, in the process of random leader election, if there is an empty election exceeding the set round, a multi-round verifiable random function is attempted, and in each round of each block, each verifier locally performs a multi-round verifiable random function calculation, each attempt uses different input, including the round, the seed of the previous round, for each attempt, the output is calculated, which is calculated according to the verifier key and the input, and it is checked whether the output is less than the leader selection probability, so that at least one leader is elected in each height under overwhelming probability, if any of the attempts meet the condition, the verifier becomes the leader, and the smallest output that meets the condition is selected as its output.

[0011] Further, in the process of each verifier locally performing a multi-round verifiable random function calculation, the number of rounds M calculation process includes:

[0012] Wherein, The probability of at least one of all verifiers being selected after the attempt is , The probability of a single verifier being selected in an attempt.

[0013] Further, by periodically adjusting the expected number of leader selections in a single round , the system determines the probability interval boundary of the leader to reduce the leader empty election rate, if the number of recent empty elections exceeds the set value, then increase ; On the contrary, if the number of leaders exceeds the set threshold, then reduce ; The adjustment formula of T is:

[0014] Wherein , is the adjustment amplitude, , is the weight value; The empty election rate is , the actual number of empty elections in 100 blocks / 100; The target number of leader selections is The actual total number of leaders in 100 blocks / 100.

[0015] As an alternative implementation, the verifiable random function constructed by the chain random seed is ; Where H is a cryptographic hash function, the signature of the leader on the seed of the previous round, generate a random value as the input of the verifiable random function.

[0016] As an optional implementation, the content of the block generated by the leader includes the corresponding round, the transaction set, the random seed of the current round, the parent block hash, the timestamp and the additional field.

[0017] As an optional implementation, after the leader generates the block, the leader publishes the block after signing the block hash using the block signature private key.

[0018] As an optional implementation, the content of the block verified by each verifier includes: verifying the correctness of the leader's signature of the block, whether the height is continuous, whether the timestamp is within a reasonable interval, and the correctness of the random binary hash sequence of the verifiable random function.

[0019] As a further implementation, the process of verifying the correctness of the leader's signature of the block by each verifier includes: calculating the hash value using the same hash algorithm, and then performing mathematical verification using the signer's public key.

[0020] As a further implementation, when verifying the correctness of the random binary hash sequence of the verifiable random function, if the verification is passed, it is judged whether the size of the floating point number converted from the hash value meets the condition that the floating point number is less than the leader's selection probability , if it meets the condition, the block is passed and placed in the voting waiting sequence in the order of the random binary hash sequence from small to large, otherwise the block is abandoned.

[0021] As an optional implementation, when the verifier votes, each verifier obtains the voting waiting sequence, and after a waiting time of half the duration of the round, the block with the smallest random binary hash sequence is voted and broadcasted, and the voting content includes the direction of the vote and the hash and height of the source block, the hash and height of the target chain.

[0022] A consensus system resistant to recombination attacks, comprising: an election module configured to conduct random leader election from the verifiers using a verifiable random function constructed with a chain random seed in each round of consensus process; a block generation and verification module configured to generate a block by the elected leader, and each verifier receives the block of the round and verifies it, and if the verification is passed, the corresponding block is sequentially placed in the voting waiting sequence; a voting module configured to obtain the voting waiting sequence by each verifier, and preferentially vote for the block with the smallest random binary hash sequence; A consensus module is configured to iteratively perform multiple rounds of voting, generate a proof of a previous block and put the proof into the block when the leader collects a sufficient number of valid votes, and reach a final state when two consecutive blocks obtain the proof.

[0023] Compared with the prior art, the present application has the following beneficial effects: The present application uses a dynamic and unpredictable block generation order and a stable leader selection scheme based on a verifiable random function (VRF) and a probability model scheme, so that each verifier performs multiple rounds of VRF calculation at the block height, ensures that the leader selection at each height is approximately a deterministic algorithm, and uses an unpredictable random seed to enhance the input entropy, thereby completely avoiding the deterministic risk of rotation mode and eliminating pre-computation attacks; and solves the risk and block generation stability problem caused by partial reorganization attacks.

[0024] The present application solves the problem of reorganization attacks caused by predicted leaders in traditional rotating leader consensus protocols, improves the traditional VRF scheme, solves the problem that VRF cannot guarantee the stability of leader selection, changes the single leader determination of the traditional VRF to dynamic multiple rounds of attempts, realizes approximate deterministic block generation through a probability model, and can adjust the threshold in real time according to the network state, so that the system always converges to the target empty selection rate and the number of leader selection.

[0025] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the following preferred embodiments are described in detail below, and the accompanying drawings are used for explanation. BRIEF DESCRIPTION OF DRAWINGS

[0026] The drawings accompanying the specification of the present application serve to provide a further understanding of the present application, and the schematic embodiments of the present application and their descriptions serve to explain the present application and do not constitute an improper limitation on the present application.

[0027] Figure 1 It is a flowchart of an embodiment; Figure 2 It is a system architecture diagram of an embodiment; Figure 3 It is a dynamic threshold adjustment module running flowchart of an embodiment. DETAILED DESCRIPTION

[0028] The present application will be further described below in combination with the drawings and embodiments.

[0029] It should be pointed out that the following detailed description is exemplary and is intended to provide further explanation of the present application. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as generally understood by those skilled in the art to which the present application belongs.

[0030] It is to be noted that the terms used herein are merely for describing specific embodiments and are not intended to limit exemplary embodiments according to the present application. As used herein, the singular forms are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising," when used in this specification, specify the presence of stated features, steps, operations, elements, components, and / or combinations thereof, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof.

[0031] The embodiments in the present application and the features in the embodiments can be combined with each other without conflict.

[0032] Embodiment One A consensus algorithm resistant to recombination attacks is particularly used in a blockchain system with nodes, the participants of the system include the following roles: Validators: Nodes become validators to obtain the qualification of consensus participation with a certain reputation.

[0033] Responsible for participating in the consensus process, including proposing blocks, verifying new blocks, and participating in block voting.

[0034] At least one leader is randomly selected from active validators in each round to run the consensus algorithm, and the remaining validators only participate in block confirmation voting.

[0035] Leaders / Random Seed Maintainers: In each round of consensus, a validator is randomly selected by VRF to serve as a leader.

[0036] The leader is responsible for generating a new block and submitting its VRF output as "identity credentials".

[0037] Each leader is composed of a leader in each round, and each leader signs the last round seed to generate a new random seed, which is used as the random seed of the next round to prevent seed manipulation.

[0038] Among them, the leader is a subset of the validator, which is a specific role randomly selected from the validator through VRF. The validator is a set of nodes participating in consensus, which is the remaining nodes left after the election. The division of responsibilities: the leader leads the block generation, and the validator is responsible for consensus verification.

[0039] The technical solutions of the present application are as follows: a consensus algorithm resistant to recombination attacks, as shown in Figure 1 includes the following steps: 1. Initial setting (1) Construct a blockchain system. Assume that the blockchain system has N nodes (or clients), no more than f Byzantine attackers (i.e., nodes), and satisfies N ≥ 3f + 1.

[0040] This embodiment implements a consensus optimization algorithm on the blockchain system so that each node reaches a consensus.

[0041] (2) The initial random seed is set when the system starts , which is set by trust or generated randomly.

[0042] (3) The initial validator set is .

[0043] Iterate each round of consensus steps (round number is , the duration of a single round is ).

[0044] 2. Leader Selection The random selection of the leader is based on a Verifiable Random Function (VRF). VRF is a cryptographic primitive with the following characteristics: Randomness: Output unpredictable pseudo-random numbers Verifiability: Anyone can verify the authenticity of the result using the public key Uniqueness: For the same input and key, the output is always certain VRF workflow: 1) Generate VRF key: :in, The private key is kept secret by the user and is used to generate the random value of the VRF and the corresponding proof; It is a public key, which can be made public and used to verify the private key. The generated random value and the validity of the proof ensure the authenticity and unforgeability of the random value.

[0045] 2) Random number generation: Each validator uses a random seed as input , perform VRF calculation:

[0046] Among them, the output is a random binary hash sequence, Proof of this sequence.

[0047] 3) Public Verification: , 0 or 1.

[0048] Random Leader Election: Each validator locally generates a hash value using the VRF algorithm above and proof , which is treated as an integer, normalized by dividing by the size of the hash space ( ) to achieve normalization, through the formula:

[0049] Convert to a floating-point number in [0, 1) (better representation precision, left-closed and right-open) , by comparing with the leader selection probability to determine whether it is selected as a leader. If it is less than the leader selection probability, it is selected as a leader, and the output of the VRF is encapsulated in the extra field of the block header and published with the block.

[0050] 3. Block Proposal The leader generates a block , the content of which includes: height (round) ; transaction set ; The random seed of this round is generated by the leader signing the previous round seed , and if the previous round is empty, then .

[0051] parent block hash ; extra field: includes , proof, etc.

[0052] timestamp, difficulty, and other information.

[0053] After the block is generated, the leader signs the block hash using the block signature private key and publishes it:

[0054] 4. Block Verification Each validator receives the block and verifies it: (1) Verify the correctness of the block leader signature: calculate using the same hash algorithm: , then use the signer's public key to perform mathematical verification: ;​ (2) Verify whether the block height is continuous, the timestamp is within a reasonable interval, etc. (3) Verify the correctness of and , and if the size of the floating-point number after the hash value conversion is consistent with , the block is verified and put into the voting waiting sequence in ascending order . If not, the block is discarded.

[0055] 5. Validator voting (Voting) Each verifier gets the voting waiting sequence, waits for (half of the round duration) after which the smallest block (when there are multiple leaders, choose the smallest as the priority leader) is given priority voting and broadcast, where source and target represent the direction of the vote, source represents the hash and height of the source block, and target represents the hash and height of the target chain.

[0056] Here we want to talk about the round, how to handle the next round, from the perspective of consensus, it is not perfect, the next round of processing method needs to be fully explained, and the flowchart also needs to be reflected.

[0057] When exhausted, the round ends, and step 2 is repeated, growing to .

[0058] 6. Block confirmation (Finality) At the beginning of each round, the leader collects the votes of the previous height block, and when at least N-f valid votes are collected (f is the number of allowed faulty nodes), the proof of the previous block is generated and prepared to be put into the block, which contains the source block hash, target block hash, current round, etc. Key information.

[0059] When two consecutive blocks obtain proof, it reaches the "finality" state, and the finality block is irreversible, ensuring the consistency of the blockchain.

[0060] For the case of multiple rounds of empty selection (no random value of any verifier meets the conditions) in the leader election (Leader Selection), the present invention designs a multi-round VRF attempt scheme.

[0061] ​​In a multi-round VRF process: in each block height (round), each verifier can locally perform multiple VRF calculations (e.g. times). Each attempt uses a different input: = , where is the height, is the previous height seed, . For each attempt, compute , where is the verifier key, and check if the condition is satisfied: , where is the leader selection probability, such that at each height, at least one leader is elected with overwhelming probability (i.e. , is the system tolerated error probability, ). If any of the attempts satisfies the condition, the verifier becomes the leader and selects the smallest that satisfies the condition as its output.

[0062] As shown in Figure 2 , in the above multi-round VRF attempt (Multi-Round VRF) scheme, the value of can be dynamically calculated according to the preset system tolerated error probability (i.e. ). The calculation method of is described as follows.

[0063] Adjust the number of attempts : if the probability of a single verifier being selected in an attempt is , the probability of not being selected in an attempt is , then the probability of not being selected after attempts is , then the probability of verifiers being empty is reduced from to . The present application requires that the probability of at least one of all verifiers being selected after attempts (i.e. the probability of the system generating a leader) is . This probability can be calculated by the following formula:

[0064] where, , and simplified as:

[0065] The calculation method of is as follows:

[0066] Anti-predictable random seed generation method: Seed generation adopts a chain strategy, and the current high random seed is generated by the previous block seed, that is:

[0067] wherein H is a password hash function, is the signature of the leader on the seed of the previous round. The random value can be generated as the input of the VRF function.

[0068] In multi-round VRF attempts, as shown in Figure 3 , the value of the number of calculations needs to be ensured to be an integer, thus causing a certain error in the selection of the probability interval. At the same time, in order to maintain the stability of the block, it is necessary to balance between the low empty selection rate and the low fork probability, and the selection of is adjusted by the module. Let , wherein represents the expected number of leader selections of a single height, and the initial value is 1. The present application can control the probability interval boundary of the system to determine the leader by periodically adjusting to reduce the empty selection rate of the leader. For example, if the number of empty selections appears too much in the recent period, then is appropriately increased (i.e., the condition is relaxed); on the contrary, if multiple leaders (forks) appear, then is reduced.

[0069] In a real system, it can be periodically called with the height self-growth. After each consensus process is ended, it is judged whether the current height taken modulo 100 is 0, and if yes, the module is called. The following parameters are counted each time the module is called: let be the empty selection rate, be the actual number of empty selections in 100 blocks / 100; be the target number of leader selections, be the actual total number of leaders in 100 blocks / 100, then the adjustment formula of is:

[0070] wherein , is the adjustment amplitude, , recommended value (which can be adjusted according to the demand): High security scenario: =0.2, =0.05; High performance scenario: =0.1, =0.1; Boundary limit protection, Recommended value (can be adjusted according to requirements): Lower limit: prevent the system performance from being affected by too large empty selection rate, ; Upper limit: prevent frequent block reorganization caused by too many leaders, .

[0071] Embodiment two A consensus system resistant to reorganization attacks, comprising: An election module configured to perform random leader election from the verifiers in each round of consensus process by using a verifiable random function constructed with a chain random seed; A block generation and verification module configured to generate a block by the elected leader, and each verifier verifies the block after receiving the block of this round, and if the verification is passed, the corresponding block is sequentially put into a voting waiting sequence; A voting module configured to make each verifier obtain the voting waiting sequence and vote preferentially for the block with the smallest random binary hash sequence; A consensus module configured to iteratively perform multiple rounds of voting, and if the leader collects a sufficient number of valid votes, generate a proof of the previous block and put it into the block, and when two consecutive blocks obtain the proof, reach a final determination state.

[0072] Those skilled in the art will understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, optical storage, etc.) containing computer-usable program code. CD - ROM

[0073] The present application is described with reference to flowcharts and / or block diagrams of the method, device (system), and computer program product according to the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of the flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device that implements the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions specified in one flow or multiple flows and / or blocks Figure 1 The functions specified in one flow or multiple flows and / or blocks​

[0074] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the flow Figure 1 one or more flow or blocks and / or blocks Figure 1 one or more flow or blocks and / or blocks

[0075] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions that are executed on the computer or other programmable apparatus provide steps for implementing the flow Figure 1 one or more flow or blocks and / or blocks Figure 1 one or more flow or blocks and / or blocks

[0076] The above description is only preferred embodiments of the present application and is not intended to limit the present application. The present application can be variously changed and modified by those skilled in the art without departing from the spirit and scope of the present application. Any modification, equivalent replacement, improvement, etc. made by those skilled in the art without departing from the spirit and scope of the present application should be included in the scope of the present application.

Claims

1. A consensus method resistant to reorganization attacks, characterized by: The following steps are involved: In each round of consensus, a verifiable random function constructed using a chained random seed is used to randomly elect a leader from the validators. The elected leader generates a block. After receiving the block of this round, each validator verifies it. If the verification passes, the corresponding block is sequentially placed in the voting waiting queue; Each validator obtains a voting waiting sequence and preferentially votes for the block with the smallest random binary hash sequence; Multiple rounds of voting are performed iteratively. If the leader collects a sufficient number of valid votes, a proof of the previous block is generated and placed in the block. When two consecutive blocks obtain proof, the final state is reached.

2. A consensus method for resisting reorganization attacks as claimed in claim 1, characterized in that: The process of random leader election from validators using a verifiable random function constructed with a chained random seed includes: Generate a verifiable random function key; Each verifier uses the random seed as input and performs a verifiable random function calculation based on the verifiable random function key; Each validator generates a hash value locally using a verifiable random function calculation method and proof , the hash value Treated as an integer, normalized, and the hash value Convert to a floating point number in [0,1) , by comparing floating point numbers and leader selection probability Determine whether you are selected as the leader. If it is less than , it means you are selected as the leader, and encapsulate the output of the verifiable random function in the extra field of the block header and publish it with the block.

3. A consensus method for resisting reorganization attacks as claimed in claim 1, characterized in that: During the random leader election process, if there are more than the set number of empty elections, multiple rounds of verifiable random function attempts are performed. In each block round, each validator locally performs multiple rounds of verifiable random function calculations, using different inputs for each attempt. The input includes the seeds of this round and the previous round. For each attempt, the output is calculated based on the validator key and the input, and it is checked whether the output is less than the leader selection probability, so that at least one leader is selected at each height with an overwhelming probability. If any of the attempts meets the conditions, the validator becomes the leader and selects the smallest output that meets the conditions as its output.

4. A consensus method for resisting reorganization attacks as claimed in claim 3, characterized in that: Each verifier performs multiple rounds of verifiable random function calculations locally. The calculation process for the number of rounds M performed includes: in, The probability that at least one of all validators is selected after attempts is , is the probability of a single validator being selected in one attempt.

5. A consensus method for resisting reorganization attacks as claimed in claim 4, characterized in that: By periodically adjusting the expected number of leader selections in a single round , to control the probability interval boundary of the system to determine the leader to reduce the leader empty selection rate. If the number of empty selections in the recent period exceeds the set value, the ; On the contrary, if the number of leaders exceeds the set threshold, the ; The adjustment formula for T is: in , To adjust the amplitude, , is the weight; is the empty selection rate, The actual number of empty selections in 100 blocks / 100; Select the number of target leaders. It is the total number of leaders in the actual 100 blocks / 100.

6. A consensus method for resisting reorganization attacks as claimed in claim 1, characterized in that: The verifiable random function constructed using chained random seeds is: the random seed of the current round is generated by the seed of the previous block, that is, ; Where H is a cryptographic hash function, The leader's signature on the previous round's seed, Generates a random value as input to a verifiable random function.

7. A consensus method for resisting reorganization attacks as claimed in claim 1, characterized in that: When a leader generates a block, the block content includes the corresponding round, transaction set, random seed of this round, parent block hash, timestamp, and additional fields; After the leader generates a block, the leader uses the block signature private key to sign the block hash and then publishes it. Verify the correctness of the block leader's signature, whether the height is continuous, whether the timestamp is within a reasonable range, and verify the correctness of the random binary hash sequence of the random function; The process by which each validator verifies the correctness of the block's leader's signature involves calculating a hash value using the same hash algorithm, followed by mathematical verification using the signer's public key.

8. A consensus method for resisting reorganization attacks as claimed in claim 7, characterized in that: When verifying the correctness of the random binary hash sequence of the verifiable random function, if the verification passes, the floating point number after the hash value conversion is judged Is the size of a floating point number consistent with Less than the leader selection probability If it meets the requirements, the block will pass the block verification and be placed in the voting waiting sequence in ascending order according to the random binary hash sequence. If it does not meet the requirements, the block will be abandoned.

9. A consensus method for resisting reorganization attacks as claimed in claim 1, characterized in that: When validators vote, each validator obtains a voting waiting sequence. After waiting for half the round duration, it will give priority to voting for the block with the smallest random binary hash sequence and broadcast it. The voting content includes the direction of the vote, the hash and height of the source block, and the hash and height of the target chain.

10. A consensus system resistant to reorganization attacks, characterized by: include: The election module is configured to randomly elect a leader from the validators during each consensus round using a verifiable random function constructed from a chained random seed. The block generation and verification module is configured to generate blocks for the elected leader. After each validator receives the block of the round, it verifies it. If the verification passes, the corresponding block is sequentially placed in the voting waiting queue; The voting module is configured to obtain a voting waiting sequence for each validator and give priority to voting for the block with the smallest random binary hash sequence; The consensus module is configured to iterate multiple rounds of voting. If the leader collects a sufficient number of valid votes, it generates a proof of the previous block and puts it into the block. When two consecutive blocks obtain proof, the final state is reached.

Images