Block chain-based bulk commodity supply chain traceability management method and system

Abstract

The invention discloses a bulk commodity supply chain traceability management method and system based on a block chain, and belongs to the technical field of commodity supply chain traceability management. In a detection application stage, a traceability management platform generates a unique task identifier and sets a strict data uploading time window, and a digital signature mechanism of a detection mechanism is combined, so that the traceability of the bulk commodity supply chain is realized; uniqueness and timeliness control of the data submission process is realized; further performing permission verification strength analysis, task identifier repeated verification and security evaluation before consensus on the upload request through an intelligent contract to ensure that only credible, non-repeated and compliant data can be written into the block chain; according to the scheme, the problem of false data uplink caused by weak intelligent contract permission control in the prior art is effectively solved, and the data uploading security and the overall credibility and tamper-resistant capability of the traceability system are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of commodity supply chain traceability management, and in particular to a blockchain-based commodity supply chain traceability management method and system. Background Art

[0002] Blockchain-based commodity supply chain traceability management uses blockchain technology to record and share information about commodities (such as oil, coal, metals, and grain) throughout their production, transportation, storage, and trading processes, enabling traceability of commodity origins, destinations, and accountability. By leveraging blockchain's immutable and decentralized nature, it ensures the authenticity and transparency of supply chain data, improves regulatory efficiency and industry trust, and reduces fraud and information asymmetry.

[0003] The existing technology has the following shortcomings:

[0004] If smart contracts contain lax authorization controls or logical vulnerabilities when uploading test data to the blockchain, unauthorized users could bypass identity verification and directly upload false test results. If a malicious user impersonates a third-party testing agency and submits a "qualified" report, the system will automatically record it and treat it as authentic, causing serious information distortion. Because blockchain contracts are difficult to modify after deployment, once exploited, vulnerabilities can persist for a long time, continuously undermining the credibility and security of the traceability system. Summary of the Invention

[0005] The purpose of the present invention is to provide a blockchain-based commodity supply chain traceability management method and system to address the shortcomings of the background technology.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a blockchain-based commodity supply chain traceability management method, comprising:

[0007] The traceability management platform generates a unique task identifier when a test application is initiated, and sets a valid data upload time window for the task, which includes a start timestamp and an end timestamp;

[0008] The third-party testing agency tests the commodity within the validity period of the time window, generates a summary of the test data, digitally signs the summary, and submits it along with the current timestamp as an upload request to the blockchain system;

[0009] The smart contract deployed in the blockchain system verifies the received upload request, determines the strength of the smart contract's permission verification, and rejects all upload requests with weak permission verification;

[0010] The smart contract further verifies whether the task identifier already exists in the historical on-chain record. If not, it is marked as a valid upload; otherwise, repeated submission is rejected.

[0011] Further consensus confirmation is carried out on the verified test data summary, and the test data that has passed the consensus confirmation is written into the blockchain evidence storage structure.

[0012] Preferably, the strength of smart contract permission verification is judged, including modeling from the behavioral trajectory direction and hardware trust direction respectively, obtaining the institution's historical compliance score and hardware signature credibility;

[0013] The specific calculation method for the institution's historical compliance score is as follows: During the initial deployment phase, a default Beta distribution parameter is assigned to each registered testing institution: ;

[0014] Each upload behavior is judged and classified as compliant upload or illegal upload; after each upload is completed, the behavior count of the corresponding institution is updated according to its result: successful upload: α=α+1; failed upload: β=β+1; using the updated α and β values, the institution's historical compliance score is calculated , the expression is: .

[0015] Preferably, the current R value is used to determine whether the institution's current credibility meets the threshold for on-chain upload. If R ≥ 0.75: high credibility, direct upload is allowed; if R < 0.5: low credibility, regulatory review is required or upload is prohibited.

[0016] Preferably, the specific calculation method of hardware signature credibility is:

[0017] A total of four factors are selected: u1 is the device security level; u2 is the key protection mechanism strength; u3 is the signature algorithm strength; and u4 is the hardware usage credibility. The indicator set is denoted as U={u1,u2,u3,u4}. The fuzzy output level set V={very high, high, medium, low, very low} of the credibility is set; the corresponding numerical level S={10,8,6,4,2}. A weight wi is assigned to each factor according to the actual scenario. A membership matrix Z is constructed. For each factor ui, according to its specific value, it is mapped to the fuzzy membership of the five credibility levels to construct the membership matrix Z. The fuzzy weighted average method is used for matrix operations: ; W is a weight vector used to represent the contribution of each factor to the final credibility; the fuzzy result vector B is matched with the numerical level set S, and the weighted sum is obtained to obtain the hardware signature credibility T.

[0018] Preferably, the institution's historical compliance score and hardware signature credibility are converted into a comprehensive feature vector, and the comprehensive feature vector is used as the input of the machine learning model. The machine learning model uses each set of comprehensive feature vectors to predict the smart contract permission verification strength analysis value label as the prediction target, and takes minimizing the sum of prediction errors of all smart contract permission verification strength analysis value labels as the training target. The machine learning model is trained until the sum of prediction errors reaches convergence, and the model training is stopped. The smart contract permission verification strength analysis value is determined based on the model output results, wherein the machine learning model is a polynomial regression model.

[0019] Preferably, the obtained smart contract permission verification strength analysis value is compared with a preset threshold. If the smart contract permission verification strength analysis value is greater than or equal to the preset threshold, the data is allowed to enter the smart contract processing flow; if the smart contract permission verification strength analysis value is less than the preset threshold, all upload requests with low-strength permission verification are rejected.

[0020] Preferably, the verified test data summary is further confirmed by consensus, specifically including: for the verified test data summary, that is, the smart contract authority verification strength analysis value generated within a fixed time period is greater than or equal to the preset threshold, the smart contract authority verification strength analysis values ​​generated within a subsequent fixed time period that are greater than or equal to the preset threshold are collected, and a data set is established, the mean and standard deviation of the data set are calculated, and the data set is analyzed and then consensus confirmed.

[0021] Preferably, if the mean of the smart contract authority verification strength analysis values ​​in the data set is greater than or equal to the reference threshold of the mean of the smart contract authority verification strength analysis values, and the standard deviation of the smart contract authority verification strength analysis values ​​is less than the reference threshold of the standard deviation of the smart contract authority verification strength analysis values, it is confirmed that all data has passed the consensus and is written into the blockchain evidence structure in batches;

[0022] If the mean of the smart contract authority verification strength analysis value is greater than or equal to the reference threshold of the mean of the smart contract authority verification strength analysis value, and the standard deviation of the smart contract authority verification strength analysis value is greater than or equal to the reference threshold of the standard deviation of the smart contract authority verification strength analysis value, only the subset of data with a percentage h higher than the mean will be selected to enter the consensus, and the remaining data will be subject to manual review by the supervisory node;

[0023] If the mean of the smart contract authority verification strength analysis value is less than the reference threshold of the mean of the smart contract authority verification strength analysis value, and the standard deviation of the smart contract authority verification strength analysis value is greater than or equal to the reference threshold of the standard deviation of the smart contract authority verification strength analysis value, the data will be marked as an abnormal batch and an alarm event will be broadcast to the supervision chain;

[0024] If the mean of the smart contract authority verification strength analysis value is less than the reference threshold of the mean of the smart contract authority verification strength analysis value, and the standard deviation of the smart contract authority verification strength analysis value is less than the reference threshold of the standard deviation of the smart contract authority verification strength analysis value, the consensus will be suspended and the delayed verification mode will be entered, waiting for review by subsequent regulatory nodes.

[0025] The present invention also provides a blockchain-based commodity supply chain traceability management system, including a task scheduling and time window management module, a data collection and signature upload module, an authority verification smart contract module, a task uniqueness verification module, and a consensus control and on-chain evidence storage module.

[0026] Task scheduling and time window management module: The traceability management platform generates a unique task identifier when a test application is initiated, and sets a valid data upload time window for the task, which includes a start timestamp and an end timestamp;

[0027] Data collection and signature upload module: The third-party testing agency tests the commodities within the validity period of the time window, generates a test data summary, digitally signs the summary, and submits it together with the current timestamp as an upload request to the blockchain system;

