Chip supply chain credible traceability and data verification method and system based on blockchain

Abstract

The application relates to the technical field of chip supply chain management, and discloses a chip supply chain credible traceability and data checking method and system based on a block chain. The method is applied to a node network of a consortium chain architecture. First, a strong logical constraint graph containing business process and physical parameter time sequence evolution rules is solidified in a smart contract. Then, the on-chain data of a business node is preprocessed and full-link pre-checking is performed. The checking result is processed in stages, and then consensus on-chain or interception operation is performed. Finally, full-link backtracking checking is performed on the on-chain data according to preset conditions, and permission control is implemented. The system corresponds to a smart contract, pre-checking, consensus on-chain, backtracking checking module. The application constructs a full-process closed-loop checking system, suppresses supply chain fraud from the source, improves data checking and supply chain management efficiency, and is suitable for credible traceability and data checking of the whole life cycle of chips.

Description

Technical Field

[0001] This invention relates to the field of chip supply chain management technology, specifically to a blockchain-based method and system for trusted traceability and data verification in the chip supply chain. Background Technology

[0002] Chips are core components of the electronics and information industry. Their supply chain covers the entire lifecycle, from design and wafer manufacturing to packaging and testing, distribution, end-user installation, and end-of-life recycling. Participants include design companies, wafer manufacturers, packaging and testing companies, distributors, end-user application companies, and industry regulatory agencies. The supply chain is characterized by numerous stages, complex data types, and significant challenges in multi-party collaboration. Currently, counterfeit activities such as overproduction, counterfeiting, and refurbishment are rampant in the chip supply chain. These practices not only severely damage the legitimate rights and interests of upstream and downstream companies but also affect the operational reliability of electronic end-user products, adversely impacting the safe and stable development of the chip industry supply chain.

[0003] To address the aforementioned issues, blockchain technology, with its characteristics of immutable data, end-to-end traceability, and node consensus verification, has been widely applied in the field of chip supply chain traceability. This enables the on-chain storage and traceability of business and testing data from each stage of the chip manufacturing process. The core of existing blockchain-based chip supply chain traceability and data verification technologies is to hash the business and testing data generated at each stage of the chip manufacturing process before uploading it to the blockchain, verifying the legitimacy of the data submitting entity through digital signatures, and verifying the integrity of the data itself through hash comparison.

[0004] Such technologies can only ensure that data is not tampered with after it is uploaded to the blockchain, and can only perform single-point verification of the legality of data in a single link. They do not combine the business process logic of the entire chip life cycle with the temporal evolution law of the chip's inherent physical parameters to build a systematic, closed-loop, and strongly constrained verification system. At the same time, the verification process is mostly a post-event verification after the data is uploaded to the blockchain, lacking a pre-interception mechanism before the data is uploaded to the blockchain. It is impossible to identify and intercept deep fraud behavior that is complete in form but has logical contradictions throughout the entire chain from the source, and it is difficult to fundamentally solve the core problem of controlling fraud in the chip supply chain. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a blockchain-based method and system for trusted traceability and data verification in the chip supply chain. This addresses the problem that existing technologies can only verify the integrity and single-point legitimacy of chip supply chain data, but cannot build a strong pre-verification mechanism for the logical and temporal evolution of business processes and physical parameters throughout the chip's entire lifecycle. It also makes it difficult to identify and intercept deep fraudulent behavior that results in data that is complete in form but contradicts the logic throughout the entire chain.

[0006] To address the aforementioned technical problems, this invention provides the following technical solution: a blockchain-based trusted traceability and data verification method for the chip supply chain, applied to a chip supply chain traceability node network with a consortium blockchain architecture. The node network includes business nodes and regulatory nodes corresponding to each stage of the chip's entire lifecycle, and comprises the following steps: Step 1: Pre-define the strong logic constraint map of the entire life cycle of the chip in the smart contract of the consortium blockchain. The constraint map includes business process logic constraint rules and physical parameter temporal evolution constraint rules. Step 2: Receive on-chain data requests initiated by each business node throughout the chip's lifecycle. After preprocessing the requested data, call the strong logic constraint graph to perform full-link pre-verification on the requested data. Step 3: For request data that passes verification, a corresponding verification credential is generated and sent synchronously to the consortium blockchain node along with the request data to complete consensus and on-chain. For request data that fails verification, it is directly intercepted and an interception record is generated and synchronized to the regulatory node. Step 4: Perform full-chain backtracking verification on the chip's full-cycle data that has been uploaded to the blockchain according to preset trigger conditions, and perform corresponding permission control operations based on the backtracking verification results.

[0007] Furthermore, the steps for constructing the business process logic constraint rules include: obtaining the design parameters and contractual parameters corresponding to the chip batch; constructing a strong constraint system for the entire lifecycle quantity of the chip batch based on the parameters; and calculating the absolute quantity limit of a single batch of chips throughout its entire lifecycle using a preset formula. The absolute quantity limit is the insurmountable constraint value for the number of qualified chips at each stage of the entire chip batch process. The preset formula is: The meanings of the parameters in the formula are as follows: This represents the theoretical maximum number of qualified chips per batch. The number of wafers produced per batch as stipulated in the contract. This refers to the standard number of bare wafers per single wafer. To determine the chip design yield threshold, the absolute quantity limit is uniquely bound to the corresponding chip batch and embedded into a smart contract.

