A frozen product supply chain record and query method based on a blockchain network

Abstract

The application discloses a frozen product supply chain record and query method based on a blockchain network, and belongs to the technical field of frozen product supply chains.The method comprises the following steps: S1, a block classification alliance chain architecture is constructed, a block identifier field and a previous block Hash identifier field are added in a block header, the block identifier field is used for identifying the data type stored in the block, and the previous block Hash identifier field is used for establishing a chained association between blocks of the same type; S2, cold chain data collected by the frozen product supply chain is divided into three types, namely, device data D1, order data D2 and privacy data D3, and after differential encryption processing is performed on the data of each type, a transaction chaining request is submitted; and S3, alliance chain nodes package transactions with the same receiving address in a transaction buffer pool.The application solves the problems of a cold chain traceability system storage bottleneck and privacy security opposition on the basis of realizing frozen product supply chain record and query, and improves traceability query efficiency and data access security.

Description

Technical Field

[0001] This invention relates to the field of frozen food supply chain technology, and more specifically, to a method for recording and querying frozen food supply chains based on a blockchain network. Background Technology

[0002] Frozen foods are a type of food stored at -12 to -23 degrees Celsius, including a wide range of meat and non-meat products such as seafood, aquatic products, chicken by-products, duck by-products, goose by-products, pork, beef, mutton, agricultural products, meatballs and pastries, other meats, and other agricultural products. A supply chain refers to the network structure formed by suppliers, manufacturers, distributors, and consumers connected through upstream and downstream members throughout the entire process from production, intermediate product manufacturing, and final product delivery to the consumer. Supply chain management is necessary to ensure the healthy, orderly, and efficient operation of the supply chain process.

[0003] Existing solutions generally suffer from fatal flaws such as crude architectural design, poor storage scalability, rigid privacy protection mechanisms, and low query and retrieval efficiency. Firstly, at the underlying architecture level, existing solutions mostly adopt a single-chain structure, indiscriminately packaging temperature and humidity sensor data, business order flow data, and core corporate trade secrets into the same block. This design leads to a rapid expansion of blockchain state data. As the number of supply chain nodes increases and time progresses, the storage pressure on all nodes rises exponentially, ultimately causing the system to be unable to operate stably in the long term. At the same time, when performing traceability queries, the single-chain structure must traverse the entire main chain block to filter specific data, severely limiting the concurrent processing capability and response speed of queries. Summary of the Invention

[0004] In view of the problems existing in the prior art, the purpose of this invention is to provide a method for recording and querying frozen food supply chains based on blockchain networks. This invention not only realizes the recording and querying of frozen food supply chains, but also solves the dilemma of storage bottleneck and privacy security in cold chain traceability systems, and improves traceability query efficiency and data access security.

[0005] To solve the above problems, the present invention adopts the following technical solution: A method for recording and querying frozen food supply chains based on a blockchain network, comprising: S1. Construct a dual-chain architecture consortium blockchain system with separate data chain and transaction chain. Add a class block identifier field and a previous class block hash identifier field to the block header of the transaction chain. The class block identifier field is used to identify the data type stored in the block, and the previous class block hash identifier field is used to establish a chain association between blocks of the same type. S2. Divide the cold chain data collected from the frozen food supply chain into three categories: equipment data D1, order data D2, and privacy data D3. Calculate the hash digest of equipment data D1 and write it into the data chain, and generate the corresponding anchor transaction request. Apply differentiated encryption processing to order data D2 and privacy data D3 and then submit a transaction on-chain request. S3. Consortium chain nodes package transactions with the same receiving address in the transaction buffer pool. When packaging, they fill in type identifiers CB1, CB2, and CB3 according to the receiving address. CB1 corresponds to the anchor transaction synchronized with the data chain, CB2 corresponds to order data, and CB3 corresponds to privacy data. After packaging, consensus is executed. After consensus is passed, the blocks are classified and stored on the chain. S4. Synchronize the hash fingerprint of the data chain to the transaction chain through anchoring technology to ensure cross-chain data consistency; S5. Construct a composite index that combines a hypergraph dynamic index with a spatiotemporal quadtree. The hypergraph dynamic index uses vertices to represent frozen product batches, transport vehicles, and warehouse entities, and uses hyperedges to represent multi-dimensional relationships between entities. The spatiotemporal quadtree stores cold chain transportation data in layers according to geographical regions and time windows. S6. Based on the consortium blockchain, the user performs selective queries on the consortium blockchain according to their permissions, and returns data of the corresponding type.

[0006] Compared with the prior art, the advantages of this invention are: This invention creatively introduces a block class identifier and a hash field of the previous block class into the block header, constructing a master-slave block classification structure. This enables logical isolation and independent chaining of device data, order data, and privacy data on the blockchain. Combined with differentiated encryption strategies for the three types of data, multi-level protection of data privacy is achieved. The dual-chain architecture stores massive amounts of environmental data hashes on a private data chain, synchronizing Merkle root fingerprints to the consortium transaction chain only through anchoring technology. This not only reduces on-chain core storage costs but also eliminates the risk of single-point tampering of off-chain data through cross-chain consistency verification. This architecture design meets the regulatory authorities' need for penetrating audits of cold chain temperature-related chain breakage while strictly protecting corporate trade secrets. It completely breaks the privacy dilemma of traditional blockchain traceability systems where data is exposed on the chain, providing a solid technical foundation for building a multi-party trust-based, mutually beneficial cold chain collaborative ecosystem.

[0007] This invention addresses the complex flow relationships in cold chain logistics by using a hypergraph dynamic index to abstract entities and multidimensional associations into vertices and hyperedges. Combined with maximum reachability and maximum coverage optimization, this enables the system to instantly locate associated nodes and responsible parties with extremely low time complexity during multi-hop traceability. The introduction of a spatiotemporal quadtree allows for second-level response times for trajectory queries based on geographic grids and time windows, providing a powerful engine for real-time dynamic monitoring and anomaly warning in cold chain logistics. Regarding query security, the system uses smart contracts to reconstruct the MPT tree root to verify user public keys and combines attribute-based encryption (ABE) to achieve fine-grained access control at the field and object levels. Even within the same data block, different roles can only decrypt fields matching their permissions. Attached Figure Description

[0008] Figure 1 This is a flowchart illustrating the steps of a method for recording and querying frozen food supply chains based on a blockchain network, as described in this invention. Figure 2 This is a flowchart of step S1 in the method for recording and querying frozen food supply chains based on a blockchain network according to the present invention. Detailed Implementation

