Efficient hierarchical parallel Byzantine consensus method based on hybrid protocol

Abstract

The invention discloses a hybrid protocol-based efficient hierarchical parallel Byzantine consensus method, which comprises the following steps of: constructing network nodes into a plurality of consensus groups capable of processing transactions in parallel and a verification group responsible for sequencing and confirming global transactions of a system, and introducing a self-adaptive hybrid consensus protocol mechanism into each consensus group, dynamically switching between a two-stage protocol and a three-stage protocol according to a network state; an efficient protocol switching and state fallback algorithm under parallel fragmentation is designed, when a protocol is switched from a two-stage to a three-stage, the safety fallback and data consistency of a consensus state can be ensured, and the robustness of system operation is ensured; each consensus group submits the transaction batch subjected to intra-group consensus preliminary processing to a verification group; the verification group globally sorts and verifies the transaction batches from all the consensus groups, and blocks are finally generated in sequence; and the block is broadcasted and distributed to all consensus groups, and each consensus group performs final verification and state submission on the block to complete a round of complete global consensus. According to the method, the problems of high communication complexity and insufficient expansibility are solved, and the consensus process parallelism and the overall operation efficiency are improved under Byzantine fault tolerance.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchain consensus, in particular to an efficient hierarchical parallelization Byzantine consensus method based on a hybrid protocol. BACKGROUND

[0002] As a revolutionary distributed ledger technology, blockchain technology is changing many industries with its characteristics of decentralization, data tamper resistance, openness and transparency. The core of blockchain is its distributed consensus mechanism. In a distributed network without a centralized trust authority, the consensus mechanism ensures that all participating nodes can reach an agreement on the order and validity of transactions, which is the cornerstone of ensuring the consistency, security and liveness of the blockchain system.

[0003] Among many consensus mechanisms, Byzantine fault-tolerant protocol has been widely used due to its high security and fast determinacy. Byzantine fault-tolerant protocol aims to solve the "Byzantine Generals Problem", that is, how to make honest nodes reach the correct consensus in a distributed network with malicious or faulty nodes (Byzantine nodes). Unlike probabilistic consensus mechanisms such as proof of work, Byzantine fault-tolerant protocol has lower transaction latency. Among them, practical Byzantine fault tolerance (PBFT) algorithm is the most representative classic protocol in the Byzantine fault-tolerant family. PBFT introduces a "three-phase" communication protocol of pre-preparation, preparation and submission, which can guarantee the security and liveness of the system when there are no more than Byzantine nodes in the network, where n is the total number of nodes in the system. The introduction of this algorithm has made Byzantine protocol go from theory to practical application.

[0004] However, with the continuous deepening of the application scenarios of blockchain technology and the continuous expansion of the network scale, the traditional Byzantine fault-tolerant consensus protocol represented by PBFT gradually exposes its inherent and difficult-to-overcome limitations, which have become the main technical bottlenecks restricting the performance and application landing of large-scale blockchain systems.

[0005] The classic PBFT protocol has high communication complexity, which requires full network broadcast in each phase of consensus. In a network containing n nodes, the number of communication messages generated by a complete consensus process in one round is proportional to the square of the number of nodes, that is, the communication complexity is as high as O(n 2). When the number of network nodes increases from tens to hundreds or even thousands, the number of consensus messages that need to be processed and transmitted in the network will increase exponentially, which not only causes huge network bandwidth congestion, but also puts a heavy burden on the calculation and verification of each node, thereby sharply reducing the overall performance of the system. High communication complexity directly leads to low consensus efficiency. Nodes need to spend a lot of time waiting, receiving and verifying messages from all other nodes in the network, making the time-consuming of a single consensus longer. At the same time, the traditional Byzantine fault-tolerant consensus process is usually executed in series, i.e. the consensus of a block must be completely reached before starting the consensus of the next block. This single-threaded, serial processing mode makes the transaction throughput of the system have an obvious upper limit, and it is difficult to meet the needs of high-frequency application scenarios such as financial transactions and large-scale Internet of Things data on-chain.

[0006] The above two problems together cause the inherent defect of Byzantine fault-tolerant protocol in scalability. This negative correlation between performance and number of nodes forces system designers to make a difficult trade-off between decentralization, security and system performance. To overcome the above challenges, the prior art has made a series of explorations.

[0007] For example, patent CN118509158A discloses an optimization method and system for PBFT alliance blockchain consensus mechanism, the core of which is to build a "temporary committee" to optimize the view switching and master node election process, mainly solving the recovery efficiency problem when the master node fails, but failing to solve the bottleneck of parallel processing transactions in the normal consensus process to improve system throughput.

[0008] For example, patent CN118677906A discloses a grouping Byzantine fault-tolerant consensus method based on aggregated signature, which adopts a hierarchical idea of grouping and proxy nodes, but the election and grouping of nodes highly depend on a complex reputation value evaluation model, which itself may introduce additional computational overhead and attack risk.

[0009] For example, patent CN116170155A discloses an improved PBFT-based alliance blockchain consensus method, which optimizes the communication in the submission phase through a random matching algorithm, but this method is essentially still an optimization within a single consensus cluster, and its scalability is limited, making it difficult to apply to large-scale node networks.

[0010] For example, patent CN116455549A discloses a blockchain sharding consensus optimization method based on aggregated signature, which uses sharding technology and aggregated signature to optimize PBFT consensus to some extent, but its sharding architecture is a flat structure and does not form a hierarchical design with different responsibilities, which is inflexible and inefficient in dealing with complex network environment changes.

[0011] In summary, the prior art scheme focuses only on process optimization within a single consensus cluster, and cannot fundamentally solve the scalability bottleneck of large-scale networks; or uses a fixed hierarchical and consensus strategy, lacks adaptive ability to dynamically adjust according to the real-time state of the network, and is difficult to always balance running efficiency and system security in a changing network environment. Although some schemes introduce hierarchical or sharding ideas to improve performance, they often result in new serialization dependencies due to the close coupling between layers or shards, and fail to achieve truly efficient parallel processing. SUMMARY

[0012] The purpose of the present application is to solve the problems existing in the prior art and provide an efficient hierarchical parallelization Byzantine consensus method based on a hybrid protocol, which realizes efficient, scalable and secure Byzantine consensus in a large-scale distributed network environment.

[0013] Technical scheme: An efficient hierarchical parallelization Byzantine consensus method based on a hybrid protocol, comprising the following steps:

[0014] Step 1, constructing network hierarchy and dividing roles

[0015] The network hierarchy includes a parallel processing layer and a global verification layer. The parallel processing layer refers to dividing the corresponding nodes in the blockchain into a plurality of consensus groups responsible for parallel processing of transactions. The global verification layer refers to dividing the corresponding nodes in the blockchain into a master verification group responsible for final ordering and confirmation of global transactions.

