A blockchain-based meat production information management method

Abstract

This invention discloses a blockchain-based method for managing meat production information, relating to the field of meat information management technology. The method includes collecting raw business data from the entire meat production chain and encapsulating it into structured data blocks with timestamps and embedded individual identifiers according to production stages; submitting the structured data blocks to a consortium blockchain network for consensus verification; upon successful verification, writing the data into the blockchain ledger to generate immutable block records; reading the block records, extracting the full-chain data fingerprint corresponding to the individual identifier, and generating a visualized production history map based on the data fingerprint; receiving query requests from terminals carrying the individual identifier to be queried, retrieving the corresponding data from the map, assembling it into a standardized response message, and returning it to the network to complete on-chain traceability. This method achieves reliable storage and full-chain traceability of meat production data, improving retrieval convenience and data reliability.

Description

Technical Field

[0001] This invention belongs to the field of meat information management technology, specifically a blockchain-based method for managing meat production information. Background Technology

[0002] Currently, meat production information management mostly adopts a centralized database storage model. Production data from various stages such as breeding, processing, and distribution are collected manually or by single devices. Simple individual identifiers are used to associate data from different stages. When the terminal queries, it needs to retrieve data from the scattered storage of each stage through a centralized server to obtain the meat production history.

[0003] Under a centralized storage model, meat production data is vulnerable to cyberattacks and human manipulation, making it difficult to guarantee data authenticity. Data from different production stages is stored in different systems without a unified index, leading to broken data links and making it impossible to achieve full-chain traceability from breeding to distribution. At the same time, the data retrieval process is cumbersome, the query results lack intuitiveness, and end users cannot quickly obtain complete and coherent meat production information, nor can they effectively verify the completeness and authenticity of the retrieved data.

[0004] It is necessary to achieve reliable storage of data across the entire meat production chain, establish effective correlations between data at each stage, realize data traceability and verification, and improve the convenience and intuitiveness of data retrieval to meet the needs of terminal devices for rapid querying of meat production history. Summary of the Invention

[0005] This invention aims to solve at least one of the technical problems existing in the prior art;

[0006] Therefore, this invention proposes a blockchain-based method for managing meat production information, comprising:

[0007] Collect raw business data from the entire meat production chain, and encapsulate the raw business data into structured data blocks with timestamps according to the production stage. The structured data blocks embed the individual identifier code as a cross-stage association index.

[0008] The structured data block is submitted to the consortium blockchain network for consensus verification. After successful verification, the structured data block is written into the blockchain ledger, generating an immutable block record.

[0009] Read the block records in the blockchain ledger and extract the full-link data fingerprint corresponding to the individual identifier code. The data fingerprint is formed by concatenating the hash values ​​of the structured data blocks in each link.

[0010] Based on the data fingerprint, a visualized meat production history map is generated. The meat production history map uses the individual identifier code as the root node and the structured data blocks of each link as branch nodes to construct a complete data link from breeding to distribution.

[0011] Receive a resume query request from a terminal device, the resume query request carrying the individual identifier code to be queried;

[0012] Based on the individual identifier code to be queried, the corresponding branch node data is retrieved in the meat production history map, and the retrieved branch node data is assembled into a standardized history response message.

[0013] The standardized traceability response message is returned to the terminal device, completing an on-chain traceability process for meat production information.

[0014] Furthermore, the original business data is encapsulated into structured data blocks with timestamps according to the production stage, including:

[0015] The original business data includes individual identification codes, feed feeding records and vaccination records in the breeding process, batch quarantine certificates, carcass segmentation diagrams and weighing data in the slaughtering process, and temperature monitoring logs and geographical location change records in the circulation process.

[0016] The individual identification codes, feed feeding records, and vaccination records of the breeding process are aligned to generate a breeding stage data table;

[0017] The batch quarantine certificates, carcass segmentation diagrams, and weighing data from the slaughtering process are normalized to generate a slaughtering stage data table;

[0018] The temperature monitoring logs and geographical location change records of the aforementioned circulation process are sorted chronologically to generate a circulation stage data table.

[0019] Extract the header fields and body content of the data tables for the breeding stage, slaughtering stage, and circulation stage respectively, and calculate the combined hash value of the header fields and body content;

[0020] The combined hash value, current system time, and stage type label are packaged and appended to the data table of each stage to form the structured data block with timestamp.

[0021] Furthermore, the structured data block is submitted to the consortium blockchain network for consensus verification, including:

[0022] Read the stage type label in the structured data block to determine the list of authorized nodes responsible for the corresponding stage of the read structured data block;

[0023] The structured data block is broadcast to all nodes in the authorized node list, triggering a multi-party cross-verification process;

[0024] Each authorized node extracts the business data within the structured data block and compares it with the original vouchers it retains. The original vouchers include electronic scans of paper documents and original sensor logs.

[0025] If the comparison results of all authorized nodes are consistent, a signature certificate for agreeing to write is generated;

[0026] After collecting a preset number of signature credentials, a new block containing the structured data block and all signature credentials is constructed and appended to the end of the blockchain ledger.

[0027] Further, the block records in the blockchain ledger are read, and the full-link data fingerprint corresponding to the individual identifier is extracted, including:

[0028] Traverse all blocks of the blockchain ledger, locate the structured data block of the breeding stage containing the individual identifier code, and record the height of the block where the structured data block of the breeding stage is located and the offset address within the block where the structured data block of the breeding stage is located.

[0029] Using the individual identifier as an index, continue to search for the slaughter stage structured data block and the circulation stage structured data block containing the same individual identifier in the subsequent blocks, and record the block height and offset address of each block.

[0030] Following the order of breeding, slaughtering, and distribution, the hash values ​​of the structured data blocks at each stage are read sequentially, and the hash values ​​are concatenated into a string;

[0031] A second hash operation is performed on the string to generate a full-link data fingerprint of a fixed length, and the full-link data fingerprint and its corresponding block location information are cached locally.

[0032] Furthermore, a visualized meat production history map is generated based on the data fingerprint, including:

[0033] Initialize an empty directed acyclic graph structure, and use the individual identifier code as the root node of the directed acyclic graph;

