Product quality full life cycle tracing method and system based on digital twinning

Abstract

The application discloses a product quality full life cycle tracing method and system based on digital twinning, comprising the following steps: constructing a digital twinning model and corresponding to a blockchain shard; collecting data and writing into a twin shard to generate a transaction identifier; executing Byzantine fault tolerance in the blockchain by using a PrivChain-based adaptive consensus module and calling zero-knowledge range proof verification to output a consensus digest; establishing a version index chain in the twin shard to generate a snapshot and a differential result, writing into the blockchain to form a version index record; constructing a strategy graph in the blockchain to generate an access credential and corresponding to the version index record; establishing a physical and twin time axis in the twin shard to generate an anchor point mapping, forming a consistency verification record and corresponding to the access credential; when receiving a tracing request, calling a cross-shard proof aggregation module to gather records to generate an aggregated tracing proof and output a tracing report. The application realizes trusted notarization and verification of full life cycle tracing data.

Description

Technical Field

[0001] This invention relates to the fields of information processing and product quality management technology, and in particular to a product quality lifecycle traceability method and system based on digital twins. Background Technology

[0002] With the development of intelligent manufacturing and the Industrial Internet, a large amount of data is generated throughout the entire lifecycle of products, including design, manufacturing, use, maintenance, and recycling. How to manage this data in a unified and reliable manner has become an important issue in quality control. In existing technologies, digital twin models have been used to virtually model physical entities, collecting structural parameters, process parameters, operating parameters, and detection parameters at different stages, and achieving status monitoring and prediction to a certain extent. However, traditional digital twin applications are mostly limited to a single stage and lack unified modeling of the entire lifecycle, making it difficult to support complete traceability across stages. Blockchain technology, due to its decentralized, immutable, and traceable characteristics, has been introduced into product traceability systems to provide data storage and verification mechanisms. However, existing blockchain systems mostly adopt fixed consensus mechanisms and cannot automatically adjust execution parameters according to timeliness and privacy levels, making it difficult to balance efficiency and security. At the same time, although zero-knowledge proofs can protect data privacy to a certain extent, most existing solutions are only used for existence verification and lack data consistency verification for range conditions, failing to meet the needs of complex traceability scenarios for sensitive parameter protection and reliable verification.

[0003] Regarding data versioning and access control, existing technologies typically utilize snapshots or logs to record changes, but lack a systematic version indexing mechanism. This makes it difficult to efficiently locate and compare different versions, and it's also difficult to effectively integrate with blockchain notarization to form a complete version index chain, let alone establish a strong correlation with consensus results. In terms of access control, common role- or attribute-based models struggle to express the multidimensional constraints in complex traceability paths. The generation and verification of access credentials lack credibility and transparency, failing to guarantee secure access to traceability data. As the system scales, traceability data is often distributed across different twin shards and blockchain shards. Existing solutions often use splicing or querying methods to aggregate results, lacking a unified proof aggregation mechanism, making it difficult to simultaneously guarantee data integrity and verifiability when outputting traceability reports.

[0004] Therefore, how to provide a product quality full lifecycle traceability method and system based on digital twins is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] One objective of this invention is to propose a product quality lifecycle traceability method and system based on digital twins. This invention fully utilizes technologies such as digital twin modeling, blockchain consensus mechanisms, zero-knowledge scope proofs, version index management, policy graph access control, and cross-shard proof aggregation. It details the complete process of establishing twin shards and corresponding them with blockchain shards at each stage of the entire lifecycle, generating traceability records and transaction identifiers, achieving trusted evidence storage through adaptive consensus and zero-knowledge verification, constructing version index chains and differential records in the twin shards, generating access credentials in the blockchain system and associating them with version index records, establishing anchor mapping between the physical timeline and the twin timeline and generating consistency verification records, and finally converging to form aggregated traceability proofs and outputting traceability reports in the cross-shard proof aggregation module. This invention has the advantages of strong traceability process credibility, high data security, sound verification logic, and comprehensive lifecycle coverage.

[0006] The product quality lifecycle traceability method based on digital twins according to embodiments of the present invention includes the following steps:

[0007] Construct a digital twin model covering all stages, divide the twin into shards, and establish corresponding relationships with blockchain shards;

[0008] Collect lifecycle data, create traceability records, write them to the twin shard, and generate transaction identifiers;

[0009] In the blockchain system, the Byzantine fault-tolerant consensus algorithm is executed using the PrivChain-based adaptive consensus module, and zero-knowledge scope proof is called to verify the transaction identifier during the consensus process, and a consensus digest is output.

[0010] A version index chain is established in the twin shard, a snapshot and differential results are generated, written to the blockchain shard to form a version index record, and associated with the consensus digest;

[0011] In a blockchain system, a policy graph access control is constructed, access credentials are generated based on the access path, and associated with the version index record.

[0012] In the twin sharding, a physical timeline and a twin timeline are established, an anchor mapping is generated, a consistency verification record based on zero-knowledge scope proof is formed, and it is associated with access credentials;

[0013] When a traceability request is received, the cross-shard proof aggregation module is invoked to aggregate consensus digests, version index records, access credentials, and consistency verification records, generate aggregated traceability proofs, and output traceability reports.

[0014] Optionally, the blockchain system includes a registration unit for registering the correspondence between twin shards and blockchain shards, a consensus unit for processing transaction identifiers and completing Byzantine fault-tolerant consensus algorithm and zero-knowledge scope proof verification, a storage unit for receiving and storing version index records, access credentials and consistency verification records, and an aggregation unit for aggregating consensus digests, version index records, access credentials and consistency verification records to generate aggregated traceability proofs and output traceability reports upon traceability request.

[0015] Optionally, the partitioning of the twin fragment specifically includes:

