Lattice-based homomorphic proxy re-encryption scheme (LHPRE) (Luo et al., 2020; Li et al., 2023) includes six algorithms: Setup, KeyGen, Enc, Dec, ReKeyGen, ReEnc.

Setup ( 1 λ , 1 d , 1 I ): Input security parameter λ, output p p , m p k : = ( A , A 1 , B , u ) and m s k : = ( S ).

KeyGen ( m s k , i d ): Given m s k and identity i d, output a secret key s k i d : s = ( 1 , − z t ) ∈ Z 2 m + 1 and the public key p k i d : A i d = [ u ∥ H ] t ∈ Z q ( 2 m + 1 ) × n .

Enc ( m p k , i d , μ ): Input μ, computes C = A i d R + 2 E + μ G.

Dec ( C , i d , s k i d ): Let c be the first column of C. Get μ = ⟨ s , c ⟩ mod q mod 2.

ReKeyGen ( s k i d , i d , i d ′ , p k i d ′ ): Given s k i d , and p k i d ′ , output the re-encryption key s k i d → i d ′ : P i d → i d ′ = A i d ′ R ′ + 2 E ′ + [ sG 0 ] ∈ Z q ( 2 m + 1 ) × N .

ReEnc ( s k i d → i d ′ , i d ′ , ( i d , C ) ): Given s k i d → i d ′ , and C, output C i d → i d ′ : = P i d → i d ′ G − 1 ( C ).

The algorithm satisfies homomorphism, that is Enc ( μ 1 + μ 2 ) = Enc ( μ 1 ) + Enc ( μ 2 ) and Enc ( μ 1 · μ 2 ) = Enc ( μ 1 ) · G − 1 (Enc ( μ 2 )). Its correctness is shown in Luo et al. (2020), Li et al. (2023), which it has been proved that the algorithm meets CPA security in semantic security.

Lattice-based homomorphic signatures scheme (LHS) (Gorbunov et al., 2015) includes four algorithms: Setup, KeyGen, Sign, Verify.

Setup ( 1 λ , 1 N ): Choose ν 1 , ν 2 , … , ν N ← Z q n , output p r m s = ( ν 1 , ν 2 , … , ν N ).

KeyGen ( i d ): Given identity i d, output the public and private keys p k i d , s i g = A i d , s k i d , s i g = td i d ← TrapGen ( 1 n , 1 m , q ).

Sign ( i d , p k i d , s i g ): Given identity i d and the public key p k i d , s i g , output the signature σ i = SamPre ( A i , ν i − μ · G , td i ).

Verify ( i d , p k i d , s i g , σ i ): Given identity i d, the public key p k i d , s i g and the signature σ i , output accept or reject by checking f ( σ i ) = Process ( G ) or not.

The algorithm also satisfies homomorphism: Sign ( μ 1 + μ 2 ) = Sign ( μ 1 ) + Sign ( μ 2 ). Its correctness is shown in Gorbunov et al. (2015), which has proved that the algorithm meets semantic security in LWE assumption.

Evaluate the similarity between two vectors by calculating the cosine value of their included angle (Ye, 2011). Cosine similarity draws vectors into vector space based on coordinate values, such as the most common two-dimensional space. Cosine similarity focuses on the angular relationship between vectors, not on their absolute size. The range of values is [ − 1 , 1 ]. When measuring the similarity of a pair of texts, when the text content is similar, if word frequency or word vectors are used as features, their Euclidean distance in the feature space may be large. However, the angle between them may be small, resulting in high similarity. Here, this article only focuses on the direction between vectors, and the direction is one direction, so the value range is [ 0 , 1 ]. The closer it is to 1, the more similar the feature vectors of the two parameters are, and vice versa, the less similar they are.

There are many ways to trade data now. In particular, this article focuses on the data trading platform model, whose advantage is that buyers and sellers can conduct open and free transactions bilaterally, and the platform manages their data transaction processes and related assets. This article designs a smart logistics data trading platform architecture, including five layers: trading data perception layer, trading data generation layer, network layer, data trading platform layer, data trading application layer, as shown in the Fig. 1.

Based on this architecture, a flexible and dynamic privacy-preserving data trading scheme with lattice homomorphism and federated learning in blockchain-enhanced smart logistics is designed, whose system model is shown in Fig. 2. In the model, there are four entities: data trading platform, InterPlanetary File System (IPFS), data buyer, data seller. •

Data trading platform (DTP): The DTP is responsible for providing data transaction services to registered users. Users with data selling needs and data buying needs can find potential customers on this platform. The platform has an administrator who is responsible for user registration, key generation and distribution, smooth transaction process, data quality measurement and negotiated pricing, model parameter aggregation and re-encryption, incentive calculation and issuance, feedback adjustment operations. It is worth noting that dynamic access control and authentication are also completed here.

Fig. 2

System model.

This article proposes a privacy-preserving logistics data transaction scheme, setting the DTP to be credible and other participants to be semi-credible (honest but curious). In addition, it is assumed that there is a malicious attacker outside the system, hoping to obtain some useful information through open eavesdropping, interception and retransmission, conspiracy attacks and other attack methods. (1)

Entity Trust Classification. We first strictly define the trust level of each participant in the consortium blockchain logistics data trading system:

Justification for Trusted DTP Assumption in Consortium Blockchain Logistics Scenarios. The DTP is designated as a trusted node only for permissioned Hyperledger Fabric consortium deployments, supported by two layers of guarantees: Institutional consortium governance constraint and Built-in cryptographic safeguards limiting DTP data leakage capability. The DTP operator is jointly nominated and supervised by multiple independent logistics enterprises, third-party regulatory auditors and equipment manufacturers that form the consortium committee. All core platform logic (user registration, re-encryption, pricing, incentive settlement) is hard-coded into open-source, auditable Fabric chaincode. Any platform operation record is timestamped and aggregated to multi-peer blocks; the consortium can launch joint arbitration and suspend DTP permissions if abnormal behaviours are detected. There is no single organization controlling the platform independently, eliminating unilateral malicious operation incentives. Even if the DTP is honest-but-curious or partially compromised, a series of hard-coded chain rules and lattice cryptographic restrictions prevent it from extracting plaintext private logistics data or tampering trading parameters arbitrarily, as detailed in Section 2 below. The trusted assumption only means the DTP will not actively launch large-scale malicious attacks; it does not grant the platform unrestricted access to plaintext sensitive information.

Based on the data trading platform model, this paper designs a privacy protection model suitable for smart logistics data transactions. Based on this, the goals to be achieved by this plan are as follows: (1)

Privacy protection. The private data involved in this solution includes original data, transaction data, user identity information, etc. One of our purposes is to protect these private data from being leaked.

Logistics data generally refers to the general term for knowledge, materials, images, data, and files of various logistics activities. It has the characteristics of various types, complex sources, large amount of information, and fast update speed. Data trading can not only better leverage the value of the data itself, but also better predict market demands and changes, optimize transportation routes, and improve warehousing efficiency. Most of the current smart logistics data transaction architecture is based on blockchain platforms, and shared privacy protection research is mostly based on cryptography and privacy computing technology. However, problems such as the uneven quality of transaction data, imperfect incentive mechanisms, inconsistencies on and off the chain, and quantum computer attacks have still not been solved well. Based on this, this article considers that the above problems can be solved well based on the lattice homomorphic proxy encryption algorithm, blockchain and privacy computing.

This article hopes to build an open, secure, and incentive-based data transaction paradigm. Different from traditional data transactions, the transaction data in this article is logistics data, and the embodied form of transaction data is the model or parameters after model training, rather than the original data or data set. On the one hand, this can improve the efficiency and accuracy of data sharing, and on the other hand, it can also protect the identity privacy of data users to the greatest extent. The specific structure and detailed description of the scheme are as follows.

The proposed privacy-preserving data trading scheme with lattice homomorphism and federated learning in blockchain-enhanced smart logistics in this article contains four phases: initialization phase, model training, parameter upload and parameter quality assessment phase, model parameter data transaction phase, trading data update and tracking phase. (1)

Initialization phase: The initialization phase consists of two parts: public parameters generation, user registration and key generation.

This subsection fully elaborates the complete pipeline of the proposed model quality evaluation method, including gradient feature extraction, vector normalization, benchmark reference vector generation, cosine similarity calculation, and standardized quality grading rules. We further provide theoretical analysis on feature selection, threshold rationality, and robustness against varying model scales and non-IID logistics data, together with executable formal pseudocode.

After local federated training via FedAvg, we extract the gradient vector of the first fully-connected layer of each local model as the feature vector F V r a w for quality assessment. The theoretical rationality is as follows: The first layer undertakes mapping of heterogeneous raw logistics sensing data (order information, temperature, vehicle trajectory, warehouse occupancy), and its gradient distribution directly reflects the fitting degree of local data to global business rules. Deep hidden layers only perform secondary feature recombination, which cannot intuitively distinguish the noise bias of original fragmented logistics datasets. Only adopting the first-layer gradient avoids redundant multi-layer vector computation, reducing the on-chain calculation overhead of the quality evaluation smart contract.

Raw gradient vectors have inconsistent dimensions and magnitudes under different FL model sizes (32/64/128/256 hidden units). We apply L2 normalization to eliminate the interference of vector length on similarity results: F V norm = F V r a w ‖ F V r a w ‖ 2 , ‖ F V r a w ‖ 2 = ∑ o = 1 k F V r a w , o 2 , where k denotes the dimension of the raw gradient vector. After normalization, all feature vectors are projected onto a unit hypersphere; cosine similarity only depends on the included angle between vectors, independent of model parameter scale.

Two standard reference vectors F V upper (optimal benchmark) and F V lower (noisy lower bound) are maintained on the consortium blockchain ledger, constructed from historical verified high-quality logistics model samples: Construction of upper reference vector F V upper . Collect all normalized feature vectors { F V 1 , F V 2 , … , F V T } of historically certified high-quality DS from on-chain storage, compute element-wise average as the global optimal gradient benchmark F V upper = 1 T ∑ t = 1 T F V t $. Then execute L2 normalization on F V upper to keep unit length consistent with local feature vectors. Construction of lower reference vector F V lower . Add zero-mean Gaussian noise ϵ ∼ N k ( 0 , 0.2 ) to F V upper to simulate gradient distribution of noisy low-quality logistics data F V lower = F V upper + ϵ. Normalize F V lower via L2 norm to unify vector scale.