[0034] Based on the block location information corresponding to the data fingerprint, all fields of the structured data block of the breeding stage are read from the blockchain ledger and transformed into the attribute list of the root node.

[0035] Create the first branch node, bind the height of the block containing the structured data block of the breeding stage, and attach the attribute list to the branch node;

[0036] The process of creating branch nodes is repeated, creating corresponding branch nodes for the structured data blocks in the slaughtering stage and the structured data blocks in the circulation stage in turn, and establishing directed edges from the root node to each branch node in the directed acyclic graph according to the production time sequence.

[0037] The directed acyclic graph is rendered as the meat production history map, and the arrows on the directed edges indicate the direction of the production process.

[0038] Further, receiving a resume query request from a terminal device includes:

[0039] Listen to the data message body of the API gateway layer and parse the protocol version number and request type fields in the data message body;

[0040] When the value of the request type field is a resume query, extract the authentication token and the individual identifier code to be queried from the data packet body;

[0041] Verify the validity of the authentication token. If the verification is successful, store the individual identifier code to be queried in the query task queue; otherwise, discard the data packet body.

[0042] The individual identifier code to be queried is popped from the query task queue, triggering the subsequent resume retrieval process.

[0043] Further, based on the individual identifier code to be queried, the corresponding branch node data is retrieved in the meat production history map, including:

[0044] Access the graph storage engine, call the index interface with the individual identifier code as the key, and obtain the memory pointer of the meat production history graph;

[0045] Following the directed acyclic graph structure pointed to by the memory pointer, all branch nodes are traversed in a depth-first manner;

[0046] In each branch node, the block height bound to the branch node is read, and the corresponding structured data block original text is retrieved from the blockchain ledger according to the block height;

[0047] The original structured data blocks of each branch node are parsed into key-value pairs of business data and then aggregated into a branch node dataset.

[0048] Furthermore, assembling the retrieved branch node data into a standardized history response message includes:

[0049] Define the top-level structure of the resume response message, which includes three parts: message header, data body, and session identifier;

[0050] Enter the operation serial number and response generation time of this query into the message header;

[0051] In the data body, the business data in the branch node dataset are arranged in the order of breeding, slaughtering, and distribution, and the block height and data generation time of the source are appended to each business data item.

[0052] The authentication token recorded in the query task queue is entered into the session identifier to complete the assembly of the standardized resume response message.

[0053] Furthermore, it also includes a step of performing data cleaning on historical blocks in the blockchain ledger, including:

[0054] Regularly analyze the access frequency of each block and generate a block popularity ranking;

[0055] Identify the cold data blocks that rank low in the block popularity ranking list. The cold data blocks refer to blocks that have not been accessed by any history query requests in the recent period of time.

[0056] The structured data blocks in the cold data block are de-identified, and the de-identification process includes deleting detailed address information and contact information that can be used to infer personal identity;

[0057] The de-identified cold data blocks are migrated to the archive storage cluster, and their data fingerprints and block height indexes are retained in the blockchain ledger to maintain the integrity of the meat production history map.

[0058] Furthermore, it also includes the step of dynamically updating the meat production traceability map during the distribution process, including:

[0059] An on-board data acquisition terminal is deployed on a cold chain transport vehicle, and the on-board data acquisition terminal continuously records the ambient temperature and latitude and longitude coordinates;

[0060] When an ambient temperature fluctuation exceeds a preset limit or a cross-regional change in latitude and longitude coordinates is detected, a circulation event record is generated.

[0061] The circulation event record is associated with the individual identifier and encapsulated into a circulation stage supplementary data block. The timestamp of the circulation stage supplementary data block is taken from the system clock of the vehicle data acquisition terminal.

[0062] The supplementary data block for the circulation stage is submitted to the consortium blockchain network. After consensus verification, it is written into the blockchain ledger and triggers an incremental update of the meat production history graph, adding a circulation event branch node to the directed acyclic graph.

[0063] Compared with the prior art, the beneficial effects of the present invention are:

[0064] Structured data blocks, packaged according to production stages, timestamped, and embedded with individual identifiers, are submitted to the consortium blockchain network for consensus verification. Once verified, the structured data block is written to the blockchain ledger, generating an immutable block record. This combination of consortium blockchain consensus verification and blockchain storage overcomes the limitations of conventional centralized storage, which is prone to data tampering and forgery. It achieves authentic retention of data across the entire meat production chain, ensuring that data at each stage cannot be illegally modified, guaranteeing data integrity and credibility, and preventing distortion of traceability information due to data tampering. This makes data at each stage of meat production traceable and verifiable.

[0065] The system reads block records from the blockchain ledger and extracts the end-to-end data fingerprint corresponding to the individual identifier code. This data fingerprint is formed by concatenating the hash values ​​of structured data blocks from each stage. Based on this data fingerprint, a visualized meat production history map is generated. This map uses the individual identifier code as the root node and the structured data blocks from each stage as branch nodes, constructing a complete data link from breeding to distribution. The system receives history query requests from terminal devices carrying the individual identifier code to be queried. Based on the individual identifier code, it retrieves the corresponding branch node data in the history map and assembles the retrieved branch node data into a standardized history response message, which is then returned to the terminal device. By connecting data from each stage through data fingerprints and constructing a visualized history map, the system overcomes the cumbersome and unintuitive nature of conventional retrieval methods, achieving an intuitive presentation of the entire meat production data chain. Terminal devices can quickly retrieve the corresponding end-to-end data, and the standardized response message clearly presents the production history without complex parsing, improving data retrieval and response efficiency and allowing end users to quickly obtain coherent and complete meat production information. Attached Figure Description

[0066] Figure 1 This is a flowchart illustrating the steps of a blockchain-based meat production information management method according to the present invention.

[0067] Figure 2 A flowchart for encapsulating raw business data into structured data blocks in stages;

[0068] Figure 3 A flowchart for extracting the end-to-end data fingerprint corresponding to an individual identifier;

[0069] Figure 4 Heatmaps showing block height and core metrics at each stage;

[0070] Figure 5 A bar chart showing the frequency of access to blockchain blocks. Detailed Implementation

