Multi-dimensional credit asset traceability system and method

Abstract

The invention discloses a multi-dimensional credit asset traceability system and method. The system comprises a data acquisition and encryption module (10) which is used for performing encryption and digital signature on credit asset data based on a trusted execution environment (TEE) and a hardware security module (HSM) at a data generation end; the parallel Hash processing module (20) is used for performing parallel Hash operation on the encrypted data and generating leaf node Hash values based on GPU acceleration and a multi-thread technology; the nested hash and zero-knowledge proof module (30) constructs leaf node hash values into a compression type Merkle tree and generates a zero-knowledge proof (ZKP), so that a third party can verify the authenticity and consistency of data without accessing full data; the on-chain evidence storage module (40) is used for recording root Hash (RootHash) and zero knowledge proof of the compression type Merkle tree to the block chain; the dynamic authorization and secure multi-party computing module (50) performs access clipping on the credit asset data based on the access intention and realizes verification of the minimum data dimension through secure multi-party computing (SMPC). Through combination of technical means such as trusted hardware acquisition, parallel hash calculation and privacy protection verification, rapid verification is realized on the premise of not exposing original data, and verification performance, data security and privacy protection capability are remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer information processing and data security, in particular to a multi-dimensional credit asset traceability verification system based on a blockchain and an implementation method thereof, and belongs to the technical application of blockchain data storage, encryption verification and privacy protection. BACKGROUND

[0002] With the digital development of supply chain finance, bank credit and commercial credit evaluation business, the amount of various data related to enterprise and personal credit has increased dramatically. The acquisition, transmission, storage and verification of these data have become typical computer information processing and data security problems.

[0003] Credit data refers to various data related to supply chain finance, bank credit and commercial credit evaluation business. These data are multi-dimensional, including but not limited to supplier dimension, service quality dimension, and customer performance dimension, etc. These data need to be processed such as cleaning, standardization, encryption and digital signature to ensure their authenticity, tamper resistance and security.

[0004] Existing credit asset management systems generally rely on centralized databases, which have the following technical defects: when transmitting and verifying credit data between multiple agencies, frequent full data exchange and comparison are required, and there is a lack of unified distributed verification mechanism, resulting in significant computing and network latency. The existing centralized architecture cannot effectively prevent database administrators or attackers from modifying historical records, and in the verification process, the full original data is often exposed, lacking a "minimum necessary authorization" mechanism, which can easily cause sensitive information leakage. Current credit data on-chain methods based on blockchain are mostly single-dimensional hash storage, which cannot efficiently process multi-dimensional structured data; at the same time, in large-scale data scenarios, the Merkle tree construction and verification process is mostly executed in series, with low CPU resource utilization and long verification delay. In some solutions, the verifier often needs to directly obtain and process the original credit data, lacking the ability to use zero-knowledge proof (ZKP), secure multi-party computation (SMPC) and other technologies to complete verification without exposing the original data.

[0005] Therefore, there is an urgent need for a multi-dimensional credit asset traceability verification system that combines computer technology such as trusted hardware acquisition, encrypted storage and transmission, parallelized hash calculation, and privacy protection verification, which can ensure the authenticity and tamper resistance of the data, and also enable fast verification without exposing the original data, while having high performance and scalability. SUMMARY

[0006] The present application proposes a multi-dimensional credit asset traceability verification system based on a blockchain, which combines trusted hardware acquisition, nested hash packaging, zero-knowledge proof, and parallelized Merkle tree construction to achieve efficient on-chain storage and secure verification of multi-dimensional credit data.

