Safe and extensible consensus method and system based on equity voting

Abstract

The invention provides a safe and extensible consensus method and system based on rights and interests voting. The method comprises the following steps: S1, defining a system model; s2, role allocation is carried out on users of the system; s3, defining a block submission rule, and constructing a legal certificate # imgabs0 # by the main node under the condition of meeting a preset generation rule; when the master node of the new view receives the # imgabs1 # timeout message, generating a timeout certificate # imgabs2 #; s4, all verifiers of the verifier committee run a consensus process in each era, and submit the blocks in a conflict-free sequence; and S5, the first block of each comment is proposed by the last leader of the previous comment, and the verifier committee passing through the two consecutive comments submits the first block of each comment consistently. The method has good compatibility, is suitable for various application scenes such as Web3.0 and meta universe, can also realize a safer consensus process, and effectively improves the expandability and security of the block chain.

Description

Technical Field

[0001] The present invention relates to a blockchain consensus method, and more particularly to a secure and scalable consensus method based on equity voting, and further to a consensus system using the secure and scalable consensus method based on equity voting. Background Art

[0002] At present, the metaverse is developing rapidly around the world. The metaverse is a self-sustaining, super-time and space three-dimensional immersive virtual shared space created by combining physical persistent virtual space with virtual 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 P2P network, and its data is organized in the form of hash-linked blocks. Due to its characteristics of decentralization, transparency and trustworthiness, timeliness and non-tamperability, blockchain plays two irreplaceable roles in the metaverse. On the one hand, blockchain technology, as a decentralized repository, enables users to store data anywhere in the metaverse. On the other hand, blockchain technology can provide a complete economic system and value system, thus building a bridge between the real world and the metaverse.

[0003] The blockchain technology currently applied to the metaverse and Web3.0 is called blockchain 3.0. In order to realize a programmable society, blockchain 3.0 emphasizes the principle of people-oriented in various complex business scenarios. For example, the concept of a human-centered metaverse has been proposed. A human-centered metaverse advocates the will and interests of the people, not just the interests of the people or companies that drive 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 is different from the previous two stages. The information recorded in blockchain 1.0 is limited to the value of digital currencies that change ownership over time, while blockchain 2.0 introduces smart contracts that allow complex tasks to be automatically executed, but the use scenarios are still limited to the financial field. At present, blockchain is gradually expanding from the digital currency and financial fields to many other fields collectively referred to as blockchain 3.0, including domain names, digital identities, e-government, the Internet of Things, smart cities, and online electronic voting.

[0004] The following is an introduction to the consensus protocol of blockchain. Consensus protocol is a key component of blockchain and has a significant impact on the performance of blockchain systems, including transaction capacity, scalability, and fault tolerance. Nakamoto consensus is the first blockchain consensus protocol and was first applied to digital currency. However, as the difficulty continues to increase, serious energy waste problems have emerged. In addition, PoW also faces centralization problems caused by the concentration of computing power, as well as efficiency challenges caused by transaction confirmation times of up to 10 minutes. Therefore, researchers have begun to explore new blockchain consensus protocols, two of which are the Proof of Stake (PoS) and Byzantine Fault Tolerance (BFT) consensus protocols.

[0005] The core idea of ​​PoS is that the chance of a validator proposing a block is proportional to the value of its stake. Although 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 leads to longer transaction confirmation delays and lower throughput. In contrast, the BFT consensus protocol is able to provide fast and deterministic block finalization. In order to ensure security and scalability, the BFT consensus protocol usually elects a number of validators to form a committee based on a specific strategy. The committee then executes the proposed BFT consensus algorithm and can tolerate up to 1 / 3 of the Byzantine validators in the committee. The BFT consensus protocol decides whether a new block is valid by voting, but it simply adopts a one-person-one-vote voting mechanism, so this is not a real vote and cannot truly reflect the rights and contributions of each validator.

[0006] Although blockchain has made some achievements in the application of Metaverse and Web3.0, there has not yet been an underlying consensus protocol that can fully meet the people-oriented values ​​of Blockchain 3.0. Therefore, how to provide a consensus method and system that is more in line with Metaverse applications, achieve a more secure consensus process, and improve the scalability and security of blockchain is undoubtedly a technical problem that needs to be solved urgently. Summary of the invention

[0007] The technical problem to be solved by the present invention is to provide a secure and scalable consensus method based on equity voting, so as to better meet the application requirements of the metaverse and achieve a safer consensus process, aiming to effectively improve the scalability and security of the blockchain. On this basis, a consensus system using the secure and scalable consensus method based on equity voting is further provided.

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

[0009] Step S1, defining a system model, including defining a fault model and cryptographic primitives;

[0010] Step S2, assigning roles to users of the system, including users, candidate verifiers, verifiers, and leaders;

[0011] Step S3, define the block submission rules. Under the condition of meeting the preset generation rules, the master node uses the aggregate signature to construct the legal certificate QC from the votes on the block. The conditions of the preset generation rules are: receiving at least 2f+1 legal votes, and the total equity of these legal votes received exceeds f represents the upper limit of the 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, it generates a timeout certificate TC.

