Online trade logistics trusted transaction method based on smart contract

Abstract

This invention discloses a trusted online trade logistics transaction method based on smart contracts, relating to the fields of blockchain and smart contract technology. Within the trusted execution environment isolation zone of a logistics edge gateway, spatiotemporal cross-consistency verification is performed on three types of heterogeneous data: RFID, GPS, and environmental sensors. A comprehensive confidence score is calculated through geofence comparison, vibration velocity correlation verification, and temperature mutation area association verification. After successful verification, a hardware-derived private key is used to sign the data within the trusted execution environment, and a trusted data proof report is uploaded to the blockchain. This cuts off the data forgery path from the physical source. The logistics trade smart contract is constructed as a finite state machine, with a pre-set force majeure delay sub-state. When the force majeure event verified by zero-knowledge proof meets the preset conditions, the contract state machine automatically jumps and recalculates the delivery deadline and related costs, achieving automatic adjustment of the contract execution path.

Description

Technical Field

[0001] This invention relates to the field of blockchain and smart contract technology, and specifically to a trusted online trade logistics transaction method based on smart contracts. Background Technology

[0002] With the continuous expansion of cross-border e-commerce and digital trade, the issues of trust costs and collaboration efficiency in the logistics supply chain are becoming increasingly prominent. Blockchain technology, with its decentralized, immutable, and traceable characteristics, is regarded by academia and industry as the core infrastructure for reconstructing the logistics trust system. Smart contracts are self-executing programs that run on the blockchain. Their terms are fixed in the form of code and are automatically invoked and executed when preset trigger conditions are met, without human intervention. Typical implementation platforms include Ethereum, Hyperledger Fabric, and FISCO BCOS.

[0003] The closest existing technical solution to this invention is a logistics tracking and automatic settlement system with IoT data, blockchain, and smart contracts as its core architecture. Representative implementations include the following two types:

[0004] The first type is a logistics status on-chain system based on manual operation terminals. The basic approach is as follows: logistics operators use handheld data terminals to perform radio frequency identification scanning or manually enter the status of goods at the goods handover node, and then submit the logistics status data to the blockchain oracle node via the Internet. The oracle node writes the data into the blockchain without verification. After the on-chain smart contract listens for the logistics status update event, it executes the release of payment or calculation of late payment penalties according to preset rules. In this scheme, the authenticity of the data depends entirely on the integrity of the operator, and there is no technical guarantee mechanism for the credibility of off-chain data.

[0005] The second type is a multi-data source aggregation and on-chain system based on a decentralized oracle network. Its basic approach is as follows: multiple independent oracle nodes obtain logistics status data from different data providers, aggregate the multiple data sources through threshold consensus, and submit the aggregated value to the blockchain. Smart contracts execute contract logic based on the on-chain data. Although this solution introduces a multi-data source redundancy mechanism, its data source is still a centralized data provider, and it lacks a hardware-level verification mechanism for the authenticity of physical sensor data, making it unable to prevent collective fraud by data providers or interface data pollution attacks.

[0006] The existing solutions described above have three fundamental technical flaws:

[0007] First, there is a fundamental break in the trust chain of oracles. In existing solutions, whether it is a manual terminal solution or a decentralized oracle aggregation solution, the data collection process is located outside the trust boundary of the blockchain and is not protected by the blockchain. Existing solutions do not establish an unforgeable technical barrier at the first scene where data is converted from the physical world into digital signals, i.e., at the sensor hardware level. As a result, once fake data is forged off-chain and put on the blockchain, smart contracts will automatically execute erroneous settlements on the basis of the tamper-proof fake data, forming a reverse effect where the more tamper-proof the blockchain is, the greater the harm of fake data.

[0008] Secondly, the contract execution lacks adaptive correction capabilities. The code logic of smart contracts deployed on the blockchain is fixed and can only be executed according to a single deterministic path. When objective force majeure occurs in the logistics link, the contract cannot identify the essential difference between objective forced delay and subjective breach of contract, treats the two as the same, and automatically deducts liquidated damages, which directly leads to unfair economic losses to the non-breaching party and the loss of the disintermediation value of smart contracts.

[0009] Third, the openness of on-chain data and the need for commercial privacy are fundamentally contradictory. The publicly verifiable ledger feature of blockchain is fundamentally contradictory to the highly sensitive commercial data in logistics and trade. Existing simple hash-based on-chain solutions can only verify data integrity, but cannot prove to smart contracts that the data meets a certain condition while concealing the original data, thus creating a dilemma of choosing between privacy and automation. Summary of the Invention

[0010] The purpose of this invention is to provide a trusted online trade and logistics transaction method based on smart contracts, in order to solve the three core technical problems existing in the prior art: off-chain forgery of logistics data, rigid contract execution that cannot adapt to force majeure, and leakage of commercial privacy under multi-party participation.

[0011] The technical solution adopted in this invention is as follows:

[0012] A trusted online trade logistics transaction method based on smart contracts includes the following steps:

[0013] Within the trusted execution environment isolation zone of the logistics edge gateway, multi-source spatiotemporal cross-consistency verification is performed on three types of heterogeneous data from RFID readers, GPS modules, and environmental sensor groups. This includes timestamp synchronization verification, geofence compliance comparison, vibration and speed correlation verification, and temperature change and geographical area association verification. After the verification is passed, a hardware-derived private key is used to generate a hardware-level signature within the trusted execution environment, and a trusted data proof report containing the signature is submitted to the blockchain data verification contract.

[0014] The logistics and trade smart contract is constructed as a finite state machine with conditional jumps. In addition to the normal performance state path, a force majeure extension sub-state is preset. When the contract receives a force majeure event certificate verified by zero-knowledge proof, the contract state machine automatically jumps to the force majeure extension sub-state and recalculates the delivery deadline and related costs according to preset parameters. After the force majeure is lifted, it automatically returns to the main performance path.

[0015] Logistics participants use sensitive data such as cargo electronic codes, real GPS coordinates, receipt timestamps, and payment amounts as private witnesses off-chain. They combine this data with publicly available inputs on-chain to generate zero-knowledge proofs, which are then submitted to an on-chain zero-knowledge proof verification contract. The contract only verifies the validity of the proof and triggers corresponding finite state machine state transitions and fund transfer instructions. The original sensitive data is not recorded on-chain.

[0016] The specific process of multi-source spatiotemporal cross-consistency verification in the above technical solution is as follows:

[0017] After receiving the RFID data stream, GPS data stream, and environmental sensor data stream in the Trusted Execution Environment Security Zone, the system first performs a synchronization check on the timestamps of the three data streams. It calculates the absolute value of the difference between each pair of the three timestamps. If all differences meet the preset maximum allowable timestamp deviation threshold, the synchronization check is passed; otherwise, it is judged as a timing anomaly and the data packet is discarded.

[0018] Based on the physical location of the RFID reading point, a legal geofence polygon associated with the reading point is predefined during the contract initialization phase. A ray casting algorithm is executed on the GPS coordinates to determine whether the coordinate point is located inside the fence. If the coordinate falls outside the fence, it is determined to be a spatial inconsistency anomaly.

[0019] If the sensor's vibration acceleration exceeds the static threshold, the carrier's velocity should simultaneously be greater than the minimum motion velocity threshold; otherwise, the vibration source is considered abnormal.

[0020] If the temperature change compared to the previous recorded value exceeds the preset mutation threshold, it is verified whether the current GPS coordinates fall within the pre-registered set of compliant temperature change areas. If the coordinates are not within the set, it is determined that the source of the temperature mutation is abnormal.

[0021] Based on geofence anomaly markers, vibration velocity anomaly markers, and temperature change anomaly markers, a weighted calculation is performed according to configurable penalty weights to obtain a comprehensive confidence score. When the comprehensive confidence score is not lower than a preset trust threshold, the data packet is determined to have passed the trust verification. When it is lower than the threshold, the abnormal data packet is reported to the blockchain data verification contract to trigger the manual review process.

[0022] The formula for calculating the overall confidence score is:

[0023] ;

[0024] in, The overall confidence score ranges from [0, 100], with higher scores indicating higher data reliability.

[0025] , , These are the penalty weights corresponding to geofence anomalies, vibration anomalies, and temperature change anomalies, respectively, satisfying... ;

[0026] , , All are binary anomaly markers with values ​​belonging to {0,1}, where the value is 1 when an anomaly occurs and 0 when a normal anomaly occurs.

[0027] In the above technical solution, the specific process of finite state machine contract state transition is as follows:

[0028] During the contract deployment phase, the buyer and seller register several certified external data source interface addresses in the contract through a multi-party joint signature mechanism. Each data source is associated with a force majeure event type identifier and its corresponding exemption parameter template, which includes the maximum allowed number of days of delay and the demurrage fee reduction ratio.

[0029] When any contract participant believes that a force majeure event has occurred, it shall initiate an exemption application and attach objective event proof data submitted in the form of zero-knowledge proof from at least two registered data sources, as well as a trusted data report on the current location and status of the goods collected through the trusted execution environment gateway.

[0030] After receiving an exemption application, the on-chain finite state machine contract calls zero-knowledge proof to verify the submitted event proof of the pre-compiled contract, checks whether the hardware signature in the trusted data report is generated by a registered compliant trusted execution environment device, and matches the event type with the preset exemption triggering conditions in the contract. After all three items are verified, the contract state machine automatically jumps to the force majeure extension sub-state.

[0031] After entering the force majeure extension sub-state, the contract automatically recalculates the postponed final delivery deadline and related costs based on preset parameters. Once the force majeure event is resolved and verified by multi-source zero-knowledge proof, the state machine returns to the corresponding state of the main path and permanently writes the recalculated parameters into the contract state storage.