[0071] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0072] See Figure 1 This method begins by collecting raw business data from each stage of the entire meat production chain. The collected data is encapsulated according to its production stage, forming timestamped structured data blocks. Each structured data block contains a unique individual identifier, serving as the core index for data association across production stages. After encapsulation, the structured data blocks are submitted to a pre-built consortium blockchain network. Nodes in this network perform consensus verification of the data blocks. Once verified, the structured data block is officially written into the blockchain ledger, forming an immutable block record. When traceability is needed, the system reads the accumulated block records in the blockchain ledger, extracts the hash values ​​of all structured data blocks associated with a specific individual identifier, and concatenates these hash values ​​to generate a data fingerprint representing the uniqueness of the individual's data across the entire chain. Based on this data fingerprint, the system constructs a visualized meat production history map. This map uses the individual identifier as the root node and structured data blocks from each stage (breeding, slaughtering, distribution, etc.) as branch nodes, thus graphically displaying the complete production data chain. When a terminal device initiates a history query request, the request carries the individual identifier code to be queried. After receiving the request, the system retrieves all branch node data corresponding to the individual identifier code in the meat production history map. Then, it assembles the retrieved scattered data into a standardized history response message with a unified format and finally returns the response message to the terminal device that initiated the query, thereby completing an information traceability process from on-chain data to the end user.

[0073] In one embodiment of the present invention, in the process of encapsulating raw business data into structured data blocks with timestamps according to production stages, the raw business data involved includes individual identification codes, feed feeding records, and vaccination records in the breeding stage; batch quarantine certificates, carcass segmentation maps, and weighing data in the slaughtering stage; and temperature monitoring logs and geographical location change records in the distribution stage. See also Figure 2The process involves aligning the fields of individual identification codes, feed feeding records, and vaccination records from the breeding stage to generate a structured breeding stage data table. For the batch quarantine certificates, carcass segmentation maps, and weighing data from the slaughtering stage, format normalization is performed to generate a slaughtering stage data table. Temperature monitoring logs and geographic location change records from the distribution stage are sorted chronologically to generate a distribution stage data table. The header fields and body contents of the breeding, slaughtering, and distribution stage data tables are extracted, and their combined hash values ​​are calculated. This combined hash value, along with the current system time and the type tag indicating the stage, is packaged and appended to each data table to ultimately form the timestamped structured data block.

[0074] When submitting a structured data block to the consortium blockchain network for consensus verification, the system reads the stage type tag from the structured data block, determines the list of authorized nodes responsible for verifying the data at that stage based on the tag, and broadcasts the structured data block to all nodes in the authorized node list, triggering a multi-party cross-verification process. Each authorized node extracts the business data encapsulated within the structured data block and compares it with its locally stored original vouchers. The original vouchers include electronic scans of paper documents and original sensor logs. If the comparison results of all participating authorized nodes are consistent, each node generates a signature voucher agreeing to write the data. The system collects these signature vouchers, and when a preset threshold is reached, it constructs a new block containing the structured data block and all collected signature vouchers, and appends this new block to the end of the blockchain ledger.

[0075] In practice, the original business data includes individual identification codes, feed feeding records, and vaccination records in the breeding stage; batch quarantine certificates, carcass segmentation maps, and weighing data in the slaughtering stage; and temperature monitoring logs and geographical location change records in the distribution stage. For example, the individual identification code in the breeding stage is "PIG-2026-1001", the feed feeding record is "2026-01-15 07:30 Mixed feed 15 kg", the vaccination record is "2026-01-20 Vaccine B 3 ml", the batch quarantine certificate in the slaughtering stage is "quarantine certificate number INSP-2026-0521", the carcass segmentation map is segmentation coordinate data, the weighing data is "carcass weight 85 kg", the temperature monitoring log in the distribution stage is "2026-02-01 14:00 3 degrees Celsius", and the geographical location change record is "from warehouse A to market B". This original business data is stored in different systems in a decentralized manner.

[0076] The individual identification codes, feed feeding records, and vaccination records in the breeding process are aligned to generate a breeding stage data table. The field alignment operation maps the data to a unified field name. For example, the breeding stage data table contains the fields "individual identification code string", "feed feeding timestamp", "feed type string", "feeding amount value", "vaccination vaccination timestamp", "vaccine type string", and "injection dosage value". The table body content is "PIG-2026-1001,2026-01-1507:30, mixed feed,15,2026-01-20,vaccine B,3". The batch quarantine certificates, carcass segmentation diagrams, and weighing data from the slaughtering stage are normalized to generate a slaughtering stage data table. Format normalization converts non-standard data into text or numerical values. Temperature monitoring logs and geographic location change records from the distribution stage are sorted chronologically to generate a distribution stage data table. The chronological sorting is based on ascending timestamps. For example, the distribution stage data table contains fields such as "Record Timestamp," "Temperature Value," "Longitude Value," and "Latitude Value," with the table body content being "2026-02-01 14:00, 3, 116.4080, 39.9041." The header fields and body content of the breeding stage data table, slaughtering stage data table, and distribution stage data table are extracted separately. The combined hash value of the header fields and body content is calculated using the following formula:

[0077]

[0078] in: It outputs a combined hash value. It is the cryptographic hash function SHA-256. It is a header field string. It is the string containing the table body content, with symbols. This section describes string concatenation operators. For example, in a data table for the breeding stage, the header field string is "Individual Identifier String, Feed Feeding Timestamp, Feed Type String, Feeding Amount Value, Vaccine Injection Timestamp, Vaccine Type String, Injection Dosage Value", and the body content string is "PIG-2026-1001,2026-01-15 07:30, Mixed Feed, 15,2026-01-20, Vaccine B, 3". After concatenation, a hash function is used to calculate the combined hash value. The combined hash value, the current system time, and the stage type label are packaged and appended to each stage data table to form a structured data block with a timestamp. The stage type label is an enumerated string such as "Breeding Stage", "Slaughtering Stage", and "Circulation Stage". For example, the structured data block contains the original data table text, the combined hash value "a1b2c3d4e5f6...", the system time "2026-02-01 14:00:00.000", and the stage type label "Breeding Stage". Data comparison shows that the original business data are heterogeneous independent records, while the structured data blocks are unified format data units with timestamps, hash values ​​and stage tags, which facilitates subsequent blockchain processing.

