A multi-level supply chain-oriented data privacy protection processing method and system

Abstract

The present application relates to the technical field of information security and distributed computing, and provides a data privacy protection processing method and system for a multi-level supply chain. In order to solve the problem that the traditional right verification cannot complete effective compliance verification without accessing the original transaction pricing data, the method creates a genesis fingerprint based on the unique identity credential generated by the core enterprise based on the physically unclonable feature and the total amount of right verification credit hash value and links it, the supplier end links the upper level path fingerprint, the physically unclonable feature credential and the split amount hash value to generate the current path fingerprint and links it when splitting, and the financial institution end recalculates the path fingerprint chain, compares the amount hash value and queries the on-chain state identifier, thereby realizing compliance verification of the credit certificate without accessing any original transaction pricing data, and significantly improving the data security and right verification credibility in the multi-level supply chain financial scene.

Description

Technical Field

[0001] This invention relates to the fields of information security and distributed computing technology, and particularly to hardware security modules and cryptographic verification technology, specifically to a data privacy protection processing method and system for multi-level supply chains. Background Technology

[0002] Supply chain data privacy protection processing refers to the process of reliably verifying the generation, splitting, transfer, and financing status of debt instruments without disclosing privacy data such as the original transaction pricing between the participants in the supply chain. In multi-level supply chain finance, privacy protection and compliant confirmation of rights are its core technical aspects.

[0003] Taking a typical multi-tiered supply chain finance scenario as an example: Core enterprise A purchases raw materials from its first-tier supplier B, creating an accounts payable of 1 million yuan, and issues electronic debt certificates to confirm the authenticity of the debt. To recover funds early, first-tier supplier B splits the debt into two parts: 300,000 yuan and 700,000 yuan. The 300,000 yuan debt certificate is then transferred to second-tier supplier C to pay for its own purchases. Second-tier supplier C, holding the 300,000 yuan debt certificate, applies for financing from bank D. During this process, bank D needs to verify the true source of the debt certificate held by second-tier supplier C, the accuracy of its declared amount, and whether the certificate has been repeatedly pledged. However, the original contract and transaction pricing data between first-tier supplier B and core enterprise A are core trade secrets of B and should not be disclosed during the verification process.

[0004] In traditional technologies, the following methods are commonly used to achieve data privacy protection and rights verification in the aforementioned scenarios: First, based on attribute-based encryption or homomorphic encryption, sensitive data such as contracts and transaction base prices are encrypted and stored, and bank D decrypts the data to obtain the plaintext for verification. Second, based on zero-knowledge proofs, a first-tier supplier B generates a cryptographic proof of the authenticity of the transaction data, and bank D verifies this proof rather than the original data to complete the rights verification. Third, based on trusted third parties or consortium blockchains, a core enterprise A or platform signs and endorses the debt certificate, and bank D verifies the signature to confirm the validity of the debt. The common technical logic followed by the above methods is that rights verification, in its computational logic, relies on the processing and disclosure of the original data or its derivative forms to be protected. Regardless of the cryptographic means used, the information connection between the verification process and the original data is not severed.

[0005] However, the aforementioned traditional technologies face a fundamental technical dilemma: privacy protection and compliance-based rights confirmation constitute a pair of mutually exclusive constraints in terms of technical implementation. To meet Bank D's compliance review requirements regarding the authenticity, legality of the source, and lack of double pledging of the debt, the original transaction pricing data that generated the debt must be provided or processed during the verification process. However, once this data is provided or processed, it is easy to expose the trade secrets between Tier 1 supplier B and core enterprise A, such as the actual transaction price, total amount, and other trade privacy and confidential data, putting B at a disadvantage in subsequent business negotiations.

[0006] The core reason for this technical dilemma lies in the prevailing view in the field that rights verification typically involves accessing or processing the original transaction pricing data that generated the claim in some form, and the trust foundation for verification is built upon direct or indirect confirmation of the data content. Consequently, the industry usually focuses on optimizing the efficiency and security of cryptographic algorithms, attempting to find a balance between "disclosure" and "concealment" through more effective encryption schemes or proof systems. However, this approach of building trust based on data content inherently cannot eliminate the inherent contradiction between privacy protection and compliant rights verification—any processing of the original data, even encryption or proof generation, will more or less expose some information that should originally be kept confidential, and the starting point of trust is always based on reproducible digital data, failing to provide universal, completely decoupled rights verification evidence from the data content for multi-level circulation scenarios. Therefore, traditional rights verification mechanisms, by default, rely on the original data content in their computational logic, and typically cannot complete effective compliant verification without accessing the original transaction pricing data.

[0007] Therefore, how to verify the authenticity of digital debt instruments circulating in a multi-level supply chain, the legality of their source, and the fact that they have not been repeatedly pledged, without accessing any original transaction pricing data, has become a pressing technical problem to be solved in the field of supply chain data privacy protection. Summary of the Invention

[0008] To address the aforementioned technical issues, this invention provides a data privacy protection processing method and system for multi-level supply chains. By introducing the physical non-cloning property to generate unique identity credentials as a root of trust, and constructing a path fingerprint chain decoupled from monetary data, this method differs from traditional trust-building models that rely on encrypting, proving, or signing the original data content. It can achieve compliant rights confirmation without accessing the original transaction pricing data, significantly improving data security and the credibility of rights confirmation in multi-level supply chain finance scenarios.

[0009] To address the aforementioned technical problems, in a first aspect, this invention provides a data privacy protection processing method for multi-level supply chains, comprising: A core enterprise responding to a debt confirmation request obtains a unique identity credential generated and stored on its own end based on the physical non-cloning characteristic; and generates a genesis fingerprint through hash operation based on the unique identity credential, the core enterprise's identity identifier, and the hash value of the total amount of the confirmed debt, and records it in a distributed ledger; When a first supplier splits and transfers debt, it obtains the upstream path fingerprint and its unique identity credential generated and stored on its own end based on the physical non-cloning characteristic; and generates a current path fingerprint through hash operation based on the upstream path fingerprint, its unique identity credential, its own identity identifier, and the hash value of the split amount; and records the transfer transaction containing the current path fingerprint in the distributed ledger, wherein the upstream path fingerprint is the genesis fingerprint or generated by its directly upstream supplier. The second supplier generates a path fingerprint; when initiating a financing request, it submits the target path fingerprint, target amount, and path public field sequence tracing back to the genesis fingerprint corresponding to the target debt. The target path fingerprint is either generated based on the initial split of the genesis fingerprint or generated when split and transferred by the direct upstream supplier of the second supplier. The financial institution receives the financing request and generates a verification path fingerprint by recalculating the path public field sequence. It compares the hash value of the target amount with the hash value of the amount contained in the target path fingerprint to verify the consistency of the amount without knowing the original amount of the upstream supplier. It also queries the on-chain status identifier of the target path fingerprint, thereby completing the compliance verification of the path validity, amount authenticity, and status uniqueness of the target debt without accessing the original transaction pricing data.

[0010] Secondly, this invention provides a data privacy protection processing system for multi-level supply chains, comprising: a core enterprise module, used to respond to debt confirmation requests, obtain a unique identity credential generated and stored on its own end based on the physical non-cloning characteristic, and generate a genesis fingerprint through hash operation based on the unique identity credential, the core enterprise's identity identifier, and the hash value of the total amount of the confirmed debt, and record it in the distributed ledger; and a first supplier module, used to obtain the upper-level path fingerprint and its unique identity credential generated and stored on its own end when debt is split and transferred, and generate a current path fingerprint through hash operation based on the upper-level path fingerprint, its unique identity credential, its own identity identifier, and the hash value of the split amount, and record the transfer transaction containing the current path fingerprint in the distributed ledger, wherein the upper-level path fingerprint is the genesis fingerprint or generated by its directly upper-level supplier. The system comprises: a path fingerprint; a second supplier-side module, used to submit, when initiating a financing request, the target path fingerprint corresponding to the target debt, the target amount, and the path public field sequence tracing back to the genesis fingerprint, wherein the target path fingerprint is a path fingerprint generated based on the first split of the genesis fingerprint, or a path fingerprint generated when split and transferred by the direct superior supplier of the second supplier; and a financial institution-side module, used to receive the financing request, generate a verification path fingerprint by recalculating using the path public field sequence, compare the hash value of the target amount with the amount hash value contained in the target path fingerprint to verify the consistency of the amount without knowing the original amount of the superior, and query the on-chain status identifier of the target path fingerprint, thereby completing the compliance verification of the path validity, amount authenticity, and status uniqueness of the target debt without accessing the original transaction pricing data.

[0011] Beneficial Effects: In the solution implemented in this invention, a unique identity credential generated and stored on the core enterprise side based on the physical unclonable characteristic is obtained. Based on this credential, the core enterprise's identity identifier, and the hash value of the total amount of the confirmed debt, a genesis fingerprint is generated and recorded in the distributed ledger. This firstly achieves the physical anchoring of the root of trust and the on-chain proof of the amount commitment, ensuring that the source of the confirmed debt possesses the uniqueness of an unclonable device and an immutable amount boundary. Based on this, when the debt is split and transferred, the first supplier side links the fingerprint of the previous path, the physical unclonable credential of the current side, and the hash value of the split amount to generate the current path. By fingerprinting the path and recording it on the blockchain, a chain-based notarization of the debt transfer trajectory is achieved. The amount exists only in the form of a hash value, severing the information link between the verification process and the original transaction pricing data at the data structure level. On this basis, the financial institution uses the path public field sequence to recalculate and generate a verification path fingerprint to verify the validity of the path. The hash value of the target amount is compared with the hash value of the amount contained in the target path fingerprint to verify the consistency of the amount without knowing the original amount of the previous level. The on-chain status identifier of the target path fingerprint is queried to verify the uniqueness of the status, thus realizing three-dimensional compliance verification of the debt certificate.

