A blockchain-based agricultural product transaction processing method and system

Abstract

The application discloses a kind of based on blockchain agricultural product transaction processing method and system, it is related to network information security technical field, the present application is oriented to national agricultural product cold chain high concurrency and weak network scene, massive fragment event data chain is encapsulated as fragment evidence abstract data and evidence package data, on-chain only processes responsibility fragment proof transaction data, realize low cost high throughput, through double signature offline receipt data ensure that evidence is verifiable and irrefutable during network interruption, avoid after-the-fact dispute, responsibility fragment contract is based on fragment compliance conclusion data to automatically generate fund processing instruction data, complete release, freeze, penalty, claim linkage, and risk level is output in combination with cargo loss risk prediction model, support fine management and on-demand disclosure evidence.

Description

Technical Field

[0001] This invention relates to the field of network information security technology, and in particular to a blockchain-based method and system for processing agricultural product transactions. Background Technology

[0002] In a nationwide agricultural product supply chain, a single batch can generate a large amount of data on handover events, sealing events, sampling events, and environmental events within a few days. Existing blockchain traceability solutions typically record each event on the blockchain or directly store raw environmental data for post-event traceability. However, in large-scale, multi-batch concurrent cold chain operations with frequent weak network conditions, these solutions are prone to problems such as insufficient on-chain throughput, high on-chain costs, and significant latency. Furthermore, network unavailability is common at the production site and during transportation, preventing real-time on-chain recording of events. Subsequent recording makes it difficult to prove that the events were generated at the time and have not been tampered with, thus hindering the formation of an automatically enforceable closed loop of evidence for liability in quality disputes, penalty settlements, insurance claims, and financing risk control. Simultaneously, financial institutions and regulators require credible evidence of compliance and non-compliance, but supply chain companies are unwilling to disclose commercially sensitive information such as complete temperature curves and cargo flow, making it difficult to reconcile credibility and privacy. Therefore, a blockchain transaction processing method for large-scale agricultural product supply chains is needed to transform on-chain processing objects from massive events into verifiable, responsible conclusions, and to form an irrefutable evidence package even under weak network conditions, so as to support automatic liquidation, penalty and compensation triggering.

[0003] Currently, Chinese invention patent application number 201910146651.4 discloses a data transaction processing method and system based on blockchain, including: a business entity and its blockchain system, a data entity and its blockchain system, a data source entity and its blockchain system, and an authentication authority; the blockchain systems of the business entity, data entity, and data source entity communicate according to unified technical specifications; the business entity, data entity, and data source entity all communicate with the authentication authority; the business entity provides business services to users; the authentication authority provides personal authentication to users; the data entity provides the data required for business processing to the business entity; the data source entity provides raw data to the data entity; the data source entity provides raw data to the business entity; the blockchain systems of the business entity, data entity, and data source entity are used for data storage and storage synchronization. Simultaneously, a data transaction processing method based on blockchain is also disclosed.

[0004] The aforementioned technologies are insufficient to achieve on-chain verification of liability conclusions based on verifiable evidence and automatic settlement, penalties, and claims linkage in the context of weak networks and high-frequency events in large-scale agricultural cold chains, while also taking into account throughput costs and commercial data privacy. Summary of the Invention

[0005] The technical problem solved by this invention is that existing technologies are difficult to achieve on-chain conclusions of liability fragments based on verifiable evidence and automatic settlement, penalties and claims linkage under the conditions of weak network and high frequency events in large-scale agricultural cold chain, while taking into account throughput costs and commercial data privacy.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: A blockchain-based method for processing agricultural product transactions includes the following steps: Step S1: Obtain batch identification data, responsible entity data, and segment rule data. Based on the responsible entity data, divide the supply chain process corresponding to the batch identification data into several responsible segments, generate responsible segment identification data, write the segment rule data into the blockchain and bind it with the responsible segment identification data to form responsible segment contract data. Step S2: Collect event data within the responsible segment. The event data includes handover event data, sealing event data, sampling event data, and environmental event data. Construct a summary of the event data, output the segment evidence summary data, and sign the segment evidence summary data with the responsible party to output the first signature summary data. Step S3: When the offline triggering condition is met, generate offline receipt data based on the first signature digest data, obtain the witness subject's signature, output double-signed offline receipt data, and cache the double-signed offline receipt data and the first signature digest data as evidence package data. Step S4: At the end of the responsibility segment, parse the evidence package data and make a segment compliance judgment on the segment event data based on the responsibility segment contract data, output the segment compliance conclusion data, and encapsulate the responsibility segment identifier data, batch identifier data, segment compliance conclusion data and segment evidence summary data into responsibility segment proof transaction data and broadcast it to the blockchain; Step S5: After the blockchain confirms the consensus on the transaction data of the liability fragment proof, it triggers the execution of the liability fragment contract data. Based on the compliance conclusion data of the fragment, it generates fund processing instruction data, which includes release instruction data, freeze instruction data, penalty instruction data and claim trigger instruction data. The fund processing instruction data is then written into the blockchain. Step S6: Upon receiving a dispute triggering request, locate the evidence package data based on the fragment evidence summary data and output the evidence data according to the disclosure rules. Write the evidence data into the blockchain and output the adjudication result data. Update the fund processing instruction data based on the adjudication result data.