[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 epoch is proposed by the last leader of the previous epoch and is unanimously submitted by the validator committee of two consecutive epochs. This block is used as a special block to achieve 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, assuming that the system model consists of n=3f+1 validators, denoted as set N, where the total stake 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 stake controlled by all Byzantine validators is less than To achieve the definition of fault model;

[0017] Step S103, when the master node receives the message M from each verifier i i and its corresponding signature σ i ←Sign i (M i ), through the formula σ←AggSign({M i ,σ i} i∈N ) generates 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 realize the definition of cryptographic primitives.

[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; the validator has write access to the blockchain ledger and is 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 specifies the corresponding leader.

[0019] A further improvement of the present invention is that in step S3, the process in which the master node uses the aggregate signature to construct the legal certificate QC from the votes on the block is as follows: when the master node receives the legal vote Vote carrying the equity value of each verifier i i When σ is passed by 2f+1 legal voting signatures i Generate an aggregate signature σ←AggSign({Vote i ,σ i} i∈N ), and then the aggregate signature σ and the voting rights value list are combined into a legal certificate QC. When the legal certificate QC is received, the corresponding block is authenticated, and its freshness is sorted by the view number. The block and legal certificate with view number v are represented as B v and QC v .

[0020] A further improvement of the present invention is that in step S3, when the master node of the new view receives 2f+1 timeout messages, the signatures of the highest view statutory certificates highQC in these timeout messages will be aggregated, and the generated aggregate signature will be spliced ​​together with the new view information and the list of the original highest view statutory certificates highQC to form a timeout certificate TC; then, 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 of step S3 is: the local blockchain is checked by the verifier. When the highest view statutory certificate highQC, the block pointed to by the highest view statutory certificate highQC, and its parent block form a double chain, and the first chain is a single direct chain, the verifier submits the parent block of the block pointed to by the highest view statutory certificate highQC; otherwise, continue to wait until the local blockchain satisfies the double 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 of view v-2, the legal certificate QC in the submitted block will be used as a random source to determine the leader of view v+1. The leader is randomly elected from the current list of validators according to the equity weight. When a validator fails to submit a block of view v-2 in view v, a polling 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 equity of a specific number of highly continuous blocks exceeds , 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 the voting of the verifier. If the received block B contains the legal certificate QC, the verifier verifies the condition that B.view=B.QC.view+1; if the block B contains the timeout certificate TC, the verifier verifies the validity of the aggregate signature of the timeout certificate TC and the highest view legal certificate highQC, first by iterating the view number of each legal certificate QC and selecting the highest number, obtaining the corresponding highest view legal certificate highQC, and then confirming whether block B is verified based on the block extension pointed to by the highest view legal certificate highQC; when the verification of block B is valid, the verifier accepts the proposal and sends its vote for block B to the leader of the next view; when the verification of block B is invalid, the verifier rejects the proposal;

[0026] Step S404: The verifier locally checks whether the blockchain satisfies the double-chain rule. If yes, it is determined that the formation of the double chain is checked 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 a timeout message η 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 newly 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 newly 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 the block it proposes extends the block pointed to by the global highest view statutory certificate highQC to convince the validator to approve the block.

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

[0029] The present invention also provides a secure and scalable consensus system based on equity voting, which adopts the secure and scalable consensus method based on equity voting as described above, and includes:

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

[0031] The role assignment module is used to assign roles to system users, including users, candidate validators, validators, and leaders.

[0032] The block submission rule module is used to implement the block submission rules. Under the condition that the preset generation rules are met, the master node uses the aggregate signature to build 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] Consensus process module, in each epoch, all validators in the validator committee run the consensus process to submit blocks in a conflict-free order;

[0034] The epoch change module proposes the first block of each epoch by the last leader of the previous epoch and is unanimously submitted by the validator committee of two consecutive epochs. This block is used as a special block to achieve dynamic rotation of the validator committee.

[0035] Compared with the prior art, the beneficial effects of the present invention are: providing a secure and scalable consensus method and system based on equity voting, fully considering the rights of the validator in the voting process, not only attaching equity value to the vote, but also realizing a window-based voting mechanism through the consensus process to increase flexibility, so that the consensus process is more in line with the people-oriented metaverse values; at the same time, by modifying the authentication rules for legal blocks and the conditions for building legal certificates QC, a safer consensus process is realized, so that it can resist all common attack methods in PoS and BFT protocols; on this basis, the dynamic rotation of the validator committee is realized through the epoch change mechanism, on the one hand, by reducing the number of messages in the voting process to improve the scalability of the blockchain, on the other hand, the power of the new and old committees is safely transferred through the conflict-free submission of special blocks, thereby ensuring the security of the blockchain. Therefore, the present invention not only has good compatibility, is suitable for a variety of application scenarios such as Web3.0 and the metaverse, is more in line with the actual application needs of the metaverse, but also can realize a safer consensus process, effectively improving the scalability and security of the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0037] Figure 2 is a schematic diagram of the conversion relationship between roles in an embodiment of the present invention;

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

[0039] Figure 4 This 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 This is an example diagram of an epoch change from epoch e to epoch e+1 according to an embodiment of the present invention. DETAILED DESCRIPTION

[0041] In the description of the present invention, if "several" is involved, it means more than one; if "multiple" is involved, it means more than two; if "greater than", "less than", or "exceed" is involved, it should be understood as not including the number itself; if "above", "below", or "within" is involved, it should be understood as including the number itself. If "first", "second", etc. are involved, they should be understood as being used only to distinguish the names of the same or similar technical features, and should not be understood as implying / indicating the relative importance of the technical features, the number of the technical features, or the order of the technical features.

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