[0009] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0010] Example: Please see Figure 1-2 A method for recording and querying frozen food supply chains based on blockchain networks, comprising: S1. Construct a dual-chain architecture consortium blockchain system with separate data chain and transaction chain. Add a class block identifier field and a previous class block hash identifier field to the block header of the transaction chain. The class block identifier field is used to identify the data type stored in the block, and the previous class block hash identifier field is used to establish a chain association between blocks of the same type. S2. Divide the cold chain data collected from the frozen food supply chain into three categories: equipment data D1, order data D2, and privacy data D3. Calculate the hash digest of equipment data D1 and write it into the data chain, and generate the corresponding anchor transaction request. Apply differentiated encryption processing to order data D2 and privacy data D3 and then submit a transaction on-chain request. S3. Consortium chain nodes package transactions with the same receiving address in the transaction buffer pool. When packaging, they fill in type identifiers CB1, CB2, and CB3 according to the receiving address. CB1 corresponds to the anchor transaction synchronized with the data chain, CB2 corresponds to order data, and CB3 corresponds to privacy data. After packaging, consensus is executed. After consensus is passed, the blocks are classified and stored on the chain. S4. Synchronize the hash fingerprint of the data chain to the transaction chain through anchoring technology to ensure cross-chain data consistency; S5. Construct a composite index that combines a hypergraph dynamic index with a spatiotemporal quadtree. The hypergraph dynamic index uses vertices to represent frozen product batches, transport vehicles, and warehouse entities, and uses hyperedges to represent multi-dimensional relationships between entities. The spatiotemporal quadtree stores cold chain transportation data in layers according to geographical regions and time windows. S6. Based on the consortium blockchain, the user performs selective queries on the consortium blockchain according to their permissions, and returns data of the corresponding type.

[0011] In a specific embodiment of the present invention, quantitative experiments have verified that, in a simulated operating environment containing 1000 block records and a 30% cross-chain anchored data offloading rate, the PBFT multi-stage consensus and classification packaging mechanism reduces the average time for public data to be uploaded to the chain to 589.03ms and the average time for private data to be uploaded to the chain to 708.59ms. Compared with the traditional single-chain storage solution, the overall system storage volume is reduced by 48.70%. By combining the hypergraph dynamic index with the spatiotemporal quadtree and the on-chain and off-chain hybrid storage architecture, the query efficiency of multi-dimensional traceability results is improved by 49.5% compared with the existing query methods. The average time for querying public data is reduced to 26.87ms and the average time for querying private data is reduced to 30.67ms. Quantitative experiments have verified that by adopting the differentiated response strategy and dual-server replica XOR operation, the data query accuracy reaches 100%, the false alarm rate is significantly reduced by 21 percentage points, and the overall data query efficiency is improved by 19.02% compared with the traditional blockchain traceability system.

[0012] By innovatively adding a class block identifier field and a previous class block hash identifier field to the block header, the system achieves sub-chain-like association of data blocks of the same type on the main chain. This breaks the drawback of mixed data storage caused by the traditional single-chain structure of blockchains. In the frozen food supply chain, the system accurately divides the collected cold chain data into three categories: equipment data D1, order data D2, and privacy data D3, and submits on-chain requests using differentiated encryption processing strategies such as signature, symmetric encryption, and asymmetric encryption. During the packaging phase, consortium chain nodes classify transactions according to the transaction receiving address, fill in the corresponding type identifiers CB1, CB2, and CB3, and achieve on-chain storage of classified and isolated blocks after consensus is reached. At the same time, the system constructs a dual-chain architecture that separates the data chain and the transaction chain. The data chain only stores environment data hashes, while the transaction chain records operation logs, ensuring cross-chain consistency through anchoring technology.

[0013] Specifically, step S1 includes: Add a class block identifier field and a previous class block hash identifier field to the block header structure of the transaction chain. The class block identifier field is used to identify the data type of the block storage, and the previous class block hash identifier field is used to establish a chain association between blocks of the same type. At the same time, the previous main block digest value field is retained to establish a vertical chain association of the main chain. Define the basic fields of the block header, including version information, block height, block timestamp, previous main block digest value, Merkle root, and block random number; When a node receives transaction data, it fills the class block identifier field according to the data type corresponding to the receiving address. Double hash calculation is performed on the filled block header to generate the hash value of the current block as the block identifier. This hash value is then written into the digest value field of the previous main block of the next main block and the hash identifier field of the previous block of the same type of the next main block, thus completing the chain association of blocks of the same type and ensuring that the new block satisfies the consistency of the hash pointers of the two chains.

[0014] In a specific embodiment of the present invention, the block header field in step S1 is specifically defined as follows: The block height is an integer used to identify the block sequence number and describe the block's position in the blockchain; The block identifier is a string that serves as a unique identifier for the block within the blockchain. Version information is a string, corresponding to the structure and field meanings of the block header; The previous main block digest value is a string that points to the block digest of the previous main block; The Merkel root is a string, generated by summarizing information related to this block using a tree structure algorithm; The block timestamp is an integer, representing the time scale of block generation, with a precision of milliseconds; The block random number is an integer and is a variable parameter used in the hash calculation for accounting nodes to compete for the right to record transactions.

[0015] The double hash calculation in step S1 uses the SHA-256 algorithm, and the specific formula is as follows: ,in Version information is a string type. This is the digest value of the previous main block, 32 bytes of data. The first block is the digest value of the previous block of the same type, a 32-byte data value. If it is the first block of the same type, it is set to a sentinel value of 64 zeros. The timestamp is the block timestamp, an 8-byte integer. For Merkel tree roots, 32 bytes of data. This is a block identifier field, a string type, containing data type identifier, encryption method identifier, and access permission identifier. Nonce is the block random number, an integer, and || is the byte sequence concatenation operator.

[0016] The data type classification and identifier filling in step S1 are limited to: Based on the characteristics of frozen food supply chain data, data types are divided into equipment data, order data, and privacy data; The node listens to the transaction buffer pool, aggregates and packages similar transactions with the same receiving address, and populates the corresponding buffers according to the receiving address mapping relationship. value; After packaging, the hash value of the previous block of the same type is assigned to the hash value of the current block. Fields that form a sub-chain structure of similar blocks; When packaging a new block, the ledger node must simultaneously retrieve the hash value of the previous main block and the hash value of the previous block of the same type from the local ledger, and fill them into the previous main block digest value and the previous block hash identifier field, respectively, to ensure that the block meets the hash pointer consistency requirements of the main chain and the sub-chain at the time of generation. Once the block is packaged, it will be broadcast to the entire network, and other nodes will need to verify the validity and continuity of both hash pointers during the verification process. The key considerations for constructing a consortium blockchain architecture based on block classification are as follows: The main chain blocks connect all types of blocks through the digest value field of the previous main block, forming a block classification structure with one main block and many sub-blocks. Blocks of the same type in a sub-chain are linked together by using the hash identifier field of the previous type of block; Any change in the data of a block will cause its own hash value to change, thereby simultaneously destroying the hash verification of subsequent blocks of the same type and blocks in the main chain, thus achieving double anti-tampering. The genesis block does not contain predecessor field values. The corresponding fields of the main chain genesis block and the genesis blocks of various sub-chains are all set to the initial all-zero sentinel string. The coordination mechanism for fork handling is defined as follows: when a temporary fork occurs on the main chain, the fork state of the child chain is attached to the main chain. The system adopts the longest chain principle as the fork handling mechanism for the main chain. When the main chain determines the longest valid chain through accumulated work or consensus voting, all child chain branches of the same type attached to abandoned main chain branches will be simultaneously abandoned. If only a child chain experiences partial forks due to network latency or other reasons, while the main chain does not fork, the hash value of the latest block of that type recorded on the main chain will be used to re-determine the unique and valid end node of the child chain, discarding other child chain forks, thereby ensuring the eventual consistency of the main chain and child chain states.