We conduct threshold sensitivity tests across four heterogeneous logistics datasets (express, warehousing, cold chain, transportation) to determine stable classification boundaries for normalized cosine similarity C S i ∈ [ 0 , 1 ]: High-quality model: C S i ∈ [ 0.8 , 1.0 ], Medium-quality model: C S i ∈ [ 0.4 , 0.8 ], Low-quality model: C S i ∈ [ 0 , 0.4 ]. When shifting high/medium threshold within 0.7 ∼ 0.9 and medium/low threshold within 0.3 ∼ 0.5, the proportion change of each quality group in all datasets is controlled within 4.3%. The threshold partition has strong stability and generalization for diversified logistics business data.

L2 normalization eliminates magnitude interference of gradient vectors. Experiments prove that model hidden dimensions ranging from 32 to 256 will not cause obvious deviation of similarity grading results. Robustness against non-IID logistics data: Logistics data naturally presents non-independent identical distribution characteristics (cold chain temperature data vs express order data have completely different feature spaces). Our gradient feature extraction focuses on the fitting trend of local data to global business rules rather than raw feature values. Even severely skewed non-IID samples can generate obviously deviated gradient vectors, and cosine similarity can stably quantify data quality gaps.

High-quality logistics datasets generate gradient vectors close to the global optimal convergence direction; noisy, sparse, non-IID local data produce deviated gradient distributions, which can be quantitatively distinguished by cosine similarity metrics as Algorithm 2.

The general process includes the following four steps: model parameter acquisition, feature vector extraction, cosine similarity calculation and model parameter quality assessment.

In order to maximize participation enthusiasm, this article designs an incentive mechanism based on data quality and participation time, mainly including income calculation and income distribution. (1)

Income calculation. For a data seller D S i , the transaction revenue allocated to the seller is calculated as: (4) income i = Total · | w 1 | C S i + | w 2 | T i ∑ i ⊆ n ( | w 1 | C S i + | w 2 | T i ) , where Total denotes total transaction revenue generated from this batch of model parameter trading, C S i ∈ [ 0 , 1 ] is the cosine similarity quality score of D S i ’s local model, and T i ∈ [ 0 , 1 ] is normalized continuous participation time of the seller on the platform. The constraint | w 1 | + | w 2 | = 1 guarantees the sum of weighted contribution terms of all sellers equals the total revenue.

The data trading platform designed in this article is based on the consortium blockchain. A total of three types of transactions (publickeyTransaction, tradingdataTransact ion and datatradingTransaction, as shown in Fig. 4) are involved, and their records will be recorded in the blockchain in real time. The blockchain platform used in this article is HyperLeger Fabric, and the consensus algorithms involved are mainly Solo, Kafka, and SBFT (Androulaki et al., 2018).

We deploy a dedicated logistics consortium oracle as an independent Fabric peer service, serving as the trusted bidirectional relay between DTP trading backend, off-chain IPFS distributed storage, and consortium blockchain ledger. This subsection elaborates the oracle’s trust assumption, data source, synchronization frequency, full workflow, failure handling, and manipulation resistance mechanism.

(1) Oracle Trust Assumption. The oracle node is operated and jointly supervised by multiple independent logistics enterprises and regulatory auditors in the Fabric consortium, not controlled solely by the DTP.

Trust premise: The oracle follows hard-coded chaincode logic and does not actively forge hash mapping data.

Mitigation against curious/compromised oracle: All IPFS file hash binding transactions require multi-peer aggregate signature before being written to blocks; any single compromised oracle cannot tamper with global synchronization records unilaterally.

The oracle does not hold user lattice private keys or plaintext logistics model parameters, so oracle compromise cannot lead to leakage of private trading data.

(2) Data Source Definition. The oracle only accepts three standardized input data sources, rejecting arbitrary unstructured payloads: Validated ciphertext batch tuples forwarded by DTP after signature & quality verification; Immutable IPFS content-addressable hash returned by official IPFS cluster API; On-chain historical synchronization records stored in Fabric world state for periodic cross-check. The oracle never reads raw plaintext logistics data; all transmitted payloads are encrypted Paillier/LWE ciphertexts or fixed-size hash digests.

(3) Synchronization Update Frequency. Two independent update cycles are configured in oracle chaincode: Immediately executed once DTP submits a validated cipher batch, no artificial delay; background consistency polling (periodic fixed cycle): Full cross-check of all on-chain hash records and corresponding IPFS files every 300 seconds (5 minutes), used to detect offline file loss or hash mismatch faults.

(4) Complete Bidirectional Synchronization Workflow. DTP forwards fully verified ciphertext batch M i to the oracle’s dedicated data interface; Oracle invokes official IPFS client API to batch store ciphertexts and obtain unique content hash Torrent.hash; Oracle packages synchronization metadata { p i d , k w , t i , quali t d , Torrent.hash , price }; Metadata transaction is broadcast to consortium peers and requires ⩾2/3 aggregate signature confirmation before block packaging; After block confirmation, the oracle writes a synchronization success flag into IPFS file extended metadata for subsequent polling check.

Read Consistency Polling (Oracle Cross-Check). Every 300s, the oracle traverses all hash records stored on the blockchain; For each recorded Torrent.hash, send a file retrieval request to the IPFS cluster; Compare the newly recalculated file hash with the on-chain stored value to judge consistency.