[0012] By combining the aforementioned interconnected effects, a data privacy protection mechanism has been constructed, which consists of "physical non-clonable characteristics anchoring the root of trust, monetary hash values ​​decoupling data content, path fingerprint chains recording the flow trajectory, and triple verification completing compliance and rights confirmation."

[0013] Therefore, unlike the traditional trust-building model in which rights confirmation verification relies on processing the original data content or its derivatives in terms of computational logic, this invention shifts the trust foundation of rights confirmation from reproducible digital data to unclonable physical characteristics. It embeds monetary information into the path fingerprint chain in the form of a one-way hash commitment, transforming the traditional "data content-driven verification" model into a "physical identity anchoring + data content decoupling" model. Ultimately, this achieves compliant verification of the path validity, monetary authenticity, and state uniqueness of debt instruments without accessing any original transaction pricing data. This solves the technical problem raised in the background technology that "traditional rights confirmation verification mechanisms cannot achieve effective compliant verification without accessing original transaction pricing data due to their computational logic dependence on original data content." It fundamentally resolves the inherent contradiction between privacy protection and compliant rights confirmation, significantly improving data security and the credibility of rights confirmation in multi-level supply chain finance scenarios. Attached Figure Description

[0014] Figure 1 A flowchart illustrating the data privacy protection processing method for multi-level supply chains provided in an embodiment of the present invention; Figure 2This is a schematic diagram of the first sub-process of the data privacy protection processing method for multi-level supply chains provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the second sub-process of the data privacy protection processing method for multi-level supply chains provided in an embodiment of the present invention; Figure 4 A schematic block diagram of a data privacy protection processing system for multi-level supply chains provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0015] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to specific examples. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0016] This invention provides a data privacy protection processing method and system for multi-level supply chains. It can be a data processing engine hosted on a server or cloud platform, capable of driving supply chain finance applications including but not limited to the following multi-dimensional applications: First, in an accounts receivable electronic debt certificate circulation platform, by recalculating and verifying the path fingerprint chain and comparing the consistency of the amount hash at the financial institution's end, compliant confirmation of rights for multi-level debt certificates can be completed without obtaining the original transaction pricing data of the core enterprise and first-tier suppliers, supporting certificate splitting and circulation and financing disbursement; Second, in a bank's multi-level supplier financing review system, by verifying the continuity and consistency of the debt path at each level and querying the on-chain status identifier of the target path fingerprint, automated technical verification of the authenticity of debt and the uniqueness of assets in pre-loan review and post-loan management is achieved; Third, in a core enterprise's supply chain credit management platform, by anchoring the source of rights confirmation through a unique identity credential generated based on the physical non-cloning characteristic, reliable penetration transmission of credit to multi-level suppliers is achieved, providing an immutable on-chain data foundation for supplier hierarchical management and dynamic adjustment of credit limits. This invention addresses the inherent conflict between privacy protection and compliance-based rights confirmation, providing reusable core data security capabilities for the digital transformation of supply chain finance.

[0017] The following detailed description of some embodiments of the present invention is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0018] In the following embodiments, a multi-level supply chain finance platform is used as an exemplary application scenario to describe the technical solution of the present invention in detail. The composition of the application scenario, including example entities and data, can be summarized as follows: Core Enterprise A: A large enterprise that serves as the source of credit in the supply chain; First-tier supplier B: A first-tier supplier that provides products or services to core enterprise A; Second-tier supplier C: A second-tier supplier that provides products or services to first-tier supplier B; Financial institution D: refers to financial institutions (such as banks and other financing institutions) that have accessed the supply chain finance platform. Total amount of confirmed claims M: An electronic debt certificate of RMB 5 million issued by core enterprise A to its first supplier B; Split Amount S1: First Supplier B splits its 5 million yuan receivables into 1.2 million yuan to pay for goods to Second Supplier C; Target amount S2: The second supplier C intends to apply for RMB1 million in financing from bank D using the RMB1.2 million debt certificate.

[0019] It should be understood that the above specific business application scenarios are merely illustrative examples for ease of explanation. The technical solutions provided by this invention can be applied to any multi-level supply chain finance scenario where there are multiple levels of suppliers and privacy protection and compliant confirmation of rights for electronic debt instruments are required. Examples include, but are not limited to, multi-level distribution supply chains in the pharmaceutical distribution field, parts outsourcing processing chains in large equipment manufacturing, and procurement chains between brand owners and multi-level agents in the retail industry. Its application scope is not limited to these.

[0020] Example 1: A data privacy protection processing method for multi-level supply chains.

[0021] In this embodiment, please refer to Figure 1 , Figure 1 This is a flowchart illustrating a data privacy protection processing method for multi-level supply chains provided in an embodiment of the present invention. Figure 1 As shown, in this embodiment, the method includes the following steps S11-S14: S11: The core enterprise responds to the claim confirmation request, obtains a unique identity credential generated and stored on its own end based on the physical non-cloning characteristic, and generates a genesis fingerprint through hash operation based on the unique identity credential, the core enterprise identity identifier and the hash value of the total amount of the claim confirmed, and records it to the distributed ledger.

[0022] Core enterprise side: This refers to the computer system or node deployed by the core enterprise that serves as the source of credit in the supply chain. It has the ability to perform cryptographic operations, interact with the distributed ledger network, and invoke hardware security modules. For example, the core enterprise side can be an enterprise-grade server deployed with a blockchain SDK and a security encryption chip, operating as a network node in a supply chain finance platform, responsible for responding to debt confirmation requests and generating genesis fingerprints.

[0023] Supplier side: refers to the computer systems or nodes deployed by suppliers at various levels in the supply chain, which also possess cryptographic operations, network interaction, and hardware access capabilities. In this embodiment, to distinguish different operational roles, the entity performing the splitting and transfer operation is called the first supplier side, and the entity initiating the financing request is called the second supplier side. Both can be physically implemented as the same or different computer systems. Furthermore, the first supplier side can specifically be a first-level or multi-level supplier side, not just a single-level supplier side, but their processing logic in the technical solution is consistent. In the above example, it is assumed that the first supplier side B is a first-level supplier providing products or services to core enterprise A, and the second supplier side C is a second-level supplier providing products or services to first supplier B. However, in a more general description, for core enterprise A, the first supplier side B may include a (n-1)-level supplier, and the second supplier side C may be an n-level supplier, where n is a natural number greater than or equal to 2, and the n-level suppliers form an upstream and downstream business logic chain sequentially.

[0024] Physically unclonable characteristics: These refer to the unique and uncopyable physical characteristics of a chip generated by uncontrollable random physical differences introduced during the manufacturing process of the hardware chip. Physically unclonable characteristics constitute the physical basis of the root of trust in this invention. Implementation methods include, but are not limited to: 1) a PUF based on the initial power-on state of static random access memory (SRAM), which utilizes the physical characteristic that memory cells randomly bias towards a 0 or 1 state upon power-on due to differences in transistor threshold voltages during manufacturing; 2) a PUF based on the frequency difference of a ring oscillator, which utilizes the physical characteristic that delay paths of the same design generate different oscillation frequencies due to process variations. For example, in a specific implementation, a security encryption chip integrating SRAM PUF functionality can be used. This type of chip automatically reads the initial state value of a specific address in the SRAM region upon power-on, and after fuzzy extraction processing, generates a unique identity credential physically bound to the chip. This credential cannot be exported or copied during the chip's lifetime.

[0025] Unique identity credential: refers to a cryptographic identity credential generated using the physical non-cloning property, uniquely bound to a specific hardware device, and whose generation process cannot be copied or transferred. In this invention, the unique identity credential serves as the starting point for hash chain calculations, replacing the reproducible digital key in traditional technologies.

[0026] Genesis fingerprint: refers to the unique hash value generated by the core enterprise, serving as the starting point of trust for the entire debt transfer path. The genesis fingerprint anchors the cryptographic commitment of the core enterprise's physical identity and the total amount of the debt, and is the verification source for all subsequent path fingerprints.

[0027] The specific implementation of this step is as follows: First, the core enterprise receives a claim confirmation request initiated by the business system.

[0028] Secondly, the core enterprise terminal invokes a pre-defined hardware security module. This module contains a physically unclonable function circuit. The core enterprise terminal sends a pre-defined challenge signal to this circuit and receives a unique response signal generated by the circuit based on random physical differences introduced in its manufacturing process. Through error correction coding and fuzzy extraction, a stable and unique identity credential, denoted as Key_core, is generated. This generation process ensures that the identity credential is physically bound to the core enterprise terminal's hardware device and cannot be copied or migrated.

[0029] Secondly, the core enterprise side calls the cryptographic hash engine to perform hash operations, which can be described as follows: Genesis_Fingerprint = Hash (Key_core || ID_core || Hash(Total_Amount)); Wherein, ID_core is the unique identifier of the core enterprise within the system, Total_Amount is the total amount of the debt confirmed this time (e.g., 5 million yuan), Hash(Total_Amount) is the digest obtained by hashing the total amount, and || indicates data concatenation.

[0030] Finally, the core enterprise packages the publicly available information corresponding to this transaction, along with the generated genesis fingerprint (Genesis_Fingerprint), into a single transaction and sends it to the distributed ledger network for consensus verification before recording it. The distributed ledger refers to a distributed database using a consortium blockchain or private blockchain architecture, providing data sharing and notarization for multiple participants in the supply chain, and possessing the characteristics of immutability and traceability.

[0031] For example, core enterprise A generates its unique identity credential Key_core_A and calculates Hash(5 million) to obtain a 256-bit hash value. Then, it executes Hash(Key_core_A || “Core_A_ID” || Hash(5 million)) to obtain the genesis fingerprint F0, and records F0 and related information to the distributed ledger.

