Layered Byzantine consensus method for transaction security

Abstract

The invention provides a layered Byzantine consensus method for transaction security. The method comprises the following steps: constructing a layered architecture comprising an execution layer and a verification layer; a user submits a transaction application to the execution layer, and the execution layer performs trusted timestamp generation, encrypted transaction sorting and secure transaction execution operation after receiving the transaction application; and sending the related information of the transaction result of the execution layer to the verification layer for batch certification verification, global consensus confirmation and state termination operation. According to the method, various transaction attacks such as front transaction attacks and sorting tampering attacks can be successfully resisted, and the fair sorting accuracy reaches 100%; the execution layer realizes physical time binding of transaction sorting by means of TEE, the tampering possibility is eliminated, the verification layer verifies zero-knowledge proof in batches by means of BFT consensus, and the global terminality is ensured. The delay and the communication overhead are lower; and the transaction content is hidden and encrypted in the transaction process, so that malicious nodes are prevented from acquiring information in advance.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a layered Byzantine consensus method for secure transactions. Background Technology

[0002] Blockchain technology, with its decentralized, tamper-proof, and traceable characteristics, has been widely applied in various fields such as finance, energy, healthcare, and the Internet of Things. The core of a blockchain system lies in its consensus mechanism, which achieves data consistency through distributed node collaboration, ensuring system security and availability. Partial synchronization consensus protocols, as a consensus scheme that balances system availability with network uncertainty in real-world network environments, allow the network to reach a synchronized state within a certain timeframe. They are better suited to complex and dynamic network environments, and protocols such as PBFT, HotStuff, and Tendermint have become fundamental protocols adopted by many blockchain systems.

[0003] However, existing synchronous Byzantine protocols have many problems: as the scale of network nodes expands, the communication complexity increases exponentially, leading to serious performance bottlenecks in the system. In Byzantine fault-tolerant protocols, the large number of message exchanges between nodes rapidly increases communication overhead and reduces consensus efficiency. Malicious nodes can carry out pre-transaction attacks and order tampering attacks by manipulating transaction timing and sorting rules. Traditional BFT algorithms require all nodes to repeatedly perform transaction verification, resulting in serious computational redundancy. Furthermore, the centralized sorting service of some solutions has a single point of trust risk. There is a fundamental contradiction between privacy protection and verification overhead. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a layered Byzantine consensus method for secure transactions, which solves the problems of performance, security, privacy protection, and verification overhead in existing partially synchronous Byzantine consensus methods, and achieves partially synchronous consensus that balances low communication overhead, high throughput, and strong resistance to attacks.

[0005] The technical solution of this invention is: a layered Byzantine consensus method for secure transactions, comprising the following steps:

[0006] S1) Construct a layered architecture that includes an execution layer and a verification layer;

[0007] S2) The user submits a transaction request to the execution layer. After receiving the transaction request, the execution layer performs trusted timestamp generation, encrypted transaction sorting, and secure transaction execution operations.

[0008] S3) Send the relevant information of the transaction results from the execution layer to the verification layer for batch proof verification, global consensus confirmation, and state finalization operations.

[0009] Preferably, in step S2), the execution layer generates a globally unique and tamper-proof millisecond-level trusted timestamp T based on the Intel SGX hardware security module. commit And the clock source is ensured to be trustworthy through DCAP remote certification.

[0010] Preferably, in step S2), the encrypted transaction sorting is performed by timestamp within the TEE secure enclave, generating a sorting proof containing a trusted timestamp and hash chain.

[0011] Preferably, in step S2), the secure transaction execution utilizes parallel virtual machine technology to execute transactions in a hardware-isolated environment, generating a transaction execution proof π of the transaction result. execution .

[0012] Preferably, in step S2), the user-submitted transaction t enters the transaction pool TxPool of the execution layer to await sorting. After receiving transaction t, the TEE calculates the trusted timestamp T. commit =TEE-Clock(t)∈N + and transaction hash value H t = hash(t); where TEE-Clock(t) represents the count of the security clock inside the TEE at local time t; N + Represents the set of positive integers;

[0013] The trusted timestamp T commit The transaction hash value H is provided by the TEE's internal clock Clock(t). t Used as a unique identifier for sorting;

