A DDoS cross-chain cooperative defense method, system, device, medium and terminal

Abstract

This invention belongs to, but is not limited to, the field of network security technology, and particularly relates to a DDoS cross-chain collaborative defense method, system, device, medium, and terminal, comprising: a source chain node: used to monitor external traffic, perform local rapid detection, construct cross-chain verification requests, and adjust defense strategies based on the feedback results from the target chain; a target chain node: used to receive verification requests, perform blacklist matching on suspicious IPs, generate ZKP proofs, and return the results to the source chain; a relay chain module: serving as a cross-chain communication channel, responsible for forwarding verification requests and responses; a zero-knowledge proof module: embedded in the target chain and source chain nodes, used for ZKP circuit construction and verification, and performing privacy-preserving verification based on a Merkle Tree structure; and a local detection module: integrating a local lightweight machine learning model to achieve preliminary identification of unknown attack traffic.

Description

Technical Field

[0001] This invention belongs to, but is not limited to, the field of network security technology, and particularly relates to a cross-chain collaborative defense method, system, device, medium, and terminal for DDoS attacks. Background Technology

[0002] With the rapid development of the internet and the continuous expansion of its application scenarios, cybersecurity issues are becoming increasingly severe, especially the risk of attacks targeting critical infrastructure networks. In recent years, blockchain technology has attracted widespread attention in the field of cybersecurity due to its decentralized, traceable, and tamper-proof characteristics. Existing research has incorporated blockchain technology into DDoS defense to achieve distributed defense and improve information transparency and credibility.

[0003] Traditional on-chain DDoS defense solutions are mostly limited to a single chain, using blacklist rules, simple rate limiting, or machine learning models for localized defense. This isolated strategy is ill-suited to dealing with covert attacks across domains and platforms. Furthermore, existing collaborative defense solutions often share attack IPs or their hashes directly in plaintext, leading to privacy breaches and signature abuse, making them particularly vulnerable in multi-chain environments.

[0004] Based on the above analysis, the urgent technical problems that need to be solved by existing technologies are: existing on-chain DDoS defense solutions are either limited to a single chain and are isolated, making it difficult to deal with covert attacks across multiple domains and platforms; or existing collaborative solutions share attack information in plaintext or hash, which leads to privacy leaks and feature abuse issues, and are more vulnerable in multi-chain environments.

[0005] In related technologies, patent application CN110113328A proposes a blockchain-based software-defined opportunistic network (SDN) DDoS defense method. This scheme utilizes the centralized control and real-time monitoring capabilities of SDN to perform feature analysis on network traffic and identify the attack source address using a source tracing algorithm. Then, it maintains an attacker blacklist through blockchain, achieving on-chain storage and sharing to assist the application layer in filtering malicious traffic. While this scheme has certain advantages in attack source tracing and blacklist storage, its defense framework is mainly limited to a single-chain environment, lacking a cross-chain collaboration mechanism. Furthermore, the blacklist is stored and disseminated in plaintext, posing risks of privacy leaks and misuse. Patent application CN120050094A proposes a blockchain-based network security protection method and system. This solution generates on-chain digital identities by integrating unique device identifiers with user biometrics, and uses this as the basis for dynamic permission management. It also utilizes adversarial deep learning models for threat detection and leverages smart contracts to dynamically update permission levels. Furthermore, it employs sharded blockchain technology and a relay chain to achieve cross-chain threat intelligence synchronization, and combines threshold signatures and zero-knowledge proof mechanisms to encrypt and verify cross-chain data and permission change records. While this solution demonstrates the advantages of combining cross-chain synchronization and zero-knowledge proofs, it primarily focuses on identity authentication and access control, and does not address cross-chain collaborative defense against DDoS attacks, particularly lacking effective mechanisms for blacklist matching and privacy verification. Summary of the Invention

[0006] To address the problems existing in current technologies, this invention provides a cross-chain collaborative defense method, system, device, and terminal for DDoS attacks. The aim is to overcome the shortcomings of existing on-chain DDoS defense solutions, such as being limited to a single chain, privacy leaks in collaborative defense, and lack of trusted verification. This invention proposes a cross-chain collaborative defense system and method for DDoS attacks based on zero-knowledge proofs. This enables trusted verification and sharing of suspicious IPs between different blockchains without exposing the specific contents of the blacklist. It ensures both the computational correctness and privacy protection of the defense process, and constructs a distributed collaborative defense mechanism for rapid detection, cross-chain verification, and strategy optimization, thereby improving network security protection capabilities in multi-chain environments.

[0007] This invention is implemented as follows: a cross-chain collaborative DDoS defense method, comprising:

[0008] Step 1, System Initialization: Deploy the blockchain network and smart contract environment on the source chain, target chain, and relay chain; deploy local machine learning detection modules and Merkle Tree-based blacklist databases on the source chain and target chain respectively; the target chain calls Setup to generate system parameters and executes KeyGen to obtain the proof key P. k With verification key V kSubsequently, ZKP generation / verification contracts were deployed on the target chain and the source chain, and the corresponding keys were loaded; a cross-chain communication module was deployed on the relay chain to support message and proof transmission.

[0009] Step 2, Local Rapid Response and Suspicious Traffic Identification: The source chain node monitors external requests in real time and first quickly searches through the local blacklist Merkle Tree. If a match is found, the request is blocked and recorded. If no match is found, a lightweight machine learning model is used to determine the source chain. Normal traffic is allowed to pass, while suspicious traffic is packaged into a cross-chain verification request and temporarily cached to wait for the verification result.

[0010] Step 3: Construct and send cross-chain verification request: For suspicious IPs that cannot be confirmed, the source chain generates a salted hash h and constructs a VerificationRequest containing a common input placeholder, feature digest and unique identifier; this request is uploaded to the source chain and forwarded to the target chain by the relay chain for processing.