[0043] This invention introduces rights and interests into the design of the BFT (Byzantine Fault Tolerance) consensus protocol for the first time, and proposes the first human-centered consensus protocol. By modifying the judgment conditions of legally authenticated blocks, a consensus process that is safer than pure BFT and PoS protocols is achieved. The epoch change mechanism designed by the present invention realizes the dynamic rotation of the committee and improves the scalability of the blockchain by reducing the number of messages in the voting process. On the whole, the present invention not only fully considers the rights and interests of voters themselves and attaches equity values ​​to votes, but also increases the flexibility of voting through sliding windows, which is in line with the actual application scenarios of the metaverse, and the consensus process is safer and more reliable.

[0044] To facilitate understanding of the essential content of the present invention, the relevant technologies are first described and illustrated.

[0045] One of the related technical solutions is the stake-based consensus protocol.

[0046] The equity-based consensus protocol, or PoS protocol, was originally designed to solve the security issues caused by the concentration of PoW computing power and the energy consumption problems caused by the increase in difficulty. The core idea of ​​PoS is that the chance of a validator proposing a block is proportional to its equity value, but it still follows the longest chain rule of the Nakamoto consensus framework to achieve probabilistic finality.

[0047] Early PoS protocols include Peercoin and NXT. Peercoin still relies on solving hash puzzles to generate blocks. Peercoin reduces the attack cost of small stake holders; while NXT is the first pure PoS consensus protocol, which solves the problem of stake monopoly from an incentive perspective. NXT proposed the concept of transparent forging, which allows nodes to generate blocks without relying on stake competition, and only needs to wait for the conditions for block generation to be met over time.

[0048] Early PoS protocols gave rise to security issues such as the Matthew effect of "the rich get richer" and no-stakes, so chain-based proof of stake was proposed as an alternative mechanism. Chain-based proof of stake adopts an orderly block generation mechanism, usually using a multi-party secure computation process to determine the block proposal committee, in which validators take turns to generate blocks. Such protocols include Ouroboros, Ouroboros Praos, and Snow White. Ouroboros is the first provably secure and robust PoS protocol, which divides physical time into epochs of fixed length. Each epoch is subdivided into N slots, and each slot randomly selects a leader for block generation. However, Ouroboros has two security issues. First, due to the strict requirements on network synchronization, it is vulnerable to desynchronization attacks. Second, because the leader sequence of the next epoch is known to all network participants, it is vulnerable to adaptive destruction attacks on slot leaders. Ouroboros Praos aims to solve these two security issues of Ouroboros. First, Ouroboros Praos is designed for partially synchronous networks, which allows a maximum delay of Δ time slots for message delivery, although voters do not know the specific value of Δ. Second, Ouroboros Praos uses a locally executed verifiable random function (VRF) that only allows voters to know their own block proposal time slots for the next epoch, which are verified by the corresponding VRF proofs. Snow White is a PoS protocol specifically designed to adapt to intermittent participation models, where nodes can switch online / offline states arbitrarily. Snow White implements a modified version of the sleep consensus protocol, an asynchronous consensus protocol that ensures consensus security in the face of intermittent participation and committee reconfiguration. In addition, Snow White uses a checkpoint scheme to finalize previous history to protect the blockchain from subsequent destruction attacks and adaptive key selection attacks.

[0049] This related technical solution has the following technical problems: The equity-based consensus protocol aims to solve the problems of computing power concentration and energy consumption of PoW. In theory, the PoS protocol can tolerate up to 50% of the equity being maliciously controlled, but there is still the Matthew effect of "the rich get richer", which will reduce the enthusiasm of small equity holders to participate in blockchain governance. Although chained equity proofs have been proposed as an alternative mechanism to early PoS protocols, they also face their own security challenges. For example, Ouroboros has strict requirements on network synchronization and is vulnerable to desynchronization attacks, while the known leader sequence makes it vulnerable to targeted sabotage. In addition, Snow White's intermittent participation design is relatively complex, which increases the operational burden. Overall, the existing equity-based consensus protocol has deficiencies in simplicity and security, which will affect the efficiency and participation of the network. If it is directly adopted, it is not suitable for the actual application scenario of the metaverse.

[0050] Another related technical solution is the voting-based consensus protocol.

[0051] A consensus protocol based on voting, that is, consensus is reached by transmitting and verifying voting messages between nodes. PoV is a high-performance voting consensus protocol suitable for permissioned chains, which introduces four roles, namely committee members, stewards, steward candidates, and ordinary users. However, the PoV protocol only tolerates crash failures and cannot tolerate Byzantine errors, because the votes of 51% of the committee members in the PoV protocol are sufficient to certify a block.