[0017] Specifically, step S2 includes: The cold chain data collected from the frozen food supply chain is divided into three categories: equipment data D1, order data D2, and privacy data D3. Fixed transaction receiving addresses are assigned to each type of data to establish specific associations. Specifically, the receiving address for the anchor transaction corresponding to equipment data D1 is specified as 0x0, the receiving address for the transaction containing order data D2 is specified as 1x1, and the receiving address for the transaction containing privacy data D3 is specified as 2x2. The receiving address is used by the consortium blockchain node to identify the data type and fill in the corresponding class block identifier during the packaging stage. For device data D1, its hash digest is written into the data chain, and a corresponding anchor transaction request is generated. Device data D1 is defined as temperature and humidity sensor data, GPS positioning data, and vehicle status data. A timestamp from the National Time Service Center is appended before the signature to prevent replay attacks. The ECDSA / secp256k1 algorithm is used to digitally sign the anchor transaction request for the timestamped device data D1. The specific formula is as follows: , D1 hash digest, The device certificate is packaged into the transaction payload and an on-chain request is sent to the receiving address 0x0; Order data D2 is encrypted using a symmetric encryption algorithm. Order data D2 is defined as the purchase order number, production batch number, inbound / outbound record number, and inspection report number. The AES-256-GCM algorithm is used for symmetric encryption of order data D2. The specific formula is as follows: ,Will The tag, IV, and AAD are packaged into a transaction payload, and an on-chain request is sent to the receiving address 1x1. Privacy data D3 is encrypted using an asymmetric encryption algorithm. Privacy data D3 is defined as cost information, customer identity information, and pricing strategy. The SM2 algorithm is used to perform asymmetric encryption on privacy data D3, supporting multi-receiver encryption. The specific formula is as follows: ,Will Pack it into a transaction payload and send an on-chain request to the receiving address 2x2; Constructing a transaction on-chain request structure ,in Strictly fill in 0x0, 1x1, or 2x2 according to the data type, and send the differentiated transaction request to the consortium blockchain transaction buffer pool.

[0018] In a specific embodiment of the present invention, the account model in step S2 is as follows: The underlying blockchain platform of this solution is constructed and defined as a permissioned blockchain network based on a self-developed consortium blockchain framework. The network adopts an account model based on digital certificates rather than the contract address model of public chains such as Ethereum. In public chain systems such as Ethereum, the all-zero address 0x0 is reserved by the protocol as the system default address, which is specifically used for the creation and deployment of smart contracts. This address does not have a corresponding private key and cannot actively initiate transactions. At the same time, ERC-20 and other token standard contracts will actively block transfer operations to the 0x0 address to prevent the token from being accidentally destroyed. Therefore, if the Ethereum address system is directly reused, 0x0 as a business receiving address will be unavailable. To avoid the aforementioned conflicts, this scheme pre-allocates three fixed virtual routing addresses (0x0, 1x1, and 2x2) as data type-specific identifiers through the system management account during the initialization phase of the consortium blockchain. These virtual routing addresses are registered as system-reserved addresses in the account model, do not correspond to any private key, and do not have the authority to initiate transactions. They serve only as routing identifiers for transaction recipients to provide data type identification and distribution during the packaging phase. The consortium blockchain's account system uses an X.509 digital certificate issued by a CA component for identity authentication. Users log in with a username and password to obtain a digital certificate and corresponding private key. The private key is symmetrically encrypted and returned to the user for safekeeping. It is used to digitally sign transactions. The virtual routing addresses, however, are independent of this identity system and only serve as passive receivers and routing classifications. When a consortium blockchain node retrieves a transaction from the transaction buffer pool, it identifies the receiving address field in the transaction structure through the built-in smart contract or packaging logic. If the receiving address is detected to be the predefined virtual routing address 0x0, 1x1, or 2x2, the transaction is determined to be a legitimate business category transaction, and the corresponding data type identifier is extracted and filled into the class block identifier field. If other non-predefined addresses are detected, the transaction is processed as a normal transfer transaction or determined to be an illegal transaction and rejected.

[0019] The specific association between data partitioning and the receiving address in step S2 is limited as follows: The receiving address for the transaction containing device data D1 is specified as 0x0; Specify the receiving address for the transaction containing order data D2 as 1x1; The receiving address for transactions containing privacy data D3 is specified as 2x2; The receiving address is used by consortium blockchain nodes to identify data types and fill in the corresponding class block identifiers during the packaging phase.

[0020] The signature processing of device data D1 in step S2 is limited to: Define device data D1 as temperature and humidity sensor data, GPS positioning data, and vehicle status data; The device data D1 is digitally signed using the ECDSA / secp256k1 algorithm, with the specific formula as follows: Where D1 is the plaintext device data, and the data type is a byte string. This is the digest value obtained by performing a SHA-256 hash calculation on the plaintext data from the device. This is the private key for the data acquisition device, fixed length 32 bytes. The generated digital signature is 64 bytes long. D1, And the device certificate is packaged into the transaction payload. A request to join the blockchain is sent to the receiving address 0x0.

[0021] The symmetric encryption processing of order data D2 in step S2 is limited to: Define order data D2 as the purchase order number, production batch number, inbound / outbound record, and inspection report number; The order data D2 is symmetrically encrypted using the AES-256-GCM algorithm. The specific formula is as follows: D2 represents the plaintext order data, which is a byte string. The key is a symmetric encryption key, distributed by the consortium blockchain key management system. Ⅳ is the initialization vector, randomly generated for each encryption. AAD is additional authentication data, containing a data generation timestamp and byte string type. The encrypted ciphertext and authentication label are in byte string format. Will Packaged as transaction payload A request to join the blockchain is sent to the receiving address 1x1.

[0022] The asymmetric encryption processing of privacy data D3 in step S2 is limited to: Define privacy data D3 as cost information, customer identity information, and pricing strategies; The SM2 algorithm is used to perform asymmetric encryption on the privacy data D3. The specific formula is as follows: D3 represents the plaintext private data, and its data type is a byte string. The SM2 public key for regulatory agencies or authorized query nodes, fixed length 64 bytes. The encrypted ciphertext data is a byte string. Will Packaged as transaction payload A request to join the blockchain is sent to the receiving address 2x2.

[0023] The precautions for differentiated encryption on-chain are as follows: Device data D1 must be appended with a timestamp from the National Time Service Center before signing to prevent replay attacks; Symmetric encryption key for order data D2 A hierarchical key architecture must be adopted, derived from the master key, and periodic rotation must be supported; The asymmetric encryption of privacy data D3 must support multi-recipient encryption, which is achieved by generating multiple ciphertext blocks to distribute keys to different authorized parties; The transaction on-chain request structure is limited to ,in Fill in 0x0, 1x1, or 2x2 strictly according to the data type.