[0028] Permission verification smart contract module: The smart contract deployed in the blockchain system verifies the received upload request, determines the strength of the smart contract's permission verification, and rejects all upload requests with low-strength permission verification;

[0029] Task uniqueness verification module: The smart contract further verifies whether the task identifier already exists in the historical on-chain record. If not, it is marked as a valid upload; otherwise, repeated submission is rejected;

[0030] Consensus control and on-chain evidence storage module: further consensus confirmation is carried out on the verified test data summary, and the test data that has passed the consensus confirmation is written into the blockchain evidence storage structure.

[0031] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0032] 1. This invention achieves timeliness and uniqueness control of data behavior by generating a unique task identifier during the detection task initiation phase and setting a strict data upload time window. Combined with a digital signature mechanism for the detection data summary, this ensures that uploaded data cannot be tampered with and is authentic and traceable from the source. The smart contract introduces a multi-factor permission verification mechanism during the data reception phase. This integrates historical compliance scores and hardware signature credibility, dynamically generating a permission verification strength analysis value through a machine learning model. Only requests that meet the credibility threshold are allowed to enter the contract process, effectively preventing the risk of unauthorized users falsifying data and bypassing verification uploads.

[0033] 2. This invention introduces a statistically based cluster data analysis mechanism during the consensus phase. By evaluating the mean and standard deviation of the permission verification strength values ​​within a fixed time period, the consistency and reliability of data quality are determined, thereby deciding whether to upload data in batches, accept them partially, issue an anomaly warning, or postpone processing. This mechanism not only improves the system's perception of the overall credibility and volatility risk of data, but also enhances its resistance to batch data attacks and abnormal behavior. It achieves a transition from single-transaction verification to overall behavioral risk control, comprehensively improving the security, stability, and intelligence level of the blockchain traceability system. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments described in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0035] Figure 1 This is a mind map of the method of the present invention.

[0036] Figure 2 This is a mind map of the system modules of the present invention. DETAILED DESCRIPTION

[0037] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0038] Example 1, please refer to Figure 1 As shown, the blockchain-based commodity supply chain traceability management method described in this embodiment includes:

[0039] The traceability management platform generates a unique task identifier when a test application is initiated, and sets a valid data upload time window for the task, which includes a start timestamp and an end timestamp;

[0040] The third-party testing agency tests the commodity within the validity period of the time window, generates a summary of the test data, digitally signs the summary, and submits it along with the current timestamp as an upload request to the blockchain system;

[0041] The smart contract deployed in the blockchain system verifies the received upload request, determines the strength of the smart contract's permission verification, and rejects all upload requests with weak permission verification;

[0042] The smart contract further verifies whether the task identifier already exists in the historical on-chain record. If not, it is marked as a valid upload; otherwise, repeated submission is rejected.

[0043] Further consensus confirmation is carried out on the verified test data summary, and the test data that has passed the consensus confirmation is written into the blockchain evidence storage structure.

[0044] In a blockchain-based commodity supply chain traceability system, whenever a batch of commodities (such as crude oil, ore, grain, etc.) enters the testing phase, the traceability management platform must ensure that the uploaded test data is unique, timely, and verifiable. To this end, when a test application is initiated, the system automatically executes the "task initialization" process:

[0045] Inspection tasks are submitted through the system by the product owner (e.g., warehouse, purchaser) or regulator. The requested information includes product identification (e.g., batch number, product ID), inspection items, submitter identity, and public key. The platform uses a hash function (e.g., SHA-256, Keccak256, etc.) to encrypt the following fields to generate a unique TaskID: TaskID = Hash(Product ID + Submitter ID + Current Timestamp + Random Salt). Alternatively, a UUID (Universally Unique Identifier)-based algorithm is used to generate TaskIDs to ensure global uniqueness. This identifier is uniquely associated with the task content and serves as the primary index key for the inspection task throughout the blockchain traceability process. The system checks for duplicate TaskIDs in the task pool and automatically recalculates any existing ones. A distributed unique ID generator with a time prefix (e.g., the Twitter Snowflake algorithm) can be used to avoid concurrency conflicts.