[0079] In some embodiments, the structured data block is submitted to the consortium blockchain network for consensus verification. This includes reading the stage type tag in the structured data block, determining the list of authorized nodes responsible for the corresponding stage of the read structured data block, and mapping the stage type tag to a preset node list, such as mapping "breeding stage" to the authorized node list [breeding farm node, regulatory agency node]. In a specific implementation, the structured data block is broadcast to all nodes in the authorized node list, triggering a multi-party cross-verification process. The broadcast operation sends the structured data block to each authorized node through the consortium blockchain network's message protocol. In a specific implementation, each authorized node extracts the business data within the structured data block and compares it with its own retained original vouchers. The original vouchers include electronic scans of paper documents and original sensor logs. For example, a breeding farm node compares feed feeding records with feeding event records in the original sensor logs, and a regulatory agency node compares electronic scans of antibody test reports. In a specific implementation, if the comparison results of all authorized nodes are consistent, a signature certificate of agreement to write is generated. The signature certificate uses the private key of the authorized node to digitally sign the hash value of the structured data block to generate a signature string. Once a preset number of signature credentials have been collected, a new block containing structured data blocks and all signature credentials is constructed and appended to the end of the blockchain ledger. The preset number is defined by consensus rules as exceeding two-thirds of the authorized node list. The new block contains a block header and transaction data, which includes the structured data blocks and the list of signature credentials. Optionally, signature credentials can be accompanied by timestamps and node identifiers to enhance traceability. It is understood that multi-party cross-verification ensures the authenticity of the structured data blocks by comparing them with independently stored original credentials. In some embodiments, the consensus verification process compares the business data in the structured data blocks with the original credentials; for example, the temperature values ​​in temperature monitoring logs and original sensor logs must match, otherwise verification fails. Optionally, the authorized node list can be dynamically configured according to the production stage to adapt to different supply chains. It is understood that digital signatures and consensus mechanisms guarantee the immutability of data in the blockchain ledger.

[0080] In one embodiment of the present invention, when reading block records in the blockchain ledger to extract the end-to-end data fingerprint corresponding to the individual identifier, refer to... Figure 3The system traverses all blocks in the blockchain ledger, locates the structured data block for the breeding stage containing the target individual identifier code, and records the block height and its offset address within the block. Using this individual identifier code as an index, the system continues to search for all structured data blocks for the slaughtering and distribution stages containing the same individual identifier code in subsequent blocks, and records their respective block heights and offset addresses. Following the production sequence of breeding, slaughtering, and distribution, the system sequentially reads the hash values ​​of the structured data blocks for each stage from the blockchain ledger and concatenates these hash values ​​into a complete string. A secondary hash operation is performed on this concatenated string to generate a fixed-length end-to-end data fingerprint. Simultaneously, the system locally caches this data fingerprint and all corresponding block location information. When constructing a visualized meat production history map based on the generated data fingerprint, the system initializes an empty directed acyclic graph (DAG) data structure, setting the individual identifier code as the root node of this DAG. Based on the block location information corresponding to the data fingerprint, the system accurately reads all field contents of the structured data block for the breeding stage from the blockchain ledger and transforms these fields into an attribute list under the root node. The first branch node is created, bound to the block height where the structured data block for the breeding stage is located, and the aforementioned attribute list is attached to this branch node. The system repeats this creation process, creating corresponding branch nodes for the structured data blocks for the slaughtering stage and the distribution stage in sequence. Based on the actual production time sequence, directed edges are established in the directed acyclic graph (DAG) pointing from the root node to each branch node. This DAG data structure is rendered as a visualized meat production history graph, where the arrows on the directed edges indicate the direction of the production process from breeding to distribution.

[0081] In practical implementation, the process involves reading block records from the blockchain ledger and extracting the full-link data fingerprint corresponding to the individual identifier. This includes traversing all blocks in the blockchain ledger, locating the structured data block for the breeding stage containing the individual identifier, and recording the block height and offset address within that block. For example, traversing all blocks from block height 1 to 100, the structured data block for the breeding stage containing "PIG-2026-1001" is located at block height 47, and the block height 47 and offset address 0x00a1 are recorded. Using the individual identifier as an index, subsequent blocks containing the same individual identifier are searched for structured data blocks for the slaughtering stage and circulation stage, recording their respective block heights and offset addresses. For example, the slaughtering stage structured data block is located at block height 63 with offset address 0x00c2, and the circulation stage structured data block is located at block height 89 with offset address 0x00e3. Following the order of breeding, slaughtering, and distribution, the hash values ​​of structured data blocks at each stage are read sequentially, and concatenated into a string. For example, if the hash value of the structured data block in the breeding stage is "H1", the hash value of the structured data block in the slaughtering stage is "H2", and the hash value of the structured data block in the distribution stage is "H3", the concatenated string is "H1H2H3". A secondary hash operation is performed on the string to generate a full-link data fingerprint of a fixed length, and the full-link data fingerprint and its corresponding block location information are cached locally. The formula for the secondary hash operation is:

[0082]

[0083] in: It is the final generated end-to-end data fingerprint. It is the cryptographic hash function SHA-256. The concatenated string "H1H2H3" is used to calculate a fixed-length 256-bit end-to-end data fingerprint, such as "f1e2d3c4b5a6...". The local cache record is {"fingerprint": "f1e2d3c4b5a6...", "location": [(47, 0x00a1), (63, 0x00c2), (89, 0x00e3)]}. Data comparison shows that what is extracted from the blockchain are the original records scattered across different blocks, while the end-to-end data fingerprint is a unique, compact, and representative string generated by hashing these records.

[0084] In some embodiments, a visualized meat production history map is generated based on the end-to-end data fingerprint. This includes initializing an empty directed acyclic graph (DAG) structure, using the individual identifier code as the root node of the DAG, which is implemented in memory using an adjacency list data structure. In a specific implementation, based on the block location information corresponding to the end-to-end data fingerprint, all fields of the structured data block for the breeding stage are read from the blockchain ledger and converted into an attribute list for the root node. For example, based on the block location information (47, 0x00a1), the original data is read, and fields such as "individual identifier code string" and "feeding timestamp" are converted into a list of attribute key-value pairs and stored in the root node. A first branch node is created, bound to the height of the block containing the structured data block for the breeding stage, and the attribute list is attached to the branch node. For example, a branch node node_1 is created, bound to block height 47, and the attribute list containing the breeding data is linked to node_1.

