Block chain-based circulation box full life cycle management method and system, and program product

Abstract

The invention relates to a supply chain management method, in particular to a circulation box full life cycle management method and system based on a block chain and a program product. According to the method, logistics event information is collected and layered splitting is carried out, three parallel block chains including a logistics main chain, a carbon evaluation side chain and a prediction side chain are constructed, cross-chain atomic writing is realized in combination with two-stage submission and BLS aggregation signature, the residual life and path of a circulation box are predicted by using a digital twin model, and a carbon quota is dynamically allocated through deep reinforcement learning, so that the residual life and path of the circulation box are predicted. And finally, the position information privacy is protected by means of zero-knowledge proof. The circulation efficiency of the circulation box, the carbon emission reduction transparency and the system safety are remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to a supply chain management method, in particular to a circulating box full life cycle management method, system and program product based on a blockchain. BACKGROUND

[0002] Under the drive of the "double carbon" strategy and international regulations such as the European Union CBAM, bulk commodities (especially natural rubber, chemical raw materials, and other bulk goods) are required to quantify carbon footprints throughout the supply chain and improve packaging recycling rates. Traditional wooden pallets or paper boxes are one-time consumable and have low recycling rates, which not only wastes forest resources but also makes it difficult for enterprises to obtain LCIA (Life Cycle Impact Assessment) level emission reduction credits. Although steel / aluminum circulating boxes have been piloted on a large scale in the tire and chemical industries, there is still a lack of a unified and reliable recording mechanism for "who owns it, who is responsible, where it turns, and when it is repaired and scrapped", resulting in high loss and idle rates of packaging nets.

[0003] Existing domestic and foreign patents and researches use blockchain to store the circulation information of circulating boxes or recyclable packaging on a single chain, which can ensure that the information cannot be tampered with, but the writing chain performance decreases sharply with the amount of business, and cannot flexibly isolate permissions in carbon accounting, predictive maintenance, and other scenarios. For example, Chinese invention patent CN107766902A (a logistics box life cycle management method) uses a single chain structure and does not provide multi-dimensional data parallel processing and rollback solutions; Chinese invention patent CN110598882B focuses on end-of-life recycling and lacks real-time monitoring and predictive maintenance during the in-service phase.

[0004] US patent US20210224819A1 and related applications chain product carbon footprint as an independent asset, support consumer display and transaction, but do not link with the real-time status of specific logistics equipment, and cannot dynamically generate device-level carbon quotas or emission reduction incentives.

[0005] To solve the performance and privacy conflicts of the main chain, the academic community proposes a side chain / shard parallel architecture and explores "two-phase commit (2PC) + BLS aggregate signature" to realize multi-chain atomic transactions to reduce confirmation delay and simplify rollback. However, existing solutions are mostly focused on cross-chain assets, and there is no industry-level template for "logistics events + carbon events" double writing with a delay of ≤200ms, and there is also a lack of reputation ranking-based guide node election to resist Sybil attacks.

[0006] Paillier homomorphic encryption and Σ-protocol zero-knowledge proof are widely used in mobile crowdsensing, Internet of Vehicles and other scenarios, which can complete aggregation calculation and legal domain verification without exposing plaintext coordinates. However, how to directly use ciphertext coordinates for on-chain heat analysis on the logistics side and support multi-chain rollback and verifiable query still lacks end-to-end solutions. Graph neural network-long short-term memory (GNN-LSTM), Dual-LSTM and other hybrid models have been verified to control the equipment RUL mean square error within 5% directly MDPI. However, such predictions are usually run offline, and the results fail to form a closed-loop feedback with the on-chain real-time state and carbon quota, resulting in a lag in maintenance / retirement decisions.

[0007] Deep Deterministic Policy Gradient (DDPG) is used for energy scheduling, freight emission allocation and other problems due to its support for continuous action space. Existing research mainly focuses on power grid or vehicle energy consumption, and has not yet included logistics features such as "number of cycle box turns, inventory occupancy rate" in the state vector, and lacks on-chain autonomous contracts to instantly redeem deposit returns and carbon credit incentives. SUMMARY

[0008] To solve the above technical problems, the purpose of the present application is to provide a blockchain-based cycle box full life cycle management method, which constructs a three-chain parallel architecture of logistics main chain, carbon assessment side chain and digital twin prediction side chain, and introduces cross-chain atomic writing, homomorphic encryption-zero-knowledge privacy protection, GNN-LSTM remaining life prediction and DDPG adaptive carbon quota allocation, etc. Key technologies to achieve data credible record, location privacy security, intelligent maintenance decision and carbon emission reduction incentive automation throughout the cycle box from deployment to retirement process, thereby improving cycle box turnover efficiency, reducing loss rate and carbon footprint, and building a transparent, efficient and sustainable green supply chain for bulk commodities.

[0009] To achieve the above purpose, the following technical solutions are adopted:

[0010] A blockchain-based cycle box full life cycle management method, comprising the following steps:

[0011] S1 Layered information splitting

[0012] Collecting cycle box unique box number c and real-time logistics events, and splitting them into: logistics plaintext segment M, including event type, timestamp t, status code; location coordinate segment L; carbon emission segment E; encrypting the location coordinate segment L to obtain ciphertext Enc(L);

[0013] S2 Three-chain parallel construction

[0014] Parallelly maintaining in the same distributed node set: logistics main chain BC log ; carbon assessment side chain BCcarbon ; Predictive side chain BC twin ;

[0015] S3 Cross-chain atomic write

[0016] Select the top-k candidate nodes with reputation to form a guide cluster; adopt a two-phase commit and BLS aggregated signature cross-chain atomic commit protocol for the corresponding event block B in BC log Synchronization addition; if either chain fails, rollback through aggregated signature to ensure inter-chain consistency carbon ;

[0017] S4 Digital twin prediction and write chain

[0018] Run the loop box digital twin model on the Oracle node in BC twin , predict the remaining useful life RUL and future turnover path, write RUL and confidence to BC twin , and associate it to the corresponding block in BC log through hash reference

[0019] S5 Dynamic carbon quota redistribution

[0020] In the period ΔT, the carbon quota allocation algorithm based on deep deterministic policy gradient (DDPG) is executed by the side chain governance node, the input is: historical carbon emission records in side chain BC carbon , RUL prediction in BC twin ; output each participant's new quota Q and chain; when the actual emission reduction ≥ Q, the smart contract automatically returns the deposit and issues carbon credits.

[0021] As a preferred, the hierarchical information splitting and homomorphic encryption steps in step S1 satisfy the following mathematical relationship:

[0022] 1) Quantize and splice coordinates; m = x φ || x λ || x h ; where m: 96-bit spliced message; x φ , x λ , x h : 32-bit non-negative integers quantized from latitude, longitude, and altitude with 10 -6 ° / 1m precision; "||": concatenation operation according to fixed bit width order

[0023] 2) Use Paillier homomorphic encryption: Enc(L) = g m r n mod n 2 ; where g: Paillier system generator; n = pq: modulus, p, q are 1024-bit prime numbers One-time random number; Enc(L): position coordinate ciphertext.

[0024] As preferred, step S2 three chains are constructed in parallel to meet:

[0025] 1) Block period Δt log = 5s, Δt carbon = 60s, Δt twin = 300s; wherein, Δt log , Δt carbon , Δt twin : target block interval of logistics main chain, carbon side chain, and prediction side chain;

[0026] 2) Byzantine fault tolerance upper limit

[0027]

[0028] Wherein, f: number of Byzantine nodes tolerated by each chain; Number of nodes participating in consensus of chain x; Floor operation.

[0029] As preferred, step S3 cross-chain atomic writing adopts:

[0030] 1) Local locking hash: h i = H(B||ctx||i); wherein, H: SHA-256 hash function; B: event block to be written; ctx: transaction context identifier; i: leading node index number;

[0031] 2) Aggregated locking hash: Hash agg = H(h1||h2||…||h k ); wherein Hash agg : two-chain locking identifier; k: number of leading nodes;

[0032] 3) Aggregated signature verification: e(∑ agg , g) = e(H1(Hash agg ), P agg ); wherein, ∑ agg : BLS aggregated signature; g: elliptic curve generator; H1: hash function mapping messages to group G1; Sum of leading node public keys; e: pairing operation.

[0033] As preferred, step S4 digital twin prediction meets:

[0034] 1) Graph convolution

[0035]

[0036] Wherein, Add self-loop adjacency matrix; Degree matrix; W (l) : 1st layer convolution weight; σ: ReLU activation function;

[0037] 2) RUL regression

[0038]

[0039] Where, Z c，t : LSTM output vector; W r , b r : Regression layer weight, bias;

[0040] 3) Confidence

[0041]

[0042] Where, MC-Dropout prediction variance; Empirical maximum variance upper bound.

[0043] As a preferred, the step S5 dynamic carbon quota redistribution step adopts a deep deterministic policy gradient (DDPG) algorithm, specifically comprising:

[0044] 1) Construct state vector:

[0045]

[0046] Where, Unit carbon emission sequence; Turnover frequency sequence; p i，t : Inventory occupancy rate; Predicted remaining life; q i，t-1 : Last period quota;

[0047] 2) Output continuous action through Actor network, and calculate new quota:

[0048] a i，t ∈[-0.2, 0.2], q i，t =q i，t-1 (1+a i，t );

[0049] Where, a i，t : Actor output continuous action; q i，t : New quota.

[0050] 3) Reward function

[0051]

[0052] Where, Target emissions; Actual emissions; Δrep i，t : Reputation increase or decrease; α, β, γ: positive weights, α+β+γ=1.

[0053] As preferred, the method further comprises a step S6 of zero-knowledge privacy verification, proving that Enc(L) written in step S3 belongs to a legal coordinate domain using Σ-protocol zero-knowledge proof to the entire network without revealing the plaintext position pair position; generating and verifying the Σ-protocol proof π for the position ciphertext Enc(L), and the on-chain verification condition is:

[0054] 1) Main verification equation

[0055] g s η n ≡tc e (modn 2 );

[0056] Wherein, g: Paillier generator; s=α+em: response value; η=ρr e modn: response random term; t=g α ρ n modn 2 : commitment; c=Enc(L): position ciphertext; e=SHA256(t||c||txHash)mod2 128 : Fiat-Shamir challenge; n: Paillier modulus;

[0057] 2) Legal domain constraint

[0058] 0≤m<2 96 ;

[0059] Wherein, m: 96-bit coordinate message after quantization and splicing.

[0060] Further, the present application also provides a circulation box multi-chain management system for executing the method, comprising:

[0061] a) Acquisition terminal: with RFID / barcode scanning and GNSS module, capable of encrypting (c, M, L, E) data packet and uploading to the chain;

[0062] b) Distributed chain service cluster: at least including logistics main chain node, carbon side chain node, prediction side chain Oracle node and privacy relay node;

[0063] c) Cross-chain coordinator: realizing two-phase commit and atomic writing of BLS aggregation signature;

[0064] d) Privacy proof engine: providing Σ-protocol proof generation and verification;

[0065] e) Smart contract module: deploy the deposit escrow contract, carbon credit settlement contract and abnormal warning contract;

[0066] f) Digital twin engine: real-time calculation of RUL and writing of prediction results into BC twin .

[0067] Further, the application also provides a computer readable storage medium, which stores a computer program or instructions, and the computer program or instructions are executed by a processor to realize the steps of the method.

[0068] Further, the application also provides a computer program product, which comprises a computer program or instructions, and the computer program or instructions are executed by a processor to realize the steps of the method.

[0069] The application has the following technical effects due to the adoption of the above technical scheme:

[0070] 1. The writing chain performance is significantly improved: the logistics events and carbon assessment transactions are written into the chain through three-chain parallelism + two-phase commit + BLS batch signature, avoiding single-chain congestion; in the actual measurement of 300,000 circulating box scenarios per year, the average writing chain delay of a single box is reduced from 420 ms to 185 ms, a reduction of about 55%; the throughput is maintained at >1000 TPS, meeting the needs of second-level visualization.

[0071] 2. The consistency between chains and the anti-tampering ability are enhanced: the reputation-driven guide cluster ensures that each transaction is written into BC_log and BC_carbon at the same time; any malicious tampering by a node will destroy the aggregated signature and be immediately rejected by the consensus mechanism; when network or node failure triggers rollback, the height of the two chains is always consistent, ensuring that carbon accounting and logistics tracking are never "misaligned".

[0072] 3. Position privacy and computability are considered: coordinates are written in the form of Paillier homomorphic ciphertext; Σ-protocol only verifies that "coordinates fall within the legal interval" without exposing the plaintext, and has intercepted 100% of abnormal coordinates in half a year, with zero leakage events; homomorphic aggregation can directly generate a route heat map on the chain, providing statistical support for path optimization and trunk scheduling.

