A cross-chain transaction method based on aggregated zero-knowledge proof

Abstract

The present invention discloses a cross-chain transaction method based on aggregated zero-knowledge proof, which belongs to the field of cross-chain transaction technology; including: an adaptive adjustment method of system load, optimizing batch size and branching factor; a cross-chain block aggregation method of a multi-branch balanced Merkle tree, increasing node branching factor; a rebalancing method of a local multi-branch Merkle tree, identifying and synchronizing the differences between local and global cross-chain multi-branch balanced Merkle trees; a secure multi-party computing method, verifying the data integrity of aggregated blocks. The present invention uses a cross-chain block aggregation method of a multi-branch balanced Merkle tree to pass aggregated zero-knowledge proofs between chains to verify the legitimacy of batch cross-chain transactions, significantly reducing the verification cost of cross-chain transactions while maintaining security and versatility; a secure multi-party computing aggregate block integrity verification method is used to ensure that the integrity of aggregated data is not destroyed, thereby preventing potential threats to aggregated data from malicious attacks.

Description

Technical Field

[0001] The present invention belongs to the technical field of cross-chain transactions, and specifically relates to a cross-chain transaction method based on aggregated zero-knowledge proof. Background Art

[0002] With the rapid development of the blockchain industry, the value exchange between various public, private and alliance chains has become increasingly important. Applications and assets on a single chain can no longer meet increasingly complex needs. Cross-chain technology has emerged to provide solutions for the interoperability of assets and data between different blockchain networks, significantly improving the interoperability and scalability of the blockchain ecosystem. The current mainstream cross-chain technology solutions include notaries, side chains and relay solutions. Among them, the relay solution has received widespread attention and application because it can achieve rapid information transmission and asset transfer between different blockchain networks. This solution promotes the flow of assets and data on the chain by using a dedicated relay chain or node as a bridge, greatly improving the efficiency and practicality of cross-chain interaction. However, since cross-chain operations involve information exchange and asset transfer between multiple chains, users' privacy and asset security are facing potential threats. Although the existing relay solution can ensure fast transaction confirmation and cross-chain asset transfer, the user's transaction details or asset information may be exposed during the information transmission and verification process, and then face the risk of malicious analysis or attack.

[0003] In order to solve these problems, researchers have introduced zero-knowledge proof technology in recent years. Zero-knowledge proof is a cryptographic technology that allows the prover to prove the correctness of a statement to the verifier without revealing the statement itself. Based on concise non-interactive zero-knowledge proof, a high level of anonymity and transaction privacy protection can be achieved for the blockchain. In addition, zero-knowledge proof can also enhance the security of cross-chain transactions by ensuring that participants must provide valid evidence to support their claims, thereby preventing malicious behavior and fraud. Therefore, the introduction of zero-knowledge proof technology helps to balance the needs of data privacy and transaction security in cross-chain operations, bringing new guarantees and possibilities for the interoperability of blockchain and crypto economy.

[0004] Although zero-knowledge proofs provide important support for privacy protection, the balance between efficiency and privacy still faces significant challenges. As the number of zero-knowledge proofs increases, their verification time increases linearly, which is particularly prominent in high-throughput cross-chain transaction environments. This growth has led to a significant increase in the burden of transaction generation and privacy calculations, which in turn affects the overall efficiency and responsiveness of the system. In addition, the coupling of the cross-chain verification mechanism with the underlying mechanisms of each blockchain further increases the complexity and potential security risks of the system. Therefore, solving the compatibility issues between different blockchain protocols and ensuring the smooth progress of cross-chain operations is also one of the challenges that need to be solved urgently.

[0005] The China Patent Library has disclosed (application number: 2024105812540) a cross-chain transaction method and device based on multi-signature and zero-knowledge proof, which specifically discloses: the user node sends a cross-chain transaction request through the first blockchain, and after the system verifies the attached zero-knowledge proof of the transaction request, it finds a matching transaction node on the second blockchain; after determining the transaction node, a transaction confirmation zero-knowledge proof is generated based on the address information of the transaction node; the signature node group of the first blockchain performs multi-signatures on the zero-knowledge proof, generates the first signature data, and sends it to the transaction node together with the zero-knowledge proof. After the transaction node verifies the first signature data and the zero-knowledge proof of transaction confirmation, it generates and returns the transaction confirmation information; the system executes the pre-transaction on the first blockchain based on the information and generates the pre-transaction result. After the pre-transaction result is confirmed by the smart contract, a zero-knowledge proof of the transaction result is generated, and the second signature data is generated through multiple signatures; finally, the system sends the second signature data and the zero-knowledge proof of the transaction result to the smart contract and the transaction node to complete the cross-chain transaction.

[0006] The China Patent Library has disclosed (Application No.: 2023104734817) a privacy-preserving cross-chain transaction verification method based on zero-knowledge proof, which specifically discloses: First, the system initializes the cross-chain node of the relay chain, the parachain registers the chain through the relay chain, and the service chain submits the service list. At the same time, the parachain synchronizes the block header to the relay chain in real time, and the relay chain maintains and stores the valid block header information of each chain. The source chain generates a zero-knowledge proof based on the block header and adds it to the cross-chain request list to prove that the cross-chain transaction does exist on the chain. The relay chain then uses the zero-knowledge set membership proof method to review the legitimacy of the cross-chain transaction and confirm whether the target service is in the cross-chain service list. The cross-chain node of the source chain encrypts the transaction content to generate ciphertext, and the cross-chain node of the target chain reads the request and decrypts it through the parachain to complete the verification of the cross-chain transaction.

[0007] The above patent, a cross-chain transaction method and device based on multi-signature and zero-knowledge proof, has the following deficiencies:

[0008] 1. In cross-chain transactions, at least two multi-signatures are required. Each multi-signature involves the participation of multiple nodes, and these nodes are randomly selected from M nodes. As the number of signature nodes increases, the verification and communication overhead will also increase significantly, increasing the complexity of the system and transaction costs;

[0009] 2. Two zero-knowledge proofs need to be generated and verified during transaction confirmation and pre-transaction. The first is used to confirm the transaction node, and the second is used to verify the pre-transaction result. This repetitiveness will lead to additional calculation and time overhead, especially when multiple rounds of zero-knowledge proof verification are performed on the chain, the performance may decrease.