[0085] The process of creating branch nodes is repeated, sequentially creating corresponding branch nodes for the structured data blocks of the slaughtering stage and the distribution stage. Directed edges are then established in the directed acyclic graph (DAG) from the root node to each branch node according to the production sequence. For example, a branch node `node_2` is created for slaughtering data with a height of 63, and a branch node `node_3` is created for distribution data with a height of 89. Then, directed edges are established: root node -> node_1, root node -> node_2, and root node -> node_3. The DAG is rendered as a meat production history graph, with the arrows on the directed edges indicating the direction of the production process. The rendering process uses a graphics library to draw the DAG data structure as a visual graphical interface containing nodes and arrows. Optionally, the arrows on the directed edges can use different colors or thicknesses to represent different production stages. It can be understood that the DAG structure clearly expresses the data associations and flow directions radiating from the root node to the branch nodes of each production stage. In some embodiments, branch nodes in the visual graph can be clicked to expand and view detailed attribute list data. Optionally, block height information can be displayed as a label next to the corresponding branch node. It can be understood that the process of generating a visualized meat production history map, from end-to-end data fingerprints, achieves a mapping from abstract hash values ​​to specific topological graphs.

[0086] In one embodiment of the present invention, receiving a history query request from a terminal device includes listening to the data packet body of the API gateway layer and parsing the protocol version number and request type field in the data packet body. For example, an API gateway deployed on a cloud server continuously listens to network traffic on a specific port. When a data packet body “{"version":"1.0","type":"trace_query","token":"abc123xyz","animal_id":"PIG-2026-1001"}” is captured, the parsing operation extracts the protocol version number "1.0" and the request type field "trace_query". In a specific implementation, when the value of the request type field is a history query, the authentication token and the individual identifier code to be queried are extracted from the data packet body. For example, the authentication token "abc123xyz" and the individual identifier code "PIG-2026-1001" are extracted from the above data packet body. The validity of the authentication token is verified. If the verification is successful, the individual identifier to be queried is stored in the query task queue; otherwise, the data packet body is discarded. The verification process is achieved by querying the token database or verifying the digital signature. The verification formula is as follows:

[0087]

[0088] in: It is the verification result (valid or invalid). It is a verification function. It is the extracted authentication token string. It is the public key held by the system, if If valid, the individual identifier "PIG-2026-1001" is pushed to the query task queue in memory. If invalid, the entire data packet is discarded and no further action is taken. The individual identifier to be queried is popped from the query task queue, triggering the subsequent history retrieval process. For example, the message processing component pops the task entry "PIG-2026-1001" from the head of the query task queue and uses this identifier as a parameter to call the graph retrieval service. Data comparison shows that when verification passes, the individual identifier is separated from the original network request and stored in an ordered queue of pending requests; when verification fails, the entire request is safely discarded to prevent invalid requests from consuming system resources.

[0089] In some embodiments, the data message body of the API gateway layer follows a fixed JSON structure, and the protocol version number indicates the version of the request format. Optionally, the authentication token can be a time-limited JWT token, whose validity includes a check for expiration time. It is understood that parsing the protocol version number allows the system to be compatible with different versions of client requests. In some embodiments, the query task queue is a first-in-first-out (FIFO) memory queue used to buffer and process query requests sequentially. Optionally, discarding the data message body may be accompanied by logging an error to the security audit system. It is understood that authentication token verification is a critical step in access control, ensuring that only authorized terminals can initiate queries. In specific implementations, popping data from the query task queue is an atomic operation, ensuring that the same query request is not processed repeatedly. Optionally, triggering subsequent resume retrieval processes can be accomplished by sending an internal event containing an individual identifier or by directly calling a function.

[0090] In one embodiment of the present invention, when retrieving corresponding branch node data in the meat production history graph based on the individual identifier code to be queried, the system accesses the graph storage engine, calls the index interface with the individual identifier code as the key, and obtains a memory pointer pointing to the meat production history graph of that individual. The system then uses a depth-first traversal algorithm to access all branch nodes along the directed acyclic graph data structure pointed to by this memory pointer. In each branch node visited, the system reads the block height information bound to that node and retrieves the corresponding structured data block original text from the blockchain ledger based on this block height information. The system parses the structured data block original text corresponding to each branch node into key-value pairs of business data and summarizes the business data of all branch nodes to form a complete branch node dataset. When assembling the retrieved branch node data into a standardized history response message, the system predefines the top-level structure of the history response message, which includes three components: a message header, a data body, and a session identifier. In the message header, the system fills in the unique operation serial number of this query and the generation time of the response message. In the data body section, the system arranges all business data in the branch node dataset according to the natural order of breeding, slaughtering, and distribution, and appends the block height of its source and the timestamp of its initial generation to each piece of business data. In the session identifier section, the system fills in the authentication token for this request extracted from the query task queue record, thereby completing the assembly of the entire standardized history response message.

[0091] In practice, based on the individual identifier code to be queried, the corresponding branch node data is retrieved from the meat production history graph. This includes accessing the graph storage engine, calling the index interface with the individual identifier code as the key, and obtaining the memory pointer of the meat production history graph. For example, when querying the individual identifier code "PIG-2026-1001", the graph storage engine searches in the index and returns the memory address 0x7ffeefbff5a0, which points to the corresponding directed acyclic graph structure. Following the directed acyclic graph structure pointed to by the memory pointer, a depth-first traversal is performed on all branch nodes. The traversal algorithm starts from the root node "PIG-2026-1001" and sequentially visits and records all the branch nodes connected to it, such as sequentially visiting the breeding stage branch node, the slaughtering stage branch node, and the distribution stage branch node. In each branch node, the block height bound to the branch node is read, and the corresponding structured data block original text is retrieved from the blockchain ledger according to the block height. For example, in the breeding stage, the bound block height 47 is read in the branch node, and the block with height 47 is queried from the blockchain service to extract the structured data block original text at offset address 0x00a1. The structured data blocks of each branch node are parsed into key-value pairs of business data and aggregated into a branch node dataset. The parsing process identifies field separators in the original structured data blocks and extracts the key:value pairs. For example, from the structured data block of the breeding stage, the key-value pair {"Individual Identifier Code": "PIG-2026-1001", "Feed Feeding Timestamp": "2026-01-15 07:30"} is parsed; from the slaughtering stage, {"Quarantine Certificate Number": "INSP-2026-0521"} is parsed; and from the circulation stage, {"Record Timestamp": "2026-02-01 14:00", "Temperature": "3"} is parsed. All key-value pairs are aggregated into the branch node dataset. Data comparison shows that depth-first traversal accesses logical nodes in the graph, while retrieving data from the blockchain ledger retrieves the original data blocks stored on the chain. The parsing operation converts the original data blocks into a set of key-value pairs that are easier for the program to process. See Table 1.

