Cross-chain communication and privacy protection method, system and device based on multi-level architecture and storage medium

Abstract

The invention provides a multi-level architecture-based cross-chain communication and privacy protection method, system and device, and a storage medium, and relates to the technical field of data processing, and the method comprises the steps that an application layer receives a cross-chain asset exchange request initiated by a user through a first block chain network, the request comprises source chain asset information, target chain asset information and a user identity identifier; the application layer executes KYC anti-money laundering verification based on the user identity identifier, and verifies whether a source chain asset address exists in a preset blacklist, so as to obtain a compliance verification passing result; and the protocol layer generates a cross-chain transaction proposal in response to a compliance verification passing result, and constructs a verifiable proof based on a zero-knowledge proof technology. According to the method, the natural contradiction between privacy protection and supervision compliance in a block chain cross-chain scene is solved.

Description

Technical Field

[0001] The present invention relates to the field of cross-chain blockchain communication technology, and in particular to a cross-chain communication and privacy protection method, system, device, and storage medium based on a multi-level architecture. Background Art

[0002] Existing cross-chain communication systems generally face a fundamental conflict between privacy protection and regulatory compliance. On the one hand, traditional solutions lack sensitive data protection mechanisms, resulting in the complete exposure of user transaction amounts and address information during cross-chain transactions. On the other hand, solutions using general-purpose encryption technologies, while enhancing privacy, cannot meet the penetrating audit requirements required by financial regulators. Furthermore, mainstream cross-chain architectures suffer from three major technical flaws: a single-layer processing model leads to the coupling of compliance verification, asset transfer, and privacy control logic, significantly reducing system throughput; the static generation mechanism of zero-knowledge proofs struggles to adapt to inter-chain state latency, often leading to cross-chain failures due to proof invalidation; and regulatory interfaces are crudely designed, either completely blocking audit permissions (violating anti-money laundering regulations) or fully exposing data. These flaws severely restrict the large-scale application of blockchain technology in scenarios such as cross-border payments and compliant DeFi. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a cross-chain communication and privacy protection method, system, device and storage medium based on a multi-level architecture to resolve the natural contradiction between privacy protection and regulatory compliance in cross-chain blockchain scenarios.

[0004] In order to solve the above technical problems, the technical solutions of the present invention are as follows: In the first aspect, a cross-chain communication and privacy protection method based on a multi-level architecture includes: S1: The application layer receives a cross-chain asset exchange request initiated by a user through the first blockchain network. The request includes source chain asset information, target chain asset information, and user identity. S2: The application layer performs KYC anti-money laundering verification based on the user identity and verifies whether the source chain asset address exists in the preset blacklist to obtain a compliance verification result; S3: The protocol layer generates a cross-chain transaction proposal in response to the compliance verification result, and constructs a verifiable proof based on zero-knowledge proof technology; S4: Based on verifiable proof, an asset freeze instruction is sent to the source chain through the cross-chain routing node. The cross-chain routing node uses a relayer and notary collaboration mechanism to monitor the block confirmation events of the source chain in real time. If no on-chain event indicating successful asset freezing is detected within the preset time, the cross-chain process is terminated and a failure notification is returned to the application layer. When the asset is frozen successfully, the validity of the generated ZKP proof on the target chain is verified. If the proof is invalid, the protocol layer is re-triggered to generate an updated ZKP proof. S5: Broadcast the unlock instruction to the target chain based on the valid ZKP proof, triggering the target chain to execute the unlock operation of the corresponding asset; S6: After the target chain unlocking operation is completed, the privacy protection module opens limited audit permissions to the regulatory node, only disclosing the transaction timestamp and compliance status field, while continuing to hide the transaction amount and counterparty address information.

[0005] Furthermore, the application layer receives a cross-chain asset exchange request initiated by the user through the first blockchain network. The request includes source chain asset information, target chain asset information, and user identity, including: S1.1: Capture the original cross-chain asset exchange request data packet through the API interface of the first blockchain network; S1.2: Perform structured parsing on the data packet and extract key fields: source chain asset information, target chain asset information, and user identity.

[0006] Furthermore, the application layer performs KYC anti-money laundering verification based on the user identity and verifies whether the source chain asset address exists in a preset blacklist to obtain a compliance verification result, including: S2.1: Extract the user identity from the generated cross-chain request object and initiate an asynchronous verification request to the KYC certification center to obtain the credential verification result; S2.2: Receive the credential verification result returned by the KYC certification center. If the returned result is invalid, terminate the process and mark the KYC verification as failed; S2.3: Parallel execution of source chain asset address blacklist screening: Call the regulatory contract interface to query whether the source chain asset address exists in the preset blacklist library. If the address hits the blacklist rule, the process is terminated and marked as blacklisted; S2.4: Generate a compliance verification pass result if and only if the KYC verification passes and the blacklist screening is not hit.

[0007] Furthermore, the protocol layer generates a cross-chain transaction proposal in response to the compliance verification result, and constructs a verifiable proof based on zero-knowledge proof technology, including: S3.1: Extract the asset information hash summary and cryptographically signed compliance token based on the generated compliance verification result; S3.2: Generate cross-chain transaction proposal core parameters based on compliant tokens: source chain asset freeze limit, target chain unlock address, and cross-chain transaction unique identifier; S3.3: Call the zero-knowledge proof engine to perform the following operations, input parameters: asset information hash summary plus cross-chain transaction unique identifier, construct a verifiable proof: transaction amount, user original address, compliance token validity signature and target chain ID, and generate a chain-verifiable proof certificate.