[0007] The application provides a multi-dimensional credit asset traceability system, characterized in that it comprises: a data acquisition and encryption module for encrypting and digitally signing credit asset data based on a trusted execution environment (TEE) and a hardware security module (HSM) at a data generation end to ensure that the source data is tamper-proof; a parallel hash processing module for performing parallel hash operations on the encrypted data to generate leaf node hash values based on GPU acceleration and multi-threading technology; a nested hash and zero-knowledge proof module for constructing the leaf node hash values into a compressed Merkle tree and generating a zero-knowledge proof (ZKP) to enable a third party to verify the authenticity and consistency of the data without accessing the full amount of data; an on-chain record module for recording the root hash (RootHash) of the compressed Merkle tree and the zero-knowledge proof to a blockchain and recording access requests and authorization information through a smart contract; a dynamic authorization and secure multi-party computation module for performing access pruning on the credit asset data based on access intentions and realizing verification of the minimum data dimension through secure multi-party computation (SMPC).

[0008] Another aspect of the application is to provide a multi-dimensional credit asset traceability method, comprising the following steps: S1. encrypting and digitally signing credit asset data at a data generation end through a trusted execution environment (TEE) and a hardware security module (HSM) to ensure that the source data is tamper-proof; S2. inputting the encrypted data into a parallel hash processing module to generate leaf node hash values based on GPU acceleration and multi-threading computation; S3. in a nested hash and zero-knowledge proof module, constructing the leaf node hash values into a compressed Merkle tree and generating a zero-knowledge proof (ZKP) to enable a third party to verify the authenticity and consistency of the data without accessing the full amount of data; S4. recording the root hash (RootHash) of the compressed Merkle tree and the zero-knowledge proof to a blockchain and recording access requests and authorization information in an on-chain record and smart contract module; S5. in a dynamic authorization and secure multi-party computation module, pruning the data access range according to access intentions and performing verification through secure multi-party computation (SMPC).

[0009] Preferably, the parallel hash processing module comprises a task distribution unit for batch segmentation of data and a multi-threaded hash operation unit based on task queue scheduling.

[0010] Preferably, the compression type Merkle tree adopts node replication and index compression, reduces redundant nodes when the number of nodes is not a power of 2, and reduces the storage amount on the chain.

[0011] Preferably, the zero-knowledge proof (ZKP) is generated based on the PLONK protocol or the Groth16 protocol.

[0012] Preferably, the on-chain evidence and smart contract module further comprises an audit log generation unit for timestamp recording and non-tamperable storage of all access requests and authorizations.

[0013] Preferably, in step S2, the parallel hash processing is based on the formula The calculation task takes time, wherein is the total time consumption of parallel processing; is the total time consumption of serial processing; P is the number of parallel threads or GPU cores.

[0014] Preferably, the dynamic authorization and secure multi-party computation module (50) maps the access intention to the required minimum data dimension set based on a pre-defined access intention mapping table.

[0015] The present application can produce the following significant technical effects in the process of blockchain multi-dimensional credit asset traceability and verification: Verification performance is significantly improved: through GPU acceleration and multi-thread parallel hash calculation, the Merkle tree construction speed is improved by more than 50% compared with the traditional serial method; the compressed Merkle tree structure reduces the number of nodes, and in the case of large-scale data, the on-chain verification time is shortened to about 40% of the original scheme; zero-knowledge proof (ZKP) makes third-party verification unnecessary to download full data, reducing network transmission overhead by more than 30%.

[0016] Data security is enhanced: introduce trusted execution environment (TEE) and hardware encryption module (HSM) at the data collection end, complete encryption and signature at the data generation link, ensure that the source data is tamper-proof; use TLS 1.3 encryption transmission and end-to-end digital signature verification throughout the link to prevent man-in-the-middle attacks and data leakage; the on-chain smart contract records all access requests and authorization information, forming an unalterable audit log for easy security traceability.

[0017] Privacy protection capability is improved: based on the dynamic authorization mechanism of access intention, the data access range can be automatically trimmed, only the minimum necessary data dimension is exposed, and full information leakage is avoided; combined with secure multi-party computation (SMPC) and zero-knowledge proof, the verifier can complete the authenticity and consistency verification without directly accessing the original data, meeting the financial data compliance requirements.

[0018] System scalability and adaptability are improved: modular architecture design can support existing dimensions such as suppliers, service quality, customer compliance, and can be extended to more credit dimensions according to business needs; compatible with mainstream blockchain platforms such as Ethereum and Hyperledger Fabric, and supports hybrid storage architecture on and off the chain, facilitating deployment in different business environments.

