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

Abstract

The application provides a cross-chain communication and privacy protection method, system and device based on a multi-level architecture and a storage medium, relates to the technical field of data processing, and the method comprises the following steps: an application layer receives a cross-chain asset exchange request initiated by a user through a first block chain network, the request containing 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; a protocol layer generates a cross-chain transaction proposal in response to the compliance verification pass result, and constructs a verifiable proof based on zero-knowledge proof technology. The application solves the natural contradiction between privacy protection and regulatory compliance in the cross-chain scene of the block chain.

Description

Technical Field

[0001] This invention relates to the field of blockchain cross-chain communication technology, and in particular to cross-chain communication and privacy protection methods, systems, devices and storage media based on a multi-level architecture. Background Technology

[0002] The mainstream cross-chain architecture suffers from three major technical flaws: the single-layer processing model leads to the coupling of compliance verification, asset transfer, and privacy control logic, which significantly reduces system throughput; the static generation mechanism of zero-knowledge proof is difficult to adapt to inter-chain state delays, and cross-chain failures are often caused by proof failures; and the regulatory interface design is crude, either completely blocking audit permissions or fully opening up data. Summary of the Invention

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

[0004] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0005] Firstly, a cross-chain communication and privacy protection method based on a multi-level architecture, the method comprising:

[0006] 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 identifier.

[0007] S2: The application layer performs KYC anti-money laundering verification based on the user identity identifier and verifies whether the source chain asset address exists in the preset blacklist in order to obtain a compliance verification result;

[0008] 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.

[0009] S4: Based on verifiable proof, the cross-chain node sends an asset freeze command to the source chain. The cross-chain node uses a relay and notary collaboration mechanism to monitor the block confirmation event of the source chain in real time. If no on-chain event of successful asset freeze 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 freeze is successful, 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.

[0010] S5: Broadcast unlock instructions to the target chain based on valid ZKP proofs, triggering the target chain to perform the corresponding asset unlocking operation;

[0011] S6: After the target chain unlocking operation is completed, the privacy protection module grants limited audit permissions to regulatory nodes, disclosing only the transaction timestamp and compliance status fields, while continuously hiding the transaction amount and counterparty address information.

[0012] Furthermore, the application layer receives cross-chain asset exchange requests initiated by users through the first blockchain network. These requests include source chain asset information, target chain asset information, and user identification, including:

[0013] S1.1: Capture the original cross-chain asset exchange request data packet through the API interface of the first blockchain network;

[0014] S1.2: Perform structured parsing on the data packet and extract key fields: source chain asset information, target chain asset information, and user identity identifier.

[0015] Furthermore, the application layer performs KYC (Know Your Customer) anti-money laundering verification based on the user's identity identifier and verifies whether the source chain asset address exists in a preset blacklist to obtain a compliance verification result, including:

[0016] S2.1: Extract the user identity identifier from the generated cross-chain request object and send an asynchronous verification request to the KYC authentication center to obtain the credential verification result;

[0017] S2.2: Receive the credential verification result returned by the KYC authentication center. If the returned result is invalid, terminate the process and mark the KYC verification as failed.

[0018] 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 database. If the address matches the blacklist rule, terminate the process and mark it as blacklisted for blocking.

[0019] S2.4: Generate a compliance verification pass result if and only if KYC verification passes and blacklist screening fails.

[0020] Furthermore, 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, including:

[0021] S3.1: Based on the generated compliance verification result, extract the asset information hash digest and the encrypted signature compliance token;

[0022] S3.2: Generate cross-chain transaction proposals based on compliance tokens. Core parameters: source chain asset freeze amount, target chain unlock address, and cross-chain transaction unique identifier;

[0023] S3.3: Call the zero-knowledge proof engine to perform the following operations, with the following input parameters: asset information hash digest plus cross-chain transaction unique identifier, construct verifiable proof: transaction amount, user original address, compliance token validity signature and target chain ID, and generate chain-verifiable proof certificate.

[0024] Furthermore, based on verifiable proofs, the cross-chain node sends an asset freeze command to the source chain. The cross-chain node employs a relay and notary collaboration mechanism to monitor the source chain's block confirmation events in real time. If no on-chain event indicating successful asset freezing is detected within a preset time, the cross-chain process terminates and a failure notification is returned to the application layer. Upon successful asset freezing, 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:

[0025] 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 relay-notary collaborative listening;

[0026] S4.2: The notary issues a freeze timeout certificate, the routing node terminates the process and returns a failure notification to the application layer, extracts the generated ZKP proof certificate, and calls the ZKP verification contract of the target chain. The input parameters include: public fields, the source chain block height contained in the event, and the notary's confirmation signature on the event.

[0027] S4.3: When the ZKP verification contract returns Proof_Invalid, the routing node sends a proof failure alert to the protocol layer, carrying a snapshot of the current source chain state. The protocol layer then re-triggers step S3.3 to generate an updated ZKP proof.