[0052] In the blockchain scenario, a Byzantine fault-tolerant voting consensus protocol is needed. The Byzantine fault-tolerant protocol is derived from the Byzantine Generals Problem proposed by Lamport. PBFT is the first protocol to reduce the communication complexity from exponential to polynomial level (O(N) in normal cases). 2 )) is a Byzantine fault-tolerant protocol. The HQ protocol proposed in 2006 further improves the efficiency of PBFT. HQ adopts a lightweight protocol based on quorum in the absence of contention (communication complexity is O(N)). However, HQ may fall back to PBFT to resolve contention. Zyzzyva uses speculation to minimize costs, but the client needs to detect inconsistencies and assist replicas to reach consensus on the requested single total order. In addition, the view change communication complexity of HQ and Zyzzyva is O(N 3). Sphinx is also a consensus protocol based on PBFT, in which each node generates blocks in parallel and acts as the leader of its own block. The VaaP protocol further improves the efficiency of Sphinx through a pipeline 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 in the classic two-round BFT protocol, but this extra communication round will result in higher latency. Fast-HotStuff reduces latency by adopting two rounds of voting and provides a method to prevent Byzantine master nodes from performing fork attacks. Both HotStuff and Fast-HotStuff draw on the chain structure of the blockchain and pipeline all stages through a unified proposal voting mode, which significantly simplifies the protocol and improves throughput. HoneyBadgerBFT is the first practical asynchronous BFT protocol, but its communication complexity is O(N 3 ), and the partial synchronous network assumption is more reasonable for blockchain scenarios.

[0053] Therefore, this related technical solution has the following technical problems: The voting-based consensus protocol reaches consensus by transmitting and verifying voting messages. However, the PoV protocol only tolerates crash failures and cannot cope with Byzantine errors, which is a significant defect in the blockchain environment. Although protocols such as PBFT, HQ, and HoneyBadgerBFT can tolerate Byzantine failures, PBFT and HoneyBadgerBFT face high communication complexity, and the HQ protocol may fall back to PBFT when resolving contention, resulting in unstable protocol efficiency. The HotStuff protocol improves responsiveness by introducing additional communication rounds, but also increases latency, thereby affecting overall performance. These performance issues lead to poor scalability or increased consensus latency in large-scale networks, especially those protocols with high communication complexity. VaaP, HotStuff, and Fast-HotStuff adopt a pipeline processing mechanism, which significantly simplifies the protocol and improves throughput. However, they simply adopt a one-person-one-vote voting mechanism, which cannot truly reflect the voting intention and equity ratio of the validator, and are more vulnerable to witch attacks. In general, existing voting-based consensus protocols face security challenges, which affect the fairness and effectiveness of consensus. They also cannot be directly applied to the actual application scenario of the metaverse.

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

[0055] A consensus protocol that mixes stake and voting improves scalability by introducing a delegation committee to reduce the communication size of the consensus process. The earliest proposed hybrid consensus is Delegated Proof of Stake (DPoS). DPoS works like a democracy, where shareholder nodes vote to grant their stake to other witnesses, where the top-ranked witnesses are selected as committee members. These representative nodes are responsible for verifying transactions and taking turns to build blocks in a pre-defined order. The transaction fees of the verified blocks are then distributed among the witnesses according to their investment ratio.

[0056] The main extension direction of DPoS consensus is to introduce the BFT algorithm into the design of PoS protocol. Specifically, Tendermint's consensus process runs on a committee of staked validators, where validators are selected as block proposers according to the proportion of their staked interests, and each block needs to go through multiple rounds of BFT voting before it can be finally confirmed. Algorand generates new blocks through a fast binary Byzantine agreement (BA*), and uses a verifiable random function to select a smaller subset from all nodes as participants in BA*. PoPT selects a subset as participants in the consensus process based on the contribution of each node 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 of the Byzantine validators in the committee, they simply adopt the one-person-one-vote rule in the voting process, resulting in the BFT algorithm only playing a sorting role and failing to effectively reflect the value differences between validators.

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

[0058] This related technical solution has the following technical problems: The consensus protocol of mixed stake and voting reduces the complexity of communication by introducing an authorized committee, thereby improving the scalability of the blockchain network, but it still faces significant disadvantages. First, DPoS may lead to the concentration of power in the committee election. The monopoly of a few nodes weakens the decentralized characteristics of the system, the attack cost of attackers is greatly reduced, and small stake holders may lack sufficient incentives to participate in governance and voting. Second, most consensus protocols of mixed stake and voting, such as DPoS, Tendermint, and Algorand, simply adopt the one-person-one-vote voting rule. This lack of differentiated voting mechanism makes the BFT algorithm only play a ranking role, failing to effectively reflect the differences in stake and contribution between validators, which may affect the fairness and effectiveness of decision-making. Finally, CasperFFG is a lightweight proof-of-stake consensus layer, but it takes a long time to finalize blocks (about one PoS vote every 100 blocks), which may provide opportunities for some common attacks. Overall, the existing consensus protocol of mixed equity and voting still has deficiencies in terms of security and fairness, fails to conform to the people-oriented values ​​of the Metaverse, and still cannot meet the needs of the actual application scenario of the Metaverse.

[0059] As the world continues to move towards the Metaverse, how to effectively build a secure and scalable blockchain consensus protocol in this virtual shared space has become a technical problem that needs to be solved urgently. The Metaverse integrates the multiple characteristics of the physical, human and digital worlds. Blockchain has become an important infrastructure for storing and protecting user digital content in the Metaverse due to its decentralization, immutability and transparency. Therefore, the blockchain consensus protocol is a key technology to ensure the security and performance of Metaverse applications. Existing blockchain consensus protocols, such as PoW due to its high energy consumption and low efficiency, and PoS due to its equity concentration risks and lack of interests, are no longer able to adapt to the needs of the Metaverse. At the same time, existing consensus protocols based on voting or existing consensus protocols based on mixed equity and voting simply adopt the rule of one person, one vote, which does not meet the actual application needs of the Metaverse.