(5) Classification of Failure Modes & Automatic Remediation. The oracle predefines three typical inconsistency faults and corresponding auto-repair logic: IPFS File Loss Failure: IPFS cannot locate the file matching the on-chain hash. Oracle pulls temporary cipher backup cached by DTP, re-uploads to IPFS, generates a new hash, and submits a supplementary correction transaction to the blockchain for record update. Hash Mismatch Failure: Retrieved IPFS file hash conflicts with the on-chain stored digest (indicating off-chain tampering). Oracle logs tampering evidence on-chain, freezes the corresponding DS’s trading qualification, and triggers manual arbitration by consortium auditors. Network Timeout Failure: IPFS API no response within 10s during write synchronization. The oracle executes 3 sequential retries; if all fail, suspend transaction submission and push fault alarm to consortium administrators to avoid invalid empty ledger entries.

(6) Manipulation Resistance Mechanism. Multi-layer anti-tampering design prevents single-point or collusive oracle manipulation: Any oracle synchronization metadata cannot be written to blocks without aggregate signatures from more than two-thirds of consortium peers; a single malicious oracle cannot alter hash mapping records independently. The oracle’s IPFS upload and hash calculation logic is solidified in open-source chaincode, which all consortium participants can audit; there is no customizable hidden variable to modify hash values arbitrarily. All oracle operation logs (upload requests, polling records, fault repair transactions) are timestamped and permanently recorded on the blockchain; any abnormal oracle behaviour can be traced via historical blocks for accountability. Oracle storage interface and DTP business backend are deployed on isolated peer nodes; DTP cannot directly access or modify IPFS file storage bypassing the oracle’s standardized interface.

Before formal privacy and collusion resistance proofs, we first state the core LWE hardness assumption supporting our lattice cryptosystem (LHPRE proxy re-encryption and LHS lattice signature).

LWE Hardness Assumption. Let n , q , χ be lattice security parameters: n lattice dimension, prime modulus q, discrete Gaussian error distribution χ over Z q .

Decision LWE Assumption: Given a matrix A ∈ Z q m × n and two distribution samples:

1) Valid LWE sample: (A, As + e), where secret s ← Z q n , noise e ← χ m ;

2) Uniform random sample: ( A , u), where u ← Z q m uniform.

No probabilistic polynomial-time (PPT) adversary can distinguish the two distributions with non-negligible advantage over the security parameter λ.

All ciphertexts and signatures in our scheme are constructed over LWE instances; recovering plaintext model parameters requires solving the corresponding LWE problem, which is computationally infeasible for PPT adversaries under standard lattice hardness. Theorem 1.

The proposed scheme meets the privacy protection requirements.

In order to comprehensively evaluate the performance of the proposed solution, we designed simulation experiments. This experiment focuses on evaluating the computational and communication costs of cryptography algorithms from both theoretical analysis and experimental evaluation perspectives. The key evaluation algorithm for computational cost focuses on the time consumption of various operations during the calculation process, including multiplication, exponentiation, logarithm, and other operations. The communication cost mainly evaluates the time and amount of information transmitted between nodes, including the time required to transmit a unit of information between nodes and the total amount of information that needs to be transmitted. The specific design is as follows.

Here, theoretical analysis and experimental verification are conducted on the computational cost of the proposed solution. The experimental environment is: Laptops 13th Gen Intel(R) Core(TM) i5-13500H 2.60 GHz RAM 32.0 GB and using PyCharm software platform in python language. Assuming T a represents the time to perform an addition operation on Z q ∗ , T m represents the time to perform a multiplying operation on Z q ∗ , T m V N represents the time to perform an multiplying operation for a vector and a number, T m V V represents the time to perform a multiplying operation for two vectors, T m M N represents the time to perform a multiplying operation for a matrix and a number, T m M M represents the time to perform a multiplying operation for two matrices, T a M M represents the time to perform an addition operation for two matrices. The addition operation of the two numbers here can be ignored and will not be considered in this paper. To eliminate random errors, each result is repeated 100 times to take the average, as shown in Table 2.

Firstly, we conduct a theoretical analysis of the proposed scheme in this paper, which includes data encryption, data aggregation and data decryption three phases. In the data encryption phase, the D S needs to perform an encryption operation and a signature operation for each transaction data and the time cost is T 1 = n · ( 2 T a M M + 2 T m M N ) = 2 n · ( T a M M + T m M N ). In the data aggregation phase, the DTP performs an aggregation operation, re-encryption operation, and signature operation, and the time cost is T 2 = ( n − 1 ) · T a M M + 2 T a M M + 2 T m M N = ( n + 1 ) · T a M M + 2 T m M N . In the data decryption phase, the D B performs a decryption operation and the time cost is T 3 = T m V V . Similarly, we conducted the same analysis on DRQP (Li et al., 2023), LBHP (Abdallah and Shen, 2016), ELDG (Qian et al., 2020) and LBDG (Qian et al., 2021) four schemes, and the results are shown in the Table 3.