[0032] In step S11, a unique identity credential is generated as a root of trust by introducing the physical non-clonable property, and the total amount of the confirmed rights is embedded in the genesis fingerprint in the form of a hash commitment. This achieves the physical anchoring of the source of trust and the on-chain proof of the amount boundary, solving the problem of weak trust foundation caused by the copyability of digital keys and the lack of constraints on the amount of the confirmed rights in traditional technologies.

[0033] S12: When the first supplier splits and transfers the debt, it obtains the upper-level path fingerprint and its unique identity credential generated and stored on its own end based on the physical non-cloning characteristic. Based on the upper-level path fingerprint, its unique identity credential, its own identity identifier, and the hash value of the split amount, it generates the current path fingerprint through hash operation and records the transfer transaction containing the current path fingerprint to the distributed ledger. The upper-level path fingerprint is the genesis fingerprint or the path fingerprint generated by its direct upper-level supplier.

[0034] Path fingerprint: This refers to a unique hash value generated by the current operator at each stage of the debt splitting and transfer process. It points to the previous stage and contains key information about the current operation. A series of sequentially generated path fingerprints constitute an irreversible and tamper-proof chain of credentials, completely recording the debt transfer trajectory. Its generation principle is as follows: The current operator concatenates the previous-level path fingerprint, the unique identity credential generated by this end based on the physical non-cloning property, the current identity identifier, and the hash value of the split amount in a preset order. This is then input into a cryptographic hash function for one-way computation. The resulting fixed-length hash value is the current path fingerprint. Due to the one-way nature and avalanche effect of hash functions, any tampering with the input fields will completely change the path fingerprint, and the specific content of the input fields cannot be deduced from the path fingerprint, thus ensuring the irreversibility of the credential chain and data privacy. In the specific implementation, the cryptographic hash function can be a national standard algorithm such as SHA-256, SHA-3 or SM3, which is executed by the hash operation module built into each participating node. This module can usually be deployed in the computer system of each terminal in the form of software library (such as OpenSSL, Bouncy Castle) or hardware encryption card.

[0035] The specific implementation of this step is as follows: First, when the first supplier operates the splitting and transfer business, it obtains its parent-level path fingerprint from the distributed ledger. In the example above of the embodiment of this specification, the first supplier B is a first-level supplier, and its parent-level path fingerprint is the genesis fingerprint Genesis_Fingerprint generated by the core enterprise A.

[0036] Secondly, the first supplier invokes its own hardware security module to obtain a unique identity credential generated based on its physically unclonable characteristics. For example, for the first supplier B, the unique identity credential can be denoted as Key_supplier_B.

[0037] Next, the first supplier calls the cryptographic hash engine to generate the current path fingerprint, as shown in the example below: Current_Fingerprint = Hash (Previous_Fingerprint || Key_supplier_B ||ID_B || Hash(Split_Amount)).

[0038] Among them, Previous_Fingerprint is the fingerprint of the previous path (which can be the genesis fingerprint), ID_B is the identity identifier of the first supplier B, and Split_Amount is the amount split to others this time (such as 1.2 million yuan).

[0039] Finally, the first supplier packages the public information of this splitting operation along with the Current_Fingerprint into a single transaction and sends it to the distributed ledger network for recording.

[0040] For example, following the previous example, the first supplier B obtains the genesis fingerprint F0 from the chain and generates its unique identity credential Key_supplier_B. A hash value is obtained by calculating Hash(1.2 million). Subsequently, Hash(F0 || Key_supplier_B || “Supplier_B_ID” || Hash(1.2 million)) is executed to generate the current path fingerprint F1, and F1 is recorded on the chain.

[0041] In step S12, a new path fingerprint is generated by linking the previous fingerprint, the local physical credentials, and the split amount hash, thus realizing the chain-like evidence storage of the debt transfer trajectory. The amount exists in the form of hash value, which severs the information association between the transfer record and the original amount data at the data structure level.

[0042] S13: When the second supplier initiates a financing request, it submits the target path fingerprint, the target amount, and the path public field sequence tracing back to the genesis fingerprint corresponding to the target debt. The target path fingerprint is a path fingerprint generated based on the first split of the genesis fingerprint, or a path fingerprint generated when the second supplier splits and transfers the data from its direct superior supplier.

[0043] Target debt: refers to the specific debt that a supplier holding electronic debt instruments (i.e., the financing party) uses as the target of financing when applying for financing from a financial institution.

[0044] Target path fingerprint: refers to the path fingerprint held by the financing party corresponding to the target debt, that is, the path fingerprint generated in the last split and transfer of the debt.

[0045] Path public field sequence: refers to the complete sequence of public input fields (such as their respective identifiers, random numbers, etc., but excluding the original amount) corresponding to each level of path fingerprint from the genesis fingerprint along the debt transfer path to the target path fingerprint. This sequence is the basis for financial institutions to recalculate and verify the validity of the entire path.

[0046] The specific implementation of this step is as follows: First, the second supplier, as the financing party, determines the target debt it intends to finance, which can be derived from the first supplier.

[0047] Secondly, the second supplier retrieves the path fingerprint generated during the last transfer of the target claim from the distributed ledger and uses it as the target path fingerprint. This target path fingerprint is the same as the path fingerprint generated when the first supplier split the claim.

[0048] Next, the second supplier extracts the sequence of path public fields from the genesis fingerprint to the target path fingerprint from the distributed ledger.

[0049] Finally, the second supplier packages the target path fingerprint, the actual target amount of financing (e.g., RMB 1 million), and the path public field sequence together into a financing request and submits it to the financial institution.

[0050] For example, following the previous example, the second supplier C uses the path fingerprint F1 as the target path fingerprint, extracts the path public field sequence from F0 to F1, and submits it along with the target financing amount of RMB 1 million to the financial institution D.

[0051] This step S13 defines a standardized data structure for financing requests, clarifying all the input information required for subsequent verification, and providing a data foundation for financial institutions to perform verification independently and unambiguously.

[0052] S14: The financial institution receives the financing request, recalculates the path public field sequence to generate a verification path fingerprint, compares the hash value of the target amount with the amount hash value contained in the target path fingerprint to verify the consistency of the amount without knowing the original amount at the previous level, and queries the on-chain status identifier of the target path fingerprint, thereby completing the compliance verification of the path validity, amount authenticity and status uniqueness of the target debt without accessing the original transaction pricing data.

[0053] Verification path fingerprint: refers to the path fingerprint that a financial institution independently recalculates after receiving a financing request, using the publicly available path field sequence provided by the financing party and following the same hash operation order as the original generation process.

[0054] On-chain status identifier: refers to a field in the distributed ledger that is associated with a specific path fingerprint and is used to identify the current status of the debt (such as "valid", "financed", "frozen").

[0055] The specific implementation of this step is as follows: First, the financial institution receives the financing request from the second supplier.

[0056] Secondly, the path verification module on the financial institution's side extracts the sequence of public path fields from the request, recalculates the hash chain in sequence, and obtains the verification path fingerprint. If the verification path fingerprint matches the target path fingerprint in the request, the path validity verification passes.

[0057] Next, the amount verification module on the financial institution's side calculates the hash value of the target amount (e.g., 1 million yuan) in the request and compares it with the amount hash value included when the target path fingerprint was generated (e.g., Hash(1.2 million) recorded by the first supplier B). Since the target path fingerprint records the amount of 1.2 million yuan split by the directly upstream supplier B, while the actual target amount for financing party C is 1 million yuan, the corresponding amount values ​​are different. According to the collision resistance of cryptographic hash functions, Hash(1 million) and Hash(1.2 million) will inevitably not be equal. Therefore, this basic comparison step can only verify whether the target amount submitted by the financing party is completely equal to the split amount recorded in the target path fingerprint, but cannot determine whether the target amount is within the legal range of the split amount (i.e., whether it is less than or equal to the split amount). The final confirmation of the authenticity of the amount and the continuity of the path needs to be completed in conjunction with the full-path continuous consistency verification by extracting the amount hash value level by level in the subsequent embodiment 5, and the zero-knowledge scope proof verification in embodiments 6 and 7.

[0058] Finally, the financial institution queries the distributed ledger for the on-chain status identifier of the target path fingerprint. If the query result shows that the status identifier is "valid" and there are no conflicting records, the uniqueness verification of the status is successful. After all three parts of the verification are successful, the financial institution can complete the compliance review of the financing request without obtaining any original transaction pricing data (such as the total confirmed amount of 5 million yuan and the split amount of 1.2 million yuan).

[0059] This step S14, through three parallel operations—recalculation verification, hash comparison, and status query—forms a compliance verification closed loop that does not rely on the original data, thus solving the fundamental technical dilemma in traditional technologies where the verification process must access the original data, leading to the leakage of trade secrets.

[0060] In this embodiment, through sequential processing in steps S11-S14, a complete data privacy protection method for multi-level supply chains is achieved by innovatively integrating cryptographic technologies such as the hardware root of trust provided by the physical non-cloning property, the chain-based anti-tampering mechanism provided by the hash chain, and the data privacy isolation provided by the decoupling of monetary amounts. The core logic of rights confirmation—that is, how to verify the validity of a claim without accessing the original monetary data—is transformed into verifying the integrity and consistency of a physically anchored, monetary-decoupled path fingerprint chain. This transformation is based on the following objective technical facts: the unidirectionality of the hash function ensures that the original amount cannot be deduced from the hash value; the physical non-cloning property ensures the non-forgeability of the root of trust; and the continuity of the hash chain ensures the immutability of the transfer records. Therefore, this invention provides a core technical solution for data privacy protection and compliant rights confirmation in multi-level supply chain finance.

[0061] Example 2: Specific implementation of unique identity credential generation.