[0008] Furthermore, based on verifiable proof, an asset freeze instruction is sent to the source chain through a cross-chain routing node. The cross-chain routing node uses a relayer and notary collaboration mechanism to monitor the block confirmation events of the source chain in real time. If no on-chain event indicating successful asset freezing is detected within a preset time, the cross-chain process is terminated and a failure notification is returned to the application layer. When the asset is successfully frozen, the validity of the generated ZKP proof on the target chain is verified. If the proof is invalid, the protocol layer is re-triggered to generate an updated ZKP proof, including: S4.1: Distribute the encapsulated cross-chain transaction package to the cross-chain routing node, triggering the routing node to perform the following operations: carry the generated frozen amount and transaction unique identifier, and start the relayer-notary collaborative monitoring; S4.2: The notary issues a freeze timeout certificate. The routing node terminates the process and returns a failure notification to the application layer. It extracts the generated ZKP certificate and calls the target chain's ZKP verification contract. The input parameters include: public fields, the source chain block height included in the event, and the notary's confirmation signature of the event. S4.3: When the ZKP verification contract returns Proof_Invalid, the routing node sends a proof invalidation alert to the protocol layer, carrying the current source chain state snapshot. The protocol layer re-triggers step S3.3 to generate an updated ZKP proof.

[0009] Furthermore, based on the valid ZKP proof, the unlocking instruction is broadcast to the target chain, triggering the target chain to execute the unlocking operation of the corresponding assets, including: S5.1: Parse the cross-chain state proof generated by the cloud routing node and extract the following key elements: valid ZKP proof certificate, source chain AssetFrozen event notarization signature, and target chain unlocking address and asset identifier; S5.2: Construct an unlocking instruction executable on the target chain and broadcast it through the notary multi-signature mechanism: the routing node distributes the instruction to the preset notary cluster and adds a multi-signature to the instruction after verification by more than 2 / 3 of the notaries to obtain the execution result of the monitored target chain; S5.3: Based on the feedback of the execution results and exception handling, the corresponding asset unlocking operation is obtained.

[0010] Furthermore, after the target chain unlocking operation is completed, the privacy protection module opens limited audit permissions to the supervisory node, only disclosing the transaction timestamp and compliance status fields, while continuing to hide the transaction amount and counterparty address information, including: S6.1: Based on the cross-chain completion certificate captured by the privacy protection module, the following audit foundation elements are extracted from it: the transaction hash value of the target chain unlocking operation, the compliant timestamp cryptographic evidence, and the set of public fields in the constructed ZKP proof; S6.2: Construct limited audit vouchers based on audit elements: transaction timestamp field, compliance status field, transaction amount field, and counterparty address; S6.3: Open a directional audit channel to the supervisory node: Verify the identity of the requesting node to match the preset supervisory node certificate whitelist, and return structured audit credentials through an encrypted data interface; S6.4: Based on the returned structured audit voucher, implement full-cycle privacy protection: transaction amount query, counterparty identification, isolated storage of sensitive fields, and blockchain public data.

[0011] Secondly, a cross-chain communication and privacy protection system based on a multi-level architecture, including: An acquisition module is configured to receive, at the application layer, a cross-chain asset exchange request initiated by a user through the first blockchain network, the request including source chain asset information, target chain asset information, and a user identity; the application layer performs KYC anti-money laundering verification based on the user identity, and verifies whether the source chain asset address exists in a preset blacklist to obtain a compliance verification pass result; The update module is used by the protocol layer to generate cross-chain transaction proposals in response to compliance verification results, and at the same time construct a verifiable proof based on zero-knowledge proof technology. Based on the verifiable proof, the cross-chain routing node sends an asset freeze instruction to the source chain. The cross-chain routing node uses a relayer and notary collaboration mechanism to monitor the block confirmation events of the source chain in real time. If no on-chain event indicating successful asset freezing is monitored within the preset time, the cross-chain process is terminated and a failure notification is returned to the application layer. When the asset is frozen successfully, the validity of the generated ZKP proof on the target chain is verified. If the proof is invalid, the protocol layer is re-triggered to generate an updated ZKP proof. The processing module is used to broadcast the unlocking instruction to the target chain based on the valid ZKP proof, triggering the target chain to execute the unlocking operation of the corresponding assets; after the unlocking operation of the target chain is completed, the privacy protection module opens limited audit permissions to the supervision node, only discloses the transaction timestamp and compliance status field, while continuing to hide the transaction amount and counterparty address information.

[0012] According to a third aspect, a computing device includes: one or more processors; The storage device is used to store one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors implement the method.

[0013] In a fourth aspect, a computer-readable storage medium stores a program, which implements the method when executed by a processor.

[0014] The above solution of the present invention includes at least the following beneficial effects: By decoupling the application layer compliance verification, protocol layer cross-chain logic and privacy protection modules through a multi-level architecture, efficient collaboration of cross-chain communication processes is achieved. The dynamic zero-knowledge proof mechanism is used to solve the problem of proof invalidation caused by inter-chain state delays. The relayer and notary public collaboration mechanism is used to ensure the reliable execution of asset freezing and unlocking. The limited audit authority design realizes the targeted disclosure of transaction timestamps and compliance status and the continuous hiding of sensitive information such as transaction amounts and addresses. While improving the throughput and success rate of the cross-chain system, it effectively balances the contradiction between privacy protection and regulatory compliance in blockchain cross-chain scenarios, providing a safe and compliant technical solution for scenarios such as cross-border payments and compliant DeFi. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 This is a flowchart of a cross-chain communication and privacy protection method based on a multi-level architecture provided by an embodiment of the present invention.

[0016] Figure 2 This is a schematic diagram of a cross-chain communication and privacy protection system based on a multi-level architecture provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0017] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0018] like Figure 1 As shown, an embodiment of the present invention proposes a cross-chain communication and privacy protection method based on a multi-level architecture, the method comprising the following steps: Step S1: The application layer receives a cross-chain asset exchange request initiated by a user through the first blockchain network. The request includes source chain asset information, target chain asset information, and user identity. Step S2: The application layer performs KYC anti-money laundering verification based on the user identity and verifies whether the source chain asset address exists in the preset blacklist to obtain a compliance verification pass result; Step S3: In response to the compliance verification result, the protocol layer generates a cross-chain transaction proposal and constructs a verifiable proof based on zero-knowledge proof technology; Step S4: Based on the verifiable proof, the cross-chain routing node sends an asset freeze instruction to the source chain. The cross-chain routing node uses a relayer and notary collaboration mechanism to monitor the block confirmation events of the source chain in real time. If no on-chain event indicating successful asset freezing is detected within the preset time, the cross-chain process is terminated and a failure notification is returned to the application layer. When the asset is frozen successfully, the generated ZKP proof is verified for validity on the target chain. If the proof is invalid, the protocol layer is re-triggered to generate an updated ZKP proof. Step S5: Based on the valid ZKP proof, the unlock instruction is broadcast to the target chain, triggering the target chain to execute the unlock operation of the corresponding asset; Step S6: After the target chain unlocking operation is completed, the privacy protection module opens limited audit permissions to the regulatory node, only disclosing the transaction timestamp and compliance status field, while continuing to hide the transaction amount and counterparty address information.