[0007] Preferably, step S1 includes the following sub-steps: Step S101: Obtain batch identification data, which is used to uniquely identify agricultural product batches; Step S102: Obtain the responsible entity data, which includes the shipper identifier, carrier identifier, warehousing entity identifier, and consignee identifier; Step S103: Obtain fragment rule data, which includes environmental threshold rules, seal consistency rules, sampling inspection qualification rules, and settlement rules; Step S104: Divide responsibility segments based on the data of the responsible subject, generate responsibility segment identification data, and write the responsibility segment identification data and segment rule data into the blockchain to form responsibility segment contract data.

[0008] Preferably, step S2 includes the following sub-steps: Step S201: Collect handover event data, which includes handover initiation time, handover completion time, entity identifiers of both parties, and handover location identifier; Step S202: Collect seal event data, which includes seal identifier, seal scanning time, and seal scanning subject identifier; Step S203: Collect sampling event data, which includes the sampling agency identifier, sampling time, and sampling conclusion identifier; Step S204: Collect environmental event data, including temperature data, humidity data, and vibration data; Step S205: Construct fragment evidence digest data from fragment event data, and sign the fragment evidence digest data based on the private key of the responsible party, outputting the first signature digest data.

[0009] Preferably, the fragment evidence summary data is constructed as follows: The event fragment data is grouped according to a preset time window to obtain several event window data; For each event window data, an event window summary value is calculated, where the event window summary value is the hash value of the event window data; Generate a summary chain data by concatenating the summary values ​​of several event windows in chronological order; Calculate the root digest value for the digest chain data, where the root digest value is the hash value of the digest chain data; The root digest value is combined with the responsible fragment identifier data and batch identifier data to output fragment evidence digest data.

[0010] Preferably, step S3 includes the following sub-steps: Step S301: Determine the offline triggering conditions, which include network unavailability and on-chain submission failure conditions; Step S302: Generate offline receipt data, which includes responsibility segment identifier data, batch identifier data, segment evidence summary data, and receipt timestamp data; Step S303: Obtain the witness subject signature, which is the witness subject's signature on the offline receipt data, and output the double-signed offline receipt data; Step S304: Encapsulate the dual-signature offline receipt data and the first signature digest data into evidence package data, and cache the evidence package data in local storage.

[0011] Preferably, step S4 includes the following sub-steps: Step S401: Parse the evidence package data and extract the responsibility fragment identifier data, batch identifier data, fragment evidence summary data, and fragment event data; Step S402, Perform fragment compliance determination: Compare the environmental event data with the environmental threshold rules and output the environmental compliance identifier; The data on sealed events is compared with the rules for consistency of sealed events, and a seal compliance mark is output; the data on random inspection events is compared with the rules for passing random inspections, and a random inspection compliance mark is output. Step S403: Merge and output the fragment compliance conclusion data, wherein the fragment compliance conclusion data is the fusion result of environmental compliance mark, seal compliance mark and sampling inspection compliance mark; Step S404: Generate the responsibility fragment proof transaction data and broadcast the responsibility fragment proof transaction data to the blockchain.

[0012] Preferably, step S5 includes the following sub-steps: Step S501, parse the compliance conclusion data of the fragment: If the fragment compliance conclusion data is compliant, then release instruction data is generated and written to the blockchain; If the data from the segment is deemed non-compliant, a freeze order will be generated and written to the blockchain. Step S502: Calculate penalty instruction data when the fragment compliance conclusion data is non-compliant: The penalty amount data is calculated based on the settlement rules, and the penalty amount data is encapsulated into penalty instruction data and written into the blockchain. Step S503: Generate claim trigger instruction data when the fragment compliance conclusion data meets the claim conditions: Based on the claim conditions in the settlement rules, the claim trigger instruction data is output and written to the blockchain.

[0013] Preferably, the dispute triggering request includes: Data on the dispute requests and grounds for dispute submitted by the responsible party; After receiving the dispute request data, the blockchain freezes the fund processing instruction data corresponding to the liability segment identifier data and outputs the evidence request data, which is used to request the provision of evidence data in the evidence package data.

[0014] Preferably, step S6 includes the following sub-steps: Step S601: Locate the evidence package data based on the fragment evidence digest data, and perform integrity verification on the evidence package data. The integrity verification is to verify that the fragment evidence digest data in the evidence package data is consistent with the fragment evidence digest data already stored in the blockchain. Step S602: Generate evidence data according to the disclosure rules, wherein the disclosure rules are used to limit the time range and data field range of the evidence data; Step S603: Write the evidence data into the blockchain and output the adjudication result data; Step S604: Update the fund processing instruction data based on the adjudication result data. The update includes replacing the freeze instruction data with release instruction data or penalty instruction data.

[0015] A blockchain-based transaction processing system includes a fragment contract construction module, a summary data generation module, an acceptance data generation module, a transaction data generation module, a conditional settlement processing module, and an evidence adjudication execution module. The segment contract construction module is used to obtain batch identification data, responsible entity data and segment rule data. Based on the responsible entity data, the supply chain process corresponding to the batch identification data is divided into several responsible segments, responsible segment identification data is generated, and segment rule data is written into the blockchain and bound to the responsible segment identification data to form responsible segment contract data. The summary data generation module is used to collect segment event data within the responsibility segment. The segment event data includes handover event data, seal event data, sampling event data, and environmental event data. The module constructs a summary of the segment event data, outputs segment evidence summary data, and signs the segment evidence summary data with the responsible party, outputting first signature summary data. The acceptance data generation module is used to generate offline receipt data based on the first signature digest data when the offline triggering conditions are met, obtain the witness subject's signature, output double-signed offline receipt data, and cache the double-signed offline receipt data and the first signature digest data as evidence package data. The transaction data generation module is used to parse the evidence package data at the end of the responsibility segment and make a segment compliance judgment on the segment event data based on the responsibility segment contract data, output segment compliance conclusion data, encapsulate the responsibility segment identifier data, batch identifier data, segment compliance conclusion data and segment evidence summary data into responsibility segment proof transaction data and broadcast it to the blockchain; The conditional settlement processing module is used to trigger the execution of the liability fragment contract data after the blockchain confirms the consensus on the liability fragment proof transaction data, and to generate fund processing instruction data based on the fragment compliance conclusion data. The fund processing instruction data includes release instruction data, freeze instruction data, penalty instruction data and claim trigger instruction data, and writes the fund processing instruction data into the blockchain. The evidence presentation and adjudication execution module is used to locate the evidence package data based on the fragment evidence summary data and output the evidence data according to the disclosure rules when a dispute triggering request is received, write the evidence data into the blockchain and output the adjudication result data, and update the fund processing instruction data based on the adjudication result data.

