Blockchain consensus method, device and system based on verifiable random selection

Abstract

The application discloses a blockchain consensus method, device and system based on verifiable random selection. The blockchain consensus method based on verifiable random selection comprises the following steps: obtaining a node block packaging sequence through calculation, and obtaining a block node in a current round according to the node block packaging sequence, so that distributed nodes in the network do not need to exchange information through multiple rounds of communication, and do not need to consume too many resources to compete for block packaging. In addition, a construction block of a new block is obtained through a fork selection calculation, so that the distributed nodes in the network can select blocks in the same rule, the blockchain consensus is converged, resource consumption is reduced, and the number of supported nodes is increased.

Description

Technical Field

[0001] This invention belongs to the field of blockchain consensus technology, specifically relating to a blockchain consensus method, apparatus, and system based on verifiable random selection. Background Technology

[0002] Currently, blockchain technology is developing rapidly. As a decentralized distributed database technology, blockchain uses a consensus mechanism to ensure the consistency of nodes in the blockchain network. Therefore, the consensus algorithm can affect the speed at which the entire blockchain network system achieves uniformity. To reduce the occurrence of system forks, public blockchains use proof-based consensus algorithms such as Proof of Work (POW) and Proof of Stake (POS) to compete for block production. However, these consensus algorithms have the disadvantages of slow consensus speed and extremely high resource overhead. Consortium blockchains commonly use consensus mechanisms such as Practical Byzantine Fault Tolerance (PBFT), Raft (Reliable, Replicated, Redundant, and Fault-Tolerant) consensus protocol, and Paxos algorithm. Although these algorithms have a certain degree of efficiency improvement compared to public blockchain consensus algorithms, in order to ensure system security, the communication complexity required for consensus is high and the resource overhead is large, which cannot support a large number of consensus nodes. Secondly, the consensus algorithms used by public and consortium blockchains have high requirements for the operating medium, requiring powerful computing power or sufficiently fast bandwidth to meet the requirements of consensus. This makes it impossible for devices with low computing power or low network capabilities to participate in consensus due to insufficient hardware conditions.

[0003] To achieve the technical goals of low resource overhead, support for a large number of nodes, and low communication complexity in consensus, existing technologies have proposed the Rotation Practical Byzantine Fault Tolerance (RPBFT) protocol. This involves randomly selecting a subset of nodes as "consensus committee nodes" to participate in each round of PBFT consensus. Since the number of consensus committee nodes is fixed and independent of node size, the RPBFT consensus algorithm offers greater scalability. However, its essence remains PBFT; it simply selects "consensus committee nodes" from a large number of nodes. Communication complexity remains high, and selecting "consensus committee nodes" can centralize consensus, potentially leading to system insecurity. Summary of the Invention

[0004] To address the aforementioned problems in the prior art, this invention provides a blockchain consensus method, apparatus, and system based on verifiable random selection.

[0005] The technical problem to be solved by this invention is achieved through the following technical solution:

[0006] In a first aspect, the present invention provides a blockchain consensus method based on verifiable random selection, comprising:

[0007] S1. Utilize nodes to create a genesis file and initiate consensus before reaching the Unix timestamp; the genesis file contains: Unix timestamp, block production time, and request election transactions, and each node creates the same genesis file;

[0008] S2. Read the request election transactions through the nodes and sort the request election transactions according to the preset rules to obtain the node's block production order;

[0009] S3. The node obtains the block-producing node of the current round by using the block-producing order of the nodes;

[0010] S4. The block-producing node in the current round performs fork selection calculations according to its own ledger content to obtain the construction block of the new block, and the non-block-producing nodes in the current round simultaneously broadcast their own request to elect transactions according to the block production time.

[0011] S5. The block-producing node in the current round verifies the request election transactions of non-block-producing nodes, and packages the verified request election transactions into the construction block of the new block to generate the packaged construction block.

[0012] S6. Increment the round number of the current round by 1. The result of the increment is the round number of the current round. Sort the request election transactions packaged in the previous preset rounds according to the preset rules in S2 to obtain the block packaging order of the nodes in the current round.

[0013] S7. Repeat steps S3-S6 until the preset number of rounds is reached.

[0014] Optionally, the method of using nodes to create a genesis file and, after initiating consensus before reaching the Unix timestamp, based on a verifiable, randomly selected blockchain consensus method, also includes:

[0015] All nodes authenticate and connect via a two-way authentication method using an SSL handshake.

[0016] Optionally, the node reads the election request transactions and sorts them according to preset rules to obtain the node's block production order, including:

[0017] The node reads the request election transactions and generates a first preset list of the request election transactions;

[0018] The node checks the penalized status of the initiating node according to the first preset list;

[0019] When the initiating node is in a penalized state, the initiating node is removed from the first preset list, and the second preset list is obtained;

[0020] The second preset list is sorted in descending order using random numbers from the second preset list to obtain the order in which nodes are packaged into blocks.

[0021] Optionally, the block-producing node in the current round performs fork selection calculations based on its own ledger content to obtain the constructing block of the new block, including:

[0022] Get the list of blocks with the highest height in the ledger content corresponding to the block-producing node in the current round;

[0023] From the list of blocks with the highest height in the ledger content, index the list of blocks with the largest index value to obtain the third list;