[0019] In an embodiment of the present invention, the legitimacy of cross-chain requests is ensured through pre-compliance verification at the application layer. The protocol layer hides sensitive transaction information and generates verifiable proof based on zero-knowledge proof technology. The cross-chain routing node uses a collaborative mechanism between a repeater and a notary to achieve reliable monitoring and dynamic proof verification of source chain asset freezes (automatically updating the proof when it expires), thereby ensuring the continuity and success rate of the cross-chain process. After the target chain is unlocked, the limited audit design of the privacy protection module is used to disclose the timestamp and compliance status in a targeted manner and hide sensitive data such as the amount and address. The entire process achieves an organic unity of compliance, security and privacy protection in cross-chain communication, effectively solving technical problems such as privacy exposure, regulatory conflicts and low cross-chain efficiency in traditional solutions.

[0020] In a preferred embodiment of the present invention, the above step S1 may include: S1.1: Capture the original cross-chain asset exchange request data packet through the API interface of the first blockchain network; S1.2: Perform structured parsing on the data packet and extract key fields: source chain asset information, target chain asset information, and user identity.

[0021] In an embodiment of the present invention, the original request data packet is captured through the API interface of the first blockchain network to ensure the standardization and compatibility of cross-chain request access, and the cross-chain asset exchange requests of different blockchain networks can be obtained in real time and reliably. The data packet is structured and parsed to extract key information, and the heterogeneous chain data can be unified into a format that can be recognized by the system, thereby improving data processing efficiency and accuracy, and providing an accurate input basis for subsequent KYC anti-money laundering verification, blacklist screening and other compliance verification steps. At the same time, by extracting necessary fields in a targeted manner, irrelevant data interference is avoided, and the exposure of sensitive information is minimized while ensuring the smoothness of the process, thereby strengthening the standardization and security of application layer data preprocessing.

[0022] In an embodiment of the present invention, the specific steps include: S1.1: The system deploys an API interface adapter compatible with the first blockchain network (such as Ethereum, Bitcoin, etc.) at the application layer, and monitors cross-chain asset exchange-related transaction events or user request entries in real time by calling the standard interface exposed by the blockchain node (such as JSON-RPC, RESTfulAPI). For the heterogeneous interface protocols of different blockchain networks (such as ERC-20, BTC-RPC), the adapter automatically completes the protocol conversion to ensure the compatibility capture of multi-chain requests. When the user initiates a cross-chain asset exchange transaction to the first blockchain network through a wallet, DApp or other client, the system captures the original data packet containing the request information (such as transaction data, smart contract call parameters) in real time, and performs hash verification (such as SHA-256) on the captured data packet to ensure that the data has not been tampered with during transmission, thereby ensuring the integrity and authenticity of the request.

[0023] S1.2: Based on the data packet format of the first blockchain network, use corresponding parsing tools (such as the open source library web3.js, bitcoinjs-lib) to convert the original binary / semi-structured data into recognizable JSON or key-value pair format. For smart contract call requests, extract the parameter list by parsing the contract ABI (Application Binary Interface) to clarify the requested function type (such as cross-chain exchange) and input parameters.

[0024] Key information extraction: Source chain asset information: Extract fields such as asset type (such as ERC-20 token, native currency), asset contract address (if it is a token), and exchange quantity from the parsed data packet.

[0025] Target chain asset information: Identifies the target blockchain network (such as Polkadot, Solana) and target asset type / contract address specified in the request to ensure target chain compatibility for cross-chain swaps.

[0026] User identity: Extract the user's address (public key hash) in the first blockchain network or the user ID pre-bound through the KYC module (if the system supports the account system) as the basis for subsequent compliance verification.

[0027] Data standardization: Map the extracted heterogeneous chain data to the system's unified data model (such as defining fields such as source chain / target chain ID, asset symbol, user unique identifier, etc.) to eliminate format differences between different blockchain networks.

[0028] In a preferred embodiment of the present invention, the above step S2 may include: S2.1: Extract the user identity from the generated cross-chain request object and initiate an asynchronous verification request to the KYC certification center to obtain the credential verification result; S2.2: Receive the credential verification result returned by the KYC certification center. If the returned result is invalid, terminate the process and mark the KYC verification as failed; S2.3: Parallel execution of source chain asset address blacklist screening: Call the regulatory contract interface to query whether the source chain asset address exists in the preset blacklist library. If the address hits the blacklist rule, the process is terminated and marked as blacklisted; S2.4: Generate a compliance verification pass result if and only if the KYC verification passes and the blacklist screening is not hit.

[0029] In an embodiment of the present invention, a parallel processing mechanism of asynchronous KYC verification and blacklist screening is used to significantly improve the system processing efficiency while ensuring compliance: on the one hand, asynchronously calling the KYC certification center interface avoids synchronous blocking, ensuring the real-time processing of user requests, and immediately terminating the process in an invalid state can effectively intercept illegal requests that fail identity authentication; on the other hand, the source chain asset address blacklist screening and KYC verification are executed in parallel, and the preset blacklist library is queried in real time through the regulatory contract interface, which can quickly identify black-related addresses and trigger the interception mechanism. The two form a double compliance filter. A compliance result is generated only when both checks are passed, which not only meets the strict requirements of anti-money laundering supervision on the legitimacy of user identity and asset sources, but also reduces unnecessary subsequent operations through process optimization, while improving the security of cross-chain transactions and reducing system resource consumption, effectively solving the problems of low compliance verification efficiency and insufficient risk control in the traditional single-layer architecture.