[0016] The beneficial effects of this invention are as follows: This invention targets high-concurrency and weak-network scenarios in the nationwide agricultural product cold chain. It encapsulates massive fragment event data off-chain into fragment evidence summary data and evidence package data, while only processing responsibility fragment proof transaction data on-chain. This achieves low cost and high throughput. Through double-signature offline receipt data, it ensures that evidence is verifiable and non-repudiable during network outages, avoiding disputes caused by subsequent re-transmission. The responsibility fragment contract automatically generates fund processing instruction data based on the fragment compliance conclusion data, completing the linkage of release, freezing, deduction, and compensation. It also outputs risk levels in conjunction with the cargo damage risk prediction model, supporting refined governance and on-demand disclosure of evidence. Attached Figure Description

[0017] Figure 1 A flowchart illustrating the steps of a blockchain-based agricultural product transaction processing method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the basic process of a blockchain-based transaction processing system provided in one embodiment of the present invention. Detailed Implementation

[0018] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0019] Example 1, referring to Figure 1 This paper provides a blockchain-based method for processing agricultural product transactions, which includes the following steps: Step S1: Obtain batch identification data, responsible entity data, and segment rule data. Based on the responsible entity data, divide the supply chain process corresponding to the batch identification data into several responsible segments, generate responsible segment identification data, write the segment rule data into the blockchain and bind it with the responsible segment identification data to form responsible segment contract data.

[0020] Step S2: Collect event data within the responsible segment. The event data includes handover event data, sealing event data, sampling event data, and environmental event data. Construct a summary of the event data, output the segment evidence summary data, and sign the segment evidence summary data with the responsible party, outputting the first signature summary data.

[0021] Step S3: When the offline triggering condition is met, generate offline receipt data based on the first signature digest data, obtain the witness subject's signature, output double-signed offline receipt data, and cache the double-signed offline receipt data and the first signature digest data as evidence package data.

[0022] Step S4: At the end of the responsibility segment, parse the evidence package data and make a segment compliance judgment on the segment event data based on the responsibility segment contract data, output the segment compliance conclusion data, and encapsulate the responsibility segment identifier data, batch identifier data, segment compliance conclusion data and segment evidence summary data into responsibility segment proof transaction data and broadcast it to the blockchain.

[0023] Step S5: After the blockchain confirms the consensus on the transaction data of the liability fragment proof, it triggers the execution of the liability fragment contract data. Based on the compliance conclusion data of the fragment, it generates fund processing instruction data, which includes release instruction data, freeze instruction data, penalty instruction data and claim trigger instruction data. The fund processing instruction data is then written into the blockchain.

[0024] Step S6: Upon receiving a dispute triggering request, locate the evidence package data based on the fragment evidence summary data and output the evidence data according to the disclosure rules. Write the evidence data into the blockchain and output the adjudication result data. Update the fund processing instruction data based on the adjudication result data.

[0025] This invention targets high-concurrency and weak-network scenarios in the nationwide agricultural product cold chain. It encapsulates massive fragment event data off-chain into fragment evidence summary data and evidence package data, while only processing responsibility fragment proof transaction data on-chain. This achieves low cost and high throughput. Double-signed offline receipt data ensures that evidence is verifiable and non-repudiable during network outages, avoiding disputes caused by subsequent re-transmission. The responsibility fragment contract automatically generates fund processing instruction data based on the fragment compliance conclusion data, completing the linkage of release, freezing, deduction, and compensation. Combined with the cargo damage risk prediction model, it outputs risk level, supporting refined governance and on-demand disclosure of evidence.

[0026] This embodiment uses the cold chain supply chain of agricultural products as a scenario: after batches are harvested and pre-cooled at the production area cooperative, they are handed over at the purchasing station, temporarily stored in cold storage, transported by trunk cold chain, distributed in cities, and stored in supermarkets. The participants in this invention include responsible entities (shipping entity, carrier entity, warehousing entity, receiving entity), witnessing entities (testing agency, cold storage access control gateway, service area gateway), and blockchain nodes (consortium blockchain ledger nodes). The goal of the method is not to put every piece of temperature data on the chain, but to divide the supply chain into responsible segments according to the handover nodes, and to calculate the massive number of segment events into responsible segment compliance conclusions and verifiable transactions on the chain, so that evidence can still be verified even under weak network conditions, and compliance conclusions can directly trigger liquidation, penalties, and compensation.

[0027] Step S1 includes the following sub-steps: Step S101: Obtain batch identification data. The batch identification data is used to uniquely identify agricultural product batches.

[0028] In step S101, the business system generates batch identification data BatchID for each batch of agricultural products and binds it with product information (category, packaging specifications, target temperature zone, maximum transportation time).