[0008] Furthermore, the business process logic constraint rules cover the entire chip lifecycle, including the design tape-out stage, wafer CP testing stage, packaging and testing FT testing stage, factory distribution stage, terminal installation stage, and scrap recycling stage. The constraint rules corresponding to each stage form a closed loop relationship with the constraint rules of all upstream stages. The design tape-out stage constraint rules solidify the core design parameters and contractually agreed parameters corresponding to the chip batch. The wafer CP testing stage constraint rules limit the number of qualified bare dies in a batch to no more than the absolute quantity limit. The packaging and testing FT testing stage constraint rules limit the test parameters of a single chip to be within the preset process deviation range from the corresponding CP test parameters. The factory distribution stage constraint rules limit the cumulative number of batches shipped to no more than the total number of qualified packaging and testing FT tests. The terminal installation stage constraint rules lock the circulation permissions after the chip's completion status is confirmed. The scrap recycling stage constraint rules permanently lock all operation permissions after the chip's destruction is confirmed.

[0009] Furthermore, the construction steps of the physical parameter timing evolution constraint rules include: during the wafer CP testing phase, collecting the inherent physical parameters of each chip, including threshold voltage, on-resistance, gate leakage current, saturation current, and turn-on voltage; generating a unique, non-cloning physical fingerprint benchmark value for the corresponding chip based on the inherent physical parameters; binding the physical fingerprint benchmark value with the unique identity of the corresponding chip and embedding it into the consortium blockchain smart contract; and constructing a chip physical parameter timing evolution model based on chip manufacturing process, material characteristics, application scenarios, and semiconductor reliability engineering standards. The model clarifies the normal drift range and change trend requirements of the physical parameters at different usage stages throughout the chip's life cycle and embedding the model into the smart contract.

[0010] Furthermore, the verification logic of the physical parameter temporal evolution constraint rules includes: when a data request to be uploaded to the chain is initiated at any stage of the chip's entire life cycle, the corresponding current physical parameters of the chip are collected synchronously, the current physical parameters are compared with the physical fingerprint benchmark value fixed on the chain, and the deviation between the current physical parameters and the benchmark value is verified to be within the normal drift range of the corresponding usage stage; the change trend of the current physical parameters relative to the benchmark value is verified to meet the requirements of the physical parameter temporal evolution model, the parameter data that passes the verification enters the subsequent pre-verification process, and the parameter data that fails the verification directly triggers the interception operation.

[0011] Furthermore, the end-to-end pre-verification is performed by a verification engine deployed in the trusted pre-gateway of each business node. The verification engine adopts an architecture of off-chain computation plus on-chain verification, and is connected to the production management system, warehouse management system, and testing machine system of the corresponding business nodes in the chip supply chain through standardized interfaces to automatically collect on-chain data from the corresponding links. The preprocessing steps include verifying the format compliance of the request data, the legality of the digital signature of the sending node, and the integrity of the request data. Request data that fails the preprocessing is directly intercepted and does not enter the subsequent end-to-end verification process.

[0012] Furthermore, after the end-to-end pre-verification is completed, a graded judgment operation is performed, which includes three levels: Level 1 pass, Level 2 warning, and Level 3 interception. The first-level verification process confirms that all requirements are met by checking all corresponding constraint rules. The verification engine generates a verification credential for the requested data, which includes the data hash value, verification timestamp, and engine digital signature, and sends it synchronously to the consortium blockchain node. When a Level 2 warning occurs, it corresponds to a non-core constraint rule exceeding a preset threshold. The verification engine generates a warning message and pushes it to the corresponding business node and regulatory node. After receiving supplementary confirmation information submitted by the corresponding responsible node, it completes the subsequent process. If the core constraint rule verification fails to meet the requirements of Level 3 interception, the verification engine will directly terminate the process of uploading the requested data to the chain and generate an interception record to be synchronized to all consensus nodes and regulatory nodes.

[0013] Furthermore, the preset triggering conditions for the end-to-end backtracking verification include three categories: fixed periodic triggering, state change triggering, and manual triggering. Fixed-cycle triggering involves performing full-link backtracking verification on all chip batches in circulation and use at preset time intervals; When a status change is triggered by a chip ownership transfer, installation confirmation, or scrapping application, a full-link backtracking verification is performed on the corresponding chip's entire lifecycle data. Manually initiated triggers allow regulatory nodes or chip design nodes to initiate end-to-end backtracking verification of a specified chip batch or a specified chip. The end-to-end backtracking verification is based on a strong logic constraint graph solidified on the chain. It performs full logic verification on all on-chain data of the target chip or batch to verify the logical consistency of the data and the temporal consistency of the evolution of physical parameters.

