Block chain verification method for quality safety tracing of catches

Abstract

The invention relates to the technical field of catch safety tracing, and discloses a block chain verification method for catch quality safety tracing. The method comprises the following steps: acquiring environmental parameter data of catches in the links of fishing, transportation and storage through a distributed sensor network, and encrypting according to a timestamp sequence to generate a catches environmental data chain; key environment indexes are extracted based on the data chain, an abnormal deviation degree is calculated by using a dynamic weight distribution algorithm, and a catch quality risk score is generated; dividing risk levels according to the risk scores, mapping data of different risk levels to a block chain differentiation storage layer, and constructing a fragment storage structure; performing redundancy verification on the high-risk data through an intelligent contract triggering mechanism, and calling a consensus node to perform cross verification to generate a verification result; and performing association analysis on the verification result and the risk score, updating the risk tag and synchronizing the risk tag to a block chain distributed account book. According to the method, full-link data tracing and verification of the catches are realized, and the data credibility and the quality control accuracy are improved.

Description

Technical Field

[0001] This invention relates to the field of fishery safety traceability technology, specifically a blockchain verification method for fishery quality and safety traceability. Background Technology

[0002] In the entire supply chain of fisheries, from catch to consumption, quality and safety traceability is a crucial link in protecting consumer rights and maintaining market order. Currently, fisheries quality and safety traceability largely relies on centralized management methods. These methods typically involve a single institution or platform responsible for data collection, storage, and management, which carries risks of data tampering and single points of failure. In the fishing stage, traditional data collection methods rely heavily on manual recording, which is prone to data delays, omissions, or falsification, making it impossible to accurately reconstruct the true environmental conditions of the catch during subsequent traceability. In the transportation stage, environmental parameter monitoring often uses local sensors or phased recording modes, making it difficult to achieve real-time monitoring throughout the entire process. Once anomalies occur in the transportation environment, it is impossible to promptly detect and trace the time and cause of the anomaly. Data management in the storage stage often faces the problem of data not being shared between different storage facilities, creating information silos and making it difficult to fully present the quality changes of the catch during storage.

[0003] Current traceability methods often employ fixed-weight algorithms to assess the quality risk of catches, neglecting the varying impacts of different environmental indicators on catch quality at different stages of distribution. This results in insufficient accuracy of risk assessments and fails to provide effective guidance for subsequent quality control. Regarding data storage, traditional methods often use a uniform storage model without differentiated management based on the catch's quality risk level. This not only increases the difficulty of verifying high-risk data but also wastes storage resources. Furthermore, existing methods lack effective data verification mechanisms. For catch data with quality risks, it is difficult to achieve cross-verification through multi-party consensus, leading to reduced data credibility. Consumers and regulatory authorities struggle to make accurate judgments based on traceability data, ultimately impacting the healthy development of the catch market and consumer trust in catch quality. Summary of the Invention

[0004] The purpose of this invention is to provide a blockchain verification method for tracing the quality and safety of fish catches, so as to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides a blockchain verification method for tracing the quality and safety of fish catches, the method comprising:

[0006] The method collects environmental parameter data of fish catches during the fishing, transportation and storage stages through a distributed sensor network, and encrypts the environmental parameter data according to the timestamp sequence to generate a fish catch environmental data chain.

[0007] Based on the aforementioned fishery environmental data chain, key environmental indicators are extracted, and the abnormal deviation of each environmental indicator is calculated through a dynamic weight allocation algorithm to generate a fishery quality risk score.

[0008] Based on the risk score of the catch, risk levels are divided, and the environmental data chains of catches with different risk levels are mapped to the differentiated storage layer of the blockchain to construct a sharded storage structure.

[0009] The high-risk data in the sharded storage structure is redundantly verified by a smart contract triggering mechanism, and a preset consensus node is invoked to cross-validate the high-risk data to generate a verification result.

[0010] The verification results are correlated with the catch quality risk score, the risk label of the catch environmental data chain is updated, and the updated risk label is synchronized to the distributed ledger of the blockchain.

[0011] Preferably, environmental parameter data of fish catches during the fishing, transportation, and storage stages are collected through a distributed sensor network. This environmental parameter data is then encrypted according to a timestamp sequence to generate a fish catch environmental data chain. Specifically:

[0012] Multiple types of sensor nodes are deployed along the fish transport path to collect temperature, humidity, salinity and vibration intensity data in real time, forming a raw environmental parameter dataset;

[0013] The original environmental parameter dataset is timestamped, and an asymmetric encryption algorithm is used to encrypt the data packet corresponding to each timestamp to generate an encrypted data unit.

[0014] The encrypted data units are linked in chronological order and the hash value of the predecessor unit is appended to construct an immutable fishery environment data chain.

[0015] Preferably, key environmental indicators are extracted based on the fishery environmental data chain, and the abnormal deviation of each environmental indicator is calculated through a dynamic weight allocation algorithm to generate a fishery quality risk score, specifically:

[0016] Temperature fluctuation rate, cumulative humidity deviation, and salinity change gradient were extracted from the aforementioned fishery environmental data chain as key environmental indicators.

[0017] The instantaneous deviation of each key environmental indicator is calculated based on the historical safety threshold range, and the weight allocation ratio is dynamically adjusted in combination with the correlation coefficient between environmental indicators.