[0016] Model the data from the design, manufacturing, use, maintenance and recycling phases to form a set of digital twin models covering each phase;

[0017] The digital twin model is divided into twin segments according to the stage, and each twin segment contains parameters and records related to the stage;

[0018] Establish a twin shard identifier for each twin shard and establish a corresponding blockchain shard identifier in the blockchain system;

[0019] Register the correspondence between twin shard identifiers and blockchain shard identifiers in the blockchain system.

[0020] Optionally, the generation of the transaction identifier specifically includes:

[0021] The twin segment receives data input from the digital twin model, including structural parameters, process parameters, operating parameters, and detection parameters;

[0022] The data input is processed for time alignment and amplitude normalization to unify the data format and precision, forming standardized traceability records.

[0023] Write standardized traceability records to the target twin shard, and record the writing time and shard identifier;

[0024] In blockchain sharding, transaction identifiers are generated based on traceability records. A one-to-one correspondence is established between transaction identifiers and traceability records, and registration is completed in the blockchain system.

[0025] Optionally, the generation of the consensus digest specifically includes:

[0026] In the consensus unit of the blockchain system, an adaptive consensus module is configured. The adaptive consensus module receives timeliness level parameters and privacy level parameters, sets message timeout thresholds and block intervals according to the timeliness level, and sets the set of verification fields and range rules for zero-knowledge scope proofs according to the privacy level.

[0027] The adaptive consensus module generates the execution configuration, which includes the view number, sequence number, round timeout, batch threshold, list of participating nodes and admission rules, and starts the Byzantine fault-tolerant consensus algorithm.

[0028] Collect transaction identifiers to form a proposal, perform a hash operation on the proposal to obtain the proposal hash value, attach the view number and sequence number, package the proof data and verification parameters of the zero-knowledge scope proof, and broadcast the pre-preparation message to the participating nodes;

[0029] After receiving the pre-preparation message, participating nodes verify the consistency of the signature, view number, sequence number, proposal hash value, and the validity of the zero-knowledge scope proof data. When the verification is successful, they record the preparation for voting and enter the preparation phase.

[0030] During the preparation phase, when the number of prepared votes reaches the preparation threshold, the submission phase begins, and a submission message is broadcast. The submission message includes the proposal hash, the set of node signatures, and the sequence number.

[0031] When a round times out, the adaptive consensus module performs view maintenance, updates the view number and sequence number, and re-initiates a pre-preparation message for the current proposal;

[0032] During the submission phase, when the number of submission messages reaches the submission threshold, a consensus result is formed, and a consensus digest is generated. The consensus digest includes the block height, view number, proposal hash value, zero-knowledge scope proof verification result, number of votes, timestamp, and block-producing node identifier, and is written to the blockchain shard.

[0033] Establish a one-to-one correspondence between consensus summaries and transaction identifiers, and register the one-to-one correspondence in the blockchain system.

[0034] Optionally, the generation of the version index record specifically includes:

[0035] In the twin shard, a version index chain is established, a version number is set and a parent version number is recorded to organize the sequential relationship between version nodes;

[0036] Collect the current state of the twin shards and generate a snapshot. The snapshot includes a parameter set, a generation timestamp, a shard identifier, and a transaction identifier reference.

[0037] The current snapshot is compared with the previous version snapshot to form a difference result, which includes the changed fields, changed values ​​and time intervals.

[0038] Calculate the hash values ​​for the snapshot and differential results respectively to obtain the snapshot hash value and the differential hash value, and record the corresponding version number and parent version number;

[0039] Write the snapshot hash, differential hash, version number, parent version number, and transaction identifier reference into the blockchain shard to form a version index record;

[0040] In the blockchain system, a one-to-one correspondence is established between the version index record and the consensus digest, and registration is completed.

[0041] Optionally, the generation of the access credentials specifically includes:

[0042] In a blockchain system, a strategy graph is constructed. The strategy graph consists of principal nodes and resource nodes, and each edge represents the access path between the principal node and the resource node.

[0043] Configure access rules for each access path. Access rules include allowed operation types, allowed access time ranges, and allowed access node ranges, and assign a unique identifier to each access rule.

[0044] Upon receiving an access request, the access rules are located based on the access path. The operation type, time range, and node range are extracted from the access rules, and the zero-knowledge range proof mechanism is invoked to verify the consistency between the access request parameters and the access rule parameters.

[0045] After the consistency verification is completed, an access credential is generated in the blockchain system. The access credential includes an access path identifier, an access rule identifier, a zero-knowledge scope proof verification result, and a generation time.

[0046] Establish a one-to-one correspondence between the generated access credentials and the version index records, and complete the registration in the blockchain system.

[0047] Optionally, the generation of the consistency verification record specifically includes:

[0048] A physical timeline is established in the twin shards, and the physical timeline records the physical timestamps of the trace records according to the acquisition order;

[0049] A twin timeline is established in the twin shard, and the twin timeline records the twin timestamps of the trace records according to the calculation order;

[0050] Extract the corresponding physical timestamp and twin timestamp between the physical timeline and the twin timeline, combine the two to form an anchor point, and assign a mapping identifier to the anchor point to generate an anchor point mapping.

[0051] The zero-knowledge scope proof mechanism is invoked to verify the anchor mapping, generating a consistency verification record. The consistency verification record contains the mapping identifier, verification parameters, and verification result.

[0052] Establish a one-to-one correspondence between consistency verification records and access credentials.

[0053] Optionally, the generation of the traceability report specifically includes:

[0054] In the aggregation unit of the blockchain system, the cross-shard proof aggregation module is called to receive the traceability request, which includes the traceability scope, shard identifier, version information and time interval;

[0055] The target twin shard and blockchain shard are determined based on the shard identifier, and consensus digest, version index record, access credential and consistency verification record are extracted from the blockchain shard.