[0024] Specifically, step S3 includes: During the transaction initiation phase, the consortium blockchain node determines the data type of the frozen food supply chain business data based on its inherent attributes, and sends the device data transaction to the receiving address 0x0, the order data transaction to the receiving address 1x1, and the privacy data transaction to the receiving address 2x2. At the same time, redundant type identifier fields are embedded in the transaction body. The consortium blockchain node retrieves the transaction buffer pool, obtains the transaction content, and performs a double verification by parsing the receiving address of each transaction and the embedded redundancy type identifier field. After confirming the match, it will be classified as a device data transaction, order data transaction, or privacy data transaction. Based on the verification results, fill the block header class block identifier field. Fill the class block identifier CB1 for transactions with receiving address 0x0 and matching embedded identifier, fill the class block identifier CB2 for transactions with receiving address 1x1 and matching embedded identifier, and fill the class block identifier CB3 for transactions with receiving address 2x2 and matching embedded identifier. At the same time, fill the corresponding previous block hash value. Construct a Merkle tree for the categorized transactions and calculate the Merkle tree root. Add the corresponding transaction to the block body and fill in the other fields of the block header to obtain the complete block header. Determine whether the block memory has reached the preset capacity threshold. If so, use the flexible packing algorithm to calculate the next block time and trigger the block consensus process. The consensus protocol is executed to verify blocks through multiple rounds of voting, specifically including the pre-preparation phase, the preparation phase, and the commit phase. In the pre-preparation phase, after the master node generates candidate blocks, it assigns proposal numbers to transactions and broadcasts the pre-preparation message to each consensus node. In the preparation phase, the consensus nodes verify the validity of the candidate blocks. After successful verification, they broadcast the preparation message to the entire network. When a consensus node receives at least 2f+1 preparation messages, it enters the ready state. In the commit phase, the ready consensus nodes broadcast the commit message to the entire network. When a consensus node receives at least 2f+1 commit messages, it confirms that the final consensus has been reached. After consensus is reached, the transactions in the candidate blocks are executed, the classified blocks are stored on the chain, and the corresponding transactions in the transaction buffer pool are cleaned up, where f is the number of abnormal nodes, which is an integer, and the total number of nodes in the system n satisfies n≥3f+1.

[0025] In a specific embodiment of the present invention, the filling rule for the class block identifier and the hash value of the previous class block in step S3 is limited to: When packaging a transaction with address 0x0, the block class identifier CB1 is filled in, and the hash value of the previous CB1 type block is obtained and filled into the hash value field of the previous block class. ; When packaging a transaction with a receiving address of 1x1, the block class identifier CB2 is filled in, and the hash value of the previous CB2 type block is obtained and filled into the hash value field of the previous block class. ; When packaging transactions with a 2x2 receiving address, the block class identifier CB3 is filled in, and the hash value of the previous CB3 type block is obtained and filled into the hash value field of the previous block class. ; The formula for calculating the Merkel root in step S3 is as follows: ,in For Merkel tree roots, 32 bytes of data. This represents the nth transaction data within the block, a byte string type, where Hash() is the SHA256 hash function, and || is the byte sequence concatenation operator; The formula for calculating the next block time in step S3 using the flexible packing algorithm is as follows: ,in This indicates the next block time, in seconds. The time it took to package the previous block into a block, in seconds. This is the baseline threshold for scaling, in seconds; the default value is 10. The scaling factor for the next stage is a dimensionless integer.

[0026] Step S3 Next stage of horizontal expansion The calculation method is limited to: When the transaction buffer is If no new transaction is obtained within the time limit, use Extended algorithm computation; When the transaction buffer is When a new transaction is acquired within a certain time period, the following method is adopted: Shrinkage algorithm calculation; in To expand the scale, dimensionless constants, The contraction ratio is a dimensionless constant. This represents the scaling level of the previous stage, a dimensionless integer. Step S3 of the consensus protocol includes a pre-preparation phase, a preparation phase, and a confirmation phase: During the pre-preparation phase, the master node assigns a proposal number to the received transactions and multicasts the pre-preparation message list to each backup node. The preparation phase involves backup nodes verifying the legality of transaction summaries and the watermark range of proposal numbers. After verification, preparation messages are multicast to the entire network. When consensus nodes have collected more than half of the preparation messages from the entire network, the system enters the ready state. The confirmation phase involves ready consensus nodes multicasting confirmation messages to the entire network. When more than half of the network's confirmation messages are collected, the node enters the commit phase, executes the transaction, and stores the categorized blocks on the blockchain. The precautions for categorized on-chain storage are as follows: When a node searches the transaction buffer pool, if it finds that the receiving address of a transaction is neither 0x0, 1x1, nor 2x2, it will put the transaction back into the transaction buffer pool. The main chain blocks connect all types of blocks through the digest value of the previous main block, forming a block classification structure with one main block and many sub-blocks. Blocks in the same sub-chain are linked together by using the hash value field of the previous block; When cleaning up the transaction buffer pool, only transaction data that has been successfully uploaded to the chain and confirmed by consensus is deleted. Transactions that have not reached consensus are kept in the buffer pool to wait for the next round of packaging.

[0027] Specifically, step S4 includes: A dual-chain architecture is constructed, separating the data chain and the transaction chain. The data chain is used to store frozen food environment data hashes, and the transaction chain is used to record supply chain operation logs. A Merkle tree is constructed for the frozen food environment data within a preset period on the data chain, and the Merkle root is calculated as a hash fingerprint. At the same time, the temperature chain break risk feature vector of the environmental data within the period is extracted. The temperature chain break risk feature vector includes the highest temperature extreme value and the duration of the chain break. Anchored transactions are generated on the transaction chain, and cross-chain anchored credentials containing the hash fingerprint, temperature chain break risk feature vector and data chain block timestamp are written into the block payload of the transaction chain and packaged and uploaded to the chain through the consensus mechanism. The cross-chain data elastic consistency verification is performed by comparing the hash fingerprint extracted from the data chain with the hash fingerprint anchored to the transaction chain. If the comparison is consistent and the temperature-induced chain break risk feature vector does not exceed the preset security threshold, the cross-chain data consistency verification is deemed to have passed. If the temperature-induced chain break risk feature vector exceeds the preset security threshold, a deep verification mechanism is triggered. The transaction chain node initiates a Merkel proof request to the data chain to obtain the Merkel path of the leaf node corresponding to the abnormal temperature data for off-chain asynchronous verification. After the verification is passed, the cross-chain data consistency confirmation is completed.

[0028] In a specific embodiment of the present invention, the generation and on-chaining of the anchor transaction in step S4 are limited as follows: The system adopts a periodic batch anchoring mode, triggering anchoring transactions when a preset time window reaches a threshold. Constructing an anchored transaction structure ; Includes fields , and Timestamp; right After being signed using the ECDSA algorithm, the message is broadcast to the transaction chain network and written into the transaction chain block after being confirmed by consensus. The formula for generating cross-chain anchored credentials in step S4 is as follows: ,in The current block height in the data chain, an integer. For the Merkle root of the current data link cycle, 32 bytes of data. The hash value of the transaction anchored in the transaction chain, 32 bytes of data. The generated cross-chain anchoring credential, consisting of 32 bytes of data, is stored in an off-chain database for querying and retrieval.