[0014] Furthermore, once the constraint rules corresponding to the strong logic constraint map of the entire chip lifecycle are solidified into the smart contract, the content of the rules cannot be tampered with. The update operation of the constraint rules must be executed after multi-signature authorization by three core nodes: chip design node, wafer manufacturing node, and regulatory node. The updated constraint rules are only effective for the chip batches added after the update. Chip batches that have been on the chain before the update will continue to use the original constraint rules before the update to perform all verification operations. The entire process of rule update is recorded synchronously on the chain and solidified.

[0015] A blockchain-based trusted traceability and data verification system for the chip supply chain includes a smart contract module, a pre-verification module, a consensus on-chain module, and a backtracking verification module. The smart contract module is used to pre-solidify a strong logic constraint graph of the entire life cycle of the chip in the consortium blockchain. The constraint graph includes business process logic constraint rules and physical parameter temporal evolution constraint rules. The pre-verification module is used to receive on-chain data requests initiated by each business node throughout the chip's lifecycle. After preprocessing the request data, it calls the strong logic constraint graph to perform full-link pre-verification on the request data. The consensus on-chain module is used to generate corresponding verification credentials for the request data that passes the verification, and send them to the consortium blockchain node synchronously with the request data to complete the consensus on-chain. For the request data that fails the verification, it directly intercepts the request data and generates an interception record that is synchronized to the supervisory node. The backtracking verification module is used to perform full-chain backtracking verification on the chip's full-cycle data according to preset trigger conditions, and to perform corresponding permission control operations based on the backtracking verification results.

[0016] Compared with existing technologies, this blockchain-based method and system for trusted traceability and data verification in the chip supply chain has the following advantages: I. This invention solidifies a strong logical constraint graph of the entire chip lifecycle in a consortium blockchain smart contract, constructing a closed-loop verification system that includes pre-chain verification before onboarding and post-chain backtracking verification. This overcomes the limitations of existing technologies that can only verify the legality and integrity of single-point data. It sets systematic and strong constraint verification rules for the logical and temporal evolution of chip business processes and physical parameters, and establishes a pre-chain interception mechanism. This can identify and intercept deep fraudulent behavior where the data is in a complete form but the logic throughout the entire chain is contradictory. This fundamentally solves the core problem of controlling fraud in the chip supply chain, effectively ensuring the credibility of chip supply chain data and protecting the legitimate rights and interests of upstream and downstream enterprises in the chip supply chain.

[0017] Second, this invention adopts a verification architecture that combines off-chain computation with on-chain verification, along with a hierarchical judgment and dynamic permission control mechanism. While completing the full-chain data verification of the chip supply chain, it can significantly reduce the overall computational load of the consortium blockchain, improve the efficiency of data collection and verification, and implement refined control over chip circulation and operation permissions based on the data verification results. The update of constraint rules requires multi-signature authorization from core nodes and is recorded on the blockchain throughout the process, ensuring the authority and stability of the verification basis. This enables full-process controllability of chip supply chain traceability management and improves the refinement and intelligence level of chip supply chain management.

[0018] Other advantages, objectives and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination or study, or may be learned from the practice of the invention. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0020] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a system architecture diagram of the present invention. Detailed Implementation

[0021] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided below.

[0022] like Figure 1 and Figure 2As shown, a blockchain-based trusted traceability and data verification method for the chip supply chain is applied to a chip supply chain traceability node network with a consortium blockchain architecture. This node network deploys business nodes and regulatory nodes corresponding to each stage of the chip's entire lifecycle. Specifically, business nodes include chip design nodes, wafer manufacturing nodes, packaging and testing nodes, distribution nodes, terminal installation nodes, and end-of-life recycling nodes. Regulatory nodes are consortium blockchain nodes corresponding to chip supply chain industry regulatory agencies and market regulatory agencies. Each node is equipped with a trusted front-end gateway and a digital signature authentication module. The national cryptographic algorithm SM2 is used to complete node identity authentication, ensuring the uniqueness of node identity and the legality of operations. The consortium blockchain uses a practical Byzantine fault-tolerant consensus algorithm to complete data on-chain consensus, and the hash algorithm uses SHA256 to generate data digests. Nodes interact with each other through an encrypted transmission protocol, ensuring the security of data transmission.

[0023] This embodiment of the blockchain-based chip supply chain trusted traceability and data verification method, at its core, solidifies a strong logical constraint graph of the entire chip lifecycle in a consortium blockchain smart contract. This enables full-link pre-verification before chip data is uploaded to the blockchain and full-link backtracking verification after data upload, forming a closed-loop verification system for the entire chip supply chain data process. The specific implementation steps are as follows: Step 1: Solidify the strong logic constraint graph of the entire chip lifecycle in the consortium blockchain smart contract This step forms the basis for chip supply chain data verification. The smart contract module is developed using the Solidity language and deployed on the consensus node of the consortium blockchain to solidify and store the strong logical constraint graph of the entire chip lifecycle. This constraint graph includes business process logic constraint rules and physical parameter temporal evolution constraint rules. Both types of rules are bound to the unique identification of the chip batch and the unique identification of the individual chip. After the rule content is written into the smart contract, it is solidified on the blockchain, providing a basis for judgment for subsequent full-chain verification.