[0062] In this embodiment, the unique identity credential is generated through the following steps: Send a challenge signal to the pre-defined physical non-cloning function circuit on this end; Based on the random physical differences introduced into the manufacturing process of the physically unclonable function circuit, a unique response signal is generated; The unique response signal is subjected to error correction encoding and fuzzy extraction processing to generate a stable and unique identity credential, which is then stored in a secure storage area on the local device and is prohibited from being read externally.

[0063] Physically Unclonable Function (PUF) circuits: These are hardware circuits that utilize uncontrollable microscopic physical differences in the integrated circuit manufacturing process to map input challenge signals into unique, unpredictable response signals.

[0064] Challenge signal: refers to the external stimulus input to the PUF circuit, which is used to trigger the PUF circuit to generate a specific response.

[0065] Random physical differences refer to the random and unique microstructural differences introduced by process deviations in the manufacturing process steps of integrated circuits, such as photolithography, doping, and oxidation. Examples include minute fluctuations in the threshold voltage of transistors and atomic-level changes in wire width.

[0066] Error-correcting coding refers to a coding technique that adds redundant information to the original data so that errors occurring during transmission or storage can be detected and corrected. In this embodiment, its purpose is to correct transient errors in the PUF response caused by factors such as temperature and voltage fluctuations.

[0067] Fuzzy extraction: refers to a cryptographic technique used to reliably extract a uniformly distributed and reproducible strong key from a noisy, unevenly distributed random source (such as a PUF response). Its common English name is FuzzyExtractor.

[0068] The specific implementation of this embodiment is as follows: First, the PUF invocation module of the participating party (core enterprise or any supplier) sends a preset challenge signal to the preset PUF circuit on its own side.

[0069] Secondly, the delay path network or memory cell array inside the PUF circuit generates a unique response signal based on the inherent and unique random physical differences in its manufacturing process.

[0070] Next, fuzzy extraction processing is performed on the original unique response signal. This process is a standard practice in the field: first, error-correcting coding techniques are used to generate auxiliary data during the registration phase. This auxiliary data can be used for subsequent recovery without revealing the response signal. During the recovery phase, the original noise-free response signal is recovered using the auxiliary data and the potentially noisy response signal through an error-correcting decoding algorithm.

[0071] Finally, the recovered stable and unique identity credentials are stored in a secure storage area on the local end, such as a trusted execution environment or an isolated area of ​​a secure encryption chip, and security policies are set to prevent any external entity from directly reading the credentials.

[0072] It should be noted that the specific selection of the above-mentioned PUF circuit is not limited to one type. In one example, a static random access memory (SRAM) type PUF can be used, utilizing the randomness of the initial power-on state of its memory cells; in another example, a ring oscillator (ROC) type PUF can be used, utilizing the frequency difference caused by the difference in gate delays of different paths. Any PUF circuit that can generate a unique response signal based on hardware manufacturing differences falls within the protection scope of this invention.

[0073] In this embodiment, by combining PUF, error correction coding and fuzzy extraction, cryptographic credentials are stably extracted from physical randomness. Thus, based on the identity credential acquisition achieved in Embodiment 1 above, this embodiment further solves the problem of how to convert environmentally sensitive PUF responses into stable and reliable cryptographic root keys, significantly improving the stability and security of the system.

[0074] Example 3: Specific implementation of SRAM PUF.

[0075] In this embodiment, the physically unclonable function circuit is a static random access memory (SRAM) type physically unclonable function circuit, the challenge signal is a set of memory cell addresses of the corresponding SRAM, and the unique response signal is the nondeterministic initial state value of the memory cell corresponding to the memory cell address at the moment of power-on due to process deviation.

[0076] SRAM PUF is an abbreviation for Static Random-Access Memory Physically Unclonable Function. SRAM stands for Static Random-Access Memory, and PUF stands for Physically Unclonable Function. SRAM PUF refers to the technical means of realizing PUF function by utilizing the randomness of the initial power-on state of SRAM memory cells.

[0077] The specific implementation of this embodiment is as follows: First, a static random access memory region in an embedded system or on-chip system is used as the PUF source.

[0078] Secondly, the physical address of a set of memory cells is used as the challenge signal. For example, the challenge signal could be {0x0000, 0x0004, ..., 0x03FC}, pointing to a row of consecutive memory cells.

[0079] Secondly, upon power-up, before any explicit write operation is performed, the target device immediately reads the logical value of the memory cell pointed to by the set of addresses. Due to the difference in the threshold voltage of transistors in the manufacturing process, each SRAM cell will be biased towards a 0 or 1 state upon power-up; this bias is random and unique. The 0 / 1 bit sequence read at this time is the unique response signal.

[0080] For example, following the previous example, when the core enterprise A starts up, it sends a challenge signal to its SRAM PUF and reads the power-on initial values ​​of 256 memory cells from address 0x1000 to 0x10FF, and gets the bit string "10011100...10" as a response.

[0081] In this embodiment, by selecting SRAM PUF as the specific implementation, it utilizes the technical characteristics of uncontrollable manufacturing process deviation, response independent of external storage, and no need for additional customized circuits. Thus, based on the general PUF implemented in Embodiment 2 above, it further realizes the low cost and easy integration and deployment of physical root of trust, which is particularly suitable for the hardware environment of many suppliers in the supply chain.

[0082] Example 4: Specific implementation of fuzzy extraction processing.

[0083] In this embodiment, please refer to Figure 2 , Figure 2 This is a schematic diagram of the first sub-process of the data privacy protection processing method for multi-level supply chains provided in an embodiment of the present invention. Figure 2 As shown, in this embodiment, the unique response signal undergoes error correction encoding and fuzzy extraction processing to generate a stable and unique identity credential, including: S21: Apply a random mask to the unique response signal to generate auxiliary data; S22: Input the auxiliary data and the random mask into a preset forward error correction encoder to generate error correction codewords; S23: Perform an XOR operation between the error correction codeword and the unique response signal to obtain the XOR operation result; S24: Extract the result of the XOR operation to obtain a stable and unique identity credential.

[0084] Random mask: refers to a random bit string of the same length as the PUF response generated by the local random number generator during the registration phase. It is used to mask the original response and ensure that the auxiliary data does not leak response information.

[0085] Auxiliary data refers to data generated during the registration phase that can be publicly used in the subsequent recovery phase to help recover the original credentials from noisy PUF responses, but it does not contain credential information itself.

[0086] Forward error correction encoder: This refers to an encoding module that adds redundancy to the original data, allowing the receiving end to correct errors automatically without retransmission when data errors occur. In this embodiment, it can be implemented using error correction coding algorithms such as BCH codes or Reed-Solomon codes.

[0087] The specific implementation of this embodiment is as follows: First, during the credential registration phase, the local random number generator generates a random mask K of the same length as the PUF response R.

[0088] Next, calculate the auxiliary data HD = R XOR K.

[0089] Next, the auxiliary data HD and the random mask K are input together into a preset forward error correction encoder. The forward error correction encoder can use BCH (n, k, t) code, where n is the encoded code length, k is the information bit length, and t is the number of errors that can be corrected. The forward error correction encoder outputs the error correction codeword C = Encode (K) (or a combination of Encode(HD || K)). Taking BCH(255, 131, 18) code as an example, it can encode 131 bits of information into a 255-bit codeword and correct 18 errors.

[0090] Then, during the credential recovery phase, the potentially noisy PUF response R' is acquired again. Calculate K' = R' XOR HD = K XOR (R XOR R').

[0091] Finally, using the error-correcting codeword C, K' is decoded to recover the correct K, thus obtaining a stable and unique identity credential.

[0092] For example, following the previous example, a mask K is generated during the initial registration, HD is calculated, and C is encoded. During subsequent recovery, even if R' differs from R by a few bits, K can be stably recovered by K' = R' XOR HD and then using C for error correction.

[0093] This embodiment defines a specific process for fuzzy extraction based on random masking and forward error correction coding, thereby achieving robust elimination of PUF response noise under environmental fluctuations. Based on the general fuzzy extraction achieved in Embodiment 2 above, it further solves the problem of how to safely and efficiently generate auxiliary data and ensure the reproducibility of credentials, significantly improving the reliability of the system under different temperature, humidity, and voltage conditions.

[0094] Example 5: Specific implementation of path continuity consistency verification.

[0095] In this embodiment, please refer to Figure 3 , Figure 3 This is a schematic diagram of the second sub-process of the data privacy protection processing method for multi-level supply chains provided in an embodiment of the present invention. For example... Figure 3 As shown, in this embodiment, comparing the hash value of the target amount with the hash value of the amount contained in the target path fingerprint to verify the consistency of the amount without knowing the original amount at the previous level includes: S31: Extract the monetary hash value contained in each level of the path fingerprint between the genesis fingerprint and the target path fingerprint from the path public field sequence. S32: Following the order of splitting and transferring, concatenate the hash values ​​of each level of amount, perform hash operations, and generate a verification amount digest; S33: Compare the verification amount summary with the amount chain summary pre-stored in the distributed ledger. The amount chain summary is generated and recorded by the direct upstream supplier corresponding to the target claim during the splitting and transfer process, so as to verify the continuity and consistency of the split amount at each level along the entire path without knowing the original amount at each level.

[0096] Verification amount summary: refers to the summary value obtained by the financial institution during the verification process by extracting the amount hash value level by level from the path public field sequence and reconcatenating and calculating it.

[0097] Money Chain Summary: This refers to the summary value calculated by the splitter when generating the path fingerprint by concatenating all the amount hash values ​​from the genesis fingerprint to the current split stage. This value is recorded on the distributed ledger along with the transactions and serves as the benchmark for subsequent full-path consistency verification.

[0098] The specific implementation of this embodiment is as follows: First, after receiving a financing request, the financial institution parses the publicly available field sequence of the path, which contains the transaction identifiers of each level tracing back to the genesis fingerprint.

