Secure and scalable stake-voting-based consensus method and system

Abstract

Provided in the present invention are a secure and scalable stake-voting-based consensus method and system. The method comprises: step S1, defining a system model; step S2, assigning roles to users of a system; step S3, defining a block submission rule, when a preset generation rule is met, a master node constructing a quorum certificate (QC), and after a master node of a new view receives 2f+1 timeout messages, generating a timeout certificate (TC); step S4, within each epoch, all validators in a validator committee performing a consensus process, and submitting blocks in a conflict-free order; and step S5, the first block of each epoch being proposed by the last leader in the previous epoch, and consistently being submitted by validator committees across two consecutive epochs. The present invention has good compatibility, making it suitable for various application scenarios, such as Web3.0 and metaverse, and can also realize a more secure consensus process, thereby effectively improving the scalability and security of blockchains.

Description

A secure and scalable consensus method and system based on stake voting Technical Field

[0001] This invention relates to a blockchain consensus method, more particularly to a secure and scalable consensus method based on stake voting, and further to a consensus system employing this secure and scalable consensus method based on stake voting. Background Technology

[0002] Currently, the metaverse is developing rapidly worldwide. The metaverse is a self-sustaining, hyperspace-transparent, three-dimensional immersive virtual shared space created by combining physically persistent virtual space with augmented reality. The metaverse integrates the three elements of the physical world, human society, and the digital world, and blockchain is one of the key underlying technologies for building the metaverse. Blockchain is a distributed ledger built on a peer-to-peer network, where data is organized in the form of hash-linked blocks. Due to its decentralized, transparent, trustworthy, time-series, and immutable characteristics, blockchain plays two irreplaceable roles in the metaverse. Firstly, as a decentralized repository, blockchain technology allows users to store data anywhere in the metaverse. Secondly, blockchain technology can provide a complete economic system and value system, thus bridging the gap between the real world and the metaverse.

[0003] The blockchain technology currently applied to the metaverse and Web3.0 is referred to as Blockchain 3.0. To realize a programmable society, Blockchain 3.0 emphasizes a human-centered principle in various complex business scenarios; for example, the concept of a human-centered metaverse has been proposed. A human-centered metaverse advocates for the will and interests of the people, not just the interests of the people or companies driving the system design. In other words, the sustainable development of a human-centered metaverse must be based on respect for human interests and values. Blockchain 3.0 differs from the previous two stages. Blockchain 1.0 recorded information limited to the value of digital currencies whose ownership changed over time, while Blockchain 2.0 introduced smart contracts, allowing for the automated execution of complex tasks, but its use cases remained limited to the financial sector. Currently, blockchain is gradually expanding from digital currencies and finance to many other areas collectively referred to as Blockchain 3.0, including domain names, digital identity, e-government, the Internet of Things, smart cities, Industry 4.0, and online electronic voting.

[0004] The following section introduces blockchain consensus protocols. Consensus protocols are a crucial component of blockchains, significantly impacting the performance of the blockchain system, including transaction capacity, scalability, and fault tolerance. Nakamoto consensus was the first blockchain consensus protocol, initially applied to cryptocurrencies. However, with increasing difficulty, it has led to serious energy waste. Furthermore, Proof-of-Work (PoW) faces centralization issues due to concentrated computing power, and efficiency challenges caused by transaction confirmation times as long as 10 minutes. Therefore, researchers have begun exploring new blockchain consensus protocols, with two important research directions being Proof-of-Stake (PoS) and Byzantine Fault-Tolerant (BFT) consensus protocols.

[0005] The core idea of ​​Proof-of-Stake (PoS) is that the probability of a validator proposing a block is proportional to their stake. While PoS follows the longest-chain rule of the Nakamoto consensus framework to achieve probabilistic finality, allowing it to tolerate up to 50% of the stake being maliciously controlled, this also results in longer transaction confirmation delays and lower throughput. In contrast, the Black-Scholes-Flush (BFT) consensus protocol offers fast and deterministic block finality. To ensure security and scalability, BFT consensus protocols typically elect a committee of validators based on a specific strategy. The committee then executes the proposed BFT consensus algorithm and can tolerate up to one-third Byzantine validators on the committee. BFT consensus protocols decide the validity of new blocks through voting, but its simple one-person-one-vote mechanism is not a true vote and does not truly reflect the stake and contribution of each validator.

[0006] While blockchain has achieved some success in its applications to the metaverse and Web3.0, a fundamental consensus protocol that fully aligns with the human-centric values ​​of Blockchain 3.0 has yet to be proposed. Therefore, providing a consensus method and system that is more suitable for metaverse applications, achieving a more secure consensus process, and improving the scalability and security of blockchain is undoubtedly a pressing technical problem that needs to be solved. Summary of the Invention

[0007] The technical problem this invention aims to solve is to provide a secure and scalable consensus method based on stake voting, which is more in line with the needs of metaverse applications and achieves a more secure consensus process, thereby effectively improving the scalability and security of blockchain. Furthermore, this invention provides a consensus system that employs this secure and scalable consensus method based on stake voting.

[0008] To address this, the present invention provides a secure and scalable consensus method based on stake voting, comprising the following steps:

[0009] Step S1: Define the system model, including defining the fault model and cryptographic primitives;

[0010] Step S2: Assign roles to users of the system. The assigned roles include user, candidate validator, validator, and leader.

[0011] Step S3: Define block submission rules. Under the condition of satisfying the preset generation rules, the master node uses aggregate signatures to construct the legal certificate QC from the votes on the block. The preset generation rules are: at least 2f+1 valid votes are received, and the total stake of these valid votes exceeds [a certain threshold]. f represents the maximum number of Byzantine validators, and s represents the total equity value of all validators; when the master node of the new view receives 2f+1 timeout messages, a timeout certificate TC is generated.

[0012] Step S4: In each epoch, all validators in the validator committee run the consensus process to submit blocks in a conflict-free order.

[0013] Step S5: The first block of each era is proposed by the last leader of the previous era and submitted unanimously by the validator committees of two consecutive eras. This block is used as a special block to realize the dynamic rotation of the validator committee.

[0014] A further improvement of the present invention is that step S1 includes the following sub-steps:

[0015] Step S101: Suppose the system model consists of n = 3f + 1 validators, denoted as set N, where the total equity of the validators is s and the total number of validators is n;

[0016] Step S102: In the fault model, the number of Byzantine validators does not exceed f, and the total equity controlled by all Byzantine validators is less than f. To achieve the definition of the fault model;