Then, the calculation time cost comparison results of these five schemes are shown in the Fig. 5. Figure 5(a) represents a comparison of the calculation time and cost during the data encryption phase; 5(b) represents a comparison of the calculation time and cost during the data aggregation and re-encryption phase, as shown in Fig. 5(c), which represents a comparison of the calculation time cost during the data decryption phase. Through observation and analysis, it can be seen that the proposed scheme in this article has obvious advantages in the data encryption, data aggregation and data decryption phases. When the data volume reaches 100 levels, the computational time consumed is still within 1 second, which is completely acceptable in the industry. This standard also meets the design objectives of this article and satisfies the requirements of efficiency.

Before presenting computational overhead comparison (Table 3), we standardize four core equalization rules to guarantee fair horizontal evaluation among our scheme, LBHP (Abdallah and Shen, 2016), ELDG (Qian et al., 2020), LBDG (Qian et al., 2021), DRQP (Li et al., 2023). All lattice primitives across five schemes are instantiated under NIST PQC Security Level 1 (128-bit quantum/classical security), based on identical standard LWE hardness assumption with fixed lattice parameter set n = 512, prime modulus q = 2 14 − 1, centred binomial noise distribution χ with parameter η = 1. No scheme uses weaker small lattices or lower security moduli to artificially reduce computation cost. For all lattice encryption/signature modules in comparison groups, we fix standardized payload sizes | c | = 120 bits per single homomorphic ciphertext, | σ | = 100 bits per lattice aggregate signature. This sizing follows lightweight LWE homomorphic proxy re-encryption literature [28, 29], optimized for small-valued logistics model gradient plaintexts (single normalized similarity values within [ 0 , 1 ]). Only shared core logistics data aggregation cryptographic operations are counted for fair comparison: local encryption, batch aggregation, single decryption. Exclusive functional modules unique to our scheme (oracle synchronization, cosine similarity quality assessment, dynamic one-time authentication, multi-weight incentive settlement) are excluded from the theoretical complexity formulas of Table 3, as baseline LBHP/ELDG/LBDG/DRQP lack these trading-system subroutines and including them would create unfair overhead bias. The variable n uniformly denotes the count of independent data sellers submitting model batches across all five complexity formulas, eliminating inconsistent variable semantics across different literature.

Our LHPRE homomorphic ciphertext and LHS lattice signature lengths are chosen to match lightweight lattice privacy-preserving aggregation schemes targeting IoT/logistics low-value numerical plaintexts (Luo et al., 2020; Li et al., 2023; Abdallah and Shen, 2016), complying with NIST Level 1 post-quantum security without redundant large vector overhead: Ciphertext | c | = 120 bits rationale. The plaintext space only stores normalized floating-point model quality values mapped to discrete 16-bit integer representations for lattice embedding. Under our fixed LWE parameter group ( n = 512, q = 16383), a compact single-row LWE ciphertext vector with additive homomorphism only requires 120 bits to embed plaintext and bounded Gaussian noise term, consistent with DRQP (Li et al., 2023) lightweight grid lattice ciphertext design. Larger multi-kilobyte ML-KEM-style ciphertexts are unnecessary here because we only encrypt scalar similarity/timestamp values instead of long arbitrary byte strings. Using 120-bit ciphertexts keeps communication overhead low for edge logistics terminals while maintaining full 128-bit post-quantum semantic security under LWE.

Signature | σ | = 100 bits rationale. The lattice aggregate signature LHS adopts GPV trapdoor sampling optimized for short message digests ( H ( C t x ) truncated to 80-bit hash). The rejection-sampled signature vector is compressed to 100 bits after coordinate modulo reduction, matching the lightweight lattice aggregate signature construction in LBHP (Abdallah and Shen, 2016). This avoids the multi-kilobyte overhead of full Dilithium/ML-DSA signatures designed for general-purpose public key systems; our logistics trading scenario only requires short transaction hash authentication, so 100-bit signatures suffice for existential unforgeability under LWE-MLIS hard problem. All four baseline works (LBHP, ELDG, LBDG, DRQP) adopt equivalent compact lattice ciphertext/signature sizing for small numerical IoT plaintexts in their original simulations. We strictly follow their lightweight parameter conventions instead of heavy general PQC standards to maintain identical overhead measurement baselines.

Next is the analysis of communication costs from both theoretical and experimental perspectives. Assuming | c | represents the length of a ciphertext, | σ | represents the length of a signature and | t | represents the length of a timestamp. In this paper, the process involving information transmission includes a D S encrypting the transmission of transaction data to the DTP and the DTP sending re-encrypted ciphertext and signing to the D B. For the former, the D S i sends M i = ( C i , σ i , p i d i , k w i , t i ) to the DTP. For the latter, the DTP sends M D T P = ( C D T P → j , σ D T P , t D T P ) and sends to the D B. So, the communication cost of our scheme is ( n + 1 ) · ( | c | + | σ | + | t | ). Here, due to the lack of keyword settings in other literature, for the sake of fairness, pseudonym and keywords are not included. Using the same analysis method, the comparison results of communication costs among LBHP, ELDG, LBDG DRQP and ours are shown in the Table 4.