[0028] Furthermore, based on a valid ZKP proof, an unlocking instruction is broadcast to the target chain, triggering the target chain to perform the corresponding asset unlocking operation, including:

[0029] S5.1: Analyze 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 notarized signature, and target chain unlock address and asset identifier;

[0030] S5.2: Construct an executable unlock command for the target chain and broadcast the unlock command through a notary multi-signature mechanism: The routing node distributes the command to the preset notary cluster and after verification by more than 2 / 3 of the notaries, it adds a multi-signature to the command to obtain the execution result of the target chain being monitored;

[0031] S5.3: Based on the feedback of the execution results and exception handling, obtain the corresponding asset unlocking operation.

[0032] Furthermore, after the target chain unlocking operation is completed, the privacy protection module grants limited audit permissions to regulatory nodes, disclosing only the transaction timestamp and compliance status fields, while continuously hiding the transaction amount and counterparty address information, including:

[0033] S6.1: Based on the cross-chain completion certificate captured by the privacy protection module, extract the following audit basic elements from it: the transaction hash value of the target chain unlocking operation, the compliant timestamp encrypted evidence, and the set of public fields in the constructed ZKP proof;

[0034] S6.2: Constructing limited audit documents based on audit elements: transaction timestamp field, compliance status field, transaction amount field, and counterparty address;

[0035] S6.3: Open a targeted audit channel to regulatory nodes: verify the identity of the requesting node to match the preset whitelist of regulatory node certificates, and return structured audit credentials through the encrypted data interface;

[0036] S6.4: Implement full-cycle privacy protection based on the returned structured audit credentials: transaction amount query, counterparty identification, isolated storage of sensitive fields, and public blockchain data.

[0037] Secondly, methods, systems, devices, and storage media for cross-chain communication and privacy protection based on a multi-level architecture include:

[0038] The acquisition module is used by the application layer to receive cross-chain asset exchange requests initiated by users through the first blockchain network. The requests include source chain asset information, target chain asset information, and user identity identifiers. The application layer performs KYC anti-money laundering verification based on the user identity identifiers and verifies whether the source chain asset address exists in a preset blacklist to obtain a compliance verification result.

[0039] The update module is used by the protocol layer to generate cross-chain transaction proposals in response to compliance verification results, and to construct verifiable proofs based on zero-knowledge proof technology. Based on the verifiable proofs, the cross-chain nodes send asset freeze instructions to the source chain. The cross-chain nodes use a relay and notary collaboration mechanism to monitor the block confirmation events of the source chain in real time. If no on-chain event of 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 freeze is successful, 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.

[0040] The processing module is used to broadcast unlocking instructions to the target chain based on valid ZKP proofs, triggering the target chain to perform the corresponding asset unlocking operation; after the target chain unlocking operation is completed, the privacy protection module grants limited auditing permissions to regulatory nodes, disclosing only the transaction timestamp and compliance status fields, while continuously hiding the transaction amount and counterparty address information.

[0041] Thirdly, a computing device includes:

[0042] One or more processors;

[0043] A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method.

[0044] Fourthly, a computer-readable storage medium storing a program that, when executed by a processor, implements the method.

[0045] The above-described solution of the present invention has at least the following beneficial effects:

[0046] By decoupling application-layer compliance verification, protocol-layer cross-chain logic, and privacy protection modules through a multi-level architecture, efficient collaboration in cross-chain communication processes is achieved. A dynamic zero-knowledge proof mechanism is used to resolve the proof failure issue caused by inter-chain state delays. A relay and notary collaboration mechanism ensures reliable execution of asset freezing and unlocking. Limited audit permissions are used to achieve targeted disclosure of transaction timestamps and compliance status, while continuously hiding sensitive information such as transaction amounts and addresses. This effectively balances the conflict between privacy protection and regulatory compliance in blockchain cross-chain scenarios, improving the throughput and success rate of the cross-chain system, and providing a secure and compliant technical solution for cross-border payments, compliant DeFi, and other scenarios. Attached Figure Description

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

[0048] Figure 2 This is a schematic diagram of a cross-chain communication and privacy protection method, system, device, and storage medium based on a multi-level architecture provided by an embodiment of the present invention. Detailed Implementation

[0049] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0050] like Figure 1 As shown, embodiments of the present invention propose a cross-chain communication and privacy protection method based on a multi-level architecture, the method comprising the following steps:

[0051] Step S1: 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 identifier.

[0052] Step S2: The application layer performs KYC anti-money laundering verification based on the user identity identifier and verifies whether the source chain asset address exists in the preset blacklist to obtain a compliance verification result;

[0053] 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.

