A safe and scalable consensus method and system based on stake voting

Abstract

The application provides a safe and scalable equity voting-based consensus method and system, comprising the following steps: S1, defining a system model; S2, assigning roles to users of the system; S3, defining a block submission rule, under the condition of meeting a preset generation rule, a main node constructs a legal certificate; when a new view main node receives a message, a timeout certificate is generated; S4, in each epoch, all verifiers of the verifier committee run a consensus process to submit blocks in a conflict-free order; S5, the first block of each epoch is proposed by the last leader of the previous epoch and is submitted by the verifier committee of two consecutive epochs. The application not only has good compatibility and is suitable for various application scenarios such as Web3.0 and metaverse, but also can realize a safer consensus process, and effectively improves the scalability and security of the blockchain.

Description

TECHNICAL FIELD

[0001] The present application relates to a blockchain consensus method, in particular to a safe and scalable consensus method based on equity voting, and further relates to a consensus system adopting the safe and scalable consensus method based on equity voting. BACKGROUND

[0002] At present, the metaverse is developing rapidly worldwide. The metaverse is a self-sustaining, super-spatial three-dimensional immersive virtual shared space created by combining physical persistent virtual space and virtual augmented reality. The metaverse combines 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 credibility, time sequence 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, thereby bridging 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 human-centeredness in various complex business scenarios, such as the concept of human-centered metaverse has been proposed. The human-centered metaverse advocates the will and interests of the people, rather than the interests of the people or companies who drive system design. In other words, the sustainable development of the human-centered metaverse must be based on respect for human interests and values. Blockchain 3.0 is different from the previous two stages, where the information recorded in blockchain 1.0 is limited to the value of digital currency whose ownership changes over time, while blockchain 2.0 introduces smart contracts that allow automatic execution of complex tasks, but the use scenarios are still limited to the financial field. At present, blockchain is gradually expanding from digital currency and the financial field to other numerous fields collectively known as blockchain 3.0, including domain names, digital identity, e-government, Internet of Things, smart cities, Industry 4.0, and online electronic voting, etc.

[0004] The consensus protocol of the blockchain will be introduced below. The consensus protocol is a key component of the blockchain and has a significant impact on the performance of the blockchain system, 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 increases, there is a serious problem of energy waste. In addition, PoW also faces the problem of centralization due to the concentration of computing power, and the efficiency challenge of a 10-minute transaction confirmation time. Therefore, researchers have begun to explore new blockchain consensus protocols, two important research directions being Proof of Stake (PoS) and Byzantine Fault Tolerant (BFT) consensus protocols.

[0005] The core idea of PoS is that the opportunity for a validator to propose a block is proportional to its stake value. Although PoS follows the longest chain rule of the Nakamoto consensus framework to achieve probabilistic finality, it can tolerate up to 50% of the stake being controlled maliciously, but this also leads to longer transaction confirmation delays and lower throughput. In contrast, BFT consensus protocols can provide fast and deterministic block finalization. In order to guarantee security and scalability, BFT consensus protocols usually elect a number of validators to form a committee according to a specific strategy, and then the committee executes the proposed BFT consensus algorithm and can tolerate up to 1 / 3 of the Byzantine validators in the committee. BFT consensus protocols decide whether a new block is valid through voting, but they simply use a one-person-one-vote voting mechanism, so this is not a real vote and cannot truly reflect the stake and contribution of each validator.

[0006] Although the blockchain has achieved some success in the metaverse and Web3.0, so far there has been no underlying consensus protocol that fully fits the human-centered values of blockchain 3.0. Therefore, how to provide a consensus method and system that is more suitable for metaverse applications and achieve a safer consensus process, improve the scalability and security of the blockchain, is undoubtedly a technical problem that needs to be solved. SUMMARY

[0007] The technical problem to be solved by the present application is to provide a safe and scalable consensus method based on stake voting in order to better meet the needs of metaverse applications, achieve a safer consensus process, and effectively improve the scalability and security of the blockchain. On this basis, a consensus system using the safe and scalable consensus method based on stake voting is further provided.

[0008] To this end, the present application provides a safe and scalable consensus method based on stake voting, comprising the following steps:

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

[0010] Step S2, role assignment is performed for the user of the system, and the assigned roles include user, candidate verifier, verifier and leader;

[0011] Step S3, block submission rules are defined, and the master node uses the aggregated signature to construct the quorum certificate from the votes on the block under the condition that the preset generation rule is met , wherein the condition of the preset generation rule is that at least valid votes are received, and the total stake of the received valid votes exceeds ; represents the upper limit number of Byzantine verifiers, represents the total stake value of all verifiers; after the master node of the new view receives timeout messages, a timeout certificate is generated ;

[0012] Step S4, in each epoch, all verifiers in the verifier committee run a 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 submitted by the verifier committee of two consecutive epochs in unison, and the block is taken as a special block to realize dynamic rotation of the verifier committee.

[0014] Further improvement of the application is that the step S1 includes the following sub-steps:

[0015] Step S101, the system model is composed of verifiers, denoted as a set , wherein the total stake of the verifiers is , and the total number of the verifiers is ;