[0024] Specifically, the business process logic constraint rules are constructed on a batch-by-batch basis. First, the chip design node and wafer manufacturing node collaborate to obtain the design parameters and contractually agreed parameters corresponding to the chip batch. Based on these parameters, a strong constraint system for the entire lifecycle quantity of the chip batch is constructed. The absolute quantity limit for a single batch of chips throughout its entire lifecycle is calculated using a preset formula. This absolute quantity limit is the insurmountable constraint value for the number of qualified chips at each stage of the entire chip batch process. The preset calculation formula is:

[0025] In the formula, This represents the theoretical maximum number of qualified chips in a single batch, i.e., the absolute upper limit of the total number of chips in a single batch throughout its entire lifecycle. The number of wafers to be fabricated in a single batch is a core parameter determined by the contract between the chip design node and the wafer manufacturing node during the tape-out stage, and is determined based on the chip design specifications and wafer manufacturing capacity. The standard number of bare dies per wafer is determined by the wafer size, chip design layout size, and wafer dicing process parameters, and is a basic process parameter in the wafer manufacturing process. This is the chip design yield threshold, determined by the chip design node based on chip manufacturing process, circuit design complexity, and industry benchmarks for similar chip designs. It is a core performance parameter in the chip design stage.

[0026] Calculated The chip is bound to a unique identifier for its corresponding chip batch and simultaneously embedded into the consortium blockchain smart contract. Based on this, business process logic constraints covering all stages of the chip's entire lifecycle are constructed. These constraints at each stage form a closed loop with the constraints at all upstream stages. Specifically, the embedded content of the constraints at each stage is as follows: In the design and tape-out stage, the core design parameters, contractual parameters, and calculated parameters corresponding to the chip batch are used... The data is embedded into a smart contract, serving as the basis for verification in all subsequent stages of this batch of chips; during the wafer CP testing stage, the number of qualified bare dies in this batch is limited to no more than [number missing]. Furthermore, the sum of the number of qualified dies and the number of unqualified dies cannot exceed the total number of dies actually produced in the wafer fabrication process, forming a closed-loop constraint at the quantity level. In the packaging and testing (FT) stage, the FT test parameters of a single chip are limited to be within a preset process deviation range from the corresponding CP test parameters. This process deviation range is determined by the packaging and testing node according to the chip packaging and testing process standards. At the same time, the number of FT-qualified chips in this batch is limited to not exceeding the number of qualified dies in the wafer CP test stage. In the factory distribution stage, the cumulative number of chips shipped in this batch is limited to not exceeding the total number of FT-qualified chips in the packaging and testing stage, and the number of chips shipped in a single batch must match the warehouse data of the distribution node. In the terminal installation stage, the chip's circulation permission is locked after the installation status is confirmed, and the chip's unique identification is bound to the terminal product's unique identification, preventing further operations in the distribution stage. In the scrapping and recycling stage, all operation permissions are permanently locked after the chip's destruction is confirmed, and the chip's unique identification is marked as scrapped, no longer participating in any verification or circulation process.

[0027] Specifically, the construction of physical parameter timing evolution constraint rules is based on a single chip. The core is to construct a unique physical fingerprint based on the chip's inherent physical parameters, and then combine this with semiconductor reliability engineering standards to build a physical parameter timing evolution model. During the wafer CP testing phase, the test equipment system at the wafer manufacturing node automatically collects the inherent physical parameters of each chip. These inherent physical parameters include threshold voltage, on-resistance, gate leakage current, saturation current, and turn-on voltage. These parameters are the chip's intrinsic electrical parameters and are unique and cannot be cloned.

[0028] The inherent physical parameters of each collected chip are normalized to generate a unique, unclonable physical fingerprint baseline value. This physical fingerprint baseline value is then bound to the chip's unique identifier and simultaneously embedded into the consortium blockchain smart contract. Based on this, the chip design node, considering chip manufacturing processes, material properties, and application scenarios, constructs a time-series evolution model of the chip's physical parameters according to semiconductor reliability engineering standards. This model clarifies the normal drift range and trend requirements of physical parameters at different stages of the chip's lifecycle. The chip usage stages are divided into the factory distribution stage, initial terminal use stage, mid-term terminal use stage, late terminal use stage, and pre-recycling testing stage. Each stage has corresponding normal drift range and trend thresholds for physical parameters. This model is also embedded into the consortium blockchain smart contract, providing a basis for subsequent time-series verification of physical parameters.

