Blockchain and spectral analysis-based trusted clearance method and system, and storage medium

Abstract

The application discloses a trusted clearance method and device based on a blockchain and spectral graph analysis, and belongs to the field of blockchains. The method comprises the following steps: an airport management node calls a first smart contract on a main chain according to a clearance request, obtains a clearance verification voucher pre-stored on the main chain by an enterprise node, and sends the clearance verification voucher and a corresponding verification request to a corresponding side chain via a decentralized verification network; a verification node on the side chain responds to the verification request, calls a second smart contract to verify the validity of zero-knowledge proof, generates a verification result for indicating whether enterprise single certificate data meets specific clearance compliance rules, and returns the verification result to the main chain via the decentralized verification network, so that the airport management node makes a clearance decision. Thus, based on the one-time submitted clearance verification voucher, the whole process of the privacy-protected, automated and trusted clearance verification for a specific country is completed, and the efficient mode of one-time submission and multi-party reuse is fully embodied.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a trusted customs clearance method, system and storage medium based on blockchain and spectral analysis. Background Technology

[0002] In the context of globalized cross-border trade, participants must comply with the customs clearance rules of different countries or regions. For example, entering the Chinese market requires meeting CCC (China Compulsory Certification) requirements, while entering the EU market requires meeting CE (Conformité Européenne) certification standards. Currently, due to independent rules and fragmented verification systems in different countries, for the same batch of goods, participants need to repeatedly prepare and submit highly overlapping but differently formatted documents (such as EMC test reports, product manuals, and certificates of origin) for different countries' customs clearance requirements. This "one country, one submission" model constitutes the main efficiency bottleneck in current cross-border trade document processing, specifically manifested in the following technical difficulties:

[0003] (1) Rigidity in rule processing: Existing trade facilitation systems or platforms lack the ability to intelligently parse and adapt regulatory texts. Rules are usually statically configured or manually interpreted, and cannot automatically convert the legal provisions of various countries into standard code that can be directly executed by computer systems, resulting in lagging rule updates and poor system flexibility.

[0004] (2) Data privacy leakage risk: To ensure the authenticity of document data, the current verification process often requires companies to transmit or share sensitive commercial document data in plaintext (such as certificates of origin containing accurate cost information), which greatly increases the risk of leakage of trade secrets.

[0005] (3) Scalability and efficiency bottlenecks of the system architecture: In the attempt to adopt blockchain technology, if all business logic and verification rules are deployed on a single blockchain, the blockchain will become overloaded and bloated. In addition, the growth and changes of rules will trigger hard forks or complex upgrades across the entire network, making system maintenance difficult and processing efficiency low.

[0006] (4) The credibility of cross-chain architecture data is difficult to guarantee: In the attempt to adopt a multi-chain architecture to improve the scalability and flexibility of the system, the cross-chain data interaction between chains usually needs to rely on a trusted third-party centralized intermediary to verify and forward the authenticity and integrity of cross-chain information. This solution that relies on a centralized intermediary has single point of failure and trust risk, which violates the decentralized principle of blockchain.

[0007] In response to the technical problems of existing cross-border trade document processing solutions, such as the inefficiency caused by the need for participants to submit documents repeatedly, rigid rule processing that cannot be automatically adapted, the risk of data privacy leakage, the performance bottleneck of a single blockchain architecture, and the lack of trustworthiness in cross-chain interaction, there is an urgent need for corresponding technical solutions. Summary of the Invention

[0008] The embodiments of this disclosure provide a trusted customs clearance method, system, and storage medium based on blockchain and spectrogram analysis, which at least solves the technical problems existing in the prior art, such as the inefficiency caused by the need for participants to repeatedly submit documents, the rigidity of rule processing and the inability to automatically adapt, the risk of data privacy leakage, the performance bottleneck of a single blockchain architecture, and the insufficient trustworthiness of cross-chain interaction.

[0009] According to one aspect of the embodiments of this disclosure, a trusted customs clearance method based on blockchain and spectral analysis is provided, comprising: a port management node responding to a customs clearance request by invoking a first smart contract on the main chain to obtain a customs clearance verification certificate pre-stored on the main chain by an enterprise node; wherein the customs clearance verification certificate includes a cryptographic digest value generated based on enterprise document data and a corresponding zero-knowledge proof; the port management node sending the customs clearance verification certificate and the corresponding verification request to a corresponding side chain via a preset decentralized verification network through the first smart contract; wherein the decentralized verification network includes multiple verification nodes that independently perform verification and provides a cross-chain bridge between the main chain and the side chain, and Furthermore, the sidechain has a pre-built second smart contract, which encapsulates verification logic corresponding to specific customs clearance compliance rules. Verification nodes on the sidechain respond to verification requests by calling the second smart contract to verify the validity of the zero-knowledge proof and generate verification results. The verification nodes then return the verification results to the main chain via a decentralized verification network. This decentralized verification network is configured to: perform spectroscopic analysis on the decentralized verification network to determine a verification node group from multiple verification nodes to vote on the cross-chain data sent from the source blockchain; and vote on the cross-chain data through the verification node group, sending the cross-chain data to the target blockchain based on the voting results.

[0010] According to another aspect of the present disclosure, a storage medium is also provided, the storage medium including a stored program, wherein, when the program is executed, a processor performs any of the methods described above.

[0011] According to another aspect of the present disclosure, a trusted customs clearance system based on blockchain and spectral analysis is also provided, including a main chain and at least one side chain, and a decentralized verification network is set between the main chain and each side chain; the nodes on the main chain include port management nodes and enterprise nodes; the nodes on the side chains include verification nodes; the decentralized verification network includes multiple verification nodes that perform independent verification and provides a cross-chain bridge between the main chain and the side chains; the port management node is configured to: respond to a customs clearance request, invoke a first smart contract on the main chain to obtain a customs clearance verification certificate pre-stored on the main chain by the enterprise node; wherein, the customs clearance verification certificate includes a cryptographic digest value generated based on enterprise document data and a corresponding zero-knowledge proof; and transmit the customs clearance verification certificate through the first smart contract. The certificate and corresponding verification request are sent to the corresponding sidechain via a pre-defined decentralized verification network. The sidechain has a pre-built second smart contract, which encapsulates verification logic corresponding to specific customs clearance compliance rules. Verification nodes are configured to: respond to verification requests, invoke the second smart contract, verify the validity of the zero-knowledge proof based on the verification logic, and generate verification results; return the verification results to the main chain via the decentralized verification network. The decentralized verification network is configured to: perform spectrum analysis on the decentralized verification network, determine a verification node group from multiple verification nodes to vote on the cross-chain data sent from the source blockchain; vote on the cross-chain data through the verification node group, and send the cross-chain data to the target blockchain based on the voting results.

[0012] In the cross-border trade customs clearance process, this application first responds to the clearance request by invoking the first smart contract deployed on the main chain to obtain the customs clearance verification certificate pre-stored by the enterprise node. This certificate includes a cryptographic digest value generated based on the enterprise's document data and the corresponding zero-knowledge proof. Thus, the enterprise's one-time submission is automatically recognized by the system and adapted to the subsequent multi-country customs clearance rule verification process. Without the need for repeated submissions by the enterprise, the port management node can obtain the necessary customs clearance verification certificate for rule verification through the on-chain contract in response to the clearance request, laying the technical foundation for achieving one-time submission and multi-party reuse.

[0013] Then, the port management node sends the verification request and credentials via a pre-defined decentralized verification network to the sidechain of the corresponding target country's customs clearance rules through the first smart contract. This decentralized verification network dynamically determines the verification node group through spectrogram analysis and conducts consensus voting on cross-chain data. Thus, it not only achieves automatic adaptation and scheduling of customs clearance verification credentials submitted by enterprises in a single transaction according to the customs clearance compliance rules of different target countries, but also ensures the authenticity and integrity of cross-chain data through the decentralized verification network, overcoming the technical challenge of insufficient trust in cross-chain interactions.

[0014] Secondly, the verification nodes on the sidechain invoke a second smart contract encapsulating specific customs clearance compliance rule verification logic to verify the validity of the zero-knowledge proof and generate a verification result. This dedicated chain design effectively decouples the complex verification logic from the main chain, distributing the computational load and overcoming the performance bottlenecks of a single blockchain architecture. Simultaneously, the verification process, based on zero-knowledge proof technology, enables verification nodes to complete mathematical compliance verification without accessing the original document data, fundamentally eliminating the risk of data privacy leaks.