[0073] 4. Prediction-driven asset utilization improvement: the GNN-LSTM digital twin model controls the residual useful life (RUL) prediction mean square error of circulating boxes to ≤5%; the maintenance / scraping decision is changed from "after-response" to "7-day early warning", the box loss rate is reduced from 2.3% to 1.2%, and the idle rate is reduced by 12%.

[0074] 5. Dynamic carbon quota and economic incentive closed loop: DDPG strategy fine-tunes quota daily in continuous action space, both suppressing drastic fluctuations and fully rewarding low-emission nodes; sidechain smart contract automatically hosts deposit and mints carbon credit NFT, six-month trial operation increases per capita carbon credit by 15%, and total CO2 equivalent emissions decrease by about 8%.

[0075] 7. Significant reduction in audit and compliance costs: carbon sidechain automatically aggregates life cycle data and generates ISO14067-compatible reports without manual table stitching; single third-party audit man-hours are reduced from 120h to 35h (-71%), while ensuring report traceability and non-repudiation.

[0076] 8. System security and scalability: verifiable delay function (VDF) randomly elects leaders, significantly reducing the success rate of targeted attacks; BFT-SMaRt consensus tolerates ≤f Byzantine nodes while maintaining service availability; modular sidechain and microservice design supports seamless expansion to other circulating devices such as pallets and turnover buckets, requiring only adjustments to terminal identification and model parameters to reuse all processes.

[0077] In summary, the present invention has achieved a quantitative leap in performance, credibility, privacy protection, asset utilization, emission reduction incentives, and audit efficiency, forming a closed-loop management system for the life cycle of the circulating box, which includes "trusted records-privacy security-predictive decision-making-smart incentives". BRIEF DESCRIPTION OF DRAWINGS

[0078] Figure 1 The figure is a schematic diagram of the overall architecture of the circulating box multi-chain management system of the present invention.

[0079] Figure 2 The figure is a flowchart of the method of the present invention.

[0080] Figure 3 The figure is a flowchart of layered information splitting and encryption.

[0081] Figure 4 The figure is a schematic diagram of the parallel construction logic of the three chains.

[0082] Figure 5 The figure is a timing diagram of cross-chain atomic write.

[0083] Figure 6 The figure is a data flow diagram of digital twin prediction and write chain.

[0084] Figure 7 The figure is a flowchart of dynamic carbon quota redistribution based on DDPG.

[0085] Figure 8 The figure is a flowchart of zero-knowledge privacy verification (Σ-protocol). DETAILED DESCRIPTION

[0086] The technical solutions in the embodiments of the present invention will be clearly and completely described below. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the present invention.

[0087] I. System Overall Architecture

[0088] like Figure 1 As shown, this invention provides a blockchain-based green supply chain circular management system for bulk commodities. Its system structure consists of six logical layers: terminal layer, edge layer, chain service cluster, service platform, and operation / storage layer. These layers work together to build a green supply chain information platform with high security, transparency, and predictive capabilities. The system architecture is as follows: Figure 1 As shown, the specific structure and functions are as follows:

[0089] 1. Terminal layer

[0090] The terminal layer includes two types of information collection devices: a handheld RFID / QR code collection terminal 10 and a gantry scanner. This layer is used to collect key data in real time at each node during the circulation of the reusable container, including container number, location information, event type, and timestamp, and uploads the collected data to the upper-level edge layer for preliminary processing.

[0091] 2. Edge layer

[0092] Edge gateway 20 is deployed at the edge layer. It is responsible for receiving data collected by the terminal, performing necessary preprocessing operations (such as data compression, encryption, and classification), and then forwarding the information to each blockchain node in the chain service cluster to ensure the standardization and integrity of the data before it enters the chain.

[0093] 3. Chain service cluster 30

[0094] The blockchain service cluster consists of three types of nodes, each undertaking different responsibilities for the blockchain ledger:

[0095] 1) Main Nodes of the Logistics Chain (BC) log Records information such as logistics events, operational status, and tracking routes for the reusable container;

[0096] 2) Carbon side chain nodes (BC) carbon Records the carbon emissions generated by each logistics event and supports carbon quota management;

[0097] 3) Predicting sidechain Oracle nodes (BC) twin ): Run the digital twin prediction model to generate prediction data for the remaining lifetime (RUL) of the cycle tank and its future path.

[0098] 4. Service middle station 40

[0099] The service middle station is the intelligent control center of the system, mainly including four core function modules:

[0100] 1) Cross-chain coordinator: realizes information synchronization, two-phase commit, atomic write and other functions between multiple chains;

[0101] 2) Privacy proof engine: used to generate Σ-protocol zero-knowledge proof for sensitive data such as encrypted location coordinates Enc(L);

[0102] 3) Digital twin engine: based on historical on-chain data and real-time logistics state, running life cycle prediction algorithm;

[0103] 4) DDPG scheduler: periodically running carbon quota redistribution algorithm based on deep deterministic policy gradient.

[0104] 5. Operation and storage layer

[0105] Including:

[0106] 1) Object storage system 50: responsible for long-term storage and indexing of on-chain and intermediate processing data;

[0107] 2) Monitoring and alarm module: real-time monitoring of chain node running state, network communication status and data anomalies, and issuing early warning when anomalies occur.

[0108] 6. Explanation of data flow relationship among modules

[0109] The terminal device sends the collected data to the edge gateway; the gateway sends the data to the BC log , BC carbon , BC twin three chains; BC log and BC BC carbon data through the cross-chain coordinator for consistency control; the prediction result of BC twin is transmitted to the digital twin engine, and is fed back to the service DDPG scheduler; the data of each chain is uniformly written to the object storage, and is uniformly managed by the monitoring and alarm system.

[0110] II. Method implementation steps

[0111] S1 Specific implementation method of layered information splitting

[0112] 1.1 Collection and field splitting

[0113] 1) Collect the unique box number c of the circulating box

[0114] The terminal obtains a 24-bit string, such as CICB-2025-00012345, through RFID or QR code scanning. This number is used as the primary key in the system and cannot be repeated.

[0115] 2) Real-time logistics event collection

[0116] The terminal triggers an event callback at each loading, unloading, warehousing, delivery, inventory, etc. node, and immediately records: event type event_type (such as LOAD, UNLOAD, CHECK_IN), timestamp t (millisecond-level UTC), status code status_code (0 = normal, > 1 indicates abnormal).

[0117] Three items are combined into a logistics plaintext fragment M = (event_type, t, status_code);

[0118] 3) Location coordinate fragment L

[0119] Use a dual-frequency GNSS module to obtain WGS-84 coordinates: latitude φ, longitude λ (both retain 1 μ°, i.e. 1 × 10 -6 °), and altitude h (m). Quantize the floating point number to a 32-bit integer:

[0120] x φ = round(φ × 10 6 ), x λ = round(λ × 10 6 ), x h = round(h);

[0121] Assemble into a three-tuple L = (x φ , x λ , x h ).

[0122] 4) Carbon emission fragment E

[0123] The terminal or gateway converts the energy consumption of this node into an instantaneous equivalent, obtaining CO2 co2_eq (g) and energy consumption category energy_id (electricity, diesel, natural gas, etc.). Represented as E = (co2_eq, energy_id); At this point, the raw data is split into c, M, L, E four parts.

[0124] 1.2 Paillier homomorphic encryption of location coordinate fragment L

[0125] 1.2.1 Key generation (system initialization once)

[0126] 1) Randomly select two large prime numbers of the same number of bits:

[0127] 2) Calculate modulus: n = p x q;

[0128] 3) Calculate lambda: lambda = lcm(p-1, q-1);

[0129] 4) Select

[0130] μ = (L_n(g λ mod n 2 )) -1 mod n;

[0131] where,

[0132] 5) Public key: pk = (n, g), sk = (lambda, mu).

[0133] 1.2.2 Coordinate encoding

[0134] Concatenate three-dimensional coordinates into a non-negative integer message: m = x φ ‖x λ ‖x h ; Where "‖" represents concatenation in fixed 32-bit width order (96 bits in total, value < n).

[0135] 1.2.3 Encryption calculation

[0136] Generated by NIST SP-800-90A compliant true random source

[0137]

[0138] Calculate ciphertext Enc(L) = c = g m r n (mod n 2 ).

[0139] 1.2.4 Parameter and symbol explanation

[0140]

[0141] 1.2.5 Result packaging and transmission

[0142] The terminal packs (c, M, E, pk_id) in CBOR format and uploads it to the edge gateway through TLS1.3. pk_id is the public key version number, which is convenient for subsequent rotation. Ciphertext c and hash SHA256(c) will be written to the logistics main chain, and the original coordinates are only visible in the decryption authority node, meeting the requirements of privacy protection and on-chain computability.

[0143] Through the above steps, the position coordinates are securely converted into homomorphic computable ciphertexts while maintaining logical association with the logistics plaintext segment M and the carbon emission segment E, laying a data foundation for subsequent cross-chain atomic writing, heat aggregation analysis, and zero-knowledge verification.

[0144] S2 Three-chain parallel construction

[0145] In the same distributed node set , three independent but interoperable chains are running simultaneously: logistics main chain BC_log, carbon assessment side chain BC_carbon, and prediction side chain BC_twin. The three chains share the underlying communication layer, key system, and monitoring facilities, but are isolated in terms of ledger data, consensus instances, and access permissions. The following explains each item in terms of network topology, ledger design, consensus configuration, cross-chain identification, and governance mechanisms.

[0146] 2.1 Network and node role division

[0147] 1) Node set

[0148] 2) Divide into three logical roles

[0149] Logistics main chain node set

[0150] Carbon side chain node set

[0151] Prediction side chain Oracle node set

[0152] And

[0153]

[0154] Some nodes represent multiple chain functions to save hardware resources and reduce cross-chain communication delay.

[0155] Among them, the total set of blockchain server nodes; the total number of nodes; respectively undertake the consensus of the three chains.

[0156] 2.2 Ledger and namespace

[0157] 1) Double block format

[0158] Each chain uses a unified block header with chain identifier chain_id:

[0159] block = (header, tx_list),

[0160] header = (prev_hash, merkle_root, timestamp, chain_id);

[0161] chain_id = 0x01 represents BC_log,

[0162] chain_id = 0x02 represents BC_carbon,

[0163] chain_id = 0x03 represents BC_twin.

[0164] 2) Data namespace

[0165] BC_log only accepts LogTx type transactions, fields are (c, M_hash, EncL_hash)

[0166] BC_carbon only accepts CarbonTx, fields are (c, CO2eq, energy_id)

[0167] BC_twin only accepts TwinTx, fields are (c, RUL, conf, ref_hash)

[0168] Wherein, prev_hash: previous block hash; merkle_root: current block transaction merkle root; chain_id: chain identifier; LogTx, CarbonTx, TwinTx: three types of incompatible transaction structures.

[0169] 2.3 Consensus algorithm and time parameters

[0170] Three chains run improved BFT-SMaRt instances, but have different block periods and transaction pool thresholds to adapt to different data frequencies.

[0171] Δt log = 5s, Δt carbon = 60s, Δt twin = 300s;

[0172] Wherein, Δt log : main chain block interval; Δt carbon : carbon side chain block interval; Δt twin : prediction side chain block interval.

[0173] The Byzantine fault tolerance upper limit satisfies:

[0174]

[0175] Wherein, Δt log , Δt carbon , Δttwin : Target block time of three chains; f: Upper limit of tolerated malicious nodes; Number of nodes joining consensus of chain x.

[0176] 2.4 Cross-chain identification and reference

[0177] To establish data association between chains, a unified hash reference is introduced:

[0178] h = H SHA256 (tx_hash‖chain_id);

[0179] When BC_twin generates TwinTx, write h into field ref_hash, pointing to the hash of LogTx with the same box number in BC_log; BC_carbon can reference h of TwinTx as needed to associate the predicted remaining life. Wherein, H SHA256 : SHA-256 hash function; tx_hash: original transaction hash; h: cross-chain lightweight reference pointer.

[0180] 2.5 Guidance and governance

[0181] Genesis block writes unified system parameters: fields such as (pk, Δt, chain_regex, governance_addr) are recorded in three chains to ensure that parameters are read-only and traceable.

[0182] On-chain governance contract is deployed in BC_carbon: maintain node reputation score rep(n_i), provide metrics for subsequent cross-chain atomic write phase to select guided cluster; automatically process chain parameter upgrade proposal, pass BFT voting to reach ≥2 / 3 of the approving parties to take effect.

[0183] 2.6 Start-up and running process

[0184] 1) The system administrator issues three configuration files config_log.yml, config_carbon.yml, config_twin.yml to all nodes, specifying the port, node public key list and block time of each chain instance.

[0185] 2) Nodes start three consensus processes in turn, each process listens to an independent port; share the same TLS certificate and hardware key slot.

[0186] 3) The scheduling script detects process survival and performs health checks regularly; if a chain instance fails, the scheduler first replaces the container on the same machine, and if it is invalid, it triggers dynamic member change on the standby machine to remove the failed node from the consensus.