[0029] Step 2: Receive on-chain data requests and perform end-to-end pre-verification. After each business node completes its corresponding business operations throughout the chip's lifecycle, the corresponding production management system, warehouse management system, and testing machine system automatically collect business data, test data, and flow data, and initiate on-chain data requests to the consortium blockchain. These requests are received by the trusted front-end gateway configured by each business node. The front-end verification module is deployed in the trusted front-end gateway and serves as the main body for executing the full-link front-end verification. It adopts an architecture of off-chain computation plus on-chain verification, completing data preprocessing and full-link verification computation off-chain to reduce the computational load on the consortium blockchain. Only the verification results and compliance data are synchronized to the blockchain to complete the verification.

[0030] The pre-verification module interfaces with the production management system, warehouse management system, and testing equipment system of the corresponding business nodes in the chip supply chain via standardized interfaces such as OPCUA and MQTT. This enables automatic collection and synchronization of on-chain data without manual intervention, improving the efficiency and accuracy of data collection. Upon receiving an on-chain data request, the module first performs preprocessing operations on the requested data. The preprocessing criteria include the format compliance of the requested data, the legality of the digital signature of the sending node, and the integrity of the requested data. The format compliance is determined according to the pre-set data on-chain format standard of the consortium blockchain, verifying the data fields, data types, and data units. The legality of the digital signature of the sending node is verified using the national cryptographic SM2 algorithm to confirm that the data sending node is a legitimate node authorized by the consortium blockchain. The integrity of the requested data is confirmed by calculating the data hash value and comparing it with the hash value submitted by the data sending node, confirming that the data has not been tampered with during transmission.

[0031] Request data that fails preprocessing is directly intercepted by the pre-verification module, bypassing the subsequent full-link verification process, and a preprocessing failure record is generated and synchronized to the corresponding business node. Request data that passes preprocessing is then subjected to full-link pre-verification by the pre-verification module, which invokes the strong logical constraint graph embedded in the consortium blockchain smart contract. This verification process covers both business process logic constraints and physical parameter temporal evolution constraints: for business process logic constraints, it verifies whether the quantity and process parameters in the request data meet the constraints of each stage and form a logical closed loop with the data already on-chain from upstream stages; for physical parameter temporal evolution constraints, it synchronously collects the current physical parameters of the corresponding chip, compares them with the physical fingerprint benchmark value embedded on-chain, verifies that the deviation between the current physical parameter and the benchmark value is within the normal drift range of the corresponding usage stage, and verifies that the trend of the current physical parameter relative to the benchmark value conforms to the requirements of the physical parameter temporal evolution model. Request data that fails physical parameter verification is directly intercepted and does not proceed to the next stage.

[0032] Step 3: Perform on-chain or interception operations based on the pre-verification results. After the end-to-end pre-verification is completed, the pre-verification module performs a tiered judgment operation on the verification results. The tiered judgment results include three levels: Level 1 pass, Level 2 warning, and Level 3 interception. Each level corresponds to a different processing procedure. The consensus on-chain module performs subsequent on-chain or interception operations based on the tiered judgment results. Level 1 passed, meaning all constraint rules for the requested data met the requirements without any deviations or anomalies. The pre-verification module generates a verification certificate for the requested data, which includes the data hash value, verification timestamp, and digital signature from the pre-verification module. The consensus on-chain module synchronously sends the requested data and verification certificate to all nodes of the consortium blockchain. The consortium blockchain uses a practical Byzantine fault-tolerant consensus algorithm to achieve node consensus. After consensus is passed, the data is uploaded to the blockchain for notarization. The uploaded data is bound to the unique identifier of the chip batch and individual chip, enabling data traceability and association. Level 2 warning occurs when the non-core constraint rules of the requested data exceed the preset threshold, while the core constraint rules all meet the requirements. The pre-verification module generates warning information, which includes deviation parameters, deviation range, and corresponding constraint rules. This information is pushed to the corresponding business node and regulatory node via the consortium blockchain message push mechanism. After the corresponding business node submits supplementary confirmation information and the regulatory node reviews and approves it, the pre-verification module re-completes the verification. Once the verification is successful, the data is uploaded to the blockchain according to the Level 1 approval process. The supplementary confirmation information and review information are uploaded to the blockchain for evidence storage along with the original requested data. Level 3 interception occurs when the core constraint rules of the requested data fail to meet requirements, or when there are logical contradictions throughout the entire chain or serious anomalies in physical parameters. The pre-verification module directly terminates the on-chain process of the requested data, and the consensus on-chain module generates an interception record. The interception record includes the content of the requested data, the basis for the verification failure, and the interception time. This record is synchronized to all consensus nodes and supervisory nodes of the consortium blockchain. Supervisory nodes can initiate verification operations on the corresponding business nodes based on the interception record.

[0033] Step 4: Perform end-to-end backtracking verification and implement access control. The backtracking verification module is deployed on the regulatory nodes and core business nodes of the consortium blockchain. For the full lifecycle data of the chip that has been uploaded to the chain, it automatically performs full-link backtracking verification according to preset trigger conditions. The core of the full-link backtracking verification is to perform full logical verification on the on-chain data of the target chip or chip batch based on the strong logical constraint graph solidified on the chain. This verifies the logical consistency of the data in all stages and the temporal consistency of the evolution of physical parameters, ensuring that the chip supply chain data is tamper-free and logically consistent throughout its entire lifecycle.