[0015] Finally, the verification node reliably returns the verification result to the main chain via the decentralized verification network, allowing port management nodes to make customs clearance decisions. Thus, based on a one-time submitted customs clearance verification certificate, a complete, privacy-preserving, automated, and reliable customs clearance verification process is achieved, tailored to a specific country, fully demonstrating the high efficiency of a single submission for multiple parties. This solves the technical problems of existing cross-border trade document processing solutions, such as inefficiency due to participants having to repeatedly submit documents, rigid rule processing that cannot be automatically adapted, data privacy leakage risks, performance bottlenecks of a single blockchain architecture, and insufficient trust in cross-chain interactions. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this application, illustrate exemplary embodiments of this disclosure and are used to explain this disclosure, but do not constitute an undue limitation of this disclosure. In the drawings:

[0017] Figure 1 This is a hardware structure block diagram of a computing device for implementing the method described in Embodiment 1 of this disclosure;

[0018] Figure 2 This is an architecture diagram of a trusted customs clearance system based on blockchain and spectral analysis as described in Embodiment 1 of this application;

[0019] Figure 3 This is a flowchart of the trusted customs clearance method based on blockchain and spectral analysis according to Embodiment 1 of this application;

[0020] Figure 4A This is a schematic diagram of the decentralized verification network in the trusted customs clearance system according to Embodiment 1 of this application;

[0021] Figure 4B This is a schematic diagram of the graph structure corresponding to the decentralized verification network in the trusted customs clearance system according to Embodiment 1 of this application;

[0022] Figure 5 This is a schematic diagram of the enterprise node architecture according to Embodiment 1 of this application;

[0023] Figure 6This is a schematic diagram of the structure of the NLP module according to Embodiment 1 of this application;

[0024] Figure 7 This is a schematic diagram of the ZKP generator according to Embodiment 1 of this application;

[0025] Figure 8 This is a schematic diagram of the CCC certification ZKP generator according to Embodiment 1 of this application;

[0026] Figure 9 This is a schematic diagram of the process of putting enterprise node documents on the blockchain according to Embodiment 1 of this application;

[0027] Figure 10 This is a schematic diagram of the structure of the rule maintenance node according to Embodiment 1 of this application;

[0028] Figure 11 This is a schematic diagram of the structure of the verification node according to Embodiment 1 of this application;

[0029] Figure 12 This is a schematic diagram of the decentralized relay network in the trusted customs clearance system according to Embodiment 1 of this application; and

[0030] Figure 13 This is a schematic diagram of the graph structure corresponding to the decentralized relay network in the trusted customs clearance system according to Embodiment 1 of this application. Detailed Implementation

[0031] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this disclosure.

[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0033] Example 1

[0034] According to this embodiment, a method embodiment of a trusted customs clearance method based on blockchain and spectral analysis is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0035] The method embodiments provided in this example can be executed on a server or similar computing device. Figure 1 A hardware block diagram of a computing device for implementing a trusted customs clearance method based on blockchain and spectral analysis is shown. Figure 1 As shown, a computing device may include one or more processors (processors may include, but are not limited to, microprocessors such as MCUs or programmable logic devices such as FPGAs), memory for storing data, transmission devices for communication functions, and input / output interfaces. The memory, transmission devices, and input / output interfaces are connected to the processor via a bus. In addition, it may also include a display, keyboard, and cursor control device connected to the input / output interfaces. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, a computing device may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0036] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element in a computing device. As involved in the embodiments of this disclosure, the data processing circuits serve as processor control (e.g., selection of a variable resistor termination path connected to an interface).

[0037] The memory can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the trusted customs clearance method based on blockchain and spectral analysis in this embodiment of the present disclosure. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the trusted customs clearance method based on blockchain and spectral analysis of the aforementioned application. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the computing device via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0038] The transmission device is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the computing device's communications provider. In one example, the transmission device includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0039] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows users to interact with the user interface of the computing device.

[0040] It should be noted here that, in some optional embodiments, the above... Figure 1 The computing device shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 1 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computing devices.

[0041] Figure 2 This is a schematic diagram of a trusted customs clearance system based on blockchain and spectral analysis, as described in an embodiment of this application. (Reference) Figure 2 As shown, the trusted customs clearance system includes: a main chain, at least one side chain, a decentralized verification network, a decentralized relay network, and blockchain nodes connected to each chain.

[0042] The main chain serves as the system's public collaboration and scheduling platform, storing cryptographic digests, zero-knowledge proofs, and key metadata related to cross-border trade documents. Side chains, acting as specialized verification chains, are designed for specific customs clearance compliance rules (such as CCC certification side chains and CE certification side chains). Furthermore, the main chain and each side chain are connected via a decentralized verification network. This network provides cross-chain bridging functionality between the main chain and side chains and ensures the trustworthiness of cross-chain data transmission.

[0043] The nodes deployed on the main chain include: rule maintenance nodes, port management nodes, enterprise nodes, IoT nodes, and other participating party nodes (such as nodes corresponding to banks, insurance institutions, and inspection and testing institutions).

[0044] in:

[0045] The rule maintenance node, as a key node, is configured to acquire and monitor customs clearance compliance rules (such as CCC certification rules, CE certification rules, etc.) issued by legislative bodies and / or administrative regulations departments, and then formalizes the rules and deploys them to the corresponding sidechains through cross-chain technology.

[0046] The port management node, as a light node, corresponds to the terminal equipment of the customs or customs clearance regulatory agency. It is configured to initiate verification requests, receive verification results, and make customs clearance decisions based on the verification results.

[0047] Enterprise nodes, as light nodes, correspond to the terminal devices of trading companies (such as suppliers and buyers), and are configured to process and submit customs clearance document data.

[0048] IoT nodes, as physical data access nodes, are configured to receive real-time data collected by various sensors in logistics, warehousing, and other processes.

[0049] Verification nodes are deployed on the sidechain, corresponding to the terminal devices of specific certification authorities. They are configured to respond to verification requests, perform zero-knowledge proof verification, and generate verification results.

[0050] Furthermore, IoT nodes are connected to the main chain via a decentralized relay network. This decentralized relay network acts as a buffer layer, effectively addressing the instability of IoT device network connections. It ensures that real-time data collected by various sensors, such as logistics status, temperature, humidity, and location, are reliably and continuously uploaded to the main chain for storage after encryption, providing tamper-proof physical world data support for cross-border trade.

[0051] Under the aforementioned operating environment, according to the first aspect of this embodiment, a trusted customs clearance method based on blockchain and spectral analysis is provided. This method comprises... Figure 2 The blockchain nodes shown are used together to achieve this. Figure 3 A flowchart illustrating the method is shown below. (Refer to...) Figure 3 As shown, the method includes:

[0052] S302: In response to the customs clearance request, the port management node calls the first smart contract on the main chain to obtain the customs clearance verification certificate pre-stored on the main chain by the enterprise node; wherein, the customs clearance verification certificate includes a cryptographic digest value generated based on the enterprise's document data and the corresponding zero-knowledge proof;

[0053] S304: The port management node sends the customs clearance verification certificate and the corresponding verification request to the corresponding side chain through the first smart contract via the pre-set decentralized verification network; wherein, the decentralized verification network includes multiple verification nodes that perform independent verification and provides a cross-chain bridge between the main chain and the side chain, and the side chain has a pre-set second smart contract, which encapsulates the verification logic corresponding to specific customs clearance compliance rules.

[0054] S306: The verification node on the sidechain responds to the verification request, calls the second smart contract to verify the validity of the zero-knowledge proof, and generates the verification result;

[0055] S308: The verification node returns the verification result to the main chain via the decentralized verification network.

[0056] Furthermore, the decentralized verification network configuration is used for: performing spectrum analysis on the decentralized verification network to determine a group of verification nodes from multiple verification nodes to verify the cross-chain data sent from the source blockchain; and verifying the cross-chain data through the verification node group, and sending the cross-chain data to the target blockchain based on the verification voting results.