[0024] Determine the number of blocks in the third list;

[0025] When the number of blocks in the third list is 1, the block with the largest index value is used as the building block of the new block.

[0026] Optionally, after determining the number of blocks in the third list, the blockchain consensus method based on verifiable random selection further includes:

[0027] If the number of blocks in the third list is not 1, then a block is randomly selected as the building block of the new block using the VRF algorithm.

[0028] Optionally, after repeatedly executing steps S3-S6 until a preset number of rounds, the blockchain consensus method based on verifiable random selection further includes:

[0029] Determine the number of packaged construction blocks with the largest index value among the packaged construction blocks generated in the preset number of rounds;

[0030] When the number of packaged building blocks is 1, it is confirmed that all packaged building blocks meet the deterministic judgment when the preset number of rounds is reached; among them, the packaged building blocks that meet the deterministic judgment will not generate rollback processing.

[0031] Optionally, after the block-producing nodes in the current round verify the election transactions requested by non-block-producing nodes, the blockchain consensus method based on verifiable random selection also includes:

[0032] The block-producing node in the current round penalizes the election transactions of non-block-producing nodes that have not passed verification, so that non-block-producing nodes that have not passed verification are not allowed to produce blocks in the current round and in the preset rounds after the current round.

[0033] Secondly, the present invention provides a blockchain consensus device based on verifiable random selection, comprising: a creation unit, a sorting unit, an acquisition unit, a calculation unit, a verification unit, and a circulation unit;

[0034] S1, the creation unit is used to create a genesis file using nodes and to initiate consensus before the Unix timestamp is reached; the genesis file contains: Unix timestamp, block production time, and request election transaction, and the genesis file created by each node is the same;

[0035] S2, the sorting unit is used to read the request election transactions through the node and sort the request election transactions according to the preset rules to obtain the node's block packaging order;

[0036] S3. The acquisition unit is used to obtain the block-producing node of the current round by utilizing the block-producing order of the nodes;

[0037] S4, the calculation unit is used to enable the block-producing node of the current round to perform fork selection calculation according to its own ledger content to obtain the construction block of the new block, and the non-block-producing node of the current round to broadcast its own request for election transaction according to the block production time.

[0038] S5. The verification unit is used to verify the request election transactions of non-block-producing nodes using the block-producing nodes in the current round, and to package the verified request election transactions into the construction block of the new block to generate the packaged construction block.

[0039] S6. The sorting unit is also used to add 1 to the number of rounds in the current round, and use the result of adding 1 as the number of rounds in the current round. The request election transactions packaged in the previous preset number of rounds are sorted according to the preset rules in S2 to obtain the block packaging order of the nodes in the current round.

[0040] S7, the loop unit is used to repeatedly execute steps S3-S6 until the preset number of rounds.

[0041] Thirdly, the present invention provides a blockchain consensus system based on verifiable random selection, comprising: a processor, a storage medium and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the system is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the method described in the first aspect.

[0042] Fourthly, the present invention provides a storage medium storing a computer program, wherein the computer program, when run by a processor, executes the steps of the method described in the first aspect.

[0043] This invention provides a blockchain consensus method, apparatus, and system based on verifiable random selection, comprising: S1, using nodes to create a genesis file and initiating consensus before reaching the Unix timestamp; wherein, the genesis file contains: Unix timestamp, block production time, and request election transactions, and each node creates the same genesis file; S2, reading request election transactions through nodes and sorting the request election transactions according to preset rules to obtain the node block production order; S3, nodes using the node block production order to obtain the block-producing node for the current round; S4, the block-producing node for the current round performs fork selection according to its own ledger content. The calculation process involves obtaining the new block's construct block, and simultaneously broadcasting the election request transactions of the non-block-producing nodes in the current round according to their block production time. Step 5: The block-producing node in the current round verifies the election request transactions of the non-block-producing nodes and packages the verified transactions into the new block's construct block, generating a packaged construct block. Step 6: The round number of the current round is incremented by 1, and the resulting increment is used as the current round number. The election request transactions packaged for previous rounds are then sorted according to the preset rules in Step 2 to obtain the node block production order for the current round. Step 7: Steps S3-S6 are repeated until the preset round number is reached. By calculating the node block production order and obtaining the block-producing node for the current round according to this order, distributed nodes in the network do not need to exchange information through multiple rounds of communication, nor do they need to consume excessive resources to compete for blocks. Furthermore, by using fork selection calculation to obtain the new block's construct block, it ensures that distributed nodes in the network can select blocks using the same rules, promoting blockchain consensus and convergence, reducing resource overhead, and increasing the number of supported nodes.

[0044] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0045] Figure 1 A flowchart illustrating a blockchain consensus method based on verifiable random selection, provided in an embodiment of the present invention.

[0046] Figure 2 A schematic diagram of the bifurcation selection algorithm provided in an embodiment of the present invention;

[0047] Figure 3 A schematic diagram of a blockchain consensus device based on verifiable random selection provided in an embodiment of the present invention;

[0048] Figure 4 This is a schematic diagram of a blockchain consensus system based on verifiable random selection, provided as an embodiment of the present invention. Detailed Implementation

[0049] The present invention will be further described in detail below with reference to specific embodiments, but the implementation of the present invention is not limited thereto.