[0014] Through trusted timestamp T commit and transaction hash value H t Generating zero-knowledge proofs of π commit =ZKP-Proof(H t ,T commit ), where ZKP-Proof represents zero-knowledge proof, and it stores transaction information (H t ,T commit ,π commit It is stored in the execution layer transaction pool TxPool.

[0015] Preferably, the encrypted transaction sorting operation in step S2) is as follows:

[0016] S221), Input transaction information (H) t ,T commit ,π commit And verify the zero-knowledge proof of π. commit ,

[0017] If zero-knowledge proof of π commit If valid, proceed to step S22);

[0018] S222), for any transaction t i ,t j ∈S, if the reliable timestamp T commit (t i ) <T commit (t j If so, then the batch transactions will be processed according to... Sort in an ordered transaction sequence S ordered middle;

[0019] S223) Generate batch transaction sorting proof π1 ordering ;Right now:

[0020] π1 ordering =ZK-Prove(C order S ordered ,{π commit});

[0021] Where ZK-Prove represents a zero-knowledge proof protocol; C order S represents the sorting constraint. ordered Represents an ordered sequence of transactions; π commit Proof of zero knowledge;

[0022] S24), Publish the orderly transaction list S ordered =(t1,t2,…,t n ), and store the batch transaction sorting proof π1 ordering Reach the consensus node.

[0023] Preferably, in step S2), the secure transaction execution operation is performed as follows:

[0024] S231), according to the trusted timestamp T commit Sort the transactions to generate an ordered set O. t ;Right now:

[0025] O t =sort(TxPool,T commit );

[0026] S232) Generate a transaction ranking proof π2 at the transaction pool level. ordering ,Right now:

[0027] π2 ordering =ZKP-Prove(T) commit O t );

[0028] S233), for an ordered set of transactions Ot Each transaction t in i The transaction result is And generate transaction execution proof π execution :

[0029]

[0030] Among them, TEE-Execute(t i ) indicates that a transaction or task is executed within a trusted execution environment. i Operation;

[0031] S234) will trade t i Execution results Transaction Execution Proof π execution Store in executed transaction set E t And prove π2 by sorting transactions at the transaction pool level. ordering and the set of executed transactions E t Send to the verification layer.

[0032] Preferably, in step S3), the batch proof verification uses the improved Groth16 aggregation verification algorithm to verify the ordering and execution of the proof; the global consensus confirmation uses the optimized PBFT protocol to achieve second-level finality confirmation in a partially synchronous network; the state finalization writes the verified transactions into a Merkle tree by timestamp to form an irreversible on-chain record.

[0033] Preferably, in step S3), the transaction ordering proof π2 submitted by the execution layer at the transaction pool level is verified. ordering Verify the correct order of transactions submitted by the execution layer, ensuring that the execution layer transactions are ordered according to the submission timestamp T. commit Sort the data; verify the transaction execution proof π. execution Verify the correctness of the transaction execution results at the execution layer, ensuring that the transaction execution process complies with the smart contract rules and that the transaction results have not been tampered with.

[0034] Preferably, in step S3), the global consensus confirmation adopts the Byzantine consensus algorithm.

[0035] TS-HBFT, the Byzantine consensus algorithm, requires initialization before execution:

[0036] By initializing the consensus period Epoch to 0, the main consensus committee members MCC are selected through VRF and divided into multiple sub-validation committees SVCList;

[0037] Initialize the proposal buffer (ProposalBuffer) and the consensus buffer (ConsensusBuffer);

[0038] The timeout threshold Δ is dynamically set based on twice the latest network latency.

[0039] Preferably, step S3) of the global consensus confirmation specifically includes the following steps:

[0040] S31) Subcommittee Verification Phase

[0041] Execution layer submits batch proofs {π ordering ,π execution Afterwards, the sub-verification committees (SVCs) work in parallel, using the Groth16 algorithm to aggregate multiple zero-knowledge proofs, resulting in an aggregated proof.

[0042] If the AggregatedProof is successfully verified, a MerkleRoot is generated. The MerkleRoot is then BLS-signed using the private key of the subcommittee, and the signature result is broadcast to the main committee. If the verification fails, the batch of proofs is rejected.

[0043] S32) Main Committee Proposal Stage