[0057] Specifically, in combination Figure 2 As shown, in a cross-border trade customs clearance scenario, when an enterprise node (such as a supplier or purchaser) needs to export goods to a target country, it initiates a customs clearance request to the port management node on the main chain through its terminal device. This request carries information about the target country. In response, the port management node (corresponding to customs or a customs clearance regulatory agency) calls the first smart contract pre-deployed on the main chain based on the customs clearance request to automatically obtain the customs clearance verification certificate (corresponding to step S302) pre-stored on the main chain by the enterprise node that matches the customs clearance requirements of the target country. This customs clearance verification certificate includes a cryptographic digest value generated based on the enterprise's document data and a zero-knowledge proof proving the compliance of the document data. Thus, the enterprise's one-time submission is automatically recognized by the system and adapted to the subsequent multi-country customs clearance rule verification process that may be involved. Without the need for repeated submissions by the enterprise, the port management node can obtain the customs clearance verification certificate required for rule verification through the on-chain contract in response to the customs clearance request, laying the technical foundation for achieving one-time submission and multi-party reuse.

[0058] Then, the port management node triggers the first smart contract to execute a cross-chain call. Based on the target country information in the customs clearance request, the verification request and customs clearance verification certificate are routed to the corresponding sidechain via a pre-defined decentralized verification network (corresponding to step S304). For example, when the target country is China, the second smart contract routes the verification request and customs clearance verification certificate to a sidechain with pre-defined CCC certification rules via the decentralized verification network. When the target country is the European Union, the second smart contract routes the verification request and customs clearance verification certificate to a sidechain with pre-defined CE certification rules via the decentralized verification network. Through this smart routing mechanism, the system automatically adapts and schedules customs clearance verification certificates submitted by enterprises in a single transaction according to the customs clearance compliance rules of different target countries.

[0059] Furthermore, decentralized verification networks (DRMs) ensure the credibility of cross-chain data. Specifically, DRMs dynamically select high-credibility verification node groups from their multiple independent verification nodes through spectrogram analysis. These verification node groups then conduct consensus voting on verification requests and clearance verification credentials for cross-chain transmissions, ensuring the authenticity and integrity of data transmitted between chains. This avoids the risks of relying on a single centralized intermediary and fundamentally solves the technical challenge of insufficient credibility in cross-chain interactions.

[0060] Furthermore, a second smart contract is pre-built on the sidechain, encapsulating verification logic corresponding to specific customs clearance compliance rules. This sidechain architecture offers high scalability. When the system needs to support customs clearance rules for a new country or region (e.g., adding US FCC certification), there's no need to modify the main chain's core logic; only a new sidechain carrying the corresponding new rule verification logic needs to be deployed. This modular design, dedicated to a specific chain, not only avoids the performance bottleneck caused by piling all rules onto the main chain but also enables the system to flexibly and cost-effectively adapt to the dynamic growth and changes in cross-border trade rules.

[0061] Next, the verification nodes on the sidechain (such as certification authority nodes like TUV) respond to the verification request, invoking the second smart contract to verify the validity of the zero-knowledge proof based on the verification logic, and generating a verification result (e.g., "passed" or "failed") indicating whether the company's document data meets specific customs clearance compliance rules (corresponding to step S306). Since the second smart contract encapsulates the verification logic corresponding to the specific customs clearance compliance rules, the verification nodes can use this logic to verify the validity of the zero-knowledge proof. The essence of the verification is mathematically confirming whether the company possesses genuine document data that meets the rules. The entire process is completed under the protection of zero-knowledge proof technology; the verification nodes do not need to access the original document data, effectively avoiding the risk of data privacy leakage.

[0062] Finally, the verification node reliably returns the verification result to the main chain via the decentralized verification network, so that the port management node can make customs clearance decisions based on the verification result (corresponding to step S308). Thus, based on the one-time submitted customs clearance verification certificate, a complete, privacy-protected, and automated customs clearance verification process for a specific country has been completed, fully demonstrating the efficient model of one-time submission and multi-party reuse.

[0063] As described in the background section above, existing cross-border trade document processing solutions suffer from inefficiencies due to participants having to repeatedly submit documents, rigid rule processing that cannot be automatically adapted, risks of data privacy leaks, performance bottlenecks of a single blockchain architecture, and insufficient trustworthiness in cross-chain interactions.

[0064] In light of this, in the cross-border trade customs clearance process, the port management node first responds to the clearance request by invoking the first smart contract deployed on the main chain to obtain the customs clearance verification certificate pre-stored by the enterprise node. This certificate includes a cryptographic digest value generated based on the enterprise's document data and the corresponding zero-knowledge proof. Thus, the enterprise's one-time submission is automatically recognized by the system and adapted to the subsequent multi-country customs clearance rule verification process. Without requiring repeated submissions from the enterprise, the port management node can obtain the necessary customs clearance verification certificate for rule verification through the on-chain contract in response to the clearance request, laying the technical foundation for achieving one-time submission and multi-party reuse.

[0065] Then, the port management node sends the verification request and credentials via a pre-defined decentralized verification network to the sidechain of the corresponding target country's customs clearance rules through the first smart contract. This decentralized verification network dynamically determines the verification node group through spectrogram analysis and conducts consensus voting on cross-chain data. Thus, it not only achieves automatic adaptation and scheduling of customs clearance verification credentials submitted by enterprises in a single transaction according to the customs clearance compliance rules of different target countries, but also ensures the authenticity and integrity of cross-chain data through the decentralized verification network, overcoming the technical challenge of insufficient trust in cross-chain interactions.

[0066] Secondly, the verification nodes on the sidechain invoke a second smart contract encapsulating specific customs clearance compliance rule verification logic to verify the validity of the zero-knowledge proof and generate a verification result. This dedicated chain design effectively decouples the complex verification logic from the main chain, distributing the computational load and overcoming the performance bottlenecks of a single blockchain architecture. Simultaneously, the verification process, based on zero-knowledge proof technology, enables verification nodes to complete mathematical compliance verification without accessing the original document data, fundamentally eliminating the risk of data privacy leaks.

[0067] Finally, the verification node reliably returns the verification result to the main chain via the decentralized verification network, allowing port management nodes to make customs clearance decisions. Thus, based on a one-time submitted customs clearance verification certificate, a complete, privacy-preserving, automated, and reliable customs clearance verification process is achieved, tailored to a specific country, fully demonstrating the high efficiency of a single submission for multiple parties. This solves the technical problems of existing cross-border trade document processing solutions, such as inefficiency due to participants having to repeatedly submit documents, rigid rule processing that cannot be automatically adapted, data privacy leakage risks, performance bottlenecks of a single blockchain architecture, and insufficient trust in cross-chain interactions.

[0068] The process by which the verification nodes of the decentralized verification network verify cross-chain data can be referenced from the explanation of the notary mechanism in existing cross-chain technologies.

[0069] Optionally, before performing spectroscopic analysis on the decentralized verification network, the method further includes: constructing a graph structure corresponding to the decentralized verification network, wherein the verification nodes of the decentralized verification network correspond to the nodes in the graph structure, and the edges between verification nodes are related to the consistency of verification votes between verification nodes. Furthermore, the process of performing spectroscopic analysis on the decentralized verification network to determine the verification node group for verifying cross-chain data sent from the source blockchain includes: randomly selecting verification nodes from the decentralized verification network according to a pre-set number to determine multiple candidate verification nodes; randomly generating multiple chromosome vectors according to preset constraints, where each bit of the chromosome vector corresponds to a different candidate verification node, used to indicate whether the corresponding candidate verification node is selected as the target verification node for verification voting; defining a fitness function, where the fitness function is positively correlated with the algebraic connectivity of the target verification node corresponding to the chromosome vector and negatively correlated with the number of target verification nodes corresponding to the chromosome vector; performing a genetic algorithm iteration on the multiple chromosome vectors according to the fitness function to determine the optimal chromosome vector; and determining the verification node group for verifying cross-chain data sent from the source blockchain based on the optimal chromosome vector.

[0070] refer to Figure 4A As shown, a decentralized verification network (DMU) comprises multiple independent verification nodes. Therefore, when the main chain (i.e., the source blockchain) sends document data (i.e., cross-chain data) to the sidechain (i.e., the target blockchain), it needs to be transmitted to the DMU for verification by multiple verification nodes (e.g., verifying its legality or illegality), and a vote is held based on the verification results. Based on the voting results, the document data is then transmitted to the sidechain.