[0011] Step 4, Target Chain Blacklist Matching and ZKP Construction: The target chain searches in the local blacklist MerkleTree according to the request; if a match is found, the Merkle Tree path is extracted as private input, ProofGen is called to generate a structured zero-knowledge proof π, and it is encapsulated together with the public input as a response message and returned; if no match is found, a miss status is returned directly.

[0012] Step 5, Source Chain Verification and Policy Update: After receiving the response, the source chain calls Verify to verify; if the verification is valid, the corresponding IP is added to the local blacklist to block subsequent access and is used as a training sample to optimize the local model; if the verification fails, the original state is maintained.

[0013] Furthermore, the zero-knowledge proof cross-chain blacklist verification mechanism enables the source chain to verify whether a certain IP in the target chain is on the blacklist without exposing the actual content of the blacklist. The specific process of the zero-knowledge proof cross-chain blacklist verification mechanism is as follows:

[0014] S1: Zero-knowledge proofs and cross-chain adaptive parameter initialization Setup(1) λ →Params

[0015] Set the safety parameter λ, and map e: G1×G2→G t It is a non-degenerate bilinear pair, G tThis is the target group that receives the results of bilinear pairing. G1 and G2 are cyclic groups of order p, each with g1 and g2 as generators. The tree depth, denoted as Tdth, is dynamically calculated based on the actual size of the Merkle tree of the target chain blacklist, replacing the traditional fixed-depth method. This achieves parameter adaptation in cross-chain scenarios, avoiding circuit redundancy or insufficient constraints. The final output parameter set is: Params = (λ, Tdth, G1, G2, G...). t ,g1,g2,e).

[0016] S2: Dynamic Key Generation and Registration for Cross-Chain Authentication KeyGen(Params,C)→(P k V k )

[0017] Given a constraint circuit C, the target chain performs a trust setting based on the constraint circuit C to generate a proof key P. k With verification key V k V k Registering on-chain via smart contracts provides a common input for subsequent cross-chain verification. Smart contracts enable dynamic key management; when the target chain's blacklist is updated, causing a change in the Merkle root, the smart contract registration of the key is automatically triggered. k This ensures that the verification key is synchronized with the latest chain state. This process is automated through contracts, improving the real-time performance and security of cross-chain verification.

[0018] S3: Privacy-preserving blacklist proof generation and optimization ProofGen(P) k (x, w) → π

[0019] The target chain uses P k Generate zero-knowledge proof π. The proof inputs include: public input x = (root, h): where root is the root of the blacklisted Merkle tree, and h is the salted hash of the target IP; private input w = (path, direction): path is the path hash sequence from the target IP hash to the Merkle tree root, and direction corresponds to the direction bit (where the lengths of path and direction should be equal to Tdth to ensure that the path calculation matches the Merkle tree level).

[0020] S4: Verification and Result Feedback (Verify(V)) k (x,π)→rlt

[0021] After receiving the proof π, the source link calls V through the on-chain verification contract. kPerform a verification operation on the proof π. The common input x = (root, h) must be synchronized with the latest state of the target chain. If π is valid, the output result rlt = 1, indicating that the IP exists in the target chain's blacklist; otherwise, rlt = 0, indicating a miss or invalid proof.

[0022] Furthermore, step one specifically includes:

[0023] 1.1 Blockchain Network Deployment: Complete node deployment on the source chain, target chain, and relay chain to establish a smart contract execution environment;

[0024] 1.2 Deploy local detection modules: Deploy local machine learning detection modules on the source chain and target chain respectively, and generate a local blacklist database based on historical data (using a Merkle tree structure for storage, supporting root verification and path extraction).

[0025] 1.3 System parameter initialization: The target chain node calls Setup(1) λ Set the global security parameter λ, and set the non-degenerate bilinear pair e: G1×G2→G t The Merkle tree depth Tdth is fixed during initialization to ensure the validity of the circuit structure and the consistency of the path length. The global parameter set is output as: Params = (λ, Tdth, G1, G2, g1, g2, e).

[0026] 1.4 Generating the Proof Key and Verification Key: The target chain executes KeyGen(Params, C) to generate the proof key P. k and verification key V k V k By uploading smart contracts to the blockchain, they can be invoked during cross-chain verification of the source chain;

[0027] 1.5 Deploying Zero-Knowledge Proof Contracts: Deploying ZKP Generation Contracts (ProofGen(P)) on the Target Chain k ,x,w)), and load the proof key P k ; Deploy ZKP verification contract (Verify(V)) on the source chain k ,x,π)), and load the verification key V k .

[0028] 1.6 Deploy cross-chain communication module: Deploy cross-chain communication relay module in the relay chain to realize message and proof transmission between the source chain and the target chain.

[0029] Furthermore, step three specifically includes:

[0030] 3.1 When the source chain node cannot confirm whether the target IP is in the local blacklist, it sends the suspicious IP to the target chain for verification;

[0031] 3.2 Package the suspicious IP address into a cross-chain verification request (VerificationRequest).

[0032] The verification request includes the following details:

[0033] IP salting sequence h = SHA256(IP_address + salt) is used to prevent joint analysis and original IP tracing, where salt = nonce||source_chainID||timestamp;

[0034] Attack signature summary meta: {src_port, dst_port, freq, timestamp};

[0035] Unique identifier: UUID; Initiation timestamp;

[0036] 3.3 Once constructed, the request is uploaded to the blockchain via the source chain smart contract and forwarded by the relay chain node;

[0037] 3.4 The relay chain will analyze the request content and broadcast it to the target chain node group asynchronously.

[0038] Furthermore, step four specifically includes:

[0039] 4.1 After receiving the verification request, the target link extracts the hash value h and checks if it exists in the local blacklist Merkle Tree;

[0040] 4.2 If a match is found, execute the following proof generation process:

[0041] 4.2.1 Record the corresponding Merkle path, including the hash sequence from the leaf node to the root node and the direction bit;