[0029] Step S102: Obtain the responsible entity data, which includes the shipper identifier, carrier identifier, warehousing entity identifier, and consignee identifier.

[0030] In step S102, data of the responsible entities are collected, including at least the identifiers of the shipping entity, the carrier entity, the warehousing entity, and the receiving entity, and a blockchain address and signature key pair are assigned to each entity.

[0031] Step S103: Obtain fragment rule data, which includes environmental threshold rules, seal consistency rules, sampling inspection qualification rules, and liquidation rules.

[0032] In step S103, a fragment rule data Rule is constructed, including environmental threshold rules, seal consistency rules, random inspection qualification rules, and settlement rules. Among them, the environmental threshold rules are represented by the allowable temperature zone, the allowable cumulative duration of temperature exceedance, and the allowable temperature fluctuation intensity; the seal consistency rules are represented by the seal identifier remaining unchanged and the unpacking event being witnessed and signed; the random inspection qualification rules are represented by the random inspection conclusion being marked as qualified and the random inspection agency being marked as being in the whitelist; and the settlement rules are represented by compliant release, minor non-compliance penalty, and serious non-compliance freezing and triggering claims.

[0033] Step S104: Divide responsibility segments based on the data of the responsible subject, generate responsibility segment identification data, and write the responsibility segment identification data and segment rule data into the blockchain to form responsibility segment contract data.

[0034] In step S104, the supply chain process of BatchID is divided into several responsibility segments based on the data of the responsible entity, responsibility segment identification data SegmentID is generated, and Rule is bound to SegmentID and written into the blockchain to form responsibility segment contract data Contract(SegmentID).

[0035] To ensure that subsequent judgments are quantifiable, this embodiment defines the key parameters in the environmental threshold rules as follows: Let the target temperature range be an interval. The sampling interval is Sampling within the fragment The sub-temperature sequence is .

[0036] Define the over-temperature indication function: ; The cumulative duration of overheating is: ; And define the intensity of temperature fluctuations (to identify quality degradation caused by frequent fluctuations): ; The compliance threshold is and ,in , It is given by the Rule and is configurable with the category.

[0037] Step S2 includes the following sub-steps: Step S201: Collect handover event data, which includes the handover initiation time, handover completion time, the main body identifiers of the handover parties, and the handover location identifier.

[0038] In step S201, at the beginning and end of each responsibility segment, both parties collect handover event data via mobile terminals. This includes the handover initiation time, handover completion time, handover location identifier, and the main identifiers of both parties involved in the handover, as well as the BatchID / SegmentID.

[0039] Step S202: Collect seal event data, which includes seal identifier, seal scanning time, and seal scanning subject identifier.

[0040] In step S202, seal event data S is collected during the scanning of packing seals and warehousing seals, including seal identifier SealID, seal scanning time and scanning subject identifier.

[0041] Step S203: Collect sampling event data, which includes the sampling agency identifier, sampling time, and sampling conclusion identifier.

[0042] In step S203, the testing agency collects sampling event data Q at the sampling point, including the sampling agency identifier, sampling time, and sampling conclusion identifier Result.

[0043] Step S204: Collect environmental event data, including temperature data, humidity data, and vibration data.

[0044] In step S204, environmental event data is collected by a temperature and humidity recorder and a vibration sensor during segment execution. Including temperature sequences , humidity sequence With vibration sequence And the corresponding timestamp, where vibration is used to identify rough handling, and a vibration energy index is defined: ; And set in the Rule Optional constraints.

[0045] Step S205: Construct fragment evidence digest data from fragment event data, and sign the fragment evidence digest data based on the private key of the responsible party, outputting the first signature digest data.

[0046] The fragment evidence summary data is constructed as follows: The event fragment data is grouped according to a preset time window to obtain several event window data.

[0047] Calculate the event window summary value for each event window data. The event window summary value is the hash value of the event window data.

[0048] Several event window summary values ​​are concatenated in chronological order to generate a summary chain data.

[0049] Calculate the root digest value for the digest chain data. The root digest value is the hash value of the digest chain data.

[0050] The root digest value is combined with the responsible fragment identifier data and batch identifier data to output fragment evidence digest data.

[0051] In step S205, the original sequences of H, S, Q, and E are not directly added to the chain, but are instead processed according to a preset time window. Fragment event data is grouped into event window data. A digest value for each event window is calculated and concatenated chronologically to form a digest chain. The root digest value, RootHash, is then calculated for the digest chain. Finally, the RootHash is combined with the BatchID, SegmentID, and fragment start and end times to form the fragment evidence digest data, Digest. The responsible party then signs the Digest using their private key to obtain the first signed digest data, Sig1(Digest). This Digest is subsequently used for on-chain verification of evidence consistency, while Sig1(Digest) is used for non-repudiation.

[0052] Step S3 includes the following sub-steps: Step S301: Determine the offline triggering conditions. The offline triggering conditions include network unavailability and on-chain submission failure.

[0053] In step S301, the terminal determines the offline triggering conditions in real time, including network unavailability or blockchain submission failure; if triggered, the offline receipt process begins.

[0054] Step S302: Generate offline receipt data, which includes responsibility segment identifier data, batch identifier data, segment evidence summary data, and receipt timestamp data.

[0055] In step S302, the responsible entity generates offline receipt data Receipt based on Sig1 (Digest) and key milestone events (handover, unpacking, spot check, phase end). The Receipt includes at least BatchID, SegmentID, receipt timestamp, RootHash, and receipt type identifier.

[0056] Step S303: Obtain the witness subject's signature. The witness subject's signature is the witness subject's signature on the offline receipt data. Output the double-signed offline receipt data.