[0018] The instantaneous deviation value and the dynamic weight allocation ratio are aggregated by a weighted summation algorithm to output the quality risk score of the catch.

[0019] Preferably, based on the risk score of the catch quality, risk levels are divided, and the environmental data chains of catches with different risk levels are mapped to the differentiated storage layer of the blockchain to construct a sharded storage structure, specifically as follows:

[0020] By setting risk level threshold ranges, the quality risk scores of the catches are divided into three levels: low risk, medium risk, and high risk.

[0021] Each risk level is assigned an independent blockchain storage partition, with high-risk level data stored in a high-frequency verification partition and medium- and low-risk level data stored in a standard verification partition.

[0022] A logically isolated sharded storage structure is constructed by recording the mapping relationship between the catch environment data chain and the storage partition through a sharded index table.

[0023] Preferably, a smart contract triggering mechanism is used to perform redundancy verification on high-risk data in the sharded storage structure, and a preset consensus node is invoked to perform cross-validation on the high-risk data to generate a verification result, specifically as follows:

[0024] When high-risk data is added to the sharded storage structure, the execution conditions of the smart contract are triggered, and a verification request is broadcast to the preset consensus node group.

[0025] Each consensus node independently retrieves the associated historical records of the high-risk data and votes on the authenticity of the data through a majority voting mechanism;

[0026] The voting results are tallied and a consistency verification report is generated. The verification report is then written into the blockchain's temporary transaction log.

[0027] Preferably, the verification results are correlated with the catch quality risk score, the risk label of the catch environmental data chain is updated, and the updated risk label is synchronized to the distributed ledger of the blockchain, specifically as follows:

[0028] Compare the conflicting items between the consistency verification report and the original catch quality risk score, and mark the time interval of the disputed data;

[0029] Based on the time interval of the disputed data, the deviation of environmental indicators was recalculated, and the risk score of the catch quality was corrected using a Bayesian inference algorithm.

[0030] The revised risk score is converted into an update instruction, which is then broadcast to all nodes via the blockchain network to complete the tag synchronization of the distributed ledger.

[0031] Preferably, the method further includes:

[0032] A batch index for catches is established in the distributed ledger, and the environmental data chain and quality risk score of the same batch of catches are aggregated to generate a batch quality profile.

[0033] The blockchain explorer interface provides a query service for the batch quality files, supporting composite searches based on time range, geographical region, and risk level.

[0034] Preferably, a catch batch index is established in the distributed ledger, and the environmental data chain and quality risk score of the same batch of catch are aggregated to generate a batch quality file, specifically:

[0035] Extract the fishing license number and transport document number of the catch as batch identifiers, and construct a batch-data chain mapping table;

[0036] Time series alignment is performed on environmental data chains of catches belonging to the same batch identifier in the mapping table, and key environmental indicator data are merged.

[0037] Calculate the batch-level comprehensive risk index and generate a batch quality profile that includes the original data chain, correction scores, and verification records.

[0038] Preferably, the batch quality records are provided as a query service through a blockchain explorer interface, supporting composite searches based on time range, geographical region, and risk level, specifically:

[0039] Deploy a scalable query engine to parse the time interval, GPS coordinate range, and risk level filtering conditions submitted by the user;

[0040] Locate the batch quality file that matches the conditions in the fragmented storage structure and return the encrypted data digest;

[0041] After authorization, the data digest is decrypted, and a complete catch quality traceability report is output.

[0042] Preferably, the method further includes:

[0043] Periodically scan low-activity batch quality files in the distributed ledger, migrate them to the cold storage layer, and update the shard index table;

[0044] Generate lightweight hash proofs for data migrated to the cold storage layer, enabling rapid verification of data integrity during subsequent audits.

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

[0046] This blockchain verification method for tracing the quality and safety of aquatic products collects environmental parameter data of aquatic products during the fishing, transportation, and storage stages through a distributed sensor network, and generates an environmental data chain of aquatic products by encrypting it according to the timestamp sequence. This achieves real-time, comprehensive collection and tamper-proof storage of environmental data throughout the entire circulation process of aquatic products, avoiding the problems of data lag, omission, or falsification under traditional manual recording methods, and allowing the environmental status of aquatic products at each stage to be accurately restored and traced.

[0047] Based on the environmental data chain of the catch, key environmental indicators are extracted. An abnormal deviation degree is calculated and a quality risk score is generated through a dynamic weight allocation algorithm. The weights can be adjusted according to the actual impact of different environmental indicators at different stages of the catch, so that the risk score is more in line with the real situation of the catch quality changes. Compared with the traditional fixed weight algorithm, it can more accurately reflect the quality risk status of the catch and provide accurate guidance for subsequent quality control.

[0048] Risk levels are determined by the quality risk score of the catch, and data of different risk levels are mapped to a differentiated storage layer on the blockchain to build a sharded storage structure. This achieves hierarchical storage management of data, avoiding the waste of storage resources and the difficulty of verifying high-risk data in the traditional unified storage model. It can not only ensure the storage security and subsequent verification convenience of high-risk data, but also optimize the storage efficiency of medium and low-risk data, thereby improving the rationality and economy of overall data management.