[0019] Measurable comprehensive improvement: the upper chain storage delay is reduced to milliseconds, and a single node can support concurrent storage operations of ten thousand credit assets; the verification throughput is increased by 2-3 times, and can be linearly expanded under multi-node deployment; the risk of data leakage is significantly reduced, and the access range and authorization records can be confirmed through security audit.

[0020] Through the above technical effects, the application not only provides management capability of multi-dimensional credit assets at the business level, but also realizes quantifiable improvement in computer technology indicators such as computing performance, data security, privacy protection and system scalability, ensuring efficiency, reliability and compliance in actual application. BRIEF DESCRIPTION OF DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the embodiments or the related art, the following will briefly introduce the drawings needed to be used in the embodiment or related art description. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor.

[0022] Figure 1 The overall system unit function structure diagram of the embodiment; Figure 2 The method flowchart of the second embodiment. DETAILED DESCRIPTION

[0023] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0024] It should be noted that the terms "include" and "have" and any variations thereof in the embodiments of the present application and the drawings are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device including a series of steps or units is not limited to the listed steps or units, but can optionally include steps or units not listed, or can optionally include other steps or units inherent to the process, method, product or device.

[0025] The system of the present application is composed of five parts: data collection and encryption module 10, parallel hash processing module 20, nested hash and zero-knowledge proof module 30, on-chain storage module 40, dynamic authorization and secure multi-party computation module 50. The system deployment structure is as shown in Figure 1 .

[0026] Data collection and encryption module 10: The system deploys a collection device with a trusted execution environment (TEE) at the data collection end, which can adopt ARM TrustZone or Intel SGX architecture to perform data collection, encryption and signature operations in a hardware isolated secure area. At the same time, the collection device integrates a hardware security module (HSM) for local generation and secure storage of asymmetric key pairs to prevent private key leakage.

[0027] During the collection process, the system obtains raw data from the dimensions of suppliers, service quality and performance, and performs cleaning and standardization processing on the data. Missing values are filled in by mean imputation method, and abnormal values are removed by 3σ principle. For numerical features, the following standardization operation is performed: Where μ is the sample mean and σ is the standard deviation; the category type feature uses One-Hot encoding method. The standardized data is encrypted by the HSM module using AES-256 symmetric encryption, and the SHA-256 hash value is signed using the device private key using ECDSA digital signature, and the signature process is as follows: The encrypted data and its signature are transmitted to the off-chain processing node through the TLS 1.3 protocol, thereby ensuring the authenticity, tamper resistance and security of the data at the data generation link.

[0028] This module is responsible for collecting multi-dimensional credit data from various data sources and performing encryption processing to prevent leakage during transmission and processing. The encrypted data is directly passed to the parallel hash processing module 20 for subsequent processing, providing a secure and reliable raw data basis for the entire system.

[0029] Parallel hash processing module 20: In this embodiment, after receiving the encrypted data, the off-chain processing node first divides the dataset into three subsets, D1, D2, and D3, according to the dimensions, and then divides each subset into several batches Bi (the i-th batch), so that each batch can be individually assigned to a thread or node for computation, enabling parallel computation. The parallel hash processing module (20) includes a task distribution unit, which is used to divide the encrypted dataset to be processed according to a preset batch size and allocate it to multiple threads or GPU cores for hash computation; the batching method is denoted as Bi, where i represents the batch number.

[0030] This embodiment utilizes the NVIDIA CUDA architecture to call the GPU to perform parallel SHA-256 computation. Each GPU thread is responsible for processing the hash operation of one data block. Its parallel acceleration effect can be expressed as follows: Where P is the number of concurrent GPU threads; This represents the total time spent on parallel processing. The total time for serial processing is considered. In actual testing (RTX 3080 GPU), for example, with 100,000 records, the serial hash calculation for a single record takes 24 μs, while the parallel calculation takes 0.95 seconds, which is about 2.53 times faster than the 2.4 seconds of serial calculation.