[0016] Step S102, the number of Byzantine verifiers in the fault model does not exceed , and the total stake controlled by all Byzantine verifiers is less than , so as to realize the definition of the fault model;

[0017] Step S103, when the master node receives a message and the corresponding signature from each verifier, the aggregated signature is generated by the formula ; given a message , wherein , the aggregated signature is verified by the public key Verification is performed to achieve the definition of cryptographic primitives.

[0018] Further improvement of the present application is that in the step S2, the user only participates in the block distribution and message forwarding process; all candidate verifiers constitute an election pool of committees, at the beginning of each epoch, a fixed number of verifiers are selected from the election pool according to a preset strategy; the verifiers have the write permission of 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 specifies the corresponding leader.

[0019] Further improvement of the present application is that in the step S3, the master node uses an aggregated signature to build a quorum certificate from the votes on the block The process is as follows: when the master node receives a legal vote of each verifier carrying the stake value, an aggregated signature is generated by the signature of one legal vote , and then the aggregated signature and the list of voting stake values are combined into a quorum certificate . When receiving the quorum certificate , the corresponding block is authenticated, and its freshness is sorted by the view number, and the block and the quorum certificate of the view number are denoted as and .

[0020] Further improvement of the present application is that in the step S3, when the master node of the new view receives timeout messages, the aggregated signature of the highest view quorum certificate in these timeout messages is aggregated, and the generated aggregated signature is spliced with the list of the original highest view quorum certificate and the new view information to form a timeout certificate ; subsequently, the master node of the new view proposes a new block carrying the timeout certificate .

[0021] Further improvement of the present application is that in the step S3, the block submission rule is that the verifier checks the local blockchain, when the highest view quorum certificate and the block pointed to by the highest view quorum certificate 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 quorum certificate ; otherwise, continue to wait until the local blockchain satisfies the double chain rule.

[0022] The further improvement of the present application is that the step S4 comprises the following sub-steps:

[0023] Step S401 is used for implementing leader election, and the consensus process runs in a series of monotonically increasing views, each view is mapped to a unique leader to propose a valid block; when a validator fails to submit a block of view in view , the quorum certificate in the submitted block will be used as the randomness source to determine the leader of view , and the leader is randomly elected from the current validator list according to the weight of the stake; when a validator fails to submit a block of view in view , a polling fallback mechanism will be used to determine the leader of view ;

[0024] Step S402 is used for implementing leader proposal, when the number of votes collected by the leader is not less than , and the stake of a certain number of blocks in high continuity and exceeding , the view number is continuously increased, at this time, the leader of view receives votes from view and aggregates them into a quorum certificate ; then, this quorum certificate is included in the block proposal of view , and broadcasted to other validators;

[0025] Step S403 is used for implementing validator voting, if the received block contains a quorum certificate , the validator verifies the conditions of ; if the block contains a timeout certificate , the validator verifies the aggregated signature of the timeout certificate and the validity of the highest view quorum certificate , first get the corresponding highest view quorum certificate by iterating the view number of each quorum certificate and selecting the highest number, and then confirm whether the block is verified based on the block extension pointed by the highest view quorum certificate ; when the block is verified, the validator accepts the proposal and sends the vote of the block to the leader of the next view; when the block is not verified, 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 view The leader failed, and all honest validators submitted their data to the view. The leader sends a timeout message ; after receiving at least After a timeout message, the view The leader will create a timeout certificate with an aggregate signature. and incorporate it into the view. In the block proposal; new proposal for block extension timeout certificate China's highest view statutory certificate The block it points to defines the parent block of the new proposed block as the timeout certificate. China's highest view statutory certificate The block it points to; via timeout certificate or statutory certificate The leader proved that the proposed block extended the global highest view legal certificate. The block it points to, in order to persuade the validator 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 committees from the epochs vote on the special block and the two blocks following it. The voting formed an era Statutory Certificate From the Era The voting formed an era Statutory Certificate Special blocks in the era Harmony Era The two chains satisfy the double-chain rule.