[0049] By using a smart contract triggering mechanism to perform redundant verification of high-risk data, and calling preset consensus nodes for cross-verification to generate verification results, multi-party verification of high-risk data is achieved with the help of the blockchain consensus mechanism. This avoids the problem of insufficient data credibility in the traditional single-institution verification model, improves the authenticity and reliability of high-risk data, and allows regulatory authorities and consumers to trust the quality status of the catch reflected by the traceability data.

[0050] By correlating the verification results with the quality risk score, updating the risk labels in the fishery environmental data chain, and synchronizing them to the blockchain distributed ledger, dynamic updates and full-node synchronization of risk labels are achieved. This ensures that the risk labels obtained by all participants are always consistent and up-to-date, avoiding quality misjudgments caused by information asymmetry. At the same time, the immutability of the distributed ledger further guarantees the authenticity of the risk labels, providing complete and reliable technical support for the traceability of fishery quality and safety, and contributing to the standardized development of the fishery market and the protection of consumer rights. Attached Figure Description

[0051] Figure 1 This is a schematic diagram illustrating the working principle of the blockchain verification method for tracing the quality and safety of fish catches as described in this invention.

[0052] Figure 2A flowchart for generating an environmental data link for fish catches;

[0053] Figure 3 A flowchart for constructing a fragmented storage structure. Detailed Implementation

[0054] 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 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.

[0055] Please see Figure 1 This invention provides a blockchain verification method for tracing the quality and safety of catches. The method integrates a distributed sensor network, blockchain technology, and smart contract mechanisms to achieve quality monitoring and risk verification of catches throughout the entire process from harvesting to storage. The overall solution first utilizes sensor nodes deployed in the catch transportation process to collect environmental parameters such as temperature, humidity, salinity, and vibration intensity. This data is then encrypted with a timestamp sequence to generate an immutable catch environmental data chain. Based on this data chain, the method extracts key environmental indicators such as temperature fluctuation rate and cumulative humidity deviation, calculates the abnormal deviation degree of each indicator through a dynamic weight allocation algorithm, and generates a catch quality risk score. The score results are used to classify the risk into low, medium, and high risk levels, and the data chains of different levels are mapped to a differentiated storage layer of the blockchain, forming a sharded storage structure. For high-risk level data, the smart contract triggers a redundant verification process, calling consensus node groups for cross-validation to generate a consistency verification report. Finally, the method correlates the verification results with the original risk score, updates the risk label of the data chain, and synchronizes it to the distributed ledger, completing closed-loop management of quality traceability.

[0056] Example 1: See Figure 2A sensor network deployed along the fish catch transportation route forms the foundation for data acquisition. This network includes various types of sensing units, such as digital temperature sensors, capacitive humidity sensors, conductivity and salinity sensors, and triaxial accelerometers for monitoring vibration intensity. These nodes are distributed in a self-organizing network in key locations such as fishing vessel holds, transport refrigerated containers, and storage areas. They continuously capture environmental parameters at preset sampling intervals (e.g., every five minutes), forming raw, multi-dimensional time-series datasets. The collected raw data is immediately appended with a high-precision timestamp, derived from a hardware clock module synchronized with Coordinated Universal Time (UTC) to ensure global time series consistency. Each timestamped data packet then enters an encryption process using an asymmetric encryption system. Specifically, the RSA-2048 algorithm is used to process the data packets. The public key used for encryption is provided by an embedded digital certificate, while the corresponding private key is secretly kept by the responsible party for the catch (e.g., the fishing company), thereby generating independent, encrypted data units in ciphertext form. Encrypted data units need to be organized into a tamper-proof chain structure. This method calculates a unique hash value for each unit using the SHA-256 hash algorithm, which uniquely represents the data content of the unit. During the linking process, the header information of the current data unit includes the hash value of the previous data unit, forming a continuous chain of hash pointers. Any attempt to tamper with historical data in the chain will cause its hash value to change, thereby disrupting the logical connection with subsequent units. This makes tampering easily detectable, ultimately constructing a complete, chronologically extended chain of fishery environmental data.

[0057] The generated data chain needs further analysis to assess potential quality risks. The analysis process first extracts several key environmental indicators, which are not raw readings but calculated derived values. Temperature volatility is quantified by analyzing the temperature series over a time window and calculating its standard deviation or range. Humidity cumulative deviation is achieved by accumulating the deviations of the measured humidity values ​​at each sampling point from the upper or lower limits of a preset safety threshold range, reflecting the overall degree of humidity loss of control. Salinity change gradient is captured by calculating the first difference of salinity readings at continuous time points to capture the dynamic trend of salinity changes. The dynamic weight allocation algorithm is the core of the risk score calculation. This algorithm calculates an instantaneous deviation value for each key environmental indicator, reflecting the degree to which the instantaneous value of the indicator deviates from its ideal safety range. The weight allocation is not fixed but takes into account the interaction between indicators. For example, when temperature and humidity data show a high positive correlation, this method will appropriately reduce the weight allocation ratio of one of the indicators to avoid repeated calculations for the same risk source. The weight coefficients are normalized to ensure that the sum of the weights of all indicators is constant at 1. The weighted summation process multiplies the instantaneous deviation of each indicator by its dynamically assigned weight, then sums all the products to output a quantitative risk score for the catch. This score is designed to be a value between 0 and 100, with higher values ​​indicating greater risk based on environmental parameters. This score serves as the direct basis for subsequent risk level classification and blockchain storage strategy decisions.