[0031] To improve the efficiency of Merkle tree construction, this embodiment adopts a compressed balanced binary tree structure. When the number of nodes is not a power of 2, redundant nodes are reduced through a "node copying + index compression" strategy. The construction formula is as follows: in The hash value of the parent node; SHA256 is the hash function. The hash value of the left child node; This is the hash value of the right child node.

[0032] The number of nodes can be reduced by about 27% after compression, thereby reducing on-chain storage usage and verification latency.

[0033] This module utilizes multi-threaded or GPU parallel computing to perform hash operations on data blocks from the data acquisition and encryption module 10, generating a list of hash values ​​for each data block, thereby significantly improving data preprocessing speed. These hash values ​​will be used as input to the nested hashing and zero-knowledge proof module 30 for integrity protection and privacy verification.

[0034] Nested Hash and Zero-Knowledge Proof Module 30 In this embodiment, the first-level hash value is calculated for each dimension of the dataset: , , D1, D2, and D3 are the original data blocks, which are the results of splitting the input dataset according to certain rules.

[0035] To construct a nested hash structure, if the number of leaf nodes is less than a power of 2, copy the last node H3 to obtain H4, and then perform the following steps: Step S1 ; Step S2 ; Step S3 ; RootHash is the root hash value of a Merkle tree (a nested hash structure).

[0036] Meanwhile, the system, based on zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge, a zero-knowledge proof technique that allows one party (the prover) to prove the correctness of an assertion to another party (the verifier) ​​without revealing the specific content of the assertion, and the proof process is concise and non-interactive), such as using the PLONK protocol or Groth16 protocol, generates a zero-knowledge proof 𝜋 to prove the correctness relationship between the hash values ​​of each dimension and the RootHash. The generation process is as follows: The verifier, without obtaining the original data, verifies the data through a verification function: This allows us to determine whether the data is authentic and valid. Test results show that the verification latency using zero-knowledge proof is 20ms, which is about 85% lower than the original data comparison method.

[0037] This module calculates the RootHash from the hash value from the parallel hash processing module 20 according to a nested hash structure (such as a Merkle tree), and generates a zero-knowledge proof (ZKP) based on the RootHash to complete integrity verification without exposing the original data. The generated RootHash and ZKP will be transmitted to the on-chain storage module 40 and the off-chain indexing and verification module 50, respectively, to provide core data for the storage and verification process.

[0038] On-chain evidence storage module 40: Off-chain nodes generate a CreditAssetProof data structure, which includes a unique identifier credit_id, RootHash, hash values ​​for each dimension, the publisher's public key, a timestamp, a digital signature, and a zero-knowledge proof. The CreditAssetProof is submitted to the blockchain via a smart contract, which performs the following verification: The ECDSA verification algorithm is invoked to confirm the signature validity; the zk-SNARK verification function is invoked to verify the correctness of the zero-knowledge proof; and the access request and verification result are written to an immutable audit log on the blockchain. Furthermore, the hash value of the audit log is written back to the blockchain, forming a two-layer evidence storage structure, further enhancing traceability and tamper-proof capabilities.

[0039] This module is responsible for recording the RootHash and necessary metadata from the nested hash and zero-knowledge proof module (30) on the blockchain to form an immutable on-chain notarization. This notarization information will be referenced by the off-chain index and verification module (50) during the verification process to compare and verify the validity and integrity of the data. The on-chain notarization and smart contract module (40) may further include an audit log generation unit, which records all access requests and authorization information in the form of timestamps and stores them immutably on the blockchain during smart contract execution to form an audit log.

[0040] Dynamic authorization and secure multi-party computation module 50 When a third party requests access, it must submit its access intent (loan_audit, insurance_underwriting, supplier_check, etc.). The system automatically matches the minimum required data dimension based on predefined mapping rules and generates the corresponding authorization credentials. To complete verification without revealing the original data, the system uses the Shamir secret sharing algorithm for secure multi-party computation, decomposing the hash value of each dimension into multiple shares. Share j The j-th share is a secret share obtained through polynomial calculation and distributed to the j-th participant.