[0071] Conversely, when a sidechain (i.e., the source blockchain) returns verification information (i.e., cross-chain data) to the main chain (i.e., the target blockchain), it needs to be transmitted to a decentralized verification network (DRM), where multiple verification nodes sign and vote. Based on the voting results, the verification information is transmitted to the main chain.

[0072] Furthermore, while each verification node in the decentralized verification network independently verifies cross-chain data, in order to perform spectral analysis on each verification node, this embodiment constructs edges between verification nodes based on the verification consistency between them.

[0073] Specifically, refer to Figure 4A As shown, the decentralized verification network (DMU) comprises multiple verification nodes. Each time cross-chain data needs verification, the DMU selects a group of verification nodes (the second subset described later) from among these nodes to verify and vote on the data. This group of verification nodes (the target verification nodes described later) records the nodes with consistent verification results and those with inconsistent results. If verification node a and verification node b have consistent verification results, their consistency count is increased by one; conversely, if their results are inconsistent, their inconsistency count is increased by one. Thus, after each verification vote, the number of consistent or inconsistent verification results among the verification nodes in this group increases.

[0074] Similarly, each time data is validated and voted on, the decentralized validation network selects validation nodes from different groups to vote on the validation, and the number of times the validation nodes in each group confirm or disagree with each other increases.

[0075] Therefore, every preset period, the decentralized verification network calculates the ratio between the number of times verification is consistent among verification nodes and the number of times they are in the same group, using this ratio as the consistency coefficient. Specifically, the consistency coefficient E between verification node i and verification node j is... i,j Calculate using the following formula:

[0076]

[0077] Where T i,j F is the number of times verification is consistent between verification node i and verification node j. i,j This represents the number of times there is a verification inconsistency between verification node i and verification node j.

[0078] Therefore, based on the consistency coefficient between two verification nodes, it can be determined whether to establish an edge between them. Specifically, for two verification nodes with a consistency coefficient greater than or equal to a predetermined threshold, an edge is established between them; for two verification nodes with a consistency coefficient less than the predetermined threshold, no edge is established between them.

[0079] This method allows us to determine the graph structure corresponding to the decentralized verification network. See details in the reference section. Figure 4B As shown.

[0080] Based on this, a spectroscopic analysis of the decentralized verification network was conducted to identify the operations of the verification node group used to verify and vote on cross-chain data sent from the source blockchain from multiple verification nodes. These operations include:

[0081] S401: After receiving cross-chain data, randomly select a first subset of candidate validator nodes from the validator nodes according to a pre-set number N (N less than M). Since the selection is random each time, it can be guaranteed that different validator nodes are selected for verification voting each time, thereby avoiding the influence of attacked validator nodes on the verification voting.

[0082] S402: Define the particle chromosome vector X = [x1, x2, ..., x...] N ] T Wherein, each bit x in the chromosome vector X n (n = 1 to N) correspond to different candidate verification nodes in the first subset, and their values ​​can be either 0 or 1, where 0 represents that the candidate verification node was not selected for verification voting, and 1 represents that the candidate verification node was selected as the target verification node for verification voting. Thus, the second subset of target verification nodes used for verification voting of cross-chain data can be determined based on the chromosome vector X.

[0083] S403: Randomly generate multiple chromosome vectors X1 to X according to preset constraints. K ,in:

[0084] X k＝ [x k,1 ,x k,2 ,x k,3 ,...,x k,N ] T , k = 1 ~ K.

[0085] Specifically, the constraint is that the number of target verification nodes selected for verification voting must be greater than or equal to the pre-set minimum number of nodes, Min. That is, for the chromosome vector X, we have:

[0086]

[0087] in, This represents the number of target verification nodes determined based on the chromosome vector X.

[0088] S404: Define the fitness function S(X):

[0089]

[0090] Where F(X) is the algebraic connectivity of the target verification node determined based on the chromosome vector X; X represents the number of target verification nodes determined based on the chromosome vector X; α is the scaling factor, where α > 0.

[0091] F(X) is determined in the following way:

[0092] First, based on the connection relationship between the target verification nodes corresponding to chromosome vector X, construct the Laplacian matrix L corresponding to chromosome vector X;

[0093] Then, the second smallest eigenvalue of the Laplacian matrix L is taken as the algebraic connectivity corresponding to the chromosome vector X.

[0094] The fitness function is related to the algebraic connectivity of the target verification node corresponding to the chromosome vector X. The greater the algebraic connectivity, the better the connectivity of the network formed by the target verification nodes, the stronger the consensus achieved, and thus the stronger the ability to resist malicious node collaborative attacks.

[0095] As the denominator, it means that the fewer the number of target verification nodes, the better (however, the number of target verification nodes must still be greater than or equal to the pre-set minimum number of nodes Min).

[0096] S405: The chromosome vectors X1 to X2 calculated according to the above formula. K fitness S1~S K Using the softmax function, determine the values ​​relative to X1 to X2 respectively. K The corresponding probabilities Q1 to Q K :