[0044] When the main committee receives valid signatures from nf subcommittees, it verifies the validity of the signatures and then aggregates the Merkle roots of all subcommittees into a global root AGG. root BLS signature aggregation into AGG sig Build a pre-prepared message (MSG) preprepare Broadcast to the entire network;

[0045] S33) Verification Phase

[0046] The node verifies the validity of the global Merkle root and aggregate signature of the prepared message, and generates a BLS signature sharing σ upon successful verification. ptepare Build the preparation message MSG prepare Send to the main committee leader and start a dynamic timeout timer Δ; if no commit message is received before the timeout, trigger the fallback mechanism to switch to the backup protocol;

[0047] S34) Submission Phase

[0048] After the main committee collects the preparation messages from 2 / 3 of the nodes, it aggregates the signatures shared by these nodes into a BLS threshold signature, Threshold. sig Construct the commit message MSG commmit Broadcast to all nodes across the network;

[0049] S35), Finalization and Block Generation

[0050] After the node verifies the threshold signature, it constructs the finalized block B based on the global Merkle root. kIt is written to the irreversible ledger, the consensus cycle number Epoch is incremented by 1, a new consensus cycle is entered, and the main committee and sub-committees are reconfigured through VRF.

[0051] The beneficial effects of this invention are as follows:

[0052] 1. This invention can successfully resist various transaction attacks such as pre-transaction attacks and order tampering attacks, with a fair ordering accuracy of 100%; the execution layer uses TEE to achieve physical time binding of transaction ordering, eliminating the possibility of tampering; the verification layer uses BFT consensus to batch verify zero-knowledge proofs to ensure global finality. Even with 10% malicious nodes, it maintains nanosecond-level timing accuracy and fairness, and the attack interception rate is 98.4% higher than the baseline solution.

[0053] 2. This invention reduces the communication complexity from O(n^2) of traditional BFT to O(n^2) through a layered architecture. 2 The computation time is reduced to O(n), and the message volume is reduced by combining BLS aggregate signature; the execution layer and the verification layer are decoupled, with the execution layer focusing on transaction ordering and zero-knowledge proof generation, and the verification layer compressing the overhead of a single proof to the 3ms level through BLS aggregate signature and batch verification technology; the dynamic committee based on VRF random election balances the node load, and at a scale of 200 nodes, the throughput is increased by more than 50% compared with HotStuff;

[0054] 3. This invention has lower latency and communication overhead, and the latency growth trend is significantly lower as the number of nodes increases;

[0055] 4. This invention utilizes zero-knowledge proofs to protect transaction privacy; the execution layer only outputs the execution proof π. execution The transaction content is hidden; the verification layer only needs to verify the proof and does not need to know the details. The transaction is continuously encrypted during the transaction sorting stage to prevent malicious nodes from obtaining information in advance. Attached Figure Description

[0056] Figure 1 This is a flowchart illustrating the method of Embodiment 1 of the present invention;

[0057] Figure 2 This is a flowchart illustrating the encrypted transaction sorting operation of Embodiment 1 of the present invention;

[0058] Figure 3 This is a schematic diagram of the secure transaction execution operation in Embodiment 1 of the present invention;

[0059] Figure 4 This is a flowchart illustrating the Byzantine consensus algorithm of Embodiment 1 of the present invention;

[0060] Figure 5 This is a schematic diagram showing the results of Embodiment 2 of the present invention;

[0061] Figure 6This is a schematic diagram showing the results of Embodiment 3 of the present invention;

[0062] Figure 7 This is a schematic diagram of the results of Embodiment 4 of the present invention. Detailed Implementation

[0063] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings:

[0064] Example 1

[0065] like Figure 1 As shown, this embodiment provides a layered Byzantine consensus method for transaction security, including the following steps:

[0066] S1) Construct a layered architecture that includes an execution layer and a verification layer;

[0067] S2) The user submits a transaction request to the execution layer. After receiving the transaction request, the execution layer performs trusted timestamp generation, encrypted transaction sorting, and secure transaction execution operations.

[0068] S3) Send the relevant information of the transaction results from the execution layer to the verification layer for batch proof verification, global consensus confirmation, and state finalization operations.