[0057] In step S303, the witness signature Sig2(Receipt) is obtained. The witness can be a cold storage access control gateway, a service area gateway, or a testing agency terminal. Its signature key is pre-registered in the blockchain whitelist. The dual-signature offline receipt data DualReceipt={Receipt,Sig1(Digest),Sig2(Receipt)} is formed.

[0058] Step S304: Encapsulate the dual-signature offline receipt data and the first signature digest data into evidence package data, and cache the evidence package data in local storage.

[0059] In step S304, the DualReceipt, along with the event window summary chain data within the fragment and the original records of key events (such as unpacking image hash and sampling order number hash), are encapsulated into an evidence package data EvidencePack and cached. Since the DualReceipt contains both the signature of the responsible party and the signature of the witnessing party, even if it is re-transmitted after a network outage, it can still be verified that it was generated at the time and has not been tampered with.

[0060] This embodiment provides the logic for verifying the verifiability of offline receipts: When verifying Sig2(Receipt) on the blockchain, the public key of the witness subject's whitelist is first read from the blockchain. ,verify: ; Re-verify the responsible party's signature on the Digest document: ; If both conditions are met, then DualReceipt is reliable.

[0061] Step S4 includes the following sub-steps: Step S401: Analyze the evidence package data and extract the responsibility fragment identifier data, batch identifier data, fragment evidence summary data, and fragment event data.

[0062] In step S401, when the responsibility segment ends, the EvidencePack is parsed, and the BatchID, SegmentID, Digest, segment event data and DualReceipt (if they exist) are extracted. Integrity verification is performed: the RootHash′ is recalculated on the event window digest chain data, and it is determined that the RootHash′ is consistent with the RootHash in the Digest to confirm that the segment event data has not been replaced.

[0063] Step S402, Perform fragment compliance determination: Compare the environmental event data with the environmental threshold rules and output the environmental compliance identifier.

[0064] The system compares the seal event data with the seal consistency rules and outputs a seal compliance indicator. It also compares the sampling event data with the sampling compliance rules and outputs a sampling compliance indicator.

[0065] In step S402, a fragment compliance determination is performed: environmental event data is processed. temperature sequence Substitute into step S1 , The formula yields the cumulative duration of overheating and the intensity of the fluctuation, and is compared with the rule. , Environmental compliance identifiers are obtained by comparison; the SealID sequence of the seal event data S is compared with the seal consistency rules of the Rule to obtain the seal compliance identifier; the Result of the sampling event data Q is compared with the sampling agency identifier and the Rule to obtain the sampling compliance identifier; vibration energy index... and Comparison yields loading and unloading compliance markings.

[0066] Step S403: Merge and output the fragment compliance conclusion data. The fragment compliance conclusion data is the fusion result of environmental compliance label, seal compliance label and sampling inspection compliance label.

[0067] In step S403, the compliance conclusion data of the fused output fragments is determined as follows: when the environmental compliance label, the seal compliance label, and the sampling inspection compliance label are all compliant, the conclusion is compliant; when any non-compliance exists, the conclusion is determined as minor non-compliance or serious non-compliance according to the liquidation rules.

[0068] This embodiment further establishes a cargo damage risk prediction model in step S403 to predict the impact of this segment on quality and drive the penalty intensity and claim triggering. The model input is a non-existent derived data vector. ,include , , Number of times the box was opened Inspection conclusion code and transportation time ,in This data was obtained from statistics on sealing and unpacking events. The damage risk is determined by mapping the sampling inspection results. The cargo damage risk prediction model uses logistic regression to output the cargo damage risk probability. : ; ; The model training data comes from fragmented event data of historical batches and actual cargo damage labels. (For example, a score of 1 is given for items that fail in-store inspection or are returned), and the system is trained using cross-entropy loss: ; After training, the hash value of the sum is written to the blockchain as the model version identifier ModelHash, and the currently available model version identifier is registered in the responsibility fragment contract data. During prediction, the non-existent derived data vector of the current fragment is used. Input Get And generate risk level data RiskLevel: when For low risk, when As medium risk, when High risk, among which , For Rule parameters. Finally, the index information of BatchID, SegmentID, Conclusion, RiskLevel, Digest, Sig1(Digest) and DualReceipt (if it exists) is encapsulated into ProofTx, a responsibility fragment proof transaction data, and broadcast to the blockchain.

[0069] Step S404: Generate the responsibility fragment proof transaction data and broadcast the responsibility fragment proof transaction data to the blockchain.

[0070] Step S5 includes the following sub-steps: Step S501, parse the compliance conclusion data of the fragment: If the fragment compliance conclusion data is compliant, then release instruction data is generated and written to the blockchain.

[0071] If the data in the fragment compliance conclusion is non-compliant, then freeze instruction data is generated and written to the blockchain.

[0072] In step S501, after the blockchain consensus confirms ProofTx, the Contract(SegmentID) is executed, resolving the Conclusion and RiskLevel. If the Conclusion is compliant, a ReleaseCmd instruction is generated to release the corresponding freight or storage fees for that segment and advance the batch status. If the Conclusion is non-compliant, a FreezeCmd instruction is generated to freeze the relevant funds.

[0073] Step S502: Calculate penalty instruction data when the fragment compliance conclusion data is non-compliant: The penalty amount is calculated based on the settlement rules, and the penalty amount is encapsulated into penalty instruction data and written to the blockchain.

