A blockchain consensus protocol based on proof-of-stake mechanism

Abstract

The application relates to a blockchain consensus protocol based on a proof-of-stake mechanism, and proposes a new distributed random beacon (DRB) to select a leader for generating a block, which can resist attacks of malicious nodes and guarantee randomness and fairness of leader election. A new longest chain rule is proposed, so that honest nodes can select the same main chain for block synchronization, improve consensus efficiency and reduce chain bifurcation rate, and support dynamic availability. Compared with some previous blockchain consensus protocols, the blockchain consensus protocol based on the proof-of-stake mechanism has higher throughput, safety and consensus efficiency.

Description

Technical Field

[0001] This invention belongs to the field of blockchain consensus system technology, specifically relating to a blockchain consensus protocol based on a proof-of-stake mechanism. Background Technology

[0002] Blockchain, as the underlying technology of encrypted digital currencies, is a distributed database system jointly maintained and recorded by all nodes. It possesses characteristics such as anonymity, decentralization, traceability, and immutability. Blockchain technology uses a database as the data storage medium and a P2P network as the communication medium. It relies on cryptography to determine ownership and protect privacy, and on a distributed system consensus framework to ensure consistency. Its aim is to build a value exchange system. Roles in a blockchain system are functionally divided into two categories: participating nodes and maintaining nodes. Participating nodes are client nodes that use the system. These nodes interact with users, initiating requests on client nodes and broadcasting them to the network. Maintaining nodes are the nodes that maintain the system's data records. These nodes verify user requests, create blocks, generate the blockchain, and store the blockchain data; they are the core roles in the blockchain system.

[0003] In a blockchain system, the blockchain consensus protocol establishes a set of rules that each node must follow to ensure the consistency of blockchain data backups across all nodes in the distributed system. The consensus protocol is a core component of the overall blockchain architecture, playing a crucial role in the blockchain's performance, security, scalability, and block production efficiency. The blockchain consensus protocol consists of two main steps: block-producing node election and block consensus. In the block-producing node election phase, a node (or multiple nodes) is elected as a block-producing node through a certain election mechanism, thus proposing a new block. Due to the potential presence of malicious nodes and forked blocks in the distributed network, other nodes cannot directly add the new block to their local blockchain system after receiving it. All nodes need to reach a consensus on the new block and the main chain it constitutes using the main chain consensus mechanism. The block-producing node election mechanism and block consensus together ensure the correctness and consistency of blockchain data, thereby providing technical support for establishing trust relationships between untrusted entities in a distributed environment.

[0004] In existing technologies, the random election function in the block-producing node election process has weak unpredictability, and the election process is relatively complex, consuming a lot of communication resources and reducing the efficiency of generating random numbers, thereby reducing consensus efficiency. The main chain consensus phase is mostly based on the longest chain rule, which is simple and efficient but has lower transaction throughput and more orphan blocks. Processes with high transaction throughput are more complex and are more suitable for permissioned chains. Summary of the Invention

[0005] To address the aforementioned problems in existing technologies, this invention provides a blockchain consensus protocol based on a proof-of-stake mechanism. The technical problem to be solved by this invention is achieved through the following technical solution:

[0006] This invention provides a blockchain consensus protocol based on a proof-of-stake mechanism, comprising:

[0007] Register each node in the blockchain system and generate node information;

[0008] The leader node of the blockchain is randomly selected using distributed random beacons;

[0009] The leader node packages the transactions into a new block and broadcasts it to the blockchain system, where other nodes verify the new block.

[0010] For newly verified blocks, consensus on the main blockchain is achieved through chain selection rules.

[0011] In one embodiment of the present invention, the node information includes: node number U i The node state value sid, the distributed random beacon key, and the node equity value s, wherein the distributed random beacon key includes a public key cpk and a private key sk.

[0012] In one embodiment of the present invention, the distributed random beacon is a quintuple polynomial algorithm, represented as: R = (CmteGen, PartialRand, CombRand, VerifyRand, Updstate), where CmteGen represents the key generation function, PartialRand represents the partial evaluation function, CombRand represents the total evaluation function, VerifyRand represents the node verification function, and Updstate represents the leader update function;