[0034] Specifically, the preset triggering conditions for end-to-end backtracking verification include three categories: fixed-period triggering, state change triggering, and manual triggering. The execution logic for each type of triggering condition is as follows: Triggered by a fixed period, the backtracking verification module performs full-chain backtracking verification on all chip batches in circulation and use at preset time intervals. The time interval can be configured by the regulatory node according to the regulatory needs of the chip supply chain. Shorter verification cycles can be configured for high-value, high-precision chip batches, and longer verification cycles can be configured for general chip batches. When a chip undergoes a status change, such as ownership transfer, installation confirmation, or scrapping application, the corresponding business node initiates a request to upload the status change data to the blockchain. At the same time, it triggers the backtracking verification module to perform full-link backtracking verification on the chip's entire lifecycle data to ensure that there are no anomalies in the chip data before the status change. Manually initiated, regulatory nodes or chip design nodes can initiate full-link backtracking verification of a specified chip batch or a specified chip based on regulatory requirements and business verification requirements. After receiving the initiation instruction, the backtracking verification module immediately performs full-link backtracking verification on the target object.

[0035] After the backtracking verification module completes the full-link backtracking verification, it performs corresponding permission control operations based on the verification results: If the verification result shows no abnormalities in the data across all stages, the chip's original flow and operation permissions remain unchanged; if the verification result shows non-core data deviations, it pushes warning information to the corresponding business nodes and regulatory nodes, temporarily restricting the chip's flow permissions, and lifts the flow permission restrictions after the business nodes complete data correction and review; if the verification result shows core data contradictions, data tampering, or serious physical parameter anomalies, it immediately freezes all flow and operation permissions of the chip, marks it as an abnormal chip, and generates an anomaly verification report that is synchronized to the regulatory node. The regulatory node organizes relevant business nodes to complete the verification, and only after the verification is completed and confirmed to be problem-free can the regulatory node authorize the lifting of the permission freeze.

[0036] In this embodiment, the constraint rules corresponding to the strong logic constraint graph of the chip's entire lifecycle are solidified into a smart contract. The rules cannot be tampered with, ensuring the authority and stability of the verification basis. If the constraint rules need to be updated due to chip manufacturing process upgrades, supply chain business process optimizations, or regulatory standard updates, the update operation must be executed only after multi-signature authorization from three core nodes: chip design node, wafer manufacturing node, and regulatory node. Multi-signature authorization uses the national cryptographic SM2 algorithm for signature confirmation. The rule update process can only be initiated after all three core nodes have completed their signatures. The updated constraint rules only apply to newly added chip batches after the update. Chip batches already on the blockchain before the update will continue to use the original constraint rules for all verification operations. The entire process, including the rule update initiation time, update content, signatures of each core node, and update effective time, is synchronously recorded and solidified on the blockchain, achieving traceability of the rule update process.

[0037] This embodiment also discloses a blockchain-based trusted traceability and data verification system for the chip supply chain, applicable to the aforementioned blockchain-based trusted traceability and data verification method for the chip supply chain. The system consists of a smart contract module, a pre-verification module, a consensus on-chain module, and a backtracking verification module. Each module is deployed independently and completes data interaction through a consortium blockchain encrypted interface, forming a collaborative closed-loop system. The hardware deployment, functional implementation, and working mechanism of each module are as follows: Smart contract module The smart contract module is deployed on all consensus nodes of the consortium blockchain and developed using the Solidity language. It serves as the system's core rule storage module, with its core function being to pre-define a strong logical constraint graph of the entire chip lifecycle within the consortium blockchain. This constraint graph includes business process logic constraints and physical parameter temporal evolution constraints. Simultaneously, the smart contract module provides interfaces for rule querying, rule binding, and rule updating, offering rule invocation support to the pre-verification and backtracking verification modules. It performs multi-signature authorization verification on rule update operations to ensure the legality of rule updates and records the entire rule update process on the blockchain for permanent preservation.

[0038] Pre-verification module The pre-verification module is deployed in the trusted pre-gateway of each business node and regulatory node. As the system's pre-verification execution module, its core function is to receive on-chain data requests initiated by each business node throughout the chip's lifecycle, preprocess the requested data, and then invoke the strong logical constraint graph embedded in the smart contract module to perform end-to-end pre-verification of the requested data. This module has a built-in verification engine and standardized interfaces, enabling automatic integration and data collection with the business systems of each business node. It also performs hierarchical judgment of verification results, providing a basis for judgment for the consensus on-chain module.