[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 rule module is used for implementing a block submission rule, and the master node uses an aggregated signature to construct a quorum certificate from the voting on the block under the condition of meeting a preset generation rule When the master node of the new view receives a timeout message, a timeout certificate is generated ;

[0033] The consensus process module is used for running a consensus process by all verifiers in the verifier committee in each epoch to submit blocks in a conflict-free order.

[0034] The epoch change module is used for proposing, by the last leader of the previous epoch, the first block of each epoch, and submitting the block as a special block by the verifier committee of two consecutive epochs, so as to realize dynamic rotation of the verifier committee.

[0035] Compared with the prior art, the beneficial effects of the present application are that a safe and scalable consensus method and system based on stake voting are provided, the stake of the verifier is fully considered in the voting process, not only the stake value is attached to the voting, but also a window-based voting mechanism is realized through the consensus process to increase flexibility, so that the consensus process is more in line with the people-oriented value of the metaverse; at the same time, by modifying the authentication rule for the legal block and modifying the condition for constructing the quorum certificate , a safer consensus process is realized, which can resist all common attack methods in PoS and BFT protocols; on this basis, the dynamic rotation of the verifier committee is realized through the epoch change mechanism, on the one hand, the number of messages in the voting process is reduced 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 the special block, so as to ensure the security of the blockchain. Therefore, the present application not only has good compatibility and is suitable for various application scenarios such as Web3.0 and metaverse, but also is more in line with the actual application requirements of the metaverse, and can realize a safer consensus process, effectively improving the scalability and security of the blockchain. BRIEF DESCRIPTION OF DRAWINGS

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

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

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

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

[0040] Figure 5 Epoch e to epoch e Epoch change example diagram of +1. DETAILED DESCRIPTION

[0041] In the description of the present application, if it involves "several", it means more than one; if it involves "multiple", it means more than two; if it involves "greater than", "less than", "more than", it should be understood as not including the number; if it involves "above", "below", "within", it should be understood as including the number. If it involves "first", "second", etc., it should be understood as only for distinguishing the same or similar technical feature names, and cannot be understood as implying / indicating the relative importance of the technical features, cannot be understood as implying / indicating the number of technical features, and cannot be understood as implying / indicating the sequence of technical features.

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

[0043] The present application first introduces the right into the design of the BFT (Byzantine Fault Tolerance) consensus protocol, and proposes the first human-centered consensus protocol. By modifying the judgment condition of the legal authentication block, a more secure consensus process than the pure BFT and PoS protocol is realized. The epoch change mechanism designed by the present application realizes the dynamic rotation of the committee, and improves the scalability of the blockchain by reducing the number of messages in the voting process. In summary, the present application not only fully considers the self-interest of the voter, but also adds an interest value to the voting, and increases the flexibility of the voting through the sliding window, which is consistent with the actual application scenario of the meta universe. The consensus process is more secure and reliable.

[0044] In order to facilitate the understanding of the essential content of the present application, the related technologies are described and explained first.

[0045] One of the related technical solutions is a consensus protocol based on rights.

[0046] The consensus protocol based on rights, namely PoS protocol, is originally to solve the security problem caused by the concentration of PoW computing power and the energy consumption problem caused by the increase of difficulty value. The core idea of PoS is that the opportunity of the validator to propose a block is proportional to its right value, but it still follows the longest chain rule of Nakamoto consensus framework to realize the probability finality.

[0047] Early PoS protocols include Peercoin and NXT. Peercoin still relies on solving a hash puzzle to generate blocks. Peercoin reduces the attack cost of small stakers; while NXT is the first pure PoS consensus protocol, which solves the problem of staking monopoly from the perspective of incentives. NXT proposes the concept of transparent forging, which makes nodes not rely on staking competition to generate blocks, but only need to wait for the block generation condition to be met over time.

[0048] Early PoS protocols have the problem of the Matthew effect of "the rich get richer" and security problems such as no stake. Therefore, chain-based proof of stake is proposed as an alternative mechanism. Chain-based proof of stake adopts an ordered block generation mechanism, usually using a multi-party secure computation process to determine the block proposal committee, and the validators in it 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, and each epoch is subdivided into slots, and a leader is randomly selected for each slot to generate blocks. However, Ouroboros has two security problems, one is that it is vulnerable to step attack due to strict network synchronization requirements, and the other is that it is vulnerable to adaptive destruction attack on time slot leaders because the sequence of leaders in the next epoch is known to all network participants. Ouroboros Praos aims to solve these two security problems of Ouroboros. First, Ouroboros Praos is designed for partially synchronous networks, which allows a maximum delay of 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 next epoch block proposal slots, which are verified by the corresponding VRF proof. Snow White is a PoS protocol specially designed to adapt to the intermittent participation model, in which nodes can switch online / offline at will. Snow White implements a modified version of the sleep consensus protocol, which is an asynchronous consensus protocol that can ensure consensus security in the case of intermittent participation and committee reconfiguration. In addition, Snow White uses a checkpointing scheme to finally determine the previous history to protect the blockchain from subsequent destruction attacks and adaptive key selection attacks.

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

[0050] Another related technical scheme is a voting-based consensus protocol.

[0051] The voting-based consensus protocol is to reach consensus through the transmission and verification of voting messages between nodes. PoV is a high-performance voting consensus protocol suitable for permissioned chains, which introduces four roles, namely committee, janitor, janitor candidate and ordinary user, however, PoV protocol only tolerates crash faults and cannot tolerate Byzantine errors, because 51% of the committee's votes in PoV protocol are sufficient to authenticate a block.

[0052] In the blockchain scenario, a voting consensus protocol that is Byzantine fault-tolerant is needed. Byzantine fault-tolerant protocols are derived from the Byzantine Generals Problem proposed by Lamport. PBFT is the first Byzantine fault-tolerant protocol that reduces communication complexity from exponential to polynomial (O ) under normal conditions. The HQ protocol proposed in 2006 further improves the efficiency of PBFT, and HQ uses a lightweight protocol based on quorum in the absence of contention (communication complexity is O ). However, HQ may revert to PBFT to solve contention. Zyzzyva uses speculation to minimize costs, but clients need to detect inconsistencies and help replicas agree on a single total order of requests. In addition, the view change communication complexity of HQ and Zyzzyva is Sphinx is also a PBFT-based consensus protocol, 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 pipelined confirmation mechanism, and also proposes a rollback mechanism to resist fork attacks. HotStuff achieves optimistic responsiveness and linear view changes by introducing an additional round in the classic two-round BFT protocol, but this additional communication round results in higher latency. Fast-HotStuff reduces latency by adopting a two-round voting mechanism and provides a method to prevent Byzantine leader nodes from performing fork attacks. Both HotStuff and Fast-HotStuff draw on the chain structure of blockchains, streamlining all stages through a unified proposal voting mode, thereby significantly simplifying the protocol and improving throughput. HoneyBadgerBFT is the first practical asynchronous BFT protocol, but its communication complexity is Moreover, the partially synchronous network assumption is more reasonable for blockchain scenarios.

[0053] Therefore, the related technical solutions have the following technical problems: The voting-based consensus protocol achieves consensus by transmitting and verifying voting messages. However, the PoV protocol only tolerates crash faults and cannot cope with Byzantine errors, which is a significant drawback in the blockchain environment. Although PBFT, HQ, and HoneyBadgerBFT protocols can tolerate Byzantine faults, 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 an additional communication round, but also increases latency, thereby affecting overall performance. These performance problems result in poor scalability or increased consensus latency in large-scale networks, especially for protocols with high communication complexity. VaaP, HotStuff, and Fast-HotStuff use a pipelined processing mechanism to significantly simplify the protocol and improve throughput. However, they simply use a one-person-one-vote voting mechanism, which cannot truly reflect the voting intentions and weight of validators, and are more susceptible to Sybil attacks. In summary, existing voting-based consensus protocols face security challenges, affecting the fairness and effectiveness of consensus, and cannot be directly applied to the meta-universe, an actual application scenario.

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

[0055] Hybrid equity and voting consensus protocols improve scalability by introducing a committee of delegates to reduce the communication size of the consensus process. The first hybrid consensus protocol proposed is Delegated Proof of Stake (DPoS). DPoS works similarly to a democratic system, where shareholder nodes delegate their equity to other witnesses through voting, and the top-ranked witnesses are elected as committee members, which are responsible for validating transactions and building blocks in a predefined order. The transaction fees of the validated blocks are then distributed among the witnesses according to their investment proportion.

[0056] The main extension of DPoS consensus is to introduce BFT algorithms into the design of PoS protocols. Specifically, the consensus process of Tendermint runs on a committee of validators with staked equity, where validators are selected as block proposers according to their staked equity proportion, and each block needs to go through multiple rounds of BFT voting process before being finally confirmed. Algorand generates new blocks through a fast binary Byzantine agreement (BA*) and selects a small subset of all nodes as participants of BA* using a verifiable random function. PoPT selects a subset of nodes as participants of the consensus process according to their contribution 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 use the rule of one person one vote in the voting process, which leads to the BFT algorithm only playing a role in sorting, and cannot effectively reflect the value difference 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, which realizes the final confirmation of checkpoint blocks through equity voting on checkpoints. However, the final confirmation takes a long time, about once every 100 blocks, which may provide opportunities for some common attacks.

[0058] The related technical scheme has the following technical problems: the consensus protocol of mixed equity and voting reduces the communication complexity by introducing the authorized committee, thereby improving the scalability of the blockchain network, but still faces significant shortcomings. First, DPoS may lead to power concentration in committee election, and the monopoly of a few nodes weakens the decentralization characteristics of the system, greatly reduces the attack cost of attackers, and small equity holders may lack sufficient incentives to participate in governance and voting. Second, most consensus protocols with mixed equity and voting, such as DPoS, Tendermint and Algorand, simply adopt a one-person-one-vote voting rule. This lack of differentiated voting mechanism makes the BFT algorithm only serve as an ordering function, failing to effectively reflect the differences in equity and contribution among validators, which may affect the fairness and effectiveness of decision-making. Finally, CasperFFG as a lightweight proof-of-stake consensus layer, but it takes a long time to finalize the block (about once every 100 blocks PoS voting), which may provide opportunities for some common attacks. In summary, the existing consensus protocols with mixed equity and voting still have shortcomings in security and fairness, which cannot meet the needs of the meta-universe application scenario.

[0059] With the continuous development of the global meta-universe, how to effectively build a secure and scalable blockchain consensus protocol in this virtual shared space has become a pressing technical problem. The meta-universe combines the multi-dimensional characteristics of the physical, human and digital worlds, while blockchain has the characteristics of decentralization, tamper resistance and transparency, and has become an important infrastructure for storing and protecting user digital content in the meta-universe. Therefore, the blockchain consensus protocol is a key technology to ensure the security and performance of the meta-universe application. Existing blockchain consensus protocols, such as PoW, have problems such as high energy consumption and low efficiency, and PoS has problems such as equity concentration risk and no stake. Existing voting-based consensus protocols or existing consensus protocols with mixed equity and voting only simply adopt a one-person-one-vote rule, which does not meet the actual application needs of the meta-universe.

[0060] To this end, the embodiment aims to provide a safe and scalable consensus method and system based on stake voting, namely Stake Voting Protocol, SVP or SVP protocol for short, focusing on meeting the practical application requirements of metaverse blockchain in humanistic values, security and scalability. The stake voting protocol (SVP) proposed in the embodiment fully considers the stake of the verifier in the voting process of the BFT protocol, adds a stake value to the voting, and increases the degree of freedom through a sliding window-based voting mechanism, thereby realizing a true sense of "voting". The embodiment modifies the judgment condition of the authenticated legal block in the two-stage BFT protocol of the pipeline, and proposes a consensus process that is more secure than the pure BFT and PoS protocol, taking into account the willingness of high-stake verifiers and low-stake verifiers. On this basis, the embodiment further designs a epoch change mechanism to realize the dynamic rotation of the verifier committee, ensuring the security and scalability of the protocol.

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

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

[0063] Step S1, defining a system model, including defining a fault model and a cryptography primitive;

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

[0065] Step S3, defining a block submission rule, under the condition of meeting a preset generation rule, a main node uses an aggregated signature to construct a quorum certificate from the voting on the block , wherein the condition of the preset generation rule is that at least legal votes are received, and the total stake of the received legal votes exceeds ; , wherein n represents the upper limit number of Byzantine verifiers, represents the total stake value of all verifiers; after the main node of the new view receives timeout messages, a timeout certificate 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, assume the system model is composed of The set consists of 10 validators. The total equity of the validators is The total number of validators is ;

[0071] Step S102, the number of Byzantine verifiers in the fault model does not exceed The total power held by all Byzantine validators is less than [number missing]. This is to achieve the definition of the fault model;

[0072] Step S103, when the master node receives data from each validator information and its corresponding signature At that time, through the formula Generate aggregate signature Given message ,in Through public key The verifier verifies the aggregate signature. Verification is performed to achieve the definition of cryptographic primitives.

[0073] More specifically, in the fault model, consider a fault caused by... A system consisting of 10 validators is denoted as set. The total equity of the validators is At most Each validator is Byzantine in nature, and the total power held by all Byzantine validators is less than [amount missing]. Byzantine validators may act arbitrarily, while honest validators always adhere to the agreement.

[0074] In the network model, this embodiment adopts a partially synchronized model, in which there exists a known limit. and an unknown global stabilization time (GST). After GST, all transmissions between two correctly validated nodes will arrive within time The consensus protocol of the embodiment will always ensure safety and guarantee progress within a limited time after GST.

[0075] In the cryptographic primitives, when the primary node fails, the embodiment uses an aggregated signature to generate a single collective signature of constant size instead of appending all the validators' signatures. The process is as follows: when the primary node receives a message from each validator and its corresponding signature , it uses this information to generate an aggregated signature . Given a message , where , the aggregated signature and the public key , the validator can verify the aggregated signature . In addition, the attacker is computationally constrained and cannot forge signatures or message digests with negligible probability, thus, the security performance can also be guaranteed.

[0076] The step S2 described in the embodiment is used to implement role allocation.

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

[0078] User: can join or leave the network at will, but can only participate in block distribution and message forwarding processes, and cannot participate in the consensus process.

[0079] Validator candidate: all validator candidates constitute an election pool for 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. The default election strategy for the committee in the embodiment is a random strategy to ensure that each candidate validator has an equal probability of being selected; in actual applications, other preset strategies can be replaced.

[0080] Validator: the validator committee has the write permission 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 according to the stake they hold, and validators holding larger stakes have greater influence on the governance of the blockchain.

[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). This involves setting a pre-defined generation rule (for the pre-defined quorum certificate). The conditions for the generation rule are: upon receiving at least There are 100 legal votes, and the total value of these legal votes received exceeds 100%. At that time, construct statutory certificates It is worth noting that, unlike related technical solutions, this embodiment uses authentication rules for legitimate blocks (i.e., legal certificates). The generation rule is modified to: at least receive at least There are 100 legal votes, and the total equity of legal votes is greater than 100%. 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 master node uses aggregate signatures to construct a legal certificate from the votes on the blocks. The process is as follows: when the master node receives each validator Legitimate voting with carry-on equity value At that time, through A valid signature for a vote Generate aggregate signature Then by aggregate signature Combined with the list of voting rights values, it forms a statutory certificate. When a legal certificate is received If the corresponding block is verified, its freshness is sorted by view number, where the view number is... The blocks and legal certificates are represented as follows: and .

[0085] Specifically, the SVP protocol uses the legal certificate with the highest view number known to the validator. Called The SVP protocol modifies the statutory certificates in the BFT protocol. The generation rules require that not only at least In addition to the number of legitimate votes, it is also necessary to ensure that the total value of these legitimate votes exceeds [a certain threshold]. That is, the window equity value exceeds , and thus effectively enhances the security of the consensus process. The window refers to a highly continuous preset number of blocks, the size of which is represented by , which can be set and adjusted according to actual conditions and requirements.

[0086] Timeout Certificate (TC): When a validator abandons the current view, it broadcasts a timeout message containing its quorum certificate and the signature of the highest view quorum certificate . In step S3 of the embodiment, when the primary node of the new view receives the timeout message, the highest view quorum certificate signature in the timeout message is aggregated to generate an aggregated signature, which is spliced with the new view information and the original highest view quorum certificate to form a timeout certificate ; then, the primary node of the new view proposes a new block carrying the timeout certificate ; the quorum certificate provides proof of the highest view quorum certificate of the block extension global view, and the highest view quorum certificate of the global view is the latest quorum certificate held by the majority of validators, or the latest quorum certificate held by the majority of validators with a higher view number.

[0087] In the block submission rule, chain and direct chain are also involved.

[0088] Chain: Blocks of different heights are linked together to form a block chain through hashing and quorum certificates . In addition to the genesis block, each block must contain the Hash of the parent block and the quorum certificate of the parent block. The latest BFT protocol greatly simplifies the protocol through pipelined chain processing, because voting for a block now also votes for all uncommitted ancestor blocks. Block chains may have forks, as shown in Figure 3 , block is neither a predecessor nor an ancestor of block , and block is neither a predecessor nor an ancestor of block , so blocks and are conflicting, but they have a common fork vertex block .

[0089] Direct Chain: If a block is added on top of another block , denoted as , then the two blocks form a single chain. If another block is added on top of block , then , and form a double chain, and so on. There are two ways in which the blockchain grows. First, the chain grows in a continuous manner, in which the view numbers of two consecutive blocks are also consecutive. For example, for two blocks and , if and , then there is a single direct chain between blocks and . If , , , and , then it can be determined that there is a double direct chain between blocks , and , i.e., blocks , and satisfy the double chain rule. Second, two views can fail to generate blocks due to a Byzantine master node or network failure, in which case , where , and , then it can be said that there is no direct chain between and .

[0090] Commit Rule: The commit rule of the block in the embodiment is modified based on the BFT protocol of the two-stage commit pipeline. Specifically, the block commit rule of step S3 in the embodiment is as follows: the validator checks the local blockchain, and when the highest view quorum certificate and the block pointed to by the highest view quorum certificate and its parent block form a double chain, and the first chain is a single direct chain, the validator submits the parent block of the block pointed to by the highest view quorum certificate . As shown in Figure 2 , blocks , and form a double chain, and blocks and form a single direct chain, so block can be safely submitted.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 mapped to a unique leader to propose a valid block; when an honest validator in a view... Received containing legal certificate The block and submitted the view When submitting a block, the legal certificate in the submitted block... Will be used as a defined view The randomness of the leader comes from the fact that the leader is randomly elected from the current list of validators according to a stake-weighted random selection; when a validator is in the view... Failed to submit view When the validator is in a block, for example, in the view The view failed to be submitted due to Byzantine behavior, crashes, or message delays. The blocks will use a polling rollback mechanism to determine the view. The leader.

[0095] Step S402 is used to implement the leader's proposal. This occurs when the leader has collected no fewer than [number missing] votes. And ensure the rights and interests of the window and more At this time, it belongs to the normal path. Under the normal path, the view number increases continuously. At this time, the view... The leader from the view Receive votes and aggregate them into legal certificates Subsequently, this statutory certificate Included in the view The block proposal is included and broadcast to other validators.

[0096] A window refers to a pre-defined number of highly continuous blocks, the size of which is specified by [reference needed]. This indicates that the preset quantity can be set and adjusted according to actual conditions and needs. When this embodiment mentions height... blocks When referring to a window, it means from the height to altitude The total A view's timer timed out, indicating a masternode failure and causing gaps in the blockchain's view sequence. This could be due to a masternode crash or insufficient votes or stake in a previous view. If the view... If the leader fails, all honest validators will report to the view. The leader sends a timeout message After receiving at least After a timeout message, the view The leader will create a timeout certificate with an aggregate signature. and incorporate it into the view. In the proposed block, the new proposed block requires an extended timeout certificate. China's highest view statutory certificate The block it points to, i.e., the parent block of the newly proposed block, should be the timeout certificate. China's highest view statutory certificate The block it points to. (Passed through timeout certificate) or statutory certificate The leader can prove that the proposed block extends the global block. The block it points to, thereby persuading the validator to approve the block. For example... Figure 4 As shown, view and view There were no failures, allowing the block proposal to contain only legal certificates. However, view The leader malfunctioned, causing the view The leader proposed a system that includes timeout certificates. The block.

[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 way. If the received block... Includes statutory certificates The verifier needs to verify. The conditions. If the block Includes timeout certificate The verifier's certificate verification timed out. Aggregate signature and highest view statutory certificate The validity of the certificate is first determined by iterating through each legal certificate. Select the highest view number and obtain the corresponding highest view legal certificate. Then the validator confirms the block. Is it based on the highest view statutory certificate? The verification is performed by pointing to a block extension; when the block The verification is valid, i.e., the block is valid. Based on the highest view statutory certificate If the block being pointed to is extended, then the validator accepts the proposal and adds it to the block. The vote is sent to the leader of the next view; when the block The verification was invalid; the verifier rejected the proposal and discarded the block. .

[0098] Unlike the BFT protocol, this embodiment incorporates the validator's stake into the voting data structure. Validators can determine the stake value for each vote; the protocol itself only restricts a validator's voting stake 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 legal certificate of the next block in a timely manner. However, even in the event of such an invalid vote, the validator can still reuse this stake value in the next round of voting. Figure 4 As shown, upon receiving the block At that time, the verifier From timeout certificate Extract the highest view legal certificate At this time, the statutory certificate Selected as the highest view statutory certificate When the window size When set to 3, in order to determine the legal certificate The validity of the verifier It is necessary to confirm the construction of statutory certificates. The number of votes exceeded (Right now ), and statutory certificates Statutory Certificate and legal certificates Total equity value exceeds If a statutory certificate Valid, verifier Will the block Voting. Additionally, validators... They can freely exercise their rights Assigned to blocks Block and blocks The vote. Validator The equity value, It 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] like Figure 4 As shown, in the block Block and blocks A two-chain structure was formed between them, and the blocks and blocks They form a single direct chain, therefore the validators Submit block now Based on 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, according to the security proof, if a block is committable, then all blocks preceding that block have reached consensus on all nodes, thus allowing for recursive submission. If a block is submitted due to the satisfaction of the dual-chain rules... If the block is..., then it is called a direct commit. Because of directly submitting the extension Submitting a block directly into another block 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] like Figure 5 As shown, epoch The last leader proposed a special block containing the epoch. The initial stake value of all validators in the block. Special blocks can also carry transactions like regular blocks. 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. Epoch The committee cannot immediately withdraw after a special block is proposed because the block 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. Among them, the committees from the epoch... The voting formed an era Statutory Certificate Based on the modified construction of legal certificates On the basis of these conditions, ensure the unanimous withdrawal of the old committee; from the era The voting formed an era Statutory Certificate This facilitated and ensured the legitimate establishment of the new committee. Special blocks in the epoch... Harmony Era The two-chain rules are met, ensuring conflict-free submission of special blocks and 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 legal certificates from the votes on blocks. When the main node of the new view receives After a timeout message is received, a timeout certificate is generated. ;