[0056] Input the consensus digest, version index record, access credential, and consistency verification record into the cross-shard proof aggregation module, and perform aggregation processing to generate an aggregated traceability proof.

[0057] The blockchain system outputs a traceability report, which includes the traceability scope, shard identifier, version information, time interval, and aggregated traceability proof.

[0058] According to an embodiment of the present invention, a product quality lifecycle traceability system based on digital twins includes:

[0059] The digital twin modeling module is used to build digital twin models covering the design, manufacturing, use, maintenance and recycling stages, divide the twin into segments and establish a correspondence between the twin and the blockchain segments in the blockchain system;

[0060] The traceability record generation module is used to receive model data input in the twin shard, perform time alignment and normalization, generate traceability records, and generate transaction identifiers corresponding to the traceability records in the blockchain shard.

[0061] The consensus processing module is used to configure the adaptive consensus module in the consensus unit, adjust parameters according to the timeliness level and privacy level, execute the Byzantine fault-tolerant consensus algorithm, and call the zero-knowledge scope proof based on PrivChain to verify the transaction identifier, generate a consensus digest and write it to the blockchain shard.

[0062] The version index management module is used to establish a version index chain in the twin shard, generate snapshots and differential results, calculate hash values ​​and write them into the blockchain shard to form version index records, and correspond them with consensus digests;

[0063] The access control module is used to build a policy graph in the blockchain system, configure access rules, and generate access credentials by calling zero-knowledge scope proofs when receiving access requests, and to correspond them with version index records.

[0064] The time consistency verification module is used to establish physical timelines and twin timelines in twin shards, generate anchor mappings and call zero-knowledge scope proofs for verification, form consistency verification records, and correspond them with access credentials;

[0065] The traceability aggregation module is used to call the cross-shard proof aggregation module in the aggregation unit, receive traceability requests, extract consensus digests, version index records, access credentials and consistency verification records, generate aggregate traceability proofs and output traceability reports.

[0066] The beneficial effects of this invention are:

[0067] This invention establishes digital twin models and divides them into twin fragments at each stage of the product's entire lifecycle. This enables data from the design, manufacturing, use, maintenance, and recycling stages to be managed and traced within a unified framework, solving the problems of limited application scope and inability to cover the entire lifecycle in existing digital twin technologies. Utilizing the adaptive consensus module in the blockchain system and the zero-knowledge range proof mechanism based on PrivChain, it not only ensures the credible storage of transaction identifiers but also enables dynamic adjustment of consensus parameters in different scenarios, thus balancing efficiency and privacy protection and effectively compensating for the shortcomings of traditional blockchain systems in terms of flexibility and security.

[0068] Regarding data versioning and access control, this invention establishes a version index chain in twin sharding, generates version index records by combining snapshot and differential results, and associates them with consensus digests, ensuring the integrity and verifiability of data during the traceability process. Simultaneously, it constructs a policy graph access control within the blockchain system, generates access credentials based on the access path, and verifies them using zero-knowledge scope proofs. This makes access control not only more refined but also transparent and trustworthy with the support of blockchain-based evidence storage.

[0069] Regarding cross-shard data aggregation, this invention utilizes a cross-shard proof aggregation module to uniformly aggregate consensus digests, version index records, access credentials, and consistency verification records, generating aggregated traceability proofs and outputting traceability reports. This solves the problems of low efficiency and fragmented verification logic in existing cross-shard traceability technologies. Therefore, this invention achieves efficient, reliable, and verifiable traceability covering the entire product lifecycle while ensuring data security and privacy. Attached Figure Description

[0070] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0071] Figure 1 This is a flowchart of the product quality lifecycle traceability method based on digital twins proposed in this invention;

[0072] Figure 2 This is a schematic diagram of cross-sharded proof aggregation processing in the product quality lifecycle traceability method based on digital twins proposed in this invention. Detailed Implementation

[0073] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0074] refer to Figure 1-2 A product quality lifecycle traceability method and system based on digital twins includes the following steps:

[0075] Construct a digital twin model covering all stages, divide the twin into shards, and establish corresponding relationships with blockchain shards;

[0076] Collect lifecycle data, create traceability records, write them to the twin shard, and generate transaction identifiers;

[0077] In the blockchain system, the Byzantine fault-tolerant consensus algorithm is executed using the PrivChain-based adaptive consensus module, and zero-knowledge scope proof is called to verify the transaction identifier during the consensus process, and a consensus digest is output.

[0078] A version index chain is established in the twin shard, a snapshot and differential results are generated, written to the blockchain shard to form a version index record, and associated with the consensus digest;

[0079] In a blockchain system, a policy graph access control is constructed, access credentials are generated based on the access path, and associated with the version index record.

[0080] In the twin sharding, a physical timeline and a twin timeline are established, an anchor mapping is generated, a consistency verification record based on zero-knowledge scope proof is formed, and it is associated with access credentials;

[0081] When a traceability request is received, the cross-shard proof aggregation module is invoked to aggregate consensus digests, version index records, access credentials, and consistency verification records, generate aggregated traceability proofs, and output traceability reports.

[0082] This invention constructs a digital twin model covering the entire product lifecycle—from design and manufacturing to use, maintenance, and recycling—and stores it in corresponding twin shards and blockchain shards, achieving complete modeling and reliable recording of data across all stages. Lifecycle data is standardized, written to the twin shards, and transaction identifiers are generated. Verification is performed in the blockchain system using adaptive consensus and zero-knowledge scope proofs to form a consensus digest, thus ensuring data tamper-proofing and traceability. Simultaneously, the version index chain, policy graph access control, time consistency verification, and cross-shard aggregation proof modules work together to ensure that traceability reports accurately reflect the entire lifecycle data chain. This invention implements a closed-loop traceability mechanism from data generation to cross-shard verification, improving the credibility and completeness of traceability.