[0046] Time window C is the time interval within which test results are allowed to be submitted for this task, set as [Tstart,Tend]. Tstart is the timestamp of task creation, typically the current system time (UTC). Tend is the last time point allowed for upload, calculated based on business rules. Tend = Tstart + ΔT. ΔT is the predefined upload time limit, such as 1800 seconds or 21600 seconds. ΔT can be dynamically configured based on product category and test type. For example, for hazardous chemicals, upload within 30 minutes; for conventional grains, upload within 12 hours.

[0047] Timestamps are based on blockchain node consensus time or NTP (Network Time Protocol) synchronization servers to prevent uploaders from tampering with local time. The platform can ensure time consistency through trusted time source services (such as blockchain timestamp oracle services). Tstart and Tend are stored along with the TaskID in the on-chain task table or off-chain database cache. The time window parameters are publicly available to uploaders and can be accessed in real time via the REST API or contract query interface, preventing uploaders from submitting incorrectly due to unclear time windows.

[0048] After the traceability management platform assigns the inspection task and sets the effective time window, the third-party inspection agency must complete the quality inspection of the bulk commodity within the time window. The inspection content usually includes but is not limited to the following:

[0049] The physical and chemical properties of the product (such as purity, ingredient ratio, and impurity content);

[0050] Environmental condition records (such as sampling temperature and humidity);

[0051] Additional metadata such as sample number, tester information, and test equipment number.

[0052] Test data can be collected and processed uniformly by the internal system of the testing organization (such as the LIMS laboratory information management system) to form a standardized data structure, ensuring the consistency and readability of various types of test data.

[0053] In order to reduce the volume of data uploaded to the chain and improve the efficiency of blockchain processing, the testing agency summarizes the complete test data, that is, extracts the core content of the data to generate a test data summary: the so-called summary is a fixed-format data compression, summary extraction or hashing of the test data content to form an identifier with a unique fingerprint feature; the test data summary is used to mark the core content of the batch of test results, and is used as one of the evidence contents when uploaded to the blockchain; the original test report is usually retained in off-chain storage (such as an internal database or a decentralized storage system such as IPFS), and a one-to-one mapping is established with the on-chain information through the summary.

[0054] To ensure that the test data is generated by a genuine organization and to prevent forgery, tampering, or false uploading, the testing organization needs to digitally sign and authenticate the test data summary:

[0055] The digital signature is a security certificate generated based on the private key of the testing organization;

[0056] The signature object contains information such as the test data summary, the current test timestamp, the task ID, and the identity of the uploader;

[0057] The signature can bind the summary to the identity of the testing organization through an encryption algorithm and achieve post-verification;

[0058] Nodes on the blockchain can verify the legitimacy of the signature through the public key, confirming the identity of the data uploader and that the data has not been tampered with.

[0059] After the testing agency completes the signature, it constructs a standardized data upload request, which mainly includes the following elements:

[0060] Detection task ID (assigned by the platform to identify which detection task the upload request belongs to);

[0061] Summary of test data (representative data content that has been processed);

[0062] Current timestamp (used to verify whether the data upload is still within the time window);

[0063] The digital signature of the testing organization (for identity authentication and data integrity verification);

[0064] Other optional fields, such as product number, test method identifier, test equipment number, etc.

[0065] The upload request is sent by the testing agency's system to the blockchain platform or its corresponding smart contract entrance through the interface.

[0066] After the blockchain platform receives the upload request, it will enter the next stage of the smart contract verification process, which mainly includes: time window verification (whether it is within the specified time range); signature validity verification (whether it is issued by an authorized testing agency); detection task uniqueness verification (whether it is the first upload); data summary on-chain storage (if it passes the verification, it will be recorded on the blockchain).

[0067] By introducing the detection data summary and signature mechanism, the system ensures data authenticity, verifies data integrity, prevents upload tampering, and improves upload efficiency.

[0068] Traditional blockchain data uploads often rely solely on simple verification of the uploader's identity, without breaking down and quantifying the security strength of the upload. This can result in even weakly authenticated testers being allowed to upload, creating security risks. To address this, our system introduces a mechanism for calculating the strength of permission verification. Through smart contracts, upload requests are analyzed on-chain using multiple parameters, and the system dynamically determines the legitimacy and credibility of the request based on the analysis results.