[0054] Step S4: Based on verifiable proof, the cross-chain node sends an asset freeze command to the source chain. The cross-chain node uses a relay and notary collaboration mechanism to monitor the block confirmation event of the source chain in real time. If no on-chain event of successful asset freeze 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 freeze is successful, 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.

[0055] Step S5: Broadcast the unlock instruction to the target chain based on the valid ZKP proof, triggering the target chain to perform the unlock operation of the corresponding asset;

[0056] Step S6: After the target chain unlocking operation is completed, the privacy protection module grants limited audit permissions to the regulatory node, disclosing only the transaction timestamp and compliance status fields, while continuously hiding the transaction amount and counterparty address information.

[0057] In this embodiment of the invention, the legality of cross-chain requests is ensured through application-layer pre-compliance verification. The protocol layer hides sensitive transaction information and generates verifiable proofs based on zero-knowledge proof technology. The cross-chain mechanism enables reliable monitoring and dynamic proof verification of the frozen source chain assets (automatic proof updates when invalid) by nodes through a relay and notary collaboration mechanism, 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 discloses the timestamp and compliance status in a targeted manner while hiding sensitive data such as amount and address. The entire process achieves an organic unity of compliance, security and privacy protection in cross-chain communication, effectively solving the technical problems of privacy exposure, regulatory contradictions and low cross-chain efficiency in traditional solutions.

[0058] In a preferred embodiment of the present invention, step S1 may include:

[0059] S1.1: Capture the original cross-chain asset exchange request data packet through the API interface of the first blockchain network;

[0060] S1.2: Perform structured parsing on the data packet and extract key fields: source chain asset information, target chain asset information, and user identity identifier.

[0061] In this embodiment of the invention, the original request data packets are captured through the API interface of the first blockchain network, ensuring the standardization and compatibility of cross-chain request access. This enables real-time and reliable acquisition of cross-chain asset exchange requests from different blockchain networks. The data packets are then structured and parsed to extract key information, unifying heterogeneous chain data into a system-recognizable format. This improves data processing efficiency and accuracy, providing a precise input basis for subsequent compliance verification steps such as KYC anti-money laundering verification and blacklist screening. Simultaneously, by selectively extracting necessary fields, irrelevant data interference is avoided. This ensures smooth process flow while minimizing the exposure of sensitive information, thus strengthening the standardization and security of application-layer data preprocessing.

[0062] In this embodiment of the invention, the specific steps include:

[0063] S1.1: The system deploys an API interface adapter compatible with the first blockchain network at the application layer. By calling the standard interface exposed by the blockchain node, it listens in real time for transaction events or user request entry points related to cross-chain asset exchange. For heterogeneous interface protocols of different blockchain networks, the adapter automatically completes protocol conversion to ensure compatibility capture of multi-chain requests. When a user initiates a cross-chain asset exchange transaction to the first blockchain network through the client, the system captures the original data packet containing the request information in real time, performs hash verification on the captured data packet to ensure that the data has not been tampered with during transmission, and guarantees the integrity and authenticity of the request.

[0064] S1.2: Based on the data packet format of the first blockchain network, use the corresponding parsing tool to convert the raw binary / semi-structured data into a recognizable JSON or key-value pair format. For smart contract call requests, extract the parameter list by parsing the contract ABI to clarify the function type and input parameters of the request.

[0065] Key information extraction:

[0066] Source chain asset information: Extract fields such as asset type, asset contract address, and exchange quantity from the parsed data packet.

[0067] Target Chain Asset Information: Identifies the target blockchain network and target asset type / contract address specified in the request to ensure target chain compatibility for cross-chain exchanges.

[0068] User identification: Extract the user's address in the first blockchain network or the user ID pre-bound through the KYC module as the basis for subsequent compliance verification.

[0069] Data standardization processing:

[0070] The extracted heterogeneous chain data is mapped to a unified data model of the system, eliminating the format differences between different blockchain networks.

[0071] In a preferred embodiment of the present invention, step S2 above may include:

[0072] S2.1: Extract the user identity identifier from the generated cross-chain request object and send an asynchronous verification request to the KYC authentication center to obtain the credential verification result;

[0073] S2.2: Receive the credential verification result returned by the KYC authentication center. If the returned result is invalid, terminate the process and mark the KYC verification as failed.

[0074] 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 database. If the address matches the blacklist rule, terminate the process and mark it as blacklisted for blocking.

[0075] S2.4: Generate a compliance verification pass result if and only if KYC verification passes and blacklist screening fails.

[0076] In this embodiment of the invention, a parallel processing mechanism of asynchronous KYC verification and blacklist screening significantly improves system processing efficiency while ensuring compliance. On the one hand, asynchronous calls to the KYC authentication center interface avoid synchronous blocking, ensuring the real-time processing of user requests. Immediate termination of the process in case of failure effectively intercepts illegal requests that fail identity verification. On the other hand, source chain asset address blacklist screening and KYC verification are executed in parallel. By querying the preset blacklist database in real time through the regulatory contract interface, it is possible to quickly identify addresses involved in illegal activities and trigger the interception mechanism. The two form a dual compliance filter. This improves the security of cross-chain transactions while reducing system resource consumption, effectively solving the problems of low compliance verification efficiency and insufficient risk control in traditional single-layer architectures.