[0083] In this embodiment, the blockchain system includes a registration unit for registering the correspondence between twin shards and blockchain shards, a consensus unit for processing transaction identifiers and completing Byzantine fault-tolerant consensus algorithm and zero-knowledge scope proof verification, a storage unit for receiving and storing version index records, access credentials and consistency verification records, and an aggregation unit for aggregating consensus digests, version index records, access credentials and consistency verification records to generate aggregated traceability proofs and output traceability reports upon traceability request.

[0084] This invention organically combines data registration, transaction identifier verification, version indexing and access control storage, and cross-shard aggregation traceability proof by setting up a registration unit, consensus unit, storage unit, and aggregation unit in the blockchain system. The registration unit ensures the one-to-one correspondence between twin shards and blockchain shards is registered, guaranteeing the integrity of the data structure; the consensus unit combines the Byzantine fault-tolerant algorithm with zero-knowledge range proofs, enhancing the security and privacy protection of the verification process; the storage unit is responsible for storing version indexes, access credentials, and consistency verification records, providing a reliable data source for traceability; and the aggregation unit can quickly call and integrate various proof data after receiving a traceability request, outputting a reliable traceability report. Through the layered design of the blockchain system, this invention significantly improves the credibility, verifiability, and processing efficiency of the traceability process.

[0085] In this embodiment, the division of the twin fragments specifically includes:

[0086] Model the data from the design, manufacturing, use, maintenance and recycling phases to form a set of digital twin models covering each phase;

[0087] The digital twin model is divided into twin segments according to the stage, and each twin segment contains parameters and records related to the stage;

[0088] Establish a twin shard identifier for each twin shard and establish a corresponding blockchain shard identifier in the blockchain system;

[0089] Register the correspondence between twin shard identifiers and blockchain shard identifiers in the blockchain system.

[0090] This invention constructs a digital twin model by separately modeling and forming twin shards from data at different lifecycle stages, assigning a unique identifier to each shard, and then establishing a corresponding relationship with blockchain shards and completing registration, thereby achieving a precise mapping between the physical world and on-chain data. Data from the design stage, such as structural parameters; manufacturing stage, such as processes and control; usage stage, such as operation and load; maintenance stage, such as inspection and repair; and recycling stage, such as reuse information, can all be accurately distinguished and managed through the sharding and identification system. By registering the corresponding relationship in the blockchain system, cross-stage data querying and verification become more efficient. This invention solves the problems of scattered lifecycle data and lack of unified registration of mapping relationships in existing traceability systems, realizing standardized modeling and trusted on-chain mapping of multi-stage data.

[0091] In this embodiment, the generation of the transaction identifier specifically includes:

[0092] The twin segment receives data input from the digital twin model, including structural parameters, process parameters, operating parameters, and detection parameters;

[0093] The data input is processed for time alignment and amplitude normalization to unify data format and precision, forming standardized traceability records;

[0094] Write standardized traceability records to the target twin shard, and record the writing time and shard identifier;

[0095] In blockchain sharding, transaction identifiers are generated based on traceability records. A one-to-one correspondence is established between transaction identifiers and traceability records, and registration is completed in the blockchain system.

[0096] This invention receives data input from different sources, including structural parameters, process parameters, operational parameters, and detection parameters, in a twin shard. It then performs time alignment and amplitude normalization to form standardized traceability records, ensuring the uniformity and comparability of data from different sources. These standardized traceability records are written to the target twin shard, recording the writing time and shard identifier to guarantee complete source traceability. Transaction identifiers are generated for the traceability records in the blockchain shard, establishing a one-to-one correspondence between each record. Registration is then completed in the blockchain system, ensuring on-chain evidence storage of the traceability data. Through this method, the invention effectively solves the problem of high heterogeneity and difficulty in unified processing of lifecycle data, achieving standardized, evidence-based, and identifier-based data management, and improving the standardization and credibility of the traceability system.

[0097] In this embodiment, the generation of the consensus digest specifically includes:

[0098] In the consensus unit of the blockchain system, an adaptive consensus module is configured. The adaptive consensus module receives timeliness level parameters and privacy level parameters, sets message timeout thresholds and block intervals according to the timeliness level, and sets the set of verification fields and range rules for zero-knowledge scope proofs according to the privacy level.

[0099] The adaptive consensus module generates the execution configuration, which includes the view number, sequence number, round timeout, batch threshold, list of participating nodes and admission rules, and starts the Byzantine fault-tolerant consensus algorithm.

[0100] Collect transaction identifiers to form a proposal, perform a hash operation on the proposal to obtain the proposal hash value, attach the view number and sequence number, package the proof data and verification parameters of the zero-knowledge scope proof, and broadcast the pre-preparation message to the participating nodes;

[0101] After receiving the pre-preparation message, participating nodes verify the consistency of the signature, view number, sequence number, proposal hash value, and the validity of the zero-knowledge scope proof data. When the verification is successful, they record the preparation for voting and enter the preparation phase.

[0102] During the preparation phase, when the number of prepared votes reaches the preparation threshold, the submission phase begins, and a submission message is broadcast. The submission message includes the proposal hash, the set of node signatures, and the sequence number.

[0103] When a round times out, the adaptive consensus module performs view maintenance, updates the view number and sequence number, and re-initiates a pre-preparation message for the current proposal;

[0104] During the submission phase, when the number of submission messages reaches the submission threshold, a consensus result is formed, and a consensus digest is generated. The consensus digest includes the block height, view number, proposal hash value, zero-knowledge scope proof verification result, number of votes, timestamp, and block-producing node identifier, and is written to the blockchain shard.