[0069] To improve the accuracy of the system's judgment, modeling is performed from the perspective of behavioral trajectory and hardware trustworthiness, including obtaining the institution's historical compliance score and hardware signature credibility;

[0070] The institution's historical compliance score is calculated based on the testing institution's behavior records in the testing data it uploaded in the past. The specific calculation method is:

[0071] During the initial deployment of the system, a default Beta distribution parameter is assigned to each registered testing agency: (meaning "neutral trust");

[0072] The system needs to judge each upload behavior and classify it into: compliant upload (recorded as successful): such as uploading on time, qualified content, legal signature, etc.; illegal upload (recorded as failed): such as uploading within the time limit, being rejected by the regulator, repeated submission, etc.

[0073] After each upload is completed, the system updates the behavior count of the corresponding organization according to its results: successful upload: α=α+1; failed upload: β=β+1;

[0074] Calculate the institution's historical compliance score using the updated α and β values , the expression is: The system determines whether the current credibility of the institution meets the threshold for uploading to the chain based on the current R value. For example, if R ≥ 0.75: high credibility, direct uploading is allowed; if R < 0.5: low credibility, regulatory review is required or uploading is prohibited.

[0075] Hardware signature credibility is used to evaluate whether the data is bound to the signature of the trusted hardware when it is uploaded. The specific calculation method is:

[0076] A total of four factors are selected: u1 is the device security level (such as TPM, HSM, TEE, etc.); u2 is the strength of the key protection mechanism (such as hardware encapsulation, anti-physical attack, PIN); u3 is the strength of the signature algorithm (such as RSA2048, ECC256, Ed25519); u4 is the trustworthiness of hardware use (such as authorized use, exclusive use, shared use); the indicator set is U={u1,u2,u3,u4}; the fuzzy output level set (5 levels) of the set credibility is V={very high, high, medium, low, very low}; the corresponding numerical level S={10,8,6,4,2};

[0077] Assign weights to each factor based on the actual scenario, with the total weight being 1. For example, wi={w1=0.4,w2=0.3,w3=0.2,w4=0.1} indicates that the security level is the most important and is given the highest weight; reliability is relatively less important.

[0078] Construct the membership matrix Z. For each factor ui, according to its specific value, it is mapped to the fuzzy membership of the five-level credibility level (between 0 and 1). The membership matrix Z is constructed. The fuzzy weighted average method is used for matrix operation: ; W is a weight vector used to represent the contribution of each factor to the final credibility; the fuzzy result vector B is matched with the numerical level set S, and the weighted sum is obtained to obtain the hardware signature credibility T.

[0079] The institution's historical compliance score and hardware signature credibility are converted into a comprehensive feature vector, which is used as the input of the machine learning model. The machine learning model uses each set of comprehensive feature vectors to predict the smart contract permission verification strength analysis value label as the prediction target, and takes minimizing the sum of prediction errors of all smart contract permission verification strength analysis value labels as the training target. The machine learning model is trained until the sum of prediction errors reaches convergence, and the model training is stopped. The smart contract permission verification strength analysis value is determined based on the model output results. The machine learning model is a polynomial regression model.

[0080] The obtained smart contract permission verification strength analysis value is compared with the preset threshold. If the smart contract permission verification strength analysis value is greater than or equal to the preset threshold, the data is allowed to enter the smart contract processing flow; if the smart contract permission verification strength analysis value is less than the preset threshold, all upload requests with low-strength permission verification are rejected.

[0081] After receiving the data upload request from the testing agency, the smart contract parses the core fields contained in the request, especially: the testing task identifier (TaskID), the testing data summary, the timestamp, and the digital signature; at this point, the system will use the TaskID as the core index value and enter the repeatability verification process.

[0082] The smart contract maintains a task status mapping table or hash index structure to record the processed TaskIDs. The table structure is usually in the form of key-value pairs, such as TaskID→true / false or processing status flags. The table is usually located in the contract's storage variables and is efficiently searched through a mapping structure (such as mapping or table).

[0083] The smart contract accesses the above mapping structure to determine whether the currently received TaskID already exists. If the TaskID has been registered, it means that the task has successfully submitted data. The system immediately rejects the upload request and can also trigger abnormal event logs, such as duplicate submission records and abnormal behavior warnings of institutions.