[0041] a i For polynomial system Number, Where a0 is the secret value itself, and the others a1, a2, ..., a k−1These are randomly selected coefficients used to construct the polynomial. J is the share index (or number), usually a non-zero integer representing the j-th participant; mod p represents the modulo operation on the result, where p is a large prime number to ensure the operation is performed in a finite field to prevent overflow and ensure security. k represents the minimum number of shares required to recover the secret, i.e., the "threshold" value. The secret can be recovered as long as at least k shares are collected.

[0042] The verifier can reconstruct the verification value and determine the data validity by collecting no fewer than k Shares. This process does not require the transmission of the original data, effectively preventing the leakage of sensitive information.

[0043] This module is responsible for determining the validity of target data when a verification request occurs, by combining the RootHash provided by the on-chain storage module 40 with the ZKP proof data generated by the nested hash and zero-knowledge proof module 30. In this way, fast, efficient, and privacy-secure data verification can be completed without transmitting or exposing the original data.

[0044] Example 2, based on the system structure and technical process described in Example 1, elaborates on the operational steps of each functional module in detail, combined with a specific application scenario. It also uses example parameters for numerical calculations to intuitively illustrate the processing flow and performance of the present invention's technical solution in actual deployment. This example clearly verifies the significant advantages of the present invention in data processing speed, storage consumption, and privacy protection, providing reviewers and technicians with a repeatable and verifiable implementation reference.

[0045] Parameter settings (used for numerical input; these are all illustrative selections and can be replaced according to actual deployment). a) Number of credit assets to be processed: N=10000.

[0046] b) Number of dimensions per asset: 3 (supplier, service, execution).

[0047] c) Average size of the original structured data per dimension: .

[0048] d) SHA-256 output length: .

[0049] e) Smart contracts store metadata other than root_hash: .

[0050] f) Digital signature length (ECDSA): .

[0051] g)zk-SNARK proof size (example): .

[0052] h) Merkle partial proof size (example): .

[0053] i) Network bandwidth (example): .

[0054] j) SHA-256 serial single-run time (example measured): .

[0055] k) Approximate time estimate for a single SHA operation after GPU parallelization (example speedup 2.53): .

[0056] l) ECDSA signature time (HSM, example): .

[0057] m) AES-256 hardware acceleration encryption time for 1KB (example): =5μs.

[0058] n) Time spent per dimension for data cleaning / standardization (example): .

[0059] o)zk-SNARK generation (Prove) time (example): (Can be done in parallel).

[0060] p)zk-SNARK verification time (example): .

[0061] q) SMPC / Shamir copy threshold example: threshold k=3, each copy size is approximately 32 bytes.

[0062] r) On-chain batch write size (example): Each transaction packages 100 assets in Bonchain; the average confirmation / commit time for each on-chain transaction is... (Example).

[0063] s) The number of prover worker nodes that can be used to generate proofs in parallel (example): W=100. Note: The example parameters above are used to demonstrate numerical computation and effect quantification.

[0064] like Figure 2 The diagram shown is a flowchart of a method embodiment. Specifically: Step S1 — Source-side trusted data collection and local processing (TEE+HSM) Deploy a Trusted Execution Environment (TEE) and Hardware Security Module (HSM) on the source device (enterprise side). Perform the following operations on each asset across three dimensions: missing value imputation (mean / interpolation), outlier removal (3σ method), and numerical feature standardization (…). The data is first categorically and then one-hot encoded for each dimension. Then, the SHA-256 hash of each dimension is calculated, and the hash value is ECDSA-signed using the device's private key within the HSM. Finally, the original dimension data is AES-256 encrypted and sent to the off-chain processing node via TLS 1.3 (the off-chain node is used for subsequent parallel processing and encapsulation).