[0060] In this regard, the present embodiment aims to provide a secure and scalable consensus method and system based on equity voting, namely, Stake Voting Protocol, referred to as SVP or SVP protocol, focusing on meeting the practical application requirements of the Metaverse blockchain in terms of humanistic values, security and scalability. The Stake Voting Protocol (SVP) proposed in this embodiment fully considers the rights and interests of the validator in the voting process of the BFT protocol, attaches equity value to the vote, and increases the degree of freedom through the voting mechanism based on the sliding window, thereby realizing "voting" in the true sense. This embodiment proposes a consensus process that is safer than the pure BFT and PoS protocols by modifying the judgment conditions for authenticated legal blocks in the pipeline two-stage BFT protocol, taking into account the wishes of higher-equity validators and lower-equity validators. On this basis, this embodiment further designs an epoch change mechanism to realize the dynamic rotation of the validator committee, ensuring the security and scalability of the protocol.

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

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

[0063] Step S1, defining a system model, including defining a fault model and cryptographic primitives;

[0064] Step S2, assigning roles to users of the system, including users, candidate verifiers, verifiers, and leaders;

[0065] Step S3, define the block submission rules. Under the condition of meeting the preset generation rules, the master node uses the aggregate signature to construct the legal certificate QC from the votes on the block. The conditions of the preset generation rules are: receiving at least 2f+1 legal votes, and the total equity of these legal votes received exceeds f represents the upper limit of the 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, it generates a timeout certificate TC.

