Self-random cross-chain dynamic cooperative supervision method based on zero knowledge proof

Abstract

The invention discloses a self-random cross-chain dynamic cooperative supervision method based on zero knowledge proof, which is used for realizing safe and supervisible privacy protection transactions in a block chain cross-chain environment. The method comprises the following steps: dynamically screening users through MACRO credit scores to form supervision chains, the number of which is consistent with that of application chains, and generating public and private keys; deploying a contract and a ZKP circuit in each chain, wherein ZKP generation adopts self-random hash; according to the supervision chain secret key and the self-random hash, the transaction is encrypted, verified and signed, and a random block header and a transaction link are recorded in a linker (TEE); after the supervision chain verifies the signature, the transaction is linked and stored in a supervision chain Merkel mountain range, and a linker is updated at the same time; a supervision chain of any party puts forward a supervision application, and after the supervision application is agreed by the opposite party, two rounds of two-layer secret sharing technology collaboratively supervise the recoverable transaction. According to the method, self-random encryption, zero-knowledge proof and dynamic supervision mechanisms are fused, and multi-key supervision, self-random encryption key dynamic change and multi-supervision-chain dynamic cooperative supervision are realized.

Description

Technical Field

[0001] The present invention relates to the field of information security technology, and specifically to a self-random cross-chain dynamic collaborative supervision method based on zero-knowledge proof. Background Art

[0002] With the rapid development of cross-chain technology, data interoperability and asset transfers within multi-chain ecosystems are becoming increasingly frequent. However, existing cross-chain systems often rely on single keys or centralized auditing, which poses single points of failure and makes it difficult to maintain data privacy. Traditional cross-chain regulatory models also face challenges such as insufficient privacy protection, regulatory lags, cross-chain heterogeneity, and the inability of static regulatory architectures to adapt to dynamic and changing cross-chain scenarios. This paper proposes a self-randomized cross-chain dynamic collaborative regulatory framework based on zero-knowledge proofs, aiming to achieve a balance between privacy and compliance, and enhance the controllability and transparency of the cross-chain ecosystem.

[0003] As the multi-chain ecosystem expands, "value silos" are forming between blockchain platforms, making cross-domain information sharing and coordinated oversight difficult. Traditional centralized cross-chain solutions rely on trusted third parties, which pose a single point of failure risk (e.g., the Ronin Network lost hundreds of millions of dollars due to attacks on centralized verification nodes). Cross-chain technologies based on hash locking or notary models struggle to meet the privacy and dynamic oversight requirements of complex business scenarios.

[0004] At the same time, there's a conflict between cross-chain privacy protection and regulatory transparency. Blockchain transparency makes sensitive data (such as transaction amounts and user addresses) vulnerable to leakage. Innovations in zero-knowledge proof technology have advanced cross-chain privacy regulation. Zero-knowledge commitments offer privacy-enhancing properties. Zero-knowledge proofs (ZKPs) transform private data into verifiable mathematical statements (such as Pedersen commitments), enabling cross-chain transaction verification without leaking the original information. However, the single-key system of traditional zero-knowledge proof technology struggles to support multi-party regulatory scenarios. For example, cross-chain sharing of medical data requires both privacy (hiding patient information) and verifiability (proving diagnostic compliance).