[0013] Among them, CmteGen(1 λ ,t,l): A group of nodes U1,…,U in the blockchain system i ,…,U l Run the program and output a public key cpk and the private key SK = {sk1, ..., sk} for each node. i ,...,sk l}, where 1 λ Let U represent the set of {0, 1} bit strings of length λ, l represent the number of nodes participating in the blockchain system, and the number of nodes under adversary control θ does not exceed the threshold t. i The node number sk represents the i-th node. i This represents the private key of the distributed random beacon key of the i-th node, and sk represents the private key of each node. i Only the relevant node knows;

[0014] PartialRand(sid i ,sk i ,cpk): Input the consensus state st of the (m-1)th round. m-1 Each node's private key SK = {sk1,...,sk} i ,...,sk l Given a public key cpk, output the random beacon value and proof corresponding to each node in the m-th round of consensus, denoted as ε. i =(U i ,δ m,i ,π m,i ), where st m-1 ={sid1,...,sid i ,...,sid l}, sid i δ represents the node state value of the i-th node in this round of consensus. m,i Let π represent the random beacon value of the i-th node in the m-th round of consensus. m,i This represents the proof of consensus at the i-th node in the m-th round;

[0015] CombRand(st m-1 ,ε,cpk): Input the state st of the consensus in the (m-1)th round. m-1 The set ε = {ε1, ..., ε} i ,…,ε l} and a public key cpk, if node i is the leader node, then output its corresponding random beacon value and proof as the random beacon value and proof for the m-th round of consensus (δ m ,π m Otherwise, output ⊥, where δ m Let π represent the random beacon value of the m-th round of consensus. m The proof of consensus in the m-th round, where ⊥ indicates no output result;

[0016] VerifyRand(st m-1 ,δ m ,π m ,cpk): Input the consensus state st of the (m-1)th round. m-1 The random beacon value and proof of the m-th round of consensus (δ) m ,π m ) and a public key cpk, to verify (δ) n ,π n If valid, output 1; otherwise, output 0.

[0017] Updstate(st n-1 ,δ n ,πn ,cpk): Input the consensus state st of the (m-1)th round. m-1 The random beacon value and proof of the m-th round of consensus (δ) m ,π m When the leader node proposes a block and calculates the new leader through the leader update function, the updated state value st of the m-th round is output. m When no result can be calculated, output ⊥.

[0018] In one embodiment of the present invention, other nodes verify the new block, including:

[0019] The leader credential of the new block is verified, and the legality of the new block is verified after the leader credential is verified.

[0020] In one embodiment of the present invention, the chain selection rule is as follows:

[0021] A tree-structured block consensus mechanism is adopted, and a set of chains is output for comparison. This set of chains consists of the two longest chains in the tree structure.

[0022] If the two chains are of different lengths, the chain with the longer length is selected to be added to the new block;

[0023] If the two chains are of the same length, the chain with the earlier consensus round after the fork point is selected to be added to the new block;

[0024] If the consensus rounds of blocks after the fork point are the same, then the chain with the smaller random beacon value after the fork point is selected to be added to the new block;

[0025] If two nodes simultaneously propose a new block and extend the same chain, the new block proposed by the earlier registered node will be used for chain extension.

[0026] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0027] 1. The blockchain consensus protocol based on the proof-of-stake mechanism of this invention proposes a new distributed random beacon method by utilizing existing methods for generating randomness sources. This method enables any node to verify the newly generated block, while other nodes cannot predict new blocks that have not been broadcast. This makes the generated blocks independent and continuously improves their rationality and security.

[0028] 2. The blockchain consensus protocol based on the proof-of-stake mechanism of the present invention utilizes the existing tree-like and graph-like chain structures to propose a new block consensus rule, thereby reducing the fork rate of the blockchain system and increasing transaction throughput.

[0029] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described in detail below with reference to the accompanying drawings. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of a UC model provided in an embodiment of the present invention;

[0031] Figure 2 This is a flowchart of a blockchain consensus protocol based on a proof-of-stake mechanism provided in an embodiment of the present invention;

[0032] Figure 3 This is a schematic diagram of a tree-like chain structure provided in an embodiment of the present invention. Detailed Implementation

[0033] To further illustrate the technical means and effects adopted by the present invention to achieve the intended purpose, the following detailed description of a blockchain consensus protocol based on a proof-of-stake mechanism proposed in accordance with the present invention is provided in conjunction with the accompanying drawings and specific embodiments.