[0097] Q1~Q K =softmax(S1~S K (4)

[0098] S406: Based on probabilities Q1 to Q... K For chromosome vectors X1 to X K Random sampling is performed to determine the new population X1 to X2. K .

[0099] S407: For the new population X1~XK Perform crossover and mutation operations to determine the corresponding subpopulations Y1 to Y2. K .

[0100] S408: Determine whether the conditions for ending the iteration have been met (e.g., the iteration result converges or the preset number of iterations has been reached). If the conditions for ending the iteration have not been met, then process the subpopulations Y1 to Y... K As a new population X1~X K A new round of iterative calculations is then performed. If the condition for ending the iteration is met, the optimal chromosome vector X is determined. best

[0101] S409: Based on the optimized chromosome vector X best The second subset is determined by identifying the target verification nodes used for voting on cross-chain data.

[0102] Therefore, according to the technical solution of this application, the connection relationship between each verification node is constructed based on the consistency coefficient between each verification node. Thus, the more verification nodes with connections, the stronger the proof of the verification node's legitimacy. In this application, by randomly selecting candidate verification nodes each time, the vulnerability to attacks caused by selecting fixed verification nodes each time is avoided. Based on the selection of candidate verification nodes, in the genetic algorithm, a fitness function is constructed using spectral analysis and the algebraic connectivity of the verification nodes corresponding to chromosome vectors. Thus, during the iteration process of the genetic algorithm, verification nodes with good connectivity, strong consistency, and strong resistance to malicious node collaborative attacks can be selected to verify and vote on cross-chain data. This enhances the security and credibility of the cross-chain data verification process.

[0103] Optionally, before constructing the graph structure corresponding to the decentralized verification network, the method further includes: deleting some verification nodes of the decentralized verification network through voting operations of the verification nodes of the decentralized verification network, wherein the voting operations are used to determine the verification nodes with the lowest voting consistency in the decentralized verification network; and restoring the verification nodes that were deleted before a predetermined period.

[0104] Specifically, in the technical solution of this application, the decentralized verification network allows each verification node to vote at preset intervals, listing the verification node with the lowest consistency coefficient (or a predetermined number of verification nodes with the lowest consistency coefficient) for each verification node in that interval. The predetermined number of verification nodes with the most votes are temporarily removed from the decentralized verification network, and in subsequent verification voting processes, the removed verification nodes will not be selected as candidate verification nodes.

[0105] Furthermore, after a validator node is deleted, it will be reinstated for validation voting after a specified number of periods. For a newly reinstated validator node, its degree will be set to the maximum degree in the current decentralized validator network's graph structure (i.e., the maximum number of edges a single node can connect to). Then, its connections with other validator nodes will be randomly determined according to the determined degree.

[0106] Based on this, as mentioned above, the decentralized verification network randomly selects candidate verification nodes to form the first subset, and then uses a genetic algorithm to determine the target verification node.

[0107] In this way, at predetermined intervals, the decentralized verification network identifies suspected compromised verification nodes through voting among its various verification nodes, thereby making the verification process of the decentralized verification network more secure.

[0108] Optionally, enterprise nodes store customs clearance verification credentials on the main chain through the following steps: extracting document data elements corresponding to specific customs clearance compliance rules from the original enterprise document data; generating corresponding cryptographic digest values ​​based on the document data elements; generating zero-knowledge proofs to prove that the enterprise document data complies with specific customs clearance compliance rules based on the cryptographic digest values ​​and specific customs clearance compliance rules; and combining the cryptographic digest values ​​and zero-knowledge proofs into customs clearance verification credentials and uploading them to the main chain for storage.

[0109] Specifically, refer to Figure 5 As shown, the application layer of the enterprise node includes an OCR module to recognize scanned documents and generate corresponding structured document data, which serves as the original enterprise document data. The contract layer of the enterprise node includes an NLP module, which allows the enterprise node to extract document data elements corresponding to specific customs clearance compliance rules from the original enterprise document data. These document data elements include, but are not limited to, requirements for the qualified entity, certification standards, validity periods, and certification number format requirements (e.g., requirements for obtaining CE certification numbers, CCC certification numbers, etc.).

[0110] The NLP module is pre-configured with Solidity logic trees (as element extraction templates) corresponding to the customs clearance compliance rules adopted by each target country. (See reference...) Figure 6As shown, the NLP module, for example, has a CCC certification Solidity logic tree corresponding to the CCC certification rules adopted in China and a CE certification Solidity logic tree corresponding to the CE certification rules adopted in EU countries. When an enterprise node has a need to export goods to China and EU countries, the NLP module extracts the document data element 1 required for CCC certification and the document data element 2 required for CE certification from the original enterprise document data. An example of document data element 2 is: "CE certification requirement: The product must provide an EMC test report, valid for 3 years."

[0111] Subsequently, the enterprise node will proceed with cryptographic processing and zero-knowledge proof generation based on the extracted document data elements to construct the final customs clearance verification certificate. (Refer to...) Figure 5 As shown, this process first generates cryptographic digest values ​​(including document data hash value 1 and document data hash value 2) corresponding to different rules (such as CCC certification rules and CE certification rules) through the encryption module. Then, it calls a dedicated zero-knowledge proof (ZKP) generator, which uses its embedded rule verification logic tree to generate corresponding zero-knowledge proofs (including proof1 and proof2) for the cryptographic digest value. The detailed process of how the ZKP generator performs rule verification and generates zero-knowledge proofs will be discussed below.

[0112] After generating the zero-knowledge proof, the enterprise node combines the cryptographic digest value (including document data hash value 1 and document data hash value 2) and the zero-knowledge proof (including proof1 and proof2) into a customs clearance verification certificate, and uploads it to the main chain for notarization, that is, putting the customs clearance verification certificate on the main chain's data layer. In addition, publicly available data related to the document data (such as customs declaration number and basic information such as trading country) can usually be included in the customs clearance verification certificate and uploaded to the main chain's data layer together, so that the port management node can use it to assist in the subsequent verification process.

[0113] Thus, through the aforementioned modular and automated process, enterprise nodes have transformed raw document data into customs clearance verification credentials that can be verified by multiple parties without compromising privacy, and anchored to the main chain. This lays a solid data foundation for subsequent port management nodes to flexibly and reliably call upon and verify these credentials according to specific customs clearance needs.

[0114] Optionally, the operation of generating a zero-knowledge proof to prove that the enterprise's document data complies with the specific customs clearance compliance rules, based on the cryptographic digest value and the specific customs clearance compliance rules, includes: invoking a locally deployed zero-knowledge proof generator; wherein the zero-knowledge proof generator has pre-built rule verification logic corresponding to the specific customs clearance compliance rules; inputting the cryptographic digest value into the zero-knowledge proof generator, which then performs compliance verification on the cryptographic digest value based on the rule verification logic; and if the verification passes, the zero-knowledge proof generator generates a zero-knowledge proof to prove that the enterprise's document data complies with the specific customs clearance compliance rules.

[0115] Specifically, refer to Figure 5 As shown, the enterprise node's contract layer also includes an encryption module and a ZKP generator for rule verification. Further, refer to... Figure 7 As shown, based on different target customs clearance countries, this ZKP generator includes, for example, a CCC certification ZKP generator and a CE certification ZKP generator. The encryption module encrypts document data element 1 and document data element 2 extracted by the NLP module, generating a cryptographic digest value corresponding to CCC certification (i.e., document data hash value 1) and a cryptographic digest value corresponding to CE certification (i.e., document data hash value 2). Then, document data hash value 1 and document data hash value 2 are input into the ZKP generator. The CCC certification ZKP generator in the ZKP generator performs rule verification on document data hash value 1, generating the corresponding zero-knowledge proof (corresponding to...). Figure 7 (proof1 in the document). The CE certification ZKP generator performs rule verification on the hash value 2 of the document data, generating the corresponding zero-knowledge proof (corresponding to...). Figure 7 (proof2 in the middle).

[0116] Furthermore, each ZKP generator encapsulates a Solidity logic tree (used for rule validation) corresponding to a specific customs clearance compliance rule, and the Solidity logic tree includes all rules corresponding to that specific customs clearance compliance rule. For example, refer to... Figure 8 As shown, the Solidity logic tree in the CE certification ZKP generator includes various rules corresponding to CE certification rules. For example, Rule 1: An EMC report must be included; Rule 2: Validity period ≥ 1 year; and Rule 3: Product nameplate information (such as model, specifications, and manufacturer) conforms to the format and content requirements of Chinese mandatory standards. After inputting the document data hash value 2 into the CCC certification ZKP generator, the CE certification ZKP generator uses its internal Solidity logic tree to verify the rules. If the rule verification passes, it generates the corresponding zero-knowledge proof (proof2) to prove that the company's document data complies with CE certification rules.

[0117] The ZKP generator operates based on a predefined zero-knowledge proof circuit template. This template first takes a document hash and a private key as input, then verifies a match through internal circuit logic (e.g., calculating the hash of the private key and comparing it to the provided document hash). If a match is found, a valid signal is output, proving that the company not only possesses the correct document data, but that the data itself generated the hash and has not been tampered with. This transforms complex compliance rule verification into a verifiable mathematical relationship.

[0118] Specifically, the generation process of this zero-knowledge proof is executed off-chain. The ZKP generator takes the hash value of the certificate data and a private key as input, runs a pre-built zero-knowledge proof circuit (such as the Groth16 algorithm), and finally outputs proof data containing parameters such as a, b, c and commitment, which serves as the zero-knowledge proof.

[0119] Similarly, the Solidity logic tree encapsulated in the CCC certification ZKP generator includes various rules corresponding to the CCC certification rules. After inputting the document data hash value 1 into the CCC certification ZKP generator, the CCC certification ZKP generator uses its Solidity logic tree to verify the rules. If the rule verification passes, it generates the corresponding zero-knowledge proof (proof1) to prove that the enterprise's document data complies with the CCC certification rules.

[0120] Thus, by calling a locally pre-built ZKP generator specifically designed for different customs clearance rules, enterprise nodes can automatically generate verifiable compliance credentials without leaving the local machine, providing critical privacy protection verification capabilities for core business logic.

[0121] To clearly and completely demonstrate the entire process of enterprise nodes transforming original documents into customs clearance verification certificates and storing them on the main chain, and to intuitively illustrate the data flow and collaboration relationships between the application layer and contract layer modules, refer to Figure 9 As shown, the process of putting enterprise node documents on the blockchain includes:

[0122] 1. Enterprise nodes use the OCR module in their application layer to perform OCR recognition on scanned documents and convert them into preliminary structured documents / data;

[0123] 2. The OCR module sends the initial structured documents / data to the NLP module deployed within the main chain contract layer of the enterprise node;

[0124] 3. The NLP module accurately extracts document data elements corresponding to specific customs clearance compliance rules from the received structured documents / data based on pre-set rule templates (such as CCC certification rule templates and CE certification rule templates);

[0125] 4. The NLP module sends the extracted document data elements to the encryption module, which is also located in the main chain contract layer;

[0126] 5. The encryption module encrypts the data elements of the document, generates its cryptographic digest value (hash value), and generates a private key for zero-knowledge proof (as witness information private to the prover).

[0127] 6. The encryption module sends the generated hash value (as public input) and the private key (as private input) to the ZKP generator, which is also located in the main chain contract layer;

[0128] 7. The ZKP generator is based on a pre-built verification logic (Solidity logic tree) corresponding to customs clearance compliance rules, and uses the input data to generate zero-knowledge proofs (Proofs) that can prove that the document data complies with the rules.

[0129] 8. Enterprise nodes combine the hash values ​​of document data elements, zero-knowledge proofs, and necessary public data (such as customs declaration numbers) into customs clearance verification credentials, and store them on the blockchain in the main chain's data layer.

[0130] Through the above methods, enterprise nodes achieve end-to-end automated processing from physical documents to trusted on-chain credentials. This not only seamlessly integrates cryptographic technologies such as zero-knowledge proofs into business operations, ensuring secure sharing of document data and preventing privacy leaks, but also clarifies the responsibilities of each stage through modular design, providing a solid technical foundation for the core paradigm of "one-time submission, multi-party reuse."

[0131] Optionally, the second smart contract is deployed on the sidechain by the rule maintenance node on the main chain through the following steps: obtaining the customs clearance compliance rules issued by the legislative body; extracting rule elements from the customs clearance compliance rules and formalizing the rule elements into verification logic that can be executed by the second smart contract; and deploying the second smart contract with the verification logic to the corresponding sidechain through cross-chain operations.

[0132] Specifically, refer to Figure 10As shown, the application layer of the rule maintenance node includes a rule acquisition module, which automatically retrieves or receives the original text of customs clearance compliance rules (such as newly promulgated technical standards, certification catalog updates, etc.) from the API interfaces, websites, or databases of legislative and / or administrative regulatory departments. The contract layer of the rule maintenance node includes a rule processing module. Using its built-in Natural Language Processing (NLP) capabilities, the module identifies and extracts key elements from the acquired rule text (e.g., identifying the applicable certification type, required document types, validity period requirements, key technical parameters, etc.), and formalizes it into structured logical statements that can be executed by smart contracts (e.g., Solidity code snippets). Subsequently, the rule maintenance node encapsulates the formalized verification logic into a second smart contract and deploys this contract to the specific sidechain corresponding to its rule by calling the cross-chain bridging service provided by the decentralized verification network.

[0133] Thus, by automatically parsing the legal texts of various countries and generating executable code through Natural Language Processing (NLP), administrative regulations described in natural language are automatically and accurately transformed into digital rules that can be automatically executed on the blockchain. This ensures that the sidechain verification logic is synchronized with the latest laws and regulations, laying a solid foundation for the compliance of the entire system.

[0134] Optionally, the rule maintenance node is also used to perform the following operations: monitor whether the customs clearance compliance rules issued by the legislature have been updated; if the customs clearance compliance rules issued by the legislature have been updated, extract new rule elements from the updated customs clearance compliance rules and formalize the new rule elements into new verification logic; and redeploy the updated second smart contract, which encapsulates the new verification logic, to the corresponding sidechain through cross-chain operations to replace the original second smart contract.

[0135] Specifically, refer to Figure 10 As shown, the application layer of the rule maintenance node also includes a rule monitoring module. This module periodically (e.g., timed polling) or event-driven (e.g., subscribing to RSS updates) monitors the monitored rule sources. It intelligently identifies rule updates by comparing version numbers, publication dates, or content hash values. Once an update is detected, the rule monitoring module triggers the rule acquisition and processing flow. The rule processing module extracts the new rule elements and formalizes them into new verification logic, generating an updated second smart contract version. Finally, the rule maintenance node deploys the new contract to the target sidechain via cross-chain operations (usually through version upgrades or contract replacements), ensuring the sidechain's verification capabilities are synchronized with regulatory changes in real time. Furthermore, the sidechain uses DPoS consensus, supporting thousands of rule update requests per second.

[0136] This endows the entire customs clearance system with the ability to dynamically adapt to changes in regulations, avoids business interruptions or compliance risks caused by outdated rules, and enables continuous online and seamless updates of the verification logic, ensuring the long-term effectiveness, agility and reliability of the cross-border trade customs clearance process.

[0137] In addition, refer to Figure 11 As shown, the contract layer of the verification node on the sidechain includes a ZKP rule verification module and a result feedback module. Specifically, the ZKP rule verification module encapsulates the verification logic of the second smart contract. Its core is a pre-compiled zero-knowledge proof (ZKP) verifier, which uses algorithms such as Groth16 to reduce the proof size and controls the verification time to the millisecond level, effectively improving the performance of the ZKP verifier. When the verification node receives a verification request and related data (including the hash value of the certificate data, the zero-knowledge proof, and public data) from the main chain, it calls the ZKP rule verification module to perform rule verification. The execution entry point of this ZKP rule verification module is a function similar to verifyCertificate. This function takes the received proof data (a, b, c, commitment, etc.) and public input (such as the certificate hash) as parameters and calls the underlying verification contract to perform mathematical calculations. The verification process does not touch the original certificate content, but strictly verifies the validity of the proof, that is, confirms whether the enterprise has real data that meets specific customs clearance compliance rules (such as "must hold a valid CCC certification"), and outputs a boolean verification result (true / false). The result feedback module is responsible for business-orientedizing this Boolean result, mapping it to a state with clear business meaning, such as "pass" or "rectification," and possibly including the reason for failure. Subsequently, the result feedback module encapsulates this final verification result into a blockchain transaction and reliably sends it back to the main chain through the cross-chain bridging service provided by the decentralized verification network, completing the closed loop of this verification task.

[0138] Thus, through the collaborative work of these two modules, the verification nodes on the sidechain achieve automated and privacy-protected compliance verification of requests to the main chain, and anchor the tamper-proof verification conclusions back to the main chain's public ledger, ensuring the auditability of the entire verification process and the credibility of the final result, providing a crucial and reliable basis for core customs clearance decisions.

[0139] It should be noted that the second smart contract is specifically embodied as a customs clearance document ZKP verification contract. This contract initializes a pre-compiled Groth16 validator instance during construction. Internally, the contract uses a public mapping structure to track the hashes of successfully verified documents to prevent redundant proofs from consuming resources. Its core is a public verification function designed according to the Groth16 proof verification input specification, requiring proof data (including point a, matrix b, point c, and commitment value) and the document hash as public input. During function execution, it delegates cryptographic verification to the underlying Groth16 validator, updates its internal state based on the verification result, triggers verification events, and ultimately returns a boolean value indicating whether the entire document data set meets the specific customs clearance compliance rules carried by the sidechain.

[0140] In this embodiment of the invention, a flexible and practical aggregation strategy is adopted in the implementation of the sidechain smart contract. Customs clearance compliance rules and Solidity logic tree verification contracts are not forcibly bound one-to-one. To reduce management costs and optimize gas efficiency, the system allows multiple logically related or frequently updated customs clearance compliance rules to be integrated into the same verification contract. Within such aggregated contracts, each rule typically corresponds to an independent judgment function, coordinated and called by a main verification function, using assertion statements to ensure that all conditions are met. This design effectively reduces the number of on-chain contracts while maintaining code modularity and clarity, and minimizes the frequency of contract upgrades due to rule updates by grouping stably changing rules, thereby enhancing the stability and scalability of the entire system.

[0141] Optionally, the method further includes: IoT nodes uploading received detection data to the main chain via a decentralized relay network; and port management nodes obtaining detection data from the main chain and using the detection data to cross-validate customs clearance verification certificates. The decentralized relay network is configured to: perform spectral analysis on the decentralized relay network and delete insecure relay nodes based on the results of the spectral analysis.

[0142] For specific references Figure 2 As shown, IoT nodes communicate with the main chain through a decentralized relay network, thereby uploading the detection data received from the sensors to the main chain via the decentralized relay network.

[0143] in Figure 12 A further schematic diagram of a decentralized relay network is shown. (Reference) Figure 12 As shown, a decentralized relay network consists of multiple repeaters, thus referencing... Figure 13 As shown, a corresponding graph structure can be constructed based on the signal connectivity between each repeater. Nodes RN1 to RN2 are shown. L Each corresponds to a separate repeater.

[0144] To prevent attacked or tampered repeaters from participating in data transmission, a penalty mechanism is introduced for each repeater. Specifically, if a repeater fails to transmit data, resulting in the failure to upload detection data to the blockchain (i.e., "malicious behavior" as described below), a corresponding number of points are deducted from that repeater. The number of points deducted for a single malicious act varies among different repeaters.

[0145] In this embodiment, by... Figure 13 The graph structure shown is analyzed to determine the weighting coefficients for deducting the integral for each repeater. Therefore, in the event of a failure to upload detection data to the chain, the integral to be deducted from the malicious repeater is determined based on the corresponding weighting coefficients.

[0146] Therefore, according to the technical solution of this application, the importance of different repeaters in a decentralized relay network can be determined through spectral analysis. The weighting coefficient for deducting the integral of each repeater can then be determined based on its importance. In this way, the impact of malicious behavior by highly important repeaters on the entire decentralized relay network can be reduced more accurately.

[0147] Optionally, the operation of performing spectral analysis on the decentralized relay network and deleting insecure relay nodes based on the results of the spectral analysis includes: constructing a relay graph structure corresponding to the decentralized relay network, wherein the relay graph nodes in the relay graph structure correspond to repeaters, and the connection relationships between the relay graph nodes correspond to the actual signal connectivity relationships between the repeaters; performing spectral analysis on the relay graph structure to determine the eigenvector centrality of each relay graph node; and determining the weight for deducting the integral for each repeater based on the eigenvector centrality.

[0148] Specifically, as mentioned above, this application constructs a corresponding relay graph structure for decentralized relay networks, such as... Figure 13 As shown.

[0149] Then, determine the adjacency matrix A∈R corresponding to the decentralized verification network. L*L The element a of the adjacency matrix A i,j (i,j = 1 to L) are assigned values ​​as follows:

[0150] a i,j =1, if RN i With RN j Connected;

[0151] a i,j =0, if RN i With RN j Not connected; and

[0152] ai,i =0.

[0153] Then, based on the adjacency matrix A, determine the RN of each node. i eigenvector centrality c i :

[0154] Let C = [c1, c2, ..., c L ] T Then it is calculated using the following formula:

[0155] AC = λC, where

[0156] λ is the largest eigenvalue of the adjacency matrix A.

[0157] Then, based on each repeater node RN1~RN L The corresponding eigenvector centrality c1~c L Then determine the weights corresponding to each repeater. For example, the eigenvector centrality c1 to c2 can be directly assigned. L As the weights corresponding to each repeater.

[0158] Therefore, when a failure occurs in the detection data uploading process, the corresponding points will be deducted from the repeater for the malicious behavior, based on the repeater's weight.

[0159] Optionally, each repeater counts the repeaters with the most malicious behavior to be deleted at predetermined intervals; then each repeater votes on the repeaters to be deleted and deletes the corresponding repeaters according to the voting results.

[0160] Specifically, in the scheme of this application, each relay in the decentralized relay network will record the malicious relay that caused the on-chain failure during the transmission of detection data.

[0161] For example, when repeaters 1, 2, and 3 are transmitting detection data to the main chain, the on-chain data is successfully transmitted from repeater 1 to repeater 2, and from repeater 2 to repeater 3. However, if repeater 3 fails to transmit the data (malicious behavior), repeaters 1 and 2 will record that repeater 3 has committed a malicious act.

[0162] Similarly, within a preset period, the relayer records the frequency of malicious relayers among all the on-chain failures it experiences. This information is used to identify the malicious relayers that voted for the correct outcome.

[0163] Each repeater then votes on the malicious repeaters it has identified, and the repeater with the most votes is selected as the target for deletion.

[0164] IoT devices generally suffer from weak security and are easily accessed and tampered with. If a device is compromised, the sensor data it generates and the transactions it initiates may be malicious, or involve garbage data entering and exiting the network. Even the most secure on-chain and cross-chain protocols cannot prevent data source corruption. Malicious data entering the main chain via cross-chain bridges contaminates the ledger, causing smart contract execution errors, and is difficult to trace and correct afterward. Therefore, this application's technical solution uses a decentralized approach, where each relay votes on its identified malicious relays to determine which relays to remove. This effectively excludes attacked relays, ensuring that detection data remains untouched and unaffected after passing through the decentralized relay network.

[0165] In addition, the method also includes restoring repeaters that were deleted before a preset period. That is, after a repeater is deleted, it is not completely removed from use, but rather restored to use after a preset period.

[0166] In addition, optionally, the method also includes: the main chain node performing contextual credibility reasoning based on the received detection data and a pre-defined knowledge graph.

[0167] As mentioned above, IoT devices generally suffer from weak security and are easily accessed and tampered with. If a device is compromised, the sensor data it generates and the transactions it initiates may be malicious, or they may contain garbage data flowing in and out. No matter how secure the on-chain and cross-chain protocols are, they cannot solve the problem of data source fraud. Malicious data entering the main chain through cross-chain bridges will pollute the ledger, causing smart contract execution errors, and making it difficult to trace and correct them afterward.

[0168] In view of this, the main chain node performs contextual credibility reasoning based on the received detection data and a pre-defined knowledge graph. Specifically, the technical solution of this application utilizes a knowledge graph to determine the credibility of the data source.

[0169] In this application, each IoT device, the gateway connecting the IoT device, its geographical location, device model, and sidechain node are considered an entity. Therefore, a rich set of relationships can be defined to identify the trustworthiness of an entity, such as the device's geographical location (BeiDou positioning), device model, gateways the device has communicated with, the data type submitted by the device, the geographical location of the sidechain node, and the rule-based division of labor of the sidechain node. Furthermore, the entity's historical behavioral data (average reporting frequency, data range, power consumption characteristics, etc.) are also used as its operational attributes.

[0170] Therefore, when an IoT device initiates a transaction (uploads data), the main chain verifies the credibility of the data source and uses the knowledge graph to perform context (runtime environment) credibility reasoning.

[0171] For example:

[0172] 1) Anomaly detection. A CT scan device located at a Xinjiang port suddenly reported BeiDou coordinates from Beijing; a sidechain node responsible for RCEP rules provided feedback on the verification status of an EU inspection and testing report;