[0042] 4.2.2 Calling ProofGen(Pk,x,w) → π:

[0043] 4.2.2.1 Common input x = (root, h), where root is the current blacklist Merkle Tree root, and h is the salted hash of the target IP.

[0044] 4.2.2.2 Private input w = (path, direction), with the same length as Tdth;

[0045] 4.2.2.3 Circuit verification to determine if h can be reconstructed as root using path and direction;

[0046] 4.2.2.4 Generating Structured Zero-Knowledge Proofs of π

[0047] 4.2.3 Encapsulate π, x, target chain ID, etc. into a VerificationResponse and return it to the source chain through the relay chain;

[0048] 4.3 If a miss occurs, return a "miss" status code.

[0049] Furthermore, step five specifically includes:

[0050] 5.1 After receiving the VerificationResponse, the source chain calls the verification contract interface to perform the verification operation;

[0051] 5.2 Input proofs for π and x, then call Verify(V k (x,π)→rlt, determine whether the verification passes;

[0052] 5.2.1 If rlt = 1, it means that the IP corresponding to h exists in the target chain blacklist, and the following operation is performed:

[0053] Add h to the local blacklist Merkle Tree;

[0054] Block subsequent connection requests from this IP address and record the blocking event on the blockchain.

[0055] The event is used as a labeled sample input into the local ML model to assist in incremental training;

[0056] 5.2.2 If verification fails, no action will be taken, and the original state will be retained;

[0057] Another objective of this invention is to provide a DDoS cross-chain collaborative defense system for implementing the aforementioned DDoS cross-chain collaborative defense method, comprising:

[0058] Source chain node: Used to monitor external traffic, perform local fast detection, construct cross-chain verification requests, and adjust defense strategies based on the feedback results from the target chain;

[0059] Target chain node: Used to receive verification requests, match suspicious IPs against a blacklist, generate ZKP proofs, and return the results to the source chain;

[0060] Relay Chain Module: Serves as a cross-chain communication channel, responsible for verifying the forwarding of requests and responses;

[0061] Zero-knowledge proof module: Embedded in the target chain and source chain nodes, used for ZKP circuit construction and verification, and performs privacy-preserving verification based on the Merkle Tree structure;

[0062] Local detection module: Integrates a local lightweight machine learning model to achieve preliminary identification of unknown attack traffic.

[0063] Another object of the present invention is to provide a computer device, the computer device including a memory and a processor, the memory storing a computer program, which, when executed by the processor, causes the processor to perform the steps of the DDoS cross-chain collaborative defense method.

[0064] Another object of the present invention is to provide a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the DDoS cross-chain collaborative defense method.

[0065] Another objective of this invention is to provide an information data processing terminal, which includes the aforementioned DDoS cross-chain collaborative defense system.

[0066] Based on the above technical solutions and the technical problems solved, the advantages and positive effects of the technical solution to be protected by this invention are as follows:

[0067] This invention combines the triple advantages of ZKP—computational correctness, privacy protection, and collaborative verifiability—with the requirements of DDoS distributed defense, forming a closed-loop defense system that integrates rapid detection, trusted verification, and network-wide optimization.

[0068] This invention effectively avoids privacy leaks caused by publicly available data, a problem inherent in traditional defense solutions, by combining local rapid identification with asynchronous ZKP cross-chain verification. The system encapsulates blacklist data across different chains using a Merkle structure, achieving highly reliable collaborative judgment without exposing IP addresses, and dynamically adjusting strategies and optimizing models based on verification results.

[0069] This invention utilizes the zk-SNARK structured proof mechanism to design a zero-knowledge proof cross-chain blacklist verification mechanism. By encapsulating the blacklist as a Merkle Tree and combining it with the ZKP mechanism, the source chain can verify whether an IP in the target chain is on the blacklist without exposing the actual content of the blacklist. Based on this, a zero-knowledge proof-based DDoS cross-chain collaborative defense system is proposed, which divides the defense process into local fast response and asynchronous cross-chain verification, balancing real-time performance and collaborative security, and avoiding privacy risks caused by plaintext data interaction.

[0070] This invention has the following significant advantages:

[0071] Privacy protection: Blacklist hit verification is implemented through ZKP circuits to avoid leakage of plaintext IP characteristics;

[0072] Verifiability: The source chain can verify the proof generated by the target chain to ensure the credibility of the collaborative result;

[0073] Highly scalable: Supports multi-chain deployment, modular structure, and flexible expansion of inter-chain communication and policy linkage;

[0074] Performance optimization: ZKP proofs have a fixed size, low verification time, and high system response efficiency;

[0075] Decentralized trust mechanism: Cross-chain trust is achieved through verification keys registered on the blockchain, eliminating the need for centralized management.

[0076] (1) The technical solution of this invention fills a technical gap in the industry both domestically and internationally:

[0077] Existing DDoS defense technologies achieve blacklist sharing within a single chain, posing a risk of privacy breaches; or they achieve cross-chain data synchronization but lack a privacy-provable blacklist verification mechanism, failing to balance trustworthiness and privacy. This invention deeply integrates ZKP with a cross-chain blacklist verification process, enabling the source chain to verify whether an entry matches the target chain's blacklist without directly accessing the target chain's entries. This fills the technological gap of "cross-chain collaborative verification without disclosing blacklist content." In complex protection environments involving multiple chains and multiple stakeholders, this invention provides an auditable and verifiable collaboration model between different blockchains, overcoming the limitations of traditional defense systems.

[0078] (2) The technical solution of the present invention solves a technical problem that people have long wanted to solve but have never been able to solve successfully:

[0079] In a distributed, trustless multi-chain environment, this invention achieves efficient and privacy-secure collaborative defense. Specifically, traditional solutions, to guarantee the credibility of cross-chain verification, must sacrifice privacy (transmitting data in plaintext) or performance (bearing enormous on-chain computational overhead); while pursuing privacy protection often requires the introduction of centralized institutions, violating the trustless principle of blockchain. This invention, through a clever combination of zero-knowledge proofs and Merkle trees, successfully solves this problem at the engineering level. It allows the holder of massive blacklist data (the target chain) to prove the authenticity of an assertion (IP hit) to the verifier (the source chain) without disclosing any sensitive information. Simultaneously, the verifier requires only minimal, fixed on-chain computational overhead to complete the verification, providing crucial technical support for building a truly usable cross-chain secure collaborative infrastructure. Attached Figure Description

[0080] Figure 1 This is a schematic diagram of the solution architecture provided in the embodiments of the present invention;

[0081] Figure 2 This is a schematic diagram of the zero-knowledge proof cross-chain blacklist verification mechanism provided in an embodiment of the present invention;

[0082] Figure 3This is a schematic diagram of the defense system process provided in an embodiment of the present invention;

[0083] Figure 4 This is a schematic diagram comparing defense latency provided in an embodiment of the present invention;

[0084] Figure 5 This is a schematic diagram comparing the defense success rate provided in an embodiment of the present invention. Detailed Implementation

[0085] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0086] The purpose of this invention is to overcome the shortcomings of existing on-chain DDoS defense schemes, such as being limited to a single chain, privacy leaks in collaborative defense, and lack of trusted verification. This invention proposes a cross-chain collaborative DDoS defense system and method based on zero-knowledge proofs (e.g., Figure 1 This enables trusted verification and sharing of suspicious IPs across different blockchains without exposing the specific contents of the blacklist. It ensures both the computational correctness and privacy protection of the defense process, and constructs a distributed collaborative defense mechanism for rapid detection, cross-chain verification, and strategy optimization, thereby improving network security protection capabilities in a multi-chain environment.

[0087] The basic principle of the DDoS cross-chain collaborative defense method and system of this invention lies in achieving rapid identification and defense against distributed denial-of-service attacks in a cross-chain environment through the coordinated operation of the source chain, target chain, and relay chain. During the initialization phase, the system deploys the blockchain network and smart contract environment, and loads zero-knowledge proof modules and local detection modules onto the target chain and source chain, respectively. The target chain generates system parameters and verification keys through Setup and KeyGen, while the source chain registers the corresponding verification contract and key. The relay chain deploys a cross-chain communication module to support the transmission of messages and proofs, thus laying the foundation for subsequent defense processes.

[0088] During the local detection phase, source chain nodes monitor external traffic in real time. If a requesting IP address matches the local Merkle tree blacklist, it is immediately blocked and recorded; if not, a lightweight machine learning model is invoked for judgment. Normal traffic is allowed to pass directly, while suspicious traffic is marked and further packaged into a cross-chain verification request. This mechanism ensures the efficiency and tiered processing capabilities of the defense, enabling the source chain to filter out the vast majority of known attack traffic in advance.

[0089] When the source chain generates a cross-chain verification request, it salts and hashes the target IP address, attaching an attack signature digest, a unique identifier, and a timestamp to construct a complete verification request. This request is first written into the source chain's smart contract, then listened to by relay chain nodes and forwarded to the target chain. The relay chain uses an asynchronous broadcast mechanism to ensure that messages are reliably transmitted to the target chain's node group, avoiding impacts on verification efficiency due to single points of failure or network latency.

[0090] Upon receiving a verification request, the target chain performs a match based on its local blacklist database. If a match is successful, it extracts the Merkle path and direction bits as private input, and uses the IP hash and Merkle root as public input to generate a proof using a zero-knowledge proof mechanism. This proof, along with the public input, is returned to the source chain for subsequent verification. If a match is not found, a "missed" status is returned, thus ensuring that cross-chain verification is completed without revealing the actual blacklist content.

[0091] During the verification phase, the source chain invokes the verification contract and inputs the verification key, public input, and proof for verification. If the verification result is valid, the source chain automatically adds the IP address to its local blacklist, blocking its subsequent access, and uses the attack event as a training sample to input into the local machine learning model for incremental learning and model optimization. If the verification fails, the original state is maintained, and no adjustments are made to the system policy, thus ensuring the rigor of the judgment.

[0092] In scenarios where the blacklist is dynamically updated, the Merkle root node of the target chain changes as the blacklist changes. The target chain node automatically triggers an update mechanism via a smart contract, uploading the new verification key to the chain and recording the updated state in the corresponding block. The source chain always uses the latest verification key during cross-chain verification, ensuring the real-time nature and security of the verification results and avoiding defense vulnerabilities caused by key expiration or root node asynchrony.

[0093] Through the above mechanism, this invention achieves a complete cross-chain defense closed loop: the source chain undertakes local rapid detection and verification request construction, the target chain provides authoritative blacklist verification and zero-knowledge proof support, the relay chain is responsible for secure and efficient cross-chain communication, and the local machine learning model continuously optimizes its recognition capabilities. This closed loop, while ensuring privacy protection, possesses low latency, high accuracy, and evolvability, thereby effectively improving the defense level against DDoS attacks in complex cross-chain environments.

[0094] The system of this invention consists of five parts: source chain node, target chain node, relay chain module, zero-knowledge proof module, and local detection module. These parts cooperate to achieve cross-chain DDoS defense functionality. Specifically:

[0095] (1) Source chain node: used to listen to external traffic, perform local fast detection, construct cross-chain verification requests, and adjust the defense strategy according to the feedback results of the target chain;

[0096] (2) Target chain node: Used to receive verification requests, perform blacklist matching on suspicious IPs, generate ZKP proofs, and return the results to the source chain;

[0097] (3) Relay Chain Module: As a cross-chain communication channel, it is responsible for verifying the forwarding of requests and responses;

[0098] (4) Zero-knowledge proof module: Embedded in the target chain and source chain nodes, used for ZKP circuit construction and verification, and performs privacy-preserving verification based on the Merkle Tree structure;

[0099] (5) Local detection module: integrates a local lightweight machine learning model to achieve preliminary identification of unknown attack traffic.

[0100] This invention utilizes the zk-SNARK structured proof mechanism to design a zero-knowledge proof cross-chain blacklist verification mechanism. This mechanism enables the source chain to verify whether a specific IP address in the target chain is blacklisted without exposing the actual content of the blacklist. The specific process of the zero-knowledge proof cross-chain blacklist verification mechanism is as follows (e.g.) Figure 2 ):