[0187] Through the above method, the logistics main chain, the carbon side chain and the prediction side chain realize logical isolation, time dislocation, and governance unified "parallel three-chain" operation mode in the same physical node cluster, which not only guarantees the real-time performance of high-frequency logistics writing, but also provides sufficient bandwidth for carbon accounting and prediction analysis, and lays a structural foundation for subsequent cross-chain atomic writing and privacy calculation.

[0188] S3 cross-chain atomic writing

[0189] Cross-chain atomic writing ensures that the same logistics event takes effect on BC_log and BC_carbon at the same time or rolls back at the same time, and there is no intermediate state. The protocol is divided into three stages: leader election of bootstrap cluster, two-phase commit, and aggregated signature rollback.

[0190] 3.1 Leader election of bootstrap cluster

[0191] 1) Node reputation score calculation

[0192] In the governance contract, each node n i maintains the reputation score in real time:

[0193] R(n i )=w1U i +w2(1-E i )+w3S i +w4Q i ;

[0194] Where, U i is the online rate in the past week; E i is the block error rate (the number of proposals rejected / rolled back); S i is the normalized value of the staked amount; Q i is the inverse of the average confirmation delay in the past month; w1…w4 are weight constants, satisfying ∑w j =1.

[0195] 2) Candidate set generation

[0196] The governance contract executes select_k_leaders(k) every τ=10 minutes:

[0197] Sort all nodes in descending order of R(n i ); take the top k to form the bootstrap cluster: If the same score, randomly scatter through the output of the verifiable delay function VDF. Where, R(n i ): node reputation score; w j : weight; τ: election period; k: number of bootstrap nodes; This round of bootstrap cluster.

[0198] 3.2 "Two-phase commit + BLS aggregated signature"

[0199] Preceding data: Event block B = (header, tx_list) to be written, where tx_list contains at least a logistic transaction LogTx and a carbon transaction CarbonTx.

[0200] First stage: Preparation and locking

[0201] 1) The coordinator broadcasts PREPARE (B, ctx) to all the bootstrap nodes; ctx is the context identifier of the current transaction.

[0202] 2) Each bootstrap node generates a local hash: h i = H (B || ctx || i);

[0203] 3) The coordinator calculates an aggregated locking hash: Hash agg = H (h1 ||... || h k );

[0204] 4) Hash_agg is written into the locking block of both chains; its status is marked as PREPARED.

[0205] Second stage: Confirmation and commitment

[0206] 1) Each bootstrap node signs Hash_agg using the BLS private key s i : σ i = s i · H1 (Hash agg ); where H1: {0, 1} \* → G1 is a hash function that maps messages to the curve group G1.

[0207] 2) The coordinator collects k local signatures and performs linear aggregation:

[0208]

[0209] 3) Calculate the aggregated public key:

[0210]

[0211] 4) Broadcast COMMIT (B, Hash_agg, Σ_agg) to both chains. Each node verifies:

[0212]

[0213] If the equation is true, the node officially appends B to the tail of each chain and changes the status of the locking block to COMMITTED. Wherein, H: SHA-256 hash function; H1: BLS message mapping function; g: curve generator; e(·, ·): pairing operation; P i : node n i ​BLS public key of the leader; σ i : local signature;∑ agg : aggregated signature.

[0214] 3.3 Failure detection and aggregated signature rollback

[0215] Let T commit be the maximum acceptable commit time limit of the entire network (e.g., 200 ms). If any chain does not enter the COMMITTED state within T commit, rollback is triggered:

[0216] 1) The leader node regenerates the aggregated signature with the same batch of signatures:

[0217]

[0218] 2) The coordinator broadcasts ROLLBACK (Hash agg,∑ rollback agg) to both chains.

[0219] 3) After verifying the signature, each node changes the corresponding lock block state to ABORTED and discards the block B content; the main chain and the side chain remain highly consistent.

[0220] 4) Consistency guarantee theorem

[0221] If the aggregated cluster satisfies and all normal nodes comply with the protocol, the same transaction can only be simultaneously COMMITTED or ABORTED on both chains, and there is no divergent state. Among them, T commit: commit timeout threshold; aggregated signature for rollback; f: tolerable number of Byzantine nodes.

[0222] 5) Protocol delay and security boundary

[0223] Network propagation d net and signature verification d sig are both sub-millisecond level;

[0224] Total protocol delay:

[0225] D total ≈d net +2d sig +Δt consensus ;

[0226] The measured D total is kept at 110-180 ms.

[0227] When there are at most f malicious nodes in the leader cluster and they deliberately refuse the second stage signature, the transaction will be consistently rolled back; the malicious node reputation score is immediately reduced by δR, and the weight is reduced in the next round of election.

[0228] This step realizes low-latency, high-security cross-chain atomic writing between BC_log and BC_carbon through reputation-driven guided election, two-stage transaction locking, and one-time aggregate signature verification, and can automatically roll back when any chain fails, ensuring consistency between the two chain ledgers.

[0229] S4 Digital Twin Prediction and Write Chain

[0230] The goal of this step is to use digital twin technology to predict the remaining useful life (RUL) and future K-step turnover path for each circulating box in the prediction side chain BC_twin in real time, and then write the prediction results to the blockchain and hash-level anchor with the logistics main chain BC_log to form a verifiable and traceable "state-prediction" closed loop. The entire process consists of five stages: data preparation, space-time representation, RUL calculation, path inference, and chain anchoring.

[0231] 4.1 Data Preparation: Map Discrete Events to Space-Time Tensors

[0232] The Oracle node first retrieves the latest N logistics events {M t-N+1 , …, M t} of box number c within the time window: T = 24h. Each event contains node identification, event type, duration, etc. properties. Combined with the warehouse-port-mainline topology, a static directed graph G = (V, E) is obtained. Then for each topology node v ∈ V, a feature vector is constructed:

[0233]

[0234] turnover v,τ : the turnover count of node v at time τ; dwell v，τ : the dwell time of the box at node v; temp v，τ , hum v，τ : the ambient temperature and humidity at the time.

[0235] 4.2 Space-Time Representation: Use GNN to Extract Spatial Relationships and LSTM to Encode Temporal Evolution

[0236] 1) Spatial Convolution

[0237] A normalized adjacency matrix with self-loops is used Extract neighbor influence:

[0238]

[0239] 2) Time Encoding

[0240] Send the latest N-step spatial feature sequence to LSTM:

[0241]

[0242] where, W (l) : the l-th layer graph convolution weight; σ: ReLU activation function; Z v，t : the space-time vector representation of node v at time t.