[0005] Furthermore, static regulatory architectures cannot adapt to the dynamic and ever-changing nature of cross-chain scenarios. A dynamic regulatory framework can combine smart contracts and multi-key commitments to create a programmable regulatory rules engine. For example, cross-chain governance credit evaluation systems (such as Tencent's CCGP credit model) dynamically adjust key permission thresholds to enable real-time interception and tracing of abnormal transactions. Currently, Tencent's CCGP cross-chain platform, through a "governance chain + sub-chain proxy" architecture, supports dynamic key allocation and audit traceability for multi-party co-governance. However, it lacks privacy protection, its governance chain suffers from performance bottlenecks, and the system is overly complex and lacks ecological compatibility. Summary of the Invention

[0006] (1) Technical problems solved

[0007] The purpose of this invention is to provide a self-randomized cross-chain dynamic collaborative supervision method based on zero-knowledge proof, integrating self-randomized encryption, zero-knowledge proof, and dynamic supervision mechanisms. It can achieve multi-key supervision, dynamic changes in self-randomized encryption keys, and dynamic collaborative supervision of multiple supervision chains.

[0008] Existing solutions use a static blinding factor generation mechanism, reusing the same random parameters across consecutive transactions. This allows attackers to infer user identities based on correlations between ciphertext patterns. This invention introduces a random blinding factor. Traditional solutions, such as Monero's RingCT protocol, use an elliptic curve-based random number generator, which is time-consuming and CPU-intensive to generate. This invention leverages the inherent randomness of the block header hash to generate the random blinding factor, simplifying computational overhead. By selecting a different blinding factor each time, the risk of privacy leaks can be reduced.

[0009] The existing solution uses static supervision chain mapping, which leads to the occurrence of unauthorized access events. In the present invention, the supervision chain will be dynamically re-selected after m transactions, realizing a dynamic, flexible and secure supervision model. Through the one-to-one correspondence between the supervision chain and the application chain, the corresponding permissions can be clearly managed.

[0010] In response to current privacy supervision schemes, such as the lack of checks and balances in the master-slave supervision node design, there is a problem of supervisor betrayal, which leads to the leakage of private data. The present invention encrypts the blinding factor and the public key together, and combines it with a secret sharing scheme (threshold signature, two-round two-layer secret sharing), which can prevent a single supervisor from obtaining the user's private data. Even if a supervisor in the supervision chain betrays, only one fragment of a part of the key can be obtained, and the user's private content cannot be restored. The cooperation of the supervision chains of both parties is required to restore the private information. At the same time, the supervision chain can only obtain the key fragment if it has permission. The two-round two-layer secret sharing technology can also prevent the recipient from maliciously claiming that it has not received the fragment to obtain more secret information.

[0011] (2) Technical solution

[0012] To achieve the above objectives, the present invention provides the following technical solution: a self-random cross-chain dynamic collaborative supervision method based on zero-knowledge proof, comprising the following steps:

[0013] Step 1: Public supervision public key: After every m transactions, the application chain C participating in the cross-chain A 、C B In the process, the MACRO credit score smart contract automatically screens qualified on-chain users to form a new custody chain SC A , SC BThe number is consistent with the number of application chains participating in the cross-chain. The threshold signature technology is used to generate the public and private keys of the supervision chain, and the public key pk of the supervision chain is made public. A 、pk B ;

[0014] Step 2: Deploy the contract and complete the ZKP circuit: Deploy the required smart contract on-chain and complete the corresponding ZKP circuit. Self-random hashing is used in ZKP generation.

[0015] Step 3, transaction generation and signature: based on the public key pk of the transaction's supervision chain A 、pk B , the negotiated random block header hash H A 、H B , encrypt and sign the transaction information, the transaction recipient's custody chain signs the address, and the transaction initiator's custody chain verifies the validity of the transaction through the received non-interactive zero-knowledge proof and signature, and signs the transaction, while recording the random block number and the link to the transaction information on the linker (TEE);

[0016] Step 4: Verification and on-chaining of transactions: Transaction recipient custody chain (SC) B Verify the signature. If verify(Tx S ,pk A )=1, the transaction Tx is put on the chain, the transaction information is stored in the Merkle Mountains of each custody chain, and the link is updated on the linker (TEE);

[0017] Step 5, request supervision: If the linker finds that the transaction is abnormal, such as an anonymous user has made too many transactions or the transaction amount is excessive in a short period of time, the transaction parties will supervise the chain SC. A , SC B Each party can apply for supervision to the other party's supervision chain. After the other party's supervision chain agrees, the two parties can realize collaborative supervision, find the linker, and share the previously negotiated block header hash H through two rounds of two-layer secret sharing technology (in order to prevent the receiver of a shard from falsely claiming that it has not received the shard, which will cause the receiver to obtain more secret information when the shard is re-segmented and sent). A H B , through the key and block header hash H A H B Restore the transaction information before encryption.

[0018] In step 1, after every m transactions, the application chain C participating in the cross-chain A 、C B In the process, the MACRO credit score smart contract automatically screens qualified on-chain users to form a new custody chain SCA , SC B The number is consistent with the number of application chains participating in the cross-chain. The threshold signature technology is used to generate the public and private keys of the supervision chain, and the public key pk of the supervision chain is made public. A 、pk B The public key of the custody chain is used for subsequent encryption and signature verification of transactions.

[0019] The specific steps of step 2 are as follows:

[0020] Step 2.1: Deploy the corresponding smart contracts on the source and target chains to handle asset locking, unlocking, and transaction verification logic, and complete the ZKP circuit to generate non-interactive zero-knowledge proofs. Self-random hashing is used in ZKP generation.

[0021] In step 2.2, the custody chain needs to deploy a verification contract to verify the validity of the transaction by verifying the zero-knowledge proof and signature to ensure the legality of the cross-chain transaction;

[0022] In step 2.3, the off-chain linker needs to deploy a smart contract, store the random block number and transaction information link, and interact with the on-chain verification logic through the smart contract. Deploy the privacy smart contract in the trusted execution environment.

[0023] In step 3, the specific steps are as follows:

[0024] Step 3.1, according to the public key pk of the custody chain A 、pk B , the negotiated random block header hash H A 、H B , encrypt and sign the transaction information, specifically first add the transaction recipient address B Encrypt, add' B =addGen(add B ,H B ), transaction receiver custody chain SC B Add' to the address B Add signature BS =Sign(add' B ,sk B ).

[0025] Step 3.2, transaction initiator A1 receives add B 'First verify whether the address signature of the recipient B1 is legal. If verify(add BS ,pk B )=1, then generate transaction Tx=TxGen(add A ,add' B ,num,pk B ,HA ) and the corresponding zero-knowledge proof π=Prove(CRS,Tx,Nullifier,rt,sk A ,num,H A CRS is a public reference string containing a proof key (PK) and a verification key (VK); Nullifier is an anti-double-spending flag; rt is the current Merkle tree root; and the output π is the generated zero-knowledge proof in the form of a combination of elliptic curve points.

[0026] Step 3.3, SC A The transaction's validity is verified using the received non-interactive zero-knowledge proof and signature. Verify(vk,π,cm,Nullifier,rt) = 1 if and only if e([A],[B])·e([C],G) = e([H],[Z]), where "e([A],[B])" represents a bilinear pairing operation. Verification involves verifying that A(s)·B(s)-C(s) = H(s)·Z(s), where "·" represents the encrypted form of the polynomial on the elliptic curve (e.g., implemented through homomorphic encryption or bilinear pairing), and [A][B][C][H] represents the encrypted form of the polynomial commitment (elliptic curve point). This equation, derived from a constraint system (R1CS), ensures the correctness of the transaction logic. The verifier verifies the validity of the proof by checking the polynomial's equality through bilinear pairing without knowing any secret parameters.

[0027] Step 3.4, after successful verification, SC A Sign the transaction Tx S =Sign(Tx,sk A ), and record the link of the random block number n and transaction information Tx on the linker;

[0028] In step 4, SC B Verify the signature. If verify(Tx S ,pk A )=1, the transaction Tx is put on the chain, the transaction information is stored in the Merkle Mountains of each supervision chain, and the link is updated on the linker (TEE), and the transfer operation is automatically completed by the smart contract.

[0029] In the step 5.

[0030] Step 5.1, Chain of Custody (SC) B Through the transaction information counted by the linker in steps 3 and 4, if abnormal transactions are found (such as T min Number of transactions within time T n >MAX), can be reported to the chain of custody SC A Request supervision and send the signature S of the abnormal transaction B .

[0031] Step 5.2, SC A After receiving the supervision request, if verify(S B ,pk B )=1, agree to conduct supervision operation, then find the linker to hash the block header H used for encrypted transaction in step 3 A Sent to SC through two rounds of layer-2 secret sharing technology B .

[0032] Step 5.3, SC B After receiving the block header hash, restore the add from Tx A , and send it to SC at the same time A , on the contrary SC A You can also ask SC B Initiate a regulatory request.

[0033] (3) Beneficial effects

[0034] Compared with the prior art, the present invention has the following beneficial effects:

[0035] This invention proposes a self-randomized cross-chain dynamic collaborative supervision method based on zero-knowledge proof, integrating self-randomized encryption, zero-knowledge proof, and dynamic supervision mechanisms. It can achieve multi-key supervision, dynamic changes in self-randomized encryption keys, and dynamic collaborative supervision across multiple supervision chains.

[0036] Existing solutions use a static blinding factor generation mechanism, reusing the same random parameters across consecutive transactions. This allows attackers to infer user identities based on correlations between ciphertext patterns. This invention introduces a random blinding factor. Traditional solutions, such as Monero's RingCT protocol, use an elliptic curve-based random number generator, which is time-consuming and CPU-intensive to generate. This invention leverages the inherent randomness of the block header hash to generate the random blinding factor, simplifying computational overhead. By selecting a different blinding factor each time, the risk of privacy leaks can be reduced.

[0037] The existing solution uses static supervision chain mapping, which leads to the occurrence of unauthorized access events. In the present invention, the supervision chain will be dynamically re-selected after m transactions, realizing a dynamic, flexible and secure supervision model. Through the one-to-one correspondence between the supervision chain and the application chain, the corresponding permissions can be clearly managed.

[0038] In response to current privacy supervision schemes, such as the lack of checks and balances in the master-slave supervision node design, there is a problem of supervisor betrayal, which leads to the leakage of private data. The present invention encrypts the blinding factor and the public key together, and combines it with a secret sharing scheme (threshold signature, two-round two-layer secret sharing), which can prevent a single supervisor from obtaining the user's private data. Even if a supervisor in the supervision chain betrays, only one fragment of a part of the key can be obtained, and the user's private content cannot be restored. The cooperation of the supervision chains of both parties is required to restore the private information. At the same time, the supervision chain can only obtain the key fragment if it has permission. The two-round two-layer secret sharing technology can also prevent the recipient from maliciously claiming that it has not received the fragment to obtain more secret information. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 This is a summary flow chart of the present invention's self-randomized cross-chain dynamic collaborative supervision method based on zero-knowledge proof;

[0040] Figure 2 This is the architecture diagram of the self-random cross-chain dynamic collaborative supervision based on zero-knowledge proof of the present invention.

[0041] Figure 3 This is a transaction flow chart of the present invention's self-random cross-chain dynamic collaborative supervision based on zero-knowledge proof.

[0042] Figure 4 This is a regulatory flow chart of the present invention's self-random cross-chain dynamic collaborative supervision based on zero-knowledge proof.

[0043] Figure 5 This is a trusted setup phase diagram of the zero-knowledge proof circuit generation process based on zero-knowledge proof self-random cross-chain dynamic collaborative supervision of the present invention.

[0044] Figure 6 It is an MDS scatter plot of transaction data generated by the same transaction parties under the self-random cross-chain dynamic collaborative supervision based on zero-knowledge proof of the present invention.

[0045] Figure 7 It is an edit distance similarity data graph of transaction data generated by the same transaction parties under self-random cross-chain dynamic collaborative supervision based on zero-knowledge proof of the present invention. DETAILED DESCRIPTION

[0046] The following will clearly and completely describe the technical solutions of the present invention in the embodiments of the present invention in conjunction with the drawings of the present invention in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0047] Example

[0048] The present invention provides a self-random cross-chain dynamic collaborative supervision method based on zero-knowledge proof, such as Figure 2 As shown, please follow the steps below:

[0049] In step 1, a supervision chain is formed: after every m transactions, in the application chains participating in the cross-chain, the MACRO credit score smart contract automatically screens qualified chain users to form a new supervision chain. The number is consistent with the number of application chains participating in the cross-chain. The threshold signature technology is used to generate the supervision chain public and private keys, and the public key pk of the supervision chain is made public. Taking two chains as an example, C A is the source chain, C B For the target chain, SC A C A Chain of custody, SC B C B The custody chain, public key pk A 、pk B .

[0050] Step 2 is as follows:

[0051] Step 2.1: Deploy the corresponding smart contracts on the source and target chains to handle asset locking, unlocking, and transaction verification logic, and complete the ZKP circuit to generate non-interactive zero-knowledge proofs. Self-random hashing is used in ZKP generation. Figure 5 This diagram shows the trusted setup phase of the zero-knowledge proof circuit generation process. The framed portion is a cryptographic random beacon, showing the self-random block header hash. Its function is to ensure that the final parameter generation cannot be pre-calculated or manipulated through a public and uncontrollable random source.

[0052] In step 2.2, the custody chain needs to deploy a verification contract to verify the validity of the transaction by verifying the zero-knowledge proof and signature to ensure the legality of the cross-chain transaction;

[0053] In step 2.3, the off-chain linker needs to deploy a smart contract, store the random block number and transaction information link, and interact with the on-chain verification logic through the smart contract. Deploy the privacy smart contract in the trusted execution environment.

[0054] The details of step 3 are as follows. The specific transaction process is as follows Figure 3 As shown:

[0055] Step 3.1: The transaction described in this article is based on the example of transferring the amount num from chain A to chain B. The corresponding custody chains of the two parties to the transaction first negotiate a common, random block number n, where n = Random (nonce <Max(A num ,B num)-6), and calculate the block header hash H of the block number on the corresponding application chain A H B , H A =getABlockH(n),H B =getBBlockH(n), sent to the transaction parties on the corresponding application chain respectively;

[0056] Step 3.2, according to the public key pk of the custody chain A 、pk B , the negotiated random block header hash H A 、H B , encrypt and sign the transaction information, specifically first add the transaction recipient address B Encrypt, add' B =addGen(add B ,H B ), transaction receiver custody chain SC B Add' to the address B Add signature BS =Sign(add' B ,sk B ).

[0057] Step 3.3, transaction initiator A1 receives add B 'First verify whether the address signature of the recipient B1 is legal. If verify(add BS ,pk B )=1, then generate transaction Tx=TxGen(add A ,add' B ,num,pk B ,H A ) and the corresponding zero-knowledge proof π=Prove(CRS,Tx,Nullifier,rt,sk A ,num,H A CRS is a public reference string containing a proof key (PK) and a verification key (VK); Nullifier is an anti-double-spending flag; rt is the current Merkle tree root; and the output π is the generated zero-knowledge proof in the form of a combination of elliptic curve points. Figure 6 The MDS scatter plot of transaction data of 20 privacy-preserving transactions generated for the same transaction party is the projection coordinate after high-dimensional similarity data is compressed into a two-dimensional plane using the multidimensional scaling (MDS) algorithm. Their main function is to reflect the similarity relationship between samples through relative position. Figure 6The presentation of the MDS scatter plot of transaction data generated by the same transaction party shows that the overall similarity between these 20 samples is low. This shows that the privacy-preserving transaction data generated by the same transaction party has a low correlation. The edit distance (Levenshtein Distance) is then used to quantitatively calculate the average similarity and maximum similarity between transaction data strings. The edit distance measures the degree of difference between two strings, that is, how many single-character edits (insertion, deletion, substitution) are required to transform one string into another. The larger the value, the greater the difference. Convert the edit distance to similarity. The similarity calculation formula is: st are two strings, d(s,t) is the edit distance, max(s,t) is the maximum possible distance. If the strings are of equal length (length L), the maximum distance is L (full replacement operation). If the strings are of unequal length (length m and n respectively), the maximum distance is max(m,n) or m+n (depending on the scenario). For N strings, calculate all After the similarity of the two pairs, the calculation formula of the average structural similarity is: According to data analysis, the specific results are as follows Figure 7 As shown, there are significant differences between the strings. The average character position match rate for all transaction data string pairs is only 16.88%. The two most similar transaction data strings still have 81.04% different characters.

[0058] Step 3.4, Transaction Initiator’s Chain of Custody (SC) A The transaction's validity is verified using the received non-interactive zero-knowledge proof and signature. Verify(vk,π,cm,Nullifier,rt) = 1 if and only if e([A],[B])·e([C],G) = e([H],[Z]), where [A][B][C][H] is the encrypted form of the polynomial commitment (elliptic curve point). Verification involves verifying whether the encrypted polynomial A(s)·B(s)-C(s) = H(s)·Z(s) holds. This equation, derived from a constraint system (R1CS), ensures the correctness of the transaction logic. The verifier verifies the validity of the polynomial through bilinear pairing, confirming the correctness of the proof without knowing any secret parameters.

[0059] Step 3.5, after successful verification, SC A Sign the transaction Tx S =Sign(Tx,sk A ), and record the link of the random block number n and transaction information Tx on the linker;

[0060] In step 4, SC B Verify the signature. If verify(Tx S ,pk A)=1, the transaction Tx is put on the chain, the transaction information is stored in the Merkle Mountains of each supervision chain, and the link is updated on the linker (TEE), and the transfer operation is automatically completed by the smart contract.

[0061] In step 5, the specific supervision process is as follows Figure 4 shown.

[0062] Step 5.1, Chain of Custody (SC) B Through the transaction information counted by the linker in steps 3 and 4, if an abnormal transaction is found (FoundException such as T min Number of transactions within time T n >MAX), can be reported to the chain of custody SC A Request supervision and send the signature S of the abnormal transaction B .

[0063] Step 5.2, SC A After receiving the supervision request, if verify(S B ,pk B )=1, agree to conduct supervision operation, then find the linker to hash the block header H used for encrypted transaction in step 3 A Sent to SC through two rounds of layer-2 secret sharing technology B .

[0064] Step 5.3, SC B After receiving the block header hash, restore the add from Tx A , and send it to SC at the same time A , on the contrary SC A You can also ask SC B Initiate a regulatory request.

[0065] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A self-randomized cross-chain dynamic collaborative supervision method based on zero-knowledge proof, comprising the following steps: Step 1: Public supervision public key: After every m transactions, the MACRO credit score smart contract automatically screens qualified on-chain users to form a new supervision chain. The number of supervision chains is consistent with the number of application chains. Threshold signature technology is used to generate the supervision chain public and private keys, and the supervision chain public key is made public. Step 2: Deploy the contract and complete the ZKP circuit: Deploy the required smart contract on-chain and complete the corresponding ZKP circuit. Self-random hashing is used in ZKP generation. Step 3, transaction generation and signing: Based on the key of the custody chain of both parties and the agreed random block header hash, the transaction information is encrypted, verified and signed, and the link between the random block header and the transaction information is recorded on the linker (TEE); Step 4: Verification and on-chaining of transactions: The transaction recipient’s chain of custody verifies the signature, on-chains the transaction, and updates the link on the linker (TEE); Step 5, Request Supervision: Both the transaction chain can submit a supervision request to the other chain. After the other chain agrees, through two rounds of Layer 2 secret sharing technology, the two parties can achieve collaborative supervision and restore the transaction information before encryption.

2. According to the method of claim 1, a self-random cross-chain dynamic collaborative supervision method based on zero-knowledge proof, in step 1, after every m transactions, in the application chains participating in the cross-chain, the MACRO credit score smart contract automatically screens qualified chain users to form a new supervision chain. The number of supervision chains is consistent with the number of application chains, and a one-to-one correspondence is presented in specific transactions. The threshold signature technology is used to generate the public and private keys of the supervision chain, and the public key of the supervision chain is made public. The public key of the supervision chain is used for subsequent encryption and signature verification of the transaction.

3. According to the method for self-randomized cross-chain dynamic collaborative supervision based on zero-knowledge proof in claim 1, the specific steps of step 2 are as follows: Step 2.1: Deploy the corresponding smart contracts on the source and target chains to handle asset locking, unlocking, and transaction verification logic, and complete the ZKP circuit to generate non-interactive zero-knowledge proofs. Self-random hashing is used in ZKP generation. In step 2.2, the custody chain needs to deploy a verification contract to verify the validity of the transaction by verifying the zero-knowledge proof and signature to ensure the legality of the cross-chain transaction; In step 2.3, the off-chain linker needs to deploy a smart contract, store the random block number and transaction information link, and interact with the on-chain verification logic through the smart contract. Deploy the privacy smart contract in the trusted execution environment.

4. According to the method for self-randomized cross-chain dynamic collaborative supervision based on zero-knowledge proof in claim 1, the specific steps of step 3 are as follows: Step 3.1: The corresponding custody chains of the two parties to the transaction first negotiate a common random block number, and each calculates the block header hash of the block number on the corresponding application chain, and sends it to the two parties on the corresponding application chain; In step 3.2, the transaction recipient's address is encrypted using the block header hash received from the custody chain. After the custody chain verifies that the address is legitimate, it signs the address with the private key and the transaction recipient sends the address to the transaction initiator. In step 3.3, after receiving the private address of the transaction recipient in step 3.2, the transaction initiator encrypts it with its own transaction information using the block header hash sent by the received custody chain and the public key of the custody chain corresponding to the transaction recipient disclosed in step 1; In step 3.4, the transaction initiator generates a zero-knowledge proof and sends it to its own custody chain. After verification, the custody chain signs the transaction and sends it to the transaction initiator. The transaction initiator transmits the transaction across the chain to the transaction recipient chain.

5. According to the method for self-randomized cross-chain dynamic collaborative supervision based on zero-knowledge proof in claim 1, the specific steps of step 4 are as follows: Step 4.1: After the recipient receives the transaction information sent by the transaction initiator in step 3, its custody chain verifies the signature using the public key of the transaction initiator's custody chain disclosed in step 1. In step 4.2, after the transaction recipient's custody chain successfully verifies the signature, the corresponding transaction information is uploaded to the chain. The transaction information is stored in the Merkle Mountains of each custody chain, and the link is updated on the linker (TEE). The transfer operation is automatically completed by the smart contract.

6. According to the method for self-randomized cross-chain dynamic collaborative supervision based on zero-knowledge proof in claim 1, the specific steps of step 5 are as follows: Step 5.1: The transaction receiver's chain of custody uses the transaction information collected by the linker (TEE) in steps 3 and 4. If any abnormal transaction is found, it can request supervision from the transaction initiator's chain of custody and send proof of abnormal transaction discovery. In step 5.2, after the transaction initiator's supervision link receives the supervision request, if the verification proves successful and agrees to the supervision operation, the lookup linker will send the block header hash used to encrypt the transaction in step 3 to the transaction receiver's supervision chain through two rounds of two-layer secret sharing technology; In step 5.3, after receiving the block header hash, the transaction recipient restores the transaction information of the transaction initiator and sends it to the transaction initiator's supervision chain at the same time. Conversely, the transaction initiator's supervision chain can also initiate a supervision request to the transaction recipient's supervision chain.

Images