[0039] Consensus on-chain module The consensus-on-chain module is deployed on all nodes of the consortium blockchain. It serves as the system's data upload and interception execution module. Its core function is to generate corresponding verification credentials for verified request data, which are then sent synchronously to the consortium blockchain nodes to complete the consensus-on-chain process. For request data that fails verification, it directly intercepts the data and generates an interception record, which is then synchronized to the monitoring node. This module integrates a practical Byzantine fault-tolerant consensus algorithm and a hash encryption algorithm to achieve consensus and notarization of data upload, while simultaneously generating various operation records to ensure the traceability of the data upload and interception process.

[0040] Backtracking verification module The backtracking verification module is primarily deployed on the regulatory nodes and core business nodes of the consortium blockchain, such as chip design and wafer manufacturing. It serves as the system's subsequent verification and access control module. Its core function is to perform full-chain backtracking verification on all chip lifecycle data already on the blockchain according to preset trigger conditions, and to execute corresponding access control operations based on the backtracking verification results. This module can be configured with backtracking verification trigger conditions and verification scope, automatically completes full logical verification and generates verification reports, and simultaneously connects to the consortium blockchain's node access control system to achieve real-time control over chip circulation and operation permissions.

[0041] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A blockchain-based method for trusted traceability and data verification in the chip supply chain, applied to a chip supply chain traceability node network with a consortium blockchain architecture, wherein the node network includes business nodes and regulatory nodes corresponding to each stage of the chip's entire lifecycle, characterized in that... Includes the following steps: Step 1: Pre-define the strong logic constraint map of the entire life cycle of the chip in the smart contract of the consortium blockchain. The constraint map includes business process logic constraint rules and physical parameter temporal evolution constraint rules. Step 2: Receive on-chain data requests initiated by each business node throughout the chip's lifecycle. After preprocessing the requested data, call the strong logic constraint graph to perform full-link pre-verification on the requested data. Step 3: For request data that passes verification, a corresponding verification credential is generated and sent synchronously to the consortium blockchain node along with the request data to complete consensus and on-chain. For request data that fails verification, it is directly intercepted and an interception record is generated and synchronized to the regulatory node. Step 4: Perform full-chain backtracking verification on the chip's full-cycle data that has been uploaded to the blockchain according to preset trigger conditions, and perform corresponding permission control operations based on the backtracking verification results.

2. The blockchain-based trusted traceability and data verification method for the chip supply chain according to claim 1, characterized in that, The steps for constructing the business process logic constraint rules include: obtaining the design parameters and contractual parameters corresponding to the chip batch; constructing a strong constraint system for the quantity of chips throughout the entire lifecycle of the chip batch based on the parameters; and calculating the absolute quantity limit of a single batch of chips throughout its entire lifecycle using a preset formula. The absolute quantity limit is the insurmountable constraint value for the number of qualified chips at each stage of the chip batch's entire process. The preset formula is: The meanings of the parameters in the formula are as follows: This represents the theoretical maximum number of qualified chips per batch. The number of wafers produced per batch as stipulated in the contract. This refers to the standard number of bare wafers per single wafer. To determine the chip design yield threshold, the absolute quantity limit is uniquely bound to the corresponding chip batch and embedded into a smart contract.

3. The blockchain-based trusted traceability and data verification method for the chip supply chain according to claim 2, characterized in that, The business process logic constraint rules cover the entire chip lifecycle, including the design and tape-out stage, wafer CP testing stage, packaging and testing FT testing stage, factory distribution stage, terminal installation stage, and scrap recycling stage. The constraint rules corresponding to each stage form a closed loop relationship with the constraint rules of all upstream stages. The constraint rules of the design and tape-out stage solidify the core design parameters and contractual parameters corresponding to the chip batch. The constraint rules of the wafer CP testing stage limit the number of qualified bare dies in the batch to not exceed the absolute quantity limit. The constraint rules of the packaging and testing FT testing stage limit the test parameters of a single chip to be within the preset process deviation range from the corresponding CP test parameters. The constraint rules of the factory distribution stage limit the cumulative number of batches shipped to not exceed the total number of qualified packaging and testing FT tests. The constraint rules of the terminal installation stage limit the transfer permissions to be locked after the chip completion status is confirmed. The constraint rules of the scrap recycling stage limit all operation permissions to be permanently locked after the chip completion destruction confirmation.

4. The blockchain-based trusted traceability and data verification method for the chip supply chain according to claim 1, characterized in that, The steps for constructing the physical parameter time-series evolution constraint rules include: during the wafer CP testing phase, collecting the inherent physical parameters of each chip, including threshold voltage, on-resistance, gate leakage current, saturation current, and turn-on voltage; generating a unique, non-clonable physical fingerprint benchmark value for each chip based on the inherent physical parameters; binding the physical fingerprint benchmark value with the unique identifier of the corresponding chip and embedding it into the consortium blockchain smart contract; and constructing a chip physical parameter time-series evolution model based on chip manufacturing process, material characteristics, application scenarios, and semiconductor reliability engineering standards. The model clarifies the normal drift range and change trend requirements of physical parameters at different usage stages throughout the chip's lifecycle and embeds the model into the smart contract.