[0058] Example 2: See Figure 3 This method predefines a clear risk level threshold range, dividing the calculated risk score of 0 to 100 into three discrete levels: 0-30 points are defined as low risk, 31-70 points as medium risk, and 71-100 points as high risk. This classification is based on historical data analysis and industry standards, aiming to differentiate between potential quality issues of varying degrees. After classifying the risk levels, this method maps data of different levels to different storage partitions on the blockchain, implementing differentiated resource allocation and management strategies. High-risk data is directed to the high-frequency verification partition, which is typically supported by high-performance storage devices deployed on core nodes. Multiple replicas are automatically created and distributed across nodes in different geographical locations during data writes to enhance data availability and resilience. Medium- and low-risk data are directed to the standard verification partition, which employs a more economical storage solution with fewer data replicas and a relatively lower frequency of data consistency checks, thereby optimizing overall storage costs while ensuring basic data security.

[0059] To effectively manage these logically isolated storage partitions, this method constructs a sharded index table to record and maintain the mapping relationship between the catch environment data chain and specific physical storage locations. This index table itself employs a fast-querying data structure, such as a hash-based key-value pair set, where the key is the unique identifier of the catch environment data chain (usually its root hash value), and the value is the corresponding storage partition address pointer and necessary metadata. This sharded storage structure ensures that data is placed in the appropriate storage environment according to its importance, while providing a unified logical view for easy subsequent access and retrieval operations. When new data is identified as high-risk and successfully written to the high-frequency verification partition, a pre-defined smart contract monitoring mechanism is triggered. The smart contract predefines execution conditions; for example, when a new data block is detected added to the high-frequency verification partition and its risk score is greater than 70, the contract state machine automatically switches to the pending execution state. The contract then broadcasts a verification request containing the high-risk data identifier to a pre-defined set of consensus nodes in the network. This broadcast process is completed through a peer-to-peer network protocol, aiming to gather enough nodes to participate in the verification work.

[0060] Upon receiving the verification request, each consensus node begins working independently. They first retrieve historical records related to the high-risk data from the blockchain's distributed ledger. These records may include environmental data chains generated by the same catch at previous points in time, historical risk score trends, and other related transaction information. Based on the acquired contextual information, each node independently judges the authenticity and reasonableness of the current high-risk data using a built-in set of rules (e.g., checking whether temperature changes are within a reasonable physiological range, or whether vibration data matches transport logs), and forms its own preliminary opinion. After independent judgment, this method initiates a majority voting mechanism to aggregate the opinions of all nodes. Each consensus node submits its judgment result (usually "approved" or "questioned") as a vote. This method counts all valid votes, and only when the number of "approved" votes exceeds a preset legal threshold (e.g., two-thirds of the total voting nodes) is the batch of high-risk data considered to have passed cross-validation. The voting results are then formatted to generate a timestamped consistency verification report. This report details the participating nodes, their respective voting opinions, and the final conclusion. This report is written as a new transaction to the blockchain's temporary transaction log area, which uses an append-only write mode, thus providing an immutable audit trail for the entire verification process.

[0061] Taking a batch of deep-sea tuna, numbered "CF20231015B," caught in the North Atlantic fishing grounds as an example, the catch was placed in a specially designed refrigerated hold equipped with compliant temperature and humidity sensors. During the return voyage, which lasted several days, the sensor nodes continuously recorded environmental parameters within the hold at a frequency of once per minute, forming a raw data stream. As the fishing vessel approached shore, this method encrypted and chained the environmental data collected during the voyage, generating a complete environmental data chain for the catch, with a root hash value of "a1b2c3d4e5f6...". A risk analysis program was then initiated, extracting key indicators such as temperature fluctuation rate and cumulative humidity deviation during the voyage from the data chain. After dynamic weight calculation, the quality risk score for this batch of catch was determined to be 85 points. Based on a preset threshold range, the score of 85 points automatically classified this batch of data as high-risk. The partitioning action triggers a response from the storage management mechanism, querying the sharding index table to determine that high-risk data should be stored in the high-frequency verification partition numbered "Shard-H-03". This partition is located in a storage pool jointly maintained by multiple coastal port verification nodes. When data is written to the "Shard-H-03" partition, this method automatically creates three identical data copies within that partition and stores these copies on blockchain nodes located in Qingdao, Shanghai, and Guangzhou, respectively, thereby achieving high availability and disaster recovery capabilities. Simultaneously, this method updates the sharding index table, adding a record that binds the identifier "a1b2c3d4e5f6..." of the catch environment data chain to the storage partition address "Shard-H-03", completing the targeted storage of high-risk data. When the data from batch "CF20231015B" along with its risk score of 85 is successfully written to the "Shard-H-03" partition, this event triggers the smart contract monitoring that partition. The contract code detects that the new blockchain transaction contains a high-risk tag with a score greater than 70, thus fulfilling its execution conditions. The smart contract automatically generates a verification request message containing the root hash of the high-risk data, risk score details, and timestamp information. This request is then broadcast to a pre-defined consensus node group via a peer-to-peer network protocol. This node group consists of five authorized nodes representing the fisheries association, quality inspection agency, logistics company, sales enterprise, and port management, respectively.