[0069] In a preferred embodiment, in step S2), the execution layer generates a globally unique and tamper-proof millisecond-level trusted timestamp T based on the Intel SGX hardware security module. commit The clock source is ensured to be trustworthy through DCAP remote authentication. The encrypted transaction sorting is performed within the TEE secure enclave, sorting encrypted transactions by timestamp and generating a sorting proof containing a trusted timestamp and hash chain. The secure transaction execution utilizes parallel virtual machine technology to execute transactions in a hardware-isolated environment, generating a transaction execution proof π for the transaction results. execution .

[0070] In a preferred embodiment, in step S2), the transaction t submitted by the user includes basic information such as the transaction amount, counterparty, and contract call. After the user submits transaction t, it enters the transaction pool TxPool of the execution layer to wait for sorting. After receiving transaction t, the TEE calculates the trusted timestamp T. commit =TEE-Clock(t)∈N + and transaction hash value H t = hash(t); where TEE-Clock(t) represents the count of the security clock inside the TEE at local time t; N + Represents the set of positive integers; hash is the hash function; the trusted timestamp T is... commit The transaction hash value H is provided by the TEE's internal clock Clock(t). tUsed as a unique identifier for sorting;

[0071] Through trusted timestamp T commit and transaction hash H t Generating zero-knowledge proofs of π commit =ZKP-Proof(H t ,T commit ), where ZKP-Proof represents zero-knowledge proof, and it stores transaction information (H t ,T commit ,π commit It is stored in the execution layer transaction pool TxPool.

[0072] In a preferred embodiment, the encrypted transaction sorting operation in step S2) is as follows: Figure 2 As shown, the details are as follows:

[0073] S221), Input transaction information (H) t ,T commit ,π commit And verify the zero-knowledge proof of π. commit ,

[0074] If zero-knowledge proof of π commit If valid, proceed to step S22);

[0075] S222), for any transaction t i ,t j ∈S, if the reliable timestamp T commit (t i ) <T commit (t j If so, the transaction will be conducted according to... Sort in an ordered transaction sequence S ordered middle;

[0076] S223) Generate batch transaction sorting proof π1 ordering ;Right now:

[0077] π1 ordering =ZK-Prove(C order S ordered ,{π commit});

[0078] Where ZK-Prove represents a zero-knowledge proof protocol; C order S represents the sorting constraint. ordered Represents an ordered sequence of transactions; π commit Proof of zero knowledge;

[0079] S24), Publish the orderly transaction list S ordered =(t1,t2,…,tn ), and store the transaction batch transaction sorting proof π1 ordering Reach the consensus node.

[0080] In a preferred embodiment, in step S2), as follows: Figure 3 As shown, the secure transaction execution operation is as follows:

[0081] S231), according to the trusted timestamp T commit Sort the transactions to generate an ordered set O. t ;Right now:

[0082] O t =sort(TxPool,T commit );

[0083] In the formula, sort represents the sorting operation;

[0084] S232) Generate a transaction ranking proof π2 at the transaction pool level. ordering ,Right now:

[0085] π2 ordering =ZKP-Prove(T) commit O t );

[0086] S233), for an ordered set of transactions O t Each transaction t in i The transaction result is And generate transaction execution proof π execution :

[0087]

[0088] Among them, TEE-Execute(t i ) indicates that a transaction or task is executed within a trusted execution environment. i Operation;

[0089] S234) will trade t i Execution results Transaction Execution Proof π execution Store in executed transaction set E t And prove π2 by sorting transactions at the transaction pool level. ordering and the set of executed transactions E t Send to the verification layer.

[0090] In a preferred embodiment, in step S3), the batch proof verification verifies the ordering and execution proofs using the improved Groth16 aggregation verification algorithm; it verifies the correctness of the transaction ordering submitted by the execution layer by verifying the transaction ordering proof submitted by the execution layer, ensuring that the execution layer transactions are in accordance with the submission timestamp T. commit Sort the data; verify the transaction execution proof π. execution The verification process verifies the correctness of transaction execution results, ensuring that the transaction execution process complies with smart contract rules and that the transaction results have not been tampered with. The global consensus confirmation adopts an optimized PBFT protocol, achieving second-level finality confirmation in partially synchronous networks; the state finalization process writes verified transactions into a Merkle tree by timestamp, forming irreversible on-chain records.