[0065] Data cleaning time (3 dimensions): Time taken per dimension hash (3 SHA operations) (measured serially): ECDSA signing (3 times) time: AES-256 encryption (3 times, 1KB / dimensional) time: The amount of data transmitted from the source node to the off-chain node (including signature): Corresponding transmission time (100 Mbps): Total time spent on a single asset in S1: Substituting the values ​​into the equation: That is approximately 5.442 ms / message.

[0066] Total time (batch N records) (excluding parallel processing): Step S2 — Parallel hash computation and compressed Merkle construction (off-chain parallelization) The off-chain processing nodes perform parallel hashing acceleration (GPU / CUDA or multi-core parallelism) on the received hashes (or decrypted data) of each dimension. For each asset, a balanced binary Merkle Tree is constructed in a predetermined order (if the number of leaf nodes is not a power of 2, the last leaf is copied to make up the gap), and the parent nodes L1, L2 and root hash RootHash are calculated.

[0067] Formulas and values ​​(for a single asset): Number of hash operations between parent and root nodes: 3 (L1, L2, Root); Parallel SHA processing time (time per operation using parallel SHA): Therefore, the time required to construct a parent / root hash for a single asset is: That is approximately 0.02846 ms / strip (28.46 μs / strip).

[0068] Total time elapsed (excluding parallel scheduling overhead): Step S3 — Nested hash wrapping and zero-knowledge proof generation (zk-SNARK): For each asset, construct the RootHash from the three dimension hashes H1, H2, and H3 using the Merkle obtained in step S2; generate a zero-knowledge proof π off-chain using zk-SNARK (or equivalent ZKP) to verify the correctness relationship between the RootHash and the hashes of each dimension; the generated proof can be submitted along with the certificate or transmitted to the verifier as needed.

[0069] Single asset zk-SNARK generation time (example): Total time taken to prove all N lines (serial): That is, 25 minutes (generated serially).

[0070] Parallel processing (example): If we deploy W=100 prover workers (for generating zero-knowledge proofs) in parallel nodes, the wall-clock time is approximately: Single proof confirmation size (example): Proof generation is typically computationally intensive, but the overall wall time (the total time elapsed in the real world from task start to task finish) can be reduced to an acceptable level by horizontally scaling the prover (computational side) nodes for parallelization; in the example above, with W=100, the wall time after parallelization is 15 seconds.

[0071] Step S4 — Generate off-chain evidence object (CreditAssetProof) and store it on-chain. For each asset, an off-chain notarization object, CreditAssetProof, is generated, containing the fields: credit_id, root_hash, dimension_hashes, issuer_pubkey, timestamp, sign, and proof (π). Necessary fields (at least root_hash and metadata) are written to the blockchain via a smart contract. To reduce on-chain transaction volume, a per-bill approach is adopted. onchain A batch processing strategy that packages a transaction into a single transaction.

[0072] Minimum amount of data to be stored on a single asset chain (example only stores RootHash + metadata): here, This is the standard output length of a SHA-256 hash. Regardless of the input data size, the output of SHA-256 is a fixed 256 bits (256 / 8 = 32 bytes). M=200 is the size set by the on-chain appender, which can be adjusted according to the number and length of fields in the actual system metadata.

[0073] When storing the RootHash on the chain, the hash value that needs to be saved is this 32-byte length.

[0074] The total on-chain space occupied by all N records (if only the minimum field is stored): If calculated per If each item is packaged into a single on-chain transaction, then the number of transactions is: Assuming average on-chain confirmation time per transaction The total wall-clock delay for writing to the chain is then (example): This module is responsible for recording the RootHash and necessary metadata from the nested hash and zero-knowledge proof module 30 on the blockchain, forming an immutable on-chain notarization. This notarization information will be referenced by the off-chain indexing and verification module 50 during the verification process to compare and verify the validity and integrity of the data.

[0075] Step S5—Least Authorization and Secure Multi-Party Computation (SMPC) Verification Based on Access Intent When a third party requests verification, it submits an access intent (e.g., loan_audit, insurance_underwriting). The system determines the minimum set of dimensions required based on the intent mapping table (e.g., loan approval: {supplier, execution}). To avoid exposing the original data, the relevant parties use Shamir secret sharing or the SMPC protocol to shard / locally compute and exchange shares for the hashes of the involved dimensions or intermediate verification values, thereby completing the verification function f(⋅) without revealing the original data.