[0062] Five consensus nodes, distributed across different geographical locations, received the verification request almost simultaneously. Each node began working independently. First, based on the received root hash "a1b2c3d4e5f6...", they queried and retrieved detailed information about the environmental data chain of the "CF20231015B" batch of catch from their local blockchain ledger copy. Next, the nodes attempted to obtain historical background information related to this batch, such as querying environmental data records from other voyages of the fishing vessel within the past month, or comparing temperature and humidity change patterns of similar catches from other fishing vessels in the same sea area during the same period. Based on all the information obtained, each node made independent judgments using its built-in rule set: for example, the fisheries association's node might focus on whether the temperature curve had exceeded the safety threshold for an extended period; the quality inspection agency's node might analyze whether the stability of the humidity data was within an acceptable range.

[0063] After completing their independent analyses, the five consensus nodes submitted their respective judgments. Node 1 (the Fisheries Association), based on historical data, discovered an abnormal temperature rise lasting approximately two hours during the voyage, exceeding the safety threshold; therefore, it voted "Data Suspected Anomaly." Node 2 (the Quality Inspection Agency) believed that although there were temperature fluctuations, the overall humidity control was good, and no unacceptable risks were found; therefore, it voted "Data is Reasonable." Node 3 (the Logistics Company), after checking the transportation logs, found no equipment malfunction records and tended to accept the data's authenticity; therefore, it voted "Data is Reasonable." Node 4 (the Sales Company), based on market experience, believed that such fluctuations were within an acceptable range; therefore, it voted "Data is Reasonable." Node 5 (the Port Management Authority), upon retrieving the port entry rapid testing records, found no obvious problems; therefore, it voted "Data is Reasonable." All votes were collected, resulting in four votes for "Data is Reasonable" and one vote for "Data Suspected Anomaly." According to the preset majority voting rules (a two-thirds majority is required for approval), the high-risk data passed verification. The smart contract then generates a consistency verification report, which includes the verification request ID, participating nodes, voting details for each node, the final conclusion (passed), and the report generation timestamp. This report itself is written as a new transaction to the blockchain's temporary transaction log area, which uses an append-only mode to ensure the immutability and auditability of the verification process. The smart contract-triggered verification process for the high-risk data batch "CF20231015B" is now complete.

[0064] Example 3: This method parses the verification report line by line, paying particular attention to conclusions marked "disputed" or "requires review," and maps these conclusions to the data time points used in the original scoring calculation. This identifies specific data time intervals where problems may exist, typically characterized by abrupt changes in sensor readings or data segments severely inconsistent with environmental patterns. Once the disputed data time intervals are located, a recalculation process is initiated to re-analyze the original environmental parameters within these specific intervals. This recalculation is not a simple repetition of previous steps; rather, it employs more precise algorithms to examine the deviation of environmental indicators. For example, for temperature data, it might calculate the difference between the instantaneous rate of change within the disputed interval and the rate of change in the surrounding stable intervals, thus more sensitively capturing abnormal patterns. The goal of this stage is to obtain more prudent assessment indicators regarding the data quality within the disputed intervals.

[0065] Based on the recalculated deviation information, this method employs a Bayesian inference algorithm to correct the original catch quality risk score. The advantage of the Bayesian method lies in its ability to combine new evidence (i.e., verification reports and recalculated results) with existing knowledge (i.e., historical data distribution and initial scores). The correction process can be expressed as:

[0066]

[0067] Where: symbol Representing the true risk level to be estimated (e.g., low, medium, or high risk), it is an implicit variable. (Symbol) This represents the set of environmental indicator deviation data obtained after recalculation from the disputed time period; this data constitutes new evidence for risk assessment. (Symbol) This represents the independent judgment information provided by the consistency verification report generated after the smart contract is verified, which serves as another important source of evidence. It is the prior probability of the risk state, and its value is based on the historical risk score data of the batch of catch before the disputed period and the general quality statistics of similar products. It is the likelihood function, which describes the likelihood state under the assumption that the true risk state is... Under these conditions, the currently recalculated environmental deviation data were observed. and verification report conclusions The joint probability, which is defined by the built-in risk assessment model. It is a normalization constant that ensures the sum of the posterior probabilities is 1. Ultimately, This is the posterior probability we are looking for, which combines all the old and new information to give the current risk state. The latest probability distribution. Typically, the median risk score corresponding to the risk state with the highest posterior probability is selected as the corrected risk score for the catch quality.

[0068] After generating the revised risk score, this method converts it into a standardized update instruction. This instruction includes a unique identifier for the catch environment data chain to be updated, the revised risk score value, the version number, and a timestamp. This update instruction is broadcast to all participating nodes in the network via the blockchain network's built-in peer-to-peer communication protocol. Upon receiving the broadcast instruction, nodes do not immediately modify their local distributed ledger but instead temporarily store the update instruction in a mempool, awaiting confirmation from the consensus mechanism. The ledger synchronization process relies on a consensus algorithm configured by the network to coordinate the behavior of each node, such as using a state-based replicator mechanism. Under this mechanism, a selected master node collects multiple update instructions received over a period of time, packages them into a proposal block, and then broadcasts the block to other replica nodes. Each replica node independently verifies the legality of all update instructions in the proposal block, including checking the digital signature of the instructions, version number continuity, and permissions. After successful verification, nodes reach a consensus on whether to accept the block through multiple rounds of message exchange. Only when a sufficient number of nodes (e.g., more than two-thirds) reach a consensus will the proposed block be officially added to their respective blockchains. Once the block is successfully added to the chain, each node begins executing the update instructions contained within the block, modifying the risk label of the corresponding catch environment data chain in its local ledger. The label update not only includes a change in risk level but also records the reason for the update (the transaction hash linked to the consensus verification report), the identity of the update initiator, and the exact time of the update.