[0105] Establish a one-to-one correspondence between consensus summaries and transaction identifiers, and register the one-to-one correspondence in the blockchain system.

[0106] This invention introduces an adaptive consensus module into the consensus unit of a blockchain system. This module automatically adjusts consensus parameters based on the timeliness and privacy levels of different data, setting message timeout thresholds, block intervals, and verification rules for zero-knowledge proofs. Transaction identifiers are collected as proposals and hashed using view numbers and sequence numbers, while simultaneously broadcasting zero-knowledge proof data to nodes. Participating nodes can verify the signature, hash consistency, and the validity of the zero-knowledge proof. Upon reaching the preparation and submission thresholds, a consensus digest is generated and written to a blockchain shard, establishing a correspondence with the transaction identifier to ensure data immutability. This invention, by combining adaptive consensus with zero-knowledge proofs, improves the flexibility, security, and privacy protection of the consensus process, overcoming the shortcomings of traditional fixed consensus mechanisms that struggle to balance efficiency and security.

[0107] In this embodiment, the generation of the version index record specifically includes:

[0108] In the twin shard, a version index chain is established, a version number is set and a parent version number is recorded to organize the sequential relationship between version nodes;

[0109] Collect the current state of the twin shards and generate a snapshot. The snapshot includes a parameter set, a generation timestamp, a shard identifier, and a transaction identifier reference.

[0110] The current snapshot is compared with the previous version snapshot to form a difference result, which includes the changed fields, changed values ​​and time intervals.

[0111] Calculate the hash values ​​for the snapshot and differential results respectively to obtain the snapshot hash value and the differential hash value, and record the corresponding version number and parent version number;

[0112] Write the snapshot hash, differential hash, version number, parent version number, and transaction identifier reference into the blockchain shard to form a version index record;

[0113] In the blockchain system, a one-to-one correspondence is established between the version index record and the consensus digest, and registration is completed.

[0114] This invention establishes a version index chain within a twin shard, where each version includes a sequence number and a parent sequence number, forming a clear version order. It records the data change process by collecting the current state and generating snapshots and differential results. The snapshots and differential results are hashed and written to the blockchain shards, forming version index records and establishing a correspondence with consensus digests, achieving joint notarization of versions and consensus results. Through this mechanism, the system can quickly locate historical versions, accurately compare differences between different versions, and ensure the integrity and consistency of data versions during the tracing process. This invention overcomes the shortcomings of existing technologies, such as decentralized version management and lack of on-chain verification, and realizes a tracing mechanism that combines version updates with on-chain notarization.

[0115] In this embodiment, the generation of the access credential specifically includes:

[0116] In a blockchain system, a strategy graph is constructed. The strategy graph consists of principal nodes and resource nodes, and each edge represents the access path between the principal node and the resource node.

[0117] Configure access rules for each access path. Access rules include allowed operation types, allowed access time ranges, and allowed access node ranges, and assign a unique identifier to each access rule.

[0118] Upon receiving an access request, the access rules are located based on the access path. The operation type, time range, and node range are extracted from the access rules, and the zero-knowledge range proof mechanism is invoked to verify the consistency between the access request parameters and the access rule parameters.

[0119] After the consistency verification is completed, an access credential is generated in the blockchain system. The access credential includes an access path identifier, an access rule identifier, a zero-knowledge scope proof verification result, and a generation time.

[0120] Establish a one-to-one correspondence between the generated access credentials and the version index records, and complete the registration in the blockchain system.

[0121] This invention constructs a strategy graph in a blockchain system, consisting of principal nodes and resource nodes. Access paths are represented by the relationships between nodes, and access rules are configured for each path, including operation type, time range, and access scope. When an access request is received, the system can quickly locate the access rule based on the access path and use zero-knowledge range proofs to verify the consistency of the access request parameters. Upon successful verification, an access credential is generated, containing an access path identifier, a rule identifier, and the verification result, and establishing a correspondence with the version index record. Through this design, this invention achieves refined and reliable access control, solving the shortcomings of traditional traceability systems where access rules are difficult to verify and credentials lack credibility.

[0122] In this embodiment, the generation of the consistency verification record specifically includes:

[0123] A physical timeline is established in the twin shards, and the physical timeline records the physical timestamps of the trace records according to the acquisition order;

[0124] A twin timeline is established in the twin shard, and the twin timeline records the twin timestamps of the trace records according to the calculation order;

[0125] Extract the corresponding physical timestamp and twin timestamp between the physical timeline and the twin timeline, combine the two to form an anchor point, and assign a mapping identifier to the anchor point to generate an anchor point mapping.

[0126] The zero-knowledge scope proof mechanism is invoked to verify the anchor mapping, generating a consistency verification record. The consistency verification record contains the mapping identifier, verification parameters, and verification result.

[0127] Establish a one-to-one correspondence between consistency verification records and access credentials.

[0128] This invention establishes a physical timeline and a twin timeline within a twin-sharded architecture, recording the physical timestamps and simulation timestamps of the traceability records respectively. By combining these two, an anchor point mapping is generated, ensuring an accurate correspondence between events in the physical world and those in the simulation. Each anchor point is verified through a zero-knowledge scope proof mechanism, generating a consistency verification record that records the mapping identifier, verification parameters, and results, and corresponds to access credentials. In this way, the invention guarantees data consistency across the time dimension, preventing time discrepancies or inconsistencies in traceability records. It addresses the lack of verification mechanisms in traditional traceability systems for cross-timeline management, thereby improving the accuracy and reliability of lifecycle traceability.

[0129] In this embodiment, the generation of the traceability report specifically includes:

[0130] In the aggregation unit of the blockchain system, the cross-shard proof aggregation module is called to receive the traceability request, which includes the traceability scope, shard identifier, version information and time interval;