[0077] In this embodiment of the invention, the specific steps include:

[0078] S2.1: Extract the user identity field from the cross-chain request object generated in step S1. This field may be a blockchain address or a user ID registered with the system, depending on whether the system integrates an off-chain account system. Call the asynchronous verification interface provided by the KYC authentication center via HTTP / HTTPS protocol. The request parameters include the user identity, request timestamp, and system signature. The asynchronous mode is used to decouple the verification logic, avoid blocking the main process due to the KYC center's response delay, improve system throughput, generate a unique KYC verification request ID, associate it with the cross-chain request object, record the KYC verification status in memory or database, start a timeout timer, and terminate the process if no result is returned before the timeout.

[0079] S2.2: Obtain the verification result returned by the KYC authentication center through an asynchronous callback interface or polling mechanism, parse it into structured data, including fields: status, reason, and timestamp. If status is invalid or timeout, immediately terminate the cross-chain process, record the log (including user identifier and reason for failure), and return a KYC verification failure notification to the user through the application layer, mark the failed request, and trigger the risk audit process.

[0080] S2.3: Extract the source chain asset address from the cross-chain request object, call the smart contract deployed on the regulatory chain through the blockchain node interface, execute the checkBlacklist(address) function, and pass the source chain address as a parameter. The regulatory contract internally maintains a dynamically updated blacklist database to store risky addresses; it supports fuzzy matching rules, such as triggering 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, and an alert is sent to the regulatory node. The matched address is then tracked on-chain, its historical transaction records are correlated, and in-depth risk analysis is triggered.

[0081] S2.4: Compliance verification is deemed successful only if the following conditions are met simultaneously: the KYC verification result is valid, the source chain address is not on the blacklist, a compliance token with an encrypted signature is generated, including the fields: user identifier, verification pass timestamp, KYC credential hash, and blacklist query result hash, which is signed with the system private key to ensure immutability, and the compliance token is attached to the cross-chain request object as an access credential to the protocol layer. If any verification fails, the process terminates and resources are released, and sensitive information of failed requests is encrypted and archived in compliance with data retention regulations.

[0082] In a preferred embodiment of the present invention, step S3 above may include:

[0083] S3.1: Based on the generated compliance verification result, extract the asset information hash digest and the encrypted signature compliance token;

[0084] S3.2: Generate cross-chain transaction proposals based on compliance tokens. Core parameters: source chain asset freeze amount, target chain unlock address, and cross-chain transaction unique identifier;

[0085] S3.3: Call the zero-knowledge proof engine to perform the following operations, with the following input parameters: asset information hash digest plus cross-chain transaction unique identifier, construct verifiable proof: transaction amount, user original address, compliance token validity signature and target chain ID, and generate chain-verifiable proof certificate.

[0086] In this embodiment of the invention, by extracting the asset information hash digest and the encrypted signature compliance token from the compliance verification result, it is ensured that only compliant transactions enter the cross-chain process, blocking the subsequent processing of illegal transactions from the source. Based on the compliance token, core parameters for cross-chain transactions are generated, and a unique identifier enables full-cycle tracking of transactions. Combined with the precise mapping between the frozen amount on the source chain and the unlocking address on the target chain, the accuracy of cross-chain asset transfers is guaranteed. When calling the zero-knowledge proof engine, the hash digest and unique identifier are used as input parameters, hiding sensitive information such as transaction amount and user address within the proof structure. Simultaneously, the validity and compliance of the proof are ensured by embedding the compliance token signature, allowing the target chain to complete verification without obtaining the original data. This satisfies the privacy protection requirements of cross-chain communication and constructs a decentralized trust mechanism through chain-verifiable proof credentials, improving the security and regulatory compatibility of cross-chain transactions.

[0087] In this embodiment of the invention, the specific steps include:

[0088] S3.1: From the compliance verification pass result passed from the application layer, the following key data is parsed out:

[0089] Asset information: including source chain asset type, quantity, target chain asset type, etc.;

[0090] Compliance token: This is the encrypted signature token generated in step S2.4, which contains compliance proofs such as user identity verification results and blacklist screening results.

[0091] The asset information is structured and processed using cryptographic hash functions to ensure data integrity. The digital signature of the compliance token is verified to ensure that the token has not been tampered with and is within its validity period.

[0092] S3.2: Extract the source chain asset exchange quantity from the asset information, and calculate the actual frozen amount based on the cross-chain transaction fee 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, it will be extracted directly; if not specified, the system will automatically generate a temporary target chain address and associate it with the user's account to ensure asset traceability.