[0069] Example 4: This method first requires establishing an effective batch indexing mechanism in the distributed ledger. The index construction relies on legally valid identification information generated during the circulation of catches, such as a fishing license number "ZY-2023-08-015" issued by the fisheries management department and a cold chain transport document number "WL20230927008" provided by the logistics company. These two strings are concatenated with underscores to form a composite key "ZY-2023-08-015_WL20230927008", which serves as the unique batch identifier for this batch of catches. Based on this batch identifier, this method creates and maintains a batch-datachain mapping table in the ledger. This table is essentially a set of key-value pairs, where the key is the batch identifier and the value is a list that records the root hash values ​​of all catch environmental data chains belonging to this batch and generated chronologically. For example, for batch “ZY-2023-08-015_WL20230927008”, its mapped value may contain the hashes of three data chains, corresponding to environmental data records of three key nodes: after being caught and brought ashore, when the fish enters the hold, at the intermediate transfer point, and when it enters the destination cold storage.

[0070] Before generating batch quality profiles, all environmental data chains belonging to the same batch in the mapping table need to be time-series aligned and merged. This process first sorts each data chain according to its internal timestamp, forming a continuous timeline. Next, key environmental indicators (such as temperature and humidity) are extracted from each data chain, and these indicator data are stitched together along the timeline to generate a continuous sequence of environmental parameters covering the entire cycle of the batch. For example, the temperature at the end of the fishing stage data chain is compared with the starting temperature of the transportation stage data chain to check for any anomalous jumps at the handover point. After obtaining continuous time-series data, a comprehensive risk index for the batch level is calculated. This index is not simply an average of the risk scores of each data chain, but rather considers the weight of the time period covered by each data chain. For example, a data chain covering a 20-hour transportation process will have a much higher weight in the comprehensive index than a data chain recording only a 15-minute storage process. Through this weighted calculation, a comprehensive risk index that represents the quality status of the entire batch of catch is finally obtained.

[0071] This method generates a structured batch quality profile, which logically encapsulates access pointers to all original data chains, a weighted comprehensive risk index, all relevant smart contract verification records, and merged key environmental indicator statistics (such as average temperature, maximum humidity, and number of vibration exceedances). This profile itself is hashed and stored in a distributed ledger, with its metadata recorded in extended fields of the batch-data chain mapping table. To provide flexible query services, this method deploys a scalable blockchain explorer query engine. This engine is designed to parse complex search criteria submitted by users through a web interface or API. These criteria are typically encapsulated in JSON format, such as {"timeRange": {"start": "2023-09-25T00:00:00Z", "end": "2023-09-28T23:59:59Z"}, "geoRange": {"north": 39.9, "south": 39.4, "east": 116.7, "west": 116.1}, "riskLevel": "HIGH"}. This means that the user wants to query all fish catches that flowed through the geographical area of ​​Beijing between 116.1-116.7 degrees east longitude and 39.4-39.9 degrees north latitude between September 25 and 28, 2023, and were marked as high-risk.

[0072] Upon receiving a request, the query engine first performs identity authentication and authorization checks to verify whether the requester has permission to access this type of data. After successful verification, the engine begins locating batch quality files matching the criteria within the sharded storage structure. It first performs preliminary filtering in the metadata index based on the submitted time range and GPS coordinate range, and then compares the batch's risk level. For matching batches, the engine does not directly return the complete file data; instead, it generates an encrypted data packet containing a summary information such as the batch identifier, file hash value, and comprehensive risk index, and returns it to the user. When a user needs to view the details of a specific batch quality file, this method performs a second permission verification to confirm that the user has the right to access the data for that specific batch. After successful verification, the complete file data is retrieved from the storage layer, decrypted, and assembled into the final catch quality traceability report. This report is presented in a graphical and textual format, potentially including graphs of environmental parameters changing over time, timelines of risk level changes, stamps from each verification stage, and related logistics information.

[0073] Table 1: Batch Quality Record Data Table

[0074] Batch identifier Includes the number of data chains Data link start timestamp Data link termination timestamp Overall Risk Index File status Last updated ZY-2023-08-015_WL20230927008 3 2023-09-27T08:15:30Z 2023-09-28T16:40:00Z 68.5 Verified 2023-09-29T10:00:12Z LN-2023-09-101_WL20231005022 2 2023-10-05T14:20:15Z 2023-10-06T09:05:18Z 24.1 To be verified 2023-10-06T09:30:05Z SD-2023-09-205_WL20231012015 4 2023-10-12T03:10:40Z 2023-10-13T18:35:20Z 82.3 High-risk monitoring 2023-10-13T20:15:33Z