[0017] Step S103, when the master node receives message M from each validator i i and its corresponding signature σ i ←Sign i (M i When ), use the formula σ←AggSign({M i ,σ i} i∈N Generate an aggregate signature σ; given messages M1, M2, ..., M y Where 2f+1≤y≤n, through public keys PK1,PK2,…,PK y The verifier verifies the aggregate signature σ to achieve the definition of the cryptographic primitive.

[0018] A further improvement of the present invention is that, in step S2, the user only participates in the block distribution and message forwarding process; all candidate validators constitute the election pool of the committee, and at the beginning of each epoch, a fixed number of validators are selected from the election pool according to a preset strategy; validators have write permissions to the blockchain ledger and are responsible for executing the consensus process to ensure the sequential growth of the blockchain; the leader is responsible for collecting votes and proposing blocks, and the consensus process includes a series of views, each view uniquely designating a corresponding leader.

[0019] A further improvement of the present invention is that, in step S3, the process by which the master node constructs the legal certificate QC from the votes on the block using aggregate signatures is as follows: when the master node receives the legitimate votes (Vote) carrying the stake value from each validator i... i At that time, the signatures σ obtained through 2f+1 valid votes i Generate aggregate signature σ←AggSign({Vote i ,σ i} i∈N Then, the aggregate signature σ and the list of voting stake values ​​are combined to form the statutory certificate QC. When a statutory certificate QC is received, the corresponding block is certified, and its freshness is sorted by view number. The block with view number v and the statutory certificate are represented as B, respectively. v and QC v .

[0020] A further improvement of the present invention is that, in step S3, after the master node of the new view receives 2f+1 timeout messages, it aggregates the signatures of the highest view legal certificate (highQC) in these timeout messages, and the generated aggregated signature is concatenated with the new view information and the list of the original highest view legal certificates (highQC) to form a timeout certificate (TC); subsequently, the master node of the new view proposes a new block carrying the timeout certificate (TC).

[0021] A further improvement of the present invention is that the block submission rule in step S3 is as follows: the validator checks the local blockchain, and if the highest view legal certificate highQC, the block pointed to by the highest view legal certificate highQC, and its parent block form a dual chain, and the first chain is a single direct chain, then the validator submits the parent block of the block pointed to by the highest view legal certificate highQC; otherwise, it continues to wait until the local blockchain meets the dual-chain rule.

[0022] A further improvement of the present invention is that step S4 includes the following sub-steps:

[0023] Step S401 is used to implement leader election. The consensus process runs in a series of monotonically increasing views, each view is mapped to a unique leader to propose valid blocks. When a validator receives a block containing a legal certificate QC in view v and submits a block for view v-2, the legal certificate QC in the submitted block will serve as the source of randomness in determining the leader of view v+1. The leader is randomly elected from the current list of validators according to stake weighting. When a validator fails to submit a block for view v-2 in view v, a round-robin fallback mechanism will be used to determine the leader of view v+1.

[0024] Step S402 is used to implement the leader proposal, when the number of votes collected by the leader is not less than nf, and the total stake of a certain number of highly consecutive blocks exceeds [a certain threshold]. At this point, the view number increases continuously. At this time, the leader of view v receives votes from view v-1 and aggregates them into a legal certificate QC. Subsequently, this legal certificate QC is included in the block proposal of view v and broadcast to other validators.

[0025] Step S403 is used to implement validator voting. If the received block B contains a statutory certificate QC, the validator verifies the condition B.view = B.QC.view + 1. If block B contains a timeout certificate TC, the validator verifies the validity of the aggregate signature of the timeout certificate TC and the highest view statutory certificate highQC. First, by iterating through the view numbers of each statutory certificate QC and selecting the highest number, the validator obtains the corresponding highest view statutory certificate highQC. Then, the validator confirms whether block B is verified based on the block extension pointed to by the highest view statutory certificate highQC. When block B is verified as valid, the validator accepts the proposal and sends its vote for block B to the leader of the next view. When block B is verified as invalid, the validator rejects the proposal.

[0026] In step S404, the validator locally checks whether the blockchain meets the dual-chain rule. If it does, it is determined that a dual-chain has been formed, and the block is submitted.

[0027] A further improvement of the present invention is that, in step S402, if the leader of view v-1 fails, all honest validators send timeout messages η to the leader of view v; after receiving at least nf timeout messages, the leader of view v creates a timeout certificate TC with an aggregate signature and incorporates it into the block proposal of view v; the new proposed block extends the block pointed to by the highest view statutory certificate highQC in the timeout certificate TC, and defines the parent block of the new proposed block as the block pointed to by the highest view statutory certificate highQC in the timeout certificate TC; through the timeout certificate TC or the statutory certificate QC, the leader proves that its proposed block extends the block pointed to by the highest global view statutory certificate highQC, thereby persuading the validators to approve the block.

[0028] A further improvement of the present invention is that, in step S5, the committees of both consecutive epochs vote on the special block and the two blocks following that special block; wherein, the vote from epoch e forms the legal certificate QC for epoch e. e The votes from Epoch e+1 form the legal certificate QC for Epoch e+1. e+1 Special blocks satisfy the double-chain rule between epoch e and epoch e+1.

[0029] This invention also provides a secure and scalable consensus system based on stake voting, which employs the secure and scalable consensus method based on stake voting as described above, and includes:

[0030] The system model definition module is used to define the system model, including defining the fault model and cryptographic primitives;

[0031] The role assignment module is used to assign roles to users of the system. The assigned roles include user, candidate validator, validator and leader.

[0032] The block submission rules module is used to implement block submission rules. Under the condition of satisfying the preset generation rules, the master node uses aggregate signatures to construct the legal certificate QC from the votes on the block; when the master node of the new view receives 2f+1 timeout messages, it generates a timeout certificate TC.

[0033] The consensus process module involves all validators in the validator committee running the consensus process in each epoch to submit blocks in a conflict-free order.

[0034] The Epoch Change Module: The first block of each epoch is proposed by the last leader of the previous epoch and submitted unanimously by the validator committees of two consecutive epochs. This block serves as a special block, enabling dynamic rotation of the validator committee.

[0035] Compared with existing technologies, the beneficial effects of this invention are as follows: It provides a secure and scalable consensus method and system based on stake voting. During the voting process, it fully considers the rights and interests of validators, not only attaching a stake value to each vote but also implementing a window-based voting mechanism through the consensus process to increase flexibility, making the consensus process more in line with the human-centered metaverse values. Simultaneously, by modifying the authentication rules for legitimate blocks and the conditions for constructing the statutory certificate (QC), it achieves a more secure consensus process, making it resistant to all common attack methods in PoS and BFT protocols. Furthermore, it implements dynamic rotation of the validator committee through an epoch change mechanism. On the one hand, it improves the scalability of the blockchain by reducing the number of messages in the voting process; on the other hand, it ensures the security of the blockchain by achieving a secure transfer of power between the old and new committees through conflict-free submission of special blocks. Therefore, this invention not only has good compatibility, applicable to various application scenarios such as Web3.0 and the metaverse, and better meets the actual application needs of the metaverse, but also achieves a more secure consensus process, effectively improving the scalability and security of the blockchain. Attached Figure Description

[0036] Figure 1 is a schematic diagram of the workflow of an embodiment of the present invention;

[0037] Figure 2 is a schematic diagram of the role conversion relationship in one embodiment of the present invention;

[0038] Figure 3 is a schematic diagram of the chain structure of a pipeline proposal according to an embodiment of the present invention;

[0039] Figure 4 is an example diagram of a consensus process with a window size of 3 according to an embodiment of the present invention;

[0040] Figure 5 is an example diagram of an epoch change from epoch e to epoch e+1 according to an embodiment of the present invention. Detailed Implementation

[0041] In the description of this invention, the term "several" means one or more; the term "multiple" means two or more; the terms "greater than," "less than," and "exceeding" are all understood to exclude the stated number; and the terms "above," "below," and "within" are all understood to include the stated number. The terms "first," "second," etc., are understood to be used only to distinguish identical or similar technical feature names, and should not be construed as implying / indicating the relative importance of the technical features, the number of technical features, or the sequential relationship between the technical features.

[0042] The preferred embodiments of the present invention will now be described in further detail with reference to the accompanying drawings.

[0043] This invention is the first to introduce stake into the design of a BFT (Byzantine Fault Tolerance) consensus protocol and proposes the first human-centered consensus protocol. By modifying the criteria for determining the validity of certified blocks, it achieves a consensus process that is more secure than pure BFT and PoS protocols. The epoch change mechanism designed in this invention enables dynamic rotation of the committee, improving the scalability of the blockchain by reducing the number of messages in the voting process. In summary, this invention not only fully considers the rights of voters, attaching stake values ​​to votes, but also increases the flexibility of voting through a sliding window, aligning with the practical application scenarios of the metaverse, making the consensus process more secure and reliable.

[0044] To facilitate understanding of the essence of this invention, the relevant technologies will be described and explained first.

[0045] One related technical solution is a consensus protocol based on rights.

[0046] The Proof-of-Stake (PoS) consensus protocol was initially developed to address the security issues caused by the concentration of computing power in Proof-of-Work (PoW) and the energy consumption problems caused by the increased difficulty. The core idea of ​​PoS is that the chance of a validator proposing a block is proportional to their stake, but it still follows the longest chain rule of the Nakamoto consensus framework to achieve probabilistic finality.

[0047] Early PoS protocols included Peercoin and NXT. Peercoin still relied on solving hashing puzzles to generate blocks. Peercoin reduced the attack cost for small stakers; while NXT was the first pure PoS consensus protocol, solving the problem of stake monopoly from an incentive perspective. NXT introduced the concept of Transparent Forging, which allows nodes to generate blocks without relying on stake competition, simply waiting for the block-generating conditions to be met over time.

[0048] Early Proof-of-Stake (PoS) protocols suffered from the Matthew effect (the rich get richer) and security issues such as stakelessness. Therefore, blockchain-based Proof-of-Stake (PoS) was proposed as an alternative mechanism. Blockchain-based PoS employs an ordered block generation mechanism, typically using a multi-party secure computation process to determine the block proposal committee, where validators take turns generating blocks. Protocols of this type include Ouroboros, Ouroboros Praos, and Snow White. Ouroboros was the first provably secure and robust PoS protocol. It divides physical time into fixed-length epochs, each subdivided into N slots, with each slot randomly selecting a leader to generate blocks. However, Ouroboros suffers from two security problems: first, its strict requirement for network synchronization makes it vulnerable to out-of-sync attacks; second, because the leader sequence for the next epoch is known to all network participants, it is susceptible to adaptive disruption attacks targeting the slot leader. Ouroboros Praos aims to address these two security issues of Ouroboros. First, Ouroboros Praos is designed for partially synchronous networks, allowing a maximum message delivery latency of Δ time slots, although voters do not know the specific value of Δ. Second, Ouroboros Praos employs a locally executed Verifiable Random Function (VRF), allowing voters to know only the block proposal time slots for their next epoch, which are verified by corresponding VRF proofs. Snow White is a PoS protocol specifically designed to accommodate intermittent participation models, where nodes can arbitrarily switch between online and offline states. Snow White implements a modified sleep consensus protocol, an asynchronous consensus protocol that ensures consensus security under intermittent participation and committee reconfiguration. Furthermore, Snow White uses a checkpointing scheme to finally determine previous history, protecting the blockchain from subsequent sabotage attacks and adaptive key selection attacks.

[0049] The related technical solutions suffer from the following technical problems: Stake-based consensus protocols aim to solve the problems of computational power concentration and energy consumption in Proof-of-Work (PoW). Theoretically, PoS protocols can tolerate up to 50% of the stake being maliciously controlled, but the Matthew effect of "the rich getting richer" still exists, which will reduce the enthusiasm of small stake holders to participate in blockchain governance. Although chained proof-of-stake has been proposed as an alternative mechanism to early PoS protocols, it also faces its own security challenges. For example, Ouroboros has strict requirements for network synchronization and is vulnerable to out-of-sync attacks, while the known leader sequence makes it susceptible to targeted sabotage. In addition, Snow White's intermittent participation design is complex and increases the operational burden. Overall, existing stake-based consensus protocols are insufficient in terms of simplicity and security, which will affect network efficiency and participation. Direct adoption is not suitable for the practical application scenario of Metaverse.

[0050] Another related technical solution is a consensus protocol based on voting.

[0051] PoV is a voting-based consensus protocol that achieves consensus through the transmission and verification of voting messages between nodes. It is a high-performance voting consensus protocol suitable for permissioned blockchains, which introduces four roles: committee members, stewards, steward candidates, and ordinary users. However, the PoV protocol only tolerates crash failures and cannot tolerate Byzantine faults, because in the PoV protocol, the votes of 51% of the committee members are sufficient to validate a block.

[0052] In blockchain scenarios, a Byzantine fault-tolerant voting consensus protocol is required. The Byzantine fault-tolerant protocol originates from the Byzantine Generals Problem proposed by Lamport. PBFT was the first protocol to reduce communication complexity from exponential to polynomial level (normally O(N)). 2 The Byzantine Fault Tolerance (PBFT) protocol is used in both HQ and Zyzzyva. The HQ protocol, proposed in 2006, further improves the efficiency of PBFT. HQ employs a lightweight quorum-based protocol (communication complexity O(N)) in the absence of contention. However, HQ may fall back to PBFT to resolve contention. Zyzzyva uses speculation to minimize cost, but the client needs to detect inconsistencies and assist replicas in reaching consensus on a single total order of requests. Furthermore, both HQ and Zyzzyva have a view change communication complexity of O(N). 3Sphinx is also a PBFT-based consensus protocol, where each node generates blocks in parallel and acts as the leader of its own block. The VaaP protocol further improves Sphinx's efficiency through a pipelined confirmation mechanism and also proposes a rollback mechanism to resist fork attacks. HotStuff achieves optimistic responsiveness and linear view changes by introducing an extra round into the classic two-round BFT protocol, but this extra communication round leads to higher latency. Fast-HotStuff reduces latency by employing two rounds of voting and provides a method to prevent Byzantine masternodes from executing fork attacks. Both HotStuff and Fast-HotStuff borrow from the chain structure of blockchains, pipelined through a unified proposal voting model, significantly simplifying the protocol and improving throughput. HoneyBadgerBFT is the first practical asynchronous BFT protocol, but its communication complexity is O(N). 3 Furthermore, the partial synchronization network assumption is more reasonable for blockchain scenarios.

[0053] Therefore, these related technical solutions suffer from the following technical problems: Voting-based consensus protocols achieve consensus by transmitting and verifying voting messages. However, the PoV protocol only tolerates crash failures and cannot handle Byzantine faults, a significant drawback in the blockchain environment. While protocols like PBFT, HQ, and HoneyBadgerBFT can tolerate Byzantine faults, PBFT and HoneyBadgerBFT face high communication complexity, and the HQ protocol may revert to PBFT when resolving contention, leading to unstable protocol efficiency. The HotStuff protocol improves responsiveness by introducing additional communication rounds, but also increases latency, thus impacting overall performance. These performance issues result in poor scalability or increased consensus latency in large-scale networks, especially for protocols with high communication complexity. VaaP, HotStuff, and Fast-HotStuff employ pipelined processing mechanisms, significantly simplifying the protocol and improving throughput. However, their simple one-person-one-vote voting mechanism fails to accurately reflect the voting intentions and stake of validators and is more vulnerable to Sybil attacks. In summary, existing voting-based consensus protocols face security challenges, affecting the fairness and effectiveness of consensus, and are also not well-suited for direct application in the metaverse scenario.

[0054] Another related technical solution is a consensus protocol that combines equity and voting.

[0055] Hybrid consensus protocols that combine stake and voting improve scalability by introducing a delegation committee to reduce the communication volume of the consensus process. The earliest proposed hybrid consensus protocol is Delegated Proof-of-Stake (DPoS). DPoS works similarly to a democratic system, where shareholder nodes delegate their stake to other witnesses through voting. The top-ranked witnesses are elected as committee members, and these representative nodes are responsible for verifying transactions and building blocks in a predefined order. Transaction fees from verified blocks are then distributed among the witnesses according to their investment proportions.

[0056] The main extension of DPoS consensus is to incorporate the BFT algorithm into the design of PoS protocols. Specifically, Tendermint's consensus process operates on a committee of validators with staked equity, where validators are selected as block proposers according to their staked equity, and each block requires multiple rounds of BFT voting before final confirmation. Algorand generates new blocks using a fast binary Byzantine protocol (BA*) and uses a verifiable random function to select a small subset of nodes as BA* participants. PoPT selects a subset of nodes as participants in the consensus process based on their contributions to the system and proposes a parallel consensus mechanism based on PBFT to improve throughput. Although Tendermint, Algorand, and PoPT can tolerate up to 1 / 3 Byzantine validators in the committee, their simple one-person-one-vote rule in the voting process means that the BFT algorithm only serves a ranking function and cannot effectively reflect the value differences between validators.

[0057] Casper FFG is a lightweight proof-of-stake consensus layer built on top of Ethereum's proof-of-work block proposal mechanism. It achieves final confirmation of checkpoint blocks through stake voting at checkpoints. However, final confirmation takes a relatively long time, with PoS voting occurring approximately every 100 blocks, which may provide opportunities for some common attacks.

[0058] This related technical solution has the following technical problems: While consensus protocols that combine stake and voting reduce communication complexity and improve the scalability of blockchain networks by introducing authorized committees, they still face significant drawbacks. First, DPoS may lead to power concentration in committee elections, with a few nodes monopolizing the system and weakening its decentralized nature. This also significantly reduces the cost of attacks for attackers, and small stakers may lack sufficient incentive to participate in governance and voting. Second, most consensus protocols combining stake and voting, such as DPoS, Tendermint, and Algorand, simply adopt a one-person-one-vote voting rule. This lack of differentiated voting mechanisms means that the BFT algorithm only serves a ranking function, failing to effectively reflect the differences in stake and contribution among validators, potentially affecting the fairness and effectiveness of decision-making. Finally, Casper FFG, as a lightweight proof-of-stake consensus layer, requires a relatively long time to finalize blocks (approximately one PoS vote every 100 blocks), which may provide opportunities for some common attacks. In summary, existing consensus protocols that combine stake and voting still fall short in terms of security and fairness, fail to align with the human-centered values ​​of the metaverse, and still cannot meet the needs of this practical application scenario.

[0059] With the continuous development of the world towards a metaverse, how to effectively build a secure and scalable blockchain consensus protocol in this virtual shared space has become an urgent technical problem to be solved. The metaverse integrates the diverse characteristics of the physical, human, and digital worlds, and blockchain, due to its decentralized, immutable, and transparent features, has become a crucial infrastructure for storing and protecting users' digital content in the metaverse. Therefore, blockchain consensus protocols are a key technology for ensuring the security and performance of metaverse applications. Existing blockchain consensus protocols, such as PoW, are no longer suitable for the needs of the metaverse due to their high energy consumption and low efficiency, while PoS suffers from the risks of concentrated stake and lack of stakeholder involvement. Furthermore, existing voting-based consensus protocols or those that combine voting and stake simply adopt a one-person-one-vote rule, which does not meet the actual application requirements of the metaverse.

[0060] To address this, this embodiment aims to provide a secure and scalable consensus method and system based on stake voting, namely the Stake Voting Protocol (SVP), which focuses on meeting the practical application needs of the Metaverse Blockchain in terms of humanistic values, security, and scalability. The Stake Voting Protocol (SVP) proposed in this embodiment fully considers the stakes of validators during the voting process of the BFT protocol, attaching a stake value to each vote, and increasing the degree of freedom through a sliding window-based voting mechanism, thereby achieving true "voting." This embodiment proposes a more secure consensus process than pure BFT and PoS protocols by modifying the criteria for determining the validity of authenticated blocks in the two-stage pipelined BFT protocol, balancing the wishes of both higher-stake validators and lower-stake validators. Furthermore, this embodiment designs an epoch change mechanism to achieve dynamic rotation of the validator committee, ensuring the security and scalability of the protocol.

[0061] Therefore, this embodiment not only has good compatibility and can be applied to various application scenarios such as Web3.0 and metaverse, but also better meets the actual application needs of metaverse. Furthermore, it can achieve a more secure consensus process, effectively improving the scalability and security of blockchain.

[0062] More specifically, as shown in Figures 1 to 5, this embodiment provides a secure and scalable consensus method based on stake voting, including the following steps:

[0063] Step S1: Define the system model, including defining the fault model and cryptographic primitives;

[0064] Step S2: Assign roles to users of the system. The assigned roles include user, candidate validator, validator, and leader.

[0065] Step S3: Define block submission rules. Under the condition of satisfying the preset generation rules, the master node uses aggregate signatures to construct the legal certificate QC from the votes on the block. The preset generation rules are: at least 2f+1 valid votes are received, and the total stake of these valid votes exceeds [a certain threshold]. f represents the maximum number of Byzantine validators, and s represents the total equity value of all validators; when the master node of the new view receives 2f+1 timeout messages, a timeout certificate TC is generated.

[0066] Step S4: In each epoch, all validators in the validator committee run the consensus process to submit blocks in a conflict-free order.

[0067] Step S5: The first block of each era is proposed by the last leader of the previous era and submitted unanimously by the validator committees of two consecutive eras. This block is used as a special block to realize the dynamic rotation of the validator committee.

[0068] Step S1 in this embodiment is used to define the system model, including but not limited to fault models, network models, and cryptographic primitives.

[0069] In this embodiment, step S1 preferably includes the following sub-steps:

[0070] Step S101: Suppose the system model consists of n = 3f + 1 validators, denoted as set N, where the total equity of the validators is s and the total number of validators is n;

[0071] Step S102: In the fault model, the number of Byzantine validators does not exceed f, and the total equity controlled by all Byzantine validators is less than f. To achieve the definition of the fault model;

[0072] Step S103, when the master node receives message M from each validator i i and its corresponding signature σ i ←Sign i (M i When ), use the formula σ←AggSign({M i ,σ i} i∈N Generate an aggregate signature σ; given messages M1, M2, ..., M y Where 2f+1≤y≤n, through public keys PK1,PK2,…,PK y The verifier verifies the aggregate signature σ to achieve the definition of the cryptographic primitive.

[0073] More specifically, in the failure model, consider a system consisting of n = 3f + 1 validators, denoted as set N, where the total stake of the validators is s, and at most f validators are Byzantine validators. The total stake held by all Byzantine validators is less than s. Byzantine validators may act arbitrarily, while honest validators always adhere to the protocol. For simplicity, stake is defined as the number of tokens a user stakes.

[0074] In this network model, the embodiment employs a partially synchronous model, where there is a known boundary Δ and an unknown Global Stabilization Time (GST). After the GST, all transmissions between the two correct validators will arrive within time Δ. The consensus protocol in this embodiment will always ensure security and guarantee progress for a finite period after the GST.

[0075] In cryptographic primitives, when the master node fails, this embodiment uses aggregate signatures to generate a single, constant-size collective signature, instead of appending the signatures of all validators. The process is as follows: when the master node receives message M from each validator i... i and its corresponding signature σ i ←Sign i (M i When generating an aggregate signature σ←AggSign({M) using this information, the signature is then used. i ,σ i} i∈N Given messages M1, M2, ..., M y Where 2f+1≤y≤n, aggregate signature σ and public keys PK1,PK2,…,PK y Verifiers can verify the aggregate signature σ. Furthermore, attackers are computationally constrained and cannot forge signatures or message digests with negligible probability, thus ensuring its security.

[0076] Step S2 in this embodiment is used to assign roles.

[0077] To reduce communication complexity, the consensus process in this embodiment runs on a validator committee. As shown in Figure 2, there are four roles in the consensus system: user, candidate validator, validator, and leader.

[0078] Users can freely join or leave the network, but can only participate in block distribution and message forwarding, not the consensus process. Users can become candidate validators by staking a certain amount of tokens. The staked tokens are converted into candidate validator equity proportionally.

[0079] Validator candidates: All candidate validators constitute the election pool of the committee, which refers to the validator committee. At the beginning of each epoch, a fixed number of validators are selected from the election pool according to a preset strategy. In this embodiment, a random strategy is used by default for the election of the committee to ensure that each candidate validator has an equal probability of being selected; in practical applications, other preset strategies can be used instead.

[0080] Validators: The validator committee has write permissions to the blockchain ledger and is responsible for executing the consensus process to ensure the sequential growth of the blockchain. Each validator has voting rights based on their stake, with validators holding larger stakes having greater influence on blockchain governance.

[0081] Leader: The leader is responsible for collecting votes and proposing blocks. The consensus process involves a series of views, each uniquely designating a leader. By default, the leader is randomly elected from all validators based on stake weight.

[0082] Step S3 in this embodiment is used to implement the block submission rules.

[0083] In step S3 of this embodiment, the first step is to implement the Quorum Certificate (QC). The conditions for the preset generation rule (the generation rule for the pre-defined Quorum Certificate QC) are: at least 2f+1 valid votes are received, and the total equity of these valid votes received exceeds [a certain threshold]. At that time, a statutory certificate QC is constructed. It is worth noting that, unlike related technical solutions, this embodiment modifies the authentication rules for legitimate blocks (i.e., the rules for generating the statutory certificate QC) to: at least 2f+1 legitimate votes must be received, and the total stake of the legitimate votes must be greater than... This enables a more secure consensus process and makes it resistant to all common attack methods in PoS and BFT protocols.

[0084] In step S3 of this embodiment, the process by which the master node constructs the legal certificate QC from the votes on the block using aggregate signatures is as follows: When the master node receives the legitimate votes (Votes) carrying stake values ​​from each validator i... i At that time, the signatures σ obtained through 2f+1 valid votes i Generate aggregate signature σ←AggSign({Vote i ,σ i} i∈N Then, the aggregate signature σ and the list of voting stake values ​​are combined to form the statutory certificate QC. When a statutory certificate QC is received, the corresponding block is certified, and its freshness is sorted by view number. The block with view number v and the statutory certificate are represented as B, respectively. v and QC v .

[0085] Specifically, the SVP protocol refers to the statutory certificate QC with the highest view number known to the validator as the highQC. The SVP protocol modifies the statutory certificate QC generation rules in the BFT protocol, requiring not only at least 2f+1 valid votes but also ensuring that the total stake of these valid votes exceeds [a certain threshold]. That is, the window equity value exceeds This effectively enhances the security of the consensus process. A window refers to a pre-defined number of highly contiguous blocks, denoted by the number w. This pre-defined number can be set and adjusted according to actual conditions and needs.

[0086] Timeout Certificate (TC): When a validator abandons the current view, it broadcasts a timeout message containing its own legal certificate (highQC) and a signature of the highest view legal certificate (highQC). In step S3 of this embodiment, after the master node of the new view receives 2f+1 timeout messages, it aggregates the signatures of the highest view legal certificate (highQC) in these timeout messages. The generated aggregated signature is then concatenated with the new view information and the list of the original highest view legal certificates (highQC) to form the timeout certificate (TC). Subsequently, the master node of the new view proposes a new block carrying the timeout certificate (TC). The legal certificate (TC) provides proof of the highest view legal certificate (highQC) of the global view of the block extension. The highest view legal certificate (highQC) of the global view is the latest legal certificate (QC) held by the majority of validators, or a QC with a higher view number than the latest legal certificate (QC) held by the majority of validators.

[0087] The block submission rules also cover chains and direct chains.

[0088] Chain: Blocks at different heights are linked together using hashes and QCs (Quality Certificates) to form a blockchain. Except for the genesis block, each block must contain the hash of its parent block and the parent block's QC. The latest BFT protocol greatly simplifies the protocol through pipelined chain processing, as voting on a block now also votes on all uncommitted ancestor blocks. Blockchains can fork, as shown in Figure 3, block B... v+1 It is not block B v+2 The predecessor was not the ancestor, and block B was also... v+2 It's not block B either. v+1 The predecessor or ancestor of, therefore block B v+1 and Block B v+2 They are conflicting, but they share a common fork vertex block B. v .

[0089] Direct Chain: If a block B is added to another block B', represented as B.parent = B', then these two blocks form a single chain. If another block B... * If it is then added to block B, then B′, B, and B *This constitutes a double chain, and so on. There are two ways a blockchain can grow. The first is that the chain grows sequentially, where the view numbers of two consecutive blocks are also consecutive. For example, for two blocks B and B′, if B.view = B′.view + 1 and B.parent = B′, then there is a single direct chain between blocks B and B′. If B.view = B′.view + 1 and B.parent = B′, then B... * .view = B.view + 1, and B * If .parent = B, then it can be determined that the block is in blocks B', B, and B. * There are two direct chains between them, namely blocks B′, B, and B. * The first scenario satisfies the two-chain rule. The second scenario involves two views that might fail to generate blocks due to a Byzantine master node or network failure. In this case, B.view = B′.view + k, where k > 1, and B.parent = B′, then it can be said that there is no direct chain between B′ and B.

[0090] The commit rule in this embodiment is modified based on the BFT protocol of two-phase pipeline commit. Specifically, the block commit rule in step S3 of this embodiment is as follows: The validator checks the local blockchain. If a dual-chain is formed between the highest view legal certificate (highQC), the block pointed to by the highest view legal certificate (highQC), and its parent block, and the first chain is a single direct chain, then the validator commits the parent block of the block pointed to by the highest view legal certificate (highQC); as shown in Figure 2, block B... v+2 Block B v+3 and Block B v+5 This forms a two-chain structure, and block B... v+2 and Block B v+3 It forms a single direct chain, therefore block B can be safely committed. v+2 And its uncommitted ancestor blocks. Otherwise, continue to wait until the local blockchain meets the dual-chain rules. After issues such as network latency or partitioning are resolved, the dual-chain rules will eventually be met. Therefore, this embodiment can ensure the activity of the system and guarantee that nodes can promptly resume the consensus process and operate normally after network or partitioning issues are resolved.

[0091] Step S4 in this embodiment is used to implement the consensus process, also known as the consensus procedure.

[0092] In each epoch, all validators on the committee need to run the consensus process to submit blocks in a conflict-free order. The consensus process in this embodiment improves throughput by pipelined processing of requests at each stage.

[0093] In this embodiment, step S4 preferably includes steps S401 to S404.

[0094] Step S401 is used to implement leader election. The consensus process operates in a series of monotonically increasing views, each of which is mapped to a unique leader to propose valid blocks. When an honest validator receives a block containing a legal certificate QC in view v and commits a block for view v-2, the legal certificate QC in the committed block will serve as the source of randomness in determining the leader of view v+1. The leader is randomly elected from the current list of validators according to stake weighting. When a validator fails to commit a block for view v-2 in view v, for example, due to Byzantine behavior, crash, or message delay, a round-robin rollback mechanism will be used to determine the leader of view v+1.

[0095] Step S402 is used to implement the leader's proposal. This occurs when the leader has collected no less than nf votes and ensures the window's equity and exceed [a certain threshold]. At this point, it is considered a normal path. In a normal path, the view number increases continuously. At this time, the leader of view v receives votes from view v-1 and aggregates them into a legal certificate QC. Subsequently, this legal certificate QC is included in the block proposal of view v and broadcast to other validators.

[0096] A window refers to a pre-defined number of highly consecutive blocks, denoted by w. This pre-defined number can be set and adjusted according to actual conditions and needs. In this embodiment, when referring to the window of block B at height h, it refers to a total of w blocks from height h-w+1 to height h. A view's timer timeout indicates a master node failure, causing gaps in the blockchain's view sequence. This could be due to a master node crash or insufficient votes or stake in the previous view. If the leader of view v-1 fails, all honest validators will send a timeout message η to the leader of view v. After receiving at least nf timeout messages, the leader of view v will create a timeout certificate TC with an aggregate signature and include it in the block proposal of view v. The new proposed block needs to expand the block pointed to by the highest view legal certificate highQC in the timeout certificate TC; that is, the parent block of the new proposed block should be the block pointed to by the highest view legal certificate highQC in the timeout certificate TC. By using a timeout certificate (TC) or a validator certificate (QC), a leader can prove that its proposed block extends the block pointed to by the global highQC, thereby persuading validators to approve the block. As shown in Figure 4, no failure occurred between view v and view v+2, resulting in the block proposal containing only a validator certificate (QC). However, a failure occurred in the leader of view v+3, causing the leader of view v+4 to propose a block containing a timeout certificate (TC).

[0097] Step S403 is used to implement validator voting. Upon receiving a block proposed by the current view, the validator checks the block's validity in the following ways: If the received block B contains a statutory certificate QC, the validator needs to verify the condition B.view = B.QC.view + 1. If block B contains a timeout certificate TC, the validator verifies the aggregate signature of the timeout certificate TC and the validity of the highest view statutory certificate highQC. First, by iterating through the view numbers of each statutory certificate QC and selecting the highest number, the validator obtains the corresponding highest view statutory certificate highQC. Then, the validator confirms whether block B is validated based on the block extension pointed to by the highest view statutory certificate highQC. If block B is validated as valid, i.e., block B is based on the block extension pointed to by the highest view statutory certificate highQC, the validator accepts the proposal and sends its vote for block B to the leader of the next view. If block B is validated as invalid, the validator rejects the proposal and discards block B.

[0098] Unlike the BFT protocol, this embodiment incorporates the validator's stake into the voting data structure. Validators can determine their stake value for each vote; the protocol itself only restricts a validator's voting stake value for any given window to not exceeding their own stake value. Due to potential network latency or masternode censorship, a validator's vote for the current block may not be recorded in the QC (Quality Certificate) of the next block in a timely manner. However, even in the event of such an invalid vote, the validator can still reuse that stake value in the next round of voting. As shown in Figure 4, upon receiving block B... v+4 At this time, verifier i retrieves the highest-view statutory certificate highQC from the timed-out certificate TC. At this point, the statutory certificate QC... v+2 The highest-view legal certificate, highQC, is selected. This is done when the window size w is set to 3, in order to determine the legal certificate QC. v+2 For the validity of the certificate, verifier i must confirm the construction of the statutory certificate QC. v+2 The number of votes exceeds nf (i.e., 2f+1), and the statutory certificate QC v Statutory Certificate QC v+1 and statutory certificate QC v+2 Total equity value exceeds If the statutory certificate QC v+2 Valid, validator i will validate block B. v+4 Voting. Furthermore, validator i is free to transfer its stake S. i Assigned to block B v+1 Block B v+2 and Block B v+4 The vote. i The equity value of validator i, and s is the total equity value of all validators.

[0099] Step S404 is used to commit the block. The validator locally checks whether the blockchain meets the two-chain rule. If it does, it determines that a two-chain has been formed and commits the block.

[0100] As shown in Figure 4, in block B v+1 Block B v+2 and Block B v+4 A double chain is formed between them, and block B v+1 and Block B v+2 They form a single direct chain, so validator i immediately submits block B. v+1 According to the design of the classic pipelined BFT protocol, it should be noted that in this embodiment, submitting a block recursively submits all unsubmitted ancestor blocks. That is, based on the security proof, if a block is committable, then all blocks preceding that block have reached consensus on all nodes, so recursive submission is possible. If block B is submitted due to the satisfaction of the dual-chain rules, it is called a direct submission. If block B is submitted because of a direct submission of a block extending B, it is called an indirect submission.

[0101] Step S5 in this embodiment is used to implement the epoch change.

[0102] The epoch change mechanism in this embodiment is designed to facilitate dynamic rotation of the validator committee. This mechanism relies on the conflict-free commit of a special block across two consecutive epochs. The special block refers to the first block of each epoch, proposed by the last leader of the previous epoch, and requiring unanimous commit from the committees of two consecutive epochs.

[0103] As shown in Figure 5, the last leader of epoch e proposes a special block containing the initial stake values ​​of all validators in epoch e+1. This special block can also carry transactions like a regular block. This embodiment uses on-chain pseudo-randomness to implement the committee election strategy to prevent leaders from manipulating the committee list for the next epoch. The committee of epoch e cannot immediately withdraw after the special block is proposed, as it has not yet been finalized in the ledger and may be revoked. Therefore, this embodiment redefines the authentication rules for the special block and its two subsequent blocks, requiring committees in both consecutive epochs to vote on the special block and its two subsequent blocks.

[0104] That is, in step S5 of this embodiment, the committees of both consecutive epochs vote on the special block and the two blocks following that special block. The vote from epoch e forms the legal certificate QC for epoch e. e Based on the modified conditions for constructing the statutory certificate QC, the unanimous withdrawal of the old committee is ensured; the vote from Epoch e+1 forms the statutory certificate QC for Epoch e+1. e+1This facilitates and ensures the legitimate establishment of the new committee. Special blocks satisfy the dual-chain rule between epoch e and epoch e+1, ensuring conflict-free submission of special blocks and the secure transfer of power between the old and new committees.

[0105] This embodiment also provides a secure and scalable consensus system based on stake voting, which employs the secure and scalable consensus method based on stake voting as described above, and includes:

[0106] The system model definition module is used to define the system model, including defining the fault model and cryptographic primitives;

[0107] The role assignment module is used to assign roles to users of the system. The assigned roles include user, candidate validator, validator and leader.

[0108] The block submission rules module is used to implement block submission rules. Under the condition of satisfying the preset generation rules, the master node uses aggregate signatures to construct the legal certificate QC from the votes on the block; when the master node of the new view receives 2f+1 timeout messages, it generates a timeout certificate TC.

[0109] The consensus process module involves all validators in the validator committee running the consensus process in each epoch to submit blocks in a conflict-free order.

[0110] The Epoch Change Module: The first block of each epoch is proposed by the last leader of the previous epoch and submitted unanimously by the validator committees of two consecutive epochs. This block serves as a special block, enabling dynamic rotation of the validator committee.

[0111] In summary, this embodiment provides a secure and scalable consensus method and system based on stake voting, demonstrating significant advantages in several aspects. First, this embodiment fully considers the stake of validators during the voting process, not only attaching a stake value to each vote but also implementing a window-based voting mechanism through the consensus process to increase flexibility, making the consensus process more in line with the practical application needs of the metaverse. Second, this embodiment modifies the authentication rules for legitimate blocks and the conditions for constructing the statutory certificate QC, requiring that the number of votes collected by the master node is not less than nf and the window stake value exceeds [a certain threshold]. Only by aggregating these votes into a valid legal certificate (QC) can this embodiment resist all common attack methods in PoS and BFT protocols, enhancing the security of the consensus process. Third, this embodiment also implements dynamic rotation of the validator committee through an epoch change mechanism. On the one hand, it improves the scalability of the blockchain by reducing the number of messages in the voting process; on the other hand, it ensures the security of the blockchain by achieving a secure transfer of power between the old and new committees through conflict-free submission of special blocks. Fourth, this invention not only has good compatibility, applicable to various application scenarios such as Web3.0 and the metaverse, but it is also suitable for building the underlying blockchain for Web3.0 and metaverse scenarios. It can seamlessly integrate with existing blockchain technologies to better meet the actual application needs of the metaverse, effectively improving the scalability and security of the blockchain.

[0112] 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 secure and scalable consensus method based on stake voting, characterized in that, Includes the following steps: Step S1: Define the system model, including defining the fault model and cryptographic primitives; Step S2: Assign roles to users of the system. The assigned roles include user, candidate validator, validator, and leader. Step S3: Define block submission rules. Under the condition of satisfying the preset generation rules, the master node uses aggregate signatures to construct the legal certificate QC from the votes on the block. The preset generation rules are: at least 2f+1 valid votes are received, and the total stake of these valid votes exceeds [a certain threshold]. f represents the maximum number of Byzantine validators, and s represents the total equity value of all validators; when the master node of the new view receives 2f+1 timeout messages, a timeout certificate TC is generated. Step S4: In each epoch, all validators in the validator committee run the consensus process to submit blocks in a conflict-free order. Step S5: The first block of each era is proposed by the last leader of the previous era and submitted unanimously by the validator committees of two consecutive eras. This block is used as a special block to realize the dynamic rotation of the validator committee.

2. The secure and scalable consensus method based on stake voting according to claim 1, characterized in that, Step S1 includes the following sub-steps: Step S101: Suppose the system model consists of n = 3f + 1 validators, denoted as set N, where the total equity of the validators is s and the total number of validators is n; Step S102: In the fault model, the number of Byzantine validators does not exceed f, and the total equity controlled by all Byzantine validators is less than f. To achieve the definition of the fault model; Step S103, when the master node receives message M from each validator i i and its corresponding signature σ i ←Sign i (M i When ), use the formula σ←AggSign({M i ,σ i } i∈N Generate an aggregate signature σ; given messages M1, M2, ..., M y Where 2f+1≤y≤n, through public keys PK1,PK2,…,PK y The verifier verifies the aggregate signature σ to achieve the definition of the cryptographic primitive.

3. The secure and scalable consensus method based on stake voting according to claim 1, characterized in that, In step S2, users only participate in the block distribution and message forwarding process; all candidate validators constitute the election pool of the committee, and at the beginning of each epoch, a fixed number of validators are selected from the election pool according to a preset strategy; validators have write permissions to the blockchain ledger and are responsible for executing the consensus process to ensure the sequential growth of the blockchain; The leader is responsible for collecting votes and proposing blocks. The consensus process involves a series of views, each uniquely designating a corresponding leader.

4. The secure and scalable consensus method based on stake voting according to any one of claims 1 to 3, characterized in that, In step S3, the process by which the master node constructs the legal certificate QC from the votes on the block using aggregated signatures is as follows: when the master node receives the legitimate votes (Vote) carrying the stake value from each validator i... i At that time, the signatures σ obtained through 2f+1 valid votes i Generate aggregate signature σ←AggSign({Vote i ,σ i } i∈N Then, the aggregate signature σ and the list of voting stake values ​​are combined to form the legal certificate QC; when the legal certificate QC is received, the corresponding block is certified, and its freshness is sorted by view number. The block with view number v and the legal certificate are represented as B respectively. v and QC v .

5. The secure and scalable consensus method based on stake voting according to claim 4, characterized in that, In step S3, when the master node of the new view receives 2f+1 timeout messages, it will aggregate the signatures of the highest view legal certificate highQC in these timeout messages. The generated aggregated signature will be concatenated with the new view information and the list of the original highest view legal certificates highQC to form the timeout certificate TC. Subsequently, the master node of the new view proposes a new block carrying the timeout certificate TC.

6. The secure and scalable consensus method based on stake voting according to claim 4, characterized in that, The block submission rule for step S3 is as follows: the validator checks the local blockchain. If a dual-chain is formed between the highest view legal certificate highQC, the block pointed to by the highest view legal certificate highQC, and its parent block, and the first chain is a single direct chain, then the validator submits the parent block of the block pointed to by the highest view legal certificate highQC; otherwise, it continues to wait until the local blockchain meets the dual-chain rule.

7. The secure and scalable consensus method based on stake voting according to any one of claims 1 to 3, characterized in that, Step S4 includes the following sub-steps: Step S401 is used to implement leader election. The consensus process runs in a series of monotonically increasing views, each of which is mapped to a unique leader to propose valid blocks. When a validator receives a block containing a credential certificate QC in view v and commits a block in view v-2, the credential certificate QC in the committed block will serve as the source of randomness in determining the leader of view v+1. The leader is randomly elected from the current list of validators based on stake weighting. When a validator fails to commit a block in view v-2, a round-robin rollback mechanism will be used to determine the leader of view v+1. Step S402 is used to implement the leader proposal, when the number of votes collected by the leader is not less than nf, and the total stake of a certain number of highly consecutive blocks exceeds [a certain threshold]. At this time, the view number increases continuously. At this point, the leader of view v receives votes from view v-1 and aggregates them into a legal certificate QC. Subsequently, this statutory certificate QC was included in the block proposal of view v and broadcast to other validators; Step S403 is used to implement validator voting. If the received block B contains a statutory certificate QC, the validator verifies the condition B.view = B.QC.view + 1. If block B contains a timeout certificate TC, the validator verifies the validity of the aggregate signature of the timeout certificate TC and the highest view statutory certificate highQC. First, by iterating through the view numbers of each statutory certificate QC and selecting the highest number, the validator obtains the corresponding highest view statutory certificate highQC. Then, the validator confirms whether block B is verified based on the block extension pointed to by the highest view statutory certificate highQC. Once block B is validated, the validator accepts the proposal and sends its vote for block B to the leader of the next view. When block B is invalidated, the verifier rejects the proposal; In step S404, the validator locally checks whether the blockchain meets the dual-chain rule. If it does, it is determined that a dual-chain has been formed, and the block is submitted.

8. The secure and scalable consensus method based on stake voting according to claim 7, characterized in that, In step S402, if the leader of view v-1 fails, all honest validators send timeout messages η to the leader of view v; after receiving at least nf timeout messages, the leader of view v creates a timeout certificate TC with an aggregate signature and incorporates it into the block proposal of view v. The new proposed block extends the block pointed to by the highest view statutory certificate highQC in the timeout certificate TC, and defines the parent block of the new proposed block as the block pointed to by the highest view statutory certificate highQC in the timeout certificate TC. Through the timeout certificate TC or statutory certificate QC, the leader proves that its proposed block extends the block pointed to by the global highest view statutory certificate highQC, in order to convince the validators to approve the block.

9. The secure and scalable consensus method based on stake voting according to any one of claims 1 to 3, characterized in that, In step S5, the committees of both consecutive epochs vote on the special block and the two blocks following it; the vote from epoch e forms the legal certificate QC for epoch e. e The votes from Epoch e+1 form the legal certificate QC for Epoch e+1. e+1 Special blocks satisfy the double-chain rule between epoch e and epoch e+1.

10. A secure and scalable consensus system based on stake voting, characterized in that, It employs a secure and scalable consensus method based on stake voting as described in any one of claims 1 to 9, and includes: The system model definition module is used to define the system model, including defining the fault model and cryptographic primitives; The role assignment module is used to assign roles to users of the system. The assigned roles include user, candidate validator, validator and leader. The block submission rules module is used to implement block submission rules. Under the condition of satisfying the preset generation rules, the master node uses aggregate signatures to construct the legal certificate QC from the votes on the block; when the master node of the new view receives 2f+1 timeout messages, it generates a timeout certificate TC. The consensus process module involves all validators in the validator committee running the consensus process in each epoch to submit blocks in a conflict-free order. The Epoch Change Module: The first block of each epoch is proposed by the last leader of the previous epoch and submitted unanimously by the validator committees of two consecutive epochs. This block serves as a special block, enabling dynamic rotation of the validator committee.

Images