[0099] Secondly, based on the transaction identifier, the financial institution extracts the amount hash value H(S_i) corresponding to each level of splitting and transferring from the distributed ledger. Here, extraction step by step means extracting the amount hash value recorded in each level of splitting and transferring transaction in the order of the debt transfer, starting from the genesis transaction where the genesis fingerprint is located.

[0100] Next, following the order of the splitting and transfer, the hash values ​​of each level of amount are concatenated to form a long string, and a hash operation is performed on this string to generate a verification amount digest: Digest_Verify = Hash( H(S_1)|| H(S_2) || ... || H(S_n) ).

[0101] Finally, the verification amount digest is compared with the amount chain digest Digest_Chain pre-stored on the chain, which is calculated and recorded by the direct upstream supplier when generating the target path fingerprint. If the two are consistent, it proves that the amount hash value at any level in the entire chain from genesis to the financing party has not been tampered with or replaced, thus verifying the continuity and consistency of the split amount at each level along the entire path.

[0102] For example, following the previous example, financial institution D extracts the amount hash values ​​H(5 million) and H(1.2 million) from the chain, concatenates them, and calculates the hash(H(5 million) || H(1.2 million)) to obtain the verification digest. Simultaneously, the amount chain digest recorded by the first supplier B on the chain is also hash(H(5 million) || H(1.2 million)). The two hashes match, and the verification passes.

[0103] In this embodiment, by introducing the summaries of the monetary chain as the verification benchmark for full-path consistency, the verification dimension is expanded from single-point equality to the continuous integrity of the entire chain. Thus, based on the single-level monetary comparison achieved in Embodiment 1 above, in-depth defense against monetary tampering is further realized, solving the problem that traditional technologies can only verify adjacent nodes but cannot detect tampering in the middle of the path, and significantly improving the security depth of the audit.

[0104] Example 6: Specific implementation of zero-knowledge scope proof.

[0105] In this embodiment, after verifying the continuity and consistency of the split amounts at each level along the entire path, the method further includes: Receive the zero-knowledge scope proof submitted by the second supplier, the zero-knowledge scope proof being used to prove that the target amount does not exceed the amount split by its direct superior supplier; Using the amount hash value contained in the target path fingerprint as public input, the zero-knowledge scope proof is verified without knowing the amount split by the direct upstream supplier or the specific value of the target amount.

[0106] Zero-Knowledge Range Proof: This refers to a cryptographic protocol that allows a prover to demonstrate to a verifier that a promised secret value lies within a public range without revealing the specific value of that secret. Its common English name is Zero-Knowledge Range Proof.

[0107] In this invention, zero-knowledge scope proof is used to solve the problem of verifying hierarchical constraints on supply chain amounts. Specifically, at each level of debt splitting and transfer, the splitting party (e.g., the first supplier) embeds the split amount into a path fingerprint in the form of a hash commitment and records it in a distributed ledger. When a lower-level supplier holding the split debt (e.g., the second supplier) initiates financing, it acts as the prover, proving to the financial institution that its target amount does not exceed the amount split by its immediate superior supplier, without revealing the specific value of any amount during this process. The verifier (financial institution) uses the hash value of the amount contained in the target path fingerprint as public input to verify the zero-knowledge scope proof submitted by the prover, thereby completing the compliance review of amount constraints under zero-knowledge conditions. By setting the verification object of the zero-knowledge scope proof to the amount constraint relationship between two adjacent levels, rather than the total amount constraint across levels, this invention achieves a precise match between the verification architecture and the hierarchical transmission characteristics of the supply chain. This ensures that the verification at each level only needs to process the commitment values ​​of two adjacent levels, making the verification complexity independent of the supply chain path length and significantly improving the scalability of the privacy-protected verification mechanism.

[0108] The specific implementation of this embodiment is as follows: First, the second supplier, acting as the financier and also the prover of the zero-knowledge scope proof, generates a local proof that proves the target amount held by it is less than or equal to the split amount promised by its direct superior supplier, based on the cryptographic commitment between the target amount held by it and the split amount promised by its direct superior supplier.

[0109] Secondly, the second supplier submits the zero-knowledge scope proof to the financial institution.

[0110] Secondly, the financial institution, acting as the verifier, uses the amount hash value contained in the target path fingerprint as public input and calls a zero-knowledge-range proof verification algorithm to verify the proof. The verification process is conducted entirely in the encrypted space, and the financial institution cannot know the specific value of the split amount or the target amount during this process. For specific details on the proof generation and verification implementation, please refer to the complete process description based on the Bulletproofs protocol in Example 7.

[0111] In this embodiment, by precisely setting the verification object of the zero-knowledge scope proof to the amount constraint of two adjacent levels, rather than the total amount constraint across levels, the verification architecture and the step-by-step transmission characteristics of the supply chain are accurately matched. Thus, based on the verification consistency in the above embodiment 5, zero-knowledge verification of the amount boundary constraint is further realized, which significantly improves the depth of compliance review under the premise of privacy protection.

[0112] Example 7: Specific implementation of Bulletproofs.

[0113] In this embodiment, the zero-knowledge scope proof is a Bulletproofs proof; Verification of the zero-knowledge scope proof includes: The amount hash value contained in the target path fingerprint and the hash value of the target amount are used as public inputs; The Bulletproofs are verified by inner product proof to verify that the target amount is less than or equal to the amount split by the direct upstream supplier without revealing the specific value of the amount split by the direct upstream supplier and the target amount.

[0114] Bulletproofs refer to a zero-knowledge range proof protocol that requires no trusted setup, has a small proof size, and is highly efficient in verification. Its core idea is to reduce range proofs to inner product proofs and to reduce the proof size to logarithmic levels through recursive compression techniques. "Bulletproofs" is an English term used as a proper noun in the field of cryptography.

[0115] In this invention, Bulletproofs, rather than zk-SNARKs or STARKs, is chosen as the specific implementation protocol for zero-knowledge range proofs based on the following technical considerations: First, Bulletproofs does not require a trusted setup phase, avoiding the security risks that may be introduced by the trusted setup process in traditional zk-SNARKs, and is more suitable for the decentralized deployment needs among multiple distrustful participants in supply chain finance; Second, the proof size and proof duration of Bulletproofs are logarithmically related to the number of bits in the upper limit of the range. In supply chain finance scenarios (the upper limit of the amount range is usually 32 or 64 bits), the size of a single proof can be controlled within a few hundred bytes to less than 1KB, and the verification time is in the millisecond range, which can meet the processing requirements of financial-grade real-time transactions; Third, Bulletproofs supports batch verification, and financial institutions can simultaneously aggregate and verify multiple range proofs from multiple financing requests, further reducing the computational overhead of verification.

[0116] Inner product proof verification: This refers to the core step of the Bulletproofs verification algorithm. The verifier confirms that the promised secret value satisfies the claimed range relation by checking the validity of the inner product relationship in the proof, without needing to know the specific numerical value of the secret value. Its basic principle is to transform the range relation "0 ≤ v < 2^n" into an inner product consistency check of the bit decomposition of the promised value, and through multiple rounds of recursive compression, reduce the verification process, which originally required n promises, to a single inner product equation verification. In the Bulletproofs protocol, the verification complexity of inner product proof is O(log n), rather than O(n) of the naive method, which is the fundamental source of its efficiency.

[0117] The specific implementation of this embodiment is as follows: First, during the system initialization phase, the supply chain finance platform selects a secure elliptic curve cyclic group, Group, with a prime order q. Two independent generators G and H are selected from this group, and their discrete logarithmic relationship is unknown. The elliptic curve parameters (group order q, generators G and H) are globally public parameters of the system, uniformly distributed to all participating nodes by the genesis block of the distributed ledger network or configured smart contracts.

[0118] Secondly, during the proof generation phase, the second supplier, acting as the proof provider, performs the following steps: Step 1: Commitment Calculation. The second supplier obtains the target amount v_target for this financing and the amount v_split split by its immediate upstream supplier. Two random blind factors r_target and r_split are generated, where the random blind factors are uniformly and randomly selected from the finite field Z_q. Using the Pedersen commitment scheme, the commitment value C_target = r_target × G + v_target × H and the commitment value C_split = r_split × G + v_split × H for the target amount are calculated on the elliptic curve Group. In this invention, the hash value H(v_split) of the split amount v_split has been embedded with the target path fingerprint and recorded in the distributed ledger by the immediate upstream supplier during the splitting process. Therefore, the hash commitment of the amount corresponding to C_split can be publicly verified on the blockchain.

[0119] Step Two: Range Relationship Encoding. Encode the range relationship to be proven, "0 ≤ v_target ≤ v_split < 2^n", into two independent range proof statements: "v_target ∈ [0, 2^n - 1]" and "v_split - v_target ∈ [0, 2^n - 1]". Decompose v_target and the difference v_diff = v_split - v_target into n-bit binary representations, where n is the number of bits required to represent the monetary value. The value of n should satisfy the condition that 2^n is greater than the maximum monetary value that may occur in the supply chain finance scenario. Typically, 32 bits or 64 bits are used. 32 bits can cover a monetary range of approximately 4.295 billion, while 64 bits can cover a larger range.

[0120] Step 3: Bulletproofs proof generation. Using the commitment values ​​C_target and C_split, the monetary values ​​v_target and v_diff, the random blind factor r_target and (r_split - r_target) as secret inputs, and the elliptic curve group parameters as public inputs, execute the Bulletproofs proof generation algorithm.

[0121] The core algorithm process includes: First, generating Pedersen commitments for each bit of v_target and v_diff, forming two commitment vectors of length n; Second, compressing the statement "each commitment value is indeed a commitment for the corresponding bit (0 or 1)" into a single inner product equation through inner product proof; Third, using recursive compression techniques, halving the size of the inner product equation in each round, reducing it to a single scalar equation after log2(n) rounds; Finally, applying the Fiat-Shamir heuristic to convert the interactive proof into a non-interactive proof, obtaining the final Bulletproofs proof π, whose volume is approximately 2×log2(n) group elements plus a small amount of scalars, approximately 600 bytes when n=32.