[0016] The method for dividing roles is that each consensus group in the parallel processing layer is provided with a master node and a plurality of slave nodes, and the total number of nodes n and the number of tolerable Byzantine nodes f satisfy n≥3f+1. In the global verification layer, the member nodes of the master verification group include the master nodes of all consensus groups, and can optionally include other pre-set high-trust nodes.

[0017] Step 2, performing adaptive hybrid consensus within the group

[0018] An adaptive hybrid consensus protocol mechanism is designed within the consensus group and the verification group. The adaptive hybrid consensus protocol mechanism has a protocol switching and rollback algorithm built in. According to the network state switching condition, the protocol switching and rollback algorithm is called to realize the dynamic switching of the two-phase consensus protocol (high efficiency) and the three-phase consensus protocol (high security) (this mechanism includes two-phase / three-phase consensus process, switching condition and protocol switching and rollback algorithm three parts). The protocol switching and rollback algorithm is used to ensure the safety of the consensus state when switching protocols. When the condition for switching from the two-phase consensus protocol to the three-phase consensus protocol is met, the consistency and safety of the system state are ensured.

[0019] When the protocol switching and fallback algorithm switches the two-stage consensus protocol to the three-stage consensus protocol, the following steps are specifically performed:

[0020] Step 2.1, view switching, that is, view switching messages are exchanged between nodes in the group, and a new master node is elected based on a preset election strategy through interaction among the nodes in the group;

[0021] Step 2.2, consensus isolation, that is, the consensus group and the verification group triggered by switching interact, so that the transactions to be processed are temporarily isolated from the global consensus process;

[0022] Step 2.3, state synchronization, that is, the consensus group completes the synchronization of its internal state in the isolation state, and aligns the local state according to the global system state obtained from the verification group;

[0023] Step 2.4, consensus recovery, that is, after the local state of the consensus group and the global state reach an agreement, the global consensus process is re-joined by requesting and obtaining permission from the verification group;

[0024] Step 3, performing inter-group parallel layered consensus

[0025] The consensus group submits the transactions processed by the group to the verification group; the verification group globally sorts and verifies the transactions received from each consensus group, and forms a final block through consensus; and the verification group distributes the final block to each consensus group, and each consensus group performs final verification and state confirmation on the block.

[0026] The layered parallel architecture design solves the problems of high communication complexity and insufficient scalability faced by the traditional Byzantine consensus; by introducing an adaptive hybrid consensus protocol and a secure fallback mechanism, the parallelism and overall running efficiency of the consensus process are improved under Byzantine fault tolerance, achieving dynamic balance between efficiency and security in different network environments, and significantly improving the transaction throughput and user experience of the blockchain system.

[0027] Further, in the step 1 global verification layer, in addition to the master verification group, a standby verification group is also provided, and the master verification group is responsible for verification and sorting when the parallel processing layer requests; when the master node of the master verification group has a Byzantine error and needs to be replaced, the standby verification group takes over the function of global consensus to ensure the continuity of consensus service;

[0028] To realize the layered fault tolerance and efficient governance, the master node of each consensus group and the master node p v of the verification group in the system need to initialize and distribute two threshold signature public and private key pairs with different threshold values for the members in the group. One set of public and private key pairs {pk i,1 ,ski,1 ,} for two-phase protocol (i denotes the index of the node to which the key pair belongs), threshold t = 3f + 1; another set of public and private key pair {pk i,2 ,sk i,2} for three-phase protocol, threshold t = 2f + 1.

[0029] For each set of key pair, the master node calculates and distributes its independent private key share to each member node through a secure secret sharing protocol. After completing the secure distribution of all key shares, the master node immediately destroys all master secrets and polynomial coefficients used to generate the shares, thereby ensuring that the control of the key is completely decentralized among the members of the group.

[0030] Further, the dynamic network state switching conditions in the adaptive hybrid consensus protocol mechanism include the following two aspects:

[0031] 1) If the master node can receive a preset threshold number of signatures, it is determined that the current network communication is stable, and then switches to a two-phase consensus protocol to maximize consensus efficiency and system throughput;

[0032] 2) If the master node does not receive a preset threshold number of signatures or there is suspected abnormal behavior such as Byzantine behavior, it is determined that the current network is congested or unstable, and then switches to a three-phase consensus protocol to enhance the security and fault tolerance of the system in harsh environments; Byzantine behavior includes intentionally not responding after receiving information, selectively ignoring requests from legitimate clients, replay attacks, forging client content, and double proposals, and different behaviors have different determination methods; For example, if the master node intentionally does not respond after receiving information, the consensus timeout will be triggered, and the slave node will determine that the master node has Byzantine behavior; For example, replay attack, when the slave node receives a request that has been consensus, the slave node will also determine that the master node has Byzantine behavior.

[0033] Further, the view switching specifically includes the following steps:

[0034] (1) Trigger and broadcast view switching request: any node in the consensus group broadcasts a view switching message to all other nodes in the group when it monitors that the master node times out or meets the preset failure condition. The message at least contains the new view number v+1 proposed by the node and the proof of the latest proposal set in the prepared state known by the node;

[0035] (2) Collect and verify view switching messages: each node in the group collects view switching messages from other nodes. When a node collects 2f valid view switching messages from different nodes that are consistent with its own state, it is considered that the view switching condition has been met;

[0036] (3) generating and broadcasting a new view message: according to the preset election strategy, the master node determined as the new view v+1 generates and broadcasts a new view message after collecting 2f valid view switching messages. The new view message contains a proposal set O that needs to be re-consensed first in the new view;

[0037] (4) verifying and accepting the new view: each slave node in the group verifies the legality of the new view message after receiving it. After verification, the slave node accepts the new view v+1 and updates the master node;

[0038] (5) resume consensus under the new view: under the leadership of the new master node, the consensus group first re-consenses the proposal set O determined in the new view message. After completing the processing of these historical legacy proposals, the entire view replacement process ends, and the consensus group resumes to a state where it can process new client requests.

[0039] Further, the consensus isolation specifically includes the following steps:

[0040] (1) generating and signing an isolation notification: the newly elected master node after completing the internal view switching generates and signs a notification message for exiting consensus on behalf of the consensus group;

[0041] (2) broadcast the isolation notification: broadcast the notification message to all member nodes of the verification group;

[0042] (3) execute the isolation operation: after receiving and verifying the validity of the signature of the notification message, the member nodes of the verification group reach an agreement in their internal consensus, update the state of the consensus group to synchronization, and temporarily reject any new transaction proposal submitted from the consensus group in the subsequent global block generation process.

[0043] Further, the state synchronization specifically includes the following steps:

[0044] (1) sending a global state synchronization request: after the group state reaches an agreement, the new master node of the consensus group sends a synchronization state request message to the verification group, which contains the height h n of the local latest block;

[0045] (2) responding and returning the global state: after receiving the request, the verification group returns a set of blocks B and their proofs σ B between the current latest block height h n′ and h n to the master node;

[0046] (3) execute local state synchronization: the master node of the consensus group broadcasts the information in the group, and each node in the group runs a round of three-phase protocol according to the information to complete the local and global state synchronization.

[0047] Further, the consensus recovery specifically includes the following steps:

[0048] (1) Generating and sending a re-joining request: After the consensus group completes state synchronization, its master node generates a request message of the type re-joining consensus, which contains the state proof σ of its aligned latest local block latest , and sends the re-joining consensus request message to the verification group;

[0049] (2) Verification and approval of joining: After receiving the request, the verification group verifies the consistency of the state proof contained in the request with the current global state. After the verification passes, the verification group marks the state of the consensus group from synchronization to active in its internal consensus, and sends an approval joining confirmation message to the consensus group;

[0050] (3) Resuming parallel consensus function: After receiving the approval joining message, the consensus group resumes its parallel transaction processing consensus function.

[0051] Further, the adaptive hybrid consensus protocol mechanism further includes the following specific data processing:

[0052] (1) Consensus state identification: All communication messages between nodes in the consensus process carry the height or view information of the current consensus round;

[0053] (2) Anti-message replay and prophecy attack processing: When a node receives a message, it filters the message according to the consensus height it is in, discards or caches messages that do not belong to the current height, and prevents old messages or future messages from interfering with the current consensus process.

[0054] The detailed method of step 3 inter-group parallel layered consensus includes:

[0055] (1) Local consensus and proof generation: Each consensus group reaches a local consensus on the transaction set allocated to it in parallel, and generates a corresponding proof for the local consensus (e.g., by generating an aggregated signature, and using the signature as the proof of the local consensus) and submits it to the verification group;

[0056] (2) Global ordering and block generation: The verification group collects and verifies the local consensus proofs from each consensus group; globally and uniformly sorts all transactions corresponding to the proofs that pass the verification (according to the sequence numbers of each transaction); based on the sorting result, generates a final block containing the global consensus result, and broadcasts the block to each consensus group;

[0057] (3) Global block confirmation and state submission: After receiving the final block, each consensus group verifies the validity of the block, confirms the block through internal consensus, submits and updates the local state machine, thereby completing a complete consensus process.

[0058] Beneficial effects: The application can organically combine parallelization architecture with adaptive protocol, while meeting high throughput, high scalability and high security of the system. Compared with the prior art, the following advantages are specifically included:

[0059] (1) The application provides an adaptive consensus mechanism with high efficiency and high security. Compared with the scheme of using a fixed, single consensus protocol in the prior art, the adaptive hybrid protocol of the application can dynamically switch between the efficient two-stage mode and the high-security three-stage mode according to the real-time network state, maximizing the system throughput when the network condition is good, automatically enhancing the fault tolerance when the network condition deteriorates, and achieving dynamic balance of efficiency and security.

[0060] (2) The application fundamentally solves the scalability bottleneck of the traditional Byzantine consensus protocol through a hierarchical and parallel system architecture. Compared with the consensus scheme in the prior art in which all nodes are in the same plane and the communication complexity is high, the application divides the network into consensus groups that can work in parallel and a global verification group, significantly reducing the communication complexity of the whole network, so that the system can support a larger scale of node network and has excellent scalability.

[0061] (3) The application designs efficient intra-group consensus and inter-layer interaction processes, significantly reducing consensus delay and computing overhead. Compared with the scheme in the prior art in which a large number of point-to-point communication and independent signature verification are required in each stage, the application optimally adopts a threshold signature mechanism in intra-group consensus, aggregating multiple signatures and verifications into a single operation; at the same time, through clear hierarchical division and role definition, the flow path of local consensus proof to global consensus is optimized, effectively reducing redundant communication and computing overhead in the consensus reaching process.

[0062] (4) The application includes a complete set of protocol switching and security rollback algorithms, greatly enhancing the robustness and attack resistance of the system. Compared with the scheme in the prior art that may cause consensus stagnation or lack of safe recovery path when facing network anomalies, the application establishes a rigorous rollback and recovery process including "isolation, view replacement, state synchronization, and rejoining". This mechanism ensures that even when part of the consensus group encounters failure or attack, the system can safely complete fault recovery and protocol mode switching without affecting the normal operation of other parts, ensuring the data consistency and continuous activity of the entire system. BRIEF DESCRIPTION OF DRAWINGS

[0063] Figure 1 is a whole consensus flowchart of the application;

[0064] Figure 2 is a two-stage consensus protocol and three-stage consensus protocol switching diagram in the embodiment. DETAILED DESCRIPTION

[0065] The technical solutions of the present application will be described in detail below, but the protection scope of the present application is not limited to the embodiments.

[0066] As shown in the drawings, the high-efficiency hierarchical parallelization Byzantine consensus method based on hybrid protocol of the present application comprises the following steps: Figure 1

[0067] Step 1, constructing network hierarchy and dividing roles

[0068] The network hierarchy comprises a parallel processing layer and a global verification layer, the parallel processing layer refers to dividing the corresponding nodes in the blockchain into a plurality of consensus groups responsible for parallel processing transactions, and the global verification layer refers to dividing the corresponding nodes in the blockchain into a master verification group responsible for final ordering and confirmation of global transactions;

[0069] The method for dividing roles is that each consensus group in the parallel processing layer is provided with a master node and a plurality of slave nodes, and the total number of nodes n and the number of tolerable Byzantine nodes f satisfy n≥3f+1; in the global verification layer, the member nodes of the master verification group include the master nodes of all consensus groups, and can optionally include other preset high-trust nodes;

[0070] Step 2, executing in-group adaptive hybrid consensus

[0071] An adaptive hybrid consensus protocol mechanism is designed inside the consensus group and the verification group, the adaptive hybrid consensus protocol mechanism is built-in with protocol switching and rollback algorithm, according to the network state switching condition, the protocol switching and rollback algorithm is called to realize the dynamic switching of the two-phase consensus protocol and the three-phase consensus protocol, as shown in the drawings Figure 2

[0072] Step 2.1, view switching, that is, view switching messages are exchanged between nodes in the group, and a new master node is elected based on a preset election strategy;

[0073] Step 2.2, consensus isolation, that is, the consensus group and the verification group triggered by switching are interacted, so that the transactions to be processed are temporarily isolated from the global consensus process;

[0074] Step 2.3, state synchronization, that is, the consensus group completes the synchronization of its internal state in the isolated state, and aligns the local state according to the global system state obtained from the verification group;