[0091] In a preferred embodiment, in step S3), the global consensus confirmation adopts the Byzantine consensus algorithm TS-HBFT. The Byzantine consensus algorithm TS-HBFT needs to be initialized before execution.

[0092] By initializing the consensus period Epoch to 0, the main consensus committee members MCC are selected through VRF and divided into multiple sub-validation committees SVCList;

[0093] Initialize the proposal buffer (ProposalBuffer) and the consensus buffer (ConsensusBuffer);

[0094] The timeout threshold Δ is dynamically set based on twice the latest network latency.

[0095] like Figure 4 As shown, the specific steps include the following:

[0096] S31) Subcommittee Verification Phase

[0097] Execution layer submits batch proofs {π ordering ,π execution Afterwards, the sub-verification committees (SVCs) work in parallel, using the Groth16 algorithm to aggregate multiple zero-knowledge proofs, resulting in an aggregated proof.

[0098] If the AggregatedProof is successfully verified, a MerkleRoot is generated. The MerkleRoot is then BLS-signed using the private key of the subcommittee, and the signature result is broadcast to the main committee. If the verification fails, the batch of proofs is rejected.

[0099] S32) Main Committee Proposal Stage

[0100] When the main committee receives valid signatures from nf subcommittees, it verifies the validity of the signatures and then aggregates the Merkle roots of all subcommittees into a global root AGG.root BLS signature aggregation into AGG sig Build a pre-prepared message (MSG) preprepare Broadcast to the entire network;

[0101] S33) Verification Phase

[0102] The node verifies the validity of the global Merkle root and aggregate signature of the prepared message, and generates a BLS signature sharing σ upon successful verification. prepare Build the preparation message MSG prepare Send to the main committee leader and start a dynamic timeout timer Δ; if no commit message is received before the timeout, trigger the fallback mechanism to switch to the backup protocol;

[0103] S34) Submission Phase

[0104] After the main committee collects the preparation messages from 2 / 3 of the nodes, it aggregates the signatures shared by these nodes into a BLS threshold signature, Threshold. sig Construct the commit message MSG commmit Broadcast to all nodes across the network;

[0105] S35), Finalization and Block Generation

[0106] After the node verifies the threshold signature, it constructs the finalized block B based on the global Merkle root. k It is written to the irreversible ledger, the consensus cycle number Epoch is incremented by 1, a new consensus cycle is entered, and the main committee and sub-committees are reconfigured through VRF.

[0107] Example 2

[0108] This embodiment provides the application of a layered Byzantine consensus protocol for transaction security in a scenario involving 30 transactions, as detailed below:

[0109] S1) Initialization: Set the consensus period Epoch to 0, select the main consensus committee member MCC through VRF, and divide it into multiple sub-validation committees SVCList; initialize the proposal buffer and consensus buffer; set the timeout threshold Δ;

[0110] S2), Input: 30 ERC-20 transfer transactions;

[0111] S3) Transaction Submission: 30 users submit transactions at the execution layer, and the trusted timestamp T is calculated by the TEE. commit With transaction hash H t Stored in the execution layer transaction pool;

[0112] S4) Execution Layer Transaction Sorting and Execution: The execution layer uses a TEE to sort and execute 30 transactions by timestamp, generating a transaction sorting proof π.ordering and transaction execution proof π executing ;

[0113] S5) Subcommittee Verification: The Subcommittee Verification Committee (SVC) receives batches of zero-knowledge proofs, aggregates the proofs using the Groth16 algorithm, generates a Merkle root after verification, signs it, and broadcasts it to the main committee.

[0114] S6) Main Committee Proposal: After receiving enough signatures from subcommittees, the main committee aggregates the Merkle root and signatures, constructs a pre-prepared message, and broadcasts it to the entire network.

[0115] S7) Verification and Commit: After verifying the pre-preparation message, the node sends a preparation message. After the main committee collects 2 / 3 of the preparation messages, it generates a commit message and broadcasts it. After the node verifies the message, it builds a block and writes it to the ledger.

[0116] like Figure 5 As shown, this embodiment successfully resists pre-transaction attacks and sorting tampering attacks, with a fair sorting accuracy of 100%, and the transaction order is completely consistent with the theory, resulting in a 0% attack success rate.

[0117] Example 3