[0030] In an embodiment of the present invention, the specific steps include: S2.1: Extract the user identity field from the cross-chain request object (structured data model) generated in step S1. This field may be a blockchain address or a user ID registered in the system, depending on whether the system is integrated with the off-chain account system. Call the asynchronous verification interface (such as POST / kyc / verify) provided by the KYC certification center through the HTTP / HTTPS protocol. The request parameters include the user identity, request timestamp and system signature (tamper-proof). Use an asynchronous mode (such as message queue MQ, such as RabbitMQ, Kafka) to decouple the verification logic to avoid blocking the main process due to response delays from the KYC center and improve system throughput. Generate a unique KYC verification request ID and associate it with the cross-chain request object. Record the KYC verification status in memory or database, start a timeout timer (such as 5 minutes). If no result is returned within the timeout, mark it as Timeout and terminate the process.

[0031] S2.2: Obtain the verification result returned by the KYC certification center through an asynchronous callback interface (such as Webhook) or polling mechanism, and parse it into structured data (such as JSON), including the following fields: status (valid / invalid / timeout), reason (if invalid), timestamp (verification time). If the status is invalid or timeout, terminate the cross-chain process immediately, record the log (including user ID and failure reason), and return a KYC verification failure notification to the user through the application layer. Mark the failed request (such as the database field kyc_status=FAILED), triggering the risk audit process (such as manual review).

[0032] S2.3: Extract the source chain asset address (i.e., the sending address of the chain where the asset the user is redeeming is located), such as an Ethereum address or a Bitcoin address, from the cross-chain request object. Call the smart contract deployed on the regulatory chain through the blockchain node interface (such as Infura for Ethereum) and execute the checkBlacklist(address) function, passing in the source chain address as a parameter. The regulatory contract maintains a dynamically updated blacklist library (such as adding / deleting addresses through the on-chain governance mechanism) to store risky addresses such as those involved in money laundering and fraud. It supports fuzzy matching rules (such as prefix matching and label matching), such as triggering an interception when a certain type of address is marked as high-risk. If the contract returns isBlacklisted = true, the cross-chain process is immediately terminated, a blacklist interception log is recorded, including the address and blacklist type (such as the OFAC sanctions list), and an alert is sent to the regulatory node. The hit address is tracked on-chain, linked to its historical transaction records, and triggered in-depth risk analysis.

[0033] S2.4: The compliance verification is considered to have passed only when the following conditions are met simultaneously: the KYC verification result is valid, the source chain address does not hit the blacklist, and a cryptographically signed compliance token (such as JWT format) is generated, which contains the following fields: user ID, verification pass timestamp, KYC certificate hash, blacklist query result hash, and is signed with the system private key to ensure that it cannot be tampered with. The compliance token is attached to the cross-chain request object as an access credential to enter the protocol layer. If any verification fails, the process terminates and resources are released (such as unfreezing the pre-occupied on-chain asset quota, if any). Sensitive information of the failed request is encrypted and archived to comply with data retention regulations (such as GDPR).

[0034] In a preferred embodiment of the present invention, the above step S3 may include: S3.1: Extract the asset information hash summary and cryptographically signed compliance token based on the generated compliance verification result; S3.2: Generate cross-chain transaction proposal core parameters based on compliant tokens: source chain asset freeze limit, target chain unlock address, and cross-chain transaction unique identifier; S3.3: Call the zero-knowledge proof engine to perform the following operations, input parameters: asset information hash summary plus cross-chain transaction unique identifier, construct a verifiable proof: transaction amount, user original address, compliance token validity signature and target chain ID, and generate a chain-verifiable proof certificate.

[0035] In an embodiment of the present invention, by extracting the asset information hash summary and cryptographically signed compliance token from the compliance verification results, it is ensured that only compliant transactions enter the cross-chain process, and the subsequent processing of illegal transactions is blocked from the source; the core parameters of cross-chain transactions are generated based on the compliance token, and the full-cycle tracking of transactions is achieved through a unique identifier. Combined with the precise mapping of the source chain frozen amount and the target chain unlocked address, the accuracy of cross-chain asset transfers is guaranteed; when calling the zero-knowledge proof engine, the hash summary and the unique identifier are used as input parameters, and sensitive information such as the transaction amount and user address are hidden in the proof structure. At the same time, the validity and compliance of the proof are ensured by embedding the compliance token signature, so that the target chain can complete the verification without obtaining the original data, which not only meets the privacy protection requirements of cross-chain communication, but also builds a decentralized trust mechanism through chain-verifiable proof credentials, thereby improving the security and regulatory compatibility of cross-chain transactions.

[0036] In an embodiment of the present invention, the specific steps include: S3.1: Analyze the following key data from the compliance verification results delivered by the application layer: Asset information: including source chain asset type, quantity, target chain asset type, etc. (e.g. ETH10 → USDT100); Compliance token: This is the cryptographically signed token (e.g., JWT format) generated in step S2.4, which contains compliance proofs such as user identity verification results and blacklist screening results.

[0037] Structuring asset information (such as serializing it into JSON), using cryptographic hash functions (such as SHA-256) to generate a fixed-length hash digest (Hash(asset information)), ensuring data integrity (any modification will result in a change in the hash value), verifying the digital signature of the compliance token (such as using the system public key to decrypt the JWT signature), and ensuring that the token has not been tampered with and is within the validity period (such as checking the exp field).

[0038] S3.2: Extract the source chain asset exchange quantity (e.g., "ETH10") from the asset information and calculate the actual frozen amount (e.g., "ETH10.01") based on the cross-chain handling fee (e.g., 0.1%) to ensure that the frozen amount covers the exchange demand and on-chain operation costs. If the user specifies the target chain address in the request, the withdrawal is made directly; if not, the system automatically generates a temporary target chain address (e.g., derived through an HD wallet) and associates it with the user's account to ensure asset traceability.