[0076] With a fragmentation threshold of k=3 and each fragment approximately 32 bytes in size, the data that needs to be transmitted (at least k fragments) during each SMPC verification phase is as follows: Validation latency (example, including local computation and network switching): per zk-SNARK validation time With several message rounds of SMPC, the single verification latency can be controlled to the tens of milliseconds level (for example, this solution can achieve a verification latency of about 20ms / time).

[0077] This module is responsible for recording the RootHash and necessary metadata from the nested hash and zero-knowledge proof module 30 on the blockchain, forming an immutable on-chain notarization. This notarization information will be referenced by the off-chain indexing and verification module 50 during the verification process to compare and verify the validity and integrity of the data.

[0078] Through the coordinated operation of its various functional modules, this invention achieves the following significant technical effects: First, in terms of verification performance, the parallel hash processing module 20 of this invention, combined with GPU acceleration and multi-threaded parallel computing technology, significantly improves the construction speed of the Merkle tree, increasing it by more than 50% compared to the traditional serial method. Furthermore, by optimizing the Merkle tree structure through node compression, the number of nodes in the tree structure is reduced, shortening the on-chain verification time to approximately 40% of the original solution. In the nested hash and zero-knowledge proof module (30), zero-knowledge proof (ZKP) technology is used, enabling third-party verification to complete authenticity verification without downloading the full amount of data, thereby reducing network transmission overhead by approximately 30%.

[0079] Secondly, regarding data security, the data acquisition and encryption module 10 of this invention introduces a Trusted Execution Environment (TEE) and a Hardware Security Module (HSM) at the data generation end, completing data encryption and signing during the acquisition phase to ensure the immutability of the source data. The entire chain employs the TLS 1.3 encrypted transmission protocol and an end-to-end digital signature verification mechanism to prevent man-in-the-middle attacks and data leakage. Simultaneously, the on-chain evidence storage and smart contract module 40 records all access requests and authorization information, forming an immutable audit log for easy subsequent security traceability.

[0080] Furthermore, regarding privacy protection, the dynamic authorization and secure multi-party computation module (50) of this invention, based on the dynamic authorization mechanism of access intent, can automatically trim the scope of data access, exposing only the minimum necessary data dimensions and avoiding the leakage of all information. Combining secure multi-party computation (SMPC) and zero-knowledge proof (ZKP) technologies, it enables the verifier to complete the verification of the authenticity and consistency of the data without directly accessing the original data, meeting the compliance requirements in financial data scenarios.

[0081] Furthermore, regarding system scalability and adaptability, this invention adopts a modular architecture design, supporting existing credit dimensions such as suppliers, service quality, and customer fulfillment, and can be expanded to more credit dimensions according to business needs. The system is compatible with mainstream blockchain platforms such as Ethereum and Hyperledger Fabric, and supports a hybrid on-chain and off-chain storage architecture, facilitating deployment and application in different business environments.

[0082] Finally, regarding measurable overall performance improvements, this invention reduces on-chain evidence storage latency to milliseconds, enables a single node to support concurrent evidence storage operations for tens of thousands of credit assets, increases verification throughput by 2-3 times, and achieves near-linear scalability under multi-node deployment conditions. Simultaneously, by leveraging access pruning mechanisms and secure multi-party computation technology, the risk of data leakage is effectively reduced, and security audits confirm that the access scope and authorization records are completely consistent, thus ensuring the system's comprehensive advantages in performance and security.

[0083] The table below lists the effects obtained by substituting the above values ​​into the technical solution of this application, and compares them with the baseline values ​​used for comparison (only the values ​​are shown, without describing the implementation method of the baseline). The "baseline values" in the table are reference values ​​used for quantitative comparison as an example.