[0118] This embodiment performs performance testing of a layered Byzantine consensus protocol for transaction security on a 200-node scale.

[0119] This embodiment simulates a partially synchronized network consisting of 200 nodes, with nodes set as honest nodes and malicious nodes (malicious nodes accounting for no more than 33%), performing a large number of transaction processing, recording throughput and latency data, and comparing it with the HotStuff protocol.

[0120] like Figure 6 As shown, the results indicate that at a scale of 200 nodes, the throughput of this method is increased by 53% compared to HotStuff, and the latency is reduced by 20% compared to HotStuff, demonstrating superior performance.

[0121] Example 4

[0122] This embodiment performs performance tests on the layered Byzantine consensus protocol for transaction security at different node scales (40-400 nodes).

[0123] The number of nodes was increased from 40 to 400, and transaction processing was performed at each node scale to test the throughput and latency of this method, PBFT, FastBFT, and HotStuff.

[0124] like Figure 7As shown, in terms of throughput: this method reaches 183 op / s with 40 nodes; when the number of nodes is expanded to 400, the throughput drops to 110 op / s, a decrease of 39.9%, which is much better than FastBFT (throughput of only 8 op / s with 400 nodes) and HotStuff (throughput of only 30 op / s with 400 nodes).

[0125] Regarding latency: with 40 nodes, the latency of this method is 22ms; when the number of nodes is increased to 400, the latency of this method increases to 88ms (an increase of 300%), which is much lower than FastBFT (171ms) and PBFT (210ms), and 34.8% lower than HotStuff.

[0126] The embodiments and descriptions above are merely illustrative of the principles and preferred embodiments of the present invention. Various changes and modifications may be made to the present invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed.

Claims

1. A layered Byzantine consensus method for secure transactions, characterized in that, Includes the following steps: S1) Construct a layered architecture that includes an execution layer and a verification layer; S2) The user submits a transaction request to the execution layer. After receiving the transaction request, the execution layer performs trusted timestamp generation, encrypted transaction sorting, and secure transaction execution operations. S3) Send the relevant information of the transaction results from the execution layer to the verification layer for batch proof verification, global consensus confirmation, and state finalization operations.

2. The layered Byzantine consensus method for transaction security according to claim 1, characterized in that: In step S2), the execution layer generates a globally unique and tamper-proof millisecond-level trusted timestamp T based on the Intel SGX hardware security module. commit And the clock source is ensured to be trustworthy through DCAP remote certification.

3. The layered Byzantine consensus method for transaction security according to claim 2, characterized in that: In step S2), the encrypted transaction sorting is performed by timestamp within the TEE secure enclave, generating a transaction sorting proof containing a trusted timestamp and hash chain.

4. The layered Byzantine consensus method for transaction security according to claim 3, characterized in that: In step S2), the secure transaction execution utilizes parallel virtual machine technology to execute transactions in a hardware-isolated environment, generating a transaction execution proof π of the transaction result. execution .

5. The layered Byzantine consensus method for transaction security according to claim 4, characterized in that: In step S2), the user-submitted transaction t enters the execution layer's transaction pool TxPool to await sorting. After receiving transaction t, the TEE calculates the trusted timestamp T. commit =TEE-Clock(t)∈N + and transaction hash value H t = hash(t); where TEE-Clock(t) represents the count of the security clock inside the TEE at local time t; N + Represents the set of positive integers; The trusted timestamp T commit The transaction hash value H is provided by the TEE's internal clock Clock(t). t Used as a unique identifier for sorting; Through trusted timestamp T commit and transaction hash value H t Generating zero-knowledge proofs of π commit =ZKP-Proof(H t ,T commit ), where ZKP-Proof represents zero-knowledge proof, and it stores transaction information (H t ,T commit ,π commit It is stored in the execution layer transaction pool TxPool.

6. The layered Byzantine consensus method for transaction security according to claim 5, characterized in that: In step S2), the encrypted transaction sorting operation is specifically as follows: S221), Input transaction information (H) t ,T commit ,π commit And verify the zero-knowledge proof of π. commit If zero-knowledge proof of π commit If valid, proceed to step S22); S222), for any transaction t i ,t j ∈S, if the reliable timestamp T commit (t i ) <T commit (t j If ), then the transaction will be processed according to t. i <t j Sort in an ordered transaction sequence S ordered In the middle; where S is the transaction set, S223) Generate batch transaction sorting proof π1 ordering ;Right now: p1 ordering =ZK-Prove(C order ;S ordered ,{π commit }); Where ZK-Prove represents a zero-knowledge proof protocol; C otder S represents the sorting constraint. otdered Represents an ordered sequence of transactions; π commit Proof of zero knowledge; S24), Publish the orderly transaction list S ordered =(t1,t2,…,t n ), and store the batch transaction sorting proof π1 ordering Reach the consensus node.