[0050] To illustrate in detail the blockchain consensus method based on verifiable random selection provided in the embodiments of the present invention, the model assumptions, symbol descriptions, etc., are described in detail here.

[0051] Model assumptions

[0052] 1. Consortium blockchains are admission-permitted for nodes, and each node has a unique identity. There is no Sybil attack, meaning that one person cannot control two or more fake identities (nodes).

[0053] 2. The network is semi-synchronous, meaning that information can be transmitted and synchronized throughout the entire blockchain network within a certain period of time.

[0054] 3. The number of malicious nodes is limited and cannot exceed half of the total number of nodes in the network. Furthermore, it is assumed that the behavior of malicious nodes primarily involves: responding, not responding, and responding with false information.

[0055] Symbol description

[0056] This invention uses typographical conventions to represent symbols in formulas, some of which require special explanation.

[0057] For functions that may be externally defined, their names are represented in all uppercase. For example, SORT represents the sorting function, NOW represents the current Unix timestamp function, KEC represents the Keccak-256 hash function, and ECDSA_EMSA1_SHA_256 represents the ECDSA signature function that uses the Keccak-256 hash function as the message digest generation function.

[0058] Tuples are typically represented using an uppercase letter, such as B for a block. All components of a tuple are enclosed in angle brackets, for example, using...<header,transactions,votes,punishes> The tuple is used to represent all the parts that make up a block B. A single component of a tuple is represented using a dot, for example, B.header represents the block header of block B. The subscript of a tuple is usually set to distinguish it from other identical tuples; for example, B1 and B2 are two different blocks.

[0059] Lists are typically represented using bold uppercase letters and enclosed in parentheses. For example, B represents a list of blocks consisting of blocks B, and (B1, B2, ..., B...) represents a list of blocks. n Let ) represent a block list B consisting of n blocks.

[0060] Unless otherwise stated, scalars are represented by a sequence of characters that begin with a lowercase letter and contain only letters, such as the timestamp of transaction T.

[0061] In this embodiment of the invention, scalars are considered to be positive integers belonging to set N, and all byte sequences belong to set N. The limited length of such a set of sequences can be indicated by subscripts; therefore, all sequences longer than 2... 256 Small positive integers use This indicates that a byte sequence of length 32 uses express.

[0062]

[0063]

[0064] In the embodiments of the present invention, the symbols used are described as follows:

[0065] 1. P: The private key in an asymmetric encryption system.

[0066] 2.D: The public key in an asymmetric encryption system.

[0067] 3. N(p): The node with private key p. A node is a network device with a certain computing power.

[0068] 4. N(d): The node with public key d.

[0069] 5. Nodes(t): The set of nodes in the network that the current system is connected to at time t, Nodes(t) ≡ {N(p1), N(p2), N(p3), ..., N(p... m )}

[0070] 6.T: Transaction. A single cryptographically signed instruction.

[0071] In this invention, there are three types of transactions:

[0072] 1)T C : Ordinary transaction.

[0073] 2)T V Request for an election deal.

[0074] 3)T P : Punishment evidence transactions. These transactions contain evidence that other nodes have produced blocks repeatedly, and are used to assist the network in punishing malicious nodes.

[0075] These three types of transactions share some common fields:

[0076] 1) timestamp: The Unix timestamp of the moment the transaction was constructed.

[0077] 2) key: Creator's public key. The creator uses the private key corresponding to the key to digitally sign the transaction.

[0078] 3) Signature: Digital signature. The creator uses the private key corresponding to the key to digitally sign the transaction and stores the digital signature in the signature.

[0079] 4) hash: The Keccak-256 hash value of the transaction itself after serialization.

[0080] T C Transactions can also include more content, and the transaction load can be determined by specific business requirements.

[0081] Right now:

[0082] T C ≡<timestamp,key,signature,hash> (3)

[0083] T V The transaction also includes the following:

[0084] 1) number: Pseudo-random number. A pseudo-random number generated by the VRF random number generator.

[0085] 2) proof: proof. Proof generated by the VRF random number generator.

[0086] Right now:

[0087] T V ≡<timestamp,key,signature,hash,number,proof> (4)

[0088] T P The transaction also includes the following:

[0089] 1) height: Height of the evidence block.

[0090] 2)suspectKey: The public key of the block-producing node being reported.

[0091] 3) evidence: tuple, evidence of a node producing duplicate blocks.

[0092] Right now:

[0093] T P ≡<timestamp,key,signature,hash,suspectKey,evidence> (5)

[0094] in,

[0095] evidence≡<block1.hash,block1.signature,block2.hash,block2.signature> (6)

[0096] 7. BH: Block Header. It is a collection of relevant information fragments. The information contained in the block header includes the following:

[0097] 1) timestamp: The Unix timestamp at the moment the block was constructed.

[0098] 2) key: Creator's public key. The creator uses the private key corresponding to the key to digitally sign the transaction.

[0099] 3) Signature: Digital signature. The creator uses the private key corresponding to the key to digitally sign the transaction and stores the digital signature in the signature.

[0100] 4) hash: The Keccak-256 hash of the block itself after serialization.

[0101] 5) parentHash: Keccak-256 hash of the parent block.