Set | c | = 120 bits, | σ | = 100 bits, | t | = 60 bits and n ⊆ { 0 , 10 , 20 , 30 , 40 , 50 , 60 , 70 , 80 , 90 , 100 }. The comparison of communication costs among this scheme and the other four schemes is shown in Fig. 6. From the comparison results, it is clear that the communication cost (referring to the amount of communication data) of the proposed solution in this article has always been at a relatively low level and has obvious advantages. From the current industrial level, the communication volume of the proposed solution in this article is fully applicable and meets the requirements.

Before communication overhead analysis (Table 4), we reference the identical fairness constraints defined in Section 5.2, including unified NIST Level 1 LWE post-quantum security, consistent | c | = 120 bit ciphertext and | σ | = 100 bit signature sizing across LBHP/ELDG/LBDG/DRQP and our lattice suite. Again, only shared upload/download cipher/sign payloads are calculated for fair comparison; auxiliary metadata unique to our trading platform (oracle hash, quality score fields) is excluded from the communication cost formulas in Table 4 to match baseline schemes’ payload structure. Set single ciphertext payload | c | = 120 bits, lattice aggregate signature | σ | = 100 bits, transaction timestamp | t | = 60 bits as standardized lightweight lattice sizing justified in 5.2, consistent with all compared IoT/lattice baseline literature. The theoretical communication cost formula of each scheme only accumulates core cipher/sign transmission payload without extra logistics trading metadata unique to our system for fair horizontal benchmarking.

After observation and analysis, it can be seen that the communication cost of the proposed solution in this article has obvious advantages, and when the user volume reaches 100, the communication cost is only 3.5 KB, which can fully meet the existing industrial needs. In addition to theoretical analysis, this article also simulates a transmission delay of 1024 bytes data on the ns-3 platform (Riley and Henderson, 2010), which is 3.69 milliseconds. Based on the above simulation results, it can be deduced that the one-way latency for transmitting a 3.5 KB payload to the peer node solely at the network link layer is 12.915 ms. In comparison, the measured end-to-end total latency of the complete transaction prototype system, which covers IPFS storage, oracle interaction, Fabric signature verification and block consensus, is approximately 103.32 ms, as shown in Fig. 7. The value of 12.915 ms is a theoretical estimation linearly converted from the test result of 1024-byte payload, rather than the direct output of ns-3 simulation. Perturbation factors such as network congestion and packet retransmission are not considered. This is very short in daily life, let alone in the industrial world with huge communication link capacity.

Next, we need to analyse communication costs from both theoretical derivation and ns-3 network simulation perspectives. Let | c | denote the bit length of a single ciphertext, | σ | the signature length, | t | the timestamp length. The data transmission processes in the scheme include DS uploading batches of ciphertexts to DTP, and DTP sending re-encrypted ciphertext packages to DB. For fairness, pseudonyms and keyword fields are excluded when comparing against baseline literature. The theoretical communication cost of our scheme is ( n + 1 ) · ( | c | + | σ | + | t | ). We set single ciphertext payload | c | = 120 bits, signature | σ | = 100 bits, timestamp | t | = 60 bits, and test n ∈ { 0 , 10 , 20 , … , 100 } data sellers. The communication volume comparison results against LBHP, ELDG, LBDG, DRQP are listed in Table 4 and visualized in Fig. 6. The proposed scheme maintains low transmission data volume across all participant scales; when n = 100, the total payload size is only around 3.5 KB.

We construct a standard urban logistics 5G network topology in ns-3 to obtain the baseline one-way transmission latency. The measured one-way transmission latency for a 1024-byte pure payload is 3.69 ms. Linear scaling is performed for a total payload size of 3.5 KB: total bytes = 3.5 KB = 3584 Bytes, scaling factor = 3584/1024 = 3.5, which yields a pure-payload one-way transmission latency of 3.5 × 3.69 = 12.915 ms. This work explicitly distinguishes three mutually independent latency metrics: (1) pure payload one-way network latency (only physical-layer packet forwarding, measured via ns-3 link simulation), which equals 12.915 ms for a 3.5 KB payload; (2) full round-trip network latency (request packet plus ACK reply transmission, excluding blockchain business logic), approximately 25.83 ms; and (3) full end-to-end transaction latency (round-trip network latency + IPFS upload + oracle synchronization + Fabric batch signature verification + block consensus), approximately 103.32 ms.

From the ns-3 experimental results in Fig. 7, the raw network forwarding overhead of 3.5 KB ciphertext batches is only ∼12.9 ms, which is negligible for logistics data trading systems. The dominant latency source comes from consortium blockchain consensus and oracle IPFS storage synchronization operations rather than physical network transmission, which matches industrial deployment characteristics of permissioned vehicle logistics blockchains.

This article aims to extract key information from express delivery orders and uses public datasets for federated learning training. In order to differentiate the quality of the model, we divided the dataset unevenly into three sub-datasets, with two of them being relatively close. The loss, F1, and training time of the trained model are shown in Fig. 8(a)–(c). After analysis, it can be seen that the federated model obtained through model parameter aggregation has obvious advantages. Specifically, it is characterized by minimal loss, fastest convergence, highest accuracy, highest F1 value, and minimum average training.