[0101] Step 1: Zero-knowledge proof and cross-chain adaptive parameter initialization Setup(1) λ →Params

[0102] Set the safety parameter λ, and map e: G1×G2→G t It is a non-degenerate bilinear pair, G t This is the target group that receives the results of bilinear pairing. G1 and G2 are cyclic groups of order p, each with g1 and g2 as generators. The tree depth, denoted as Tdth, is dynamically calculated based on the actual size of the Merkle tree of the target chain blacklist, replacing the traditional fixed-depth method. This achieves parameter adaptation in cross-chain scenarios, avoiding circuit redundancy or insufficient constraints. The final output parameter set is: Params = (λ, Tdth, G1, G2, G...). t (g1, g2, e).

[0103] Step 2: Dynamic Key Generation and Registration for Cross-Chain Verification KeyGen(Params, C) → (P k V k )

[0104] Given a constraint circuit C, the target chain performs a trust setting based on the constraint circuit C to generate a proof key P. k With verification key V k V kRegistering on-chain via smart contracts provides a common input for subsequent cross-chain verification. Smart contracts enable dynamic key management; when the target chain's blacklist is updated, causing a change in the Merkle root, the smart contract registration of the key is automatically triggered. k This ensures that the verification key is synchronized with the latest chain state. This process is automated through contracts, improving the real-time performance and security of cross-chain verification.