[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 epoch is proposed by the last leader of the previous epoch and is unanimously submitted by the validator committee of two consecutive epochs. This block is used as a special block to achieve dynamic rotation of the validator committee.

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

[0069] The step S1 in this embodiment preferably includes the following sub-steps:

[0070] Step S101, assuming that the system model consists of n=3f+1 validators, denoted as set N, where the total stake 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 stake controlled by all Byzantine validators is less than To achieve the definition of fault model;

[0072] Step S103, when the master node receives the message M from each verifier i i and its corresponding signature σ i ←Sign i (M i ), through the formula σ←AggSign({M i ,σ i} i∈N ) generates 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 realize the definition of cryptographic primitives.

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

[0074] In the network model, this embodiment adopts a partial synchronization model, in which there is a known bound Δ and an unknown global stabilization time (GST). After the GST, all transmissions between two correct validators will arrive within the time Δ. The consensus protocol of this embodiment will always ensure security and guarantee progress within a limited time after the GST.

[0075] In cryptographic primitives, when the master node fails, this embodiment uses aggregate signatures to generate a single collective signature of constant size instead of appending the signatures of all validators. The process is as follows: when the master node receives a message M from each validator i i and its corresponding signature σ i ←Sign i (M i ), use this information to generate an aggregate signature σ←AggSign({M i ,σ i} i∈N ). Given messages M1,M2,…,M y , where 2f+1≤y≤n, the aggregate signature σ and the public keys PK1,PK2,…,PK y , the verifier can verify the aggregate signature σ. In addition, the attacker is subject to computational constraints and cannot forge signatures or message digests with negligible probability, so its security performance can also be guaranteed.

[0076] Step S2 described in this embodiment is used to implement role allocation.

[0077] To reduce communication complexity, the consensus process of this embodiment is run on the validator committee. Figure 2 As shown, there are four roles in the consensus system: users, candidate validators, validators, and leaders.

[0078] User: can join or leave the network at will, but can only participate in block distribution and message forwarding, not in the consensus process. Users can become candidate validators by staking a certain amount of tokens. The number of staked tokens is converted into the equity of candidate validators in proportion.

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

[0080] Validator: The Validator Committee has write access 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 the stake they hold, and validators with greater stakes have greater influence on blockchain governance.

[0081] Leader: The leader is responsible for collecting votes and proposing blocks. The consensus process consists of a series of views, each of which uniquely specifies a corresponding leader. The leader is randomly elected from all validators based on stake weight by default.

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

[0083] In step S3 of this embodiment, the first thing that needs to be implemented is the quorum certificate (QC). The preset generation rule (the generation rule for the preset quorum certificate QC) is: after receiving at least 2f+1 legal votes, and the total equity of these legal votes exceeds It is worth noting that, unlike the related technical solutions, this embodiment modifies the authentication rules of legal blocks (i.e., the generation rules of legal certificates QC) to: at least 2f+1 legal votes are received, and the total equity of legal votes is greater than This enables a more secure consensus process and makes it able to resist all common attack methods in PoS and BFT protocols.

[0084] In step S3 of this embodiment, the process of the master node using the aggregate signature to construct the legal certificate QC from the votes on the block is as follows: when the master node receives the legal vote Vote with the equity value of each verifier i i When σ is passed by 2f+1 legal voting signatures i Generate an aggregate signature σ←AggSign({Vote i ,σ i} i∈N ), and then the aggregate signature σ and the voting rights value list are combined into a legal certificate QC. When the legal certificate QC is received, the corresponding block is authenticated, and its freshness is sorted by the view number. The block and legal certificate with view number v are represented as B v and QC v .

[0085] In particular, the SVP protocol calls the legal certificate QC with the highest view number known to the validator highQC. The SVP protocol modifies the legal certificate QC generation rules in the BFT protocol, requiring not only receiving at least 2f+1 legal votes, but also ensuring that the total equity of these legal votes exceeds That is, the window equity value exceeds This effectively enhances the security of the consensus process. A window refers to a preset number of highly continuous blocks, the size of which is represented by w. The preset number can be set and adjusted according to actual conditions and needs.

[0086] Timeout Certificate (TC): When the verifier abandons the current view, it broadcasts a timeout message, which includes its own legal certificate highQC and the signature of the highest view legal certificate highQC. In step S3 described in this embodiment, when 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 aggregate signature is spliced ​​with the new view information and the list of the original highest view legal certificate highQC to form the timeout certificate TC; then, 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 block extension global view. The highest view legal certificate highQC of the global view is the latest legal certificate QC held by most verifiers, or a QC with a higher view number than the latest legal certificate QC held by most verifiers.

[0087] In the block submission rules, chains and direct chains are also involved.

[0088] Chain: Blocks of different heights are linked together through hashes and legal certificates QC to form a blockchain. Except for the genesis block, each block must contain the hash of the parent block and the legal certificate QC of the parent block. The latest BFT protocol greatly simplifies the protocol through pipeline chain processing, because now voting for a block also votes for all uncommitted ancestor blocks. The blockchain may have forks, such as Figure 3 As shown, block B v+1 Neither block B v+2 The predecessor of block B is not an ancestor either. v+2 Not Block B v+1 The predecessor or ancestor of block B v+1 and Block B v+2 are conflicting, but they have a common forked vertex block B v .

[0089] Direct Chain: If a block B is added to another block B′, expressed as B.parent = B′, then the two blocks form a single chain. * is added to block B, then B′, B and B *There are two ways for a blockchain to grow. The first is that the chain grows in a continuous manner, where the view numbers of two consecutive blocks are also continuous. For example, for two blocks B and B', if B.view = B'.view+1 and B.parent = B', then there is a single direct link between blocks B and B'. * .view=B.view+1, and B * .parent = B, then it can be determined that in blocks B′, B and B * There are two direct chains between them, namely blocks B′, B and B * Satisfies the double chain rule. Second, blocks may not be generated between the two views due to Byzantine master nodes or network failures. 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 link between B' and B.

[0090] Commit Rule: This embodiment makes modifications to the block submission rule based on the BFT protocol of pipeline two-stage submission. Specifically, the block submission rule of step S3 of this embodiment is: the verifier checks the local blockchain, and when the highest view legal certificate highQC and the block pointed to by the highest view legal certificate highQC and its parent block form a double chain, and the first chain is a single direct chain, the verifier submits the parent block of the block pointed to by the highest view legal certificate highQC; if Figure 2 As shown, block B v+2 、Block B v+3 and Block B v+5 It forms a double chain, and block B v+2 and Block B v+3 A single direct chain is formed, so block B can be submitted safely v+2 and its uncommitted ancestor blocks. Otherwise, continue to wait until the local blockchain satisfies the double-chain rule. After network delays or partitions are resolved, the double-chain rule will eventually be satisfied. Therefore, this embodiment can ensure the activity of the system and ensure that the nodes can resume the consensus process and operate normally in time after the network or partition problems are resolved.

[0091] Step S4 described in this embodiment is used to implement a consensus process, also called a consensus process.

[0092] At each epoch, all validators in the committee need to run the consensus process to submit blocks in order without conflicts. The consensus process of this embodiment improves throughput by pipeline processing of requests at each stage.

[0093] The step S4 described in this embodiment preferably includes steps S401 to S404.

[0094] 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 an honest validator receives a block containing a legal certificate QC in view v and submits a block of view v-2, the legal certificate QC in the submitted block will be used as a random source to determine the leader of view v+1, and the leader is randomly elected from the current list of validators according to equity weighting; when a validator fails to submit a block of view v-2 in view v, for example, the validator fails to submit a block of view v-2 in view v due to Byzantine behavior, crash or message delay, a polling fallback mechanism will be used to determine the leader of view v+1.

[0095] 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 rights and interests of the window are ensured to exceed 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; then, this legal certificate QC is included in the block proposal of view v and broadcast to other validators.

[0096] A window refers to a preset number of blocks with a high degree of continuity, and its size is represented by w. The preset number can be set and adjusted according to actual conditions and needs. When the present embodiment refers to the window of block B of height h, it refers to a total of w blocks from height h-w+1 to height h. The timer of the view times out, indicating that the master node fails, resulting in a gap in the view sequence of the blockchain. This may be due to the crash of the master node or insufficient votes in the previous view in terms of quantity or equity. 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 extend the block pointed to by the highest view statutory 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 statutory certificate highQC in the timeout certificate TC. Through the timeout certificate TC or the legal certificate QC, the leader can prove that the block it proposes extends the block pointed to by the global highQC, thereby convincing the validators to approve the block. Figure 4 As shown, there is no failure between view v and view v+2, resulting in the block proposal containing only the legal certificate QC. However, the leader of view v+3 fails, causing the leader of view v+4 to propose a block containing the timeout certificate TC.

[0097] Step S403 is used to implement validator voting. When receiving the block proposed by the current view, the validator checks the validity of the block in the following way. If the received block B contains the legal certificate QC, the validator needs to verify the condition that B.view=B.QC.view+1. If block B contains an expired certificate TC, the validator verifies the validity of the aggregate signature of the expired certificate TC and the highest view legal certificate highQC. First, it iterates the view number of each legal certificate QC and selects the highest number to obtain the corresponding highest view legal certificate highQC. Then the validator confirms whether block B is based on the block extension pointed to by the highest view legal certificate highQC for verification; when block B verification is valid, that is, block B is based on the block extension pointed to by the highest view legal certificate highQC, the validator accepts the proposal and sends its vote for block B to the leader of the next view; when block B verification is 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. The validator can decide the stake value of each vote by himself, and the protocol itself only limits the validator's voting stake value for any window to not exceed the validator's own stake value. Due to possible network delays or master node review, the validator's vote for the current block may not be recorded in the legal certificate QC of the next block in time. However, even if such an invalid vote occurs, the validator can still use this stake value again in the next round of voting. Figure 4 As shown, upon receiving block B v+4 When the verifier i extracts the highest view legal certificate highQC from the timeout certificate Tc, the legal certificate QC v+2 is selected as the highest view legal certificate highQC. When the window size w is set to 3, in order to determine the legal certificate QC v+2 The validity of the verifier i must confirm the construction of the legal certificate QC v+2 The number of votes exceeds nf (i.e. 2f+1), and the legal certificate QC v , Statutory Certificate QC v+1 And statutory certificate QC v+2 The total equity value exceeds If the statutory certificate QC v+2 Valid, validator i will verify block B v+4 In addition, validator i is free to vote its stake S i Assigned to block B v+1 、Block B v+2 and Block B v+4 S i The stake value of validator i, s is the total stake value of all validators.

[0099] Step S404 is used to implement block submission. The verifier locally checks whether the blockchain meets the double-chain rule. If yes, it is determined that the formation of the double chain is checked and the block is submitted.

[0100] like Figure 4 As shown, 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 A single direct chain is formed between them, so validator i immediately submits block B v+1 . According to the design of the classic pipeline BFT protocol, it should be noted that in this embodiment, submitting a block will recursively submit all unsubmitted ancestor blocks, that is, according to the security proof, if a block can be submitted, then all blocks before the block have been agreed on by all nodes, so it can be submitted recursively. If block B is submitted because the double chain rule is satisfied, it is called a direct submission. If block B is submitted because the block that extends B is submitted directly, it is called an indirect submission.

[0101] Step S5 described in this embodiment is used to implement era change.

[0102] The epoch change mechanism of this embodiment is to facilitate the dynamic rotation of the validator committee, which relies on the conflict-free submission of a special block in two consecutive epochs. A special block refers to the first block of each epoch, which is proposed by the last leader of the previous epoch and requires unanimous submission by the committee of two consecutive epochs.

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

[0104] That is, in step S5 of this embodiment, the committees of two consecutive epochs vote on the special block and the two blocks following the special block. The votes from epoch e form the legal certificate QC of epoch e. e, based on the modified conditions for constructing the legal certificate QC, ensure the unanimous exit of the old committee; the votes from epoch e+1 form the legal certificate QC of epoch e+1 e+1 , promoting and guaranteeing the legal establishment of the new committee. Special blocks satisfy the double-chain rule between epoch e and epoch e+1, ensuring conflict-free submission of special blocks and the safe transfer of power between the old and new committees.

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

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

[0107] The role assignment module is used to assign roles to system users, including users, candidate validators, validators, and leaders.

[0108] The block submission rule module is used to implement the block submission rules. Under the condition that the preset generation rules are met, the master node uses the aggregate signature to build 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] Consensus process module, in each epoch, all validators in the validator committee run the consensus process to submit blocks in a conflict-free order;