[0243] 4.3 RUL computation and confidence evaluation

[0244] 1) Regression layer

[0245]

[0246] 2) Confidence (MC-Dropout)

[0247] Repeat turning off random neurons m times in the inference phase to get the prediction variance

[0248]

[0249] Renormalize to 0-1 interval confidence

[0250]

[0251] where, r , b r : regression layer weight and bias; · m: Dropout sampling times; · Empirical maximum variance upper bound.

[0252] 4.4 Future path inference: probability beam search

[0253] For the subsequent K-step direction of the prospect box, use softmax-BeamSearch:

[0254]

[0255] Finally output the highest probability path π \* . Where, K: prediction depth; π k : the k-th step position node; W p : path prediction weight matrix.

[0256] 4.5 Write chain anchoring: permanently bind the prediction result to the logistics true trace

[0257] 1) Transaction packaging Oracle will

[0258]

[0259] push to BC_twin. Where,

[0260] ref_hash = H(tx_hash log || 0x01);

[0261] Anchoring the prediction record to the hash of the latest logistics transaction with the same container number in BC_log.

[0262] 2) The consensus node verifies the signature sig and packages the TwinTx into a block. At this point, the logistics state and the prediction data form a traceable one-to-one mapping, and any querying party can quickly locate it across the chain through ref_hash.

[0263] Through the above process of "spatiotemporal coupling model → RUL + confidence → on-chain anchoring", the invention not only guarantees the prediction accuracy, but also realizes the trusted writing chain and global sharing of digital twin results, laying a data foundation for subsequent dynamic carbon quota adjustment and abnormal early warning.

[0264] S5 Dynamic carbon quota redistribution

[0265] This step uses the deep deterministic policy gradient (DDPG) framework to let the governance nodes of the carbon side chain BC_carbon dynamically issue tradable carbon emission quotas Q for each business participant within a fixed period ΔT. The process can be divided into four stages: state construction, policy inference, on-chain validation, and performance settlement. By converting historical emissions, device health (RUL), and other information into quota adjustment amounts in a continuous action space, the invention realizes an adaptive closed loop of "the less emissions, the wider the quota, and the higher the incentive".

[0266] 5.1 State construction: mapping on-chain indicators to DDPG input vectors

[0267] In each governance period ΔT = 24h; the governance nodes summarize the data of the system participant set one by one. For any node p i , construct the current state vector:

[0268]

[0269] Where n: sliding window length (days); Unit emission vector of node i in the last n days (gCO2 / turnover); Turnover frequency vector in the same period; p i，t : Real-time inventory occupancy rate of node (0-1); Average remaining useful life given by the prediction side (days); q i，t-1 : Last period effective quota; constant 1 provides a bias channel.

[0270] This combination not only reflects the emission history but also incorporates device health, providing a rich context for the policy network.

[0271] 5.2 Strategy inference: map state to quota adjustment Δq

[0272] DDPG consists of two networks, Actor (strategy) and Critic (value), whose weights are denoted by θ and φ, respectively.

[0273] 1) Action definition

[0274] Continuous action a i，t = Δq i，t ∈ [-η, η], η = 0.2; represents a proportional adjustment of ±20% on the previous quota q i，t-1 .

[0275] 2) Quota update formula

[0276] q i，t = max(q min , min(q max , q i，t-1 [1 + a i，t ])) ;

[0277] where η: upper limit of action; q min , q max : system-level quota hard threshold; q i，t : new quota for this period.

[0278] 3) Reward function

[0279] To encourage emission reduction and avoid drastic fluctuations, the immediate reward is designed as:

[0280]

[0281] where α, β, γ: positive weights, α + β + γ = 1; quota-adjusted target emission; actual emission of node; Δrep i，t : credit increase / decrease value (emission reduction score - violation penalty) for this period.

[0282] 4) Network training and update

[0283] Use priority experience replay (PER) to retain the last 10 6 interactions.

[0284] Target network soft update; θ - ← τθ + (1 - τ)θ - , φ - ← τφ + (1 - τ)φ - ;

[0285] where θ - , φ -: Actor, Critic target network weights; τ: soft replacement rate, τ = 0.005.

[0286] After multiple iterations, the Actor learns to issue quotas to nodes with higher emission reduction potential and healthier RULs while ensuring fairness.

[0287] 5.3 On-chain enforcement: new quotas are recorded persistently with QuotaTx

[0288] After policy inference, the governance node creates a QuotaTx for each p i Create a transaction

[0289] QuotaTx i = (p i , q i，t , period = t ， sig gov ) ;

[0290] and submits it to BC_carbon. Consensus nodes package all QuotaTx in the next block cycle to form the only trusted snapshot of quota allocation. Among them, sig gov : the governance private key signs the transaction hash.

[0291] 5.4 Performance settlement: deposit return and automatic minting of carbon credits

[0292] Each business node needs to lock up a refundable deposit d i，t = λq i，t before the quota takes effect; where λ is the deposit unit price ($ / kgCO2$).

[0293] At the end of the period, the sidechain Oracle aggregates the actual emissions

[0294] 1) Emission reduction compliance

[0295] Contract execution

[0296]

[0297] That is, the full deposit is returned, and carbon credits NFTs are minted according to the amount of savings.

[0298] 2) Excessive emissions violation

[0299] Destroy a portion of the deposit d i，t κ (k ∈ (0, 1] is the penalty coefficient), and deduct the credit; the next period quota is forced to be reduced.

[0300] This directly links economic benefits with low emissions, and promotes all nodes to take active energy-saving measures.

[0301] Through the above interwoven text and formula design, the application organically combines reinforcement learning strategy decision, blockchain storage and economic incentive, and realizes intelligent, transparent and self-evolution distribution of the recycling box carbon quota.

[0302] S6 zero-knowledge privacy verification

[0303] In the aforementioned cross-chain atomic write link, the precise coordinates L of the recycling box have been encrypted as Enc(L)=c using the Paillier public key and written to BC_log. In order to make any third party believe that "this is indeed a set of three-dimensional geographic coordinates and located in the physically feasible range Omega" without decrypting the coordinates, the application adds a non-interactive Sigma-protocol zero-knowledge proof π to BC_log.

[0304] 6.1 Target statement

[0305] We want to prove to all verifiers that the proposition:

[0306] Stmt: [ Make c=g m r n modn 2 ∧0≤m<B];

[0307] Where, c—write chain ciphertext Enc(L); g, n—Paillier public key parameters; m—96-bit integer after quantization and splicing of three-dimensional coordinates; B=2 96 —upper bound (ensure that the coordinates are located in the legal domain Omega); —Paillier random number.