[0039] Adopting a combination generation strategy: ,in, Is a millisecond timestamp, is a 128-bit random number (binary), that is, 、 It is the hash value (binary) of the source chain address, calculated by a hash function (such as SHA-256), It is a string concatenation operation that connects the three parts in sequence to form a unique identifier.

[0040] S3.3: Select a proof scheme based on target chain compatibility, such as: Groth16: Suitable for chains that support precompiled verification contracts, such as Ethereum, with high proof generation efficiency; PLONK / STARK: Suitable for scenarios that require resistance to quantum attacks or dynamic trusted settings.

[0041] Input parameter processing: Public input: asset information hash summary, cross-chain transaction unique identifier (TXID), used by the target chain to verify the relevance of the proof to the on-chain events; Private input: transaction amount, user original address (such as source chain address), compliance token validity signature (such as the signature field of JWT), target chain ID (such as BSCID in ETH→BSC).

[0042] Proof construction process: Parameter initialization: Call the proof engine's setup function to generate a common reference string (CRS) for proof generation and verification (only needs to be executed once and can be reused); Proof generation: Private data is input through the prove function, and combined with public input, a proof π is generated. The proof content includes: The transaction amount matches the asset information hash; The user's address passes KYC verification (proven by the compliance token signature); The target chain ID is consistent with the request.

[0043] Proof serialization: Serialize the proof π into a byte stream (such as Base64 encoding) to facilitate cross-chain transmission and on-chain storage.

[0044] In a preferred embodiment of the present invention, the above step S4 may include: S4.1: Distribute the encapsulated cross-chain transaction package to the cross-chain routing node, triggering the routing node to perform the following operations: carry the generated frozen amount and transaction unique identifier, and start the relayer-notary collaborative monitoring; S4.2: The notary issues a freeze timeout certificate. The routing node terminates the process and returns a failure notification to the application layer. It extracts the generated ZKP certificate and calls the target chain's ZKP verification contract. The input parameters include: public fields, the source chain block height included in the event, and the notary's confirmation signature of the event. S4.3: When the ZKP verification contract returns Proof_Invalid, the routing node sends a proof invalidation alert to the protocol layer, carrying the current source chain state snapshot. The protocol layer re-triggers step S3.3 to generate an updated ZKP proof.

[0045] In an embodiment of the present invention, through the relayer-notary collaborative mechanism of cross-chain routing nodes, real-time monitoring and reliable verification of source chain asset freezing events are achieved: the relayer continuously tracks the block confirmation status, and the notary issues an authoritative certificate in a timeout scenario to terminate the invalid process and avoid long-term resource occupation; after the asset is successfully frozen, the target chain dynamically verifies the proof certificate through the ZKP verification contract. When the proof fails due to inter-chain state delay, the routing node captures the exception in real time and triggers the protocol layer to regenerate and update the proof to ensure the consistency of cross-chain transactions and on-chain states. This mechanism not only improves the anti-attack and fault tolerance of cross-chain operations through multi-party collaborative consensus, but also solves the verification failure problem caused by time difference in traditional static zero-knowledge proofs through a dynamic proof update mechanism, significantly improving the success rate of cross-chain processes and system robustness, and providing reliable execution guarantees for cross-chain asset transfers in complex network environments.

[0046] In an embodiment of the present invention, the specific steps include: S4.1: Serialize the cross-chain transaction proposal (including frozen amount, TXID, ZKP proof, etc.) generated in step S3 into a transaction package and broadcast it to a preset cross-chain routing node cluster (e.g., 10 distributed nodes) through the P2P network. Each routing node deploys a relay program and subscribes to specific events (e.g., AssetFrozen) through the source chain API (e.g., WebSocket). The monitoring range is ±1000 (configurable) of the current block height. The relay continuously monitors the number of source chain block confirmations and records the precise timestamp of the event (e.g., block.timestamp). The routing node randomly selects 3-5 notary nodes to form a temporary committee. The monitoring event is confirmed through a multi-signature mechanism (e.g., ECDSA threshold signature). The notary node independently verifies the authenticity of the event (e.g., whether the asset frozen amount matches the TXID).

[0047] S4.2: If no successful asset freezing event is detected within a preset time (e.g., 20 minutes), the Notary Committee issues a FreezeTimeoutProof through a consensus mechanism (e.g., PBFT), which includes: Timeout timestamp, monitoring block range, and signature set of participating notaries; The routing node writes the proof into the cross-chain state contract, terminates the process, and returns a failure notification (such as code = 408) through the application layer API.

[0048] If the asset freeze is successful (the relayer captures the AssetFrozen event and the notary confirms it), the routing node extracts the ZKP proof certificate and constructs the verification parameters: Public fields: asset information hash summary, TXID; Source chain block height: the block number where the event occurred; Notary signature: multiple signatures on events; Call the pre-deployed ZKP verification contract (such as a Solidity contract) through the target chain RPC interface and execute the verifyProof function: ,in, The public input set, It is a zero-knowledge proof certificate generated by the ZKP engine. is the source chain block height, that is, the block number when the asset freeze event occurs, It is a collection of notary signatures.

[0049] S4.3: The target chain verifies the contract and returns the result: Proof_Valid: Continue to execute step S5 and Proof_Invalid: Trigger the proof invalidation process.

[0050] The routing node immediately calls the source chain API to obtain a snapshot of the current state, including: Latest block height, asset contract balance, and event log; Send a ProofExpiredAlert to the protocol layer via an internal message queue (such as RabbitMQ), carrying: expired TXID, state snapshot hash, and verification failure reason.

[0051] After receiving the alert, the protocol layer extracts the current source chain status data and re-executes step S3.3: Input parameters: new asset information hash (reflecting the latest status), original TXID; Call the ZKP engine to generate the updated proof (such as Groth16 proof); The new proof is returned to the routing node, re-triggering the target chain verification process (step S4.2).

[0052] In a preferred embodiment of the present invention, the above step S5 may include: S5.1: Parse the cross-chain state proof generated by the cloud routing node and extract the following key elements: valid ZKP proof certificate, source chain AssetFrozen event notarization signature, and target chain unlocking address and asset identifier; S5.2: Construct an unlocking instruction executable on the target chain and broadcast it through the notary multi-signature mechanism: the routing node distributes the instruction to the preset notary cluster and adds a multi-signature to the instruction after verification by more than 2 / 3 of the notaries to obtain the execution result of the monitored target chain; S5.3: Based on the feedback of the execution results and exception handling, the corresponding asset unlocking operation is obtained.