[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] To sum up, the embodiment provides a safe and scalable stake-based voting consensus method and system, which exhibits significant benefits in multiple aspects. First, the embodiment fully considers the stake of the verifier in the voting process, not only attaching a stake value to the voting, but also implementing a window-based voting mechanism through the consensus process to increase flexibility, making the consensus process more in line with the actual application requirements of the metaverse. Second, the embodiment modifies the authentication rules for legal blocks, modifies the conditions for constructing a legal certificate , i.e., requiring the number of votes collected by the main node to be no less than and the window stake value to exceed , to aggregate these votes into an effective legal certificate , so that the embodiment can resist all common attack methods in PoS and BFT protocols, enhancing the security of the consensus process. Third, the embodiment also implements dynamic rotation of the verifier committee through the epoch change mechanism. On the one hand, it reduces the number of messages in the voting process to improve the scalability of the blockchain, and on the other hand, it implements a conflict-free submission of special blocks to achieve a safe transfer of power between the old and new committees, thereby ensuring the security of the blockchain. Fourth, the invention not only has good compatibility, but is suitable for a variety of application scenarios such as Web3.0 and the metaverse, i.e., suitable for building the underlying blockchain of Web3.0 and the metaverse, can seamlessly integrate with existing blockchain technologies, so as to be more in line with the actual application requirements of the metaverse, effectively improving the scalability and security of the blockchain.