[0110] The epoch change module proposes the first block of each epoch by the last leader of the previous epoch and is unanimously submitted by the validator committee of two consecutive epochs. This block is used as a special block to achieve dynamic rotation of the validator committee.

[0111] In summary, this embodiment provides a secure and scalable consensus method and system based on equity voting, which demonstrates significant beneficial effects in many aspects. First, this embodiment fully considers the rights of validators in the voting process. It not only adds equity value to the vote, but also implements a window-based voting mechanism through the consensus process to increase flexibility, making the consensus process more in line with the actual application needs of the metaverse. Second, this embodiment modifies the conditions for constructing the legal certificate QC by modifying the authentication rules for legal blocks, that is, requiring that the number of votes collected by the master node is not less than nf and the window equity value exceeds Only then can these votes be aggregated into a valid legal certificate QC, so that this embodiment can resist all common attack methods in PoS and BFT protocols, and enhance the security of the consensus process. Third, this embodiment also realizes the dynamic rotation of the validator committee through the epoch change mechanism. On the one hand, it improves the scalability of the blockchain by reducing the number of messages in the voting process, and on the other hand, it realizes the safe transfer of power between the old and new committees through the conflict-free submission of special blocks, thereby ensuring the security of the blockchain. Fourth, the present invention not only has good compatibility, but is also suitable for a variety of application scenarios such as Web3.0 and the metaverse, that is, it is suitable for building the underlying blockchain for scenarios such as Web3.0 and the metaverse, and can be seamlessly connected with existing blockchain technology to better meet the actual application needs of the metaverse, effectively improving the scalability and security of the blockchain.