[0122] Then, during the proof submission phase, the second supplier submits the generated Bulletproofs proof π, commitment value C_target, and C_split along with the financing request to the financial institution. Since the hash value H(v_split) of the split amount v_split corresponding to C_split has already been embedded in the target path fingerprint and recorded in the distributed ledger by the direct upstream supplier during the splitting process, the financial institution can first extract this hash value from the target path fingerprint to confirm the association between C_split and the on-chain record. Then, using C_target, C_split, and elliptic curve group parameters as public inputs, it executes the subsequent Bulletproofs verification algorithm.

[0123] Finally, during the verification and implementation phase, the financial institution performs the following steps: Step 1: Input Preparation for Verification. The financial institution extracts the Bulletproofs π, commitment value C_target, and C_split from the financing request. It extracts the amount hash value H(v_split) from the target path fingerprint and associates it with C_split as a public verification context.

[0124] Step Two: Inner Product Proof Verification. The core step of the Bulletproofs verification algorithm is the inner product proof verification. The verification process is as follows: First, C_diff = C_split - C_target = (r_split - r_target) × G + (v_split - v_target) × H is reinterpreted as a Pedersen commitment to the difference v_diff, and this commitment is verified to be consistent with the corresponding commitment in the proof of π. Second, O(log n) group operations are performed on the elliptic curve group, checking round by round whether the compressed inner product equation in the proof of π holds. If all checks pass, the proof is accepted, confirming that "v_target ≤ v_split" holds.

[0125] Step 3: Output Results. If the inner product validation passes, the financial institution will output "Pass," confirming that, without knowing the specific values ​​of v_split and v_target, the target amount has not exceeded the amount split by its direct upstream supplier.

[0126] For example, following the previous example, the supply chain finance platform selects the secp256k1 elliptic curve, with a group order q ≈ 2^256 and generators G and H. The second supplier C selects random blind factors r_target and r_split, calculating C_target = r_target × G + v_target × H and C_split = r_split × G + v_split × H, where v_target = 1 million and v_split = 1.2 million. Taking n=32, v_target and v_diff = v_split - v_target = 200,000 are decomposed into 32-bit binary representations. The Bulletproofs generation algorithm is executed to obtain proof π, which has a size of approximately 608 bytes. After receiving π, C_target, and C_split, the financial institution D extracts H(v_split) from the target path fingerprint F1 to confirm that the hash commitment of C_split is consistent with the on-chain record, and then performs inner product proof verification. The verification algorithm performs approximately 64 group multiplication operations on the elliptic curve group, with a total time consumption of approximately 5 to 15 milliseconds. The verification passed, and financial institution D confirmed that 1 million ≤ 1.2 million is true without knowing the specific values ​​of 1.2 million and 1 million.

[0127] It should be noted that the specific selection of the aforementioned zero-knowledge range proof protocol is not limited to Bulletproofs. In one example, a zk-SNARKs protocol (such as Groth16) based on trusted settings can be used, achieving smaller proof size and faster verification speed through pre-generated public reference strings. This is suitable for private blockchain scenarios with higher requirements for verification efficiency and acceptable single-point trust assumptions. In another example, a STARKs protocol based on hash functions can be used, achieving completely transparent trustworthiness and possessing resistance to quantum computing attacks, suitable for scenarios with higher requirements for long-term security. Any zero-knowledge proof protocol capable of verifying range relationships without exposing the secret value falls within the scope of protection of this invention.

[0128] In this embodiment, by selecting Bulletproofs, a zero-knowledge scope proof protocol that requires no trusted setup, has a compact proof size, and is highly efficient in verification, a precise match is achieved between the verification architecture and the step-by-step transmission characteristics of the supply chain. Thus, based on the general scope proof achieved in Embodiment 6 above, it further solves the problems of traditional proof systems requiring trusted setup, having large proof size, and slow verification. At the same time, by decoupling the verification complexity from the supply chain path length, the scalability and operational efficiency of the privacy-preserving verification mechanism in multi-level supply chain scenarios are significantly improved.

[0129] Example 8: Specific implementation of abnormal state audit trajectory generation.

[0130] In this embodiment, after querying the on-chain state identifier of the target path fingerprint, the method further includes: When the on-chain status identifier of the target path fingerprint is found to be frozen or has a financing record, a verification anomaly record is generated. The verification anomaly record contains the target path fingerprint and the current timestamp. Broadcast the verification exception record to the distributed ledger; Query all historical financing records associated with the target path fingerprint and generate a debt status anomaly report. The debt status anomaly report includes the block height of the first valid financing record and the transaction hash value of the current freeze operation.

[0131] The specific implementation of this embodiment is as follows: First, when financial institutions perform status queries, if they find that the on-chain status identifier corresponding to the target path fingerprint F_target is "financed" or "frozen", they will immediately trigger the abnormal handling process.

[0132] Secondly, the exception handling module generates a new verification exception record. The data structure of this record includes: the target path fingerprint of this financing request, the current server timestamp, and the detailed reason code that triggered the exception (such as "DUPLICATE_FINANCING" or "ASSET_FROZEN").

[0133] Next, the financial institution uses its private key to sign the verification anomaly record and broadcasts it as a special transaction to the distributed ledger. After the consensus nodes in the distributed ledger verify the signature, they write the anomaly record into a new block, making it an immutable audit trail.

[0134] Finally, the financial institution initiates a query to the distributed ledger to retrieve all historical financing records containing the fingerprint of the target path. If a first valid financing record exists, its block height is extracted; if a freeze operation exists, the hash value of the freeze transaction is extracted. This information is then aggregated to generate a structured report on anomalies in the claim status.

[0135] In this embodiment, by transforming the failure result of a single verification into a traceable and tamper-proof audit record on the chain, the full network transparency and permanent evidence storage of abnormal states are achieved. Thus, based on the status query implemented in Embodiment 1 above, a positive credit punishment closed loop is independently constructed, which significantly improves the system's capabilities in risk prevention and post-event auditing.

[0136] Example 9: Specific implementation of quantum computing security enhancement.

[0137] In this embodiment, the hash operation employs a cryptographic hash algorithm resistant to quantum computing attacks; The cryptographic hash algorithm is a lattice-based hash algorithm or a multivariate polynomial-based hash algorithm; The genesis fingerprint and the path fingerprints at each level are all generated based on the cryptographic hash algorithm.