[0029] Specifically, the specific association of the double-chain architecture in step S4 is limited as follows: As a private blockchain, the data chain only stores encrypted digests of environmental data and does not store plaintext operation logs; The transaction chain, as a consortium blockchain, stores operation logs including handover records, permission changes, and query logs. The data chain and the transaction chain establish a temporal relationship through block timestamps and a data mapping relationship through data chain block hashes. The formula for calculating Merkelgen in step S4 is as follows: ,in The Merkle root of the current data chain cycle is 32 bytes of data. H(Ln) is the SHA-256 hash value of the nth environmental data record, also 32 bytes. || is the byte sequence concatenation operator. The specific implementation of the dual-chain architecture with separate data chain and transaction chain in step S4 is limited to: Before writing environmental data into the data chain, a data cleaning and field filtering mechanism is adopted to remove user identity and business attribute fields from the collected data, and only the sensor physical readings and collection timestamps are extracted. The fixed-length digest is calculated using the SM3 or SHA-256 cryptographic hash algorithm as a digital fingerprint and stored in the data chain to achieve physical isolation between privacy data and on-chain evidence. When generating anchored transactions, the transaction chain explicitly defines anchoring fields in the transaction payload structure. These anchoring fields include the data chain block height, data chain Merkle root, anchoring trigger timestamp, and ECDSA digital signature of the operation node, in order to form an operation log with tamper-proof and traceable characteristics. When performing cross-chain anchoring, the cross-chain relay component extracts and transmits only the Merkle root hash of the data chain block and the corresponding block height parameter to the transaction chain network. The cross-chain message body is prohibited from containing plaintext of the original environment data, thereby reducing cross-chain communication bandwidth overhead and on-chain storage costs.

[0030] Specifically, step S5 includes: A hypergraph dynamic indexing model is constructed, with frozen product batches, transport vehicles, and warehouse entities as hypergraph vertices and multi-dimensional relationships between entities as hyperedges. A label set is maintained for each vertex to generate a vertex-to-hyperedge index. Extract high-frequency condition combinations from the query log, generate a dynamic condition subgraph index based on the hyperedge association relationship, and cache the subgraph index to the edge nodes; Construct a spatiotemporal quadtree, divide the spatial dimension by geographical region level, divide the time level by time window, and store the cold chain transportation data summary within the corresponding spatiotemporal range for each tree node; A hybrid on-chain and off-chain storage architecture for index data is set up, storing the hypergraph dynamic index, dynamic condition subgraph index, and spatiotemporal quadtree structure data and node detail data in an off-chain distributed database. When an off-chain index is added or updated, the root node hash value and version number of the updated hypergraph dynamic index and the spacetime quadtree are extracted, an index state Merkle tree is constructed, the root hash of the index state Merkle tree is calculated as the index state fingerprint, and the index state fingerprint is written into the consortium chain block for storage through anchor transactions, so as to avoid the huge storage and update overhead caused by directly putting massive index details on the chain. When performing a joint query on a composite index, the query node first obtains the target index data and its corresponding Merkel path proof from the off-chain distributed database, and then extracts the corresponding index state fingerprint stored in the latest block from the consortium blockchain. The Merkel path proof is used to reconstruct the Merkel tree root hash locally and compare it with the index state fingerprint extracted from the chain. If the comparison is consistent, it is confirmed that the off-chain index data is consistent with the on-chain state and has not been tampered with. Based on the verified index data, the associated entities are traversed through the hypergraph dynamic index, the transportation trajectory is located through the spatiotemporal quadtree, and the multi-dimensional traceability results are output.

[0031] In a specific embodiment of the present invention, the version synchronization strategy between the off-chain index and the on-chain fingerprint in step S5 is as follows: The query node first obtains the target index data and the Merkle path proof of the corresponding index state Merkle tree from the off-chain distributed database, and at the same time obtains the version identifier or block height identifier of the index data. In order to eliminate the version mismatch problem caused by the time window between the off-chain index update frequency and the on-chain anchoring frequency, the system introduces a synchronization strategy based on version snapshots and anchoring checkpoints. The off-chain database retains historical version snapshots when updating the index, and the on-chain anchoring synchronously records the timestamp or block height corresponding to the version as a checkpoint. Subsequently, the query node extracts the anchored index status fingerprint that strictly corresponds to the version from the consortium blockchain based on the version identifier of the off-chain data, rather than blindly extracting fingerprints from the latest block. If it is determined that the current off-chain index version has not yet been anchored on-chain, it is marked as pending confirmation. The query node first rolls back to the off-chain snapshot data corresponding to the previous anchored version and performs a consistency comparison with the on-chain fingerprint, or triggers a temporary incremental anchoring transaction to ensure the eventual consistency of the query data.

[0032] The steps for generating the dynamic conditional subgraph index in step S5 are limited to: A. Extract high-frequency condition combinations from user historical query logs; B. Generate a subgraph index based on hyperedge relationships; C. Cache the subgraph index to the edge nodes.

[0033] The construction and storage of the spacetime quadtree in step S5 are limited as follows: The spatial dimensions are divided according to the geographical region hierarchy, and the two-dimensional geographical space is recursively divided into four quadrants as spatial hierarchy nodes. The time hierarchy is divided according to the time window, and each spatial node is further divided into four time period sub-nodes according to the timestamp interval; Each leaf node stores the hash value of cold chain transportation data and the digital asset identifier (DAI) within the corresponding spatiotemporal range; The spatiotemporal quadtree supports dynamic concurrent editing. When new cold chain transportation data is added, the system automatically calculates the spatiotemporal grid to which it belongs and incrementally updates the corresponding nodes.

[0034] Specifically, the algorithm for constructing the hypergraph dynamic index and querying reachability in step S5 is limited to: For each vertex u in the hypergraph, maintain a label set L(u), where each element in the label set L(u) is a tuple (e,s) indicating that vertex u can reach hyperedge e by s; Given query vertices u and v, the formula for calculating their maximum reachability MR(u,v) is as follows: Where MR(u,v) is the maximum reachability weight from vertex u to vertex v, a dimensionless integer, and L(u) and L(v) are the label sets of vertices u and v, respectively, and are data types of sets. and The superedge identifier is a string. and The reachability strength weight is a dimensionless integer. The query process iterates through L(u) and L(v) using merge sort to find the common superedge e and retrieve it. The maximum value; In step S5, the optimization of the transitive coverage detection of the hypergraph index is limited to: The maximum coverage metric MCD is introduced to accelerate coverage detection. The MCD calculation formula for the superedge e is as follows: Where MCD(e) is the maximum cover of hyperedge e, a dimensionless integer, and E is the set of hyperedges. For other hyperedges in set E, For the global order assigned based on the importance of hyperedges, use dimensionless integers. To from the super-edge The set of paths to superedge e. For path set The out-of-band value is a dimensionless integer.

[0035] In a specific embodiment of the present invention, the composite index joint query in step S5 is limited to: Receive composite query requests that include frozen product batch identifiers and spatiotemporal ranges; Locate the starting vertex in the hypergraph dynamic index based on the frozen product batch identifier, and then apply the maximum reachability formula. Iterate through and obtain the set of all associated vehicle and warehouse vertices. ; Extract the geographic coordinate range and time window from the query request, and calculate the set of leaf nodes that are hit in the spatiotemporal quadtree. ; Pick The transport data hash associated with the middle vertex and The intersection of the hashes of the stored data is used to locate the final trajectory of the abnormal event.