[0034] The foregoing and other technical contents, features, and effects of the present invention will be clearly presented in the following detailed description of specific embodiments in conjunction with the accompanying drawings. Through the description of the specific embodiments, a more in-depth and concrete understanding can be gained of the technical means and effects adopted by the present invention to achieve its intended purpose. However, the accompanying drawings are for reference and illustration only and are not intended to limit the technical solutions of the present invention.

[0035] This invention presents a provably secure blockchain consensus protocol. It utilizes the UC model to design a series of ideal functions, thereby abstracting the environment, participants, and algorithm of the consensus protocol and analyzing its security. The relevant technologies involved in this invention are described first.

[0036] 1. UC Model

[0037] UC framework such as Figure 1 As shown, firstly, the UC framework defines the real-world environment ( Figure 1 The REAL environment describes the actual operation of the protocol, where all parties run the real protocol under the presence of a real adversary attack A; secondly, the UC framework defines the ideal environment (REAL). Figure 1The IDEAL in cryptographic protocols describes the ideal operation of a cryptographic protocol. In an ideal environment, there are virtual participants, an ideal adversary S, and an ideal function F. Participants do not communicate directly with each other, nor with the adversary S; all participants and the adversary S interact with the ideal function. The ideal function is essentially an unassailable, trusted role used to complete the ideal operation and functionality required by the protocol. In the UC security framework, environment Z simulates the entire external environment of the protocol operation (including other parallel protocols, attackers, etc.). Z can activate all participants, as well as attackers A and S, and communicate directly with them, for example, by sending a Corrupt message to the adversary. Z does not allow direct access to the ideal function F.

[0038] A function F is defined if and only if for any real adversary A, there exists an ideal adversary S such that any environment Z can be distinguished by at most a negligible probability from a real environment with A and protocol π and an ideal environment with S and ideal function F. If the protocol can simulate the ideal function F in UC, then protocol π is said to have securely implemented the ideal function F under the UC framework, and protocol π is also said to be UC secure.

[0039] Complex protocols typically consist of multiple sub-protocols, each capable of performing a specific security task. According to the composition theorem, a more complex protocol can be securely constructed using UC-secure protocols to achieve the designated task while guaranteeing the corresponding security properties.

[0040] 2. Blockchain consensus protocol

[0041] Blockchain consensus protocols consist of two main steps: block-producing node election and main chain consensus. In the block-producing node election phase, one or more nodes become block-producing nodes and propose new blocks. Due to the potential presence of malicious nodes and forked blocks in the distributed network, other nodes cannot directly add the new block to their local blockchain system upon receiving it. All nodes need to utilize main chain consensus to reach an agreement on the new block and the main chain it constitutes. The block-producing node election mechanism and main chain consensus together ensure the correctness and consistency of blockchain data, thus providing technical support for establishing trust relationships between untrusted entities in a distributed environment.

[0042] (1) Block production node election

[0043] Proof of Stake (PoS) Mechanism: While Proof of Stake mitigates the computational waste problem of Proof of Work to some extent, it further addresses this issue and improves block-producing node election efficiency. Instead of a competitive election mechanism based on challenging problems, it employs a Proof of Stake mechanism based on a random function. This type of mechanism uses a random algorithm with stake as the weight to determine block-producing nodes. Other nodes can verify the block-producing node's identity using the random algorithm. Since it no longer utilizes computational power competition to become a block-producing node, Proof of Stake based on a random function is a non-competitive election mechanism.

[0044] (2) Main chain consensus

[0045] Mainchain consensus refers to the process by which distributed network nodes reach an agreement on block data. In the operation of a blockchain system, nodes in the distributed network become block-producing nodes according to the block-producing node election mechanism, generate new blocks, and broadcast them. Because the block-producing node election mechanism can result in multiple blocks being generated at the same height, nodes locally maintain a tree-like structure of the blocks, i.e., a block tree. Therefore, nodes need to utilize mainchain consensus to reach an agreement on the final blockchain data within the block tree.

[0046] Based on whether the block data satisfies eventual consistency, main chain consensus can be divided into probabilistic consensus and deterministic consensus: In probabilistic consensus, the block data reaches consensus with a certain probability, and the probability gradually increases over time. It cannot guarantee that the block data will not be changed in the future. This kind of consistency is also called weak consistency. In deterministic consensus, once the block data reaches consensus, it cannot be changed. It is also called strong consistency.

[0047] Because permissionless blockchain networks are large-scale, message transmission is time-consuming and costly. Therefore, a probabilistic consensus mechanism for selecting the main chain is typically achieved through a single round of broadcasting. In this type of rule, the block-producing node broadcasts the newly generated block to other nodes. Nodes then use the main chain selection rule to determine the main chain block from their local block tree. Over time, the main chain blocks of all nodes become nearly identical. The longest chain rule selects the longest branch in the block tree as the main chain. Due to the use of a proof-of-work mechanism, the longest chain accumulates the most proof-of-work. Based on the principle of "one processor, one vote," the longest chain can be considered a decision made by a majority of nodes in the distributed network. Therefore, as long as most of the computing power is controlled by honest nodes, the distributed network can reach consensus on block data using the longest chain rule.

[0048] (3) Verifiable random function (VRF)

[0049] VRF is a non-interactive random number verification algorithm based on asymmetric encryption. It can verify the correctness of random number output. The process is as follows:

[0050] KeyGen(1 k → (VRF.vk, VRF.sk): The key generation algorithm generates the KES key (VRF.vk, VRF.sk).

[0051] Evaluate(VRF.sk, seed) → (nonce, proof): The evaluation function uses the private key and a random seed to calculate a random number and its proof.

[0052] VRF(VRF.vk,seed,nonce,proof)→(1 / 0): The random verification function uses public information such as the public key, random seed, random number, and proof for verification. If the result is 1, it means that the random number was indeed generated by the prover corresponding to the public key.

[0053] (4) Distributed key generation (DKG)

[0054] By involving multiple parties, a shared public and private key set is computed, addressing the issues of single points of failure and reliance on trusted third parties in distributed systems. In (n,t)-DKG, n is the number of nodes, and t is a threshold. The DKG protocol allows n nodes to jointly generate a key, ensuring that any subset of nodes with a number greater than the threshold t can use this shared key; however, any subset of nodes with a number less than the threshold t has no knowledge of this shared key.

[0055] (5) Digital signature scheme: Hash-and-Sign

[0056] Let Π = (Gen) S (Sign, Vrfy) is a standard scheme with a message length of l(n), let Π H =(Gen H H is a hash function where the output length of H is n, and the security parameter is 1. n Relevant. Based on Π=(Gen,Sign,Vrfy) and Π H =(Gen H Construct a signature method Π' = (Gen', Sign', Vrfy'):

[0057] Gen': Enter 1 n Run (pk,sk) ← Gen S (1 n ) and s←Gen H (1 n ), where the public key is pk' =<pk,s> The private key is sk'= <sk ,s >

[0058] Sign': Enter the private key sk=<sk,s> And message m∈{0,1} * ,Calculate δ'←Sign sk (H s (m)).

[0059] Vrfy': Input public key pk=<pk,s> Message m∈{0,1} * and a signature δ', if and only if Vrfy pk (H s When (m),δ)? = 1, the output is 1.

[0060] Furthermore, the relevant models involved in the blockchain consensus protocol based on the proof-of-stake mechanism of this invention will be described.

[0061] 1. System Model

[0062] Blockchain Composed of a series of blocks B0||B1||B2||…||B l The block is composed of an initial block B0, and each subsequent block contains the hash of the previous block, B0. i It can be defined as B i = <h i-1 payload i ,r i ,I,sig>, where payloads represent the set of valid transactions contained in the block,h i-1 =hash(B i-1 ) represents the hash value B of the previous block. i-1 The digital signature is sig=Sign sk <h i-1 payload i ,round,I>,I= i ,δ,π> represents information about equity holders, r i Defined as the current round. Each participant has initial public information during execution and possesses a local state st∈{0,1} in each round. λ , Indicates the length of the blockchain.

[0063] 2. Clock Model

[0064] ​Nodes should use a unified clock stamp when reaching consensus. The consensus time for each block generation round is fixed, assuming nodes can obtain the current unified timestamp at any time, such as with the Network Time Protocol (NTP). Nodes can calculate the current consensus round using the genesis timestamp from the genesis block and the current timestamp, without relying on a precisely ordered global clock.

[0065] 3. Network Communication Model

[0066] Network communication models are categorized into three types: synchronous, asynchronous, and weakly synchronous. A synchronous network model means that all messages received by nodes in the network are received within a predetermined time; that is, node clock drift has an upper bound, network transmission delay has an upper bound, and node computation speed is the same. An asynchronous model means that the arrival time of all messages by nodes in the network is uncertain; node clock drift has no upper bound, network transmission delay has no upper bound, and node computation speed varies. A weakly synchronous network model (also called a partially synchronous model) lies between synchronous and asynchronous network models (different assumptions can be made depending on the application scenario). Real-world network communication models often resemble this third type, where most messages arrive at a relatively certain time, while the arrival time of the remaining messages is uncertain. Assuming the protocol operates on a partially synchronous open distributed network model similar to a real-world scenario, communication between nodes in the network is partially synchronous; messages sent by nodes arrive within the maximum delay, and messages that have not arrived by that delay will never arrive.

[0067] 4. Random Oracle Model

[0068] In the random oracle model, the "oracle" is like a simple box that accepts a binary string as input and returns a binary string as output. The internal workings of this box are unknown and highly complex. Everyone (including honest players and adversaries) can interact with this box. Such interaction involves taking a binary string x as input and receiving a binary string y as output. This interaction process is called "querying the oracle z," and z is referred to as the "query" to the oracle. In this paper, the SHA256 hash function is treated as an idealized function that provides a random result for each different query. That is, the random oracle H: {0,1}*→{0,1} λ Whenever we query this function H with a new input x∈{0,1}*, H changes from {0,1} λ H generates a random answer value and returns it. Whenever x is queried again, H simply returns the same answer it previously gave for input x.

[0069] The technical solution of this invention will be described below. To address the issues of block election nodes: how to ensure that any node can verify the newly generated block while it is being generated; how other nodes cannot predict new blocks that have not been broadcast; and how to ensure that a new block is independent and unaffected by any other events when it is generated. This invention also addresses the block consensus issue: how to ensure a low fork rate, high system performance, and good security in the blockchain system under network latency and adversary conditions when designing consensus rules. Figure 2 The flowchart of the blockchain consensus protocol based on the proof-of-stake mechanism shown mainly includes block generation and main chain consensus. In the block generation stage, a distributed random beacon (DRB) is used to allow all participants to generate a random value to randomly select the blockchain leader. In the main chain consensus stage, a consensus rule with low fork probability, high performance, and strong security is formulated based on the longest chain rule and adversary attack prevention, so that blockchain nodes can reach a consensus on each new block, have the same blockchain view, and achieve consistency.

[0070] Specifically, a blockchain consensus protocol based on a proof-of-stake mechanism includes the following steps:

[0071] Step 1: Register each node in the blockchain system and generate node information;

[0072] In a blockchain system, node states are dynamic; nodes can join or leave the network at any time. Nodes in the system have both synchronous and asynchronous states. Each node needs to be registered, generating corresponding node information, including: node ID U. i The node state value is sid, the distributed random beacon key is s, and the node stake value is s. The distributed random beacon key includes the public key cpk and the private key sk. The node state value sid is a string consisting of {0,1}.

[0073] In this embodiment, the Hash-and-Sign algorithm is mainly used to sign and verify the node information to ensure the unforgeability of each node's information.

[0074] Step 2: Randomly select the leader node of the blockchain using distributed random beacons;

[0075] A Distributed Random Beacon (DRB) is used to have all participants generate a random value to randomly select the leader of the blockchain. Ideally, once a node is elected as the leader, it gains the right to generate new blocks. During the generation of new blocks, it is necessary to ensure that: any node can verify the generated new block; other nodes cannot predict new blocks that have not been broadcast; and a new block is independent and unaffected by any other events when it is generated. Verifiability ensures the validity and security of the new block. Unpredictability prevents adversaries from controlling the blockchain by adaptively corrupting the leader. Independence ensures that corrupted nodes cannot find the node that will generate future blocks through repeated sampling.

[0076] In this embodiment, the distributed random beacon is a quintuple polynomial algorithm, formally represented as: t-out-of-l, R = (CmteGen, PartialRand, CombRand, VerifyRand, Updstate), where l represents the number of nodes participating in the blockchain system, and the number of nodes under adversary control θ does not exceed the threshold t; CmteGen represents the key generation function, used to distribute public and private keys to each node; PartialRand represents the partial evaluation function, used to calculate the random beacon value and proof for each node; CombRand represents the total evaluation function, used to calculate the final output random beacon value and proof based on the output values ​​of the partial evaluation functions of each node; VerifyRand represents the node verification function, used to verify whether the node itself has been elected as the leader node; and Updstate represents the leader update function.

[0077] In this embodiment, the calculation process of the distributed random beacon is as follows:

[0078] CmteGen(1 λ ,t,l): A group of nodes U1,…,U in the blockchain system i ,…,U l Run the program and output a public key cpk and the private key SK = {sk1, ..., sk} for each node. i ,...,sk l}, where 1 λ U represents the set of {0, 1} bit strings of length λ. i The node number sk represents the i-th node. i This represents the private key of the distributed random beacon key of the i-th node, and sk represents the private key of each node. i Only the relevant node knows.

[0079] PartialRand(sid i ,sk i,cpk): Input the consensus state st of the (m-1)th round. m-1 Each node's private key SK = {sk1,...,sk} i ,...,sk l Given a public key cpk, output the random beacon value and proof corresponding to each node in the m-th round of consensus, denoted as ε. i =(U i ,δ m,i ,π m,i ), where st m-1 ={sid1,...,sid i ,...,sid l}, sid i δ represents the node state value of the i-th node in this round of consensus. m,i Let π represent the random beacon value of the i-th node in the m-th round of consensus. m,i This represents the proof of consensus reached by the i-th node in the m-th round.

[0080] CombRand(st m-1 ,ε,cpk): Input the state st of the consensus in the (m-1)th round. m-1 The set ε = {ε1, ..., ε} i ,…,ε l} and a public key cpk, if node i is the leader node, then output its corresponding random beacon value and proof as the random beacon value and proof for the m-th round of consensus (δ m ,π m Otherwise, output ⊥, where δ m Let π represent the random beacon value of the m-th round of consensus. m The proof of consensus in the m-th round, ⊥ indicates no output result, that is, the output of the total evaluation function is a null value;

[0081] VerifyRand(st m-1 ,δ m ,π m ,cpk): Input the consensus state st of the (m-1)th round. m-1 The random beacon value and proof of the m-th round of consensus (δ) m ,π m ) and a public key cpk, to verify (δ) n ,π n If valid, output 1; otherwise, output 0.

[0082] Updstate(st n-1 ,δ n ,π n ,cpk): Input the consensus state st of the (m-1)th round. m-1 The random beacon value and proof of the m-th round of consensus (δ)m ,π m When the leader node proposes a block and calculates the new leader through the leader update function, the updated state value st of the m-th round is output. m When no result can be calculated, output ⊥.

[0083] In this embodiment, through the random beacon value δ n This is used to determine whether the node has been elected as the leader node.

[0084] Step 3: The leader node packages the transactions into a new block and broadcasts it to the blockchain system, where other nodes verify the new block;

[0085] In this embodiment, the leader node generates a block header and leader credential based on its own relevant information and transaction information, assembles the block header and block body into a complete new block, and then broadcasts the new block and leader credential to other consensus nodes through the distributed network.

[0086] Other nodes verify the new blocks they receive. First, they verify the leader's credentials. Once the leader's credentials are verified, the nodes verify the legality of the new blocks. Once the verification is successful, the blocks are added to the node's local blockchain view.

[0087] Specifically, verifying a new block mainly includes: checking if the block has been verified, and returning it if verified; verifying the block's format, timestamp, and version; checking if the Merkle root hash is consistent; checking if the block size is within the length limit; verifying that the first transaction must be a coinbase transaction, and the rest cannot be coinbase transactions; using a checklist to verify the transactions within the block and ensure their validity; and verifying whether the beacon value and proof of the block proposer are valid.

[0088] Step 4: For new blocks that pass verification, achieve consensus on the main blockchain using chain selection rules.

[0089] In a blockchain system, nodes need to reach a consensus on the final blockchain data in the block tree using the main chain consensus mechanism. The Proof-of-Stake (PoS) mechanism uses node stake instead of computing power as the credential for consensus. In this embodiment, a new chain selection rule is designed by combining the longest chain rule, resistance to greedy and adaptive adversaries, and random election. (See also...) Figure 3 The diagram shows a tree-like chain structure. The chain selection rule for this embodiment is as follows:

[0090] a. Adopt a tree-structured block consensus method, output a set of chains for comparison, which consists of the two longest chains in the tree structure.

[0091] b1. If the two chains have different lengths, the chain with the longer length is selected to be added to the new block.

[0092] b2. If the two chains are of the same length, the chain with the earlier consensus round after the fork point is selected to be added to the new block; if the consensus rounds after the fork point are the same, the chain with the smaller random beacon value after the fork point is selected to be added to the new block.

[0093] It should be noted that if two nodes simultaneously propose a new block and extend the same chain, the new block proposed by the node that registered earlier will be selected for chain extension.

[0094] The blockchain consensus protocol based on the proof-of-stake mechanism in this embodiment, in practical applications, is implemented by designing an ideal function F. com This can be achieved by analyzing its security using probability theory. The ideal function F... com It is set according to the block generation and main chain consensus rules, and the function includes 3 sub-functions:

[0095] F register The new node needs to be passed through F register The function is used to register nodes.

[0096] F elect Equity holders need to go through F elect The function is used to determine whether it has been elected as the leader node.

[0097] F verify After a new block is generated, the remaining stakeholders need to verify whether the block is valid.

[0098] This invention presents a blockchain consensus protocol based on a proof-of-stake mechanism. Utilizing existing methods for generating randomness sources, it proposes a novel distributed random beacon method. This method allows any node to verify newly generated blocks, while other nodes cannot predict unbroadcasted blocks, thus ensuring the independence of generated blocks and continuously improving their rationality and security. Secondly, leveraging existing tree-like and graph-like chain structures, it proposes a new block consensus rule, reducing the fork rate and increasing transaction throughput of the blockchain system.

[0099] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations are intended to cover non-exclusive inclusion, such that an article or apparatus comprising a list of elements includes not only those elements but also other elements not expressly listed. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the article or apparatus that includes said element.

[0100] 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.

Claims

1. A blockchain consensus protocol based on a proof-of-stake mechanism, characterized in that, include: Register each node in the blockchain system and generate node information; The leader node of the blockchain is randomly selected using distributed random beacons; The distributed random beacon uses a quintuple polynomial algorithm, expressed as: , This represents the key generation function. This represents a partial evaluation function. Represents the total evaluation function. This represents the node verification function. This indicates the function to update the leader; in, : A group of nodes in the blockchain system Run the program and output a public key. and the private key of each node , in, Indicates length is The set of {0, 1} bit strings, This represents the number of nodes participating in the blockchain system, and the number of nodes under the control of an adversary. Not exceeding the threshold , Indicates the first i Node number of each node Indicates the first i The private key of the distributed random beacon key for each node, the private key of each node. Only the relevant node knows; : Enter the first m -1 round of consensus status Each node's private key and a public key Output the first m The random beacon value and proof corresponding to each node in the consensus round are represented as follows: ,in, , Indicates the first i The node state values ​​of each node in this round of consensus. Indicates the first i The node m The random beacon value of the consensus round, Indicates the first i The node m Proof of consensus; : Enter the first m -1 round of consensus status ,gather and a public key If node i If the node is the leader, it outputs its corresponding random beacon value and proof as the first... m Random beacon values ​​and proofs for round consensus Otherwise output ,in, Indicates the first m The random beacon value of the consensus round, No. m Proof of consensus This indicates that there is no output. : Enter the first m -1 round of consensus status , No. m Random beacon values ​​and proofs for round consensus and a public key ,verify If valid, output 1; otherwise, output 0. : Enter the first m -1 round of consensus status , No. m Random beacon values ​​and proofs for round consensus When the leader node proposes a block and calculates the new leader through the leader update function, the output is the first... m Round-up update of state values If no result can be calculated, output ⊥; The leader node packages the transactions into a new block and broadcasts it to the blockchain system, where other nodes verify the new block. For newly verified blocks, consensus on the blockchain main chain is achieved through chain selection rules, which are as follows: A tree-structured block consensus mechanism is adopted, and a set of chains is output for comparison. This set of chains consists of the two longest chains in the tree structure. If the two chains are of different lengths, the chain with the longer length is selected to be added to the new block; If the two chains are of the same length, the chain with the earlier consensus round after the fork point is selected to be added to the new block; If the consensus rounds of blocks after the fork point are the same, then the chain with the smaller random beacon value after the fork point is selected to be added to the new block; If two nodes simultaneously propose a new block and extend the same chain, the new block proposed by the earlier registered node will be used for chain extension.

2. The blockchain consensus protocol based on proof-of-stake mechanism according to claim 1, characterized in that, The node information includes: node number Node status values Distributed random beacon key and node stake value The distributed random beacon key includes a public key. and private key .

3. The blockchain consensus protocol based on proof-of-stake mechanism according to claim 1, characterized in that, Other nodes verify the new block, including: The leader credential of the new block is verified, and the legality of the new block is verified after the leader credential is verified.

Images