[0112] The above contents are further detailed descriptions of the present invention in combination with specific preferred embodiments, and it cannot be determined that the specific implementation of the present invention is limited to these descriptions. For ordinary technicians in the technical field to which the present invention belongs, several simple deductions or substitutions can be made without departing from the concept of the present invention, which should be regarded as falling within the protection scope of the present invention.

Claims

1. A secure and scalable consensus method based on stake voting, characterized by: The following steps are involved: Step S1, defining a system model, including defining a fault model and cryptographic primitives; Step S2, assigning roles to users of the system, including users, candidate verifiers, verifiers, and leaders; Step S3, define the block submission rules. Under the condition of meeting the preset generation rules, the master node uses the aggregate signature to construct the legal certificate QC from the votes on the block. The conditions of the preset generation rules are: receiving at least 2f+1 legal votes, and the total equity of these legal votes received exceeds f represents the upper limit of the 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, it generates a timeout certificate TC. 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 epoch is proposed by the last leader of the previous epoch and is unanimously submitted by the validator committee of two consecutive epochs. This block is used as a special block to achieve dynamic rotation of the validator committee.

2. The secure and scalable consensus method based on stake voting according to claim 1, characterized in that: The step S1 comprises the following sub-steps: Step S101, assuming that the system model consists of n=3f+1 validators, denoted as set N, where the total stake 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 stake controlled by all Byzantine validators is less than To achieve the definition of fault model; Step S103, when the master node receives the message M from each verifier i i and its corresponding signature σ i ←Sign i (M i ), through the formula σ←AggSign({M i ,σ i } i∈N ) generates 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 realize the definition of cryptographic primitives.

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 committee's election pool, 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 access 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 consists of a series of views, each of which uniquely specifies the corresponding leader.

4. A secure and scalable consensus method based on equity voting according to any one of claims 1 to 3, characterized in that: In step S3, the process of the master node using the aggregate signature to construct the legal certificate QC from the vote on the block is as follows: when the master node receives the legal vote Vote carrying the equity value of each verifier i i When σ is passed by 2f+1 legal voting signatures i Generate an aggregate signature σ←AggSign({Vote i ,σ i } i∈N ), and then the aggregate signature σ and the voting rights value list are combined into a legal certificate QC; when the legal certificate QC is received, the corresponding block is authenticated, and its freshness is sorted by the view number. The block and legal certificate with view number v are represented as B 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 aggregates the signatures of the highest view legal certificates highQC in these timeout messages, and the generated aggregate signature is combined 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 of step S3 is: the verifier checks the local blockchain. When the highest view legal certificate highQC, the block pointed to by the highest view legal certificate highQC, and its parent block form a double chain, and the first chain is a single direct chain, the verifier submits the parent block of the block pointed to by the highest view legal certificate highQC; otherwise, continue to wait until the local blockchain satisfies the double chain rule.

7. A secure and scalable consensus method based on equity voting according to any one of claims 1 to 3, characterized in that: The step S4 comprises the following sub-steps: Step S401 is used to implement leader election. The consensus process runs in a series of monotonically increasing views, and 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 of view v-2, the legal certificate QC in the submitted block will be used as a random source to determine the leader of view v+1, and the leader will be randomly elected from the current list of validators according to the equity weight; when a validator fails to submit a block of view v-2 in view v, a polling fallback 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 equity of a specific number of highly continuous blocks exceeds When , the view number increases continuously, at this time, the leader of view v receives votes from view v-1 and aggregates them into a quorum certificate QC; This legal certificate QC is then included in the block proposal of view v and broadcast to other validators; Step S403 is used to implement the voting of the verifier. If the received block B contains the legal certificate QC, the verifier verifies the condition that B.view=B.QC.view+1; if the block B contains the timeout certificate TC, the verifier verifies the validity of the aggregate signature of the timeout certificate TC and the highest view legal certificate highQC, first by iterating the view number of each legal certificate QC and selecting the highest number, obtaining the corresponding highest view legal certificate highQC, and then confirming whether the block B is verified based on the block extension pointed to by the highest view legal certificate highQC; When block B is verified to be 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 to be invalid, the validator rejects the proposal; Step S404: The verifier locally checks whether the blockchain satisfies the double-chain rule. If yes, it is determined that the formation of the double chain is checked 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 a timeout message n 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 includes it in 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 the block it proposes extends the block pointed to by the global highest view statutory certificate highQC to convince the validator to approve the block.

9. A secure and scalable consensus method based on equity voting according to any one of claims 1 to 3, characterized in that: In step S5, the committees of two consecutive epochs vote on the special block and the two blocks following the special block; the votes from epoch e form the legal certificate QC of epoch e. e , the votes from epoch e+1 form the legal certificate QC of 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: A secure and scalable consensus method based on stake voting as described in any one of claims 1 to 9 is adopted, and includes: System model definition module, used to define the system model, including fault model and cryptographic primitives; The role assignment module is used to assign roles to system users, including users, candidate validators, validators, and leaders. The block submission rule module is used to implement the block submission rules. Under the condition that the preset generation rules are met, the master node uses the aggregate signature to build 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; Consensus process module, in each epoch, all validators in the validator committee run the consensus process to submit blocks in a conflict-free order; The epoch change module proposes the first block of each epoch by the last leader of the previous epoch and is unanimously submitted by the validator committee of two consecutive epochs. This block is used as a special block to achieve dynamic rotation of the validator committee.

Images