[0036] The precautions for building composite indexes are limited to: The vertices of the Hypergraph dynamic index must be uniquely mapped to the frozen food digital asset identifier (DAI) to avoid the index pointing to the wrong entity due to duplicate entity names; Before the dynamic conditional subgraph index is cached to the edge nodes, the subgraph data must be symmetrically encrypted to prevent edge node data leakage. The granularity of the time window division of the spatiotemporal quadtree must be matched with the frequency of sensor data reporting. When the amount of data in a time-space quadtree node exceeds a preset capacity threshold, a node splitting operation is triggered, distributing the data evenly among the four child nodes.

[0037] Specifically, step S6 includes: The user terminal generates a query request containing the user's identity identifier, query type identifier, and target frozen product digital asset identifier (DAI), signs the query request, and sends it to the consortium blockchain node. The consortium blockchain node invokes the access control smart contract to reconstruct the MPT Merkel Patricia root node to verify the user terminal's public key and access permissions. A subchain is defined as a similar blockchain branch structure derived from the main chain of the consortium blockchain, having independent functions or structures and operating in dependence on the main chain infrastructure. After the permission verification is passed, the consortium blockchain node will route the query request to the corresponding subchain to perform the retrieval based on the query type identifier. A differentiated response strategy is adopted based on the data type of the query request. If it is device data, the consortium blockchain performs an XOR operation on the plaintext device data and a randomly generated mask during the data on-chain storage stage to generate ciphertext. The ciphertext and the mask are stored in two independent node server replicas respectively. At the same time, a key-value pair index structure is established based on the target frozen product digital asset identifier (DAI) to support random access. During the query, the first node server replica returns the device data ciphertext according to the index, and the second node server replica returns the corresponding mask. The user terminal performs an XOR operation on the ciphertext and the mask to reconstruct the plaintext device data. If it is order data, a symmetric encrypted ciphertext and additional authentication data are returned. If it is privacy data, after verifying the regulatory authority through an attribute-based encryption strategy, an asymmetric encrypted ciphertext is returned. After receiving the response message, the user terminal reconstructs and decrypts the data based on a preset algorithm, and calculates the hash value to perform a consistency check with the on-chain anchor hash.

[0038] In a specific embodiment of the present invention, the redundancy strategy for the device data storage and query portion in S6 is as follows: If the data is device data, the consortium blockchain performs an XOR operation between the plaintext device data and a randomly generated mask to generate ciphertext during the data on-chain storage phase. To avoid the loss of ciphertext or mask due to single node failure or data loss, thus preventing the reconstruction of the original data, the system introduces a distributed redundant storage strategy for the ciphertext and mask respectively: A multi-replica mechanism is adopted, storing the ciphertext and mask in at least three independent node server replicas. When the master node fails, the system can automatically retrieve data from the available slave replicas through a heartbeat detection mechanism to ensure business continuity. Simultaneously, a key-value index structure is established based on the target frozen product digital asset identifier (DAI) to support random access. During a query, the system prioritizes returning the encrypted device data from the first node server cluster based on the index, and returns the corresponding mask from the second node server cluster. If a failure of the preferred node is detected, a failover and data recovery mechanism is automatically triggered, reading data from redundant replicas or reconstructing data through erasure coding. After the user terminal obtains the complete encrypted data and mask, it performs an XOR operation to reconstruct the plaintext device data without loss.

[0039] The algorithm for querying and reconstructing device data in step S6 is limited to: A dual-server replication mechanism is adopted, whereby the data queryer generates two query requests and sends them to two independent ledger nodes. The specific formula is as follows: Request generation: , ; Response generation: , ; Result reconstruction: ; Where n is the total number of bits in the system-preset device data index (in integers), q1 is a randomly generated binary sequence in bits, q2 is a request sequence containing the target index in bits, Index is the binary index position of the target device data in bits, ⊕ is the XOR logical operator, a1 is the response message returned by the first accounting node based on q1 (byte string type), and a2 is the response message returned by the second accounting node based on q2 (byte string type). For target device data encrypted using the queryer's public key, the byte string type is... This is the reconstructed encrypted target device data, in byte string type.

[0040] Specifically, the permission verification and fine-grained permission control in step S6 are limited as follows: The consortium blockchain node invokes the access control smart contract, uses the public key of the data accessor DU in the query request and the Merkel proof path it provides, to reconstruct the root hash value of the Merkel Patricia tree MPT, and directly compares the reconstructed MPT root hash value with the original MPT root hash value stored in the consortium blockchain block. If the two are completely consistent, it is confirmed that the public key of the data accessor DU exists in the authorized MPT, and the object-level permission verification is passed. Construct a field-level access control mechanism based on attribute-based encryption, define a frozen food supply chain data object field mapping data structure containing object identifiers and field identifiers, map object-level access permissions to MPT leaf nodes, and bind field-level access permissions to each sensitive field of the data object; For each sensitive field, an independent field-level symmetric key is derived for data encryption. Based on a preset attribute access policy tree, the field-level symmetric key is encrypted using a user public key or attribute public key that meets specific attribute requirements to generate field-level ciphertext. The field-level ciphertext is then stored in the transaction payload or MPT extension node of the corresponding data object. During the query response phase, if the object-level permission verification passes and the user attribute set of the data visitor DU meets the attribute access policy of a specific field, then the user is allowed to use their own attribute private key to decrypt and obtain the symmetric key of that field, and then decrypt and obtain the plaintext of the corresponding field. For fields where the data visitor DU's attributes do not meet the access policy, the corresponding field-level ciphertext is refused to be returned or the data after de-identification is returned, thereby refining the granularity of permission verification to the field level and the object level.

[0041] In a specific embodiment of the present invention, the query and response of order data in step S6 is limited to: The response structure for the consortium blockchain node to return order data is as follows: ; After receiving the data, the user terminal calls the symmetric decryption algorithm, the formula is: ,in This is the encrypted order data, a byte string type. Ⅳ is the initialization vector, a 12-byte data set. AAD is the additional authentication data, containing the data generation timestamp, also a byte string type. For symmetric encryption keys, 32 bytes of data, This is the decrypted plaintext order data, in byte string format.

[0042] In step S6, the query and response to privacy data are limited to: Access verification is performed using an attribute-based encryption-based access strategy. The smart contract verifies whether the set of attributes carried in the query request satisfies the preset access strategy tree, as shown in the formula. ; like If True, the consortium blockchain sends the decryption key, which is encrypted using the public key of the data accessor DU and stored in the MPT, to the DU. The DU then decrypts the key using its own private key. ; in This is a collection of attributes submitted by the user terminal; the data type is a collection. This is a predefined access strategy tree, with a tree data type and ⊨ representing the relational symbol for attributes. This is the attribute-based permission verification result, a boolean type. This is encrypted private data, in byte string format.