[0112] The above is a further detailed description of the present invention in combination with a specific preferred embodiment, and the specific implementation of the present invention cannot be limited to these descriptions. For ordinary skilled persons in the technical field to which the present invention belongs, without departing from the concept of the present invention, a number of simple deductions or substitutions can be made, which should be considered within the scope of protection of the present invention.

Claims

1. A safe and scalable consensus method based on equity voting, characterized in that, The method comprises the following steps: 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, defining a block submission rule, under the condition of meeting a preset generation rule, the master node uses an aggregated signature to construct a quorum certificate from the votes on the block , wherein the condition of the preset generation rule is that at least valid votes are received, and the total stake of the received valid votes exceeds ; represents the upper limit number of Byzantine validators, represents the total stake value of all validators; after the master node of the new view receives timeout messages, a timeout certificate is generated ; Step S4, in each epoch, all verifiers in the verifier committee run a consensus process to submit blocks in conflict-free order; Step S5, the first block of each epoch is proposed by the last leader of the previous epoch and is submitted by the verifier committee of two consecutive epochs in agreement, taking this block as a special block to realize dynamic rotation of the verifier committee; The step S1 comprises the following sub-steps: Step S101, assuming that the system model is composed of a group of validators, denoted as set , wherein the total stake of the validators is , and the total number of the validators is ; Step S102, the number of Byzantine verifiers in the fault model is not more than , and the total amount of rights controlled by all Byzantine verifiers is less than , to achieve the definition of the fault model; Step S103, when the main node receives the message from each validator and their respective signatures , it generates an aggregated signature by the formula ; given the message , where , the validators verify the aggregated signature by the public key to implement the definition of the cryptographic primitive; In step S3, the master node uses aggregate signatures to construct a legal certificate from the votes on the block. The process is as follows: when the master node receives each validator Legitimate voting with carry-on equity value At that time, through A valid signature for a vote Generate aggregate signature Then by aggregate signature Combined with the list of voting rights values, it forms a statutory certificate. When a legal certificate is received If the corresponding block is verified, its freshness is sorted by view number, where the view number is... The blocks and legal certificates are represented as follows: and ; In step S3, when the master node of the new view receives... After receiving a timeout message, the highest-ranking legal certificate among those timeout messages will be used. The signatures are aggregated, and the generated aggregated signature is combined with the new view information and the original highest view legal certificate. The list is concatenated to generate the timeout certificate. Subsequently, the master node of the new view proposes a certificate carrying the timeout certificate. The new block; The block submission rule of the step S3 is: checking the local blockchain by the validator, when the highest view quorum certificate and the block pointed by the highest view quorum certificate and its parent block form a double chain, and the first chain is a single direct chain, the validator submits the parent block of the block pointed by the highest view quorum certificate ; otherwise, continue to wait until the local blockchain satisfies the double chain rule; The step S4 comprises the following sub-steps: Step S401 is used to implement leader election. The consensus process runs through a series of monotonically increasing views, each view being mapped to a unique leader to propose valid blocks; when a validator in a view... Received containing legal certificate The block and submitted the view When submitting a block, the legal certificate in the submitted block Will be used as a defined view The randomness of the leader comes from the fact that the leader is randomly elected from the current list of validators according to a stake-weighted random selection; when a validator is in the view... Failed to submit view When determining the block, a polling rollback mechanism will be used to determine the view. The leader; Step S402, for realizing leader proposal, when the number of votes collected by the leader is not less than , and the rights of a certain number of blocks with high continuity and more than , the view number is continuously increased, at this time, the view of the leader receives votes and aggregates them into a quorum certificate ; subsequently, this quorum certificate is included in the block proposal of the view , and broadcast to other validators; ​ Step S403 is used to realize the verifier voting, if the received block contains the quorum certificate , the verifier verifies the condition; if the block contains the timeout certificate , the verifier verifies the validity of the aggregated signature of the timeout certificate and the highest view quorum certificate , first, by iterating the view number of each quorum certificate and selecting the highest number, the corresponding highest view quorum certificate is obtained, and then it is confirmed whether the block is verified based on the block extension pointed to by the highest view quorum certificate ; when the block is verified, the verifier accepts the proposal and sends the vote on the block to the leader of the next view; when the block is invalid, the verifier rejects the proposal; Step S404, the verifier locally checks whether the blockchain satisfies the double-chain rule until yes, and judges that the formation of the double chain is checked and the block is submitted; In step S5, the committees of both consecutive epochs vote on the special block and the two blocks following it; among them, the committees from the epochs vote on the special block. The voting formed an era Statutory Certificate From the Era The voting formed an era Statutory Certificate Special blocks in the era Harmony Era The two chains satisfy the double-chain rule.