[0075] Referring to Table 1, some key metadata of the batch quality file is displayed. For example, batch "SD-2023-09-205_WL20231012015" contains four environmental data chains, covering the circulation cycle from October 12th to 13th, 2023. Its comprehensive risk index is 82.3, and this method has marked it as "high-risk under monitoring," which means that smart contract verification for this batch may have been triggered or is ongoing. This tabular metadata view facilitates internal management and rapid retrieval, and is also a clear form of displaying a list of query results to authorized users. The entire implementation aggregates fine-grained data into business objects and provides powerful composite query capabilities, enabling quality traceability information to be used efficiently and securely.

[0076] Example 5: This method periodically scans the entire distributed ledger. The scan task is automatically initiated by the management node during off-peak hours. The goal of the scan is to identify data archives that meet the definition of "low activity." The criteria for determining low activity are typically based on the last access timestamp. For example, a threshold is set; if the last query time of a batch of quality archives is more than 365 days after the current scan time, the archive is marked as a candidate for migration. The scan process traverses all records in the batch-data chain mapping table, checking the metadata fields corresponding to each record. A migration assessment report is generated for each candidate migration object. The report includes the archive's identifier, creation time, last access time, total data size, and the estimated access probability model calculation results. This report helps the method optimize migration strategies, such as prioritizing the migration of archives with large data volumes and extremely low access probabilities.

[0077] After determining the list of files to be migrated, this method begins the actual migration operation. The migration process is not a simple file move, but a rigorous data transfer and link update process. First, in the cold storage layer, typically using an object storage-based archiving service, a new storage location is created for the files to be migrated. The complete batch quality archive data, including all its environmental data links, verification records, risk scoring history, etc., is transmitted and written to the cold storage layer in compressed and encrypted form. After the data writing is complete, a permanent access address for the data is obtained from the cold storage layer. Next, the shard index table needs to be updated to reflect this migration. The update operation is critical; it needs to maintain the accuracy of the data's logical location. This method does not directly delete the original address pointer of the file in the hot storage layer from the shard index table. Instead, it modifies the pointer type, changing it from a "data pointer" pointing to the original data to a "redirect pointer" pointing to the new location in the cold storage layer. Simultaneously, the migration time, operator identifier, and new storage path information are recorded in the metadata of the index table entry. This design ensures that even if the physical location of the data changes, the data can still be accurately located through the shard index table. After data is migrated to the cold storage layer, an efficient method is needed to verify the integrity of this offline data without frequently retrieving the entire data itself to meet potential future audit or verification needs. This method employs a scheme to generate lightweight hash proofs. Specifically, after the migration operation is complete, this method calculates a cryptographic hash value for the batch quality archive data successfully stored in cold storage, for example, using the SHA-256 algorithm. This hash value is referred to as the data's "content fingerprint."

[0078] A single archive hash value is inefficient for batch auditing. To optimize this, this method constructs a Merkle tree structure for multiple batches of quality archives migrated during the same period. In this tree structure, each leaf node corresponds to the hash value of a migrated archive, while non-leaf nodes are obtained by concatenating the hash values ​​of their two child nodes and then calculating the hash. In this way, a unique root hash is formed, which represents the overall state of all archive data migrated within a certain time window. This lightweight root hash proof is stored in a special index in the main storage layer (hot storage) and associated with metadata such as the timestamp of the batch migration and the list of archive identifiers included. When subsequent auditing is required to verify whether the data of a batch of archives in cold storage is intact and untampered, the audit does not need to retrieve the complete cold data. It only needs to obtain the adjacent hash values ​​required to construct its Merkle tree path from the hot storage layer based on the identifier of the archive to be verified, and then verify whether the final root hash matches the pre-stored root hash proof through a small amount of hash calculation. If they match, it proves that the archive data has maintained its integrity since the migration. This mechanism significantly reduces the access pressure on the cold storage layer during the auditing process, improving verification efficiency. The entire data archiving and proof generation process forms a complete closed loop for historical data management. It enables high-value but infrequently accessed quality traceability data to be stored long-term in a more economical way, while ensuring data verifiability through cryptographic techniques.

[0079] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0080] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A blockchain verification method for tracing the quality and safety of fish catches, characterized in that, Includes the following steps: Environmental parameter data of fish catches during the fishing, transportation and storage stages are collected by a distributed sensor network. The environmental parameter data is then encrypted according to the timestamp sequence to generate a fish catch environmental data chain. Based on the aforementioned fishery environmental data chain, key environmental indicators are extracted, and the abnormal deviation of each environmental indicator is calculated through a dynamic weight allocation algorithm to generate a fishery quality risk score. Based on the risk score of the catch, risk levels are divided, and the environmental data chains of catches with different risk levels are mapped to the differentiated storage layer of the blockchain to construct a sharded storage structure. The high-risk data in the sharded storage structure is redundantly verified by a smart contract triggering mechanism, and a preset consensus node is invoked to cross-validate the high-risk data to generate a verification result. The verification results are correlated with the catch quality risk score, the risk label of the catch environmental data chain is updated, and the updated risk label is synchronized to the distributed ledger of the blockchain.