[0043] The data consistency check algorithm in step S6 is limited to: After the user terminal decrypts and obtains the plaintext data, it calculates the hash value and compares it with the hash of the Merkle tree leaf node anchored on the chain. The formula is as follows: ,in The decrypted plaintext data is in byte string format. This is the hash value obtained by performing SHA-256 calculation on plaintext data, 32 bytes of data. To query the hash value of the data corresponding to the request in the Merkel leaf node of the data chain, 32 bytes of data. The result of the consistency check is a boolean type. The precautions for permission-based selective queries are as follows: XOR logical operation queries must use a dual-server replica mechanism. The querying party generates two different request messages and sends them to two independent accounting nodes. The querying party does not interact directly with the accounting nodes. like or If the query is returned as False, the consortium blockchain node will directly reject the query request and log the unauthorized access. The signature in the query request must be timestamped to prevent replay attacks; When the user terminal decrypts the ciphertext, if If the value returns False, an exception alarm will be triggered and the data will be discarded.

[0044] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and its improved concept, should be covered within the scope of protection of the present invention.

Claims

1. A method for recording and querying frozen food supply chains based on blockchain networks, characterized in that, include: S1. Construct a dual-chain architecture consortium blockchain system with separate data chain and transaction chain. Add a class block identifier field and a previous class block hash identifier field to the block header of the transaction chain. The class block identifier field is used to identify the data type stored in the block, and the previous class block hash identifier field is used to establish a chain association between blocks of the same type. S2. Divide the cold chain data collected from the frozen food supply chain into three categories: equipment data D1, order data D2, and privacy data D3. Calculate the hash digest of equipment data D1 and write it into the data chain, and generate the corresponding anchor transaction request. Apply differentiated encryption processing to order data D2 and privacy data D3 and then submit a transaction on-chain request. S3. Consortium chain nodes package transactions with the same receiving address in the transaction buffer pool. When packaging, they fill in type identifiers CB1, CB2, and CB3 according to the receiving address. CB1 corresponds to the anchor transaction synchronized with the data chain, CB2 corresponds to order data, and CB3 corresponds to privacy data. After packaging, consensus is executed. After consensus is passed, the blocks are classified and stored on the chain. S4. Synchronize the hash fingerprint of the data chain to the transaction chain through anchoring technology to ensure cross-chain data consistency; S5. Construct a composite index that combines a hypergraph dynamic index with a spatiotemporal quadtree. The hypergraph dynamic index uses vertices to represent frozen product batches, transport vehicles, and warehouse entities, and uses hyperedges to represent multi-dimensional relationships between entities. The spatiotemporal quadtree stores cold chain transportation data in layers according to geographical regions and time windows. S6. Based on the consortium blockchain, the user performs selective queries on the consortium blockchain according to their permissions, and returns data of the corresponding type.

2. The method for recording and querying frozen food supply chains based on blockchain networks according to claim 1, characterized in that, Step S1 includes: Add a class block identifier field and a previous class block hash identifier field to the block header structure of the transaction chain. The class block identifier field is used to identify the data type of the block storage, and the previous class block hash identifier field is used to establish a chain association between blocks of the same type. At the same time, the previous main block digest value field is retained to establish a vertical chain association of the main chain. Define the basic fields of the block header, including version information, block height, block timestamp, previous main block digest value, Merkle root, and block random number; When a node receives transaction data, it fills the class block identifier field according to the data type corresponding to the receiving address. Double hash calculation is performed on the filled block header to generate the hash value of the current block as the block identifier. This hash value is then written into the digest value field of the previous main block of the next main block and the hash identifier field of the previous block of the same type of the next main block, thus completing the chain association of blocks of the same type and ensuring that the new block satisfies the consistency of the hash pointers of the two chains.

3. The method for recording and querying frozen food supply chains based on blockchain networks according to claim 1, characterized in that, Step S2 includes: The cold chain data collected from the frozen food supply chain is divided into three categories: equipment data D1, order data D2, and privacy data D3. Fixed transaction receiving addresses are assigned to each type of data to establish specific associations. For device data D1, its hash digest is written into the data chain, and a corresponding anchor transaction request is generated. Device data D1 is defined as temperature and humidity sensor data, GPS positioning data, and vehicle status data. A timestamp from the National Time Service Center is appended before the signature to prevent replay attacks. The ECDSA / secp256k1 algorithm is used to digitally sign the anchor transaction request for device data D1 with the appended timestamp. The hash digest of D1, ... The device certificate is packaged into the transaction payload and an on-chain request is sent to the receiving address 0x0; Order data D2 is encrypted using a symmetric encryption algorithm. Order data D2 is defined as the purchase order number, production batch number, inbound / outbound record number, and inspection report number. The AES-256-GCM algorithm is used for symmetric encryption of order data D2. The tag, IV, and AAD are packaged into a transaction payload, and an on-chain request is sent to the receiving address 1x1. The privacy data D3 is encrypted using an asymmetric encryption algorithm. Specifically, the SM2 algorithm is used to perform multi-receiver asymmetric encryption on the privacy data D3. Pack it into a transaction payload and send an on-chain request to the receiving address 2x2; Construct a transaction on-chain request structure and send the differentiated transaction request to the consortium blockchain transaction buffer pool.

4. The method for recording and querying frozen food supply chains based on blockchain networks according to claim 1, characterized in that, Step S3 includes: During the transaction initiation phase, the consortium blockchain node determines the data type of the frozen food supply chain business data based on its inherent attributes, and sends the device data transaction to the receiving address 0x0, the order data transaction to the receiving address 1x1, and the privacy data transaction to the receiving address 2x2. At the same time, redundant type identifier fields are embedded in the transaction body. The consortium blockchain node retrieves the transaction buffer pool, obtains the transaction content, and performs a double verification by parsing the receiving address of each transaction and the embedded redundancy type identifier field. After confirming the match, it will be classified as a device data transaction, order data transaction, or privacy data transaction. Based on the verification results, fill the block header class block identifier field. Fill the class block identifier CB1 for transactions with receiving address 0x0 and matching embedded identifier, fill the class block identifier CB2 for transactions with receiving address 1x1 and matching embedded identifier, and fill the class block identifier CB3 for transactions with receiving address 2x2 and matching embedded identifier. At the same time, fill the corresponding previous block hash value. Construct a Merkle tree for the categorized transactions and calculate the Merkle tree root. Add the corresponding transaction to the block body and fill in the other fields of the block header to obtain the complete block header. Determine whether the block memory has reached the preset capacity threshold. If so, use the flexible packing algorithm to calculate the next block time and trigger the block consensus process. The consensus protocol is executed to verify the block through multiple rounds of voting. When the consensus node receives at least 2f+1 commit messages, it confirms that the final consensus has been reached. Once consensus is reached, the transactions in the candidate blocks are executed, the categorized blocks are stored on the blockchain, and the corresponding transactions in the transaction buffer pool are cleared.

5. The method for recording and querying frozen food supply chains based on blockchain networks according to claim 1, characterized in that, Step S4 includes: A dual-chain architecture is constructed, separating the data chain and the transaction chain. The data chain is used to store frozen food environment data hashes, and the transaction chain is used to record supply chain operation logs. A Merkle tree is constructed for the frozen food environment data within a preset period on the data chain, and the Merkle root is calculated as a hash fingerprint. At the same time, the temperature chain breakage risk feature vector of the environmental data within this period is extracted. Generate anchored transactions on the transaction chain, write cross-chain anchored credentials into the block payload of the transaction chain, and package them onto the chain through the consensus mechanism; Perform cross-chain data elastic consistency verification, and complete cross-chain data consistency confirmation after the verification is passed.