[0075] Step 2.4, consensus recovery, that is, after the local state of the consensus group and the global state reach an agreement, the global consensus process is re-joined by requesting and obtaining permission from the verification group;

[0076] ​​Step 3, performing inter-group parallel layered consensus

[0077] The consensus groups submit the transactions processed by the intra-group consensus to the verification group; the verification group globally sorts and verifies the transactions received from each consensus group, and forms a final block through consensus; and the verification group distributes the final block to each consensus group, which performs final verification and state confirmation on the block.

[0078] The specific process of network layering and role division in this embodiment is as follows:

[0079] Step (1.1), network layering

[0080] According to the system configuration file, all nodes are divided into a parallel processing layer composed of M consensus groups (c represents a consensus group, and M-1 represents the unique number of a consensus group) and a global verification layer composed of a main verification group S v (v represents a verification group);

[0081] Step (1.2), role division

[0082] In each consensus group , a master node (k represents the unique number of a consensus group) and a plurality of slave nodes (i represents the node index) are elected or designated.

[0083] The master nodes of all consensus groups and a set of stable nodes {n0, n1, …} that have shown extremely high reliability, continuous online and strict compliance with the consensus protocol in the running history form members of the verification group S v ; there is also an elected or designated master node p v in the verification group S v .

[0084] Here, the stable node refers to a node that has shown extremely high reliability, continuous online and strict compliance with the consensus protocol in the running history.

[0085] Step (1.3), key generation and distribution

[0086] To achieve layered fault tolerance and efficient governance, the master nodes of each consensus group and the master node p v of the verification group in the system need to initialize and distribute two threshold signature public and private key pairs with different threshold values for the members in their groups, one set of public and private key pairs {pk i,1 , sk i,1 ,} is used for the two-phase protocol, and the threshold threshold t = 3f + 1; another set of public and private key pairs {pki,2 ,sk i,2} is used for the three-phase protocol, with a threshold t = 2f + 1.

[0087] Step (1.3.1): Select Elliptic Curve

[0088] The master node is selected from those defined in the finite field F. p The equation of the elliptic curve E on the x-axis is y. 2 =x 3 +ax+b(mod p);

[0089] Step (1.3.2): Determine and publish domain parameters

[0090] Once the curve is selected, a set of publicly available domain parameters (p, d, b, G, n) will be determined and published to all nodes in the network, where p is defined in the finite field F. p a and b are the coefficients of the chosen elliptic curve equation, G is a base point (or generator) on the curve E, and n is a large prime number and the order of the base point G, i.e., the smallest positive integer that satisfies n·G=∞ (∞ is the point at infinity);

[0091] Step (1.3.3): Select a hash function

[0092] The entire network jointly selects a cryptographic hash function H() for hash calculation in the subsequent signature process. This hash function H() is a deterministic mathematical function whose core function is to map a byte string of arbitrary length to a fixed-length byte string through an irreversible one-way calculation. This output value is the "digest".

[0093] Step (1.3.4): Generate the master key and polynomial

[0094] The master node first randomly selects an integer in the range [1, n-1] locally as the master secret. This secret serves as the logical private key for the entire consensus group. Then, the master node selects t-1 random values ​​{a1, a2, ..., a...} based on a threshold t. (t-1)}, construct a polynomial Where a0 = Secret;

[0095] Step (1.3.5): Calculate key share

[0096] The master node assigns a unique, public, non-zero index x to each participating node i within the group. i Next, the master node will assign the index x of each node. i Substituting into the polynomial f(x), the corresponding private key share sk is calculated. i =f(x) i(mod n);

[0097] Step (1.3.6): Securely distribute key shares

[0098] The master node transmits the key share sk through a secure communication channel. i The sk is sent to the corresponding node i, and after receiving it, node i securely stores it. i After distribution is complete, the master node destroys the Secret and the polynomial coefficients {a1, a2, ..., a...}. (t-1)}

[0099] Step (1.4) System configuration parameter settings

[0100] According to the configuration file, set the system configuration parameters, such as the consensus timeout threshold T. timeout And heart rate detection, etc.

[0101] This embodiment achieves local consensus on the transactions assigned to each consensus group in parallel and generates corresponding local consensus proofs. This step employs an adaptive protocol, defaulting to an efficient two-phase mode, and the specific process is as follows:

[0102] Step (2.1), Preparatory Stage

[0103] The client sends a message to a consensus group. Send transaction request m REQ =<REQ,o,ts,c> In this context, REQ represents the request message type, 'o' represents the operation, 'ts' is a unique timestamp, and 'c' is the client's unique identifier. For the validator group, the client is the master node of each consensus group, and the request is a sorting request sent by the consensus group master node. The validator group master node also needs to sort the requests and package them into blocks.

[0104] Consensus group (verification group) master node Received client transaction request m REQ Then, a unique sequence number sn = (num, v, k) is generated for it, where num is an incrementing number, v is the current view number, and k is the consensus group number. Next, the master node... Package it into a proposal message m PP ′= <Pre-Prepare,m rEQ ,v,sn,d,t>, where Pre-Prepare is the pre-prepare message type, and d is determined by m REQ The message digest H(m) calculated from the operation execution result rs REQ (rs) (the result of the verification group's operation is the packaged block), t is a unique timestamp. Master node For message m PP Sign it to get mPP = <Pre-Prepare,m REQ ,v,sn,d,ts> p Where the subscript p indicates For message m PP The signature. Finally, the master node. m Pp Broadcast to all slave nodes in the group

[0105] Each slave node After receiving m PP Next, the validity of the master node signature is verified sequentially; the view number v in the message is checked to see if it matches the current view number; the sequence number sn is checked to see if it has not been processed and is within the expected range; and the digest d is checked to see if it equals m. REQ and Execute m REQ The result is a summary of rs′ H(m) REQ If all validations pass, from node rs′). Accept the proposal and proceed to the preparation phase; if verification fails, trigger the view replacement process. Each slave node that accepts the proposal... Using the private key share sk it holds i,1 and SK i,2 Sign each message individually to generate a signature share. and And combine them into a signature group Finally, from the node Generate voting messages for the pre-preparation phase Send to the master node.

[0106] Step (2.2), Preparation Stage

[0107] Master node After receiving the signature shares from each slave node, the aggregation preparation phase proof σ is performed using different threshold signatures based on the number of messages collected. PP Collected 3f+1 messages using sk i,1 ; Collect 2f+1 messages and use sk i,2 Similar to the preparation phase, Generate preparation phase message m Prep = <Prepare,v,sn,d,σ PP > p Broadcast to the slave node.