[0092] Table 1: Branch Node Dataset Table

[0093] Production stage Data key Data value Block height Data generation time breeding stage Individual Identification Code PIG-2026-1001 47 2026-01-1507:30:00 breeding stage Feeding records 15 kg of mixed feed 47 2026-01-1507:30:00 Slaughtering stage Quarantine Certificate Number INSP-2026-0521 63 2026-01-2510:15:00 Circulation stage Temperature monitoring records 3 degrees Celsius 89 2026-02-0114:00:00

[0094] In some embodiments, the retrieved branch node data is assembled into a standardized history response message, including defining the top-level structure of the history response message, which includes three parts: a message header, a data body, and a session identifier. The top-level structure is defined in JSON format. In a specific implementation, the operation serial number and response generation time of this query are filled in the message header. The operation serial number is a unique string generated by the system, and the response generation time is the current server time. For example, the message header is {"serial_number":"OP-20260201-0001","response_time":"2026-02-0114:30:25.123"}. In the data body, the business data in the branch node dataset are arranged in the order of breeding, slaughtering, and distribution. The block height and data generation time of the source are appended to each business data item. The arrangement operation is based on the "Production Stage" field in Table 1, and "block_height" and "origin_time" fields are appended to each row of data. Enter the authentication token recorded in the query task queue into the session identifier to complete the assembly of the standardized history response message. For example, if the session identifier is {“auth_token”:“abc123xyz”}, the final assembled message will contain these three parts. The formula for generating the operation serial number during the response message generation process is:

[0095]

[0096] in: It operates on the serial number string. It is a fixed prefix "OP-". The date part is "20260201". It is a 4-digit auto-incrementing sequence number "0001", and the symbol "+" indicates a string concatenation operation. Optionally, the data body of the response message can use an array to organize data groups from different stages. It is understood that the operation sequence number in the message header facilitates the tracking and association of requests and responses. In some embodiments, the response generation time is taken from the server clock, distinguishing it from the data generation time. Optionally, the authentication token is obtained directly from the context in which the query task was processed. It is understood that the fixed structure of the standardized history response message allows for a unified parsing and processing logic across different terminals.

[0097] See Figure 4This is a heatmap showing the block height and core indicators at each stage of the meat production blockchain traceability system. It clearly demonstrates the standardized distribution of core data indicators across the three stages: breeding, slaughtering, and distribution. The slaughtering stage has the highest overall values, especially core indicator 1, which reaches 1.0, indicating that this stage's business indicator value is at its peak throughout the entire chain. The distribution stage has the highest block height, consistent with the blockchain's technical characteristic of "later-written blocks have higher heights." The breeding stage's indicators are all at a moderate to low level, serving as the starting point for the entire chain's data. The distribution of standardized values ​​allows for the rapid identification of missing or abnormal data, aiding in data cleaning and quality monitoring. It indirectly reflects the frequency and intensity of data uploads at each stage, providing a basis for decision-making regarding blockchain node optimization and cold data archiving. The color intensity quickly identifies abnormal fluctuations; for example, an abnormally high temperature indicator in the distribution stage can provide timely warnings of cold chain safety risks.

[0098] In one embodiment of the invention, the method further includes a step of performing data cleaning on historical blocks in the blockchain ledger. The system periodically counts the frequency of access to each block and generates a block popularity ranking accordingly. The system identifies low-ranking cold data blocks in the ranking, which are blocks that have not been accessed by any history query requests within the most recent statistical period. The system performs anonymization processing on the structured data blocks contained in these cold data blocks, including deleting detailed address information and contact information that could deduce personal identity. After processing, the system migrates the anonymized cold data blocks as a whole to a lower-cost archive storage cluster for long-term storage. At the same time, the data fingerprints and block height indexes of these blocks are retained in the blockchain ledger to maintain the logical integrity of the meat production history map and ensure the continuity of the traceability chain. The method also includes a step of dynamically updating the meat production history map in the circulation process, deploying onboard data acquisition terminals on cold chain transport vehicles, which continuously record the ambient temperature inside the vehicle and the real-time latitude and longitude coordinates of the vehicle. When an ambient temperature fluctuation exceeds a preset threshold, or when latitude and longitude coordinates change across administrative regions, the vehicle-mounted data acquisition terminal generates a circulation event record. This circulation event record is associated with the individual identification code of the transported meat and encapsulated into a new supplementary data block for the circulation stage. The timestamp of this data block is taken from the system clock of the vehicle-mounted data acquisition terminal. This supplementary data block for the circulation stage is submitted to the consortium blockchain network. After consensus verification, it is written into the blockchain ledger and triggers an incremental update of the meat production history graph, adding a branch node representing this circulation event to the existing directed acyclic graph.