After the federated learning training process in Section 5.4, each of the three datasets generates a sub-model from which system parameters can be extracted, and then integrated to obtain the parameters of the federated model and the federated model. By extracting the first feature vector of each model parameter and performing cosine similarity measurement, cosine distances { C D_{m1, m2} = 0.094437396429111, C D_{m1, m3} = 0.11295942078994292, C D_{m2, m3} = 0.11139562839435492, C D_{m1, fem} = 0.13955981594752434, C D_{m2, fem} = 0.20707381409395367, C D_{m3, fem} = 0.13501420655496094} are obtained. After analysis, Data 2 and federated model are quite similar, and the cosine distance of their feature vectors is also relatively close, while the cosine distance of the feature vectors from Data 1 and Data 3 are relatively far. This is consistent with expectations and has good differentiation.

The original test only adopted a single express delivery order dataset to verify the model quality assessment algorithm and incentive mechanism. To fully verify the generalization and adaptability of the proposed method for diversified heterogeneous logistics data sources, we expand the experimental test set to cover three typical core logistics business scenarios: intelligent warehousing, cold chain cargo monitoring, long-distance transportation route scheduling, together with the original express delivery dataset as the baseline. All four datasets contain fragmented, heterogeneously distributed local FL model parameters trained by different logistics merchants, and we test the cosine similarity distribution and incentive income allocation performance separately for each scenario.

Scenario 1 (Baseline): Express delivery order dataset. Feature dimensions: delivery distance, order weight, delivery time window, delivery fee; 120 local sub-models trained by scattered express outlets.

Scenario 2: Intelligent warehousing dataset. Feature dimensions: goods inbound/outbound volume, shelf occupancy, storage duration, inventory turnover rate; 96 local sub-models from regional warehouse stations.

Scenario 3: Cold chain logistics monitoring dataset. Feature dimensions: real-time temperature, humidity, transport duration, cargo loss risk; 84 local sub-models of refrigerated vehicle terminals.

Scenario 4: Long-distance transportation route scheduling dataset. Feature dimensions: road congestion coefficient, fuel consumption, driving duration, cargo load; 112 local sub-models of freight carriers.

All datasets adopt FedAvg for local federated training, extract gradient feature vectors from each sub-model, and compute cosine similarity with the unified global benchmark model to quantify data quality; then calculate distributed revenue under the dual-weight incentive formula ( w _ 1 = 0.6, quality weight; w _ 2 = 0.4, participation time weight).

We count the cosine similarity C S _ i distribution range of local sub-models in each logistics scenario, and divide data quality into three grades: High quality ( C S i ∈ [ 0.8 , 1.0 ]), Medium quality ( C S i ∈ [ 0.4 , 0.8 ]), Low quality ( C S i ∈ [ 0 , 0.4 ]). The statistical distribution results of each scenario are as follows:

Across all four heterogeneous logistics datasets, our cosine similarity measurement method can stably generate continuous quality scoring values between 0 and 1, and clearly stratify high/medium/low-quality local models without failure of discrimination caused by inconsistent feature dimensions of different logistics businesses. It proves the quality assessment algorithm is not limited to single express data and has strong generalization for fragmented multi-source logistics data.

We fix the total transaction revenue Total = 10000 token in each scenario, and select three representative data sellers (high/medium/low quality, with equal participation service time) to compare the final allocated income calculated by our dual-weight incentive formula as shown in Table 5.

From the table above, under all four heterogeneous logistics datasets, the incentive mechanism maintains consistent differentiation logic: data sellers with higher model cosine similarity (higher data quality) obtain significantly higher transaction revenue, while low-quality noisy models get lower matching income. Even for cold chain datasets with more low-quality noisy sub-models, the dual-weight formula still effectively widens the income gap between high and low-quality participants, and the income proportion fluctuation of the same quality grade across different scenarios is controlled within 6.2%. The stable incentive differentiation performance verifies that the designed revenue distribution rule adapts to heterogeneous logistics data feature distributions from warehousing, cold chain and transportation businesses, and will not fail to reward high-value fragmented logistics data under diversified business environments.

By expanding experimental verification to intelligent warehousing, cold chain and transportation scheduling datasets besides the original express order data, we confirm two key generalization properties of the proposed quality assessment and incentive mechanism:

1) The cosine similarity feature vector extraction method can adapt to different feature dimensions and value distributions of heterogeneous logistics data, and stably realize quantitative grading of local FL model quality without scenario-specific parameter adjustment;

2) The dual-weight incentive formula based on quality and participation time maintains stable income differentiation ability across all mainstream logistics business scenarios, continuously motivating merchants to provide high-quality fragmented logistics model parameters regardless of data source types.

The multi-scenario test results fully eliminate the limitation of single-dataset verification and prove the strong environmental adaptability and generalization of the algorithm for diversified smart logistics data trading scenes.

To precisely clarify the novelty of our integrated logistics data trading scheme, we select eight highly representative SOTA works including blockchain-federated learning data trading architectures and lattice-based privacy-preserving cryptosystems for horizontal comparison. Table 6 systematically evaluates all schemes from seven core functional dimensions required by the reviewer: post-quantum security, lattice proxy re-encryption, dynamic authentication, quantitative data quality evaluation, differentiated incentive allocation, oracle-based on/off-chain consistency, and comprehensive experimental performance analysis.