[0010] 3. The signature node group is randomly selected from M nodes, which may bring potential security issues; if the signature node group is not selected properly, there are malicious nodes or some nodes fail, it will pose a threat to the security and reliability of cross-chain transactions. In addition, the randomness of node selection may also lead to uncertainty in transaction confirmation time.

[0011] The above patent is a privacy-preserving cross-chain transaction verification method based on zero-knowledge proof, which has the following shortcomings:

[0012] 1. The patent generates and verifies zero-knowledge proofs multiple times in different steps, especially in the generation of zero-knowledge proofs on the source chain, the verification of legitimacy on the relay chain, and the decryption operation on the target chain, which increases the computational and communication overhead of the entire system. Each proof and verification process requires a lot of computing resources and time;

[0013] 2. The patent maintains a growing list of block headers on the relay chain, which requires a large amount of storage and computing resources, and requires the relay chain to be able to effectively synchronize and process this data. This complex communication structure is prone to cause network delays and synchronization inconsistencies, thereby increasing the instability of the system;

[0014] 3. The patent relies on the relay chain for cross-chain verification, service list maintenance, and proof of legitimacy check. This architecture that relies on the relay chain may have potential risks in performance and security. If the relay chain becomes a bottleneck or is attacked, it will affect the smooth progress of the entire cross-chain transaction.

[0015] In summary, how to solve the increased computing and communication overhead in the process of cross-chain asset transactions using zero-knowledge proof, the malicious attacks that occur during the aggregation process, and the resource allocation and performance adaptation problems in cross-chain transaction processing are the technical problems that the present invention aims to solve. Summary of the invention

[0016] The purpose of the present invention is to provide a cross-chain transaction method based on aggregated zero-knowledge proof to solve the problems raised in the above background technology.

[0017] The object of the present invention is achieved by: a cross-chain transaction method based on aggregated zero-knowledge proof, characterized in that the method comprises the following steps:

[0018] Step S1: Build a large-scale cross-chain transaction system, optimize the batch size and branching factor based on the adaptive adjustment method of system load;

[0019] The large-scale cross-chain transaction system includes a blockchain network, a smart contract, a peer node, a packaging node, a verification node, a relay network, and a gateway node;

[0020] Step S2: Adopt a cross-chain block aggregation method based on a multi-branch balanced Merkle tree to increase the node branching factor and improve query and verification efficiency;

[0021] Step S3: Use the local multi-branch Merkle tree rebalancing method to quickly identify and synchronize the differences between the local and global cross-chain multi-branch balanced Merkle trees to ensure that the branches and tree heights of each local tree are balanced;

[0022] Step S4: Introduce a secure multi-party computing method based on secret sharing to verify the data integrity of the aggregated block.

[0023] Preferably, the blockchain network is responsible for maintaining the transaction ledger and executing the smart contract; the blockchain network includes a source blockchain A for initiating cross-chain transactions and a target blockchain B for executing cross-chain transactions;

[0024] Smart contracts are responsible for managing cross-chain transaction logic and rules. Smart contracts receive, process and record cross-chain transaction information on the blockchain network and broadcast transactions to all nodes in the network.

[0025] Peer nodes are responsible for verifying and processing cross-chain transactions, packaging legal cross-chain transactions to generate new cross-chain blocks, and broadcasting them to other peer nodes in the network to reach consensus;

[0026] The packaging node is responsible for performing the cross-chain block aggregation operation, randomly grouping the cross-chain blocks, and aggregating the cross-chain blocks of each group in the form of a multi-branch balanced Merkle tree to generate an aggregated Merkle root;

[0027] The verification node is responsible for generating zero-knowledge proofs for aggregated batch cross-chain blocks. The verification node verifies the integrity of batch cross-chain blocks through secure multi-party computation and generates aggregate zero-knowledge proofs for legal aggregate Merkle roots.

[0028] The relay network is responsible for transmitting information and proofs between different blockchain networks;

[0029] The gateway node is responsible for connecting the relay network and various heterogeneous blockchains, and transmitting the generated aggregated zero-knowledge proof to the target blockchain.

[0030] Preferably, the blockchain network adopts a heterogeneous blockchain network, which refers to a blockchain network with different structures and underlying mechanisms.

[0031] The source blockchain and the target blockchain are both heterogeneous blockchain networks.

[0032] Preferably, the batch size and branching factor are optimized in step S1, specifically:

[0033] Step S1-1: Assume that the system load matrix is , the corresponding weight matrix is ;

[0034] The packaging node continuously monitors the real-time load of the cross-chain network and the cross-chain demand on the source blockchain A, and records the load matrix of each large-scale cross-chain transaction system. , and its maximum value , minimum and the average ;

[0035] Step S1-2: When the packaging node receives an aggregation request from a cross-chain contract, it normalizes the current large-scale cross-chain transaction system load to obtain and , calculate the current optimal batch size ;

[0036] After Min-Max normalization, we get:

[0037] ;

[0038] ;

[0039] in, is the normalized load matrix; is the normalized mean value;

[0040] The batch size is adjusted dynamically by the following formula:

[0041] ;

[0042] ;

[0043] ;

[0044] in, is the overall load factor, is the target load factor, is the adjustment coefficient, which is used to control the speed of adjustment; is the system load matrix The corresponding weight matrix is, is the batch size recalculated based on current system resources, The batch size for current system resources;

[0045] Step S1-3: Packing nodes calculate the batch size , adjust the branching factor The total cost The smallest, that is, the optimal branching factor .

[0046] Preferably, the optimal branching factor in step S1-3 is The specific acquisition method is as follows:

[0047] Assume that the size of the tree is the total number of nodes, that is ;in, is the branching factor;

[0048] The communication cost is proportional to the size of the tree, so the communication cost ;

[0049] in, is a constant related to communication;

[0050] Optimal branching factor ;

[0051] ;

[0052] in, and is the weight factor of communication overhead and computational overhead in the total overhead, is a constant related to communication, and are the computational overhead required for an addition operation and a hash operation, respectively. The total number of verification nodes participating in the aggregate integrity verification.