[0084] If the TaskID is not registered: it means that this task is uploaded for the first time; the system marks the request as "valid upload" and continues the subsequent processing flow.

[0085] If the TaskID verification passes (i.e., the first submission), the system will perform the following operations: record the TaskID as "uploaded" within the smart contract; prevent any subsequent uploads of the same TaskID from being accepted again; and retain the recorded information until the end of the contract lifecycle or manual clearing.

[0086] The smart contract makes the following decisions based on the judgment results:

[0087] Valid upload: execute subsequent steps such as data summary notarization, permission verification, and consensus writing; repeated upload: terminate processing immediately; return failure status to the uploader; the system can send repeated submission events to the supervision chain for audit records.

[0088] Further consensus confirmation is carried out on the verified test data summary, and the test data that has passed the consensus confirmation is written into the blockchain evidence structure, specifically including:

[0089] For the summary of the test data that has passed the verification, that is, the smart contract permission verification strength analysis value generated within a fixed time period is greater than or equal to the preset threshold, the smart contract permission verification strength analysis value generated within the subsequent fixed time period that is greater than or equal to the preset threshold is collected, and a data set is established. The mean and standard deviation of the data set are calculated, and after analysis, consensus confirmation is carried out.

[0090] If the mean of the smart contract permission verification strength analysis values ​​within the data set is greater than or equal to the reference threshold for the mean of the smart contract permission verification strength analysis values, and the standard deviation of the smart contract permission verification strength analysis values ​​is less than the reference threshold for the standard deviation of the smart contract permission verification strength analysis values, it indicates that the overall credibility of the data uploaded during that time period is high and the data stability is good, indicating that the batch of data is reliable and highly consistent. The system confirms that all data has passed consensus and is batch-written to the blockchain evidence structure.

[0091] If the mean of the smart contract permission verification strength analysis values ​​is greater than or equal to the reference threshold for the mean of the smart contract permission verification strength analysis values, and the standard deviation of the smart contract permission verification strength analysis values ​​is greater than or equal to the reference threshold for the standard deviation of the smart contract permission verification strength analysis values, it indicates that the average level of credibility is high, but the volatility is large, and there is a risk of mixing extremely high and low quality data. The system will only select a subset of data with a percentage h above the mean to enter consensus, and the remaining data will be subject to manual review by the supervisory nodes.

[0092] If the mean of the smart contract permission verification strength analysis value is less than the reference threshold of the mean of the smart contract permission verification strength analysis value, and the standard deviation of the smart contract permission verification strength analysis value is greater than or equal to the reference threshold of the standard deviation of the smart contract permission verification strength analysis value, it indicates that the average credibility is low and fluctuates greatly, and the system may be in an abnormal behavior or attack state. The data segment will be automatically marked as an abnormal batch and an alarm event will be broadcast to the chain of custody.

[0093] If the mean of the Smart Contract Permission Verification Strength Analysis Values ​​is less than the reference threshold for the mean of the Smart Contract Permission Verification Strength Analysis Values, and the standard deviation of the Smart Contract Permission Verification Strength Analysis Values ​​is less than the reference threshold for the standard deviation of the Smart Contract Permission Verification Strength Analysis Values, this indicates that the overall credibility of the data segment is low, but its stability is high. This may indicate that the overall configuration of institutions is weak or there are system unification issues. The system suspends consensus and enters delayed verification mode. The data enters the off-chain waiting pool, awaiting subsequent review by regulatory nodes or model threshold readjustment.

[0094] Example 2, please refer to Figure 2 As shown, the blockchain-based commodity supply chain traceability management system described in this embodiment includes a task scheduling and time window management module, a data collection and signature upload module, a permission verification smart contract module, a task uniqueness verification module, and a consensus control and on-chain evidence storage module;

[0095] Task scheduling and time window management module: The traceability management platform generates a unique task identifier when a test application is initiated, and sets a valid data upload time window for the task, which includes a start timestamp and an end timestamp;