[0173] 2) Correlation verification. If a device reports abnormal data, but other similar devices connected to the same gateway report normal data, the knowledge graph can infer that the single device may have been tampered with or malfunctioned, thereby reducing the weight of its data or directly triggering an alarm;

[0174] 3) Reputation propagation. If multiple devices under a gateway are marked as malicious, the gateway's own credibility will decrease, which in turn will affect its credibility in managing all devices.

[0175] Therefore, by using the above methods, the problem of data source fraud caused by the intrusion of IoT devices can be effectively avoided.

[0176] In addition, refer to Figure 1 As shown, according to a second aspect of this embodiment, a storage medium is provided. The storage medium includes a stored program, wherein, when the program is executed, a processor performs any of the methods described above.

[0177] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0178] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0179] Example 2

[0180] This embodiment provides a trusted customs clearance system based on blockchain and spectral analysis, corresponding to the method described in Embodiment 1. The trusted customs clearance system includes a main chain and at least one side chain, with a decentralized verification network established between the main chain and each side chain. Nodes on the main chain include port management nodes and enterprise nodes; nodes on the side chains include verification nodes; the decentralized verification network includes multiple verification nodes that independently perform verification and provides a cross-chain bridge between the main chain and the side chains; the port management node is configured to: respond to a customs clearance request, invoke a first smart contract on the main chain to obtain a customs clearance verification certificate pre-stored on the main chain by the enterprise node; wherein the customs clearance verification certificate includes a cryptographic digest value generated based on enterprise document data and a corresponding zero-knowledge proof; and transmit the customs clearance verification certificate and the corresponding verification request via the first smart contract through a preset decentralized verification network. The centralized verification network sends data to the corresponding sidechain. Each sidechain has a pre-built second smart contract, which encapsulates verification logic corresponding to specific customs clearance compliance rules. Verification nodes are configured to: respond to verification requests, invoke the second smart contract, verify the validity of the zero-knowledge proof based on the verification logic, and generate a verification result; return the verification result to the main chain via the decentralized verification network. The decentralized verification network is configured to: perform spectroscopic analysis on the decentralized verification network, determine a verification node group from multiple verification nodes to vote on the cross-chain data sent from the source blockchain; vote on the cross-chain data through the verification node group, and send the cross-chain data to the target blockchain based on the voting results.