7. The layered Byzantine consensus method for transaction security according to claim 6, characterized in that: In step S2), the secure transaction execution operation is performed as follows: S231), according to the trusted timestamp T commit Sort the transactions to generate an ordered transaction set O. t ;Right now: O t =sort(TxPool,T commit ); S232) Generate a transaction ranking proof π2 at the transaction pool level. ordering ,Right now: π2 ordering =ZKP-Prove(T commit ,O t ); S233), for an ordered set of transactions O t Each transaction t in i The transaction result is And generate a transaction execution proof π execution : Among them, TEE-Execute(t i ) indicates that a transaction or task is executed within a trusted execution environment. i The operation. S234) will trade t i Execution results Transaction Execution Proof π execution Store in executed transaction set E t And prove π2 by sorting transactions at the transaction pool level. ordering and the set of executed transactions E t Send to the verification layer.

8. The layered Byzantine consensus method for transaction security according to claim 7, characterized in that: In step S3), the batch proof verification uses the improved Groth16 aggregation verification algorithm to verify the ordering and execution of proofs; the global consensus confirmation uses the optimized PBFT protocol to achieve second-level finality confirmation in a partially synchronous network; the state finalization writes the verified transactions into a Merkle tree by timestamp to form irreversible on-chain records.

9. The layered Byzantine consensus method for transaction security according to claim 8, characterized in that: In step S3), the global consensus confirmation adopts the Byzantine consensus algorithm TS-HBFT. The Byzantine consensus algorithm TS-HBFT needs to be initialized before execution. By initializing the consensus period Epoch to 0, the main consensus committee members MCC are selected through VRF and divided into multiple sub-validation committees SVCList; Initialize the proposal buffer (ProposalBuffer) and the consensus buffer (ConsensusBuffer); The timeout threshold Δ is dynamically set based on twice the latest network latency.

10. The layered Byzantine consensus method for transaction security according to claim 9, characterized in that: Step S3), the global consensus confirmation, specifically includes the following steps: S31) Subcommittee Verification Phase Execution layer submits batch proofs {π ordering ,π execution Afterwards, each sub-verification committee (SVC) works in parallel, using the Groth16 algorithm to aggregate multiple zero-knowledge proofs to obtain an aggregated proof (AggregatedProof). If the verification is successful, a MerkleRoot is generated. The MerkleRoot is then BLS-signed using the private key of the sub-committee, and the signature result is broadcast to the main committee. If the verification fails, the batch of proofs is rejected. S32) Main Committee Proposal Stage When the main committee receives valid signatures from nf subcommittees, it verifies the validity of the signatures and then aggregates the Merkle roots of all subcommittees into a global root AGG. root BLS signature aggregation into AGG sig Build a pre-prepared message (MSG) preprepare Broadcast to the entire network; S33) Verification Phase The node verifies the validity of the global Merkle root and aggregate signature of the prepared message, and generates a BLS signature sharing σ upon successful verification. prepare Build the preparation message MSG prepare Send to the head committee leader and start the dynamic timeout timer Δ; If no submission message is received within the timeout period, a fallback mechanism is triggered to switch to the backup protocol; S34) Submission Phase After the main committee collects the preparation messages from 2 / 3 of the nodes, it aggregates the signatures shared by these nodes into a BLS threshold signature, Threshold. sig Construct the commit message MSG commmit Broadcast to all nodes across the network; S35), Finalization and Block Generation After the node verifies the threshold signature, it constructs the finalized block B based on the global Merkle root. k It is written to the irreversible ledger, the consensus cycle number Epoch is incremented by 1, a new consensus cycle is entered, and the main committee and sub-committees are reconfigured through VRF.

Images