[0105] Step 3: Privacy-Preserving Blacklist Proof Generation and Optimization (ProofGen(P)) k (x, w) → π

[0106] The target chain uses P k Generate zero-knowledge proof π. The proof inputs include: public input x = (root, h): where root is the root of the blacklisted Merkle tree, and h is the salted hash of the target IP; private input w = (path, direction): path is the path hash sequence from the target IP hash to the Merkle tree root, and direction corresponds to the direction bit (where the lengths of path and direction should be equal to Tdth to ensure that the path calculation matches the Merkle tree level).

[0107] Step 4: Verification and Result Feedback (Verify(V)) k ,x,π)→rlt

[0108] After receiving the proof π, the source link calls V through the on-chain verification contract. k Perform a verification operation on the proof π. The common input x = (root, h) must be synchronized with the latest state of the target chain. If π is valid, the output result rlt = 1, indicating that the IP exists in the target chain's blacklist; otherwise, rlt = 0, indicating a miss or invalid proof.

[0109] Based on the zero-knowledge proof cross-chain blacklist verification mechanism, this invention proposes a zero-knowledge proof-based cross-chain collaborative defense system for DDoS attacks. This system consists of five stages: system initialization → local identification → cross-chain request sending → target chain ZKP generation → source chain verification and response. Each stage is designed with module decoupling, privacy protection, and real-time collaboration as core principles, forming a distributed DDoS collaborative defense closed-loop system with rapid response and privacy protection capabilities. Figure 3 The general steps are as follows:

[0110] Step 1: System Initialization

[0111] The blockchain network and smart contract environment are deployed on the source chain, target chain, and relay chain; the source chain and target chain respectively deploy local machine learning detection modules and Merkle Tree-based blacklist databases; the target chain calls Setup to generate system parameters and executes KeyGen to obtain the proof key P. k With verification key V k Subsequently, ZKP generation / verification contracts were deployed on the target chain and the source chain, and the corresponding keys were loaded; a cross-chain communication module was deployed on the relay chain to support message and proof transmission.

[0112] Step Two: Local Rapid Response and Suspicious Traffic Identification

[0113] The source chain node monitors external requests in real time. It first quickly searches through the local blacklist Merkle Tree. If a match is found, the request is blocked and recorded. If no match is found, a lightweight machine learning model is used to determine the nature of the request. Normal traffic is allowed to pass, while suspicious traffic is packaged into a cross-chain verification request and temporarily cached to wait for the verification result.

[0114] Step 3: Construct and send a cross-chain verification request

[0115] For suspicious IPs that cannot be verified, the source chain generates a salted hash h and constructs a VerificationRequest containing a common input placeholder, a feature digest, and a unique identifier; this request is uploaded to the source chain and forwarded to the target chain by the relay chain for processing.

[0116] Step 4: Target chain blacklist matching and ZKP construction

[0117] The target chain searches the local blacklist Merkle Tree based on the request; if a match is found, the Merkle Tree path is extracted as private input, ProofGen is called to generate a structured zero-knowledge proof π, and the result is encapsulated together with the public input as a response message and returned; if no match is found, a miss status is returned directly.

[0118] Step 5: Source Chain Verification and Policy Update

[0119] After receiving the response, the source chain calls Verify to verify it. If the verification is valid, the corresponding IP is added to the local blacklist to block subsequent access and is used as a training sample to optimize the local model. If the verification fails, the original state is maintained.

[0120] This invention is deployed in a multi-chain collaborative environment consisting of a source chain, a target chain, and a relay chain, and utilizes zero-knowledge proof technology to achieve privacy verification of attack characteristics and policy feedback. The steps of the described zero-knowledge proof-based DDoS cross-chain collaborative defense system scheme include:

[0121] Step 1, System Initialization:

[0122] 1.1 Blockchain Network Deployment: Complete node deployment on the source chain, target chain, and relay chain to establish a smart contract execution environment;

[0123] 1.2 Deploy local detection modules: Deploy local machine learning detection modules on the source chain and target chain respectively, and generate a local blacklist database based on historical data (using a Merkle tree structure for storage, supporting root verification and path extraction).