[0053] Preferably, the cross-chain block aggregation method of the multi-branch balanced Merkle tree in step S2 is to aggregate the cross-chain blocks submitted to the packaging node in the form of a multi-branch balanced Merkle tree to obtain an aggregated Merkle root The specific operations are:

[0054] Step S2-1: Randomly group each cross-chain block submitted to the packaging node, and the number of cross-chain blocks in each group is the calculated batch size; each cross-chain block is used as a leaf node;

[0055] Step S2-2: According to the timestamp order in the block header, the packaging node organizes it into branches with a factor of Merkle tree, thereby constructing a global cross-chain multi-branch balanced Merkle tree and obtaining the aggregated Merkle root .

[0056] Preferably, the rebalancing method of the local multi-branch Merkle tree in step S3 is that each verification node rebalances the local cross-chain multi-branch Merkle tree after receiving its own cross-chain block, and the specific operations are:

[0057] Step S3-1: Assume that The verification nodes are , the number of cross-chain blocks it owns is , ; Determine the current verification node The number of cross-chain blocks owned Can it be If the condition is not divisible, copy the last cross-chain block until it meets the condition;

[0058] Step S3-2: Calculate the height of the local multi-branch Merkle tree constructed by the current verification node , and with the target tree height Compare; if they are consistent, then end; if they are inconsistent, continue to execute step S3-3;

[0059] Step S3-3: If the current verification node The number of cross-chain blocks owned , then recursively copy all cross-chain blocks owned by the current verification node until the number of cross-chain blocks is ; If the current verification node The number of cross-chain blocks owned , then copy the cross-chain block of the previous subtree at the same level until the number of cross-chain blocks is , and then recursively copy all cross-chain blocks owned by the current verification node until the number of cross-chain blocks is ;

[0060] Step S3-4: The verification node uses all the cross-chain blocks it currently owns to build a local cross-chain multi-branch balanced Merkle tree and return the local aggregated Merkle root .

[0061] Preferably, in step S4, a secure multi-party computing method based on secret sharing is introduced to select a suitable sharding method for the packaging node, and the cross-chain block sharding secret is shared to Verification nodes, among which, m∈[1, N b ] , No. The number of cross-chain blocks owned by a verification node is recorded as , the specific operations are:

[0062] Step S4-1: The packaging node searches for the closest average shard, and the shard size is of value, ensuring that each verification node can obtain a reasonable amount of computing tasks;

[0063] Step S4-2: Based on the obtained fragment size Calculate target tree height ;

[0064] Step S4-3: Based on the calculated shard size , the packaging node will verify the cross-chain block Shard the data and obtain the cross-chain blocks after sharding ;

[0065] Step S4-4: The fragmented data Randomly distributed to each verification node through secret sharing.

[0066] Preferably, in step S4-3, the packaging node sends the cross-chain block to be verified Data sharding is performed by using the following formula:

[0067] ;

[0068] in, is the number of validating nodes; It is The cross-chain block array assigned to the verification nodes, Is the best for sharding value.

[0069] Compared with the prior art, the present invention has the following improvements and advantages:

[0070] 1. By adopting a cross-chain block aggregation method based on a multi-branch balanced Merkle tree, the aggregated zero-knowledge proof is transmitted between chains to verify the legitimacy of batch cross-chain transactions, and the verification task is transferred to the chain, thereby significantly reducing the verification cost of cross-chain transactions while maintaining security and versatility.

[0071] 2. By adopting an aggregated block integrity verification method based on secure multi-party computing, data is securely shared and calculated between multiple verification nodes to ensure that the integrity of the aggregated data is not destroyed, thereby preventing potential threats to the aggregated data from malicious attacks and ensuring the accuracy and reliability of cross-chain transactions.

[0072] 3. Dynamically adjust the cross-chain transaction aggregation processing strategy by adopting an adaptive aggregation optimization method based on system load to improve the system's responsiveness and resource utilization efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0073] Figure 1 This is a working diagram of the large-scale cross-chain transaction system in the present invention.

[0074] Figure 2 Flow chart of the aggregated zero-knowledge proof generation process in the present invention.

[0075] Figure 3 The figure is a flowchart of cross-chain transactions.

[0076] Figure 4 Schematic diagram of the impact of branching factor on the integrity verification time of aggregated blocks.

[0077] Figure 5 This is a diagram showing the impact of batch size and branch factor on CPU usage.

[0078] Figure 6 Schematic diagram of the effect of batch size and branching factor on resulting memory usage.

[0079] Figure 7 Results for batch size and branching factor on time.

[0080] Figure 8 Results for the impact of batch size and branch factor on the number of CPU context switches.

[0081] Fig. 9 Results for batch size and branching factor affect the number of disk reads.

[0082] Fig.10 A comparison of the CPU usage and memory usage of the two models when generating and verifying aggregated zero-knowledge proofs for 1000 cross-chain blocks.

[0083] Fig.11 A comparison chart of the time consumption and CPU context switching times of the two models when generating and verifying aggregated zero-knowledge proofs for 1000 cross-chain blocks.

[0084] Fig.12 Comparison of disk I / O reads and zero-knowledge proof size for the two models when generating and verifying aggregated zero-knowledge proofs for 1000 cross-chain blocks. DETAILED DESCRIPTION

[0085] The present invention is further summarized below with reference to the accompanying drawings.

[0086] like Figure 1 As shown, a cross-chain transaction method based on aggregated zero-knowledge proof includes the following steps:

[0087] Step S1: Build a large-scale cross-chain transaction system, optimize the batch size and branching factor based on the adaptive adjustment method of system load;

[0088] The large-scale cross-chain transaction system includes blockchain networks, smart contracts, peer nodes, packaging nodes, verification nodes, relay networks, and gateway nodes;

[0089] The blockchain network is the basic platform for cross-chain transactions, responsible for maintaining transaction ledgers and executing smart contracts. The execution of each transaction involves two homogeneous or heterogeneous blockchains, including the source blockchain A that initiates the cross-chain transaction and the target blockchain B that executes the cross-chain transaction.

[0090] Smart contracts are self-executing codes deployed on the blockchain network, responsible for managing cross-chain transaction logic and rules; cross-chain contracts receive, process and record cross-chain transaction information on the blockchain network, and broadcast transactions to all nodes in the network.