[0053] In an embodiment of the present invention, the validity and integrity of key elements are ensured by parsing cross-chain status proofs, providing a credible basis for the target chain unlocking operation; a notary multi-signature mechanism is adopted when constructing the unlocking instruction, and the authority and anti-attack ability of the instruction are enhanced through distributed consensus, avoiding operation failure caused by malicious behavior of a single node or a single point of failure; after the instruction is broadcast, the execution result of the target chain is monitored in real time and exception handling is implemented to ensure the atomicity and eventual consistency of asset unlocking. This mechanism not only builds a decentralized trust system through cryptographic proof and multi-party collaboration, but also ensures the security, reliability and process closed-loop of cross-chain asset transfer through refined instruction execution control and exception feedback links, effectively solving technical problems such as unreliable unlocking operations and weak trust mechanisms in traditional cross-chain systems.

[0054] In an embodiment of the present invention, the specific steps include: S5.1: The routing node receives the cross-chain state proof generated by the cloud, including: ZKP proof credential: the zero-knowledge proof generated in step S4 (e.g., a Base64-encoded byte stream); Notary signature set: multiple signatures for the source chain AssetFrozen event; Target chain information: unlocking address (such as 0xTargetAddress), asset identifier (such as ERC-20 contract address).

[0055] Verify the validity of the ZKP proof (call the verification contract pre-deployed on the target chain), confirm the notary signature threshold (such as ≥ 2 / 3 quorum), extract the public input (such as asset hash summary, TXID) from the ZKP proof, parse the public key corresponding to the notary signature, verify whether it belongs to the preset whitelist (such as the set of notaries approved by the regulatory agency), extract the target chain unlock address and asset identifier, and verify the format legitimacy (such as whether it is a valid Ethereum address).

[0056] S5.2: Instruction format definition (such as JSON-RPC request), notary multi-signature process: Instruction distribution: The routing node synchronizes the instructions to the preset notary cluster (e.g. 7 nodes); Each notary independently verifies: ZKP proves validity; The relevance of source chain events and target chain operations (e.g., TXID matching); The consistency between the unlocked amount and the frozen amount (indirectly verified through ZKP proof).

[0057] Multi-signature: When ≥2 / 3 notaries (e.g. 5 / 7) pass verification, each notary signs the instruction with ECDSA, and the signatures are aggregated into an M-of-N multi-signature (e.g. 5-of-7).

[0058] The routing node broadcasts the multi-signature instruction to the target chain network, subscribes to the AssetUnlocked event through the target chain RPC interface (such as WebSocket), and sets a timeout for monitoring (such as 30 minutes).

[0059] S5.3: Listen to the target chain block confirmation, capture the AssetUnlocked event, and verify the consistency of the event parameters with the unlock instruction.

[0060] When the target chain is confirmed to be executed successfully (such as 3 blocks confirmed), the routing node: Update the cross-chain transaction status to Completed; Notify users via application layer APIs (e.g. push notifications, SMS messages); The final status is written to the regulatory node (such as the consortium chain) for evidence storage.

[0061] Timeout not executed: If the unlock event is not captured during the timeout, the routing node: Triggering a rollback mechanism (such as unfreezing source chain assets); Initiate a survey request to the notary cluster and generate a failure report.

[0062] If the AssetUnlockFailed event is captured, analyze the failure reason (such as insufficient balance, permission error), and handle it accordingly: Insufficient balance: triggers the cross-chain asset replenishment process; Permission error: Restructure the command or change the permission account.

[0063] In a preferred embodiment of the present invention, the above step S6 may include: S6.1: Based on the cross-chain completion certificate captured by the privacy protection module, the following audit foundation elements are extracted from it: the transaction hash value of the target chain unlocking operation, the compliant timestamp cryptographic evidence, and the set of public fields in the constructed ZKP proof; S6.2: Construct limited audit vouchers based on audit elements: transaction timestamp field, compliance status field, transaction amount field, and counterparty address; S6.3: Open a directional audit channel to the supervisory node: Verify the identity of the requesting node to match the preset supervisory node certificate whitelist, and return structured audit credentials through an encrypted data interface; S6.4: Based on the returned structured audit voucher, implement full-cycle privacy protection: transaction amount query, counterparty identification, isolated storage of sensitive fields, and blockchain public data.

[0064] In an embodiment of the present invention, the privacy protection module accurately captures the basic audit elements (transaction hash, compliance timestamp encrypted evidence and ZKP public fields) in the cross-chain completion certificate, while ensuring the traceability of basic information required for supervision, avoiding direct exposure of sensitive data such as transaction amount and counterparty address. When constructing limited audit certificates, a field-level disclosure strategy is adopted, and a targeted encrypted channel is only opened to regulatory nodes that have passed the certificate whitelist verification, to achieve transparent audit of transaction timestamps and compliance status, while continuously hiding core privacy information through sensitive field isolation storage technology; the full-cycle privacy protection mechanism is combined with the public data characteristics of the blockchain, which not only meets the penetrating supervision requirements of anti-money laundering regulations on transaction compliance, but also strengthens user privacy security through the principle of minimizing data disclosure, effectively resolving the fundamental conflict between privacy protection and regulatory audit in traditional cross-chain systems, and providing a safe and controllable audit solution for compliant financial scenarios.

[0065] In an embodiment of the present invention, the specific steps include: S6.1: Credential Capture: The privacy protection module captures the credentials of cross-chain transaction completion in real time by monitoring the smart contract events of the target chain (such as AssetUnlocked). The credential contains the unique transaction hash value of the target chain unlocking operation.

[0066] Compliance timestamp extraction: retrieve the encrypted and stored timestamp (such as the KYC verification pass time) from the compliance verification record of the cross-chain process. The timestamp has been encrypted by the public key of the regulatory node to ensure that it cannot be tampered with.