[0102] 6) height: Block height. The height of this block in the genesis block is 1.

[0103] 7) index: The number of ancestors of the current block. The number of indexes for the genesis block is 1.

[0104] extraData: Any bytes of data related to the current block, but must be within 32 bytes.

[0105] Right now:

[0106] BH≡<timestamp,key,signature,hash,parentHash,height,index,extraData> (7)

[0107] 8.B: Block. A block consists of the following parts:

[0108] 1) header: tuple BH, block header.

[0109] 2) Transactions: A list of ordinary transaction sets.

[0110] That is, transactions≡(T) C1 ,T C2 ,T C3 ,…)

[0111] 3) votes: a list requesting the set of vote transactions.

[0112] That is, votes≡(T) V1 ,T V2 ,T V3 ,…)

[0113] 4) Punishments: A list of transactions for which evidence of punishment exists.

[0114] That is, punishments≡(T) P1 ,T P2 ,T P3 ,…)

[0115] Right now:

[0116] B≡<header,transactions,votes,punishes> (8)

[0117] 9. Pool <t>: The transaction pool that stores transaction type T. There are three types of transaction pools: Pool <T C >、Pool <T V >and Pool <T P >

[0118] 10.C: Block ledger, a list of blocks consisting of all blocks B stored in the node.

[0119] 11. lastHeight: The block height of the latest block after the previous consensus, with an initial value of 1.

[0120] 12. PunishRoundLeft(n): The number of rounds remaining before node n is penalized. The initial value is...

[0121] 13. PunishTimes(n): The number of times node n is penalized. The initial value is...

[0122] 14. round: The current consensus round number, initially set to 1.

[0123] 15. blockTime: The time each node has to produce a block, in seconds.

[0124] Validity and legality description

[0125] Transaction validity:

[0126] Ordinary trading T C The validity is defined as follows:

[0127]

[0128] Request election transaction T V The validity is defined as follows:

[0129]

[0130] Evidence Transaction T P The validity is defined as follows:

[0131]

[0132] Legality of the transaction:

[0133] Ordinary trading T C The legality of is defined as follows:

[0134] timestamp≤NOW()∧hash=KEC(T C )∧signature=ECDSA_EMSA1_SHA_256(T C (12)

[0135] Request election transaction T V The legality of is defined as follows:

[0136] timestamp≤NOW()∧hash=KEC(T V )∧signature=ECDSA_EMSA1_SHA_256(T V )∧VRF_Valid(key,number,proof) (13)

[0137] Punishment of evidence trading T P The legality of is defined as follows:

[0138] timestamp≤NOW()∧hash=KEC(T P )∧height>0∧signature=ECDSA_EMSA1_SHA_256(T P )∧evidence.block1.signature=ECDSA_EMSA1_SHA_256(evidence.block1.hash)∧evidence.block2.signature=ECDSA_EMSA1_SHA_256(evidence.block2.hash)∧evidence.block1∈C∧evidence.block2∈C (14)

[0139] Block header validity

[0140] The validity of the block header (BH) is defined as follows:

[0141]

[0142] Block validity:

[0143] Block B consists of a block header BH and some other parts.

[0144] In addition to the block header BH in block B needing to satisfy equation (15), the other parts of block B also need to satisfy:

[0145]

[0146] Block legality

[0147] The validity of block B is defined as follows:

[0148]

[0149] To reduce resource consumption while increasing the number of supported nodes, this invention provides a blockchain consensus method based on verifiable random selection. Figure 1 This is a flowchart illustrating a blockchain consensus method based on verifiable random selection, as provided in an embodiment of the present invention. Figure 1 As shown, blockchain consensus methods based on verifiable random selection include:

[0150] S1. Use nodes to create a genesis file and start consensus before reaching the Unix timestamp; the genesis file contains: Unix timestamp, block time, and request election transactions.

[0151] The genesis file created by each of these nodes is identical.

[0152] It should be noted that before the consensus process begins in this embodiment of the invention, that is, before the formal network formation, all nodes have not yet started.

[0153] Genesis document creation: During the creation of the genesis document, the k nodes (consortium members) that will soon launch the consensus network need to generate a request for election transaction T. V The request election transaction set that constitutes the first round of block production. This set of transactions will be written into the genesis file as the transaction set for the next round of request election. Right now:

[0154]

[0155] The k nodes used to start the consensus network all hold the same genesis file. These k nodes need to be timestamped using a Unix timestamp (t). genesis Before starting the consensus nodes, these k nodes will connect via P2P networking. However, the nodes will not immediately begin consensus; instead, they will wait until t. genesis Consensus will only begin after time t. genesis At that moment, all nodes will start up and begin consensus.

[0156] S2. Read the request election transaction through the node, and sort the request election transaction according to the preset rules to obtain the node's block production order;

[0157] It should be noted that, in this embodiment of the invention, the step of reading the request election transaction through the node and sorting the request election transaction according to a preset rule to obtain the node's block production order includes:

[0158] The node reads the request election transaction and generates a first preset list of the request election transactions;

[0159] The node checks the penalized status of the initiating node according to the first preset list;

[0160] When the initiating node is in a penalized state, the initiating node is removed from the first preset list to obtain the second preset list;

[0161] The second preset list is sorted in descending order using random numbers from the second preset list to obtain the order in which the nodes are packaged into blocks.

[0162] It should be noted that in this embodiment of the invention, any node can act as an initiating node, but not all initiating nodes can act as block producing nodes.

[0163] In this embodiment of the invention, after consensus is initiated, the node from Extract all the transactions from the list and form a list T. V :

[0164]

[0165] For T V Each request election transaction in examine The penalized state of the initiating node; if it is in a penalized state, then... From T V Removed from the middle, meaning that nodes are not allowed in this round of consensus. Remove the block. Specifically, the T block after removal. V It should meet the following requirements:

[0166]

[0167] Definition of comparison Size method C:

[0168]

[0169] Method C for T V Sort in descending order:

[0170] T V =SORT(T) V ,C,DESC)#(22)

