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

Abstract

The invention belongs to but not limited to the technical field of network security, and particularly relates to a DDoS (Distributed Denial of Service) cross-chain cooperative defense method, system and device, a medium and a terminal.The DDoS cross-chain cooperative defense method comprises a source chain node used for monitoring external flow, executing local rapid detection, constructing a cross-chain verification request and adjusting a defense strategy according to a target chain feedback result; the target chain node is used for receiving the verification request, performing blacklist matching on the suspicious IP, generating a ZKP proof and returning a result to the source chain; the relay chain module is used as a cross-chain communication channel and is responsible for forwarding a verification request and a response; the zero-knowledge proving module is embedded in a target chain node and a source chain node and is used for constructing and verifying a ZKP circuit and executing privacy protection verification based on a Merkle Tree structure; and the local detection module is used for integrating a local lightweight machine learning model and realizing preliminary identification of unknown attack traffic.

Description

TECHNICAL FIELD

[0001] The present application belongs to but is not limited to the technical field of network security, and particularly relates to a DDoS cross-chain cooperative defense method, system, device, medium and terminal. BACKGROUND

[0002] With the rapid development of the Internet and the continuous expansion of application scenarios, network security problems are becoming increasingly serious, especially the attack risk on critical infrastructure networks has significantly increased. In recent years, blockchain technology has attracted widespread attention in the field of network security due to its characteristics of decentralization, traceability and tamper resistance. Existing research has introduced blockchain technology into DDoS defense to achieve distributed defense and improve information transparency and credibility.

[0003] Traditional on-chain DDoS defense schemes are mostly limited to a single chain and use blacklisting rules, simple rate limiting or machine learning models for local defense. This isolated strategy is difficult to deal with cross-domain and multi-platform covert attack behavior. At the same time, existing cooperative defense schemes mostly use plaintext to directly share attack IPs or their hashes, which has the problems of privacy leakage and feature abuse, especially in a multi-chain environment.

[0004] In view of the above analysis, the existing technical problems to be solved urgently in the prior art are: the existing on-chain DDoS defense scheme is either limited to a single chain and isolated, which is difficult to deal with cross-domain and multi-platform covert attack behavior; or the existing cooperative scheme shares attack information in plaintext or hash, which has the problems of privacy leakage and feature abuse, and is more vulnerable in a multi-chain environment.

[0005] In the related art, the patent application file with the publication number CN110113328A proposes a software-defined opportunity network DDoS defense method based on blockchain. This scheme uses the centralized control and real-time monitoring capability of SDN to analyze the characteristics of network traffic and identify attack source addresses by combining a traceability algorithm, then maintains an attacker blacklist through blockchain, realizes on-chain storage and sharing to assist the application layer in malicious traffic filtering. Although this scheme has certain advantages in attack source tracking and blacklist storage, its defense framework is mainly limited to a single-chain environment, lacks cross-chain collaboration mechanisms, and the blacklist is stored and propagated in plaintext, which poses privacy leakage and misuse risks. In the patent application document with the publication number CN120050094A, a network security protection method and system based on blockchain are proposed. This scheme generates a digital identity on the chain by fusing device unique identifiers and user biometric features, and realizes dynamic permission management based on this; at the same time, a deep learning model trained by adversarial training is used for threat detection, and the permission level is dynamically updated by means of a smart contract; in addition, the sharded blockchain technology and relay chain are used to realize cross-chain threat intelligence synchronization, and the threshold signature and zero-knowledge proof mechanisms are combined to encrypt and verify cross-chain data and permission change records. Although this scheme exhibits the advantages of cross-chain synchronization and zero-knowledge proof combination, it mainly focuses on identity authentication and permission control and does not conduct research on cross-chain collaborative defense against DDoS attacks, especially lacking effective mechanisms in blacklist matching and privacy verification. SUMMARY

[0006] In view of the problems existing in the prior art, the present application provides a DDoS cross-chain collaborative defense method, system, device and terminal, aiming to overcome the shortcomings of existing on-chain DDoS defense schemes that are limited to single-chain internal and lack privacy protection and trusted verification, and proposes a DDoS cross-chain collaborative defense system and method based on zero-knowledge proof, which realizes trusted verification and sharing of suspicious IPs between different blockchains without exposing the specific content of the blacklist, ensuring the computational correctness and privacy protection of the defense process, and building a distributed collaborative defense mechanism for rapid detection, cross-chain verification and strategy optimization, thereby improving the network security protection capability in a multi-chain environment.

[0007] The present application is implemented as follows: a DDoS cross-chain collaborative defense method, comprising:

[0008] Step 1: System initialization: complete blockchain network and smart contract environment deployment on the source chain, target chain and relay chain; deploy local machine learning detection module and Merkle Tree-based blacklist database on the source chain and target chain respectively; the target chain calls Setup to generate system parameters and executes KeyGen to obtain proof key P k and verification key V k; then deploy ZKP generation / verification contract and load corresponding key on target chain and source chain respectively; relay chain deploys cross-chain communication module to support message and proof transmission.

[0009] Step two, local rapid reaction and suspicious traffic identification: source chain node monitors external requests in real time, first searches through local blacklist Merkle Tree; if hit, directly block and record; if not hit, submit to lightweight machine learning model for judgment, normal traffic is released, suspicious traffic is packaged as cross-chain verification request, and temporarily cached for verification results.

[0010] Step three, construct and send cross-chain verification request: for suspicious IP that cannot be confirmed, source chain generates salted hash h, and constructs VerificationRequest containing public input placeholder, feature digest and unique identifier; the request is on-chain in source chain, forwarded to target chain by relay chain for processing.

[0011] Step four, target chain blacklist matching and ZKP construction: target chain searches in local blacklist Merkle Tree according to the request; if matched, extract Merkle Tree path as private input, call ProofGen to generate structured zero-knowledge proof π, and encapsulate as response message together with public input; if not hit, return not hit state directly.

[0012] Step five, source chain verification and strategy update: source chain receives response and calls Verify for verification; if the proof is valid, add the corresponding IP to the local blacklist, block subsequent access, and optimize the local model as a training sample; if the verification fails, maintain the original state.

[0013] Further, the zero-knowledge proof cross-chain blacklist verification mechanism realizes the verification of whether a certain IP in the target chain hits the blacklist by the source chain 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 proof and cross-chain adaptive parameter initialization Setup(1 λ )→Params

[0015] Set security parameter λ, mapping e:G1×G2→G t is a non-degenerate bilinear pair, G tis the target group receiving the bilinear pair result, G1, G2 are cyclic groups of prime order p, each with g1, g2 as the generator, and the actual size of the target chain blacklist Merkle tree is dynamically calculated to replace the traditional fixed depth method, and the tree depth is recorded as Tdth, which realizes parameter adaptation in cross-chain scenarios and avoids 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 verification KeyGen(Params, C)→(P k ,V k )

[0017] Given the constraint circuit C, the target chain performs trusted setting based on the constraint circuit C to generate proof key P k and verification key V k . V k Register on the chain through the smart contract to provide public input for subsequent cross-chain verification. Introduce a smart contract to realize dynamic management of keys, and when the target chain blacklist is updated, the Merkle root is changed, the smart contract registration V k is automatically triggered to ensure that the verification key is synchronized with the latest chain state. This process is automatically implemented through the contract, improving the real-time performance and security of cross-chain verification.

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

[0019] The target chain uses P k to generate a zero-knowledge proof π. The proof input includes: public input x=(root, h): where root is the Merkle tree root of the blacklist, 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 path and direction length should be equal to Tdth, ensuring that the path calculation matches the Merkle tree level).

[0020] S4: Proof verification and result feedback Verify(V k , x, π)→rlt

[0021] After receiving the proof π, the source chain calls V kTo prove π to perform verification operations, the public input x=(root, h) needs to be synchronized with the latest state of the target chain. If π is legal, the output result rlt=1, indicating that the IP exists in the target chain blacklist; otherwise, rlt=0, indicating that it is not hit or the proof is invalid.

[0022] Further, step one specifically includes:

[0023] 1.1 Blockchain network deployment: complete node deployment on the source chain, target chain and relay chain, and establish an intelligent contract execution environment;

[0024] 1.2 Deploy local detection module: deploy local machine learning detection module on the source chain and target chain respectively, and generate local blacklist database based on historical data (store using Merkle tree structure, support root verification and path extraction).

[0025] 1.3 System parameter initialization: call Setup(1 λ ) by the target chain node, set the global security parameter λ, set the non-degenerate bilinear pair e:G1×G2→G t , and fix the Merkle tree depth Tdth at initialization to ensure the legality of the circuit structure and the consistency of the path length. Output the global parameter set: Params=(λ,Tdth,G1,G2,g1,g2,e);

[0026] 1.4 Generate proof key and verification key: the target chain executes KeyGen(Params,C) to generate proof key P k and verification key V k ; V k is uploaded to the smart contract for calling by the source chain cross-chain verification;