[0093] A combined generation strategy is adopted: ,in, It is a millisecond-level timestamp. It is a 128-bit random number (binary), that is, , It is the hash value (binary) of the source chain address, calculated using a hash function. It is a string concatenation operation that joins the three parts in order to form a unique identifier.

[0094] S3.3: Select a proof scheme based on the target chain compatibility, such as:

[0095] Groth16: Suitable for chains that support pre-compiled verification contracts, with high proof generation efficiency;

[0096] PLONK / STARK: Suitable for scenarios requiring resistance to quantum attacks or dynamic trusted setups.

[0097] Input parameter processing:

[0098] Public inputs: asset information hash digest, cross-chain transaction unique identifier (TXID), used by the target chain to verify the correlation between the proof and the on-chain event;

[0099] Private inputs: transaction amount, user's original address, compliance token validity signature, target chain ID.

[0100] Proof construction process:

[0101] Parameter initialization: Call the setup function of the proof engine to generate a common reference string for proof generation and verification (only needs to be executed once, and can be reused);

[0102] Evidence generation: By inputting private data into the `prove` function and combining it with public input, a proof of π is generated. The proof includes:

[0103] The transaction amount was matched with the asset information hash.

[0104] User address is verified via KYC (proven by compliance token signature);

[0105] The target chain ID matches the request.

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

[0107] In a preferred embodiment of the present invention, step S4 above may include:

[0108] 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 relay-notary collaborative listening;

[0109] S4.2: The notary issues a freeze timeout certificate, the routing node terminates the process and returns a failure notification to the application layer, extracts the generated ZKP proof certificate, and calls the ZKP verification contract of the target chain. The input parameters include: public fields, the source chain block height contained in the event, and the notary's confirmation signature on the event.

[0110] S4.3: When the ZKP verification contract returns Proof_Invalid, the routing node sends a proof failure alert to the protocol layer, carrying a snapshot of the current source chain state. The protocol layer then re-triggers step S3.3 to generate an updated ZKP proof.

[0111] In this embodiment of the invention, a relay-notary collaboration mechanism between nodes across chains enables real-time monitoring and reliable verification of source chain asset freezing events: the relay continuously tracks the block confirmation status, and the notary issues authoritative proofs in timeout scenarios to terminate invalid processes and avoid long-term resource occupation; after successful asset freezing, the target chain dynamically verifies the proof certificate through a ZKP verification contract. When the proof fails due to inter-chain state delays, the routing node captures the anomaly in real time and triggers the protocol layer to regenerate and update the proof, ensuring the consistency between cross-chain transactions and on-chain states. This mechanism not only enhances the attack resistance and fault tolerance of cross-chain operations through multi-party collaborative consensus but also solves the verification failure problem caused by time differences in traditional static zero-knowledge proofs through a dynamic proof update mechanism, significantly improving the success rate and system robustness of cross-chain processes and providing reliable execution guarantees for cross-chain asset transfers in complex network environments.

[0112] In this embodiment of the invention, the specific steps include:

[0113] S4.1: Serialize the cross-chain transaction proposal generated in step S3 into a transaction package and broadcast it to the preset cross-chain routing node cluster (e.g., 10 distributed nodes) through the P2P network. Each routing node deploys a relay program to subscribe to specific events through the source chain API. The listening range is the current block height ±1000. The relay continuously monitors the number of source chain block confirmations and records the precise timestamp of the event. The routing node randomly selects 3-5 notary nodes to form a temporary committee to confirm the monitored events through a multi-signature mechanism. The notary nodes independently verify the authenticity of the events.

[0114] S4.2: If no successful asset freeze event is detected within the preset time, the notary committee will issue a FreezeTimeoutProof through the consensus mechanism, which includes:

[0115] Timeout timestamp, monitored block range, and set of signatures of participating notaries;

[0116] The routing node writes the proof into the cross-chain state contract, terminates the process, and returns a failure notification via the application layer API.

[0117] If the asset freeze is successful, the routing node extracts the ZKP proof credential and constructs the verification parameters:

[0118] Public fields: Asset information hash digest, TXID;

[0119] Source chain block height: The block number where the event occurred;

[0120] Notary's signature: Multiple signatures on the event;

[0121] The verifyProof function is executed by calling the pre-deployed ZKP verification contract through the target chain's RPC interface.

[0122] ,in, Public input set, It is a zero-knowledge proof credential, generated by the ZKP engine. It is the source chain block height, i.e., the block number at the time the asset freeze event occurred. It is a collection of notary signatures.

[0123] S4.3: The target chain verification contract returns the following results: Proof_Valid: Continue to execute step S5 and Proof_Invalid: Trigger the proof invalidation process.

[0124] The routing node immediately calls the source chain API to obtain a snapshot of the current state, including:

[0125] Latest block height, asset contract balance, event log;

[0126] The ProofExpiredAlert is sent to the protocol layer via an internal message queue, carrying: the expired TXID, the state snapshot hash, and the reason for the verification failure.

[0127] After receiving the alarm, the protocol layer extracts the current source chain state data and re-executes step S3.3:

[0128] Input parameters: new asset information hash, original TXID;

[0129] Use the ZKP engine to generate the updated proof;

[0130] The new proof is returned to the routing node, re-triggering the target chain verification process.

[0131] In a preferred embodiment of the present invention, step S5 may include:

[0132] S5.1: Analyze 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 notarized signature, and target chain unlock address and asset identifier;

[0133] S5.2: Construct an executable unlock command for the target chain and broadcast the unlock command through a notary multi-signature mechanism: The routing node distributes the command to the preset notary cluster and after verification by more than 2 / 3 of the notaries, it adds a multi-signature to the command to obtain the execution result of the target chain being monitored;

[0134] S5.3: Based on the feedback of the execution results and exception handling, obtain the corresponding asset unlocking operation.

[0135] In this embodiment of the invention, the validity and integrity of key elements are ensured by parsing cross-chain state proofs, providing a credible basis for the target chain unlocking operation. A notary multi-signature mechanism is adopted when constructing the unlocking instruction, enhancing the authority and resistance to attacks through distributed consensus, avoiding operational failures caused by malicious actions of a single node or single point of failure. After the instruction is broadcast, the execution result of the target chain is monitored in real time, and anomaly handling is implemented to ensure the atomicity and eventual consistency of asset unlocking. This mechanism not only constructs a decentralized trust system through cryptographic proofs and multi-party collaboration, but also ensures the security, reliability, and closed-loop process of cross-chain asset transfer through refined instruction execution control and anomaly feedback links, effectively solving the technical problems of unreliable unlocking operations and weak trust mechanisms in traditional cross-chain systems.

[0136] In this embodiment of the invention, the specific steps include:

[0137] S5.1: The routing node receives the cross-chain state proof generated by the cloud, which includes:

[0138] ZKP proof credentials: Zero-knowledge proofs generated in step S4;

[0139] Notary signature set: multi-signature of the source chain AssetFrozen event;

[0140] Target chain information: unlock address, asset identifier.

[0141] Verify the validity of the ZKP proof (by calling the verification contract pre-deployed on the target chain), confirm the notary signature threshold (e.g., ≥2 / 3 of the quorum), extract the public input from the ZKP proof, parse the public key corresponding to the notary signature, verify whether it belongs to the preset whitelist, extract the target chain unlock address and asset identifier, and verify the format legality.

[0142] S5.2: Instruction format definition, notary public multi-signature process:

[0143] Command distribution: The routing node synchronizes the command to the preset notary cluster (e.g., 7 nodes);

[0144] Each notary public independently verifies:

[0145] ZKP proves validity;

[0146] The correlation between source chain events and target chain operations;

[0147] The amount unlocked matches the amount frozen.

[0148] Multi-signature: When ≥2 / 3 of the notaries (e.g., 5 / 7) have verified the information, each notary will sign the instruction using ECDSA and the signatures will be aggregated into an M-of-N multi-signature.

[0149] The routing node will broadcast instructions carrying multi-signatures to the target chain network, subscribe to the AssetUnlocked event through the target chain's RPC interface, and set a timeout listener (e.g., 30 minutes).

[0150] S5.3: Listen for target chain block confirmation, capture the AssetUnlocked event, and verify the consistency between the event parameters and the unlock command.

[0151] Once the target chain is confirmed to have executed successfully (e.g., 3 blocks confirmed), the routing node:

[0152] Update the cross-chain transaction status to Completed;

[0153] Notify users via application layer APIs (such as push notifications and SMS messages);

[0154] The final state is written to the regulatory node for record-keeping.

[0155] Timeout: If the unlock event is not captured within the timeout period, the routing node will not execute the following:

[0156] Triggering a rollback mechanism (such as unfreezing source chain assets);

[0157] Initiate an investigation request to the notary public cluster and generate a failure report.

[0158] If the AssetUnlockFailed event is captured, analyze the reason for the failure and handle it accordingly:

[0159] Insufficient balance: Triggers cross-chain asset replenishment process;

[0160] Permission error: Reconstruct the command or change the account with permissions.

[0161] In a preferred embodiment of the present invention, step S6 may include:

[0162] S6.1: Based on the cross-chain completion certificate captured by the privacy protection module, extract the following audit basic elements from it: the transaction hash value of the target chain unlocking operation, the compliant timestamp encrypted evidence, and the set of public fields in the constructed ZKP proof;

[0163] S6.2: Constructing limited audit documents based on audit elements: transaction timestamp field, compliance status field, transaction amount field, and counterparty address;