[0108] Receive m from node Prep Then, referring to the pre-preparation phase, verify each piece of information and signature σ in the message in sequence. PP If σPP If the three-stage signature key is used, it indicates that the system does not currently meet the operation condition of the two-stage consensus protocol, triggering the protocol switching and fallback algorithm, and switching to the three-stage consensus protocol. Otherwise, the node refers to the signature share pair and the preparation stage voting information and sends them to the master node.

[0109] Step (2.3), commitment stage

[0110] If the consensus group or the verification group is in the two-stage consensus protocol, this stage does not need to be executed; if the consensus group or the verification group is in the three-stage consensus protocol, the master node in the consensus group needs to attach the globally sorted block and the proof to the message, and the verification group does not need to execute this operation.

[0111] The master node After receiving the signature share of each slave node in the preparation stage, it aggregates the collected messages using different threshold threshold signatures to generate the preparation stage proof σ Prep . Similar to the pre-preparation stage, generate the commitment stage message m CMT = <Commit, v, sn, d, σ Prep > p Broadcast to the slave node.

[0112] After the slave node receives m CMT , it refers to the pre-preparation stage, and verifies each item of information and signature σ Prep in the message in turn. The slave node refers to the pre-preparation stage to generate the signature share pair and the commitment stage voting information and sends them to the master node.

[0113] After the consensus group master node generates the aggregated signature σ CMT , it returns the signature and the execution result of the operation o to the client. The master node of the verification group sends the execution result (block Φ) of the operation o and the signature σ CMT to the master node of the consensus group.

[0114] This embodiment collects and verifies all local consensus proofs by the verification group, globally and uniformly sorts all transactions, and finally generates an authoritative block broadcast to the entire network, completing a complete consensus. The specific process is as follows:

[0115] Step (3.1), inter-group request

[0116] The consensus group master node Collecting the signature shares submitted by each follower in the preparation phase, using different threshold signature according to the number of received messages to aggregate, generating the proof σ of the preparation phase Prep , then the pre-preparation phase proof and the preparation phase proof are packaged into a proof group Then, the master node generates a global ordering request Sent to the verification group master node.

[0117] Step (3.2), global ordering

[0118] When the master node p v of the verification group S v receives messages from each consensus group , p v will verify each message, and the verification process includes:

[0119] Check if there are two messages with the same digest d but different sequence numbers sn, if there are, it indicates that there is dishonest behavior, further, verify the signature in the message. If the signature is valid, it indicates that more than 2N k / 3 (N k is the number of nodes in the consensus group) followers in the corresponding consensus group have completed the preparation phase, at which time the next step can be entered. Otherwise, if the verification fails, it indicates that there may be more than 1 / 3 faulty nodes in the consensus group, or its master node itself has a fault.

[0120] p v orders each transaction according to its sequence number, and constructs a new block Φ based on the final order. Let the height of the new block be h.

[0121] Next, p v creates a pre-preparation message for the newly constructed block Φ and sends it to all follower nodes in the verification group S v Start a round of consensus process within the verification group. The consensus process is the same as the consensus group, both using the adaptive hybrid consensus within the group, and the default is two-phase consensus. Finally, p v broadcasts a reply message m RPY = <REPLY, sn, v, d, n b , Φ, σ V > to all master nodes of the consensus group , where σ V is the proof of the verification group for the block Φ.

[0122] Step (3.3), global commitment

[0123] Consensus group master node Received M RPY Verify the signature σ V in sequence, whether the signature is correct, whether the block height h is greater than the last block height promised by the consensus group, and whether the transactions in the block belonging to the consensus group are consistent with the local storage.

[0124] If the verification group is in the two-phase consensus protocol and the verification is passed, the verification group node is replied to pass the verification. The master node replies to the client while forwarding the message of the upper partition to the slave node of the consensus group. The client verifies the message of the master node , and if it is passed, sends a message of passing the verification to the slave node to ensure the safety of the system.

[0125] If the consensus group is in the three-phase consensus protocol, the consensus group master node executes step (2.3) commitment phase.

[0126] This embodiment triggers this step when network anomalies are monitored in the local consensus process, safely switches the problematic consensus group to the high-security three-phase consensus protocol, and performs a series of state synchronization and recovery operations. The specific process is:

[0127] Step (4.1), trigger and mode switching

[0128] If the signature received by the slave node of the verification group S v in the two-phase consensus does not pass the verification, a global rollback protocol is triggered, a global rollback message is broadcast to all master nodes of the consensus group , and the verification group performs the view change (ViewChange) protocol.

[0129] When the slave node of the consensus group receives a signature that does not pass the verification in the two-phase consensus or receives a global rollback request, the protocol switching is triggered immediately. The consensus protocol of all nodes in the consensus group is automatically switched from the two-phase mode to the three-phase consensus protocol. At the same time, the master node stops processing any new client transaction request and temporarily locks the state in the group.

[0130] Step (4.2), internal view change

[0131] All nodes in the consensus group jointly execute the view change protocol. Through multiple rounds of message interaction and voting, the nodes in the group will elect a new master node New master node Broadcast the new view message to all group members and may request each member to report their local state to ensure that all honest nodes agree on the current state within the group before proceeding to the next step.

[0132] Step (4.3), consensus isolation

[0133] New master node To the verification group S v Broadcast a notification message of type "Withdraw from consensus". The message contains consensus groups. The identifier and the signature σ collected during the view switching phase. VC As proof, it is signed by the sending node.

[0134] Verification group S v After receiving and verifying the notification, the members of the consensus group will, in their internal consensus state, [add the consensus group]. The flag is updated to "in synchronization," and the set of transactions pending processing for that consensus partition is temporarily removed from the global sorting task. From this point onward, the validator group will temporarily ignore and isolate transactions from the consensus group when performing global consensus. Any new local consensus proof submitted will be rejected unless a subsequent rejoin request is received.

[0135] Step (4.4) State Synchronization

[0136] New master node Once a consensus is reached within the group, it represents the entire consensus group. To the verification group S v Send a message of type Synchronization Status Request Where h n σ represents the latest stable block height of the consensus group. n This is proof of the block.

[0137] Verification group S v After receiving the request, verify m SYC The signature information in the file. If correct, it will identify a group of blocks with a height greater than h. n Block B and its proof σ B Return to

[0138] New master node The received global status information is broadcast within the group. Each node in the process executes a new consensus process to synchronize the global state.

[0139] Step (4.5), Consensus Restoration

[0140] After confirming that the local state is aligned with the global state, the new master node To the verification group S v Send a request of type rejoin consensus The request is accompanied by its current state h latest And the proof σ latest .

[0141] Verification group verification and approval: verification group S v Verify the m JOIN Request, confirm that its reported state is consistent with the current global state. After verification, the verification group updates its internal state, changes the marker of From synchronization to active, and sends a confirmation message to Approve its re-joining. Consensus group