[0099] In practical implementation, the data cleaning steps for historical blocks in the blockchain ledger include periodically counting the access frequency of each block and generating a block popularity ranking. For example, the system executes a statistical task every 24 hours, traversing the blockchain ledger to record the number of times each block has been accessed by query requests in the past 30 days, and generating a ranking by sorting them in descending order of access frequency. Identifying low-ranking "cold data" blocks in the block popularity ranking, where "cold data" blocks refer to blocks that have not been accessed by any historical query requests in the recent past period, for example, setting the judgment condition as 0 accesses in the last 90 days, and marking the bottom 20% of blocks in the ranking as cold data blocks. De-identifying the structured data blocks in the cold data blocks, including deleting detailed address information and contact information that can deduce personal identity, such as replacing the geographical location information "No. ZZ, YY Street, XX District, Beijing" with "Beijing" in the structured data blocks in circulation, and replacing the contact phone number "13800138000" with an empty string. The anonymized cold data blocks were migrated to an archive storage cluster, and their data fingerprints and block height indexes were retained in the blockchain ledger to maintain the integrity of the meat production history map. The migration operation transferred the original block data from the online storage database to the object storage service, while retaining a stub record in the original location of the blockchain ledger, containing the block's hash fingerprint "F0E1D2C3B4A5..." and block height "47". Data comparison shows that before data cleaning, a complete circulation stage block might contain "Delivery address: No. 1001 Zhangjiang Road, Pudong New Area, Shanghai, Contact person: Li xx, Phone: 13912345678". After data cleaning and migration, only the index stub remains at this location in the online blockchain ledger, while the address and phone number fields of the corresponding block in the archive storage have been removed.

[0100] In some embodiments, the generation of the block popularity ranking can be based on a more complex access popularity decay model, and the identification threshold for cold data blocks can be dynamically adjusted according to the storage strategy. Optionally, the de-identification process can also include generalization processing of personnel names, such as processing "Zhang Sanfeng" as "Zhang*". It is understood that migrating cold data to low-cost archive storage helps reduce the storage load on the main chain. The process of identifying cold data blocks can be formally expressed as the judgment condition being:

[0101]

[0102] in: A Boolean function represents a block. Is it cold data? It is a function representing a block. In the most recent time window The function is considered true when the number of visits is 0. In practice, the steps for dynamically updating the meat production history map in the distribution process include deploying onboard data acquisition terminals on cold chain transport vehicles. These terminals continuously record ambient temperature and latitude / longitude coordinates; for example, the terminal collects the vehicle's temperature data and GPS coordinates every 5 minutes and stores them locally. When an ambient temperature fluctuation exceeds a preset limit or a cross-regional change in latitude / longitude coordinates is detected, a distribution event record is generated. The preset limit is a temperature change exceeding 2 degrees Celsius within 10 minutes. A cross-regional change occurs when the administrative division code corresponding to the coordinates changes. For example, if the temperature rises from 3 degrees Celsius to 6 degrees Celsius within 5 minutes, the record "{Event Type: Temperature Anomaly, Time: 2026-02-01 15:05, Original Temperature: 3, New Temperature: 6}" is generated.

[0103] The circulation event record is associated with the individual identifier code and encapsulated as a circulation stage supplementary data block. The timestamp of the circulation stage supplementary data block is taken from the system clock of the vehicle data acquisition terminal. For example, the record is associated with the individual identifier code "PIG-2026-1001" and encapsulated as a structured data block of {"Stage Type Label":"Circulation Supplement", "Individual Identifier Code":"PIG-2026-1001", "Event":{...}, "Timestamp":"2026-02-0115:05:30"}. The circulation stage supplementary data block is submitted to the consortium blockchain network. After consensus verification, it is written into the blockchain ledger and triggers an incremental update of the meat production history graph. A circulation event branch node is added to the directed acyclic graph. For example, the supplementary data block is written to the new block height 95. The system then adds a child node after the original circulation node in the graph corresponding to individual "PIG-2026-1001" and binds it to block height 95. Optionally, the vehicle-mounted data acquisition terminal submits cached event records in batches when the network is connected. It can be understood that the dynamic update mechanism allows the map to reflect real-time status changes during the circulation process, enhancing the timeliness of traceability information. Data comparison shows that before dynamic updates, the circulation branches of the meat production traceability map terminated at the warehousing node; after dynamic updates, the map extends new nodes under the circulation branches to reflect abnormal temperature events during transportation.

[0104] See Figure 5This is a bar chart showing the frequency of access to blockchain blocks, visually illustrating the distribution of access popularity at different block heights within the meat production traceability consortium blockchain. Early blocks (height < 60) see their access frequency gradually climb from 0 to approximately 80, representing the data cold start phase with low access volume. Mid-term blocks (height 60-80) maintain a stable access frequency between 80 and 95, entering a period of high business activity. Late-term blocks (height 80-100) reach peak access frequency (exceeding 105), representing the most popular query area across the entire chain. Active blocks are concentrated in the height range of 0-20, with extremely low access frequency (< 10), representing early-stage farming data blocks. Data from the circulation stage is the core focus of user queries, while farming stage data has the lowest access volume. For the frequently accessed late-term blocks (height > 60), the blockchain node storage and index design can be optimized to improve the response speed of history queries.

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

Claims