6. The method for recording and querying frozen food supply chains based on blockchain networks according to claim 5, characterized in that, The specific implementation of the dual-chain architecture in step S4, which separates the data chain and the transaction chain, is limited to: Before writing environmental data into the data chain, a data cleaning and field filtering mechanism is adopted to remove user identity and business attribute fields from the collected data, and only the sensor physical readings and collection timestamps are extracted. The fixed-length digest is calculated using the SM3 or SHA-256 cryptographic hash algorithm as a digital fingerprint and stored in the data chain to achieve physical isolation between privacy data and on-chain evidence. When generating anchored transactions, the transaction chain explicitly defines the anchor field in the transaction payload structure; When performing cross-chain anchoring, the cross-chain relay component extracts and transmits only the Merkle root hash of the data chain block and the corresponding block height parameter to the transaction chain network. The cross-chain message body is prohibited from containing plaintext of the original environment data, thereby reducing cross-chain communication bandwidth overhead and on-chain storage costs.

7. The method for recording and querying frozen food supply chains based on blockchain networks according to claim 1, characterized in that, Step S5 includes: A hypergraph dynamic indexing model is constructed, with frozen product batches, transport vehicles, and warehouse entities as hypergraph vertices and multi-dimensional relationships between entities as hyperedges. A label set is maintained for each vertex to generate a vertex-to-hyperedge index. Extract high-frequency condition combinations from the query log, generate a dynamic condition subgraph index based on the hyperedge association relationship, and cache the subgraph index; Construct a spatiotemporal quadtree, divide the spatial dimension by geographical region level, divide the time level by time window, and store the cold chain transportation data summary within the corresponding spatiotemporal range for each tree node; A hybrid on-chain and off-chain storage architecture for index data is set up, storing the hypergraph dynamic index, dynamic condition subgraph index, and spatiotemporal quadtree structure data and node detail data in an off-chain distributed database. When an off-chain index is added or updated, the root node hash value and version number of the updated hypergraph dynamic index and the spacetime quadtree are extracted, an index state Merkle tree is constructed, the root hash of the index state Merkle tree is calculated as the index state fingerprint, and the index state fingerprint is written into the consortium chain block for storage through anchor transactions, so as to avoid the huge storage and update overhead caused by directly putting massive index details on the chain. When performing a joint query on a composite index, the query node first obtains the target index data and its corresponding Merkel path proof from the off-chain distributed database, and then extracts the corresponding index state fingerprint stored in the latest block from the consortium blockchain. The Merkel path proof is used to reconstruct the Merkel tree root hash locally and compare it with the index state fingerprint extracted from the chain. If the comparison is consistent, it is confirmed that the off-chain index data is consistent with the on-chain state and has not been tampered with. Based on the verified index data, the associated entities are traversed through the hypergraph dynamic index, the transportation trajectory is located through the spatiotemporal quadtree, and the multi-dimensional traceability results are output.

8. The method for recording and querying frozen food supply chains based on blockchain networks according to claim 7, characterized in that, The algorithm for constructing the hypergraph dynamic index and querying reachability in step S5 is limited to: For each vertex u in the hypergraph, maintain a label set L(u), where each element in the label set L(u) is a tuple (e,s) indicating that vertex u can reach hyperedge e by s; Given query vertices u and v, the formula for calculating their maximum reachability MR(u,v) is as follows: ; The query process iterates through L(u) and L(v) using merge sort to find the common superedge e and retrieve it. The maximum value; The optimization of the transitive coverage detection of the hypergraph index in step S5 is limited to: The maximum coverage metric MCD is introduced to accelerate coverage detection. The MCD calculation formula for the superedge e is as follows: .

9. A method for recording and querying frozen food supply chains based on a blockchain network according to claim 1, characterized in that, Step S6 includes: The user terminal generates a query request containing a user identity identifier, a query type identifier, and a target frozen product digital asset identifier (DAI), signs the query request, and sends it to the consortium blockchain node. The consortium blockchain node invokes the access control smart contract to reconstruct the MPT Merkel Patricia root node to verify the user terminal's public key and access permissions. A subchain is defined as a similar blockchain branch structure derived from the main chain of the consortium blockchain, having independent functions or structures and operating in dependence on the main chain infrastructure. After the permission verification is passed, the consortium blockchain node will route the query request to the corresponding subchain to perform the retrieval based on the query type identifier. A differentiated response strategy is adopted based on the data type of the query request. If it is device data, the consortium blockchain performs an XOR operation on the plaintext device data and a randomly generated mask during the data on-chain storage stage to generate ciphertext. The ciphertext and the mask are stored in two independent node server replicas respectively. At the same time, a key-value pair index structure is established based on the target frozen product digital asset identifier (DAI) to support random access. During the query, the first node server replica returns the device data ciphertext according to the index, and the second node server replica returns the corresponding mask. The user terminal performs an XOR operation on the ciphertext and the mask to reconstruct the plaintext device data. If it is order data, a symmetric encrypted ciphertext and additional authentication data are returned. If it is privacy data, after verifying the regulatory authority through the attribute-based encryption strategy, an asymmetric encrypted ciphertext is returned. After receiving the response message, the user terminal reconstructs and decrypts the data based on a preset algorithm, and calculates the hash value to perform a consistency check with the on-chain anchor hash.

10. A method for recording and querying frozen food supply chains based on a blockchain network according to claim 9, characterized in that, The permission verification and fine-grained permission control in step S6 are limited to: The consortium blockchain node invokes the access control smart contract, uses the public key of the data accessor DU in the query request and the Merkel proof path it provides, to reconstruct the root hash value of the Merkel Patricia tree MPT, and directly compares the reconstructed MPT root hash value with the original MPT root hash value stored in the consortium blockchain block. If the two are completely consistent, it is confirmed that the public key of the data accessor DU exists in the authorized MPT, and the object-level permission verification is passed. Construct a field-level access control mechanism based on attribute-based encryption, define a frozen food supply chain data object field mapping data structure containing object identifiers and field identifiers, map object-level access permissions to MPT leaf nodes, and bind field-level access permissions to each sensitive field of the data object; For each sensitive field, an independent field-level symmetric key is derived for data encryption. Based on a preset attribute access policy tree, the field-level symmetric key is encrypted using a user public key or attribute public key that meets specific attribute requirements to generate field-level ciphertext. The field-level ciphertext is then stored in the transaction payload or MPT extension node of the corresponding data object. During the query response phase, if the object-level permission verification passes and the user attribute set of the data visitor DU meets the attribute access policy of a specific field, then the user is allowed to use their own attribute private key to decrypt and obtain the symmetric key of that field, and then decrypt and obtain the plaintext of the corresponding field. For fields where the data visitor DU's attributes do not meet the access policy, the corresponding field-level ciphertext is refused to be returned or the data after de-identification is returned, thereby refining the granularity of permission verification to the field level and the object level.

Images