[0032] The formula for calculating the postponed final delivery deadline is as follows:

[0033] ;

[0034] in, This is the extended final delivery deadline timestamp (Unix time, in seconds).

[0035] This is the original delivery deadline timestamp for the contract (Unix time, in seconds).

[0036] The actual number of days of impact reported by the event data source;

[0037] The maximum number of days of exemption allowed for this type of force majeure event is preset when the contract is deployed;

[0038] The constant 86400 represents the number of seconds per day.

[0039] In the above technical solution, the specific process of verifying the concealed status of logistics handover based on zero-knowledge proof is as follows:

[0040] Define a private witness vector, which includes the electronic code of the goods, the real GPS coordinates at the time of receipt, the receipt timestamp, and the amount of payment. All of the above data is kept off-chain.

[0041] Define a public input vector containing the goods identity commitment value, the upper and lower bounds of the valid receipt time window, the on-chain registration identifier of the target receipt area geofence, and the hash commitment value of the frozen payment amount. The above data is stored in plaintext in the on-chain contract state.

[0042] The proposition to be proved is decomposed into three arithmetic circuit constraints: the first constraint verifies that the commitment value generated by the combination of the electronic code of the goods and the random blinding factor in the private witness is equal to the commitment value of the goods identity stored on the chain;

[0043] The second constraint verifies that the receipt timestamp in the private witnessing process falls within the time window defined by the public input.

[0044] The third constraint verifies that the geographical coordinates in the private witness fall within the geofence identified by the on-chain registration identifier, which is implemented using the Merkel path verification method.

[0045] During the system initialization phase, the buyer, seller, and logistics regulator jointly perform a trusted initialization ceremony to generate a global public reference string containing a proof key and a verification key. The verification key is permanently written into the on-chain zero-knowledge proof verification contract when the contract is deployed.

[0046] After the handover event occurs, the party responsible for generating the proof generates a zero-knowledge proof off-chain based on the private witness, public input, and proof key. Then, the public input and the zero-knowledge proof are packaged and submitted to the zero-knowledge proof verification contract on the blockchain. The verification contract calls the pre-compiled bilinear pairing operation to perform the verification. After the verification is successful, the contract automatically triggers the corresponding finite state machine state transition and fund transfer instructions.

[0047] The beneficial effects of this invention are as follows:

[0048] 1. This invention establishes a multi-source spatiotemporal cross-consistency verification mechanism based on trusted execution environment hardware at the logistics edge node, cuts off the technical path of forged data on the chain at the sensor hardware level, enables on-chain logistics data to have hardware-level trusted endorsement, eliminates the trust gap of oracles, and provides a reliable data foundation for supply chain finance based on smart contracts.

[0049] 2. This invention transforms smart contracts into adaptive execution engines that support conditional jumps through a finite state machine architecture. Under the premise that the contract is immutable, it enables dynamic identification of objective force majeure events and automatic adjustment of the contract execution path, eliminating on-chain disputes caused by rigid contract execution, and making smart contracts practically valuable in complex real-world logistics scenarios.

[0050] 3. This invention, through a zero-knowledge proof mechanism, enables all participants to prove to the on-chain smart contract that the delivery conditions have been met while completely concealing sensitive business data, thus achieving a balance between trusted state transfer and absolute isolation of business privacy, and alleviating privacy concerns of business entities participating in blockchain logistics platforms. Attached Figure Description

[0051] Figure 1 This is a schematic diagram of the edge multi-source spatiotemporal cross-validation mechanism based on a trusted execution environment according to the present invention;

[0052] Figure 2 This is a schematic diagram of the adaptive dynamic exemption performance architecture based on a finite state machine according to the present invention;

[0053] Figure 3 This is a schematic diagram of the logistics handover status concealment verification network based on zero-knowledge proof according to the present invention. Detailed Implementation

[0054] The following is in conjunction with the appendix Figure 1-3 The specific embodiments of the present invention will be further described below. It should be noted that the description of these embodiments is for the purpose of helping to understand the present invention, but does not constitute a limitation of the present invention.

[0055] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0056] System Overall Architecture

[0057] The online trade logistics trusted transaction method based on smart contracts proposed in this invention consists of four core layers in its system architecture. The first layer is the physical sensing and trusted acquisition layer, which includes an RFID reader / writer, a GPS positioning module, and an environmental sensor group (including temperature and humidity sensors and vibration sensors). These three types of devices are connected to the logistics edge gateway hardware via wired or Bluetooth Low Energy protocols. The second layer is the edge trusted computing layer, which is centered on a trusted execution environment secure isolation zone and includes a multi-source data receiving module, a spatiotemporal cross-consistency verification engine, and a hardware signature and proof generation module. The third layer is the blockchain network layer, which includes a consortium blockchain node cluster, data verification contracts, finite state machine contracts, and zero-knowledge proof verification contracts. The fourth layer is the business application layer, which includes five types of business participants: buyers, sellers, logistics providers, customs, and banks. Each type of participant interacts with the blockchain network layer through an interface.