[0142] After receiving the approval message, formally resume its consensus function of processing transactions in parallel. Thereafter Will continue to run the three-phase consensus protocol with high security until its network environment has long been restored to stability, and can try to switch back to the two-phase mode.

[0143] To further verify the technical effect of the present application, the technical solution of the present application is applied to a specific scene, and the steps are as follows:

[0144] Step (1), system initialization, including the following steps:

[0145] Step (11), according to the system configuration file, divide the nodes into a parallel processing layer composed of M consensus groups and a global verification layer composed of a master verification group, in this embodiment M = 4, that is, there are 4 consensus groups;

[0146] Step (12), in each consensus group , elect or designate a master node And several slave nodes In this example, assume that each consensus group has a total of 4 nodes, and the node numbers of all consensus groups are 0 to 15, and the master node numbers of each group are 0, 4, 8, and 12. The master nodes And a set of stable nodes {n0, n1, …} that make up the verification group S v Member. In this example, the stable node set is empty. In the verification group S v There is also an elected or designated master node p v , let p v Number is 12;

[0147] Step (13), the master node Of each consensus group ​and the master node p of the verification group v Each group needs to initialize and distribute two threshold signature key pairs with different threshold values ​​to its members. In this example, each group has 4 nodes, so f is 1 for all groups, and the threshold values ​​for the two sets of keys are 3 and 4 respectively; key generation is based on consensus groups. For example, generate a two-stage key. Master node The secp256k1 elliptic curve cryptography algorithm is selected, and SHA-256 is chosen as the hash function. A master secret (Secret) is randomly generated as the key, and three random values ​​{a1, a2, a3} are randomly selected to construct a polynomial. Where a0 = Secret. Substitute the node numbers {0,1,2,3} within the group into the polynomial to calculate the key share {sk0 = f(0)(modn), sk1, sk2, sk3}. The calculated private key share sk is transmitted through a secure, peer-to-peer encrypted channel. i Send them to the corresponding node i respectively. The master node immediately destroys its locally stored master secret and the coefficients {a1,a2,a3} of the polynomial;

[0148] Step (14): According to the configuration file, set the system configuration parameters, such as the timeout threshold T. timeout And heart rate detection, etc.

[0149] Step (2), Group consensus:

[0150] Step (21): Client 0 communicates with the consensus group Send transaction request m REQ =<REQ,o,t,0> Master node Received client transaction request m REQ Then, based on the current view number v = 0, a unique sequence number sn = (0,0,0) is generated for it, and then it is packaged into a proposal message m. PP The message format is m PP = <Pre-Prepare,m REQ ,0,sn,d,ts>。 Master node For message m PP Sign it to get m PP = <Pre-Prepare,m REQ ,0,sn,d,ts> p Then m pp Broadcast to all slave nodes in the group Each slave node receives m PP Then, verify the correctness of the messages one by one. If all verifications pass, proceed from the node. Accept the proposal and enter the preparation phase. Each accepting follower node uses its held private key share sk i,1 and sk i,2 signs the message separately to generate signature shares and combine into a signature group The follower node generates a pre-preparation phase voting message and sends it to the leader node;

[0151] Step (22), the leader node collects the signature shares from each follower node in the pre-preparation phase, aggregates them using different threshold signature according to the number of collected messages, and generates a proof σ PP for the pre-preparation phase. The leader node generates a preparation phase message m prep = <Prepare, v, sn, d, σ PP > p and broadcasts it to the follower nodes. After receiving m Prep , the follower nodes verify the information and signature σ PP in the message in sequence according to the pre-preparation phase. The follower nodes further generate signature shares and preparation phase voting information and send them to the leader node.

[0152] Step (3), inter-group consensus, including the following steps:

[0153] Step (31), the consensus group leader node collects the signature shares from each follower node in the preparation phase, aggregates them using different threshold signature according to the number of collected messages, and generates a proof σ Prep for the preparation phase. Then, the leader node packs the pre-preparation phase proof and the preparation phase proof into a proof group The leader node generates a global ordering request and sends it to the verification group leader node p v ;

[0154] Step (32), when the leader node p v of the verification group S v (numbered 12) receives messages from each consensus group , p v will verify each message. p v orders the transactions according to their sequence numbers and constructs a new block Φ based on the final order. Each block is assigned a unique number h called height to identify it;

[0155] Next, p v Create a pre-preparation message for the newly constructed block Φ and transmit it to the validation group S. v All slave nodes {0,4,8} within the group initiate a round of consensus processing within the validation group. This consensus process is the same as the consensus group itself, using an intra-group adaptive hybrid consensus, which defaults to two-phase consensus. Finally, p v To all consensus groups master node Broadcast a reply message m RPY = <REPLY,sn,v,d,n b ,Φ,σ V >p;

[0156] Step (33), consensus group master node Received m RPY The information is then verified sequentially. If the verification group is using a two-phase consensus protocol and the verification passes, it sends a reply message to nodes {0,4,8,12} in the verification group, indicating that the verification has passed. If the consensus group is using a two-node protocol, it replies to client 0 and forwards the upper-layer partition message to the slave nodes {1,2,3} of the consensus group. Client 0 verifies the master node. After receiving the message, if the verification passes, a verification success message is sent to the slave node. The consensus process ends.

[0157] Step (4), protocol switching and fallback algorithm, such as Figure 2 As shown, it includes the following steps:

[0158] Step (41): In this example, a consensus group is used. For example, when the consensus group... slave node If a signature received during the two-phase consensus fails verification or a global rollback request is received, a protocol switch is immediately triggered. This consensus group... All internal nodes switch their consensus protocol logic to a three-phase consensus protocol. Simultaneously, the master node... Stop processing any new client transaction requests;

[0159] Step (42), consensus group All nodes within the node jointly execute the view replacement protocol to elect a new master node. (Numbered as 1). New Main verse After taking office, broadcast the new view message to all group members and synchronize the group status;

[0160] Step (43), Master Node Upon assuming office, he immediately reported to the verification team S v Broadcast a notification message of type "Withdraw from consensus". Verification group S v After receiving and verifying the notification, the members of the consensus group will, in their internal consensus state, [add the consensus group]. The flag is updated to be in synchronization, and the set of transactions pending in this consensus partition is temporarily removed from the global sorting task;

[0161] Step (44), New Master Node Once a consensus is reached within the group, it represents the entire consensus group. To the verification group S v Send a message of type Synchronization Status Request In this example, Φ n height h n =15. Validation group S v After receiving the request, verify m SYC The signature information in the block. If correct, a set of blocks B with a height greater than 15 and their proof σ will be found. B Return to node In this example, block B contains blocks with a maximum height of 17, meaning that block B contains two blocks with heights of 16 and 17. The new master node 1 will broadcast the received global state information within the group. Each node in the process executes a three-phase consensus protocol to reach a consensus on the global state;