[0181] Optionally, the enterprise node configuration is used to: extract document data elements corresponding to specific customs clearance compliance rules from the original enterprise document data; generate corresponding cryptographic digest values ​​based on the document data elements; generate zero-knowledge proofs to prove that the enterprise document data complies with specific customs clearance compliance rules based on the cryptographic digest values ​​and specific customs clearance compliance rules; and combine the cryptographic digest values ​​and zero-knowledge proofs into customs clearance verification credentials and upload them to the main chain for evidence storage.

[0182] Therefore, according to this embodiment, a customs clearance verification certificate based on a one-time submission is realized, completing a fully automated customs clearance verification process that is specific to a particular country, protects privacy, and fully embodies the efficient model of one-time submission and multi-party reuse. This solves the technical problems existing in cross-border trade document processing solutions, such as inefficiency due to participants having to repeatedly submit documents, rigid rule processing that cannot be automatically adapted, data privacy leakage risks, performance bottlenecks of a single blockchain architecture, and insufficient trustworthiness of cross-chain interactions.

[0183] It should be noted that the trusted customs clearance system in Embodiment 2 and the trusted customs clearance method in Embodiment 1 belong to the same inventive concept, solve the same technical problem, adopt the same technical means, and achieve the same technical effect. The similarities will not be repeated here.