[0091] Peer nodes are responsible for transaction verification and processing, block generation and propagation, and consensus achievement on the blockchain network. Transactions include local transactions and cross-chain transactions. When peer nodes collect and verify a certain number of cross-chain transactions, they package the legal cross-chain transactions to generate new cross-chain blocks, which are then broadcast to other peer nodes in the network to reach consensus.

[0092] The packaging node is responsible for performing cross-chain block aggregation operations on the blockchain network, randomly grouping cross-chain blocks, and aggregating the cross-chain blocks of each group in the form of a multi-branch balanced Merkle tree to generate an aggregated Merkle root;

[0093] The verification node is responsible for generating zero-knowledge proofs for aggregated batch cross-chain blocks on the blockchain network. The verification node verifies the integrity of batch cross-chain blocks through secure multi-party computing and generates aggregated zero-knowledge proofs for legal aggregated Merkle roots.

[0094] The relay network is a bridge for cross-chain communication, responsible for transmitting information and proofs between different blockchain networks; the present invention adopts aggregated zero-knowledge proof to transmit cross-chain information of heterogeneous blockchains; this model not only eliminates complete trust in the relay network, but also makes the relay network unnecessary to handle the complex protocols and data formats of different blockchains.

[0095] The gateway node is responsible for connecting the relay network and various heterogeneous blockchain networks, and passing the generated aggregated zero-knowledge proof to the target blockchain to complete the confirmation and execution of cross-chain transactions.

[0096] Heterogeneous blockchain networks refer to blockchain networks with different structures and underlying mechanisms. It can be said that the source blockchain A and the target blockchain B are heterogeneous. The source blockchain is a heterogeneous blockchain network, and the target chain is also a heterogeneous blockchain network.

[0097] In a complex cross-chain network environment, a fixed batch size that is too large will lead to a waste of system resources, while a fixed batch size that is too small will reduce processing efficiency and increase network latency. Similarly, a fixed branching factor may bring unnecessary communication and computing overhead during the verification process of a multi-branch balanced Merkle tree. An adaptive adjustment method based on system load is adopted to optimize the batch size and branching factor to improve the overall performance and resource utilization efficiency of the system.

[0098] In step S1, the adaptive adjustment method based on the system load is used to optimize the batch size and the branching factor. The specific operations are as follows:

[0099] Step S1-1: Assume that the system load matrix is , the corresponding weight matrix is ;

[0100] The packaging node continuously monitors the real-time load of the cross-chain network and the cross-chain demand on the source blockchain A, and records the load matrix of each large-scale cross-chain transaction system. , and its maximum value , minimum and the average ;

[0101] Step S1-2: When the packaging node receives an aggregation request from a cross-chain contract, it normalizes the current large-scale cross-chain transaction system load to obtain and , calculate the current optimal batch size ;

[0102] After Min-Max normalization, we get and ;

[0103] The batch size is adjusted dynamically by the following formula:

[0104] ;

[0105] ;

[0106] ;

[0107] in, is the overall load factor, is the target load factor, is the adjustment coefficient, which is used to control the speed of adjustment; is the system load matrix The corresponding weight matrix is, is the batch size recalculated based on current system resources, The batch size for current system resources.

[0108] When verifying the integrity of batch cross-chain blocks aggregated in the form of a multi-branch balanced Merkle tree, due to the introduction of secure multi-party computation, it is necessary to distribute the sharded global cross-chain multi-branch balanced Merkle tree to multiple verification nodes, and each verification node undertakes part of the verification work; therefore, the total overhead spent in this process mainly includes two parts, namely the communication overhead required for distributing verification tasks and the computational overhead required for each node to perform verification work; the communication overhead refers to the total overhead required to transmit the sharded global cross-chain Merkle tree to different verification nodes when performing batch block integrity verification through secure multi-party computation.

[0109] Step S1-3: Packing nodes calculate the batch size , adjust the branching factor The total cost The smallest, that is, the optimal branching factor ;

[0110] Optimal branching factor The specific acquisition method is as follows:

[0111] Assume that the size of the tree is the total number of nodes, that is ;in, is the branching factor;

[0112] Since the communication cost is proportional to the size of the tree, the communication cost ;

[0113] in, is a constant related to communication;

[0114] The computational overhead refers to the sum of the computational overhead consumed by each node to reconstruct the global cross-chain multi-branch balanced Merkle tree when performing verification work. Since the atomic operations required to construct a multi-branch balanced Merkle tree are only addition operations and hash operations; assuming that the computational overhead required for an addition operation and a hash operation is and , No. The computational cost of the layer is:

[0115] ;

[0116] in, It is The number of nodes in the layer, is the branching factor;

[0117] The computational overhead required to reconstruct the global cross-chain multi-branch balanced Merkle tree :

[0118] ;

[0119] in, is the total number of verification nodes participating in secure multi-party computing, The number of blocks allocated to each verification node, is the batch size;

[0120] It can be seen that both communication overhead and computational overhead are related to the branching factor Related; Dynamically adjust the branching factor , so as to minimize the cost of verifying the legitimacy of batch blocks through secure multi-party computing, and the optimal branching factor ;

[0121] in, and is the weight factor of communication overhead and computational overhead in the total overhead, is a constant related to communication, and They are the computational overhead required for an addition operation and a hash operation respectively.

[0122] Step S2: Adopt a cross-chain block aggregation method based on a multi-branch balanced Merkle tree to increase the node branching factor and improve query and verification efficiency. The specific operations are as follows:

[0123] Step S2-1: Randomly group each cross-chain block submitted to the packaging node, and the number of cross-chain blocks in each group is the calculated batch size; each cross-chain block is used as a leaf node;

[0124] Step S2-2: According to the timestamp order in the block header, the packaging node organizes it into branches with a factor of Merkle tree, thereby constructing a global cross-chain multi-branch balanced Merkle tree and obtaining the aggregated Merkle root .