[0308] The prover (private relay) knows (m, r), and the verifier only sees (c, n, g).

[0309] 6.2 Interactive Sigma-protocol three-step process

[0310] Step1 Commit—Commit

[0311] Prover optional:

[0312]

[0313] Calculate t=g α ρ n modn 2 ; and send t to the verifier.

[0314] Step2 Challenge—Challenge

[0315] Verifier Randomly Selects

[0316]

[0317] Step3 Response—Response

[0318] Prover computes s = α + e e (mod n); and returns (s, η).

[0319] Step4 VerifierCheck

[0320] Verifier accepts if and only if g s η n ≡ t e (mod n 2 ); and s < B + eB. The equality can be directly derived from the Paillier homomorphic property, which must hold as long as (m, r) is legal, otherwise it fails with high probability. Here, α, ρ—commitment random numbers; t—commitment value; e—random challenge (λ-bit); s, η—response pair; λ—statistical zero-knowledge security parameter.

[0321] 6.3 Non-interactive: Fiat–Shamir Transformation

[0322] To avoid repeated interactions on-chain, use Hash-Fiat–Shamir to replace the challenge e with

[0323] e = H(t‖c‖txHash log ) mod 2 128 ;

[0324] where txHash log is the on-chain transaction hash; H takes SHA-256.

[0325] The proof π then only needs to contain π = (t, s, η), and any on-chain node can locally recompute e and verify the equality (6-4) to complete the one-time, public, and traceable verification.

[0326] 6.4 Three-Dimensional Interval Proof Extension

[0327] When g s η n ≡ t e (mod n 2 ) only guarantees m < B, it still lacks the fine-grained constraints of “latitude in [-90°, 90°], longitude in [-180°, 180°], and altitude in [-1000m, 10000m]”.

[0328] Therefore, for the 32-bit subfield

[0329] m φ = m mod 2 32 ,

[0330] respectively, and then pack the three sub-proofs π φ , π λ , π h with the main proof π.

[0331] The verification side replaces the upper bounds B φ , B λ , B h in turn, and can be checked in parallel. The entire process still maintains one broadcast, parallel verification, and zero leakage.

[0332] The above steps provide a publicly verifiable legal domain proof for the entire network without leaking the plaintext coordinates through the combination of "commit-challenge-response + Fiat-Shamir + three-dimensional range proof", perfectly balancing the dual needs of privacy protection and data trust.

[0333] III. Example: 300,000 cases of circulating cases in the natural rubber supply chain for half a year of contrast test run

[0334] 1. Test design

[0335]

[0336]

[0337] 2. Execution steps

[0338] 1) Parallel three-chain deployment: the test group initializes BC log / BC carbon / BC twin on 7 servers; the control group only deploys a single chain.

[0339] 2) Cross-chain atomic writing: all logistics events in the test group are written to the double chain according to the S3 process; the control group only writes to the main chain, and the carbon data is manually aggregated every week.

[0340] 3) Digital twin prediction: the test group Oracle runs GNN-LSTM every 5 minutes, outputs RUL and confidence, and writes to BC twin .

[0341] 4) Quota scheduling: the test group runs DDPG daily, dynamically issues quotas, and manages them through the deposit contract; the control group manually issues them monthly.

[0342] 5) Privacy verification: the test group adds Σ-proof to each Enc(L); the control group writes the coordinates in plaintext to the chain.

[0343] 6) Data collection: Prometheus unified scraping write-chain latency and chain height; energy meter auto-uploading CO2eq.

[0344] 3 Result summary

[0345] Indicator Control group Test group Technical effect attribution Average write chain delay 420ms 185ms(-55%) Three-chain parallel + batch signature cross-chain congestion reduction Box annual loss rate 2.3％ 1.2％(-48％) RUL prediction + abnormal early warning and timely maintenance Box idle rate 18.5％ 16.3％(-12％) Path prediction assists warehouse position scheduling Carbon credits per capita / year 1125 1295(+15％) DDPG dynamic quota + deposit incentive Total CO2eqemissions 1820t 1675t(-8％) Homomorphic coordinate heat analysis optimizes trunk Compliance audit man-hours / half year 120h 35h(-71％) On-chain traceable ISO14067 report Leakage coordinate event 3 times 0 times Paillier ciphertext + Sigma-proof

[0346] 4 Data calculation (write-chain latency)

[0347]

[0348] where D j : the jth event write-chain completion to final confirmation delay; N: the number of events recorded within 180d (≈9x106).

[0349] 5 Effect analysis

[0350] 1) Performance: high-frequency logistics write-in parallel with three chains separates from carbon assessment / prediction chain, combined with batch BLS signature only once pairing verification, thus the delay is greatly reduced.

[0351] 2) Asset utilization: RUL accuracy mean square error within 4.7%, making the maintenance window 7 days early warning, directly reducing loss and idling.

[0352] 3) Emission reduction incentive: DDPG dynamically reduces the carbon emission ceiling according to real-time inventory and RUL, high-performance nodes realize income through NFT points, forming a positive feedback.

[0353] 4) Privacy and compliance: Σ-proof makes 300,000 coordinates zero leakage within half a year, while automatically generating a traceable life cycle report, saving two-thirds of audit costs.

[0354] The above is the description of the embodiments of the present application. Through the above description of the disclosed embodiments, those skilled in the art can implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art. The general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to these embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

[0355] Those skilled in the art will appreciate that embodiments of the application can be readily used as software, hardware, or a combination of software and hardware. In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0356] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more functions specified in the flowchart block or blocks. Figure 1 means for performing each one or more functions specified in the flowchart block or blocks.

[0357] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks. Figure 1 one or more functions specified in the flowchart block or blocks. Figure 1 means for performing each one or more functions specified in the flowchart block or blocks.

[0358] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more functions specified in the flowchart block or blocks. Figure 1 means for performing each one or more functions specified in the flowchart block or blocks.

[0359] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0360] The memory can include non-persistent memory and / or volatile memory, such as a random access memory (RAM) including a cache area for the temporary storage of data. The memory can also include non-volatile memory, such as read only memory (ROM) for storing structural information and / or instruction code. Both volatile and non-volatile memory can be implemented as a semiconductor memory, a magnetic memory, or an optical memory, among others. The memory is an example of computer readable media.

[0361] Computer-readable media includes permanent and non-permanent, moveable and non- moveable media that can be implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, without limitation, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. According to the definitions provided herein, computer readable media does not include transitory media, such as modulated data signals and carrier waves.