[0171] Take T in order V By examining all the keys in the list, you can obtain the block-producing order of the nodes in this round (public key order list) D:

[0172] D = Π key (T V )#(twenty three)

[0173] S3. The node obtains the block-producing node of the current round by using the block-producing order of the nodes;

[0174] S4. The block-producing node in the current round performs fork selection calculations according to its own ledger content to obtain the construction block of the new block, and the non-block-producing nodes in the current round simultaneously broadcast their own request to elect transactions according to the block production time.

[0175] Optionally, the current block-producing node performs fork selection calculations based on its own ledger content to obtain the constructing block of the new block, including:

[0176] Obtain the list of blocks with the highest height in the ledger content corresponding to the block-producing node of the current round;

[0177] From the list of blocks with the highest height in the ledger content, index the list of blocks with the largest index value to obtain the third list;

[0178] Determine the number of blocks in the third list;

[0179] When the number of blocks in the third list is 1, the block with the largest index value is used as the building block of the new block.

[0180] Figure 2 This is a schematic diagram of the bifurcation selection algorithm provided in an embodiment of the present invention, as shown below. Figure 2 As shown, there are four nodes in Part 1: Node 1, 2, 3, and Node 4 (hereinafter referred to as Node 1, 2, 3, and 4, respectively). Nodes 1, 2, and 3 have already locally known and stored blocks 0 through 3, while Node 4, for some reason, only knows and stores block 0. Now it's Node 4's turn to construct and broadcast the next block; it constructs block 4 based on block 0 and broadcasts it to the network. In Part 2, Nodes 1, 2, and 3 receive block 4, which was broadcast by Node 4 in Part 1, based on block 0. Similarly, other nodes in the network (such as Node 5) also receive block 4 based on block 0. Part 3 shows which block 5 should be built upon by node 5 in four different scenarios when block 5 needs to be constructed: Scenario 1: Node 5 has only blocks 0 and 4, so it should choose the longest chain, i.e., construct block 5 based on block 4; Scenario 2: Node 5 has two branches of the same length, so it should use the VRF random algorithm to randomly select which block to build block 5 based on (the result of the random selection can only be determined when the application is executed; the illustration only shows one possibility); Scenario 3: Node 5 has two branches, but the branch with blocks 0, 1, and 2 is the longest, so node 5 should choose the longest branch to build block 5, i.e., construct block 5 based on block 2; Scenario 4: Same as Scenario 3, node 5 should choose the longest branch to build block 5, i.e., construct block 5 based on block 3. Part 4 shows the choices made by a normally synchronized node (node ​​6 in the illustration) that needs to construct block 6, facing different scenarios of node 5 constructing blocks in Part 3: Scenario 1 and 2: Block 5 is constructed based on block 4. Node 6 has two branches, but the branch containing blocks 0, 1, 2, and 3 is the longest. Node 6 should choose the longest branch to construct block 6, i.e., construct block 5 based on block 3. Scenario 3: Block 5 is constructed based on block 2. Node 6 should have three branches, and two of them are the longest. In this case, a VRF random algorithm should be used to randomly select which of the two longest branches to construct block 6 from (the result of the random selection can only be determined during application execution; the illustration only shows one possibility). Scenario 4: Node 6 has two branches, but the branch containing blocks 0, 1, 2, 3, and 5 is the longest. Node 6 should choose the longest branch to construct block 6, i.e., construct block 6 based on block 5.

[0181] In this embodiment of the invention, after performing the above steps, all nodes obtain T. V Both len(T) and D are the same. Therefore, each node knows the next len(T). V ) blocks Each block B in i (lastHeight≤i≤lastHeight+len(T V )-1) will be given by the block-producing node N(Di) of the current round.

[0182] In this embodiment of the invention, each node has a block time of blockTime seconds. Therefore, the block time t of the i-th block... i Should meet

[0183] t i ∈[t genesis +(i-1)*BlockTime,t genesis +i*BlockTime]#(24)

[0184] Node N(D) i They will all be at time t i Build block B i B i Stored in the local block ledger C and broadcast to the entire network.

[0185] Block B i The construction is divided into two steps:

[0186] 1. Packaged Transaction. From the local regular transaction pool. <T C > Request the election transaction pool Pool <T V >and the penalty evidence trading pool <T P Extract all transactions T from the list. c T V and T P Write its three transaction lists into the block:

[0187] B i .transactions=T C #(25)

[0188] B i .votes=T V #(26)

[0189] B i .punishes=T P #(27)