[0125] After introducing secure multi-party computation to verify the integrity of aggregated cross-chain blocks, how to ensure the consistency of the reconstructed global cross-chain multi-branch balanced Merkle tree with the original global cross-chain multi-branch balanced Merkle tree becomes a key issue; due to the imbalance of branches or tree heights of local trees, each verification node may generate inconsistent global tree structures when reconstructing the global cross-chain multi-branch balanced Merkle tree, resulting in the inability to achieve synchronization; In order to solve this problem, a local multi-branch Merkle tree rebalancing method is proposed; Before executing the verification task, each verification node quickly identifies and synchronizes the differences between the local and global cross-chain multi-branch balanced Merkle trees by node replication and tree height alignment, ensuring that the branches and tree heights of each local tree are balanced, and improving the efficiency and reliability of data synchronization and consistency verification in distributed systems; Specifically, for the number of leaf nodes with unbalanced branches, the last leaf node is copied until the conditions are met to ensure that the number of branches of all local trees is the same; for the number of leaf nodes with unbalanced tree heights, the leaf nodes are completed by calculating and comparing the local tree heights of each verification node to ensure that the heights of all local trees are consistent with the target height.

[0126] Step S3: Use the local multi-branch Merkle tree rebalancing method to quickly identify and synchronize the differences between the local and global cross-chain multi-branch balanced Merkle trees to ensure that the branches and tree heights of each local tree are balanced. The specific operations are as follows:

[0127] Step S3-1: Assume that The verification nodes are , the number of cross-chain blocks it owns is , ; Determine the current verification node The number of cross-chain blocks owned Can it be If the condition is not divisible, copy the last cross-chain block until it meets the condition;

[0128] Step S3-2: Calculate the height of the local multi-branch Merkle tree constructed by the current verification node , and with the target tree height Compare; if they are consistent, then end; if they are inconsistent, continue to execute step S3-3;

[0129] Step S3-3: If the current verification node The number of cross-chain blocks owned , then recursively copy all cross-chain blocks owned by the current verification node until the number of cross-chain blocks is ; If the current verification node The number of cross-chain blocks owned , then copy the cross-chain block of the previous subtree at the same level until the number of cross-chain blocks is , and then recursively copy all cross-chain blocks owned by the current verification node until the number of cross-chain blocks is ;

[0130] Step S3-4: The verification node uses all the cross-chain blocks it currently owns to build a local cross-chain multi-branch balanced Merkle tree and return the local aggregated Merkle root .

[0131] Step S4: Introduce a secure multi-party computing method based on secret sharing to verify the data integrity of the aggregated block. The specific operation is: introduce a secure multi-party computing method based on secret sharing to select a suitable sharding method for the packaging node, share the cross-chain block sharding secret to Verification nodes, among which, m∈[1, N b ] , No. The number of cross-chain blocks owned by a verification node is recorded as ;

[0132] Step S4-1: The packaging node searches for the closest average shard, and the shard size is of value, ensuring that each verification node can obtain a reasonable amount of computing tasks;

[0133] Step S4-2: Based on the obtained fragment size Calculate target tree height ;

[0134] Step S4-3: Based on the calculated shard size , the packaging node will verify the cross-chain block Shard the data and obtain the cross-chain blocks after sharding ;

[0135] The packaging node will verify the cross-chain block Data sharding is performed by using the following formula:

[0136] ;

[0137] in, is the number of validating nodes; It is The cross-chain block array assigned to the verification nodes, Is the best for sharding value;

[0138] Step S4-4: The fragmented data Randomly distributed to each verification node through secret sharing.

[0139] After each verification node rebalances the local multi-branch Merkle tree, it performs its own verification tasks, builds a local cross-chain multi-branch balanced Merkle tree, and obtains the local aggregated Merkle root. Collect the local aggregate Merkle roots returned by all verification nodes , and merge them into a reconstructed global cross-chain multi-branch balanced Merkle tree, and get a new aggregate Merkle root If the reconstructed aggregate Merkle root With the global aggregate Merkle root If the same, indicating that the integrity of the aggregated block has not been compromised, an aggregated zero-knowledge proof is generated for the cross-chain block of the group.

[0140] In order to prove the performance of the cross-chain transaction method based on aggregated zero-knowledge proof (hereinafter referred to as the scheme) proposed in this invention application, we conducted multiple sets of simulation experiments to evaluate our proposed scheme; we focused on evaluating the performance of the method under different parameter settings, and compared the differences in computing resource consumption between the scheme and the traditional zero-knowledge proof cross-chain scheme, and also compared the scheme with other cross-chain schemes in terms of contract deployment and operating costs.

[0141] The proposed scheme was implemented using Python 3.10.12 on a Linux server equipped with an Intel(R) Xeon(R) Gold 6230R CPU @ 2.10GHz and 128GB. A cross-chain smart contract was written using the Solidity and Hardhat frameworks and deployed on Ethereum's testnet respectively.

[0142] We deeply analyzed the impact of batch size and branching factor on the performance of the solution and explored how to maximize efficiency and throughput under different conditions by dynamically adjusting parameters:

[0143] like Figure 4As shown in the figure, the effect of branching factor on the verification time of aggregated block integrity is shown; experimental data show that as the branching factor increases, the verification time generally shows a downward trend and tends to stabilize after reaching a certain level. The larger the branching factor, the lower the height of the Merkle tree, and the computing tasks are more concentrated, thereby reducing the verification time. However, when the branching factor is small (about 0 to 25), the situation is different. At this time, the number of child nodes of each node is small, resulting in a higher height of the tree, and more hash calculations are required during the verification process. Due to the dispersion of computing tasks and the increase in steps, the overall verification time will be affected by large fluctuations. As the branching factor increases further (more than about 25), the height of the Merkle tree decreases, the task of building the local tree becomes simpler, the verification time tends to stabilize, and the overall verification efficiency is improved.

[0144] like Figure 5 , 6 ,7, 8, and 9 show the effects of batch size and branching factor on CPU occupancy, memory usage, time, number of CPU context switches, and number of disk reads; Figure 5 It shows that as the batch size increases, the CPU occupancy rate fluctuates more significantly. When the batch size is small (such as 0 to 500), the amount of data processed each time is small and the task switching is frequent, but the overhead of each task processing is relatively small, so the CPU occupancy rate is relatively stable; as the batch size increases, the amount of data processed by a single task increases, and the complexity of task processing increases, resulting in increased fluctuations in the CPU occupancy rate. At the same time, the larger the branching factor, the lower the CPU occupancy rate. A larger branching factor (such as a branching factor of 30 or 40) reduces the depth of the Merkle tree, which reduces the number of calculations and task switching times, so that the CPU occupancy rate is relatively low and the change is relatively stable. On the contrary, a smaller branching factor (such as a branching factor of 10 or 20) reduces the number of child nodes under each node, increases the depth of the Merkle tree, and leads to more calculations and task switching, so that the CPU occupancy rate is high and fluctuates greatly.