[0067] ZKP public field parsing: Extract public input fields from the zero-knowledge proof generated in step S3, such as asset information hash summary, cross-chain transaction unique identifier (TXID), and other non-sensitive data.

[0068] S6.2: Field Mapping: Transaction timestamp: directly uses the block timestamp of the target chain unlocking event; Compliance status: Based on the KYC verification results and blacklist screening results, it is marked as passed or blocked; Transaction amount: The actual amount is encrypted (e.g., using a commitment mechanism), and only a verifiable proof of the amount range (e.g., amount ≤ $1 million) is provided to the regulatory node. Counterparty address: Convert the user's actual address into an anonymous identifier (such as generating a pseudonym through a hash algorithm combined with a random salt value), retaining the minimum associated information required for audit tracing.

[0069] Integrate the above fields into a standardized format (such as JSON), append metadata such as timestamp and credential version number, and form a structured data package that can be audited.

[0070] S6.3: When a supervisory node initiates an audit request, the system verifies its identity through the following methods: Checks whether the requesting node’s digital certificate exists in a preset whitelist (pre-authorized by the regulatory body); Verify the validity of the certificate (for example, it is not expired and is issued by a trusted CA).

[0071] The encrypted audit certificate is returned to the verified supervisory node via a secure communication protocol (such as HTTPS) to ensure that the data cannot be stolen or tampered with during transmission.

[0072] S6.4: Regulatory nodes can only obtain encrypted commitments or range proofs of amounts. If the specific amount needs to be verified, zero-knowledge proof technology must be used (such as proving that the amount is consistent with the compliance limit) to avoid exposing the true value. The counterparty's address is presented in the form of a pseudonym, and the mapping between the real address and the pseudonym is stored in shards by multi-party secure computing (MPC) nodes. It requires the cooperation of at least 2 / 3 of the regulatory nodes to decrypt. Sensitive fields such as transaction amount and real address are stored in an independent encrypted database and isolated from the blockchain's public data. The blockchain only records non-sensitive information such as transaction hashes and timestamps, and hides the final digits of the amount and some characters of the address in data displayed on public channels such as blockchain browsers to reduce the risk of privacy leakage.

[0073] like Figure 2 As shown, an embodiment of the present invention further provides a cross-chain communication and privacy protection system based on a multi-level architecture, including: An acquisition module is configured to receive, at the application layer, a cross-chain asset exchange request initiated by a user through the first blockchain network, the request including source chain asset information, target chain asset information, and a user identity; the application layer performs KYC anti-money laundering verification based on the user identity, and verifies whether the source chain asset address exists in a preset blacklist to obtain a compliance verification pass result; The update module is used by the protocol layer to generate cross-chain transaction proposals in response to compliance verification results, and at the same time construct a verifiable proof based on zero-knowledge proof technology. Based on the verifiable proof, the cross-chain routing node sends an asset freeze instruction to the source chain. The cross-chain routing node uses a relayer and notary collaboration mechanism to monitor the block confirmation events of the source chain in real time. If no on-chain event indicating successful asset freezing is monitored within the preset time, the cross-chain process is terminated and a failure notification is returned to the application layer. When the asset is frozen successfully, the validity of the generated ZKP proof on the target chain is verified. If the proof is invalid, the protocol layer is re-triggered to generate an updated ZKP proof. The processing module is used to broadcast the unlocking instruction to the target chain based on the valid ZKP proof, triggering the target chain to execute the unlocking operation of the corresponding assets; after the unlocking operation of the target chain is completed, the privacy protection module opens limited audit permissions to the supervision node, only discloses the transaction timestamp and compliance status field, while continuing to hide the transaction amount and counterparty address information.

[0074] The above is a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as within the scope of protection of the present invention.

Claims

1. A cross-chain communication and privacy protection method based on a multi-level architecture, characterized by: The method comprises: S1: The application layer receives a cross-chain asset exchange request initiated by a user through the first blockchain network. The request includes source chain asset information, target chain asset information, and user identity. S2: The application layer performs KYC anti-money laundering verification based on the user identity and verifies whether the source chain asset address exists in the preset blacklist to obtain a compliance verification result; S3: The protocol layer generates a cross-chain transaction proposal in response to the compliance verification result, and constructs a verifiable proof based on zero-knowledge proof technology; S4: Based on verifiable proof, an asset freeze instruction is sent to the source chain through the cross-chain routing node. The cross-chain routing node uses a relayer and notary collaboration mechanism to monitor the block confirmation events of the source chain in real time. If no on-chain event indicating successful asset freezing is detected within the preset time, the cross-chain process is terminated and a failure notification is returned to the application layer. When the asset is frozen successfully, the validity of the generated ZKP proof on the target chain is verified. If the proof is invalid, the protocol layer is re-triggered to generate an updated ZKP proof. S5: Broadcast the unlock instruction to the target chain based on the valid ZKP proof, triggering the target chain to execute the unlock operation of the corresponding asset; S6: After the target chain unlocking operation is completed, the privacy protection module opens limited audit permissions to the regulatory node, only disclosing the transaction timestamp and compliance status field, while continuing to hide the transaction amount and counterparty address information.

2. The cross-chain communication and privacy protection method based on a multi-level architecture according to claim 1 is characterized in that: The application layer receives a cross-chain asset exchange request initiated by a user through the first blockchain network. The request includes source chain asset information, target chain asset information, and user identity, including: S1.1: Capture the original cross-chain asset exchange request data packet through the API interface of the first blockchain network; S1.2: Perform structured parsing on the data packet and extract key fields: source chain asset information, target chain asset information, and user identity.

3. The cross-chain communication and privacy protection method based on a multi-level architecture according to claim 2 is characterized in that: The application layer performs KYC anti-money laundering verification based on the user identity and verifies whether the source chain asset address exists in the preset blacklist to obtain a compliance verification result, including: S2.1: Extract the user identity from the generated cross-chain request object and initiate an asynchronous verification request to the KYC certification center to obtain the credential verification result; S2.2: Receive the credential verification result returned by the KYC certification center. If the returned result is invalid, terminate the process and mark the KYC verification as failed; S2.3: Parallel execution of source chain asset address blacklist screening: Call the regulatory contract interface to query whether the source chain asset address exists in the preset blacklist library. If the address hits the blacklist rule, the process is terminated and marked as blacklisted; S2.4: Generate a compliance verification pass result if and only if the KYC verification passes and the blacklist screening is not hit.