5. The blockchain-based trusted traceability and data verification method for the chip supply chain according to claim 4, characterized in that, The verification logic of the physical parameter temporal evolution constraint rules includes: when a data request to be uploaded to the chain is initiated at any stage of the chip's entire life cycle, the current physical parameters of the corresponding chip are collected synchronously, and the current physical parameters are compared with the physical fingerprint benchmark value fixed on the chain to verify that the deviation between the current physical parameters and the benchmark value is within the normal drift range of the corresponding usage stage; verify that the change trend of the current physical parameters relative to the benchmark value meets the requirements of the physical parameter temporal evolution model, and the parameter data that passes the verification enters the subsequent pre-verification process, while the parameter data that fails the verification directly triggers the interception operation.

6. The blockchain-based trusted traceability and data verification method for the chip supply chain according to claim 1, characterized in that, The end-to-end pre-verification is performed by a verification engine deployed in the trusted pre-gateway of each business node. The verification engine adopts an architecture of off-chain computation plus on-chain verification and connects with the production management system, warehouse management system and testing machine system of the corresponding business nodes in the chip supply chain through standardized interfaces to automatically collect on-chain data of the corresponding links. The preprocessing steps include verifying the format compliance of the request data, the legality of the digital signature of the sending node, and the integrity of the request data. Request data that fails the preprocessing is directly intercepted and does not enter the subsequent end-to-end verification process.

7. The blockchain-based trusted traceability and data verification method for the chip supply chain according to claim 1, characterized in that, After the end-to-end pre-verification is completed, a graded judgment operation is performed, which includes three levels: Level 1 pass, Level 2 warning, and Level 3 interception. The first-level verification process confirms that all requirements are met by checking all corresponding constraint rules. The verification engine generates a verification credential for the requested data, which includes the data hash value, verification timestamp, and engine digital signature, and sends it synchronously to the consortium blockchain node. When a Level 2 warning occurs, it corresponds to a non-core constraint rule exceeding a preset threshold. The verification engine generates a warning message and pushes it to the corresponding business node and regulatory node. After receiving supplementary confirmation information submitted by the corresponding responsible node, it completes the subsequent process. If the core constraint rule verification fails to meet the requirements of Level 3 interception, the verification engine will directly terminate the process of uploading the requested data to the chain and generate an interception record to be synchronized to all consensus nodes and regulatory nodes.

8. The blockchain-based trusted traceability and data verification method for the chip supply chain according to claim 1, characterized in that, The preset triggering conditions for the end-to-end backtracking verification include three categories: fixed periodic triggering, state change triggering, and manual triggering. Fixed-cycle triggering involves performing full-link backtracking verification on all chip batches in circulation and use at preset time intervals; When a status change is triggered by a chip ownership transfer, installation confirmation, or scrapping application, a full-link backtracking verification is performed on the corresponding chip's entire lifecycle data. Manually initiated triggers allow regulatory nodes or chip design nodes to initiate end-to-end backtracking verification of a specified chip batch or a specified chip. The end-to-end backtracking verification is based on a strong logic constraint graph solidified on the chain. It performs full logic verification on all on-chain data of the target chip or batch to verify the logical consistency of the data and the temporal consistency of the evolution of physical parameters.

9. A blockchain-based method for trusted traceability and data verification in the chip supply chain, as described in claim 1, is characterized in that... Once the constraint rules corresponding to the strong logic constraint graph of the entire chip lifecycle are solidified into the smart contract, the content of the rules cannot be tampered with. The update operation of the constraint rules must be executed after multi-signature authorization by three core nodes: chip design node, wafer manufacturing node, and regulatory node. The updated constraint rules are only effective for the chip batches added after the update. Chip batches that have been on the chain before the update will continue to use the original constraint rules before the update to perform all verification operations. The entire process of rule update is recorded and solidified on the chain.

10. A blockchain-based trusted traceability and data verification system for the chip supply chain, applicable to the blockchain-based trusted traceability and data verification method for the chip supply chain as described in any one of claims 1 to 9, characterized in that, It includes a smart contract module, a pre-verification module, a consensus on-chain module, and a backtracking verification module; The smart contract module is used to pre-solidify a strong logic constraint graph of the entire life cycle of the chip in the consortium blockchain. The constraint graph includes business process logic constraint rules and physical parameter temporal evolution constraint rules. The pre-verification module is used to receive on-chain data requests initiated by each business node throughout the chip's lifecycle. After preprocessing the request data, it calls the strong logic constraint graph to perform full-link pre-verification on the request data. The consensus on-chain module is used to generate corresponding verification credentials for the request data that passes the verification, and send them to the consortium blockchain node synchronously with the request data to complete the consensus on-chain. For the request data that fails the verification, it directly intercepts the request data and generates an interception record that is synchronized to the supervisory node. The backtracking verification module is used to perform full-chain backtracking verification on the chip's full-cycle data according to preset trigger conditions, and to perform corresponding permission control operations based on the backtracking verification results.

Images