[0162] Step (44): After confirming that the local state is aligned with the global state, the new master node... To the verification group S v Send a request of type "Rejoin Consensus". In this example, h latest =17. Validation group S v right m JOIN Request verification to confirm the reported status h latest Consistent with the current global state. Upon successful verification, the verification group updates its internal state, making it consistent with the current global state. The flag is changed back from synchronization to activity, and to Send a confirmation message approving its rejoining. Consensus Group After receiving approval, its consensus function for parallel transaction processing was officially restored. Subsequently... Only after the three-phase consensus protocol has been running continuously and the network environment has been restored to stability for a long period of time can we try to switch back to the two-phase mode again.

[0163] In the three-phase model, during the global commitment phase of inter-group consensus, the consensus group receives m from the verification group. RPY Then, Φ is appended to the generated commitment phase message m. CMT = <Commit,v,sn,d,σ Prep >p In the middle, broadcast to the slave node. The slave node receives m CMT After, refer to the pre-preparation stage, verify each item of information and signature sigma Prep In the message in turn, the slave node generates a signature share pair And the commitment stage voting information And send to the master node. The master node receives the information and aggregates the signature sigma CMT As proof, the execution result of the operation is returned to the client.

[0164] Compared with the existing classic PBFT, HotStuff and MultiPBFT algorithm, the technical scheme of the application has significantly improved the safety, activity, communication overhead, consensus delay and throughput performance, and can be applied to large-scale and high-demand blockchain networks.

[0165] Security analysis: in the division of the consensus group and the verification group, each group strictly follows the Byzantine fault tolerance premise of f<n / 3, which is the basis of system security. Secondly, the hierarchical parallel strategy effectively limits the influence of malicious nodes within a specific consensus group. When no more than 1 / 3 of the consensus groups or verification groups have Byzantine problems, the core consensus of the entire system can continue normally.

[0166] Since the master node is set as the coordinator of each consensus stage in the application, the broadcast between nodes is changed to linear communication, so the trustworthiness and security of the master node must be ensured. To this end, the application introduces an EC-Schnorr threshold signature mechanism to aggregate the signature shares of multiple slave nodes into a single aggregated signature. When the slave node receives the next stage message broadcast by the master node, which contains the aggregated signature, the slave node can verify the aggregated signature to determine whether the master node has obtained the approval of enough (up to threshold t) nodes honestly, thereby effectively preventing the master node from being malicious. In addition, the adaptive hybrid consensus mechanism provides the same level of security as classic PBFT and HotStuff by automatically switching to a three-stage mode when potential Byzantine behavior is detected.

[0167] Activity analysis: the technical scheme of the application uses protocol switching and security rollback algorithm to guarantee the activity within the consensus group and the verification group. If the current master node has Byzantine behavior, the slave nodes in the group will automatically trigger the view switching process, elect a new honest master node, and switch to a three-stage consensus protocol with higher security, thereby effectively avoiding consensus stagnation caused by a single master node failure.

[0168] The protocol switching and security rollback algorithm also guarantees the activity of inter-group consensus. When a consensus group When triggering the protocol switching and security fallback algorithm, it actively sends a "exit consensus" notification to the verification group S v Sends a "exit consensus" notification to temporarily isolate itself. During this period, the verification group S v Can continue to process proposals from all other honest consensus groups and generate blocks. This means that the failure of a single consensus group will not cause the system consensus to pause. In serialized architectures such as classic PBFT and HotStuff, a view change requires the participation of all nodes in the network, and the entire system consensus process is completely blocked during this period. MultiPBFT, although it divides small groups, usually lacks a clear inter-layer fault handling protocol, and internal problems in a consensus group can still cause the upper verification group to wait indefinitely, thereby blocking the entire system. The scheme of the present application perfectly solves this problem through the protocol switching and security fallback algorithm, greatly ensuring the activity of the entire system.

[0169] Communication overhead analysis: Communication overhead mainly refers to the amount of communication generated by nodes in the consensus process. In the classic PBFT consensus process, since it needs to broadcast to all members in the preparation and confirmation phases, when the total number of system nodes is N, the total communication complexity is as high as O(N 2 ) In the scheme of the present embodiment, the network is divided into M consensus groups with a size of l, and the size of the verification group is M. In the group consensus phase, the communication is optimized to linear O(l) through threshold signature; in the inter-group consensus phase, the communication complexity is O(M).

[0170] Therefore, the total communication complexity of the scheme of the present application consists of M·O(l) in the group and O(M) between the groups, both of which run in parallel, and the actual communication complexity is close to the constant level. This complexity is not only significantly lower than the classic PBFT, but also better than the MultiPBFT of the layered architecture, because the consensus group and the verification group of the latter run in series. Even compared with HotStuff, which itself has a linear complexity of O(N), the present application provides a higher theoretical upper limit for throughput improvement in a sharded business scenario through a layered parallel architecture, thereby having more advantages in overall system efficiency. In summary, the communication overhead of the improved scheme of the present application is better than existing algorithms, and it has a significant advantage in scalability.

Claims

1. An efficient hierarchical parallelization Byzantine consensus method based on a hybrid protocol, characterized in that, The method comprises the following steps: Step 1, constructing network hierarchy and dividing roles The network hierarchy comprises a parallel processing layer and a global verification layer, wherein the parallel processing layer refers to dividing corresponding nodes in a blockchain into consensus groups responsible for parallel processing of transactions, and the global verification layer refers to dividing corresponding nodes in the blockchain into a main verification group responsible for final ordering and confirmation of global transactions; The method for dividing roles is that each consensus group in the parallel processing layer is provided with a master node and a plurality of slave nodes, and the total number of nodes n and the number of tolerable Byzantine nodes f satisfy n≥3f+1; in the global verification layer, the member nodes of the main verification group include the master nodes of all consensus groups and other preset high-trust nodes; Step 2, performing in-group adaptive hybrid consensus An adaptive hybrid consensus protocol mechanism is designed in the consensus groups and the verification group, the adaptive hybrid consensus protocol mechanism is provided with a protocol switching and rollback algorithm, the protocol switching and rollback algorithm is called to realize dynamic switching of the two-phase consensus protocol and the three-phase consensus protocol according to network state switching conditions, and the following steps are specifically performed: Step 2.1, view switching, that is, view switching messages are exchanged between nodes in the group, and a new master node is elected by negotiation based on a preset election strategy; Step 2.2, consensus isolation, that is, the consensus groups and the verification groups triggered to switch are interacted, so that the transactions to be processed are temporarily isolated from the global consensus process; Step 2.3, state synchronization, that is, the consensus group completes synchronization of the internal state in the isolation state, and aligns the local state according to the global system state obtained from the verification group; Step 2.4, consensus recovery, that is, after the local state of the consensus group and the global state reach an agreement, the global consensus process is re-joined by requesting and obtaining permission from the verification group; Step 3, performing inter-group parallel hierarchical consensus The consensus groups submit the transactions processed by the in-group consensus to the verification group; The verification group globally orders and verifies the transactions received from the consensus groups, and forms a final block through consensus; the verification group distributes the final block to the consensus groups, and the consensus groups verify and confirm the state of the block.