[0190] 2. Construct the block header. Select parent block B using a fork selection algorithm. parent Construct the block header content:

[0191] B i .parentHash=B parent .hash#(28)

[0192] B i .index=B parent .index+1#(29)

[0193] B i .height=LastHeight+i#(30)

[0194] B i .timestamp=NOW()#(31)

[0195]

[0196] B i .hash = KEC(B i )#(33)

[0197] B i .signature=ECDSA_EMSA1_SHA_256(B o )#(34)

[0198] When the current time t has exceeded the time of the last block, i.e. t>t genesis +(lastHeight+len(T V When the block height reaches 1 - 1*BlockTime, the node determines that the current consensus round has ended. Let the highest block height stored by the node after the current consensus round ends be MaxHeight.

[0199] Optionally, after determining the number of blocks in the third list, the blockchain consensus method based on verifiable random selection further includes:

[0200] If the number of blocks in the third list is not 1, then a block is randomly selected as the building block of the new block using the VRF algorithm.

[0201] S5. The block-producing node in the current round verifies the request election transactions of non-block-producing nodes, and packages the verified request election transactions into the construction block of the new block to generate the packaged construction block.

[0202] S6. Increment the round number of the current round by 1. The result of the increment is the round number of the current round. Sort the request election transactions packaged in the previous preset rounds according to the preset rules in S2 to obtain the block packaging order of the nodes in the current round.

[0203] S7. Repeat steps S3-S6 until the preset number of rounds is reached.

[0204] This invention provides a blockchain consensus method based on verifiable random selection, comprising: S1, using nodes to create a genesis file and initiating consensus before reaching the Unix timestamp; wherein, the genesis file contains: Unix timestamp, block production time, and request election transactions, and each node creates the same genesis file; S2, using nodes to read request election transactions and sorting them according to preset rules to obtain the node block production order; S3, nodes using the node block production order to obtain the block-producing node for the current round; S4, the block-producing node for the current round performs fork selection calculations according to its own ledger content. The process involves several steps: S5, S6, S7, S8, S9, S10, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S2, S2, S3, S4, S5, S6, S7, S8, S9, S11, S2, S12, S3, S13, S4, S5, S6, S7, S8, S9, S14, S15, S16, S16, S17, S18, S18, S19, S10, S11, S12, S13, S14, S15, S16, S17, S18, S18, S19, S18, S19, S18, S19, S19, S11, S12, S13, S18, S19, S19, S11, S12, S13, S14, S19, S16, S19, S19, S19, S12 ...

[0205] In this embodiment of the invention, after one round of consensus is completed, preparations need to be made for the next round of consensus. The preparation process is as follows:

[0206] Round = Round + 1#(35)

[0207] LastRoundHeight=MaxHeight#(36)

[0208] Update the remaining number of rounds of penalty for the penalized node:

[0209]

[0210] In this embodiment of the invention, the number of rounds prior to the current round is preset to be R, wherein:

[0211]

[0212] It should be noted that in this embodiment of the invention, the formula is expressed with a preset number of rounds of 5. Further, in this embodiment of the invention, if the current consensus is the 10th round, then all blocks constructed by the 5 rounds of consensus before the 10th round can be obtained through formula (38); if the current consensus is the 2nd round, then all blocks constructed by the 2-5=-3th rounds of consensus cannot be obtained, so all blocks constructed by the 1st round of consensus are obtained.

[0213] Obtain block B constructed in the Rth round of consensus, and let

[0214] T Vnext =Π votes (B)#(39)

[0215] make

[0216] T P =Π punishes (B)#(40)

[0217] For T P Each legitimate penalty transaction in Execution of penalty procedures:

[0218] (1) Obtain the penalized node n o :

[0219]

[0220] (2) Record the punished behavior:

[0221] unishTimes(n o = PunishTimes(n i )+1#(42)

[0222] PunishRoundLeft(n i ) = 5 * (PunishRoundLeft(n i )+1)*PunishTimes(n i )#(43)

[0223] The block reception process includes: when a node receives block B from other nodes... r Next, its validity and legality need to be verified. If both verifications pass, then block B will be... r Write it into the constructor of the new block, which is the local ledger C.

[0224] The process of constructing a node penalty transaction includes: when node N(d k Block B r After writing to the local ledger C, node N(p) needs to check if block B exists in the local ledger C. k ∈C satisfies:

[0225]

[0226] If block B exists r If formula (44) is satisfied, then node N(d) k It is possible to construct a punitive evidence transaction.

[0227]

[0228] Where, d k Represents a public key, N(d) k ) indicates that the public key is d k The node.

[0229]

[0230]

[0231]

[0232]

[0233]

[0234] Will Store to local transaction pool <T P >and broadcast to the entire network.

[0235] The process of constructing a request for election transactions includes:

[0236] After each round of consensus, N(p) of all non-block-producing nodes that are not in a penalized state k Each of these requires constructing a request election transaction. And broadcast it across the entire internet. A request for an election trade. The construction method is as follows:

[0237] Node N(p) k Get the hash value of the last block in Round-1 and compare it with node N(p). k private key p k Both are input into the random number generator VRF_Generator to generate random numbers and proof:

[0238] proof,number=VRF_Generator(hash,p k )#(51)

[0239] Then construct the request election transaction.

[0240]

[0241]

[0242]

[0243]

[0244]

[0245] Will Store to local transaction pool <T V >and broadcast to the entire network.

[0246] Optionally, the method of using nodes to create a genesis file and, after initiating consensus before reaching the Unix timestamp, based on a verifiable, randomly selected blockchain consensus method, also includes:

[0247] All nodes authenticate and connect via a two-way authentication method using an SSL handshake.

[0248] Optionally, after repeatedly executing steps S3-S6 until a preset number of rounds, the blockchain consensus method based on verifiable random selection further includes:

[0249] Determine the number of packaged construction blocks with the largest index value among the packaged construction blocks generated in the preset number of rounds;

[0250] When the number of packaged building blocks is 1, it is confirmed that all packaged building blocks meet the deterministic judgment when the preset number of rounds is reached; among them, the packaged building blocks that meet the deterministic judgment will not generate rollback processing.

[0251] It should be noted that, in this embodiment of the invention, finality refers to a property that ensures the irreversibility and permanence of transactions. Specifically, once a transaction is finalized, it will not be rolled back but will exist permanently on the blockchain.

[0252] Optionally, after the block-producing nodes in the current round verify the election transactions requested by non-block-producing nodes, the blockchain consensus method based on verifiable random selection also includes:

[0253] The block-producing node in the current round penalizes the election transactions of non-block-producing nodes that have not passed verification, so that non-block-producing nodes that have not passed verification are not allowed to produce blocks in the current round and in the preset rounds after the current round.

[0254] Corresponding to a blockchain consensus method based on verifiable random selection, this embodiment of the invention provides a blockchain consensus device based on verifiable random selection. Figure 3 A schematic diagram of a blockchain consensus device based on verifiable random selection provided in an embodiment of the present invention, such as... Figure 3 As shown, the blockchain consensus device based on verifiable random selection includes: a creation unit 301, a sorting unit 302, an acquisition unit 303, a calculation unit 304, a verification unit 305, and a circulation unit 306.

[0255] S1, Creation Unit 301 is used to create a genesis file using nodes and start consensus before reaching the Unix timestamp; wherein, the genesis file contains: Unix timestamp, block time and request election transaction, and the genesis file created by each node is the same;

[0256] S2, the sorting unit 302 is used to read the request election transactions through the node and sort the request election transactions according to the preset rules to obtain the node's block packaging order;

[0257] S3, the acquisition unit 303 is used to acquire the block-producing node of the current round by using the block-producing order of the nodes;

[0258] S4, the calculation unit 304 is used to enable the block-producing node of the current round to perform fork selection calculation according to its own ledger content to obtain the construction block of the new block, and the non-block-producing node of the current round to broadcast its own request for election transaction according to the block production time.

[0259] S5, Verification unit 305 is used to verify the request election transactions of non-block-producing nodes using the block-producing node in the current round, and to package the verified request election transactions into the construction block of the new block to generate the packaged construction block.

[0260] S6, the sorting unit 302 is also used to add 1 to the number of rounds in the current round, and use the result of adding 1 as the number of rounds in the current round, and sort the request election transactions packaged in the previous preset number of rounds according to the preset rules of S2 to obtain the block packaging order of the nodes in the current round.

[0261] S7, the loop unit 306 is used to repeatedly execute steps S3-S6 until the preset number of rounds.

[0262] The method provided in this invention can be applied to electronic devices. Specifically, the electronic device can be a desktop computer, a portable computer, a smart mobile terminal, a server, etc. No limitation is made herein; any electronic device that can implement this invention falls within the protection scope of this invention.

[0263] Figure 4 A schematic diagram of a blockchain consensus system based on verifiable random selection provided in an embodiment of the present invention includes: a processor 710, a storage medium 720, and a bus 730. The storage medium 720 stores machine-readable instructions executable by the processor 710. When the system is running, the processor 710 communicates with the storage medium 720 via the bus 730, and the processor 710 executes the machine-readable instructions to perform the steps of the above-described method embodiment. Specific implementation methods and technical effects are similar and will not be repeated here.

[0264] The present invention also provides a storage medium storing a computer program, which, when executed by a processor, performs the steps of the blockchain consensus method based on verifiable random selection described above.

[0265] It should be noted that the terms "first," "second," etc., are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The implementations described in the following exemplary embodiments do not represent all implementations consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure.

[0266] In the description of this specification, the references to "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features or characteristics described may be combined in any suitable manner in one or more embodiments or examples. In addition, those skilled in the art can combine and integrate the different embodiments or examples described in this specification.

[0267] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings and the disclosure, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the description of this invention, the word "comprising" does not exclude other components or steps, "a" or "an" does not exclude a plurality, and "a plurality" means two or more, unless otherwise explicitly specified. Furthermore, while different embodiments may describe certain measures, this does not mean that these measures cannot be combined to produce good results.

[0268] The method provided in this invention can be applied to electronic devices. Specifically, the electronic device can be a desktop computer, a portable computer, a smart mobile terminal, a server, etc. No limitation is made herein; any electronic device that can implement this invention falls within the protection scope of this invention.

[0269] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.< / t>

Claims

1. A blockchain consensus method based on verifiable random selection, characterized in that, include: S1. Utilize nodes to create a genesis file and initiate consensus before reaching the Unix timestamp; wherein, the genesis file contains: Unix timestamp, block production time, and request election transaction, and the genesis file created by each node is identical; S2. Read the request election transaction through the node, and sort the request election transaction according to the preset rules to obtain the node's block production order; S3. The node uses the block production order of the node to obtain the block production node of the current round; S4. The block-producing node of the current round performs fork selection calculation according to its own ledger content to obtain the construct block of the new block, and the non-block-producing node of the current round synchronously broadcasts its own request for election transaction according to the block production time. S5. The block-producing node of the current round verifies the request election transaction of the non-block-producing node, and packages the verified request election transaction into the construction block of the new block to generate the packaged construction block. S6. Increment the number of rounds in the current round by 1, and use the incremented number as the number of rounds in the current round. Sort the request election transactions that have been packaged for the previous preset number of rounds in the current round according to the preset rules in S2 to obtain the block packaging order of the nodes in the current round. S7. Repeat steps S3-S6 until the preset number of rounds is reached.

2. The blockchain consensus method based on verifiable random selection according to claim 1, characterized in that, The method for creating a genesis file using nodes and initiating consensus before reaching the Unix timestamp, based on verifiable random selection of blockchain consensus, further includes: All nodes are authenticated and connected via a two-way authentication connection using an SSL handshake.

3. The blockchain consensus method based on verifiable random selection according to claim 1, characterized in that, The step of reading the request election transaction through the node and sorting the request election transaction according to a preset rule to obtain the node's block production order includes: The node reads the request election transaction and generates a first preset list of the request election transactions; The node checks the penalized status of the initiating node according to the first preset list; When the initiating node is in a penalized state, the initiating node is removed from the first preset list to obtain the second preset list; The second preset list is sorted in descending order using random numbers from the second preset list to obtain the order in which the nodes are packaged into blocks.

4. The blockchain consensus method based on verifiable random selection according to claim 1, characterized in that, The current block-producing node performs fork selection calculations based on its own ledger content to obtain the constructing block of the new block, including: Obtain the list of blocks with the highest height in the ledger content corresponding to the block-producing node of the current round; From the list of blocks with the highest height in the ledger content, index the list of blocks with the largest index value to obtain the third list; Determine the number of blocks in the third list; When the number of blocks in the third list is 1, the block with the largest index value is used as the building block of the new block.

5. The blockchain consensus method based on verifiable random selection according to claim 4, characterized in that, After determining the number of blocks in the third list, the blockchain consensus method based on verifiable random selection further includes: When the number of blocks in the third list is not 1, a block is randomly selected as the building block of the new block using the VRF algorithm.

6. The blockchain consensus method based on verifiable random selection according to claim 1, characterized in that, The blockchain consensus method based on verifiable random selection further includes repeating steps S3-S6 until a preset number of rounds has been completed. Determine the number of the packaged construction blocks with the largest index value among the packaged construction blocks generated in the preset number of rounds; When the number of the packaged construction blocks is 1, it is confirmed that all the packaged construction blocks satisfy the deterministic judgment when the preset number of rounds is reached; among them, the packaged construction blocks that satisfy the deterministic judgment will no longer generate rollback processing.

7. The blockchain consensus method based on verifiable random selection according to claim 1, characterized in that, After the block-producing node in the current round verifies the request election transaction of the non-block-producing node, the blockchain consensus method based on verifiable random selection further includes: The block-producing node in the current round penalizes the election request transactions of the non-block-producing nodes that fail verification, so that the non-block-producing nodes that fail verification are not allowed to produce blocks in the current round and in the preset rounds that follow.

8. A blockchain consensus device based on verifiable random selection, characterized in that, include: The system includes a creation unit, a sorting unit, an acquisition unit, a calculation unit, a verification unit, and a loop unit. S1. The creation unit is used to create a genesis file using nodes and initiate consensus before reaching the Unix timestamp; wherein, the genesis file contains: Unix timestamp, block production time, and request election transaction, and the genesis file created by each node is the same; S2. The sorting unit is used to read the request election transaction through the node and sort the request election transaction according to a preset rule to obtain the node's block production order; S3. The acquisition unit is used to acquire the block-producing node of the current round using the block-producing order of the nodes; S4. The calculation unit is used to enable the block-producing node of the current round to perform fork selection calculation according to its own ledger content to obtain the construction block of the new block, and the non-block-producing node of the current round to simultaneously broadcast its own request for election transaction according to the block production time. S5. The verification unit is used to verify the request election transaction of the non-block-producing node using the block-producing node of the current round, and to package the verified request election transaction into the construction block of the new block to generate a packaged construction block. S6. The sorting unit is further configured to: add 1 to the number of rounds in the current round, and use the result of adding 1 as the number of rounds in the current round; and sort the request election transactions packaged in the preset number of rounds before the current round according to the preset rule in S2 to obtain the block packaging order of the nodes in the current round. S7. The loop unit is used to repeatedly execute steps S3-S6 until a preset number of rounds.

9. A blockchain consensus system based on verifiable random selection, characterized in that, include: The system includes a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the system is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the method as described in any one of claims 1-7.

10. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, performs the steps of the method as described in any one of claims 1-7.

Images