[0074] In step S502, when the Conclusion is non-compliant, the penalty amount data PenaltyAmount is calculated: In this embodiment, the penalty is divided into rule-based penalty and risk-based penalty. Rule-based penalty is directly related to the duration of overheating, the number of abnormal seals, etc., while risk-based penalty is related to... Correlation. Provide a reproducible penalty formula: ; in , , and Both the BaseFee and the Rule are given and written into the contract to avoid disputes later.

[0075] Step S503: Generate claim trigger instruction data when the fragment compliance conclusion data meets the claim conditions: Based on the claim conditions in the settlement rules, the claim trigger instruction data is output and written to the blockchain.

[0076] Dispute triggering requests include: Data on dispute requests and grounds for dispute submitted by the responsible party.

[0077] After receiving the dispute request data, the blockchain freezes the fund processing instruction data corresponding to the liability segment identifier data and outputs the evidence request data, which is used to request the provision of evidence data in the evidence package data.

[0078] In step S503, if the claim conditions are met (e.g., the Conclusion is serious non-compliance or the Risk Level is high risk and the inspection conclusion is unqualified), the claim trigger instruction data ClaimCmd is generated and written to the blockchain; the insurer only needs to verify the Digest and signature and contract threshold conditions in ProofTx to trigger the claim process, without needing to obtain the complete temperature curve, thereby achieving privacy control.

[0079] Step S6 includes the following sub-steps: Step S601: Locate the evidence package data based on the fragment evidence digest data, and perform integrity verification on the evidence package data. The integrity verification verifies that the fragment evidence digest data in the evidence package data is consistent with the fragment evidence digest data already stored in the blockchain.

[0080] In step S601, when the responsible party initiates a dispute triggering request, the contract freezes the relevant funds processing instructions and issues EvidenceReq, which specifies the time range and field range that need to be disclosed.

[0081] Step S602: Generate evidence data according to the disclosure rules. The disclosure rules are used to limit the time range and data field range of the evidence data.

[0082] In step S602, a subset of fragment event data that satisfies EvidenceReq is extracted from EvidencePack as EvidenceData, and the digest value of EvidenceData is recalculated to prove that it comes from the evidence package corresponding to Digest, thus ensuring that the evidence data is verifiable.

[0083] Step S603: Write the evidence data into the blockchain and output the adjudication result data.

[0084] In step S603, the summary of EvidenceData and access authorization information are written into the blockchain and the adjudication result data Verdict is output.

[0085] Step S604: Update the fund processing instruction data based on the adjudication result data. The update includes replacing the freeze instruction data with release instruction data or penalty instruction data.

[0086] In step S604, the contract updates the funds processing instruction data based on Verdict, replaces the freeze instruction with a release or penalty / claim instruction, and completes the final settlement.

[0087] Example 2, refer to Figure 2 This paper provides a blockchain-based transaction processing system, including a fragment contract construction module, a summary data generation module, an acceptance data generation module, a transaction data generation module, a conditional settlement processing module, and an evidence adjudication execution module.

[0088] The segment contract construction module is used to obtain batch identification data, responsible entity data, and segment rule data. Based on the responsible entity data, the supply chain process corresponding to the batch identification data is divided into several responsible segments, generating responsible segment identification data. The segment rule data is written into the blockchain and bound to the responsible segment identification data to form responsible segment contract data.

[0089] The summary data generation module is used to collect segment event data within the responsibility segment. The segment event data includes handover event data, sealing event data, sampling event data, and environmental event data. It constructs a summary of the segment event data, outputs segment evidence summary data, and signs the segment evidence summary data with the responsible party, outputting the first signature summary data.

[0090] The acceptance data generation module is used to generate offline receipt data based on the first signature digest data when the offline triggering conditions are met, obtain the witness subject's signature, output double-signed offline receipt data, and cache the double-signed offline receipt data and the first signature digest data as evidence package data.

[0091] The transaction data generation module is used to parse the evidence package data at the end of the responsibility segment and make a segment compliance determination on the segment event data based on the responsibility segment contract data, output segment compliance conclusion data, encapsulate the responsibility segment identifier data, batch identifier data, segment compliance conclusion data and segment evidence summary data into responsibility segment proof transaction data and broadcast it to the blockchain.

[0092] The conditional settlement processing module is used to trigger the execution of the liability fragment contract data after the blockchain confirms the consensus on the liability fragment proof transaction data. Based on the compliance conclusion data of the fragment, it generates fund processing instruction data, which includes release instruction data, freeze instruction data, penalty instruction data and claim trigger instruction data, and writes the fund processing instruction data into the blockchain.

[0093] The evidence submission and adjudication execution module is used to locate the evidence package data based on the fragment evidence summary data and output the evidence data according to the disclosure rules when a dispute triggering request is received. The evidence data is written to the blockchain and the adjudication result data is output. The fund processing instruction data is updated based on the adjudication result data.

[0094] This method uses the responsibility fragment proof transaction data as the on-chain transaction object, and constructs fragment event data into fragment evidence summary data and evidence package data off-chain. On-chain, only fragment compliance conclusion data, fragment evidence summary data and signature receipt index are processed. This avoids the transaction explosion caused by uploading environmental event data such as handover, temperature and humidity, and vibration to the chain one by one, significantly reducing the cost of uploading to the chain and the consensus pressure, and enabling stable operation in multiple batches of concurrent scenarios across the country.

[0095] By generating offline receipt data under offline trigger conditions and obtaining the witness's signature to form double-signed offline receipt data, it is ensured that when the network is unavailable, such as in cold storage at the place of origin or during trunk transportation, key milestones can still form verifiable credentials generated at that moment. When the data is re-uploaded to the chain afterward, signature verification and digest consistency verification can be used to confirm that it has not been tampered with, thus solving the core pain point of traditional solutions where data is missing or the authenticity of re-uploaded data is difficult to prove during network outages.