[0131] The target twin shard and blockchain shard are determined based on the shard identifier, and consensus digest, version index record, access credential and consistency verification record are extracted from the blockchain shard.

[0132] Input the consensus digest, version index record, access credential, and consistency verification record into the cross-shard proof aggregation module, and perform aggregation processing to generate an aggregated traceability proof.

[0133] The blockchain system outputs a traceability report, which includes the traceability scope, shard identifier, version information, time interval, and aggregated traceability proof.

[0134] Upon receiving a traceability request, the aggregation unit of the blockchain system invokes the cross-shard proof aggregation module. Based on the shard identifier in the request, it extracts the consensus digest, version index record, access credential, and consistency verification record, and performs aggregation processing to generate an aggregated traceability proof. The traceability report includes the traceability scope, shard identifier, version information, time interval, and aggregated proof, thereby achieving unified verification and result display of cross-shard data. Through this mechanism, the present invention can efficiently aggregate data proofs from different shards in a large-scale distributed environment, solving the shortcomings of low efficiency and difficulty in unified output of cross-shard verification in existing traceability systems, and improving the completeness and credibility of the traceability report.

[0135] A product quality lifecycle traceability system based on digital twins includes:

[0136] The digital twin modeling module is used to build digital twin models covering the design, manufacturing, use, maintenance and recycling stages, divide the twin into segments and establish a correspondence between the twin and the blockchain segments in the blockchain system;

[0137] The traceability record generation module is used to receive model data input in the twin shard, perform time alignment and normalization, generate traceability records, and generate transaction identifiers corresponding to the traceability records in the blockchain shard.

[0138] The consensus processing module is used to configure the adaptive consensus module in the consensus unit, adjust parameters according to the timeliness level and privacy level, execute the Byzantine fault-tolerant consensus algorithm, and call the zero-knowledge scope proof based on PrivChain to verify the transaction identifier, generate a consensus digest and write it to the blockchain shard.

[0139] The version index management module is used to establish a version index chain in the twin shard, generate snapshots and differential results, calculate hash values ​​and write them into the blockchain shard to form version index records, and correspond them with consensus digests;

[0140] The access control module is used to build a policy graph in the blockchain system, configure access rules, and generate access credentials by calling zero-knowledge scope proofs when receiving access requests, and to correspond them with version index records.

[0141] The time consistency verification module is used to establish physical timelines and twin timelines in twin shards, generate anchor mappings and call zero-knowledge scope proofs for verification, form consistency verification records, and correspond them with access credentials;

[0142] The traceability aggregation module is used to call the cross-shard proof aggregation module in the aggregation unit, receive traceability requests, extract consensus digests, version index records, access credentials and consistency verification records, generate aggregate traceability proofs and output traceability reports.

[0143] This invention integrates digital twin modeling, traceability record generation, consensus processing, version index management, access control, time consistency verification, and traceability aggregation into a systematically designed traceability system covering the entire lifecycle. The modules are logically closed-looped through shard correspondence, consensus verification, access credentials, and aggregation proofs, ensuring a complete and verifiable link for data at each stage of generation, storage, verification, aggregation, and report output. This system effectively solves the problems of insufficient lifecycle coverage, inadequate storage mechanisms, insufficient access control reliability, and low efficiency of cross-shard aggregation in traditional traceability schemes, providing a highly efficient, reliable, and scalable technical system for product quality traceability.

[0144] Example 1:

[0145] To verify the feasibility of this invention in practice, it was applied to the quality management scenario of the entire production process of a key component in a manufacturing enterprise. This component generates a large amount of data at each stage of design, manufacturing, use, maintenance, and recycling, including design drawing parameters, manufacturing process parameters, usage and operation parameters, maintenance and inspection records, and recycling and reuse parameters. In traditional traceability methods, this data mainly relies on centralized database storage and manual management, which leads to problems such as difficulty in unifying data modeling between different stages, resulting in interruptions in the traceability chain. At the same time, the data is easily tampered with or lost during storage and transmission, lacks a reliable verification mechanism, and cross-system and cross-shard data query and aggregation are time-consuming, resulting in insufficient traceability efficiency and difficulty in meeting the needs of quality supervision and responsibility determination.

[0146] In this scenario, the present invention first constructs a digital twin model covering the entire life cycle, dividing the data of the design, manufacturing, use, maintenance and recycling stages into twin shards, and establishing a one-to-one correspondence between the blockchain shards and the blockchain system, thereby forming a data mapping that runs through the entire life cycle, so that design data and manufacturing data, and use data and maintenance data can be uniformly modeled through the shard binding relationship, thereby realizing cross-stage data traceability and consistency management.

[0147] In the data acquisition phase, sensors and the production system collect process and testing parameters of components in real time, forming traceability records. After time alignment and amplitude normalization, these records are written to the corresponding twin shards, and transaction identifiers are generated in the blockchain shards, thus binding traceability data with on-chain evidence. In the consensus phase, the consensus unit of the blockchain system is configured with an adaptive consensus module based on PrivChain. This module can dynamically adjust the block interval according to the timeliness level and set the set of fields for zero-knowledge scope proof verification according to the privacy level. For example, the strength parameters of components are only verified within a specified range without revealing the complete value. A consensus digest is formed through the Byzantine fault-tolerant consensus algorithm and written to the blockchain shard, establishing a correspondence with the transaction identifier to ensure the immutability and verifiability of the traceability records.

[0148] In version management, twin shards establish a version index chain. Each state update generates a snapshot, which is compared with the previous snapshot to obtain a difference result. Both the snapshot and the difference result are hashed and written to the blockchain shard to form a version index record, which corresponds to the consensus digest. This enables quick location and verification of data versions, thereby improving the efficiency and accuracy of traceability queries.