[0145] A smaller branching factor can allocate computing tasks in a more granular manner, which is suitable for scenarios with small tasks or high parallelism. However, the task distribution may be uneven, resulting in overload of some nodes, unstable verification time, and large fluctuations. A larger branching factor has a more balanced task distribution, and the computing tasks of each verification node are more concentrated, resulting in less and more stable verification time. For situations that require stable and faster verification time, it is recommended to choose a larger branching factor (such as When computing resources are limited or high parallelism is required, a smaller branching factor can be selected, but attention should be paid to possible time fluctuations and unbalanced task distribution. The special points in the first half show that in practical applications, it is very important to choose a reasonable branching factor. Too small a branching factor may lead to unbalanced computing tasks, thus affecting the overall verification efficiency.

[0146] Figure 6 It shows that memory usage gradually decreases and stabilizes as the batch size increases. When the batch size increases, more data blocks are merged and aggregated, which reduces the storage requirements for intermediate states and temporary data. At the same time, the larger the branching factor, the higher the memory usage. The branching factor represents the number of child nodes for each node. A higher branching factor will increase the complexity of the Merkle tree structure, resulting in significant memory consumption, which may put pressure on systems with limited memory resources.

[0147] Figure 7 It shows that the time consumption gradually decreases and tends to be stable as the batch size increases. As the batch size increases, the amount of data processed each time increases, the efficiency of single processing improves, and the calculation process of branching factors with different values ​​becomes more efficient, so the time consumption decreases rapidly. At the same time, the larger the branching factor, the longer the processing time. This is because with a smaller branching factor, the computational complexity of each node is lower, so the time consumption is smaller, while with the increase of the branching factor, the computational complexity of each node increases, resulting in an increase in time consumption.

[0148] Figure 8 It shows that as the batch size increases, the number of CPU context switches generally shows a downward trend. When the batch size is small, it means that the amount of data processed each time is small. Frequent task switching increases the CPU load, resulting in an increase in the number of CPU context switches. After the batch size exceeds a certain threshold (such as 500), the number of CPU context switches tends to stabilize, and further increasing the batch size has a smaller effect on reducing the number of CPU context switches. At the same time, a larger branching factor (such as a branching factor of 40) means that each node has more child nodes, thereby increasing the number of nodes that need to be traversed for each operation, resulting in more context switches. A smaller branching factor (such as a branching factor of 10) may traverse deeper levels to obtain the required information when traversing the tree, but because there are fewer choices at each level, the number of context switches will be reduced.

[0149] Fig. 9It shows that as the batch size increases, the number of disk I / Os generally shows a downward trend. When the batch size is small, it means that the amount of data processed each time is small. A small batch size will cause frequent I / O operations, resulting in an increase in disk load. After the batch size exceeds a certain threshold, the number of disk I / Os tends to stabilize, and further increasing the batch size has little effect on reducing disk I / O. At the same time, the branching factor affects the efficiency of Merkle tree construction and verification. A larger branching factor increases the number of child nodes under each node, resulting in an increase in the number of I / Os.

[0150] From the experimental data, when the batch size is too large, the CPU occupancy rate fluctuates greatly, which may lead to unstable system performance. Setting the branch factor too small will also increase the CPU occupancy rate and affect the system performance. Therefore, under the combination of a smaller batch size and a larger branch factor, the CPU occupancy rate is low and the change is relatively stable, and the system performance is relatively superior. At the same time, increasing the batch size can significantly reduce memory usage, time consumption, CPU context switching times, and disk I / O times, but beyond a certain threshold, further increasing the batch size has little effect on optimizing system resource consumption. In addition, setting a branch factor that is too high will also increase memory usage, time consumption, CPU context switching times, and disk I / O times. Therefore, considering a variety of indicators, the parameter batch size is set to 500 and the branch factor is set to 30.

[0151] Compare the operating costs and efficiency of the cross-chain transaction solution based on aggregated zero-knowledge proof and the traditional zero-knowledge proof model in the cross-chain scenario; the experiment uses the traditional zero-knowledge proof model as a benchmark for comparison:

[0152] Fig.10 , 11 , 12 show the comparison of CPU usage, memory usage, time consumption, CPU context switching times, disk I / O read times, and zero-knowledge proof size of the two models when generating and verifying aggregated zero-knowledge proofs for 1000 cross-chain blocks, where the batch size and branching factor are set to 500 and 30 respectively.

[0153] Fig.10 (a) This scheme distributes the computing tasks to multiple nodes by adopting multi-branch balanced Merkle tree and secure multi-party computation, significantly reducing the CPU load of a single node. The CPU usage of generating and verifying aggregated zero-knowledge proofs is reduced by 50.09% and 45.10% respectively compared with the baseline. Figure 10 (b) shows that this scheme reduces the memory usage of global data by constructing a local Merkle tree, which is reduced by 99.03% and 98.73% respectively compared with the baseline.

[0154] Fig.11 (c) shows that this scheme significantly improves computational efficiency and reduces verification time by optimizing branching factor and secure multi-party computation, which are 99.47% and 81.29% lower than the baseline, respectively. Fig.11 (d) shows that this scheme reduces unnecessary task switching and improves system stability through reasonable task allocation. The number of CPU context switches is reduced by 97.81% and 60% compared with the baseline.

[0155] Fig.12 (e) shows that this solution reduces disk I / O operations by optimizing data storage and reading. The number of disk I / O reads is reduced by 99.18% and 14.73% compared with the baseline. Fig.12 (f) shows that this scheme effectively reduces the size of the proof by aggregating zero-knowledge proofs in the form of a multi-branch balanced Merkle tree. The size of the zero-knowledge proof generated for 1000 cross-chain blocks is reduced by 99.99% compared to the baseline.

[0156] Overall, this solution performs well in six aspects: CPU occupancy, memory usage, time, number of CPU context switches, number of disk I / O reads, and size of zero-knowledge proofs. It is more suitable for environments with limited resources and high efficiency requirements.

[0157] In order to evaluate the deployment and operation costs of this solution, we implemented it on Ethereum's testnet Sepolia. Gas quantifies the deployment and operation costs of smart contract functions. This article is priced in US dollars ($), and the exchange rate used is: 1 Gas = 0. 0.00000013640 USD, 1 Gas = 0.042745066 Gwei, 1 Gwei = 0.000000001 ETH, 1ETH = 3191.01 USD.

[0158] Table 1 shows the Gas value consumed by each operation

[0159] Operation Gas USD Deploy 2317686 0.316 Aggregate 481795 0.066 Deposit 21988 0.003 Validation 323542 0.044 Withdraw 21644 0.003

[0160] As shown in Table 1, the deployment cost of the smart contract in this scheme is about $0.316. Among them, the cost of the Aggregate operation is about $0.066, which is mainly used to generate aggregated zero-knowledge proofs for cross-chain transactions on the source blockchain. The Deposit operation has a low Gas consumption, with a cost of about $0.003, which represents the cost of depositing assets into the cross-chain system. The cost of the Validation operation is about $0.044, which mainly involves the process of verifying the zero-knowledge proof on the target chain. Finally, the cost of the Withdraw operation is about $0.003, reflecting the related expenses when users withdraw assets from the system.

[0161] We compared the experimental results with the multi-signature scheme, the notary committee scheme, and the mainstream zero-knowledge proof cross-chain schemes ZkRollup and Validium, as shown in Table 2:

[0162] Table 2 Comparison of Gas Costs of Cross-Chain Solutions

[0163]

[0164] Table 2 clearly shows that our proposed scheme achieves lower gas consumption in both deployment cost and total cost than traditional multi-signature schemes and notary committee schemes on the basis of improving the performance of the original zero-knowledge proof. Although the gas cost on the target chain is slightly higher than that of the multi-signature scheme and the notary committee scheme, our scheme reduces the complex transaction verification on the source chain by aggregating zero-knowledge proof technology, thereby offsetting the higher gas consumption on the target chain, making the total cost (source chain + target chain) still lower than that of the multi-signature scheme and the notary committee scheme. This is because the source chain usually bears more transaction data and computing tasks, so the optimization on the source chain has a more significant reduction in overall gas consumption. Compared with Zk-Rollup and Validium, this scheme has a lower deployment cost than Zk-Rollup, and the source chain cost reduction is more significant. Although the cost of the target chain is slightly higher, overall, the total cost of this scheme is still lower than that of Zk-Rollup, showing a clear advantage. Compared with Validium, this scheme performs better in deployment cost, but the cost on the source chain and target chain is relatively high, resulting in an overall cost higher than Validium. However, while Validium demonstrates cost optimization on certain chains, its security is not sufficient to meet the needs of high-risk scenarios.

[0165] In the notary committee scheme, Ethereum smart contracts are used to manage cross-chain transactions, which involves the selection of multiple validators, transaction verification, and the formation of committees. In order to ensure the security and reliability of transactions, this approach requires the execution of complex on-chain transaction verification processes and various consensus algorithms, which significantly increases gas consumption. The multi-signature scheme relies on smart contracts and multi-signature mechanisms to implement cross-chain transactions. Although multi-signatures can improve the security of the system and the ability to handle high-concurrency transactions, the complexity of signature verification and contract calls leads to higher gas consumption. In addition, the system needs to handle multiple transaction operations (such as token generation, withdrawal, etc.), which will increase additional gas consumption.

[0166] The Zk-Rollup solution ensures a high level of security and transparency by batching multiple on-chain transactions and integrating them into a zero-knowledge proof. However, this mechanism concentrates the legitimacy verification and status update process of all transactions on the main chain, resulting in high gas consumption on the source chain. In contrast, the Validium solution verifies transactions and issuances through an off-chain data committee, reducing the repeated verification of transaction legitimacy on the chain, thereby significantly reducing the gas cost on the source and target chains. However, Validium has increased deployment costs and also faces some challenges: its multi-signature mechanism relies on the honesty of the data committee members. If some members are dishonest, legitimate transactions may be rejected or malicious transactions may be approved. In addition, the lack of transparency in off-chain operations increases the difficulty of external audits. Once some nodes behave improperly, the security of the entire transaction batch may be compromised. The transparency of the decision-making process and the potential for coordinated attacks are also key points that need to be paid attention to. These factors together constitute the security challenges of Validium.

[0167] In contrast, this solution combines the advantages of both on-chain and off-chain by aggregating zero-knowledge proof technology to merge the proofs of multiple cross-chain transactions into a single proof. On the chain, it is only necessary to reconstruct the global cross-chain multi-branch balanced Merkle tree based on the root of the local cross-chain multi-branch balanced Merkle tree submitted by each verification node to verify the legitimacy of all transactions. This method significantly reduces the amount of transaction data and computing load, not only optimizing the on-chain data storage and computing efficiency, but also effectively reducing the cost and time of cross-chain transaction verification. Compared with other solutions, this solution significantly reduces Gas consumption during deployment, showing obvious advantages. In source chain operations, this solution reduces Gas consumption by about 31.41% compared to the multi-signature scheme, by about 18.30% compared to the notary committee scheme, and by about 13.76% compared to the Zk-Rollup scheme. Although various schemes have their own advantages and disadvantages in target chain operations, this scheme performs well in terms of total cost and is still the best choice except for Validium. Although Validium shows cost optimization in some aspects, its security is not enough to meet the needs of high-risk scenarios.

[0168] The above description is only an embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent substitution, improvement, etc. made within the spirit and principle of the present invention should be included in the scope of the claims of the present invention.

Claims

1. A cross-chain transaction method based on aggregated zero-knowledge proof, characterized by: The method comprises the following steps: Step S1: Build a large-scale cross-chain transaction system, optimize the batch size and branching factor based on the adaptive adjustment method of system load; The large-scale cross-chain transaction system includes a blockchain network, a smart contract, a peer node, a packaging node, a verification node, a relay network, and a gateway node; Step S1-1: Assume that the system load matrix is , the corresponding weight matrix is ; The packaging node continuously monitors the real-time load of the cross-chain network and the cross-chain demand on the source blockchain A, and records the load matrix of each large-scale cross-chain transaction system. , and its maximum value , minimum and the average ; Step S1-2: When the packaging node receives an aggregation request from a cross-chain contract, it normalizes the current large-scale cross-chain transaction system load to obtain and , calculate the current optimal batch size ; After Min-Max normalization, we get: ； ； in, is the normalized load matrix; is the normalized mean value; The batch size is adjusted dynamically by the following formula: ； ； ； in, is the overall load factor, is the target load factor, is the adjustment coefficient, which is used to control the speed of adjustment; is the system load matrix The corresponding weight matrix is, is the batch size recalculated based on current system resources, The batch size for current system resources; Step S1-3: Packing nodes calculate the batch size , adjust the branching factor The total cost The smallest, that is, the optimal branching factor ; Optimal branching factor The specific acquisition method is as follows: Assume that the size of the tree is the total number of nodes, that is ;in, is the branching factor; The communication cost is proportional to the size of the tree, so the communication cost ; in, is a constant related to communication; Optimal branching factor ; ； in, and is the weight factor of communication overhead and computational overhead in the total overhead, is a constant related to communication, and are the computational overhead required for an addition operation and a hash operation, respectively. The total number of verification nodes participating in the aggregate integrity verification; Step S2: Adopt a cross-chain block aggregation method based on a multi-branch balanced Merkle tree to increase the node branching factor and improve query and verification efficiency; Step S3: Use the local multi-branch Merkle tree rebalancing method to quickly identify and synchronize the differences between the local and global cross-chain multi-branch balanced Merkle trees to ensure that the branches and tree heights of each local tree are balanced; Step S4: Introduce a secure multi-party computing method based on secret sharing to verify the data integrity of the aggregated block; Introduce a secure multi-party computing method based on secret sharing to select the appropriate sharding method for packaging nodes, and share the cross-chain block sharding secrets to Verification nodes, among which, , No. The number of cross-chain blocks owned by a verification node is recorded as , the specific operations are: Step S4-1: The packaging node searches for the closest average shard, and the shard size is of value, ensuring that each verification node can obtain a reasonable amount of computing tasks; Step S4-2: Based on the obtained fragment size Calculate target tree height ; Step S4-3: Based on the calculated shard size , the packaging node will verify the cross-chain block Shard the data and obtain the cross-chain blocks after sharding ; Step S4-4: The fragmented data Randomly distributed to each verification node through secret sharing; The packaging node will verify the cross-chain block Data sharding is performed by using the following formula: ； in, is the number of validating nodes; It is The cross-chain block array assigned to the verification nodes, Is the best for sharding value.

2. A cross-chain transaction method based on aggregated zero-knowledge proof according to claim 1, characterized in that: The blockchain network is responsible for maintaining transaction ledgers and executing smart contracts. The blockchain network includes a source blockchain A for initiating cross-chain transactions and a target blockchain B for executing cross-chain transactions. Smart contracts are responsible for managing cross-chain transaction logic and rules. Smart contracts receive, process and record cross-chain transaction information on the blockchain network and broadcast transactions to all nodes in the network. Peer nodes are responsible for verifying and processing cross-chain transactions, packaging legal cross-chain transactions to generate new cross-chain blocks, and broadcasting them to other peer nodes in the network to reach consensus; The packaging node is responsible for performing the cross-chain block aggregation operation, randomly grouping the cross-chain blocks, and aggregating the cross-chain blocks of each group in the form of a multi-branch balanced Merkle tree to generate an aggregated Merkle root; The verification node is responsible for generating zero-knowledge proofs for aggregated batch cross-chain blocks. The verification node verifies the integrity of batch cross-chain blocks through secure multi-party computation and generates aggregate zero-knowledge proofs for legal aggregate Merkle roots. The relay network is responsible for transmitting information and proofs between different blockchain networks; The gateway node is responsible for connecting the relay network and various blockchain networks, and transmitting the generated aggregated zero-knowledge proof to the target blockchain.

3. A cross-chain transaction method based on aggregated zero-knowledge proof according to claim 2, characterized in that: The blockchain network adopts a heterogeneous blockchain network, which means that the structures and underlying mechanisms of the blockchains are different; The source blockchain and the target blockchain are both heterogeneous blockchain networks.

4. A cross-chain transaction method based on aggregated zero-knowledge proof according to claim 1, characterized in that: The cross-chain block aggregation method of the multi-branch balanced Merkle tree in step S2 is to aggregate the cross-chain blocks submitted to the packaging node in the form of a multi-branch balanced Merkle tree to obtain an aggregated Merkle root The specific operations are: Step S2-1: Randomly group each cross-chain block submitted to the packaging node, and the number of cross-chain blocks in each group is the calculated batch size; each cross-chain block is used as a leaf node; Step S2-2: According to the timestamp order in the block header, the packaging node organizes it into branches with a factor of Merkle tree, thereby constructing a global cross-chain multi-branch balanced Merkle tree and obtaining the aggregated Merkle root .

5. A cross-chain transaction method based on aggregated zero-knowledge proof according to claim 1, characterized in that: The rebalancing method of the local multi-branch Merkle tree in step S3 is that each verification node rebalances the local cross-chain multi-branch Merkle tree after receiving its own cross-chain block. The specific operation is: Step S3-1: Assume that The verification nodes are , the number of cross-chain blocks it owns is , ; Determine the current verification node The number of cross-chain blocks owned Can it be If the condition is not divisible, copy the last cross-chain block until it meets the condition; Step S3-2: Calculate the height of the local multi-branch Merkle tree constructed by the current verification node , and with the target tree height Compare; if they are consistent, then end; if they are inconsistent, continue to execute step S3-3; Step S3-3: If the current verification node The number of cross-chain blocks owned , then recursively copy all cross-chain blocks owned by the current verification node until the number of cross-chain blocks is ; If the current verification node The number of cross-chain blocks owned , then copy the cross-chain block of the previous subtree at the same level until the number of cross-chain blocks is , and then recursively copy all cross-chain blocks owned by the current verification node until the number of cross-chain blocks is ; Step S3-4: The verification node uses all the cross-chain blocks it currently owns to build a local cross-chain multi-branch balanced Merkle tree and return the local aggregated Merkle root .

Images