[0138] Quantum-resistant cryptographic hash algorithms: These are hash algorithms designed to resist attacks by known quantum algorithms (such as Grover's algorithm). Their security is based on lattice-hard problems or multivariate polynomial-hard problems, rather than the collision-resistant assumptions of traditional hash algorithms.

[0139] Lattice-based hash algorithms: These are families of hash functions whose security is built upon difficult problems such as the shortest vector problem or the nearest vector problem on a lattice, such as SWIFFTX.

[0140] Multivariate polynomial-based hash algorithms: These are hash functions whose security is built upon the difficulty of solving random multivariate polynomial equations over finite fields, serving as an alternative quantum-resistant candidate scheme to lattice-based schemes.

[0141] The specific implementation of this embodiment is as follows: First, during system initialization, a configuration option specifies that the hash algorithm family used throughout the privacy protection process is a quantum-resistant cryptographic hash algorithm. This configuration option corresponds to a specific algorithm instance; for example, an optimized variant of the standard lattice-based SWIFFT hash algorithm can be selected.

[0142] Secondly, the core enterprise side calls this quantum-resistant hash algorithm when generating the genesis fingerprint. For example, Genesis_Fingerprint=SWIFFT_Hash(Key_core||ID_core||SHA3_Hash(Total_Amount)).

[0143] The inner SHA3_Hash is used to generate a fixed-length digest of the amount, while the outer SWIFFT_Hash is used to ensure the quantum-resistant security of the hash chain.

[0144] Furthermore, when splitting and generating the current path fingerprint, suppliers at all levels also uniformly call this quantum-resistant hash algorithm. The specific hash calculation formula is as follows: Current_Fingerprint = SWIFFT_Hash (Previous_Fingerprint || Key_supplier || ID || SHA3_Hash(Split_Amount)).

[0145] For example, continuing from the previous example, the genesis fingerprint F0 = SWIFFT_Hash(Key_core_A || “Core_A_ID” || SHA3_Hash(5 million)). The subsequent path fingerprint F1 = SWIFFT_Hash(F0 || Key_supplier_B || “Supplier_B_ID” || SHA3_Hash(1.2 million)).

[0146] In this embodiment, by replacing the hash algorithm of the entire hash chain with a cryptographic hash algorithm resistant to quantum computing attacks, the long-term security of the trust chain is achieved. Thus, based on all the embodiments mentioned above, it further solves the problem that the current cryptographic system may be compromised and historical privacy may be leaked after the maturity of quantum computers in the future, and significantly improves the forward security of the system.

[0147] The data privacy protection processing methods for multi-level supply chains described in the above embodiments can be recombined as needed to obtain combined implementation schemes, but all are within the protection scope claimed by this invention.

[0148] Example 10: A data privacy protection processing system for multi-level supply chains.

[0149] This embodiment provides a data privacy protection processing system for multi-level supply chains, which corresponds one-to-one with the data privacy protection processing methods for multi-level supply chains described in the previous embodiments. Please refer to [link / reference]. Figure 4 , Figure 4 This is a schematic block diagram of a data privacy protection processing system for a multi-level supply chain provided in an embodiment of the present invention. Figure 4 As shown, the data privacy protection processing system 40 for multi-level supply chains includes: a core enterprise module 41, a first supplier module 42, a second supplier module 43, and a financial institution module 44. Detailed descriptions of each functional module are as follows: The core enterprise module 41 is used to respond to the debt confirmation request, obtain the unique identity credential generated and stored on the local end based on the physical non-cloning characteristic, and generate the genesis fingerprint through hash operation based on the unique identity credential, the core enterprise identity identifier and the hash value of the total amount of the confirmed debt, and record it in the distributed ledger. The first supplier-side module 42 is used to obtain the upper-level path fingerprint and its unique identity credential generated and stored on the local end based on the physical non-cloning characteristic when the debt is split and transferred. Based on the upper-level path fingerprint, its unique identity credential, the local identity identifier and the hash value of the split amount, the current path fingerprint is generated through hash operation. The transfer transaction containing the current path fingerprint is recorded in the distributed ledger. The upper-level path fingerprint is the genesis fingerprint or the path fingerprint generated by its direct upper-level supplier. The second supplier module 43 is used to submit the target path fingerprint, target amount and path public field sequence back to the genesis fingerprint when initiating a financing request. The target path fingerprint is a path fingerprint generated based on the first split of the genesis fingerprint, or a path fingerprint generated by the split and circulation of the direct superior supplier of the second supplier module 430. The financial institution module 44 is used to receive the financing request, generate a verification path fingerprint by recalculating the path public field sequence, compare the hash value of the target amount with the amount hash value contained in the target path fingerprint to verify the consistency of the amount without knowing the original amount at the previous level, and query the on-chain status identifier of the target path fingerprint, thereby completing the compliance verification of the path validity, amount authenticity and status uniqueness of the target debt without accessing the original transaction pricing data.

[0150] The specific implementation details of each of the above modules can be found in the corresponding steps in Example 1, and will not be repeated here.

[0151] Furthermore, the core enterprise-side module 41 includes: The first transmitting submodule is used to send a challenge signal to the preset physical unclonable function circuit on this end; The first generation submodule is used to generate a unique response signal based on the random physical differences introduced into the manufacturing process of the physically unclonable function circuit. The first generation submodule is used to perform error correction encoding and fuzzy extraction processing on the unique response signal to generate a stable and unique identity credential, and store the identity credential in the secure storage area of ​​the local terminal, prohibiting external access.

[0152] Furthermore, the physically unclonable function circuit is a static random access memory type physically unclonable function circuit, the challenge signal is a set of memory cell addresses of the corresponding static random access memory, and the unique response signal is the nondeterministic initial state value of the memory cell corresponding to the memory cell address at the moment of power-on due to process deviation.

[0153] Further, the first generation submodule includes: The second generation submodule is used to apply a random mask to the unique response signal to generate auxiliary data; The third generation submodule is used to input the auxiliary data and the random mask into a preset forward error correction encoder to generate error correction codewords; The first operation submodule is used to perform an XOR operation on the error correction codeword and the unique response signal to obtain the XOR operation result. The first extraction submodule is used to extract the result of the XOR operation to obtain a stable and unique identity credential.

[0154] Furthermore, the financial institution-side module 44 includes: The second extraction submodule is used to extract the amount hash value contained in each level of the path fingerprint between the genesis fingerprint and the target path fingerprint from the path public field sequence. The second calculation submodule is used to concatenate the hash values ​​of each level of amount in the order of splitting and transferring, perform hash calculation, and generate a verification amount digest. The first comparison submodule is used to compare the verification amount summary with the amount chain summary pre-stored on the distributed ledger. The amount chain summary is generated and recorded by the direct upstream supplier corresponding to the target claim during the splitting and transfer process, so as to verify the continuity and consistency of the split amount at each level along the entire path without knowing the original amount at each level.

[0155] Furthermore, the financial institution-side module 44 also includes: The first receiving submodule is used to receive the zero-knowledge scope proof submitted by the second supplier, wherein the zero-knowledge scope proof is used to prove that the target amount does not exceed the amount split by its direct superior supplier. The first verification submodule is used to verify the zero-knowledge scope proof by using the amount hash value contained in the target path fingerprint as public input, without knowing the amount split by the direct upstream supplier or the specific value of the target amount.

[0156] Furthermore, the zero-knowledge scope proof is a Bulletproofs proof; the first verification submodule includes: The first determining submodule is used to take the amount hash value contained in the target path fingerprint and the target amount hash value as public input; The second verification submodule is used to perform inner product verification on the Bulletproofs to verify that the target amount is less than or equal to the amount split by the direct upstream supplier without revealing the specific value of the amount split by the direct upstream supplier and the target amount.

[0157] Furthermore, the financial institution-side module 44 also includes: The fourth generation submodule is used to generate a verification anomaly record when the on-chain status identifier of the target path fingerprint is found to be in a frozen state or a financing record already exists. The verification anomaly record includes the target path fingerprint and the current timestamp. The first broadcast submodule is used to broadcast the verification exception record to the distributed ledger; The fifth generation submodule is used to query all historical financing records associated with the target path fingerprint and generate a debt status anomaly report. The debt status anomaly report includes the block height of the first valid financing record and the transaction hash value of the current freeze operation.

[0158] Furthermore, the hash operation employs a cryptographic hash algorithm resistant to quantum computing attacks; The cryptographic hash algorithm is a lattice-based hash algorithm or a multivariate polynomial-based hash algorithm; The genesis fingerprint and the path fingerprints at each level are all generated based on the cryptographic hash algorithm.

[0159] The specific working principles and implementation details of each of the above sub-modules have been described in detail in the aforementioned embodiments 2 to 9, and will not be repeated here.

[0160] [Experimental Verification] To verify the technical effects of the embodiments of the present invention, the following verification experiment was designed to demonstrate the correlation between the technical solution and the technical effects of the present invention: 1) List of technical effects to be verified.

[0161] Final result: Without accessing any original transaction pricing data, the system completes compliance verification of the path validity, amount authenticity, and status uniqueness of debt instruments, fundamentally resolving the inherent contradiction between privacy protection and compliance confirmation.

[0162] Direct Effect A (corresponding to the physical unclonable characteristic anchoring technology): The root of trust possesses the uniqueness of unclonable devices and the immutable monetary boundary.

[0163] Direct effect B (corresponding to the amount hash decoupling technique): cuts off the information association between the verification process and the original transaction pricing data at the data structure level.

[0164] Direct effect C (corresponding to the fingerprint chain recording technology): the debt transfer trajectory has an immutable chain-like evidence.

[0165] Direct effect D (corresponding to triple verification technology): Perform three-dimensional compliance verification on debt instruments.

[0166] 2) Experiment overview and grouping.

[0167] To verify the privacy protection capabilities and trustworthiness of the method of this invention, comparative verification experiments and ablation experiments were designed. The experiments were conducted on a server equipped with an Intel Xeon Gold 6230 CPU and 64GB of memory, using Hyperledger Fabric 2.4 to build a distributed ledger environment. The experimental dataset simulated a supply chain network including one core enterprise, 10 Tier 1 suppliers, and 100 Tier 2 suppliers, generating 1000 multi-level debt splitting and transfer transactions, of which 500 were normal transactions and 500 contained abnormal operations such as amount tampering and duplicate financing. The experiment was divided into three groups: a control group (using a traditional privacy protection method based on zero-knowledge proof), an experimental group (using the complete technical solution of this invention), and an ablation experimental group (removing the PUF module, the amount hash decoupling module, and the path fingerprint chain module, respectively).

[0168] 3) Data on the correlation between key processes and effects.

[0169] To verify the aforementioned direct effect A: the root of trust possesses unclonable device uniqueness, uniqueness and stability tests were conducted on the unique identity credentials generated by the PUF module. Experimental results show that the average Hamming distance of 100 credentials generated from 100 different devices is 49.8% (ideal value is 50%), demonstrating the good uniqueness of credentials from different devices. For the same device, within an ambient temperature range of -20°C to 80°C and a supply voltage range of 1.0V to 1.4V, after fuzzy extraction processing, the credential recovery success rate reaches 99.97%, demonstrating the high stability and resistance to environmental interference of the credentials. These results confirm the direct contribution of the physically unclonable property to the construction of an unreplicable device root of trust.

[0170] To verify the aforementioned [Direct Effect B: Decoupling of Amount Hash to Sever the Information Link Between the Verification Process and the Original Data], an audit analysis was conducted on the data uploaded to the blockchain during the rights confirmation and splitting process in the experimental group. The experimental results showed that in a total of 1000 transactions, all amount-related fields recorded on the distributed ledger were 32-byte hash values; the original amount data never appeared in any on-chain data or network transmission packets. Log analysis of the verification process at the financial institution's end indicated that when the verification module performed path recalculation and hash comparison, its input parameter was only the amount hash value; no original amount data was ever loaded or processed in memory. This result confirms the direct contribution of amount hash decoupling technology to achieving complete isolation between the original data and the verification process.

[0171] To verify the aforementioned direct effect C: the debt transfer trajectory possesses tamper-proof chain-like evidence, the integrity of the generated 1000 path fingerprint chains was checked. Experimental results show that the verified path fingerprints of all 1000 chains are consistent with the original path fingerprints, and the on-chain data hash values ​​and recalculated values ​​are completely identical, verifying the continuity and immutability of the hash chain. For 50 simulated transactions involving amount tampering, the verification method of extracting the amount hash value level by level could accurately locate the tampered link, achieving a detection rate of 100%. This result confirms the direct contribution of the path fingerprint chain to achieving tamper-proof evidence of the debt transfer trajectory.