[0058] Core Module 1: Edge Multi-Source Spatiotemporal Cross-Verification Mechanism Based on Trusted Execution Environment

[0059] This module is deployed in edge computing hardware devices at critical logistics nodes (warehouse access control, port gates, cold chain vehicle gateways). The device must have a processor supported by Intel SGX or ARM TrustZone. The module completes the entire process from raw sensor data to on-chain proof within the secure isolation zone of the Trusted Execution Environment. No external software (including the device operating system) can access the computing process and intermediate data within the Trusted Execution Environment.

[0060] Suppose that the raw data packet generated by a cargo handover event contains three channels of sensor data: the RFID data includes the cargo's electronic product code and the RFID read timestamp;

[0061] Global Positioning System (GPS) data includes longitude, latitude, vehicle speed, and GPS positioning timestamp;

[0062] The sensor data includes temperature, humidity, triaxial vibration acceleration, and sensor sampling timestamps.

[0063] The specific steps of the spatiotemporal cross-consistency verification algorithm are as follows:

[0064] The first step is data reception and timestamp synchronization verification. After receiving three sensor data streams in the trusted execution environment's secure zone, the timestamps of the three data streams are first checked for synchronization. The absolute value of the difference between each pair of the three timestamps is calculated. If all differences satisfy the following constraint, the synchronization verification is passed; otherwise, it is determined to be a timing anomaly and the data packet is discarded:

[0065] ;

[0066] in, For reading timestamps using radio frequency identification;

[0067] Use the Global Positioning System (GPS) to locate timestamps;

[0068] For sensor sampling timestamps;

[0069] This is the preset maximum allowed timestamp deviation threshold, typically set to 500 milliseconds, used to eliminate the effects of device clock drift.

[0070] The second step is geofence compliance comparison. Based on the physical location of the RFID reader, a valid geofence polygon associated with the reader is predefined during the contract initialization phase. This polygon is represented as a set of sequentially arranged vertex coordinates. Within the trusted execution environment, a ray casting algorithm is performed on the GPS coordinates to determine whether the coordinate point is located inside the geofence. If the coordinates fall outside the geofence, it is determined that the GPS data does not match the RFID reader location, and a spatial inconsistency anomaly is marked out. ,otherwise .

[0071] The third step is to verify the consistency between the motion state and the physical laws governing sensor anomalies. This step is the core logic of spatiotemporal cross-validation and is used to examine whether sensor anomalies have objective causes consistent with physical motion states. Specifically, it verifies the following two rules:

[0072] Vibration velocity correlation verification rule: If the resultant magnitude of the sensor's vibration acceleration exceeds the static threshold... (Right now Then the carrier speed Must simultaneously satisfy (If the carrier is in motion), otherwise, the vibration source is determined to be abnormal, and an output is generated. ,otherwise ;

[0073] in To preset the upper limit threshold of vibration acceleration in a static state, The minimum speed threshold for determining whether a carrier is in motion.