[0124] 1.3 System parameter initialization: The target chain node calls Setup(1) λ Set the global security parameter λ, and set the non-degenerate bilinear pair e: G1×G2→G t The Merkle tree depth Tdth is fixed during initialization to ensure the validity of the circuit structure and the consistency of the path length. The output global parameter set is: Params = (λ, Tdth, G1, G2, G...). t ,g1,g2,e);

[0125] 1.4 Generating the Proof Key and Verification Key: The target chain executes KeyGen(Params, C) to generate the proof key P. k and verification key V k V k By uploading smart contracts to the blockchain, they can be invoked during cross-chain verification of the source chain;

[0126] 1.5 Deploying Zero-Knowledge Proof Contracts: Deploying ZKP Generation Contracts (ProofGen(P)) on the Target Chain k ,x,w)), and load the proof key P k ; Deploy ZKP verification contract (Verify(V)) on the source chain k ,x,π)), and load the verification key V k .

[0127] 1.6 Deploy cross-chain communication module: Deploy cross-chain communication relay module in the relay chain to realize message and proof transmission between the source chain and the target chain.

[0128] Step 2, Local Rapid Response and Suspicious Traffic Identification:

[0129] 2.1 The source chain node continuously listens for external traffic requests and extracts fields such as access IP, port number, protocol type, and timestamp from the requests;

[0130] 2.2 Call the local MerkleLookup(h) method to check if the IP exists in the locally maintained blacklist Merkle Tree.

[0131] 2.2.1 The design principle of MerkleLookup(h) is as follows:

[0132] 2.2.1.1 The source chain maintains a blacklist Merkle Tree locally, with leaf nodes containing the hash values ​​of all blacklisted IPs;

[0133] 2.2.1.2 Each internal node is a combination of the hash values ​​of its left and right child nodes: node_hash = Hash(left_child||right_child)

[0134] 2.2.1.3 The search process is as follows: The default is a sequential search, that is, using h (the hash value of the IP) as the target, it searches the leaf node list for a complete match;

[0135] 2.3 If MerkleLookup(h) returns "Hit", the IP is determined to be a member of the blacklist, and the following operations are immediately triggered: reject its current connection request; log the blocking event;

[0136] 2.4 If no match is found, continue with the local machine learning detection and discrimination process. Input the traffic information (such as access IP, port number, protocol type, timestamp, etc.) into the model for real-time prediction:

[0137] 2.4.1 If the model determines that the traffic is "normal," then allow it to pass;

[0138] 2.4.2 If the model output is "uncertain" or "suspicious attack", the IP and context information are encapsulated into a verification request and handed over to the asynchronous cross-chain collaboration module for processing;

[0139] 2.4.3 Simultaneously, the suspicious traffic is briefly cached, awaiting the cross-chain verification result from the target chain. If the verification passes, the IP address is added to the local blacklist, and subsequent blocking operations are implemented.

[0140] 2.5 Through the above-mentioned rapid identification mechanism, the system maintains a high real-time judgment capability while building an entry point for subsequent cross-chain verification and cross-chain collaboration of suspicious traffic.

[0141] Step 3: Construct and send a cross-chain verification request:

[0142] 3.1 When the source chain node cannot confirm whether the target IP is in the local blacklist, it sends the suspicious IP to the target chain for verification;

[0143] 3.2 Package the suspicious IP address into a cross-chain verification request (VerificationRequest).

[0144] The verification request includes the following details:

[0145] IP salting sequence h = SHA256(IP_address + salt) is used to prevent joint analysis and original IP tracing, where salt = nonce||source_chainID||timestamp;

[0146] Attack signature summary meta: {src_port, dst_port, freq, timestamp};

[0147] Unique identifier: UUID; Initiation timestamp;

[0148] 3.3 Once constructed, the request is uploaded to the blockchain via the source chain smart contract and forwarded by the relay chain node;

[0149] 3.4 The relay chain will analyze the request content and broadcast it to the target chain node group asynchronously.

[0150] Step 4, Target Chain Local Blacklist Matching and ZKP Construction:

[0151] 4.1 After receiving the verification request, the target link extracts the hash value h and checks if it exists in the local blacklist Merkle Tree;

[0152] 4.2 If a match is found, execute the following proof generation process:

[0153] 4.2.1 Record the corresponding Merkle path, including the hash sequence from the leaf node to the root node and the direction bit;

[0154] 4.2.2 Calling ProofGen(Pk,x,w) → π:

[0155] 4.2.2.1 Common input x = (root, h), where root is the current blacklist Merkle Tree root, and h is the salted hash of the target IP.

[0156] 4.2.2.2 Private input w = (path, direction), with the same length as Tdth;

[0157] 4.2.2.3 Circuit verification to determine if h can be reconstructed as root using path and direction;

[0158] 4.2.2.4 Generating Structured Zero-Knowledge Proofs of π

[0159] 4.2.3 Encapsulate π, x, target chain ID, etc. into a VerificationResponse and return it to the source chain through the relay chain;

[0160] 4.3 If a miss occurs, return a "miss" status code.

[0161] Step 5: Verify ZKP on the source chain and execute policy update:

[0162] 5.1 After receiving the VerificationResponse, the source chain calls the verification contract interface to perform the verification operation;