Claims

1. A blockchain-based method for full lifecycle management of reusable containers, characterized in that, Includes the following steps: S1 Layered Information Decomposition Collect the unique box number c of the circulating box and real-time logistics events, and break them down into: logistics plaintext fragment M, including event type, timestamp t, and status code, according to node attributes; Location coordinate segment L; carbon emission segment E; encrypt the location coordinate segment L to obtain ciphertext Enc(L); S2 Tri-chain Parallel Construction Parallel maintenance of the logistics main chain BC within the same distributed set of nodes. log Carbon assessment side chain BC carbon Predicting sidechain BC twin ; S3 cross-chain atom writing Select the top k candidate nodes by reputation to form a bootstrap cluster; A cross-chain atomic commit protocol employing two-phase commit and BLS aggregate signatures is used, corresponding to event block B in BC. log With BC carbon Synchronous appending; if either chain fails, a rollback is performed via aggregated signature to ensure consistency between chains; S4 Digital Twin Prediction and Chain Writing In BC twin The Oracle node runs a circular box digital twin model to predict the remaining lifetime (RUL) and future turnaround paths, writing the RUL and confidence level into the BC. twin And associated with BC via hash reference. log Corresponding block; S5 Dynamic Carbon Quota Reallocation Within a period ΔT, the carbon quota allocation algorithm based on Deep Deterministic Policy Gradient (DDPG) is executed by the sidechain governance node, with the input being: sidechain BC. carbon Historical carbon emission records in BC twin The system predicts the RUL (Relative Usage Limit) in the blockchain; outputs a new quota Q for each participating node and uploads it to the blockchain; when the actual emission reduction of a node is greater than or equal to Q, the smart contract automatically returns the deposit and issues carbon credits.

2. The method according to claim 1, characterized in that, The hierarchical information splitting and homomorphic encryption steps in step S1 satisfy the following mathematical relationship: 1) Quantize and stitch the coordinates; m = x φ ||x λ ||x h ; Where m: 96-bit concatenated message; x φ x λ x h These are latitude, longitude, and altitude, respectively. -6° / 1m precision quantized 32-bit non-negative integer; "||": concatenation operation in fixed bit width order; 2) Paillier homomorphic encryption is used: Enc(L) = g m r n modn 2 Where g: Paillier system generator; n: modulus, n = pq, p and q are 1024-bit prime numbers; One-time random number; Enc(L): encrypted location coordinates.

3. The method according to claim 1, characterized in that, Step S2, three-chain parallel construction, satisfies: 1) Block production cycle Δt log =5s, Δt carbon =60s, Δt twin =300s; Where, Δt log , Δt carbon , Δt twin : Target block production interval for the main logistics chain, carbon side chain, and predicted side chain; 2) Byzantine fault tolerance limit Where f: the number of Byzantine nodes tolerated by each chain; The number of nodes participating in the chain x consensus; Floor operation.

4. The method according to claim 1, characterized in that, Step S3, cross-chain atom writing, employs: 1) Local locking hash h i =H(B||ctx||i); Where H: SHA-256 hash function; B: event block to be written; ctx: transaction context identifier; i: bootstrap node index number; 2) Aggregate Lock Hash Hash agg =H(h1||h2||…||h k ); Hash agg : Two-chain locking identifier; k: Number of bootstrap nodes; 3) Aggregated signature verification e(∑ agg ,g)=e(H1(Hash agg ),P agg ); Where, ∑ agg : BLS aggregate signature; g: elliptic curve generator; H1: hash function mapping message to group G1; The sum of the public keys of the bootstrap nodes; e: pairing operation.

5. The method according to claim 1, characterized in that, Step S4, digital twin prediction, satisfies: 1) Graph Convolution in, Add a self-loop adjacency matrix; degree matrix; W (l) σ: Convolutional weights of layer l; σ: ReLU activation function; 2) RUL Regression Among them, Z c，t LSTM output vector; W r b r Regression layer weights and biases; 3) Confidence level in, MC-Dropout prediction variance; The upper bound of the maximum variance in experience.

6. The method according to claim 1, characterized in that, Step S5, the dynamic carbon quota redistribution step, employs the Deep Deterministic Policy Gradient (DDPG) algorithm, specifically including: 1) Construct the state vector: in, Unit carbon emission sequence; Turnover sequence; ρ i，t Inventory occupancy rate; Predict remaining lifespan; q i，t-1 Previous quota; 2) Output continuous actions through the Actor network and calculate the new quota: a i，t ∈[-0.2,0.2],q i，t =q i，t-1 (1+a i，t ); Among them, a i，t : Actor outputs continuous actions; q i，t New quota. 3) Reward function in, Target emissions; Actual emissions; Δrep i，t : Reputation increase or decrease; α, β, γ: positive weights, α+β+γ=1.

7. The method according to claim 1, characterized in that, The method also includes step S6, zero-knowledge privacy verification, which uses Σ-protocol zero-knowledge proof to prove to the entire network that the Enc(L) written in step S3 belongs to a valid coordinate domain without revealing the plaintext position pairs; the ciphertext Enc(L) generates and verifies the Σ-protocol proof π, whose on-chain verification conditions are: 1) Master verification equation g s η n ≡tc e (modern) 2 ); Where g: Paillier generator; s = α + em: response value; η = ρr e modn: response random term; t = g α ρ n modn 2 : Commitment; c = Enc(L): location ciphertext; e = SHA256(t||c||txHa2h)mod2 128 Fiat-Shamir Challenge; n: Paillier modulus; 2) Legal domain constraints 0≤m<2 96 ； Where m: the quantized and concatenated 96-bit coordinate message.

8. A multi-chain management system for performing the method according to any one of claims 1-7, characterized in that, include: a) Data acquisition terminal: Equipped with RFID / QR code scanning and GNSS modules, capable of encrypting (c,M,L,E) data packets before uploading them to the blockchain; b) Distributed chain service cluster: including at least logistics main chain nodes, carbon side chain nodes, prediction side chain Oracle nodes, and privacy relay nodes; c) Cross-chain coordinator: Enables atomic writing of two-phase commit and BLS aggregate signature; d) Privacy proof engine: Provides Σ-protocol proof generation and verification; e) Smart Contract Module: Deploy deposit escrow contracts, carbon credit settlement contracts, and anomaly alert contracts; f) Digital Twin Engine: Real-time calculation of RUL and writing the prediction results to BCT win .

9. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method described in any one of claims 1-5.

10. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method described in any one of claims 1-5.

Images