[0074] Temperature abrupt change geographic region association verification rule: If temperature Compared to the previous recorded value The amount of change exceeds the preset mutation threshold (Right now If the current GPS coordinates fall within a pre-registered set of compliant temperature change zones (such as the entrance to a cold storage facility, or the boundary between a refrigerated truck and a room-temperature warehouse), then it is necessary to verify whether the current GPS coordinates fall within the pre-registered set of compliant temperature change zones. If the coordinates are not within the set, the source of the temperature change is determined to be abnormal, and an output is generated. ,otherwise ;

[0075] in This is the preset threshold for detecting sudden temperature changes.

[0076] The fourth step is to calculate the overall confidence score. Based on the output labels of the second and third steps, the overall confidence score of the data handed over is calculated according to the weighted formula.

[0077] ;

[0078] in, The overall confidence score ranges from [0, 100], with higher scores indicating higher data reliability.

[0079] , , These are the penalty weights corresponding to geofence anomalies, vibration anomalies, and temperature change anomalies, respectively, satisfying... The specific weight values ​​are configured during contract deployment based on different cargo types. For cold chain cargo, it is recommended to... Take the larger value;

[0080] , , All are binary outlier markers whose values ​​belong to {0,1}.

[0081] The fifth step is to determine the confidence threshold and perform branching. With preset trust threshold (Typically set to 80) for comparison:

[0082] like If the data packet passes the trust verification, proceed to step six.

[0083] like If the abnormal data packet is not found, it will be recorded along with the abnormal marker in the Trusted Execution Environment security log. The abnormal report will be submitted to the data verification contract on the blockchain through the remote proof interface of the Trusted Execution Environment, triggering the on-chain manual review process and terminating the automatic on-chain process.

[0084] Step 6: Hardware signature generation and data upload within the Trusted Execution Environment (TEE). The data packet that has passed the trusted verification is used to calculate a hash digest of the original data packet within the secure zone of the TEE. The digest is then signed using the device private key derived from the TEE hardware (this private key is permanently generated by the TEE hardware and never leaves the secure zone of the TEE) to generate a signature value. Finally, the data packet, hash digest, signature value, and comprehensive confidence score are packaged into a trusted data proof report, which is then submitted to the blockchain data verification contract along with the TEE platform certificate through the TEE remote proof protocol.

[0085] Core Module 2: Adaptive Dynamic Exemption and Fulfillment Architecture Based on Finite State Machines

[0086] This invention models a complete logistics trade contract fulfillment process as a directed weighted state graph, which includes a finite set of states, a set of state transition events, a state transition function, and a set of initial and final states.

[0087] The finite set of states includes two subsets: normal performance state and abnormal exemption state. The main path of normal performance goes through the following states in sequence: contract initialization and payment freeze state, shipment confirmation and goods out of the warehouse state, in transit and port departure state, arrival at the destination port and customs declaration state, customs release and receipt confirmation state, and payment release and contract completion state. At each state in transit, you can jump to the two exemption sub-states: force majeure delay sub-state and dispute arbitration state.

[0088] The specific steps of the force majeure event triggering and exemption from performance algorithm are as follows:

[0089] The first step is the on-chain registration of external data sources under force majeure. During the contract deployment phase, the buyer and seller register several certified external data source interface addresses in the contract through a multi-party joint signature mechanism (such as the National Meteorological Bureau interface, the customs release status interface of the target port, and the epidemic area announcement interface of the International Chamber of Commerce). Each data source is associated with a force majeure event type identifier and its corresponding exemption parameter template (including parameters such as the maximum allowed extension days and the demurrage fee reduction ratio).

[0090] The second step is the on-chain reporting and multi-source proof submission of force majeure events. When any contract participant believes that a force majeure event has occurred, it can initiate an exemption application, along with objective event proof data from at least two registered data sources (submitted in the form of zero-knowledge proofs), and a trusted data report (including hardware signature) of the current location and status of the goods collected by the applicant through the trusted execution environment gateway.

[0091] The third step is the automatic verification and state transition of the on-chain contract. After receiving the exemption application, the on-chain finite state machine contract calls the zero-knowledge proof to verify the submitted event proof of the pre-compiled contract, checks whether the hardware signature in the trusted data report is generated by the registered compliant trusted execution environment device, and matches the event type with the preset exemption trigger conditions in the contract. If all three items are verified, the contract state machine automatically transitions to the force majeure extension sub-state.

[0092] The fourth step involves the automatic recalculation of exemption parameters. After entering the force majeure extension sub-state, the contract automatically calculates the postponed final delivery deadline:

[0093] ;

[0094] in, This is the extended final delivery deadline stamp;

[0095] This is the original delivery deadline stamp in the contract;

[0096] The actual number of days of impact reported by the event data source;

[0097] The maximum number of days of exemption allowed for this type of force majeure event;

[0098] 86400 represents the number of seconds per day.

[0099] If the storage fees incurred due to the delay are borne by the responsible party, the contract will automatically calculate and deduct them from the frozen payment account according to the following formula:

[0100] ;

[0101] in, Storage fees that need to be allocated;

[0102] The daily storage fee rate preset in the contract;

[0103] This represents the percentage of costs waived for this type of force majeure event, with a value ranging from [0,1]. In such cases, a full exemption will be granted.

[0104] The fifth step is to lift the exemption status and restore the main path. After the force majeure event is lifted and the multi-source zero-knowledge proof is verified, the contract state machine returns to the corresponding state of the main path. Subsequent performance continues to proceed according to the normal path, and the recalculated parameters are permanently written into the contract state storage.

[0105] Core Module 3: Hidden Verification Network for Logistics Handover Status Based on Zero-Knowledge Proofs

[0106] The design goal of this module is to enable both parties to generate cryptographic proofs for each critical state transition during the logistics handover process, without disclosing any original sensitive data to the blockchain network. These proofs are then submitted to the on-chain zero-knowledge proof verification contract. Once the contract is verified as valid, the corresponding contract state transition and fund transfer are automatically triggered.

[0107] This module uses the Groth16 zero-knowledge concise non-interactive knowledge verification protocol. It constructs a first-order constraint system arithmetic circuit to express the verification logic of logistics handover status. Taking the core handover proposition that the goods have been signed for in the correct geographical area within the correct time period and the payment has been fully frozen as an example, the specific steps are as follows:

[0108] The first step is to define the private witness and public input. Define the private witness vector, which includes the electronic code of the goods, the real GPS coordinates at the time of receipt, the receipt timestamp, and the amount of payment. All of the above data is kept off-chain and not submitted to the blockchain. Define the public input vector, which includes the goods identity commitment value agreed upon by both parties in advance when the contract is deployed (calculated through the Pedersen commitment scheme), the upper and lower bounds of the valid receipt time window agreed upon in the contract, the on-chain registration identifier of the geofence of the target receipt area, and the hash commitment value of the frozen amount of payment. All of the above data is stored in plaintext in the on-chain contract state.

[0109] The second step is to construct arithmetic circuit constraints, decomposing the proposition to be proved into the following three constraints:

[0110] The first constraint is the consistency constraint of the cargo identity commitment, which verifies that the Pedersen commitment value generated by combining the cargo electronic code in the private witness with the known random blinding factor is equal to the cargo identity commitment value stored on the chain.

[0111] The second constraint is the receipt time window constraint, which verifies that the receipt timestamp in the private witness falls within the time window defined by the public input. This is implemented in the circuit using a range proof sub-circuit, decomposing the time difference into a 32-bit binary representation and constraining it bit by bit to prove non-negativity.

[0112] The third constraint is the geographic location compliance constraint, which verifies that the geographic coordinates in the private witness fall within the geographic fence identified by the on-chain registration identifier. The fence is stored on the chain in the form of a Merkle tree. The private witness contains the corresponding Merkle path proof. The circuit constraint requires that the Merkle path verification calculation result be true.

[0113] The third step is the trusted generation of the proof key. During the system initialization phase, the buyer, seller, and logistics regulator jointly perform a trusted initialization ceremony to generate a global public reference string containing the proof key and the verification key. The verification key is permanently written into the on-chain zero-knowledge proof verification contract when the contract is deployed.

[0114] The fourth step is off-chain proof generation. After the handover event occurs, the party responsible for generating the proof (usually the logistics provider's edge gateway) generates a zero-knowledge proof off-chain based on private witness, public input, and proof key. The entire proof is usually about 192 bytes in size.

[0115] The fifth step is on-chain proof submission and contract verification. Participants package their public input and zero-knowledge proof into a zero-knowledge proof verification contract on the blockchain. The verification contract calls a pre-compiled bilinear pairing operation to perform a Groth16 verification equation check. If the equation is true, the verification passes, and the contract automatically triggers the corresponding finite state machine state transition and fund transfer instructions. If the equation is false, the transaction is rejected and an on-chain exception log is recorded.

[0116] Three-module collaborative workflow

[0117] The complete end-to-end transaction process, with the three modules working in tandem, is as follows:

[0118] Buyers and sellers deploy finite state machine contracts on the blockchain, and the buyer's payment is deposited into an on-chain escrow account.

[0119] When the seller ships the goods, the trusted execution environment gateway collects three-source data and performs spatiotemporal cross-validation. After the verification is successful, a hardware signature report is generated and uploaded to the chain, and the finite state machine transitions to the shipment confirmation state.

[0120] If a force majeure event occurs during transportation, the logistics provider submits a zero-knowledge proof to the on-chain verification contract. After the verification is successful, the finite state machine jumps to the force majeure extension sub-state and automatically recalculates the parameters.

[0121] Upon arrival at the port, the logistics provider's trusted execution environment gateway performs spatiotemporal verification again and generates a trusted report, while simultaneously generating zero-knowledge proofs off-chain.

[0122] Zero-knowledge proofs are submitted to the on-chain verification contract. Once the verification is successful, the finite state machine transitions to the receipt confirmation state, automatically triggering the payment release instruction.

[0123] Banks automatically issue supply chain finance loans based on on-chain trusted performance records (including trusted execution environment reports and zero-knowledge proof chains).

[0124] Alternative implementation methods

[0125] In logistics edge scenarios lacking trusted execution environment (TEE) hardware, trusted execution environment (TEE) trusted computing can be replaced by a multi-party secure computation mechanism to achieve trusted data on-chaining. Specifically, a multi-party secure computation node cluster consisting of three or more independent hardware devices is deployed at the logistics node. Each node independently collects sensor data for the same goods, and the nodes have geographically distinct locations to prevent collusion. A secret sharing scheme is used to fragment the sensor data, and a secure multi-party computation protocol is executed between the multi-party secure computation nodes. The spatiotemporal cross-consistency verification result is collaboratively calculated without leaking the original data of any individual node. Finally, the verification result is uploaded to the blockchain in the form of a multi-party joint signature. The multi-party secure computation scheme does not rely on specific hardware security features and has broader hardware compatibility, but it has higher computational overhead. It is suitable for logistics scenarios with lower data collection frequency and can serve as a supplement to the trusted execution environment (TEE) scheme. The finite state machine dynamic exemption and zero-knowledge proof concealment verification modules do not require architectural adjustments in this alternative implementation and can directly reuse the original design.

[0126] For scenarios where small and medium-sized logistics enterprises cannot afford the deployment costs of the Trusted Execution Environment (TEE) edge gateway, a lightweight solution combining device digital certificates and authoritative timestamps can be used to replace the TEE module. Specifically, each sensor device is issued a non-exportable device-level digital certificate by an authoritative certificate authority at the factory. Each piece of sensor data collected by the device is automatically appended with the device certificate signature and an authoritative timestamp obtained from a national timestamp authority to ensure that the data collection time cannot be forged. Furthermore, multiple independent data receiving nodes with different network access paths are deployed at logistics nodes. Each node is required to independently report data and compare the consistency of the sensor data digests received by each node to rule out single-node data tampering. This solution has lower verification strength than the hardware-level TEE solution but extremely low deployment costs, making it suitable for ordinary cargo logistics scenarios with lower trust requirements. The architecture of the finite state machine dynamic exemption module and the zero-knowledge proof hidden verification module remains unchanged in this alternative implementation; only the implementation mechanism of the trusted data acquisition layer is replaced.

[0127] Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of the present invention. Therefore, any modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall fall within the protection scope defined by the claims of the present invention.

Claims

1. A trusted online trade logistics transaction method based on smart contracts, characterized in that, Includes the following steps: Within the trusted execution environment isolation zone of the logistics edge gateway, multi-source spatiotemporal cross-consistency verification is performed on the electronic code and reading timestamp of the goods from the RFID reader, the latitude and longitude coordinates and the carrier velocity and positioning timestamp from the GPS module, and the temperature, humidity and vibration acceleration and sampling timestamp from the environmental sensor group. Multi-source spatiotemporal cross-consistency verification includes: timestamp synchronization verification, geofence compliance comparison, vibration acceleration and carrier velocity correlation verification, and temperature mutation and geographic coordinate landing area correlation verification. Based on geofence anomaly markers, vibration velocity anomaly markers, and temperature change anomaly markers, with 100 as the full score benchmark, according to the formula... Calculate the overall confidence score, where , , The penalty weights for each exception type are given, and the sum of the three weights does not exceed 1. , , A binary anomaly flag is set to a value of {0,1}. The value is 1 when the anomaly occurs and 0 when the normality occurs. When the comprehensive confidence score is not lower than the preset trust threshold, the hardware-derived private key is used to sign the hash digest of the data packet in the trusted execution environment. The trusted data proof report containing the data packet, hash digest, signature value and comprehensive confidence score is submitted to the blockchain data verification contract through the trusted execution environment remote proof protocol. The logistics and trade smart contract is constructed as a finite state machine, which includes a normal performance main state path and a force majeure delay sub-state. When an on-chain finite state machine contract receives an exemption application and the force majeure event proof verified by zero-knowledge proof meets the preset conditions, and the verified trusted data report hardware signature comes from a registered compliant trusted execution environment device, the contract state machine automatically jumps to the force majeure extension sub-state, automatically recalculates the postponed delivery deadline and related costs, and returns to the main path after the force majeure event is lifted and verified by zero-knowledge proof. Logistics participants use the electronic code of the goods, the latitude and longitude coordinates of the GPS at the time of receipt, the receipt timestamp, and the amount of payment as private witnesses off-chain. They use the goods identity commitment value, the upper and lower limits of the valid receipt time window, the on-chain registration identifier of the target receipt area geofence, and the hash commitment value of the frozen amount of payment as public inputs. Based on the arithmetic circuit containing the consistency constraints of the goods identity commitment, the receipt time window constraints, and the geographical location compliance constraints, a zero-knowledge proof is generated. The public inputs and the zero-knowledge proof are submitted to the on-chain zero-knowledge proof verification contract. After the verification is successful, the contract automatically triggers the finite state machine state transition and fund transfer instructions. The private witness data is not recorded on the chain.

2. The method according to claim 1, characterized in that, The timestamp synchronization verification method is as follows: calculate the absolute value of the pairwise difference between the RFID reading timestamp, the GPS positioning timestamp, and the sensor sampling timestamp. If all absolute value differences do not exceed the preset maximum allowable timestamp deviation threshold, the synchronization verification is passed; otherwise, it is judged as a timing abnormality and the data packet is discarded. The method for verifying the compliance of the geofence is as follows: During the contract initialization phase, a valid geofence polygon associated with the RFID reading point is predefined. Within the trusted execution environment, a ray casting algorithm is executed on the GPS latitude and longitude coordinates to determine whether the coordinate point is inside the fence. If the coordinate falls outside the fence, a spatial inconsistency anomaly mark is output. The comprehensive confidence score is calculated as follows: with 100 as the full score benchmark, subtract the product of the geofence anomaly marker and its corresponding penalty weight, the product of the vibration velocity anomaly marker and its corresponding penalty weight, and the product of the temperature change anomaly marker and its corresponding penalty weight in sequence. The sum of each penalty weight does not exceed 1. Each anomaly marker takes a value of 1 to indicate anomaly and a value of 0 to indicate normal.

3. The method according to claim 1, characterized in that, The method for verifying the correlation between vibration acceleration and carrier velocity is as follows: if the combined vibration acceleration of the sensor exceeds the preset upper limit threshold of vibration acceleration in a static state, then it is determined whether the carrier velocity exceeds the preset minimum motion velocity threshold. If it does not exceed the threshold, an abnormal vibration source marker is output. The method for verifying the correlation between the temperature mutation amount and the geographic coordinate landing area is as follows: if the absolute value of the difference between the current temperature and the previous recorded temperature exceeds the preset temperature mutation detection threshold, then verify whether the current global satellite positioning system coordinates fall within the pre-registered set of compliant temperature change areas. If they do not fall within the set, then output an abnormal temperature mutation source marker. The set of compliant temperature change areas is registered during the contract initialization phase and includes the cold storage entrance and exit area, and the boundary area between the refrigerated truck compartment and the ambient temperature warehouse.

4. The method according to claim 1, characterized in that, The normal performance backbone state path of the finite state machine includes, in sequence, contract initialization and payment freezing state, delivery confirmation and goods leaving the warehouse state, transportation and port departure state, arrival at the destination port and customs declaration state, customs release and receipt confirmation state, and payment release and contract completion state. The force majeure delay sub-state can be triggered to jump at any intermediate state during the transportation of the main route; The finite state machine also includes a dispute arbitration state, which is entered unidirectionally by the force majeure extension sub-state and ultimately terminated through the arbitration settlement path or the contractual termination and refund path.

5. The method according to claim 1, characterized in that, After the force majeure delay sub-state is triggered, the final delivery deadline after the extension is calculated based on the original delivery deadline timestamp, the actual number of days of impact reported by the event data source, and the maximum number of days of exemption allowed for this type of force majeure event. The actual extension days are the smaller of the actual number of days of impact and the maximum number of days of exemption. If the storage fees incurred due to the delay are borne by the responsible party, the contract will automatically calculate the amount to be allocated based on the preset daily storage fee rate, the actual number of days of delay, and the fee exemption ratio corresponding to the force majeure event. The fee exemption ratio ranges from 0 to 1, and a value of 1 indicates a full exemption.

6. The method according to claim 1, characterized in that, The external data source of force majeure is registered in the contract by the buyer and seller through a multi-party joint signature mechanism during the contract deployment phase. Registration is effective only if more than half of the total number of participating parties plus the consent of one party are reached. Each data source is associated with a force majeure event type identifier and its corresponding exemption parameter template. The exemption parameter template includes the maximum allowed number of days of extension and the demurrage fee reduction ratio. Applications for exemption must be accompanied by objective event proof data from at least two different registered data sources, submitted in the form of zero-knowledge proofs.

7. The method according to claim 1, characterized in that, The implementation of the geographical location compliance constraint is as follows: the geographical fence of the target signing area is stored on the chain in the form of a Merkle tree, the private witness contains the Merkle path proof corresponding to the geographical coordinates, and the arithmetic circuit constraint requires that the verification calculation result of the hash value of the root node of the Merkle tree based on the Merkle path proof and the geographical coordinates is true. The implementation method of the signing time window constraint is as follows: the difference between the signing timestamp and the lower bound of the time window, and the difference between the upper bound of the time window and the signing timestamp are decomposed into 32-bit binary representations and constrained bit by bit to prove that both are non-negative values.

8. The method according to claim 1, characterized in that, During the system initialization phase, the zero-knowledge proof is generated by a trusted initialization ceremony jointly performed by the buyer, seller, and logistics regulator. The global public reference string contains a proof key and a verification key. The verification key is permanently written into the on-chain zero-knowledge proof verification contract during contract deployment. The on-chain zero-knowledge proof verification contract calls the pre-compiled bilinear pairing operation to perform the verification equality check. If the verification passes, the contract automatically triggers the finite state machine state transition and fund transfer instructions. If the verification fails, the transaction is rejected and an on-chain exception log is recorded.

9. The method according to any one of claims 1 to 8, characterized in that, When the trusted execution environment isolation zone lacks the hardware conditions for a trusted execution environment, it is replaced by a multi-party secure computing mechanism: Deploy a multi-party secure computing node cluster consisting of three or more independent hardware devices with different geographical locations at the logistics node. Each node independently collects sensor data of the same goods. After the sensor data is fragmented using a secret sharing scheme, a secure multi-party computing protocol is executed between the nodes. The spatiotemporal cross-consistency verification result is calculated collaboratively without leaking the original data of any single node. Finally, the verification result is uploaded to the blockchain in the form of a multi-party joint signature. The architecture of the finite state machine dynamic exemption module and the zero-knowledge proof hidden verification module remains unchanged.

10. The method according to claim 1, characterized in that, The penalty weights are configured differently based on the type of goods during contract deployment: For ordinary goods, the penalty weights for geofencing anomalies, vibration speed anomalies, and temperature change anomalies are distributed in a balanced manner. For cold chain goods, the penalty weight for abnormal temperature changes is higher than that for abnormal geofencing and abnormal vibration speed. For hazardous chemical goods, the weights for geofencing anomaly penalties and vibration speed anomaly penalties are both higher than the corresponding weights for ordinary goods.

Images