[0163] 5.2 Input proofs for π and x, then call Verify(V k (x,π)→rlt, determine whether the verification passes;

[0164] 5.2.1 If rlt = 1, it means that the IP corresponding to h exists in the target chain blacklist, and the following operation is performed:

[0165] Add h to the local blacklist Merkle Tree;

[0166] Block subsequent connection requests from this IP address and record the blocking event on the blockchain.

[0167] The event is used as a labeled sample input into the local ML model to assist in incremental training;

[0168] 5.2.2 If verification fails, no action will be taken, and the original state will be retained;

[0169] Through the detailed implementation steps described above, this invention combines the three advantages of ZKP—computational correctness, privacy protection, and collaborative verifiability—with the requirements of DDoS distributed defense, forming a closed-loop defense system that integrates rapid detection, trusted verification, and network-wide optimization.

[0170] This invention effectively avoids privacy leaks caused by publicly available data, a problem inherent in traditional defense solutions, by combining local rapid identification with asynchronous ZKP cross-chain verification. The system encapsulates blacklist data across different chains using a Merkle structure, achieving highly reliable collaborative judgment without exposing IP addresses, and dynamically adjusting strategies and optimizing models based on verification results.

[0171] An application embodiment of the present invention provides a computer device, which includes a memory and a processor. The memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of a cross-chain collaborative defense method against DDoS attacks.

[0172] An application embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of a cross-chain collaborative defense method for DDoS attacks.

[0173] An application embodiment of the present invention provides an information data processing terminal, which includes a DDoS cross-chain collaborative defense system.

[0174] This embodiment embeds the zero-knowledge proof-based cross-chain collaborative defense system of the present invention into a cloud-edge scenario to achieve joint defense across data centers. In cloud computing and edge computing platforms, there is typically a two-tier architecture of "core cloud data center – edge node." Edge nodes are located closer to the user side and are responsible for first-time access and computation; the core cloud data center centrally manages security policies and a global blacklist. This addresses the problems of "insufficient rapid response at the edge" and "difficulty in sharing central blacklist data and the resulting privacy risks" in DDoS defense.

[0175] The source chain consists of edge computing nodes, deploying a lightweight machine learning detection module, a blacklist Merkle Tree, and a zero-knowledge proof verification contract to enable rapid detection and cross-chain verification of incoming traffic. The target chain consists of cloud data center nodes, responsible for maintaining a global blacklist Merkle Tree and running a zero-knowledge proof generation module to ensure that verification requests from different edge chains receive reliable proof results. The relay chain acts as a bridge for cross-chain communication, forwarding verification requests submitted by the source chain and verification responses returned by the target chain. Based on this, the zero-knowledge proof module is implemented using zk-SNARK circuits, with the target chain responsible for proof generation and the source chain responsible for proof verification, ensuring the correctness and privacy of cross-chain verification. Simultaneously, the edge nodes also integrate local detection modules, using lightweight machine learning models to quickly classify traffic features, thereby reducing the frequency and overhead of cross-chain verification.

[0176] In the actual operation, edge nodes first monitor incoming traffic in real time. When traffic characteristics match the local blacklist, the node directly blocks the traffic; if no match is found, the local machine learning model is invoked for further judgment. For traffic for which the model still has "uncertain" judgments, the edge node packages the salted hash value of the target IP, the traffic characteristic summary, and the unique identifier into a cross-chain verification request, and forwards it to the target chain through the relay chain.

[0177] Upon receiving a verification request, the target chain searches for the hash value in the global blacklist Merkle Tree. If a match is found, the target chain extracts the corresponding Merkle path and generates a zero-knowledge proof based on a zk-SNARK circuit. The public inputs include the blacklist root value and the target hash, while the private inputs are the path and direction bits. If no match is found, a "missed" result is returned directly. The generated proof or result is returned to the source chain via a relay chain. The source chain calls its local verification contract for verification: if the verification passes and the target hash is found in the blacklist, the IP address is immediately added to the local blacklist, and subsequent traffic is blocked. Simultaneously, the sample is fed back to the local machine learning module for model updates. If the verification result is a miss, the existing traffic handling strategy remains unchanged.

[0178] Furthermore, the system supports a dynamic update mechanism. The cloud target chain periodically updates the global blacklist MerkleTree and triggers automatic updates of verification keys via smart contracts, ensuring the timeliness and security of verification parameters. Upon receiving the update, the edge chain automatically synchronizes the latest Merkle root value and verification key, thereby guaranteeing the real-time performance and reliability of cross-chain verification in dynamic network environments. This collaborative mechanism achieves efficient defense while effectively avoiding privacy leaks caused by plaintext sharing of the blacklist.

[0179] To verify the practical effect of this invention in cloud computing and edge computing platforms, a combination of simulation experiments and theoretical comparative analysis was used.

[0180] Experimental process: Normal traffic and DDoS attack traffic were continuously injected into edge nodes to test three solutions: traditional edge single-chain defense (no cross-chain verification); plaintext cross-chain verification defense (blacklist plaintext sharing); and the solution of this invention (cross-chain ZKP collaborative verification).

[0181] Table 1 Comparison of core indicators and results of different defense schemes

[0182]

[0183] This invention improves the blocking rate of traditional single-chain attacks by approximately 19.2% and by 1.8% compared to plaintext cross-chain attacks, demonstrating that cross-chain collaboration does indeed enhance defense effectiveness. ZKP introduces additional computational overhead, increasing verification latency by approximately 15ms compared to plaintext cross-chain attacks, but still within 100ms, meeting real-time defense requirements. Plaintext cross-chain attacks require direct sharing of blacklists, posing a significant risk of data leakage; this invention, using ZKP, does not expose any blacklist entries, effectively protecting data privacy. False positive rate reduction: Through a joint decision-making mechanism combining edge ML modules and cross-chain ZKP verification, the false positive rate is reduced from 6.3% to 4.8%.

[0184] Rendering illustration:

[0185] Defense latency comparison chart (e.g.) Figure 4 This study verifies the overall defense response latency of this invention in a cloud-edge collaborative scenario, where edge nodes utilize the ZKP cross-chain verification mechanism under different attack traffic scales. As attack traffic increases, detection overhead and false positive handling cause latency to rise rapidly. However, the combination of rapid edge screening and ZKP cross-chain verification in this solution results in significantly lower latency than the control group, with a smoother increase in latency curve.

[0186] Defense success rate comparison chart (e.g.) Figure 5This invention demonstrates its effectiveness in blocking attack traffic in a distributed, multi-datacenter environment as attack intensity increases. With rising attack intensity, traditional single-chain defenses suffer from a lack of cross-center collaboration and delayed blacklist updates, resulting in a success rate that drops to less than 50%. While plaintext cross-chain verification generally has a higher success rate with collaboration, plaintext sharing of blacklists poses serious privacy and security risks. This invention maintains a success rate equal to or even better than plaintext verification while avoiding plaintext blacklist leakage, achieving a dual improvement in security and performance.

[0187] It should be noted that embodiments of the present invention can be implemented in hardware, software, or a combination of both. The hardware portion can be implemented using dedicated logic; the software portion can be stored in memory and executed by a suitable instruction execution system, such as a microprocessor or dedicated-design hardware. Those skilled in the art will understand that the above-described devices and methods can be implemented using computer-executable instructions and / or included in processor control code, for example, such code provided on a carrier medium such as a disk, CD, or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The devices and modules of the present invention can be implemented by hardware circuitry such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field-programmable gate arrays, programmable logic devices, etc., or by software executed by various types of processors, or by a combination of the above-described hardware circuitry and software, such as firmware.

[0188] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any modifications, equivalent substitutions, and improvements made by those skilled in the art within the scope of the technology disclosed in the present invention, and within the spirit and principles of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A DDoS cross-chain cooperative defense method, characterized in that, Includes the following steps: Step 1: System initialization. Deploy the blockchain network and smart contract environment on the source chain, target chain, and relay chain. Deploy local machine learning detection modules and Merkle tree-based blacklist databases on the source chain and target chain, respectively. The target chain calls Setup to generate system parameters and executes KeyGen to obtain the proof key and verification key. Deploy zero-knowledge proof generation and verification contracts on the target chain and source chain, respectively, and load the corresponding keys. Deploy a cross-chain communication module on the relay chain to support message and proof transmission. Step 2, Local rapid response and suspicious traffic identification: The source chain node monitors external requests in real time. First, it quickly searches through the local blacklist Merkle tree. If a match is found, it is blocked and recorded. If no match is found, it is judged by machine learning model. Normal traffic is allowed to pass, and suspicious traffic is packaged into cross-chain verification requests and cached. Step 3: Construct and send a cross-chain verification request. The source chain generates a salted hash of the target IP and constructs a verification request containing common input, feature digest, and unique identifier. This request is uploaded to the source chain and forwarded to the target chain by the relay chain. Step 4: The target chain is blacklisted and zero-knowledge proofs are constructed. If a match is found, the Merkle tree path is extracted as private input, a zero-knowledge proof is generated and returned along with the public input. If no match is found, a miss state is returned. Step 5: Source chain verification and policy update. The source chain calls the verification contract to perform verification. If the verification is valid, the corresponding IP is added to the local blacklist and used as a training sample to optimize the local model. If the verification fails, the original state is maintained. The cross-chain verification employs a zero-knowledge proof mechanism to ensure verification is completed without exposing the actual content of the target chain's blacklist. The zero-knowledge proof generation process includes: Set the security parameter λ and establish a non-degenerate bilinear pair mapping. Calculate the tree depth based on the Merkle tree size of the target chain blacklist and output the parameter set. Based on the constraint circuit, a trusted setting is executed to generate a proof key and a verification key, and the verification key is registered through a smart contract. Using the salted hash of the target IP and the Merkle tree root as public inputs, and the Merkle path and direction bits as private inputs, a zero-knowledge proof is generated. The source chain verifies the data by inputting the verification key, public input, and proof through an on-chain verification contract, and outputs the result of whether the blacklist is hit.

2. The method as described in claim 1, characterized in that, When the target chain's blacklist is updated, causing a change in the Merkle tree root, the smart contract is automatically triggered to synchronize and update the verification key, ensuring that the verification key called during cross-chain verification of the source chain is consistent with the target chain's state.

3. The method as described in claim 2, characterized in that, The update process is automatically executed by the target chain node through a smart contract, and the updated verification key is recorded in the block where the Merkle tree has changed, thus achieving real-time and secure cross-chain verification.

4. The method as described in claim 1, characterized in that, The verification request constructed by the source chain is uploaded to the chain through the source chain smart contract and forwarded to the target chain by the relay chain node. The relay chain then broadcasts the request content to the target chain node group asynchronously.

5. The method as described in claim 4, characterized in that, The verification request includes the following: The salted hash value of the target IP, an attack feature summary including the source port, target port, access frequency and timestamp, unique identifier and request initiation time.

6. The method as described in claim 1, characterized in that, The source chain uses a local lightweight machine learning model to identify suspicious traffic and uses cross-chain verification results as labeled samples to input into the machine learning model, enabling incremental training and model optimization.

7. The method as described in claim 6, characterized in that, Once the source chain verification contract confirms that an IP address has been blacklisted by the target chain, it automatically adds the IP address to the local blacklist Merkle tree and blocks subsequent access. At the same time, the event that the IP address has been confirmed to have been blacklisted by the target chain through cross-chain verification is used as a training sample to input into the local model.

8. A DDoS cross-chain collaborative defense system implementing the method as described in any one of claims 1 to 7, characterized in that, include: Source chain node, used to perform local detection and cross-chain verification request construction; The target chain node is used to receive verification requests and generate zero-knowledge proofs. The relay chain module is used to transmit verification requests and responses between the source chain and the target chain; The zero-knowledge proof module is embedded in the target chain and source chain nodes and is used to generate and verify zero-knowledge proofs. The local detection module is used to initially identify unknown attack traffic through machine learning models.

9. The system as described in claim 8, characterized in that, The zero-knowledge proof module performs privacy-preserving verification based on a Merkle tree structure, and the local detection module is linked with the source chain blacklist database to achieve rapid search and intelligent identification.

Images