[0096] This method solidifies the segment rule data and settlement rules in the responsibility segment contract data, and automatically generates fund processing instruction data based on the segment compliance conclusion data. It realizes the on-chain automatic execution of instructions for releasing, freezing, deducting, and triggering claims for freight and storage fees, reduces the cost of manual reconciliation and disputes, and improves the efficiency of dispute resolution. It is especially suitable for cold chain businesses with high fresh food spoilage and sensitive responsibility division.

[0097] By calculating derived data such as the cumulative duration of overheating, the intensity of temperature fluctuations, and vibration energy indicators from environmental event data, and inputting them into the cargo damage risk prediction model, the model outputs cargo damage risk probability and risk level data. This ensures that the intensity of penalties and the triggering of claims not only depend on whether the threshold is exceeded, but also reflect the degree of risk. At the same time, the model version identifier is written into the blockchain to ensure that the prediction process is traceable, reproducible, and auditable.

[0098] The blockchain primarily uses fragmented evidence summaries and conclusions, with complete fragmented event data not being publicly disclosed by default. Evidence data is then output according to disclosure rules and consistency verification is performed when disputes arise or regulatory requirements are needed. This achieves on-demand disclosure that is verifiable and tamper-proof, satisfying the requirements of insurance companies, banks, and regulators for credible triggering conditions while reducing the risk of leakage of commercially sensitive data.

[0099] By standardizing liability boundaries, threshold rules, and settlement logic through liability fragment contracts, rule discrepancies in cross-enterprise collaboration are reduced. Offline receipt and evidence package caching mechanisms ensure uninterrupted business operations. Once the network is restored, on-chain rights confirmation and settlement can still be completed, thereby improving the overall stability and collaborative efficiency of large-scale cold chain networks.

[0100] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

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

Claims

1. A blockchain-based method for processing agricultural product transactions, characterized in that, Includes the following steps: Step S1: Obtain batch identification data, responsible entity data, and segment rule data. Based on the responsible entity data, divide the supply chain process corresponding to the batch identification data into several responsible segments, generate responsible segment identification data, write the segment rule data into the blockchain and bind it with the responsible segment identification data to form responsible segment contract data. Step S2: Collect event data within the responsible segment. The event data includes handover event data, sealing event data, sampling event data, and environmental event data. Construct a summary of the event data, output the segment evidence summary data, and sign the segment evidence summary data with the responsible party to output the first signature summary data. Step S3: When the offline triggering condition is met, generate offline receipt data based on the first signature digest data, obtain the witness subject's signature, output double-signed offline receipt data, and cache the double-signed offline receipt data and the first signature digest data as evidence package data. Step S4: At the end of the responsibility segment, parse the evidence package data and make a segment compliance judgment on the segment event data based on the responsibility segment contract data, output the segment compliance conclusion data, and encapsulate the responsibility segment identifier data, batch identifier data, segment compliance conclusion data and segment evidence summary data into responsibility segment proof transaction data and broadcast it to the blockchain; Step S5: After the blockchain confirms the consensus on the transaction data of the liability fragment proof, it triggers the execution of the liability fragment contract data. Based on the compliance conclusion data of the fragment, it generates fund processing instruction data, which includes release instruction data, freeze instruction data, penalty instruction data and claim trigger instruction data. The fund processing instruction data is then written into the blockchain. Step S6: Upon receiving a dispute triggering request, locate the evidence package data based on the fragment evidence summary data and output the evidence data according to the disclosure rules. Write the evidence data into the blockchain and output the adjudication result data. Update the fund processing instruction data based on the adjudication result data.

2. The method for processing agricultural product transactions based on blockchain as described in claim 1, characterized in that, Step S1 includes the following sub-steps: Step S101: Obtain batch identification data, which is used to uniquely identify agricultural product batches; Step S102: Obtain the responsible entity data, which includes the shipper identifier, carrier identifier, warehousing entity identifier, and consignee identifier; Step S103: Obtain fragment rule data, which includes environmental threshold rules, seal consistency rules, sampling inspection qualification rules, and settlement rules; Step S104: Divide responsibility segments based on the data of the responsible subject, generate responsibility segment identification data, and write the responsibility segment identification data and segment rule data into the blockchain to form responsibility segment contract data.

3. The method for processing agricultural product transactions based on blockchain as described in claim 2, characterized in that, Step S2 includes the following sub-steps: Step S201: Collect handover event data, which includes handover initiation time, handover completion time, entity identifiers of both parties, and handover location identifier; Step S202: Collect seal event data, which includes seal identifier, seal scanning time, and seal scanning subject identifier; Step S203: Collect sampling event data, which includes the sampling agency identifier, sampling time, and sampling conclusion identifier; Step S204: Collect environmental event data, including temperature data, humidity data, and vibration data; Step S205: Construct fragment evidence digest data from fragment event data, and sign the fragment evidence digest data based on the private key of the responsible party, and output the first signature digest data.

4. The blockchain-based agricultural product transaction processing method as described in claim 3, characterized in that, The fragment evidence summary data is constructed as follows: The event fragment data is grouped according to a preset time window to obtain several event window data; For each event window data, an event window summary value is calculated, where the event window summary value is the hash value of the event window data; Generate a summary chain data by concatenating the summary values ​​of several event windows in chronological order; Calculate the root digest value for the digest chain data, where the root digest value is the hash value of the digest chain data; The root digest value is combined with the responsible fragment identifier data and batch identifier data to output fragment evidence digest data.