2. The blockchain verification method for tracing the quality and safety of fish catches according to claim 1, characterized in that, Environmental parameter data of fish catches during the fishing, transportation, and storage stages are collected through a distributed sensor network. This environmental parameter data is then encrypted according to a timestamp sequence to generate a fish catch environmental data chain. Specifically: Multiple types of sensor nodes are deployed along the fish transport path to collect temperature, humidity, salinity and vibration intensity data in real time, forming a raw environmental parameter dataset; The original environmental parameter dataset is timestamped, and an asymmetric encryption algorithm is used to encrypt the data packet corresponding to each timestamp to generate an encrypted data unit. The encrypted data units are linked in chronological order and the hash value of the predecessor unit is appended to construct an immutable fishery environment data chain.

3. The blockchain verification method for tracing the quality and safety of fish catches according to claim 2, characterized in that, Based on the aforementioned fishery environmental data chain, key environmental indicators are extracted. An abnormal deviation degree for each environmental indicator is calculated using a dynamic weight allocation algorithm to generate a fishery quality risk score. Specifically: Temperature fluctuation rate, cumulative humidity deviation, and salinity change gradient were extracted from the aforementioned fishery environmental data chain as key environmental indicators. The instantaneous deviation of each key environmental indicator is calculated based on the historical safety threshold range, and the weight allocation ratio is dynamically adjusted in combination with the correlation coefficient between environmental indicators. The instantaneous deviation value and the dynamic weight allocation ratio are aggregated by a weighted summation algorithm to output the quality risk score of the catch.

4. The blockchain verification method for tracing the quality and safety of fish catches according to claim 3, characterized in that, Based on the risk score of the catch, risk levels are divided, and the environmental data chains of catches at different risk levels are mapped to the differentiated storage layer of the blockchain to construct a sharded storage structure, specifically as follows: By setting risk level threshold ranges, the quality risk scores of the catches are divided into three levels: low risk, medium risk, and high risk. Each risk level is assigned an independent blockchain storage partition, with high-risk level data stored in a high-frequency verification partition and medium- and low-risk level data stored in a standard verification partition. A logically isolated sharded storage structure is constructed by recording the mapping relationship between the catch environment data chain and the storage partition through a sharded index table.

5. The blockchain verification method for tracing the quality and safety of fish catches according to claim 4, characterized in that, The high-risk data in the sharded storage structure is redundantly verified through a smart contract triggering mechanism. A preset consensus node is invoked to perform cross-validation on the high-risk data, generating verification results. Specifically: When high-risk data is added to the sharded storage structure, the execution conditions of the smart contract are triggered, and a verification request is broadcast to the preset consensus node group. Each consensus node independently retrieves the associated historical records of the high-risk data and votes on the authenticity of the data through a majority voting mechanism; The voting results are tallied and a consistency verification report is generated. The verification report is then written into the blockchain's temporary transaction log.

6. The blockchain verification method for tracing the quality and safety of fish catches according to claim 5, characterized in that, The verification results are correlated with the catch quality risk score to update the risk label of the catch environmental data chain, and the updated risk label is synchronized to the distributed ledger of the blockchain, specifically as follows: Compare the conflicting items between the consistency verification report and the original catch quality risk score, and mark the time interval of the disputed data; Based on the time interval of the disputed data, the deviation of environmental indicators was recalculated, and the risk score of the catch quality was corrected using a Bayesian inference algorithm. The revised risk score is converted into an update instruction, which is then broadcast to all nodes via the blockchain network to complete the tag synchronization of the distributed ledger.

7. The blockchain verification method for tracing the quality and safety of fish catches according to claim 6, characterized in that, Also includes: A batch index for catches is established in the distributed ledger, and the environmental data chain and quality risk score of the same batch of catches are aggregated to generate a batch quality profile. The blockchain explorer interface provides a query service for the batch quality files, supporting composite searches based on time range, geographical region, and risk level.

8. The blockchain verification method for tracing the quality and safety of fish catches according to claim 7, characterized in that, A batch index for catches is established in the distributed ledger. Environmental data chains and quality risk scores for the same batch of catches are aggregated to generate batch quality profiles. Specifically: Extract the fishing license number and transport document number of the catch as batch identifiers, and construct a batch-data chain mapping table; Time series alignment is performed on environmental data chains of catches belonging to the same batch identifier in the mapping table, and key environmental indicator data are merged. Calculate the batch-level comprehensive risk index and generate a batch quality profile that includes the original data chain, correction scores, and verification records.

9. The blockchain verification method for tracing the quality and safety of fish catches according to claim 8, characterized in that, The blockchain explorer interface provides a query service for the batch quality records, supporting composite searches based on time range, geographical region, and risk level. Specifically: Deploy a scalable query engine to parse the time interval, GPS coordinate range, and risk level filtering conditions submitted by the user; Locate the batch quality file that matches the conditions in the fragmented storage structure and return the encrypted data digest; After authorization, the data digest is decrypted, and a complete catch quality traceability report is output.

10. The blockchain verification method for tracing the quality and safety of fish catches according to claim 9, characterized in that, Also includes: Periodically scan low-activity batch quality files in the distributed ledger, migrate them to the cold storage layer, and update the shard index table; Generate lightweight hash proofs for data migrated to the cold storage layer, enabling rapid verification of data integrity during subsequent audits.

Images