1. A blockchain-based meat production information management method, characterized by, include: Collect raw business data from the entire meat production chain, and encapsulate the raw business data into structured data blocks with timestamps according to the production stage. The structured data blocks embed the individual identifier code as a cross-stage association index. The structured data block is submitted to the consortium blockchain network for consensus verification. After successful verification, the structured data block is written into the blockchain ledger, generating an immutable block record. Read the block records in the blockchain ledger and extract the full-link data fingerprint corresponding to the individual identifier code. The data fingerprint is formed by concatenating the hash values ​​of the structured data blocks in each link. Based on the data fingerprint, a visualized meat production history map is generated. The meat production history map uses the individual identifier code as the root node and the structured data blocks of each link as branch nodes to construct a complete data link from breeding to distribution. Receive a resume query request from a terminal device, the resume query request carrying the individual identifier code to be queried; Based on the individual identifier code to be queried, the corresponding branch node data is retrieved in the meat production history map, and the retrieved branch node data is assembled into a standardized history response message. The standardized traceability response message is returned to the terminal device, completing an on-chain traceability process for meat production information. 2.The blockchain-based meat production information management method of claim 1, wherein, The original business data is encapsulated into structured data blocks with timestamps according to the production stage, including: The original business data includes individual identification codes, feed feeding records and vaccination records in the breeding process, batch quarantine certificates, carcass segmentation diagrams and weighing data in the slaughtering process, and temperature monitoring logs and geographical location change records in the circulation process. The individual identification codes, feed feeding records, and vaccination records of the breeding process are aligned to generate a breeding stage data table; The batch quarantine certificates, carcass segmentation diagrams, and weighing data from the slaughtering process are normalized to generate a slaughtering stage data table; The temperature monitoring logs and geographical location change records of the aforementioned circulation process are sorted chronologically to generate a circulation stage data table. Extract the header fields and body content of the data tables for the breeding stage, slaughtering stage, and circulation stage respectively, and calculate the combined hash value of the header fields and body content; The combined hash value, current system time, and stage type label are packaged and appended to the data table of each stage to form the structured data block with timestamp. 3.The blockchain-based meat production information management method of claim 2, wherein, Submitting the structured data block to the consortium blockchain network for consensus verification includes: Read the stage type label in the structured data block to determine the list of authorized nodes responsible for the corresponding stage of the read structured data block; The structured data block is broadcast to all nodes in the authorized node list, triggering a multi-party cross-verification process; Each authorized node extracts the business data within the structured data block and compares it with the original vouchers it retains. The original vouchers include electronic scans of paper documents and original sensor logs. If the comparison results of all authorized nodes are consistent, a signature certificate for agreeing to write is generated; After collecting a preset number of signature credentials, a new block containing the structured data block and all signature credentials is constructed and appended to the end of the blockchain ledger. 4.The blockchain-based meat production information management method of claim 3, wherein, Reading block records from the blockchain ledger and extracting the full-link data fingerprint corresponding to the individual identifier includes: Traverse all blocks of the blockchain ledger, locate the structured data block of the breeding stage containing the individual identifier code, and record the height of the block where the structured data block of the breeding stage is located and the offset address within the block where the structured data block of the breeding stage is located. Using the individual identifier as an index, continue to search for the slaughter stage structured data block and the circulation stage structured data block containing the same individual identifier in the subsequent blocks, and record the block height and offset address of each block. Following the order of breeding, slaughtering, and distribution, the hash values ​​of the structured data blocks at each stage are read sequentially, and the hash values ​​are concatenated into a string; A second hash operation is performed on the string to generate a full-link data fingerprint of a fixed length, and the full-link data fingerprint and its corresponding block location information are cached locally. 5.The blockchain-based meat production information management method of claim 4, wherein, Based on the data fingerprint, a visualized meat production history map is generated, including: Initialize an empty directed acyclic graph structure, and use the individual identifier code as the root node of the directed acyclic graph; Based on the block location information corresponding to the data fingerprint, all fields of the structured data block of the breeding stage are read from the blockchain ledger and transformed into the attribute list of the root node. Create the first branch node, bind the height of the block containing the structured data block of the breeding stage, and attach the attribute list to the branch node; The process of creating branch nodes is repeated, creating corresponding branch nodes for the structured data blocks in the slaughtering stage and the structured data blocks in the circulation stage in turn, and establishing directed edges from the root node to each branch node in the directed acyclic graph according to the production time sequence. The directed acyclic graph is rendered as the meat production history map, and the arrows on the directed edges indicate the direction of the production process. 6.The blockchain-based meat production information management method of claim 5, wherein, The receiving of a resume query request from a terminal device includes: Listen to the data message body of the API gateway layer and parse the protocol version number and request type fields in the data message body; When the value of the request type field is a resume query, extract the authentication token and the individual identifier code to be queried from the data packet body; Verify the validity of the authentication token. If the verification is successful, store the individual identifier code to be queried in the query task queue; otherwise, discard the data packet body. The individual identifier code to be queried is popped from the query task queue, triggering the subsequent resume retrieval process. 7.The blockchain-based meat production information management method of claim 6, wherein, Based on the individual identifier code to be queried, the corresponding branch node data is retrieved in the meat production history map, including: Access the graph storage engine, call the index interface with the individual identifier code as the key, and obtain the memory pointer of the meat production history graph; Following the directed acyclic graph structure pointed to by the memory pointer, all branch nodes are traversed in a depth-first manner; In each branch node, the block height bound to the branch node is read, and the corresponding structured data block original text is retrieved from the blockchain ledger according to the block height; The original structured data blocks of each branch node are parsed into key-value pairs of business data and then aggregated into a branch node dataset. 8.The blockchain-based meat production information management method of claim 7, wherein, The step of assembling the retrieved branch node data into a standardized history response message includes: Define the top-level structure of the resume response message, which includes three parts: message header, data body, and session identifier; Enter the operation serial number and response generation time of this query into the message header; In the data body, the business data in the branch node dataset are arranged in the order of breeding, slaughtering, and distribution, and the block height and data generation time of the source are appended to each business data item. The authentication token recorded in the query task queue is entered into the session identifier to complete the assembly of the standardized resume response message. 9.The blockchain-based meat production information management method of claim 8, wherein, It also includes the step of performing data cleaning on historical blocks in the blockchain ledger, including: Regularly analyze the access frequency of each block and generate a block popularity ranking; Identify the cold data blocks that rank low in the block popularity ranking list. The cold data blocks refer to blocks that have not been accessed by any history query requests in the recent period of time. The structured data blocks in the cold data block are de-identified, and the de-identification process includes deleting detailed address information and contact information that can be used to infer personal identity; The de-identified cold data blocks are migrated to the archive storage cluster, and their data fingerprints and block height indexes are retained in the blockchain ledger to maintain the integrity of the meat production history map. 10.The blockchain-based meat production information management method of claim 9, wherein, It also includes the step of dynamically updating the meat production history map during the distribution process, including: An on-board data acquisition terminal is deployed on a cold chain transport vehicle, and the on-board data acquisition terminal continuously records the ambient temperature and latitude and longitude coordinates; When an ambient temperature fluctuation exceeds a preset limit or a cross-regional change in latitude and longitude coordinates is detected, a circulation event record is generated. The circulation event record is associated with the individual identifier and encapsulated into a circulation stage supplementary data block. The timestamp of the circulation stage supplementary data block is taken from the system clock of the vehicle data acquisition terminal. The supplementary data block for the circulation stage is submitted to the consortium blockchain network. After consensus verification, it is written into the blockchain ledger and triggers an incremental update of the meat production history graph, adding a circulation event branch node to the directed acyclic graph.

Images