[0164] S6.3: Open a targeted audit channel to regulatory nodes: verify the identity of the requesting node to match the preset whitelist of regulatory node certificates, and return structured audit credentials through the encrypted data interface;

[0165] S6.4: Implement full-cycle privacy protection based on the returned structured audit credentials: transaction amount query, counterparty identification, isolated storage of sensitive fields, and public blockchain data.

[0166] In this embodiment of the invention, the privacy protection module accurately captures the basic audit elements in the cross-chain completion certificate. While ensuring the traceability of basic information required for regulation, it avoids directly exposing sensitive data such as transaction amount and counterparty address. When constructing limited audit certificates, a field-level disclosure strategy is adopted, opening a targeted encrypted channel only to regulatory nodes verified through the certificate whitelist, realizing transparent auditing of transaction timestamps and compliance status. At the same time, core privacy information is continuously hidden through sensitive field isolation storage technology. The full-cycle privacy protection mechanism, combined with the public data characteristics of blockchain, effectively solves the fundamental conflict between privacy protection and regulatory auditing in traditional cross-chain systems, providing a secure and controllable audit solution for compliant financial scenarios.

[0167] In this embodiment of the invention, the specific steps include:

[0168] S6.1: Credential Capture: The privacy protection module captures the credentials for cross-chain transaction completion in real time by listening to smart contract events on the target chain. These credentials contain a unique transaction hash value for the target chain's unlocking operation.

[0169] Compliance timestamp extraction: Retrieve the encrypted timestamp (such as the KYC verification pass time) from the compliance verification records of the cross-chain process. This timestamp has been encrypted with the public key of the regulatory node to ensure that it cannot be tampered with.

[0170] ZKP Public Field Parsing: Extract public input fields from the zero-knowledge proof generated in step S3, such as non-sensitive data like asset information hash digests and cross-chain transaction unique identifiers (TXIDs).

[0171] S6.2: Field Mapping:

[0172] Transaction timestamp: Directly uses the block timestamp of the target chain's unlock event;

[0173] Compliance status: Based on KYC verification results and blacklist screening results, marked as passed or blocked;

[0174] Transaction amount: The actual amount is encrypted (e.g., using a commitment mechanism), and only verifiable proof of the amount range is provided to the regulatory node;

[0175] Counterparty address: Convert the user's actual address into an anonymous identifier, retaining the minimum relevant information required for audit traceability.

[0176] The above fields are integrated into a standardized format, and metadata such as timestamps and voucher version numbers are added to form a structured data package that can be audited.

[0177] S6.3: When a supervisory node initiates an audit request, the system verifies its identity in the following ways:

[0178] Check if the digital certificate of the requesting node exists in the preset whitelist;

[0179] Verify the validity of the certificate.

[0180] Encrypted audit credentials are returned to verified regulatory nodes via a secure communication protocol, ensuring that data cannot be stolen or tampered with during transmission.

[0181] S6.4: Regulatory nodes can only obtain encrypted commitments or range proofs of the amount. To verify the specific amount, zero-knowledge proof technology must be used to avoid exposing the real value. The counterparty's address is presented in pseudonym form. The mapping relationship between the real address and the pseudonym is stored in shards by multiple secure computing nodes. Decryption requires the collaboration of at least 2 / 3 of the regulatory nodes. Sensitive fields such as transaction amount and real address are stored in an independent encrypted database, isolated from the public data on the blockchain. The blockchain only records non-sensitive information such as transaction hashes and timestamps. Data displayed on public channels such as blockchain explorers hides the last few digits of the amount and part of the address characters to reduce the risk of privacy leakage.

[0182] like Figure 2 As shown, embodiments of the present invention also provide a method, system, device, and storage medium for cross-chain communication and privacy protection based on a multi-level architecture, including:

[0183] The acquisition module is used by the application layer to receive cross-chain asset exchange requests initiated by users through the first blockchain network. The requests include source chain asset information, target chain asset information, and user identity identifiers. The application layer performs KYC anti-money laundering verification based on the user identity identifiers and verifies whether the source chain asset address exists in a preset blacklist to obtain a compliance verification result.

[0184] The update module is used by the protocol layer to generate cross-chain transaction proposals in response to compliance verification results, and to construct verifiable proofs based on zero-knowledge proof technology. Based on the verifiable proofs, the cross-chain nodes send asset freeze instructions to the source chain. The cross-chain nodes use a relay and notary collaboration mechanism to monitor the block confirmation events of the source chain in real time. If no on-chain event of 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 freeze is successful, 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.

[0185] The processing module is used to broadcast unlocking instructions to the target chain based on valid ZKP proofs, triggering the target chain to perform the corresponding asset unlocking operation; after the target chain unlocking operation is completed, the privacy protection module grants limited auditing permissions to regulatory nodes, disclosing only the transaction timestamp and compliance status fields, while continuously hiding the transaction amount and counterparty address information.