[0027] 1.5 Deploy zero-knowledge proof contract: the target chain deploys ZKP generation contract(ProofGen(P k ,x,w)), and loads the proof key P k ; the source chain deploys ZKP verification contract(Verify(V k ,x,π)), and loads the verification key V k .

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

[0029] Further, step three specifically includes:

[0030] 3.1 When the source chain node cannot confirm whether the target IP is in the local blacklist, send 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, Comprise the following steps: Step one, system initialization, in the source chain, target chain and relay chain complete the deployment of the blockchain network and smart contract environment, the source chain and the target chain deploy local machine learning detection module and blacklist database based on Merkle tree respectively, the target chain calls Setup to generate system parameters and executes KeyGen to obtain proof key and verification key, deploy zero-knowledge proof generation and verification contract in the target chain and the source chain respectively and load the corresponding key, deploy cross-chain communication module in the relay chain to support message and proof transmission; Step two, local rapid reaction and suspicious traffic identification, the source chain node monitors external requests in real time, first searches through the local blacklist Merkle tree, if it hits, it is blocked and recorded, if it does not hit, it is judged by the machine learning model, normal traffic is released, and suspicious traffic is packaged as cross-chain verification request and cached; Step three, construct and send cross-chain verification request, the source chain generates the salted hash of the target IP, constructs a verification request containing public input, feature digest and unique identifier, the request is on-chain in the source chain and forwarded to the target chain by the relay chain; Step four, target chain performs blacklist matching and zero-knowledge proof construction, if it matches, it extracts the Merkle tree path as the private input, generates the zero-knowledge proof and returns it together with the public input, if it does not hit, it returns the not hit state; Step five, source chain verification and strategy update, the source chain calls the verification contract for 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.

2. The method of claim 1, wherein, The cross-chain verification adopts zero-knowledge proof mechanism to ensure that the verification is completed without exposing the actual content of the target chain blacklist, wherein the zero-knowledge proof generation process comprises: Set the security parameter λ and establish the non-degenerate bilinear pair mapping, calculate the tree depth according to the size of the target chain blacklist Merkle tree, and output the parameter set; Generate proof key and verification key based on constraint circuit execution trusted setting, and register verification key through smart contract; The salted hash of the target IP and the Merkle tree root are used as public input, and the Merkle path and direction bit are used as private input to generate zero-knowledge proof; The source chain inputs the verification key, public input and proof through the on-chain verification contract for verification, and outputs the result of whether it hits the blacklist.

3. A cross-chain blacklist updating method based on a dynamic Merkle tree structure, characterized in that, When the target chain blacklist update causes the Merkle tree root to change, the smart contract is automatically triggered to update the verification key, ensuring that the verification key called by the source chain cross-chain verification is consistent with the target chain state.

4. The method of claim 3, wherein, The update process is automatically executed by the target chain node through the smart contract, and the updated verification key is recorded in the block where the Merkle tree changes, realizing the real-time and security of cross-chain verification. 5.A method for transmitting a verification request based on cross-chain relay, characterized in that, The verification request constructed by the source chain is on-chain through the source chain smart contract, and is forwarded to the target chain by the relay chain node. The relay chain broadcasts the request content to the target chain node group in an asynchronous manner.

6. The method of claim 5, wherein, The verification request includes the following contents: Salted hash value of target IP, attack feature digest, including source port, target port, access frequency and timestamp, unique identifier and request initiation time.

7. A defense method based on machine learning and cross-chain verification cooperation, characterized in that, The source chain performs suspicious traffic identification through a local lightweight machine learning model, and inputs the cross-chain verification result as a labeled sample into the machine learning model to realize incremental training and model optimization.

8. The method of claim 7, wherein, When the source chain verification contract confirms that an IP hits the target chain blacklist, the IP is automatically added to the local blacklist Merkle tree and subsequent access is blocked, and the event is input as a training sample into the local model.

9. A DDoS cross-chain cooperative defense system for implementing the method of any one of claims 1 to 8. Comprise: A source chain node for performing local detection and constructing a cross-chain verification request; A target chain node for receiving a verification request and generating a zero-knowledge proof; A relay chain module for transmitting verification requests and responses between the source chain and the target chain; A zero-knowledge proof module embedded in the target chain and the source chain node for generating and verifying a zero-knowledge proof; A local detection module for preliminary identification of unknown attack traffic through a machine learning model.

10. The system of claim 9, wherein, The zero-knowledge proof module performs privacy protection verification based on a Merkle tree structure, and the local detection module is linked with a source chain blacklist database to realize fast searching and intelligent discrimination.

Images