[0149] In the access control phase, the blockchain system constructs a strategy graph, where the access path is represented by the relationship between principal nodes and resource nodes. Different user roles, such as production managers, quality inspectors, and supply chain partners, will generate access credentials based on different access paths. The access credentials contain access rule identifiers and zero-knowledge scope proof verification results, and correspond to version index records, thereby achieving refined and trustworthy access control.

[0150] In time consistency verification, twin sharding establishes a physical timeline and a twin timeline. Anchor point mapping is generated by extracting physical timestamps and twin timestamps. Each anchor point is verified through a zero-knowledge scope proof mechanism to generate a consistency verification record, which corresponds to the access credential, thereby ensuring the consistency between physical events and simulated events in the time dimension.

[0151] When a quality traceability request occurs, the aggregation unit of the blockchain system calls the cross-shard proof aggregation module to extract the consensus digest, version index record, access credential and consistency verification record based on the shard identifier in the request. After aggregation processing, an aggregate traceability proof is generated, and a traceability report containing the traceability scope, shard identifier, version information, time interval and aggregate traceability proof is output, so that the traceability result is complete and reliable.

[0152] To further verify the effectiveness, a comparative experiment was conducted between the system of this invention and a traditional centralized database traceability system. The experiment collected indicators such as processing latency, data consistency error rate, report generation time, tamper detection success rate, access control accuracy, and cross-shard aggregation time under the same component production scenario. The comparison results are shown in Table 1.

[0153] Table 1. Performance Comparison Results of Traditional System and Invention System

[0154] index Traditional traceability system This invention system Improvement range Data write latency (ms) 250 80 ↓68% Data consistency error rate 5.7% 0.6% ↓89% Report generation time (s) 15.2 4.3 ↓72% Tamper detection success rate 78% 100% ↑22% Access control accuracy 85% 99% ↑16% Cross-shard aggregation time (s) 12.8 3.9 ↓70%

[0155] The comparative data shows that traditional systems have significant shortcomings in terms of data consistency, access control, and report generation efficiency, while the present invention shows significant advantages in terms of reduced data writing latency, reduced error rate, accelerated aggregation verification, and improved access accuracy, and can better support efficient and reliable traceability throughout the product lifecycle.

[0156] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A product quality lifecycle traceability method based on digital twins, characterized in that, The steps include the following: Construct a digital twin model covering all stages, divide the twin into shards, and establish corresponding relationships with blockchain shards; Collect lifecycle data, create traceability records, write them to the twin shard, and generate transaction identifiers; In the blockchain system, the Byzantine fault-tolerant consensus algorithm is executed using the PrivChain-based adaptive consensus module. During the consensus process, zero-knowledge range proofs are invoked to verify transaction identifiers, and a consensus digest is output, specifically: In the consensus unit of the blockchain system, an adaptive consensus module is configured. The adaptive consensus module receives timeliness level parameters and privacy level parameters, sets message timeout thresholds and block intervals according to the timeliness level, and sets the set of verification fields and range rules for zero-knowledge scope proofs according to the privacy level. The adaptive consensus module generates the execution configuration, which includes the view number, sequence number, round timeout, batch threshold, list of participating nodes and admission rules, and starts the Byzantine fault-tolerant consensus algorithm. Collect transaction identifiers to form a proposal, perform a hash operation on the proposal to obtain the proposal hash value, attach the view number and sequence number, package the proof data and verification parameters of the zero-knowledge scope proof, and broadcast the pre-preparation message to the participating nodes; After receiving the pre-preparation message, participating nodes verify the consistency of the signature, view number, sequence number, proposal hash value, and zero-knowledge scope proof data. When the verification is successful, they record the preparation for voting and enter the preparation phase. During the preparation phase, when the number of prepared votes reaches the preparation threshold, the submission phase begins, and a submission message is broadcast. The submission message includes the proposal hash, the set of node signatures, and the sequence number. When a round times out, the adaptive consensus module performs view maintenance, updates the view number and sequence number, and re-initiates a pre-preparation message for the current proposal; During the submission phase, when the number of submission messages reaches the submission threshold, a consensus result is formed, and a consensus digest is generated. The consensus digest includes the block height, view number, proposal hash value, zero-knowledge scope proof verification result, number of votes, timestamp, and block-producing node identifier, and is written to the blockchain shard. Establish a one-to-one correspondence between consensus summaries and transaction identifiers, and register the one-to-one correspondence in the blockchain system; A version index chain is established in the twin shard, a snapshot and differential results are generated, written to the blockchain shard to form a version index record, and associated with the consensus digest; In a blockchain system, a policy graph access control is constructed, access credentials are generated based on the access path, and associated with the version index record. In the twin sharding, a physical timeline and a twin timeline are established, an anchor mapping is generated, a consistency verification record based on zero-knowledge scope proof is formed, and it is associated with access credentials; When a traceability request is received, the cross-shard proof aggregation module is invoked to aggregate consensus digests, version index records, access credentials, and consistency verification records, generate aggregated traceability proofs, and output traceability reports.

2. The product quality lifecycle traceability method based on digital twins according to claim 1, characterized in that, The blockchain system includes a registration unit for registering the correspondence between twin shards and blockchain shards, a consensus unit for processing transaction identifiers and completing Byzantine fault-tolerant consensus algorithm and zero-knowledge scope proof verification, a storage unit for receiving and storing version index records, access credentials and consistency verification records, and an aggregation unit for aggregating consensus digests, version index records, access credentials and consistency verification records to generate aggregated traceability proofs and output traceability reports upon traceability request.