4. The cross-chain communication and privacy protection method based on a multi-level architecture according to claim 3 is characterized in that: In response to the compliance verification results, the protocol layer generates a cross-chain transaction proposal and constructs a verifiable proof based on zero-knowledge proof technology, including: S3.1: Extract the asset information hash summary and cryptographically signed compliance token based on the generated compliance verification result; S3.2: Generate cross-chain transaction proposal core parameters based on compliant tokens: source chain asset freeze limit, target chain unlock address, and cross-chain transaction unique identifier; S3.3: Call the zero-knowledge proof engine to perform the following operations, input parameters: asset information hash summary plus cross-chain transaction unique identifier, construct a verifiable proof: transaction amount, user original address, compliance token validity signature and target chain ID, and generate a chain-verifiable proof certificate.

5. The cross-chain communication and privacy protection method based on a multi-level architecture according to claim 4 is characterized in that: Based on verifiable proof, the cross-chain routing node sends an asset freeze instruction to the source chain. The cross-chain routing node uses a relayer and notary collaboration mechanism to monitor the block confirmation events of the source chain in real time. If no on-chain event indicating successful asset freezing is detected within the preset time, the cross-chain process is terminated and a failure notification is returned to the application layer. When the asset is successfully frozen, the validity of the generated ZKP proof on the target chain is verified. If the proof is invalid, the protocol layer is re-triggered to generate an updated ZKP proof, including: S4.1: Distribute the encapsulated cross-chain transaction package to the cross-chain routing node, triggering the routing node to perform the following operations: carry the generated frozen amount and transaction unique identifier, and start the relayer-notary collaborative monitoring; S4.2: The notary issues a freeze timeout certificate. The routing node terminates the process and returns a failure notification to the application layer. It extracts the generated ZKP certificate and calls the target chain's ZKP verification contract. The input parameters include: public fields, the source chain block height included in the event, and the notary's confirmation signature of the event. S4.3: When the ZKP verification contract returns Proof_Invalid, the routing node sends a proof invalidation alert to the protocol layer, carrying the current source chain state snapshot. The protocol layer re-triggers step S3.3 to generate an updated ZKP proof.

6. The cross-chain communication and privacy protection method based on a multi-level architecture according to claim 5 is characterized in that: Based on the valid ZKP proof, the unlock instruction is broadcast to the target chain, triggering the target chain to execute the unlock operation of the corresponding asset, including: S5.1: Parse the cross-chain state proof generated by the cloud routing node and extract the following key elements: valid ZKP proof certificate, source chain AssetFrozen event notarization signature, and target chain unlocking address and asset identifier; S5.2: Construct an unlocking instruction executable on the target chain and broadcast it through the notary multi-signature mechanism: the routing node distributes the instruction to the preset notary cluster and adds a multi-signature to the instruction after verification by more than 2 / 3 of the notaries to obtain the execution result of the monitored target chain; S5.3: Based on the feedback of the execution results and exception handling, the corresponding asset unlocking operation is obtained.

7. The cross-chain communication and privacy protection method based on a multi-level architecture according to claim 6 is characterized in that: After the target chain unlocking operation is completed, the privacy protection module opens limited audit permissions to the supervisory node, only disclosing the transaction timestamp and compliance status fields, while continuing to hide the transaction amount and counterparty address information, including: S6.1: Based on the cross-chain completion certificate captured by the privacy protection module, the following audit foundation elements are extracted from it: the transaction hash value of the target chain unlocking operation, the compliant timestamp cryptographic evidence, and the set of public fields in the constructed ZKP proof; S6.2: Construct limited audit vouchers based on audit elements: transaction timestamp field, compliance status field, transaction amount field, and counterparty address; S6.3: Open a directional audit channel to the supervisory node: Verify the identity of the requesting node to match the preset supervisory node certificate whitelist, and return structured audit credentials through an encrypted data interface; S6.4: Based on the returned structured audit voucher, implement full-cycle privacy protection: transaction amount query, counterparty identification, isolated storage of sensitive fields, and blockchain public data.

8. A cross-chain communication and privacy protection system based on a multi-level architecture, wherein the system implements the method according to any one of claims 1 to 7, characterized in that: include: An acquisition module is configured to receive, at the application layer, a cross-chain asset exchange request initiated by a user through the first blockchain network, the request including source chain asset information, target chain asset information, and a user identity; the application layer performs KYC anti-money laundering verification based on the user identity, and verifies whether the source chain asset address exists in a preset blacklist to obtain a compliance verification pass result; Update module, which is used by the protocol layer to generate cross-chain transaction proposals in response to compliance verification results, and construct verifiable proofs based on zero-knowledge proof technology; Based on verifiable proof, the cross-chain routing node sends an asset freeze instruction to the source chain. The cross-chain routing node uses a relayer and notary collaboration mechanism to monitor the block confirmation events of the source chain in real time. If no on-chain event indicating successful asset freezing is detected within the preset time, the cross-chain process is terminated and a failure notification is returned to the application layer. When the asset is frozen successfully, the generated ZKP proof is verified to be valid on the target chain. If the proof is invalid, the protocol layer is re-triggered to generate an updated ZKP proof. The processing module is used to broadcast the unlocking instruction to the target chain based on the valid ZKP proof, triggering the target chain to execute the unlocking operation of the corresponding assets; after the unlocking operation of the target chain is completed, the privacy protection module opens limited audit permissions to the supervision node, only discloses the transaction timestamp and compliance status field, while continuing to hide the transaction amount and counterparty address information.

9. A computing device, characterized in that include: one or more processors; A storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a program, which, when executed by a processor, implements the method according to any one of claims 1 to 7.

Images