[0172] To verify the aforementioned [final effect: completing three-dimensional compliance verification without accessing the original transaction pricing data], the overall performance of the three solutions was compared when processing 1000 financing requests. Experimental results show that the control group (traditional ZKP method) had an average verification time of 320 milliseconds per transaction and a privacy data leakage risk (defined as the percentage of transactions where the original amount data appears in memory during verification) of 2.3%. The experimental group (the method of this invention) had an average verification time of 18.5 milliseconds per transaction, an improvement of approximately 94.2% compared to the control group, and a privacy data leakage risk of 0%. In the ablation experiment group, after removing the amount hash decoupling module, the privacy data leakage risk increased to 18.7%; after removing the PUF module, the system's security in the simulated 51% attack scenario decreased by approximately 76% compared to the complete solution. This data demonstrates that the overall technical solution of this invention can effectively achieve efficient and reliable compliance verification without accessing the original transaction pricing data.

[0173] 4) Experimental conclusions.

[0174] The experimental data above demonstrates that the embodiments of the present invention, through constructing a data privacy protection processing mechanism of "physically unclonable anchoring of the root of trust—decoupling of data content by amount hash value—path fingerprint chain recording of the flow trajectory—triple verification to complete compliance confirmation," can: A) achieve the physical uniqueness anchoring of the root of trust, with a credential recovery success rate of 99.97%; B) achieve complete isolation between the verification process and the original data, reducing the risk of privacy data leakage to 0%; C) achieve complete and tamper-proof evidence preservation of the multi-level debt flow trajectory, with a tamper detection rate of 100%; D) reduce the time for a single compliance verification to 18.5 milliseconds, an improvement of 94.2% compared to traditional methods. This confirms that the embodiments of the present invention have significant technical effectiveness in solving the technical problem that "traditional rights confirmation verification mechanisms cannot complete effective compliance verification without accessing the original transaction pricing data because they logically rely on the original data content."

[0175] In one embodiment, a computer device is provided, which may be a core enterprise terminal, a first supplier terminal, a second supplier terminal, or a financial institution terminal, such as a server for each terminal, and its internal structure diagram may be as follows. Figure 5As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements the functions or steps of each end in a data privacy protection processing method for a multi-level supply chain.

[0176] Those skilled in the art will understand that the methods provided in the embodiments of the present invention can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. The methods can also be implemented as a computer program product stored in one or more computer-readable storage media, including but not limited to: disks, optical disks, read-only memory (ROM), random access memory (RAM), flash memory, etc. When the computer program product is executed by one or more data processing devices (such as computers), the devices perform the steps as described in any of the foregoing method embodiments.

[0177] The software tools, components, or models not belonging to our company that appear in the embodiments of this invention are merely illustrative examples and do not represent actual use.

[0178] The data collection in this embodiment of the invention complies with the requirements of relevant laws and regulations, such as the Data Security Law of the People's Republic of China, the Personal Information Protection Law of the People's Republic of China, GDPR (General Data Protection Regulation of the European Union), or information security standards of other countries and regions.

[0179] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A data privacy protection processing method for multi-level supply chains, characterized in that, include: When the core enterprise responds to the claim confirmation request, it obtains a unique identity credential generated and stored on its own end based on the physical non-cloning characteristic. Based on the unique identity credential, the core enterprise's identity identifier, and the hash value of the total amount of the claim, it generates a genesis fingerprint through hash operation and records it to the distributed ledger. When the first supplier splits and transfers the debt, it obtains the upper-level path fingerprint and its unique identity credential generated and stored on its own end based on the physical non-cloning characteristic. Based on the upper-level path fingerprint, its unique identity credential, its own identity identifier, and the hash value of the split amount, it generates the current path fingerprint through hash operation and records the transfer transaction containing the current path fingerprint to the distributed ledger. The upper-level path fingerprint is the genesis fingerprint or the path fingerprint generated by its direct upper-level supplier. When the second supplier initiates a financing request, it submits the target path fingerprint, the target amount, and the path public field sequence tracing back to the genesis fingerprint corresponding to the target debt. The target path fingerprint is a path fingerprint generated based on the first split of the genesis fingerprint, or a path fingerprint generated by the splitting and circulation of the second supplier's direct superior supplier. The financial institution receives the financing request and generates a verification path fingerprint by recalculating the path public field sequence. It then compares the hash value of the target amount with the hash value of the amount contained in the target path fingerprint to verify the consistency of the amount without knowing the original amount at the previous level. In addition, it queries the on-chain status identifier of the target path fingerprint, thereby completing the compliance verification of the path validity, amount authenticity and status uniqueness of the target debt without accessing the original transaction pricing data.

2. The data privacy protection processing method for multi-level supply chains as described in claim 1, characterized in that, The unique identity credential is generated through the following steps: Send a challenge signal to the pre-defined physical non-cloning function circuit on this end; Based on the random physical differences introduced into the manufacturing process of the physically unclonable function circuit, a unique response signal is generated; The unique response signal is subjected to error correction encoding and fuzzy extraction processing to generate a stable and unique identity credential, which is then stored in a secure storage area on the local device and is prohibited from being read externally.

3. The data privacy protection processing method for multi-level supply chains as described in claim 2, characterized in that, The physically unclonable function circuit is a static random access memory type physically unclonable function circuit. The challenge signal is a set of memory cell addresses of the corresponding static random access memory. The unique response signal is the nondeterministic initial state value of the memory cell corresponding to the memory cell address at the moment of power-on due to process deviation.

4. The data privacy protection processing method for multi-level supply chains as described in claim 2, characterized in that, The unique response signal is subjected to error correction encoding and fuzzy extraction processing to generate a stable and unique identity credential, including: A random mask is applied to the unique response signal to generate auxiliary data; The auxiliary data and the random mask are input into a preset forward error correction encoder to generate error correction codewords; Perform an XOR operation between the error correction codeword and the unique response signal to obtain the XOR result; The result of the XOR operation is extracted to obtain a stable and unique identity credential.

5. The data privacy protection processing method for multi-level supply chains as described in claim 1, characterized in that, Comparing the hash value of the target amount with the hash value of the amount contained in the target path fingerprint to verify the consistency of the amount without knowing the original amount at the previous level, including: From the path public field sequence, extract the monetary hash value contained in each level of the path fingerprint between the genesis fingerprint and the target path fingerprint. Following the order of splitting and transferring, the hash values ​​of each level of amount are concatenated sequentially, and then hashed to generate a verification amount digest. The verification amount summary is compared with the amount chain summary pre-stored on the distributed ledger. The amount chain summary is generated and recorded by the direct upstream supplier corresponding to the target claim during the splitting and transfer process, so as to verify the continuity and consistency of the split amount at each level along the entire path without knowing the original amount at each level.

6. The data privacy protection processing method for multi-level supply chains as described in claim 5, characterized in that, After verifying the continuity and consistency of the split amounts at each level throughout the entire path, the following steps are also included: Receive the zero-knowledge scope proof submitted by the second supplier, the zero-knowledge scope proof being used to prove that the target amount does not exceed the amount split by its direct superior supplier; Using the amount hash value contained in the target path fingerprint as public input, the zero-knowledge scope proof is verified without knowing the amount split by the direct upstream supplier or the specific value of the target amount.

7. The data privacy protection processing method for multi-level supply chains as described in claim 6, characterized in that, The zero-knowledge scope proof is a Bulletproofs proof. Verification of the zero-knowledge scope proof includes: The amount hash value contained in the target path fingerprint and the hash value of the target amount are used as public inputs; The Bulletproofs are verified by inner product proof to verify that the target amount is less than or equal to the amount split by the direct upstream supplier without revealing the specific value of the amount split by the direct upstream supplier and the target amount.

8. The data privacy protection processing method for multi-level supply chains as described in claim 1, characterized in that, After querying the on-chain state identifier of the target path fingerprint, the process also includes: When the on-chain status identifier of the target path fingerprint is found to be frozen or has a financing record, a verification anomaly record is generated. The verification anomaly record contains the target path fingerprint and the current timestamp. Broadcast the verification exception record to the distributed ledger; Query all historical financing records associated with the target path fingerprint and generate a debt status anomaly report. The debt status anomaly report includes the block height of the first valid financing record and the transaction hash value of the current freeze operation.

9. The data privacy protection processing method for multi-level supply chains as described in claim 1, characterized in that, The hash operation employs a cryptographic hash algorithm resistant to quantum computing attacks; The cryptographic hash algorithm is a lattice-based hash algorithm or a multivariate polynomial-based hash algorithm; The genesis fingerprint and the path fingerprints at each level are all generated based on the cryptographic hash algorithm.

10. A data privacy protection processing system for multi-level supply chains, characterized in that, include: The core enterprise module is used to respond to debt confirmation requests, obtain a unique identity credential generated and stored on the local end based on the physical non-cloning characteristic, and generate a genesis fingerprint through hash operation based on the unique identity credential, the core enterprise identity identifier and the hash value of the total amount of the confirmed debt, and then record it to the distributed ledger. The first supplier-side module is used to obtain the upper-level path fingerprint and its unique identity credential generated and stored on the local end based on the physical non-cloning characteristic when the debt is split and transferred. Based on the upper-level path fingerprint, its unique identity credential, the local identity identifier and the hash value of the split amount, the current path fingerprint is generated through hash operation. The transfer transaction containing the current path fingerprint is recorded in the distributed ledger. The upper-level path fingerprint is the genesis fingerprint or the path fingerprint generated by its direct upper-level supplier. The second supplier module is used to submit the target path fingerprint, target amount and path public field sequence back to the genesis fingerprint when initiating a financing request. The target path fingerprint is a path fingerprint generated based on the first split of the genesis fingerprint, or a path fingerprint generated when the second supplier module splits and transfers the direct superior supplier module. The financial institution module receives the financing request, recalculates the path public field sequence to generate a verification path fingerprint, compares the hash value of the target amount with the amount hash value contained in the target path fingerprint to verify the consistency of the amount without knowing the original amount at the previous level, and queries the on-chain status identifier of the target path fingerprint. Thus, it completes the compliance verification of the path validity, amount authenticity and status uniqueness of the target debt without accessing the original transaction pricing data.

Images