3. The product quality lifecycle traceability method based on digital twins according to claim 1, characterized in that, The specific division of the twin fragments includes: Model the data from the design, manufacturing, use, maintenance and recycling phases to form a set of digital twin models covering each phase; The digital twin model is divided into twin segments according to the stage, and each twin segment contains parameters and records related to the stage; Establish a twin shard identifier for each twin shard and establish a corresponding blockchain shard identifier in the blockchain system; Register the correspondence between twin shard identifiers and blockchain shard identifiers in the blockchain system.

4. The product quality lifecycle traceability method based on digital twins according to claim 1, characterized in that, The generation of the transaction identifier specifically includes: The twin segment receives data input from the digital twin model, including structural parameters, process parameters, operating parameters, and detection parameters; The data input is processed for time alignment and amplitude normalization to unify the data format and precision, forming standardized traceability records. Write standardized traceability records to the target twin shard, and record the writing time and shard identifier; In blockchain sharding, transaction identifiers are generated based on traceability records. A one-to-one correspondence is established between transaction identifiers and traceability records, and registration is completed in the blockchain system.

5. The product quality lifecycle traceability method based on digital twins according to claim 1, characterized in that, The generation of the version index record specifically includes: In the twin shard, a version index chain is established, a version number is set and a parent version number is recorded to organize the sequential relationship between version nodes; Collect the current state of the twin shards and generate a snapshot. The snapshot includes a parameter set, a generation timestamp, a shard identifier, and a transaction identifier reference. The current snapshot is compared with the previous version snapshot to form a difference result, which includes the changed fields, changed values, and time intervals. Calculate the hash values ​​for the snapshot and differential results respectively to obtain the snapshot hash value and the differential hash value, and record the corresponding version number and parent version number; The snapshot hash value, differential hash value, version number, parent version number, and transaction identifier reference are written into the blockchain shard to form a version index record; In the blockchain system, a one-to-one correspondence is established between the version index record and the consensus digest, and registration is completed.

6. The product quality lifecycle traceability method based on digital twins according to claim 1, characterized in that, The generation of the access credentials specifically includes: In a blockchain system, a strategy graph is constructed. The strategy graph consists of principal nodes and resource nodes, and each edge represents the access path between the principal node and the resource node. Configure access rules for each access path. Access rules include allowed operation types, allowed access time ranges, and allowed access node ranges, and assign a unique identifier to each access rule. Upon receiving an access request, the access rules are located based on the access path. The operation type, time range, and node range are extracted from the access rules, and the zero-knowledge range proof mechanism is invoked to verify the consistency between the access request parameters and the access rule parameters. After the consistency verification is completed, an access credential is generated in the blockchain system. The access credential includes an access path identifier, an access rule identifier, a zero-knowledge scope proof verification result, and a generation time. Establish a one-to-one correspondence between the generated access credentials and the version index records, and complete the registration in the blockchain system.

7. The product quality lifecycle traceability method based on digital twins according to claim 1, characterized in that, The generation of the consistency verification record specifically includes: A physical timeline is established in the twin shards, and the physical timeline records the physical timestamps of the trace records according to the acquisition order; A twin timeline is established in the twin shard, and the twin timeline records the twin timestamps of the trace records according to the calculation order; Extract the corresponding physical timestamp and twin timestamp between the physical timeline and the twin timeline, combine the two to form an anchor point, and assign a mapping identifier to the anchor point to generate an anchor point mapping. The zero-knowledge scope proof mechanism is invoked to verify the anchor mapping, generating a consistency verification record. The consistency verification record contains the mapping identifier, verification parameters, and verification result. Establish a one-to-one correspondence between consistency verification records and access credentials.

8. The product quality lifecycle traceability method based on digital twins according to claim 1, characterized in that, The generation of the traceability report specifically includes: In the aggregation unit of the blockchain system, the cross-shard proof aggregation module is called to receive the traceability request, which includes the traceability scope, shard identifier, version information and time interval; The target twin shard and blockchain shard are determined based on the shard identifier, and consensus digest, version index record, access credential and consistency verification record are extracted from the blockchain shard. Input the consensus digest, version index record, access credential, and consistency verification record into the cross-shard proof aggregation module, and perform aggregation processing to generate an aggregated traceability proof. The blockchain system outputs a traceability report, which includes the traceability scope, shard identifier, version information, time interval, and aggregated traceability proof.

9. A product quality lifecycle traceability system based on digital twins, implementing the product quality lifecycle traceability method based on digital twins as described in any one of claims 1 to 8, characterized in that, include: The digital twin modeling module is used to build digital twin models covering the design, manufacturing, use, maintenance and recycling stages, divide the twin into segments and establish a correspondence between the twin and the blockchain segments in the blockchain system; The traceability record generation module is used to receive model data input in the twin shard, perform time alignment and normalization, generate traceability records, and generate transaction identifiers corresponding to the traceability records in the blockchain shard. The consensus processing module is used to configure the adaptive consensus module in the consensus unit, adjust parameters according to the timeliness level and privacy level, execute the Byzantine fault-tolerant consensus algorithm, and call the zero-knowledge scope proof based on PrivChain to verify the transaction identifier, generate a consensus digest and write it to the blockchain shard. The version index management module is used to establish a version index chain in the twin shard, generate snapshots and differential results, calculate hash values ​​and write them into the blockchain shard to form version index records, and correspond them with consensus digests; The access control module is used to build a policy graph in the blockchain system, configure access rules, and generate access credentials by calling zero-knowledge scope proofs when receiving access requests, and to correspond them with version index records. The time consistency verification module is used to establish physical timelines and twin timelines in twin shards, generate anchor mappings and call zero-knowledge scope proofs for verification, form consistency verification records, and correspond them with access credentials; The traceability aggregation module is used to call the cross-shard proof aggregation module in the aggregation unit, receive traceability requests, extract consensus digests, version index records, access credentials and consistency verification records, generate aggregate traceability proofs and output traceability reports.

Images