[0184] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0185] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0186] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0187] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0188] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0189] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0190] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A trusted customs clearance method based on blockchain and spectral analysis, characterized in that, include: In response to the customs clearance request, the port management node invokes the first smart contract on the main chain to obtain the customs clearance verification certificate pre-stored on the main chain by the enterprise node; wherein, the customs clearance verification certificate includes a cryptographic digest value generated based on the enterprise's document data and the corresponding zero-knowledge proof; The port management node sends the customs clearance verification certificate and the corresponding verification request to the corresponding sidechain via the first smart contract through a preset decentralized verification network; wherein, the decentralized verification network includes multiple verification nodes that perform independent verification and provides a cross-chain bridge between the main chain and the sidechain, and the sidechain is pre-configured with a second smart contract, which encapsulates verification logic corresponding to specific customs clearance compliance rules. In response to the verification request, the verification node on the sidechain invokes the second smart contract to verify the validity of the zero-knowledge proof and generates a verification result; and The verification node returns the verification result to the main chain via the decentralized verification network; and wherein the decentralized verification network is configured for: Spectral analysis is performed on the decentralized verification network to determine a group of verification nodes from the plurality of verification nodes to perform verification voting on the cross-chain data sent from the source blockchain; and The cross-chain data is verified and voted on by the verification node group, and the cross-chain data is sent to the target blockchain according to the verification vote result.

2. The method according to claim 1, characterized in that, Before performing spectral analysis on the decentralized verification network, the method further includes: Construct a graph structure corresponding to the decentralized verification network, wherein the verification nodes of the decentralized verification network correspond to the nodes in the graph structure, and the edges between the verification nodes are related to the consistency of the verification votes between the verification nodes, and wherein... Spectral analysis of the decentralized verification network, and the operation of determining the verification node group from the plurality of verification nodes for verifying and voting on cross-chain data sent from the source blockchain, includes: According to a pre-set number, the verification nodes of the decentralized verification network are randomly selected to determine multiple candidate verification nodes; According to preset constraints, multiple chromosome vectors are randomly generated, wherein each bit of the chromosome vector corresponds to a different candidate verification node, which is used to indicate whether the corresponding candidate verification node is selected as the target verification node for verification voting. Define a fitness function, wherein the fitness function is positively correlated with the algebraic connectivity of the target validation nodes corresponding to the chromosome vector and negatively correlated with the number of target validation nodes corresponding to the chromosome vector; The optimal chromosome vector is determined by iterative genetic algorithm applied to the plurality of chromosome vectors based on the fitness function; and The optimal chromosome vector is used to determine the group of verification nodes that will vote on the cross-chain data sent from the source blockchain.

3. The method according to claim 1, characterized in that, Before constructing the graph structure corresponding to the decentralized verification network, the following steps are also included: By means of voting operations among the verification nodes of the decentralized verification network, some verification nodes of the decentralized verification network are deleted, wherein the voting operation is used to determine the verification nodes with the lowest voting consistency in the decentralized verification network; and Restore verification nodes that were deleted before the scheduled period.

4. The method according to claim 1, characterized in that, The enterprise node stores the customs clearance verification certificate on the main chain through the following steps: Extract document data elements corresponding to the specific customs clearance compliance rules from the original enterprise document data; Generate a corresponding cryptographic digest value based on the document data elements; Based on the cryptographic digest value and the specific customs clearance compliance rules, generate a zero-knowledge proof to prove that the enterprise's document data complies with the specific customs clearance compliance rules; as well as The cryptographic digest value and the zero-knowledge proof are combined into the customs clearance verification certificate and uploaded to the main chain for evidence storage.

5. The method according to claim 4, characterized in that, The operation of generating a zero-knowledge proof to prove that the enterprise's document data complies with the specific customs clearance compliance rules based on the cryptographic digest value and the specific customs clearance compliance rules includes: Invoke a locally deployed zero-knowledge proof generator; wherein, the zero-knowledge proof generator has pre-set rule verification logic corresponding to the specific customs clearance compliance rule; The cryptographic digest value is input into the zero-knowledge proof generator, which then performs a compliance check on the cryptographic digest value based on the rule verification logic; and If the verification passes, the zero-knowledge proof generator generates a zero-knowledge proof to prove that the enterprise's document data complies with the specific customs clearance compliance rules.

6. The method according to claim 1, characterized in that, The second smart contract is deployed on the sidechain by the rule maintenance node on the main chain through the following steps: Obtain customs clearance compliance rules issued by the legislature; Extract rule elements from the customs clearance compliance rules and formalize the rule elements into verification logic that can be executed by the second smart contract; as well as The second smart contract, which encapsulates the verification logic, is deployed to the corresponding sidechain via cross-chain operations.

7. The method according to claim 6, characterized in that, The rule maintenance node is also used to perform the following operations: Monitor whether the customs clearance compliance rules issued by the aforementioned legislative body are updated; If the customs clearance compliance rules issued by the legislative body are updated, new rule elements are extracted from the updated customs clearance compliance rules, and the new rule elements are formalized into new verification logic. as well as The updated second smart contract, which encapsulates the new verification logic, is redeployed to the corresponding sidechain via cross-chain operations to replace the original second smart contract.

8. A storage medium, characterized in that, The storage medium includes a stored program, wherein, when the program is executed, the method described in any one of claims 1 to 7 is performed by a processor.

9. A trusted customs clearance system based on blockchain and spectral analysis, characterized in that, It includes a main chain and at least one side chain, and a decentralized verification network is set between the main chain and each side chain; the nodes on the main chain include port management nodes and enterprise nodes; the nodes on the side chain include verification nodes; the decentralized verification network includes multiple verification nodes that perform verification independently, and provides a cross-chain bridge between the main chain and the side chain; The port management node is configured to: respond to a customs clearance request, invoke a first smart contract on the main chain to obtain a customs clearance verification certificate pre-stored on the main chain by the enterprise node; wherein the customs clearance verification certificate includes a cryptographic digest value generated based on the enterprise's document data and a corresponding zero-knowledge proof; send the customs clearance verification certificate and the corresponding verification request to the corresponding side chain via a preset decentralized verification network through the first smart contract; wherein the side chain is pre-configured with a second smart contract, the second smart contract encapsulating verification logic corresponding to specific customs clearance compliance rules; The verification node is configured to: respond to the verification request, invoke the second smart contract, verify the validity of the zero-knowledge proof based on the verification logic, generate a verification result, and return the verification result to the main chain via the decentralized verification network; The decentralized verification network is configured to: perform spectroscopic analysis on the decentralized verification network to determine a group of verification nodes from the plurality of verification nodes to perform verification voting on the cross-chain data sent by the source blockchain; perform verification voting on the cross-chain data through the verification node group; and send the cross-chain data to the target blockchain according to the verification voting results.

10. The system according to claim 9, characterized in that, The enterprise node configuration is used for: Extract document data elements corresponding to the specific customs clearance compliance rules from the original enterprise document data; Generate a corresponding cryptographic digest value based on the document data elements; Based on the cryptographic digest value and the specific customs clearance compliance rules, generate a zero-knowledge proof to prove that the enterprise's document data complies with the specific customs clearance compliance rules; as well as The cryptographic digest value and the zero-knowledge proof are combined into the customs clearance verification certificate and uploaded to the main chain for evidence storage.

Images