[0096] Data collection and signature upload module: The third-party testing agency tests the commodities within the validity period of the time window, generates a test data summary, digitally signs the summary, and submits it together with the current timestamp as an upload request to the blockchain system;

[0097] Permission verification smart contract module: The smart contract deployed in the blockchain system verifies the received upload request, determines the strength of the smart contract's permission verification, and rejects all upload requests with low-strength permission verification;

[0098] Task uniqueness verification module: The smart contract further verifies whether the task identifier already exists in the historical on-chain record. If not, it is marked as a valid upload; otherwise, repeated submission is rejected;

[0099] Consensus control and on-chain evidence storage module: further consensus confirmation is carried out on the verified test data summary, and the test data that has passed the consensus confirmation is written into the blockchain evidence storage structure.

[0100] The above formulas are all dimensionless and numerical calculations. The formulas are obtained by collecting a large amount of data and performing software simulation to obtain the most recent real situation. The preset parameters in the formulas are set by technicians in this field according to actual conditions.

[0101] The above is only a specific implementation method of the present application, but the scope of protection of the present application is not limited thereto. Any technician familiar with this technical field can easily think of changes or replacements within the technical scope disclosed in this application, which should be covered by the scope of protection of the present application.

Claims

1. A blockchain-based commodity supply chain traceability management method, characterized by: include: The traceability management platform generates a unique task identifier when a test application is initiated, and sets a valid data upload time window for the task, which includes a start timestamp and an end timestamp; The third-party testing agency tests the commodity within the validity period of the time window, generates a summary of the test data, digitally signs the summary, and submits it along with the current timestamp as an upload request to the blockchain system; The smart contract deployed in the blockchain system verifies the received upload request, determines the strength of the smart contract's permission verification, and rejects all upload requests with weak permission verification; The smart contract further verifies whether the task identifier already exists in the historical on-chain record. If not, it is marked as a valid upload; otherwise, repeated submission is rejected. Further consensus confirmation is carried out on the verified test data summary, and the test data that has passed the consensus confirmation is written into the blockchain evidence storage structure.

2. The blockchain-based commodity supply chain traceability management method according to claim 1 is characterized by: Determine the strength of smart contract permission verification, including modeling from the perspective of behavioral trajectory and hardware trustworthiness, and obtaining the institution's historical compliance score and hardware signature credibility; The specific calculation method for the institution's historical compliance score is as follows: During the initial deployment phase, a default Beta distribution parameter is assigned to each registered testing institution: ; Each upload behavior is judged and classified as compliant upload or illegal upload; after each upload is completed, the behavior count of the corresponding institution is updated according to its result: successful upload: α=α+1; failed upload: β=β+1; using the updated α and β values, the institution's historical compliance score is calculated , the expression is: .

3. The blockchain-based commodity supply chain traceability management method according to claim 2 is characterized by: Based on the current R value, determine whether the institution's current credibility meets the threshold for uploading to the chain. If R ≥ 0.75: high credibility, direct uploading is allowed; if R < 0.5: low credibility, regulatory review is required or uploading is prohibited.

4. The blockchain-based commodity supply chain traceability management method according to claim 3 is characterized by: The specific calculation method for hardware signature credibility is: A total of four factors are selected: u1 is the device security level; u2 is the key protection mechanism strength; u3 is the signature algorithm strength; and u4 is the hardware usage credibility. The indicator set is denoted as U={u1,u2,u3,u4}. The fuzzy output level set V={very high, high, medium, low, very low} of the credibility is set; the corresponding numerical level S={10,8,6,4,2}. A weight wi is assigned to each factor according to the actual scenario. A membership matrix Z is constructed. For each factor ui, according to its specific value, it is mapped to the fuzzy membership of the five credibility levels to construct the membership matrix Z. The fuzzy weighted average method is used for matrix operations: ; W is a weight vector used to represent the contribution of each factor to the final credibility; the fuzzy result vector B is matched with the numerical level set S, and the weighted sum is obtained to obtain the hardware signature credibility T.