2. The efficient hybrid-protocol-based layered parallelization Byzantine consensus method according to claim 1, characterized in that, In the step 1, the main verification group is responsible for verification and ordering when the parallel processing layer requests; when the master node of the main verification group needs to be replaced due to a Byzantine error, the standby verification group takes over the function of global consensus; The master node of each consensus group and the master node of the verification group need to initialize and distribute two threshold signature public and private key pairs with different threshold values for the members in the group, one set of public and private key pair is used for the two-phase consensus protocol, and the threshold threshold t=3f+1; the other set of public and private key pair is used for the three-phase consensus protocol, and the threshold threshold t=2f+1; For each set of key pairs, the master node calculates and distributes independent private key shares to each member node through a secure secret sharing protocol, and immediately destroys all master secrets and polynomial coefficients used to generate the shares after completing the secure distribution of all key shares.

3. The efficient hybrid-protocol-based layered parallelization Byzantine consensus method according to claim 1, characterized in that, The dynamic network state switching conditions in the adaptive hybrid consensus protocol mechanism include the following two aspects: 1) If the master node can receive a preset threshold number of signatures, it is determined that the current network communication is stable, and then switched to a two-stage consensus protocol; 2) If the master node does not receive a preset threshold number of signatures or suspected of a Byzantine behavior, it is determined that the current network is congested or unstable, and then switched to a three-stage consensus protocol; Byzantine behavior includes intentionally not responding after receiving information, selectively ignoring legitimate client requests, replay attacks, fake client content, and double proposals.

4. The efficient hybrid-protocol-based layered parallelization Byzantine consensus method according to claim 1, characterized in that, The specific steps of the view switching are as follows: First, trigger and broadcast the view switching request, that is, any node in the consensus group broadcasts a view switching message to all other nodes in the group when it monitors that the master node is timed out or meets the preset failure condition, the view switching message at least contains the new view number proposed by the node and the proof of the latest proposal set in the preparation state known by the node; Then, collect and verify the view switching message, that is, each node in the consensus group collects the view switching message from other nodes, and when a node collects 2f valid view switching messages from different nodes consistent with its own state, it is considered that the view switching condition has been met; Next, generate and broadcast the new view message, that is, according to the preset election strategy, the master node determined as the new view generates and broadcasts the new view message after collecting 2f valid view switching messages, the new view message contains the proposal set O that needs to be first re-consensed in the new view; Second, verify and accept the new view, that is, each slave node in the group verifies the legality of the new view message after receiving it, and accepts the new view and updates the master node after verification; Finally, resume consensus under the new view, that is, under the leadership of the new master node, the consensus group first re-consenses the proposal set O determined in the new view message; After completing the processing of these historical legacy proposals, the entire view replacement process ends, and the consensus group returns to the state of processing new client requests. 5.The hybrid-protocol based efficient hierarchical parallelization Byzantine consensus method according to claim 1, wherein, The specific steps of the consensus isolation are as follows: First, generate and sign the isolation notification, that is, the newly elected master node after completing the internal view switching represents the consensus group to generate and sign the notification message of exiting the consensus; Then, broadcast the isolation notification, broadcast the notification message to all member nodes of the verification group; Finally, execute the isolation operation, that is, after receiving and verifying the validity of the signature of the notification message, the member nodes of the verification group agree in their internal consensus to update the state of the consensus group to synchronization, and temporarily reject any new transaction proposal submitted from the consensus group in the subsequent global block generation process. 6.The hybrid-protocol based efficient hierarchical parallelization Byzantine consensus method according to claim 1, wherein, The steps of state synchronization include sending a global state synchronization request, responding and returning a global state, and executing a local state synchronization, which are as follows: Firstly, after the state of the group is agreed, the new master node of the consensus group sends a request message for synchronization state to the verification group, which contains the height of the latest local block; after receiving the request, the verification group returns a set of blocks and its proof between the current latest block height and the height in the request message to the master node; finally, the master node of the consensus group broadcasts the information in the group, and each node in the group runs a round of three-phase protocol according to the information to complete the synchronization of local and global state. 7.The hybrid-protocol based efficient stratified parallelization Byzantine consensus method according to claim 1, wherein, The specific steps of the consensus recovery are as follows: Firstly, generate and send a re-join request, that is, after the consensus group completes the state synchronization, the master node generates a request message of the type of re-joining consensus, which contains the state proof of the latest local block after alignment, and sends the re-joining consensus request message to the verification group; Then, verify and approve joining, that is, after receiving the request, the verification group verifies the consistency of the state proof contained in the request and the current global state; if the verification is passed, the verification group marks the state of the consensus group from synchronization to active in its internal consensus, and sends an approval joining confirmation message to it; Finally, restore and run the consensus function in parallel, that is, after receiving the approval joining message, the consensus group formally restores its consensus function of processing transactions in parallel. 8.The hybrid-protocol based efficient hierarchical parallelization Byzantine consensus method according to claim 1, wherein, The adaptive hybrid consensus protocol mechanism also includes two data processing operations of consensus state identification and anti-message replay and prophecy attack processing: Consensus state identification means that all communication messages between nodes in the consensus process carry the height or view information of the current consensus round; Anti-message replay and prophecy attack processing means that when a node receives a message, it filters the message according to the consensus height it is in, discards or caches the message that does not belong to the current height, and prevents old messages or future messages from interfering with the current consensus process. 9.The hybrid-protocol based efficient stratified parallelization Byzantine consensus method according to claim 1, wherein, The detailed method of step 3 includes: Step 3.1, local consensus and proof generation, that is, each consensus group reaches local consensus on the transaction set allocated to it in parallel, and generates the corresponding proof for the local consensus and submits it to the verification group; Step 3.2, global sorting and block generation, that is, the verification group collects and verifies the local consensus proofs from each consensus group; globally sorts all transactions corresponding to the proofs that pass the verification; based on the sorting result, generates a final block containing the global consensus result, and broadcasts the block to each consensus group; Step 3.3, global block confirmation and state submission, that is, after receiving the final block, each consensus group verifies the validity of the block, confirms the block through group consensus, and submits and updates the local state machine, thereby completing a complete consensus process.

Images