[0186] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered 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 in that, The method 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 identifier. S2: The application layer performs KYC anti-money laundering verification based on the user identity identifier and verifies whether the source chain asset address exists in the preset blacklist in order to obtain a compliance verification result; 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. S4: Based on verifiable proof, the cross-chain node sends an asset freeze command to the source chain. The cross-chain node uses a relay and notary collaboration mechanism to monitor the block confirmation event of the source chain in real time. If no on-chain event of successful asset freeze 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 freeze is successful, 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 unlock instructions to the target chain based on valid ZKP proofs, triggering the target chain to perform the corresponding asset unlocking operation; S6: After the target chain unlocking operation is completed, the privacy protection module grants limited audit permissions to regulatory nodes, disclosing only the transaction timestamp and compliance status fields, while continuously hiding 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, 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 identification, 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 identifier.

3. The cross-chain communication and privacy protection method based on a multi-level architecture according to claim 2, characterized in that, The application layer performs KYC (Know Your Customer) anti-money laundering verification based on the user's identity identifier 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 identifier from the generated cross-chain request object and send an asynchronous verification request to the KYC authentication center to obtain the credential verification result; S2.2: Receive the credential verification result returned by the KYC authentication 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 database. If the address matches the blacklist rule, terminate the process and mark it as blacklisted for blocking. S2.4: Generate a compliance verification pass result if and only if KYC verification passes and blacklist screening fails.

4. The cross-chain communication and privacy protection method based on a multi-level architecture according to claim 3, characterized in that, 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, including: S3.1: Based on the generated compliance verification result, extract the asset information hash digest and the encrypted signature compliance token; S3.2: Generate cross-chain transaction proposals based on compliance tokens. Core parameters: source chain asset freeze amount, target chain unlock address, and cross-chain transaction unique identifier; S3.3: Call the zero-knowledge proof engine to perform the following operations, with the following input parameters: asset information hash digest plus cross-chain transaction unique identifier, construct verifiable proof: transaction amount, user original address, compliance token validity signature and target chain ID, and generate chain-verifiable proof certificate.

5. The cross-chain communication and privacy protection method based on a multi-level architecture according to claim 4, characterized in that, Based on verifiable proofs, the cross-chain node sends an asset freeze command to the source chain. The cross-chain node employs a relay and notary collaboration mechanism to monitor block confirmation events on 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 terminates and returns a failure notification to the application layer. Upon successful asset freezing, 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 relay-notary collaborative listening; S4.2: The notary issues a freeze timeout certificate, the routing node terminates the process and returns a failure notification to the application layer, extracts the generated ZKP proof certificate, and calls the ZKP verification contract of the target chain. The input parameters include: public fields, the source chain block height contained in the event, and the notary's confirmation signature on the event. S4.3: When the ZKP verification contract returns Proof_Invalid, the routing node sends a proof failure alert to the protocol layer, carrying a snapshot of the current source chain state. The protocol layer then 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, characterized in that, Based on a valid ZKP proof, an unlocking command is broadcast to the target chain, triggering the target chain to perform the corresponding asset unlocking operation, including: S5.1: Analyze 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 notarized signature, and target chain unlock address and asset identifier; S5.2: Construct an executable unlock command for the target chain and broadcast the unlock command through a notary multi-signature mechanism: The routing node distributes the command to the preset notary cluster and after verification by more than 2 / 3 of the notaries, it adds a multi-signature to the command to obtain the execution result of the target chain being monitored; S5.3: Based on the feedback of the execution results and exception handling, obtain the corresponding asset unlocking operation.

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

8. A cross-chain communication and privacy protection system based on a multi-level architecture, wherein the system implements the method as described in any one of claims 1 to 7, characterized in that, include: The acquisition module is used by the application layer to receive cross-chain asset exchange requests initiated by users through the first blockchain network. The requests include source chain asset information, target chain asset information, and user identity identifiers. The application layer performs KYC anti-money laundering verification based on the user identity identifiers and verifies whether the source chain asset address exists in a preset blacklist to obtain a compliance verification 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 verifiable proofs based on zero-knowledge proof technology. Based on verifiable proofs, the cross-chain node sends an asset freeze command to the source chain. The cross-chain node uses a relay and notary collaboration mechanism to monitor the block confirmation event of the source chain in real time. If no on-chain event of successful asset freeze 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 freeze is successful, 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 unlocking instructions to the target chain based on valid ZKP proofs, triggering the target chain to perform the corresponding asset unlocking operation; after the target chain unlocking operation is completed, the privacy protection module grants limited auditing permissions to regulatory nodes, disclosing only the transaction timestamp and compliance status fields, while continuously hiding 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, which, when executed by one or more processors, cause the one or more processors to implement the method as described in any one of claims 1 to 7.

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

Images