From Table 6, all existing SOTA schemes have obvious functional fragmentation defects, while our work is the first integrated logistics data trading system that realizes all seven core required functions simultaneously, which precisely reflects the three orthogonal innovations proposed in this paper: Most blockchain-federated learning trading works (Xu et al., 2023; Tu et al., 2022; Lu et al., 2019; Li and Shi, 2024) adopt pairing/Paillier classical cryptography without post-quantum lattice support, lacking dynamic cross-buyer proxy re-encryption and cannot resist quantum attacks. Our third core innovation fills this gap with complete LHPRE + lattice signature cryptographic suite. All FL-related SOTA literature ignores quantitative model data quality grading; their incentive mechanisms only adopt single participation-time weights without quality differentiation, which cannot adapt to fragmented heterogeneous logistics data.

Neither lattice cryptography primitives nor existing blockchain trading platforms design dedicated oracle synchronization modules to resolve on-chain ledger and off-chain IPFS storage inconsistency. Our five-layer decoupled architecture (first contribution) embeds a complete bidirectional oracle read/write and error correction mechanism, a function completely absent in all compared references.

Additionally, all contrast works only conduct simulation experiments on a single fixed dataset, while our performance evaluation covers four mainstream logistics business scenarios (express, warehousing, cold chain, transportation), with more comprehensive and convincing test results. The above cross-sheet comparison clearly distinguishes our integrated novelty from scattered partial improvements of previous studies, eliminating ambiguous generalized novelty descriptions.

To verify the stability of the quality classification thresholds and the adaptability of the feature extraction algorithm to different model architectures, we conduct supplementary comparative experiments on four logistics datasets: Threshold sensitivity test: Adjust the high-medium boundary from 0.7 to 0.9 and medium-low boundary from 0.3 to 0.5. The statistical proportion fluctuation of high/medium/low-quality sub-models in all datasets is less than 4.3%, which verifies that the selected 0.4/0.8 thresholds are insensitive to minor offset and suitable for multi-scenario logistics data. Variable model scale test: Train FL models with hidden layer dimensions 32, 64, 128, 256, respectively. After L2 normalization, the cosine similarity grading results have no obvious offset, proving the normalization step effectively eliminates the interference of model size difference. Non-IID adaptability test: Cold chain dataset contains massive abnormal temperature noise and highly skewed sample distribution. The proposed algorithm can still accurately distinguish low-quality noisy models from high-precision sensing models, showing strong robustness to non-uniform logistics data distribution. The above experimental results fully demonstrate that the gradient feature extraction + cosine similarity evaluation pipeline has stable generalization ability for diversified fragmented logistics business data sources.

The Fabric network deployed for all experiments uses static unified parameters as follows (as shown in Table 7): 6 independent peer nodes (3 logistics merchants and 2 third-party auditors, and 1 DTP administrator node), SBFT (view change timeout = 4s, fault tolerance threshold t = 2 malicious peers), 2000 ms (block is sealed after timeout or when transaction batch hits maximum size), 200 concurrent transactions, single dedicated logistics data trading channel (isolated from other business ledgers), LevelDB for on-chain world state storage, IPFS v0.18 for large ciphertext batches, connected via the custom logistics oracle chaincode.

We implement four isolated Go chaincode contracts deployed on the single trading channel, each responsible for a full sub-business process:

RegisterUser(pid, role, publicLatticeKey): Record pseudonym, DS/DB/DTP role and user public lattice key to world state; execute distributed master key fragment distribution logic.

RevokeAuthCredential(pid, revokeReason): Write permanent revocation record to $AuthRevokeList$ for dynamic authentication failure handling.

QueryUserPolicy(pid): Return pre-defined RBAC access policy for subsequent trading authentication checks.

BatchVerifySignature(cipherBatch, aggLatticeSig): Batch BLS aggregate signature verification for uploaded FL model ciphertexts.

TriggerTradeRequest(dbPid, keyword, queryWindow): Validate dynamic one-time authentication credential before opening trading pipeline.

ExecuteLHPREReEncMetaRecord(dsPid, dbPid, reEncCipherHash): Log re-encryption metadata after DTP proxy transformation.

SyncIPFSHash(pid, keyword, ipfsTorrentHash, qualityScore): Real-time write binding record between ciphertext batch and IPFS storage address.

PeriodicConsistencyCheck(): Background 300s polling logic to detect file loss/hash mismatch and trigger correction transactions.

GetStoredCipherHash(pid): Authorized auditor interface to retrieve historical storage audit records.

CalcSingleIncome(csScore, normT, totalRevenue): Implement the dual-weight incentive formula income i = Total · w 1 C S i + w 2 T i ∑ ( w 1 C S k + w 2 T k ) with fixed w 1 = 0.6, w 2 = 0.4.

BatchSettleAllSellers(participantList): Traverse all DS participants in one trading batch and write immutable settlement records to blocks.

QueryHistoricalSettlement(pid, timeRange): Audit interface for historical profit distribution traceability.

Latency is dominated by the fixed 2000 ms block batch sealing timeout, throughput limited by small transaction batches. Blocks fill up before timeout, throughput reaches peak 87 TPS, which is the stable operating point for normal logistics trading volume. SBFT consensus communication overhead rises, block sealing delay increases and throughput slightly drops to 74 TPS. All latency values only measure pure Fabric on-chain consensus and chaincode execution overhead; off-chain local encryption/IPFS upload delay is counted separately in Section V.C communication experiments and not included here.