5. The blockchain-based commodity supply chain traceability management method according to claim 4 is characterized by: The institution's historical compliance score and hardware signature credibility are converted into a comprehensive feature vector, which is used as the input of the machine learning model. The machine learning model uses each set of comprehensive feature vectors to predict the smart contract permission verification strength analysis value label as the prediction target, and takes minimizing the sum of prediction errors of all smart contract permission verification strength analysis value labels as the training target. The machine learning model is trained until the sum of prediction errors reaches convergence, and the model training is stopped. The smart contract permission verification strength analysis value is determined based on the model output results. The machine learning model is a polynomial regression model.

6. The blockchain-based commodity supply chain traceability management method according to claim 5 is characterized by: Compare the obtained smart contract permission verification strength analysis value with the preset threshold. If the smart contract permission verification strength analysis value is greater than or equal to the preset threshold, the data is allowed to enter the smart contract processing flow; If the smart contract permission verification strength analysis value is less than the preset threshold, all upload requests with low-strength permission verification will be rejected.

7. The blockchain-based commodity supply chain traceability management method according to claim 6 is characterized by: Further consensus confirmation is conducted on the verified test data summaries, specifically including: for the verified test data summaries, that is, the smart contract authority verification strength analysis values ​​generated within a fixed time period are greater than or equal to the preset threshold, the smart contract authority verification strength analysis values ​​generated within the subsequent fixed time period that are greater than or equal to the preset threshold are collected, and a data set is established, the mean and standard deviation of the data set are calculated, and the data set is analyzed and then consensus confirmation is conducted.

8. The blockchain-based commodity supply chain traceability management method according to claim 7, characterized in that: If the mean of the smart contract authority verification strength analysis values ​​in the data set is greater than or equal to the reference threshold of the mean of the smart contract authority verification strength analysis values, and the standard deviation of the smart contract authority verification strength analysis values ​​is less than the reference threshold of the standard deviation of the smart contract authority verification strength analysis values, all data are confirmed to have passed consensus and are batch-written into the blockchain evidence structure; If the mean of the smart contract authority verification strength analysis value is greater than or equal to the reference threshold of the mean of the smart contract authority verification strength analysis value, and the standard deviation of the smart contract authority verification strength analysis value is greater than or equal to the reference threshold of the standard deviation of the smart contract authority verification strength analysis value, only the subset of data with a percentage h higher than the mean will be selected to enter the consensus, and the remaining data will be subject to manual review by the supervisory node; If the mean of the smart contract authority verification strength analysis value is less than the reference threshold of the mean of the smart contract authority verification strength analysis value, and the standard deviation of the smart contract authority verification strength analysis value is greater than or equal to the reference threshold of the standard deviation of the smart contract authority verification strength analysis value, the data will be marked as an abnormal batch and an alarm event will be broadcast to the supervision chain; If the mean of the smart contract authority verification strength analysis value is less than the reference threshold of the mean of the smart contract authority verification strength analysis value, and the standard deviation of the smart contract authority verification strength analysis value is less than the reference threshold of the standard deviation of the smart contract authority verification strength analysis value, the consensus will be suspended and the delayed verification mode will be entered, waiting for review by subsequent regulatory nodes.

9. A blockchain-based bulk commodity supply chain traceability management system, used to implement the blockchain-based bulk commodity supply chain traceability management method according to any one of claims 1 to 8, characterized in that: It includes task scheduling and time window management module, data collection and signature upload module, permission verification smart contract module, task uniqueness verification module, and consensus control and on-chain evidence storage module; Task scheduling and time window management module: The traceability management platform generates a unique task identifier when a test application is initiated, and sets a valid data upload time window for the task, which includes a start timestamp and an end timestamp; Data collection and signature upload module: The third-party testing agency tests the commodities within the validity period of the time window, generates a test data summary, digitally signs the summary, and submits it together with the current timestamp as an upload request to the blockchain system; Permission verification smart contract module: The smart contract deployed in the blockchain system verifies the received upload request, determines the strength of the smart contract's permission verification, and rejects all upload requests with low-strength permission verification; Task uniqueness verification module: The smart contract further verifies whether the task identifier already exists in the historical on-chain record. If not, it is marked as a valid upload; otherwise, repeated submission is rejected; Consensus control and on-chain evidence storage module: further consensus confirmation is carried out on the verified test data summary, and the test data that has passed the consensus confirmation is written into the blockchain evidence storage structure.

Images