[0084] Table 1: Comparison of the effects of this application and the baseline solution (prior art) Note: The "baseline values" in the table above are for illustrative reference (used for quantitative comparison). The values ​​in this application are derived from the step-by-step substitution calculations described above (cumulative and parallelized estimation of values ​​from S1 to S5). It is evident that this application, through the introduction of technologies such as TEE / HSM, parallelized SHA, nested Merkle + ZKP, SMPC, and on-chain batch writes, has achieved significant quantitative improvements in key indicators such as on-chain storage, network transmission, verification latency, and throughput.

[0085] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of one embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing the present invention.

[0086] Those skilled in the art will understand that the modules in the apparatus of the embodiments can be distributed in the apparatus of the embodiments as described in the embodiments, or they can be located in one or more devices different from this embodiment with corresponding changes. The modules of the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0087] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A multi-dimensional credit asset traceability system, characterized in that, include: The data acquisition and encryption module (10) is used to encrypt and digitally sign credit asset data at the data generation end based on the Trusted Execution Environment (TEE) and Hardware Security Module (HSM) to ensure that the source data is tamper-proof; The parallel hash processing module (20) is used to perform parallel hash operations on encrypted data and generate leaf node hash values ​​based on GPU acceleration and multi-threading technology. Nested hash and zero-knowledge proof module (30) is used to construct the leaf node hash value into a compressed Merkle tree and generate a zero-knowledge proof (ZKP) so that a third party can verify the authenticity and consistency of the data without accessing the full data. The on-chain evidence storage module (40) is used to record the root hash of the compressed Merkle tree and the zero-knowledge proof to the blockchain, and to record access requests and authorization information through smart contracts; The dynamic authorization and secure multi-party computation module (50) is used to perform access trimming on the credit asset data based on the access intent and to achieve verification of the minimum data dimension through secure multi-party computation (SMPC).

2. A multi-dimensional credit asset traceability method, characterized in that, Includes the following steps: S1. At the data generation end, the credit asset data is encrypted and digitally signed through a Trusted Execution Environment (TEE) and a Hardware Security Module (HSM) to ensure that the source data is tamper-proof; S2. Input the encrypted data into the parallel hash processing module (20) to generate leaf node hash values ​​based on GPU acceleration and multi-threaded calculation; S3. In the nested hash and zero-knowledge proof module (30), the hash values ​​of the leaf nodes are constructed into a compressed Merkle tree and a zero-knowledge proof (ZKP) is generated; enabling third parties to verify the authenticity and consistency of the data without accessing the full data. S4. Write the root hash of the compressed Merkle tree and the zero-knowledge proof into the blockchain, and record the access request and authorization information in the on-chain evidence storage and smart contract module (40); S5. In the dynamic authorization and secure multi-party computation module (50), the data access scope is trimmed according to the access intent and verified using secure multi-party computation (SMPC).

3. The system according to claim 1, characterized in that, The parallel hash processing module (20) includes a task distribution unit for batching and splitting data, and a multi-threaded hash operation unit based on task queue scheduling.

4. The system or method according to claim 1 or 2, characterized in that, The compressed Merkle tree uses node replication and index compression to reduce redundant nodes when the number of nodes is not a power of 2, thereby reducing on-chain storage.

5. The system or method according to claim 1 or 2, characterized in that, The zero-knowledge proof (ZKP) generation is implemented based on the PLONK protocol or the Groth16 protocol.

6. The system according to claim 1, characterized in that, The on-chain evidence storage and smart contract module (40) further includes an audit log generation unit, which is used to timestamp and store all access requests and authorizations in an unalterable manner.

7. The method according to claim 2, characterized in that, In step 2), the parallel hashing process is based on the formula Calculate the task time, where T parallel T represents the total time spent in parallel processing. serial P represents the total time spent on serial processing; P represents the number of parallel threads or GPU cores.

8. The system or method according to claim 1 or 2, characterized in that, The dynamic authorization and secure multi-party computation module (50) maps access intentions to the minimum set of data dimensions required based on a predefined access intention mapping table.

Images