5. The blockchain-based agricultural product transaction processing method as described in claim 4, characterized in that, Step S3 includes the following sub-steps: Step S301: Determine the offline triggering conditions, which include network unavailability and on-chain submission failure conditions; Step S302: Generate offline receipt data, which includes responsibility segment identifier data, batch identifier data, segment evidence summary data, and receipt timestamp data; Step S303: Obtain the witness subject signature, which is the witness subject's signature on the offline receipt data, and output the double-signed offline receipt data; Step S304: Encapsulate the dual-signature offline receipt data and the first signature digest data into evidence package data, and cache the evidence package data in local storage.

6. The blockchain-based agricultural product transaction processing method as described in claim 5, characterized in that, Step S4 includes the following sub-steps: Step S401: Parse the evidence package data and extract the responsibility fragment identifier data, batch identifier data, fragment evidence summary data, and fragment event data; Step S402, Perform fragment compliance determination: Compare the environmental event data with the environmental threshold rules and output the environmental compliance identifier; The data on sealed events is compared with the rules for consistency of sealed events, and a seal compliance mark is output; the data on random inspection events is compared with the rules for passing random inspections, and a random inspection compliance mark is output. Step S403: Merge and output the fragment compliance conclusion data, wherein the fragment compliance conclusion data is the fusion result of environmental compliance mark, seal compliance mark and sampling inspection compliance mark; Step S404: Generate the responsibility fragment proof transaction data and broadcast the responsibility fragment proof transaction data to the blockchain.

7. The method for processing agricultural product transactions based on blockchain as described in claim 6, characterized in that, Step S5 includes the following sub-steps: Step S501, parse the compliance conclusion data of the fragment: If the fragment compliance conclusion data is compliant, then release instruction data is generated and written to the blockchain; If the data from the segment is deemed non-compliant, a freeze order will be generated and written to the blockchain. Step S502: Calculate penalty instruction data when the fragment compliance conclusion data is non-compliant: The penalty amount data is calculated based on the settlement rules, and the penalty amount data is encapsulated into penalty instruction data and written into the blockchain. Step S503: Generate claim trigger instruction data when the fragment compliance conclusion data meets the claim conditions: Based on the claim conditions in the settlement rules, the claim trigger instruction data is output and written to the blockchain.

8. The method for processing agricultural product transactions based on blockchain as described in claim 7, characterized in that, The dispute triggering request includes: Data on the dispute requests and grounds for dispute submitted by the responsible party; After receiving the dispute request data, the blockchain freezes the fund processing instruction data corresponding to the liability segment identifier data and outputs the evidence request data, which is used to request the provision of evidence data in the evidence package data.

9. The blockchain-based agricultural product transaction processing method as described in claim 8, characterized in that, Step S6 includes the following sub-steps: Step S601: Locate the evidence package data based on the fragment evidence digest data, and perform integrity verification on the evidence package data. The integrity verification is to verify that the fragment evidence digest data in the evidence package data is consistent with the fragment evidence digest data already stored in the blockchain. Step S602: Generate evidence data according to disclosure rules, wherein the disclosure rules are used to limit the time range and data field range of the evidence data; Step S603: Write the evidence data into the blockchain and output the adjudication result data; Step S604: Update the fund processing instruction data based on the adjudication result data. The update includes replacing the freeze instruction data with release instruction data or penalty instruction data.

10. A blockchain-based transaction processing system, applied in a blockchain-based agricultural product transaction processing method as described in any one of claims 1-9, characterized in that, It includes a fragment contract construction module, a summary data generation module, an acceptance data generation module, a transaction data generation module, a conditional settlement processing module, and an evidence adjudication execution module; The segment contract construction module is used to obtain batch identification data, responsible entity data and segment rule data. Based on the responsible entity data, the supply chain process corresponding to the batch identification data is divided into several responsible segments, responsible segment identification data is generated, and segment rule data is written into the blockchain and bound to the responsible segment identification data to form responsible segment contract data. The summary data generation module is used to collect segment event data within the responsibility segment. The segment event data includes handover event data, seal event data, sampling event data, and environmental event data. The module constructs a summary of the segment event data, outputs segment evidence summary data, and signs the segment evidence summary data with the responsible party, outputting first signature summary data. The acceptance data generation module is used to generate offline receipt data based on the first signature digest data when the offline triggering conditions are met, obtain the witness subject's signature, output double-signed offline receipt data, and cache the double-signed offline receipt data and the first signature digest data as evidence package data. The transaction data generation module is used to parse the evidence package data at the end of the responsibility segment and make a segment compliance judgment on the segment event data based on the responsibility segment contract data, output segment compliance conclusion data, encapsulate the responsibility segment identifier data, batch identifier data, segment compliance conclusion data and segment evidence summary data into responsibility segment proof transaction data and broadcast it to the blockchain; The conditional settlement processing module is used to trigger the execution of the liability fragment contract data after the blockchain confirms the consensus on the liability fragment proof transaction data, and to generate fund processing instruction data based on the fragment compliance conclusion data. The fund processing instruction data includes release instruction data, freeze instruction data, penalty instruction data and claim trigger instruction data, and writes the fund processing instruction data into the blockchain. The evidence presentation and adjudication execution module is used to locate the evidence package data based on the fragment evidence summary data and output the evidence data according to the disclosure rules when a dispute triggering request is received, write the evidence data into the blockchain and output the adjudication result data, and update the fund processing instruction data based on the adjudication result data.

Images