2. The secure and scalable stake-based voting consensus method according to claim 1, wherein, In the step S2, the user only participates in the block distribution and message forwarding process; all candidate verifiers constitute an election pool of the committee, and at the beginning of each epoch, a fixed number of verifiers are selected from the election pool according to a preset strategy; the verifier has the write permission of 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.

3. The secure and scalable stake-based voting consensus method according to claim 1 or 2, characterized in that, In step S402, if the view The leader failed, and all honest validators submitted their data to the view. The leader sends a timeout message ; after receiving at least After a timeout message, the view The leader will create a timeout certificate with an aggregate signature. and incorporate it into the view. In the block proposal; new proposal for block extension timeout certificate China's highest view statutory certificate The block it points to defines the parent block of the new proposed block as the timeout certificate. China's highest view statutory certificate The block it points to; via timeout certificate or statutory certificate The leader proved that the proposed block extended the global highest view legal certificate. The block it points to, in order to persuade the validator to approve the block.

4. A secure and scalable consensus system based on stake voting, characterized in that, The method comprises the following steps: A system model defining module is configured to define a system model, including defining a fault model and cryptographic primitives; A role assigning module is configured to assign roles to users of the system, including users, candidate verifiers, verifiers, and leaders; 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 legal certificates from the votes on blocks. When the main node of the new view receives After a timeout message is received, a timeout certificate is generated. ; A consensus process module is configured to, in each epoch, all verifiers in the verifier committee run a consensus process to submit blocks in conflict-free order; An epoch changing module is configured to, the first block of each epoch is proposed by the last leader of the previous epoch and is submitted by the verifier committee of two consecutive epochs in agreement, taking this block as a special block to realize dynamic rotation of the verifier committee.

Images