Food Safety Big Data Sharing Management Method and System under Cloud-Chain Integration Mechanism

Abstract

This application relates to the field of distributed storage technology, and in particular to a method and system for sharing and managing food safety big data under a cloud-chain fusion mechanism. The method includes: receiving a sharing request from a first user, along with the food safety data to be shared, the user's identity identifier, a list of available storage clouds, and a sharing policy; generating a second-level code identifier for the first user from the food safety data to be shared, the user's identity identifier, the list of available storage clouds, and the sharing policy based on a second-level code identifier generation rule; storing the food safety data to be shared on a multi-cloud storage terminal based on the first user's second-level code identifier, the sharing policy, and the list of available storage clouds; and sharing the first user's food safety data according to the data acquisition request received from a second user. This solves the problems of inefficient collaborative management and low security of shared data in related technologies, achieving efficient and reliable food safety big data sharing and management.

Description

Technical Field

[0001] This application relates to the field of distributed storage technology, and in particular to a method and system for sharing and managing food safety big data under a cloud-chain fusion mechanism. Background Technology

[0002] Food safety big data is characterized by its full-chain nature, dispersion, and multi-source heterogeneity. Numerous participants in the food safety supply chain store and manage their data according to their own standardized formats. However, the lack of effective data sharing and management hinders the efficient acquisition of necessary data from various stages of the food supply chain for data analysis.

[0003] Among related technologies, cloud computing provides users with convenient and easy-to-use storage and computing services, avoiding redundant computing and storage to a certain extent, and enabling cross-platform services with flexibility. Cloud-based data sharing and management solutions effectively reduce the difficulty and cost of building and maintaining data systems. However, relying on a centralized third-party cloud platform means that if the platform fails or completely collapses, a large amount of data will be lost, threatening the security and reliability of food safety data stored by various institutions.

[0004] On the one hand, to reduce the risk of single points of failure, the industry has proposed using a multi-cloud platform collaborative storage model (rich cloud model) to share data. Using multiple cloud providers can provide geographically distributed storage, and storing data across multiple clouds offers a significant advantage in reliability. However, due to the difficulty of unified multi-cloud management, the industry is developing centralized management platforms and tools to achieve multi-cloud data sharing and access. Nevertheless, centralized data management contradicts the original intention of data sharing; therefore, how to adopt a decentralized approach to solve the problem of cross-platform data collaboration and consistency management and effectively resist single points of failure is a major challenge currently facing food safety data sharing.

[0005] On the other hand, in order to ensure that the business can successfully obtain the required shared data in the event of a failure, it is necessary to establish a high availability comparison mechanism for data to ensure the quality of shared data. Since establishing trust relationships among multiple parties becomes particularly complex in a multi-cloud environment, how to verify the efficiency and reliability of food safety big data has become another problem faced by the collaborative storage and sharing model of multi-cloud platforms. Summary of the Invention

[0006] This application provides a food safety big data sharing management method and system under the cloud-chain integration mechanism to solve problems such as inefficient collaborative management of related technologies, low security of shared data, and potential single points of failure, so as to achieve efficient and reliable food safety big data sharing management.

[0007] The first aspect of this application provides a method for sharing and managing food safety big data under a cloud-chain fusion mechanism, including the following steps:

[0008] Receive the sharing request, food safety data to be shared, user identification, list of available storage clouds, and sharing policy provided by the first user;

[0009] Based on the secondary coding identifier generation rules, the food safety data to be shared, user identity identifier, available storage cloud list, and sharing policy are used to generate a secondary coding identifier for the first user; and

[0010] Based on the first user's secondary code identifier, the sharing strategy, and the list of available storage clouds, the food safety data to be shared is stored on a multi-cloud storage terminal, and when a data acquisition request from a second user is received, the food safety data of the first user is shared according to the data acquisition request.

[0011] Optionally, before obtaining the food safety data of the first user requesting to share the data, the method further includes:

[0012] Based on the second-level coding identifier generation rule, the data acquisition application is parsed to obtain the second user identity identifier and the data storage identifiers of each sub-data of the data to be acquired.

[0013] Based on the data storage identifiers of each sub-data of the data to be acquired, the data is downloaded from the multi-cloud storage terminal to obtain each sub-data of the data to be acquired.

[0014] The integrity of each sub-data of the data to be acquired is verified based on the digital hash, and after the verification is passed, data aggregation is performed to obtain the data to be acquired, and the data to be acquired is shared with the second user.

[0015] Optionally, the above-mentioned food safety big data sharing and management method under the cloud-chain integration mechanism also includes:

[0016] Receive the user identity identifier to be deleted and the food safety data to be deleted provided by the first user;

[0017] Based on the secondary coding identifier generation rules, the user identity identifier to be deleted and the food safety data to be deleted are parsed to obtain cloud-shared data with address pointers;

[0018] While deleting the cloud-shared data with the address it points to from the multi-cloud storage terminal, the second-level code identifier of the first user is also deleted.

[0019] Optionally, the above-mentioned food safety big data sharing and management method under the cloud-chain integration mechanism also includes:

[0020] Receive new food safety data and the first user's identity certificate provided by the first user;

[0021] Based on the aforementioned secondary coding identifier generation rules, the new food safety data replaces the existing food safety data.

[0022] Optionally, the step of generating a second-level code identifier for the first user based on the second-level code identifier generation rules, using the food safety data to be shared, user identity identifier, available storage cloud list, and sharing policy, includes:

[0023] Receive the identifier registration request sent by the first user;

[0024] Based on the secondary coding identifier generation rules and the identifier registration request, the food safety data to be shared, user identity identifiers, available storage cloud list, and sharing policy are registered with identifiers.

[0025] Extract the user identity identifier and the food safety data identifier to be shared from the registered data, construct a short identifier, construct a long identifier from the remaining data, and then send the short identifier to the first user.

[0026] A second aspect of this application provides a food safety big data sharing and management system based on a cloud-chain fusion mechanism, comprising:

[0027] The first receiving module is used to receive the sharing request and food safety data to be shared, user identification, available storage cloud list and sharing policy provided by the first user;

[0028] The generation module is used to generate a secondary code identifier for the first user based on the secondary code identifier generation rules, using the food safety data to be shared, user identity identifier, available storage cloud list, and sharing policy; and

[0029] The data management module is used to store the food safety data to be shared on a multi-cloud storage terminal based on the first user's secondary code identifier, the sharing policy, and the list of available storage clouds, and to share the first user's food safety data according to the data acquisition request when a second user's data acquisition request is received.

[0030] Optionally, before obtaining the food safety data of the first user requesting to share the data based on the data, the data management module is further configured to:

[0031] Based on the second-level coding identifier generation rule, the data acquisition application is parsed to obtain the second user identity identifier and the data storage identifiers of each sub-data of the data to be acquired.

[0032] Based on the data storage identifiers of each sub-data of the data to be acquired, the data is downloaded from the multi-cloud storage terminal to obtain each sub-data of the data to be acquired.

[0033] The integrity of each sub-data of the data to be acquired is verified based on the digital hash, and after the verification is passed, data aggregation is performed to obtain the data to be acquired, and the data to be acquired is shared with the second user.

[0034] Optionally, the food safety big data sharing and management system under the aforementioned cloud-chain integration mechanism also includes:

[0035] The second receiving module is used to receive the user identity identifier to be deleted and the food safety data to be deleted provided by the first user;

[0036] The acquisition module is used to parse the user identity identifier to be deleted and the food safety data to be deleted based on the secondary coding identifier generation rules, and obtain cloud-shared data with address pointers;

[0037] The deletion module is used to delete the cloud-shared data with the address pointing to it from the multi-cloud storage terminal, and at the same time delete the second-level code identifier of the first user.

[0038] Optionally, the food safety big data sharing and management system under the aforementioned cloud-chain integration mechanism is also used for:

[0039] The third receiving module is used to receive new food safety data and the first user's identity certificate provided by the first user.

[0040] The replacement module is used to replace the food safety data with the new food safety data based on the secondary coding identifier generation rules.

[0041] Optionally, the data management module is further configured to:

[0042] Receive the identifier registration request sent by the first user;

[0043] Based on the secondary coding identifier generation rules and the identifier registration request, the food safety data to be shared, user identity identifiers, available storage cloud list, and sharing policy are registered with identifiers.

[0044] Extract the user identity identifier and the food safety data identifier to be shared from the registered data, construct a short identifier, construct a long identifier from the remaining data, and then send the short identifier to the first user.

[0045] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement the food safety big data sharing and management method under the cloud-chain fusion mechanism as described in the above embodiments.

[0046] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the food safety big data sharing and management method under the cloud-chain fusion mechanism as described in the above embodiments.

[0047] Therefore, by distributing food safety big data across multiple clouds and constructing sparse and uniform storage of the segmented data across multiple clouds through storage allocation strategies, a complete subset of shared food safety data is obtained only through data aggregation across multiple clouds. Furthermore, a unified encoding system based on shared metadata is constructed between the distributed storage data in the multi-cloud environment and the blockchain, using identifier encoding and parsing protocols. Clients then provide user operations such as data storage, updating, querying, and retrieval for food safety data sources to multiple participants. This solves the problems of inefficient collaborative management and low security of shared data in related technologies, achieving efficient and reliable shared management of food safety big data.

[0048] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0049] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0050] Figure 1 This is a flowchart illustrating the food safety big data sharing and management method under the cloud-chain fusion mechanism provided in the embodiments of this application;

[0051] Figure 2 This is a schematic diagram of a cloud-chain converged multi-cloud sharing management architecture for food safety data provided according to an embodiment of this application;

[0052] Figure 3 This is a schematic diagram of a food safety data identification and coding system provided according to an embodiment of this application;

[0053] Figure 4 This is a schematic diagram of a multi-cloud data storage process according to an embodiment of this application;

[0054] Figure 5 This is a schematic diagram of a data update process according to an embodiment of this application;

[0055] Figure 6 This is a schematic diagram of a data acquisition process according to an embodiment of this application;

[0056] Figure 7 This is a schematic diagram of a data deletion process according to an embodiment of this application;

[0057] Figure 8 This is a flowchart of a food safety big data sharing and management method under a cloud-chain fusion mechanism provided in the embodiments of this application;

[0058] Figure 9 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0059] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0060] The following describes a food safety big data sharing management method and system under a cloud-chain fusion mechanism, based on embodiments of this application, with reference to the accompanying drawings. Addressing the issues of inefficient collaborative management and low security of shared data mentioned in the background section, this application provides a food safety big data sharing management method under a cloud-chain fusion mechanism. In this method, food safety big data is distributed across multiple clouds, and a storage allocation strategy is used to construct sparse and uniform storage of the segmented sub-data across multiple clouds. Complete subsets of shared food safety data are obtained only through data aggregation across multiple clouds. Furthermore, a unified encoding of the distributed storage data across multiple clouds and the blockchain based on shared metadata is constructed using an identifier encoding and parsing protocol. Clients provide user operations such as data storage, updating, querying, and retrieval of food safety data to multiple participants in the food safety data source. This solves the problems of inefficient collaborative management and low security of shared data, achieving efficient and reliable food safety big data sharing management.

[0061] Specifically, Figure 1 This is a flowchart illustrating a food safety big data sharing and management method under a cloud-chain fusion mechanism, as provided in an embodiment of this application.

[0062] Before introducing the food safety big data sharing and management method of this application embodiment, let's introduce the blockchain and cloud blockchain integration mechanism.

[0063] Blockchain is a technological solution that collectively maintains a distributed ledger in a decentralized and trustless manner; it is a time-series chained ledger. Blockchain allows members in a distributed peer-to-peer network to conduct trusted interactions in a cryptographically verifiable way, without the need for a trusted third-party institution. Each unit of the blockchain is called a block, and each block includes a block header and a block body. Except for the genesis block, each subsequent block stores the hash value of the data from the previous block, thus linking the blocks together to form an interlocking chain, which constitutes the blockchain.

[0064] Blockchain's security features offer inherent advantages for data protection. However, because full nodes in a blockchain need to synchronize all block data, the large amount of data storage can overload nodes, thus degrading blockchain performance. Cloud storage technology, on the other hand, offers advantages such as large storage capacity and high access performance.

[0065] Therefore, the embodiments of this application can combine the advantages of both to construct a cloud-chain integrated data sharing mechanism, which can complement each other and achieve synergistic effects. This mechanism combines the large storage space and high computing efficiency of the cloud platform with the decentralized and highly trustworthy characteristics of the blockchain, realizing the division of labor and cooperation of storage tasks between the cloud platform and the blockchain, thereby achieving efficient and reliable food safety big data sharing and management under the cloud-chain integrated architecture.

[0066] The cloud-chain storage collaboration method divides the storage and collaborative management of data under the cloud-chain converged architecture. Specifically, the cloud platform stores the specific data of food safety data sources in the form of files, while the blockchain only stores abstract data such as metadata and user requests used for data sharing and management. Through the cloud-chain storage collaboration method, the shared management metadata registered in the blockchain manages and protects the original food safety storage data distributed across multiple cloud environments, focusing on ensuring the consistency of stored data across multiple clouds and the identification and records on the blockchain.

[0067] like Figure 1 As shown, the food safety big data sharing and management method under this cloud-chain integration mechanism includes the following steps:

[0068] In step S101, the system receives a sharing request from the first user, along with the food safety data to be shared, the user's identity identifier, a list of available storage clouds, and a sharing policy.

[0069] Among them, the first user can be a food safety sharing user, and a food safety data sharing user can refer to a participant in the food safety sharing data source.

[0070] Specifically, the first user submits a storage request and provides the food safety data to be shared, user identification, a list of available storage clouds, and sharing policy information. The multi-cloud storage endpoints then upload the data. The blockchain generates a secondary identifier code according to the identifier encoding protocol. When the blockchain identifier registration is complete and a short identifier is returned to the user, it indicates that the shared data has been successfully stored on the multi-cloud platform.

[0071] In step S102, based on the secondary coding identifier generation rules, the food safety data to be shared, the user identity identifier, the list of available storage clouds, and the sharing policy are used to generate a secondary coding identifier for the first user.

[0072] Optionally, in some embodiments, based on the secondary coding identifier generation rules, a secondary coding identifier for the first user is generated from the food safety data to be shared, the user's identity identifier, the list of available storage clouds, and the sharing policy. This includes: receiving an identifier registration request sent by the first user; registering the food safety data to be shared, the user's identity identifier, the list of available storage clouds, and the sharing policy based on the secondary coding identifier generation rules and the identifier registration request; extracting the user's identity identifier and the food safety data identifier to be shared from the registered data, constructing a short identifier, and constructing a long identifier from the remaining data, and then sending the short identifier to the first user.

[0073] In actual implementation, this application embodiment establishes a food safety data identification and coding protocol, and performs identification registration based on the identification and coding rules, including the following steps:

[0074] (1) The first user submits a data sharing request, and the data block interface uploads the data to be stored to the multi-cloud storage terminal after the data is divided into blocks.

[0075] (2) After storing data on the multi-cloud storage terminal, return a list of data storage address URLs.

[0076] (3) The first user initiates an identifier registration request to the blockchain, with parameters including a list of URLs, user identifier, shared data identifier, data sharing level, and available cloud list identifier;

[0077] (4) The blockchain extracts shared metadata, generates short and long identifiers according to the identifier encoding rules, stores the identifiers, and returns the short identifier to the first user.

[0078] It is worth noting that, to ensure global uniqueness, the data identifier encoding rule in this application divides the identifier namespace into a "user registration domain" and a "user data domain." The user registration domain refers to all organizations and groups that register users using blockchain under the cloud-chain integration mechanism. Each organization / group is an element in the user registration domain, distinguished by a user identity identifier. The user data domain refers to all food safety data of a single organization / group. Each data point in the food safety data domain is an element in the user data domain, distinguished by a self-named data identifier. After construction, the short identifier will combine the user identity identifier and the self-named data identifier to construct a globally unique short identifier for data metadata.

[0079] The identification encoding protocol in this application embodiment has a two-level structure, with long identifiers and short identifiers associated. The short identifier is globally unique and used to identify food safety data, while the long identifier is not required to be unique and is used to describe food safety data.

[0080] The short identifier format is: dataOwnerPk|dataID, where dataOwnerPk identifies the user identity in the "User Registration Domain" and dataID represents the user data self-name identifier in the "User Data Domain".

[0081] The long identifier represents a set of shared metadata describing food safety data, comprising: a basic data attribute field, a data sharing strategy field, a data addressing information field, a data verification information field, and an extensible field, which together constitute the shared metadata. Specifically, the basic data attribute field describes the size and type of the food safety data file; the data sharing strategy field describes the data storage period and the amount of data redundancy; the data addressing information field describes the storage address information of each sub-data item in multiple clouds; the data verification information field describes the numerical hash and storage version number information of each sub-data item; and the extensible field contains other attribute information that users need to add, and can be empty.

[0082] After the short and long identifiers are organized, key-value pairs are generated using the short identifier as the key and the long identifier as the value, and stored in the blockchain state database.

[0083] In step S103, based on the first user's secondary code identifier, sharing policy, and available storage cloud list, the food safety data to be shared is stored in a multi-cloud storage terminal, and when a data acquisition request from the second user is received, the food safety data of the first user is shared according to the data acquisition request.

[0084] Optionally, in some embodiments, before sharing the food safety data of the first user according to the data acquisition request, the method further includes: parsing the data acquisition request based on the secondary coding identifier generation rule to obtain the second user's identity identifier and the data storage identifiers of each sub-data of the data to be acquired; downloading the data from a multi-cloud storage terminal according to the data storage identifiers of each sub-data of the data to be acquired to obtain each sub-data of the data to be acquired; verifying the data integrity of each sub-data of the data to be acquired according to the digital hash, and performing data aggregation after the verification is passed to obtain the data to be acquired, and sharing the data to be acquired with the second user.

[0085] The second user can be a food safety acquisition user, which can refer to a user of food safety shared data. Furthermore, the first user / second user, i.e., the participant in the secure shared data source / user of the food safety shared data, can refer to the same user or different users.

[0086] Specifically, the first user submits a data acquisition request and provides a user identity identifier and a data identifier to be acquired. The blockchain performs layered parsing of the secondary identifier code to obtain the data storage identifiers of each sub-data of the data to be acquired. Based on the storage identifiers, the sub-data in the cloud is downloaded by addressing, and the integrity of the sub-data is verified by digital hash. After verification, data aggregation is performed, and the required data is returned to the user.

[0087] In actual implementation, this application embodiment establishes a parsing protocol for shared data secondary identifiers, and completes the data query / data retrieval function requirements based on the parsing protocol. The parsing protocol steps are as follows:

[0088] (1) The first user / second user applies for food safety data query and sends a query request to the blockchain with user identifier and data identifier as parameters.

[0089] (2) The blockchain automatically constructs a short identifier based on the request parameters to obtain the corresponding long identifier in the state database. It parses the long identifier, reverses the construction of shared metadata information, and parses out the list of sub-data storage URLs and the integrity verification digital hash. It sends the data storage URLs and digital integrity hashes to the data aggregation interface. The data aggregation interface obtains sub-data from the specified cloud based on the URL list and the integrity verification digital hash. When the digital integrity hash calculated by the sub-data is consistent with the digital hash value returned by the blockchain, the sub-data is downloaded. When all sub-data is downloaded, the data aggregation operation is performed to construct the requested food safety shared data.

[0090] (3) The data aggregation interface returns the query results / requested food safety shared data to the user.

[0091] Optionally, in some embodiments, the above-described food safety big data sharing management method under the cloud-chain fusion mechanism further includes: receiving a user identity identifier to be deleted and food safety data to be deleted provided by a first user; parsing the user identity identifier to be deleted and food safety data to be deleted based on the secondary code identifier generation rules to obtain cloud-shared data with address pointers; deleting the cloud-shared data with address pointers from the multi-cloud storage terminal while deleting the secondary code identifier of the first user.

[0092] Specifically, the first user submits a deletion request and provides the user's identity identifier and the food safety data identifier to be deleted. The blockchain parses the secondary identifier according to the encoding rules, returns the result to the first user based on the metadata information obtained from the parsing, executes the deletion operation, performs multi-cloud data deletion operation on the cloud shared data pointed to by the parsed address, and deletes the blockchain secondary encoding identifier.

[0093] In actual implementation, the data deletion protocol designed in this application embodiment includes the following steps:

[0094] (1) Data sharing users submit data deletion requests to the client. The request parameters include: user identifier and data identifier to be deleted.

[0095] (2) The multi-cloud storage terminal obtains the long identifier of the data to be deleted based on the blockchain identifier resolution protocol, obtains the sub-data storage URL list, performs the deletion operation on the URL list data, and returns the deletion completion flag after completion.

[0096] (3) The blockchain constructs a short identifier based on the parameters, performs a secondary identifier deletion operation, deletes both the short and long identifiers of the data, and returns a food safety data deletion completion flag to the data sharing user.

[0097] Optionally, in some embodiments, the above-described food safety big data sharing and management method under the cloud-chain fusion mechanism further includes: receiving new food safety data and the first user's identity certificate provided by the first user; and replacing the existing food safety data with the new food safety data based on the secondary coding identifier generation rules.

[0098] Specifically, the first user submits an update request and provides the food safety data to be updated and the user's identity identifier. The blockchain updates the data identifier according to the secondary identifier encoding rules and performs the original data deletion and data to be stored update operations on multiple cloud platforms.

[0099] In actual implementation, the data update protocol designed in this application embodiment includes the following steps:

[0100] (1) Data sharing users request the client to update the stored food safety data. The request parameters include: user identifier, original stored data identifier, and data to be updated.

[0101] (2) The multi-cloud storage terminal updates the content of each sub-data and returns the updated URL list, and the blockchain executes the update request.

[0102] (3) The blockchain updates the list of sub-data storage URLs and integrity verification digital hashes according to the identifier resolution protocol, updates the original stored data long identifier, and returns a data update success flag.

[0103] In summary, the first user uploads data to multi-cloud storage. The blockchain organizes shared metadata, user identifiers, data identifiers, and other information into secondary codes and stores them in the blockchain's distributed state database. The first user has full operational permissions for their data. The second user has query and retrieval permissions based on the purpose of data use. Executing a short identifier query can retrieve the corresponding data's metadata information, and executing a data retrieval operation can return the specified data from the multi-cloud storage to the second user's local end. The multi-cloud storage serves as the data storage medium. After applying for storage services from various clouds, the first user can store the data to be stored in the cloud. After identification encoding and registration through the blockchain, the data scattered across multiple clouds can be uniformly managed. The blockchain stores shared metadata, performs data identification and parsing processes, and stores secondary identifiers. The client, as the interface for responding to user requests, processes various data operation requests from different users, responds to data operation requests through blockchain smart contracts, and returns operation results to the user.

[0104] Therefore, this application embodiment utilizes the large storage capacity and flexible expansion of multi-cloud platforms to store food safety data, leverages the distributed, secure, and trustworthy characteristics of blockchain to store shared metadata, uses digital hashing to verify the integrity of data blocks, and finally establishes a collaborative mechanism between the multi-cloud storage platform and the blockchain network, constructs an identification encoding and identification resolution protocol for food safety data, thereby constructing a food safety big data sharing and management method under a secure and trustworthy cloud-chain fusion mechanism.

[0105] To enable those skilled in the art to further understand the food safety big data sharing and management method under the cloud-chain fusion mechanism of the embodiments of this application, the following detailed description is provided in conjunction with specific embodiments.

[0106] like Figure 2 As shown, Figure 2 This is the architecture of a food safety data sharing management system constructed according to the embodiments of this application.

[0107] I. Food Safety Data Identification and Coding Rules.

[0108] like Figure 3As shown, the identifier is a two-level structure, containing a short identifier and a long identifier. The short identifier is globally unique and used to identify food safety data, while the long identifier is not required to be unique and is used to describe shared food safety data. The short identifier format is: dataOwnerPk|dataID, where dataOwnerPk identifies the user's identity in the "User Registration Domain," and dataID represents the user's self-named identifier for food safety data in the "User Data Domain." The current user's certificate is obtained using the fabric function getCreator(), and the user's identity is obtained by taking the SHA1 hash of the certificate. The self-named identifier for user / organization food safety data can consist of Chinese characters, letters [a-zA-Z], and numbers [0-9], but cannot contain special characters, and the length of the self-named identifier cannot exceed 255 characters.

[0109] As a structure, the long identifier is organized into two parts: a base field and an extension field. The base field contains basic information, sharing strategy, addressing information, and authentication information. The definitions of each field of the secondary identifier are shown in Table 1.

[0110] Table 1

[0111]

[0112] Long identifiers are used to construct shared metadata according to a JSON structure, with each blockMeta identifier representing a data block's metadata, corresponding to... Figure 3 Data block long identifier encoding. The remaining parts consist of the file long identifier encoding after removing the already constructed short identifier part.

[0113] 1. Shared data storage protocol.

[0114] The first user submits a data sharing request to the system through the client-side data sharing and storage interface, such as... Figure 4 As shown, the system performs cloud-based sub-data storage and blockchain-based secondary identifier registration, and finally returns a short identifier to the data sharing user, indicating that data sharing and storage are complete. The specific steps are as follows:

[0115] (1) The first user submits a data storage request through the data sharing and storage interface:

[0116]

[0117] This application embodiment can submit data storage requests through a data sharing storage interface. The request parameters include a function call identifier "DataShare" and input parameter groups dataID, shareLv, dataOwnerCert, and shareCloudList. Among them, dataOwnerCert represents the user certificate, and dataOwnerPk can be calculated from this certificate. shareCloudList identifies the user's available storage cloud list. function serves as a function identifier, with each function mapped to a fixed character. The meanings of the remaining fields are the same as in Table 1.

[0118] (2) The data sharing storage interface receives parameters, receives food safety data, and sends the dataOwnerCert and shareLv parameters to the metadata management smart contract; at the same time, the data sharing storage interface uploads the food safety data to the cloud storage platform according to the shareLv size, and generates storage URLs and corresponding data hashes blockHashs.

[0119] (3) The cloud storage platform sends the address URLs and data hashes after data storage to the blockchain metadata management smart contract module;

[0120] (4) Blockchain smart contracts organize short and long codes RecordCode according to the identifier encoding rules: [shortRecord->completeRecord], construct complete shared metadata, and perform secondary identifier registration according to the identifier registration protocol (Meta Register Protocol, MRP);

[0121] (5) The blockchain executes the request according to the transaction registration - transaction verification - block packaging and sorting process. After passing the request, the secondary identifier RecordCode is written into the blockchain state database.

[0122] (6) The blockchain returns a short recorder of food safety data, shortRecord=dataOwnerPk|dataID, and a shared storage completion identifier, shareState=true, to the first user, indicating that the food safety data storage is complete.

[0123] 2. Data update protocol.

[0124] The first user submits an update request and provides the data to be updated and the user's identity identifier. The blockchain updates the data identifier according to the secondary identifier encoding rules and executes the data update operation for food safety across multiple clouds. Figure 5 As shown, the specific steps are as follows:

[0125] (1) The first user submits a data update request through the data update interface:

[0126]

[0127] This application embodiment allows data update requests to be submitted through a data update interface. The request parameters include the function call identifier "DataUpdate" and the input parameter group dataID, dataOwnerCert, and updateDataID. Among them, updateDataID represents the data used by the user for updating, and the meanings of the other fields are the same as in Table 1. (2) The data update interface receives parameters, receives the food safety data used for updating, sends the Transaction parameter to the metadata management smart contract, and simultaneously uploads the data used for updating to the cloud storage platform and places it in a waiting storage state;

[0128] (3) The metadata management smart contract executes the Meta Parse Protocol (MPP) according to the Transaction parameter, obtains the completeRecord through the mapping of shortRecord, and parses the completeRecord to obtain data URLs and blockHashs;

[0129] (4) The blockchain transmits URLs and blockHashs to the cloud storage platform for addressing and verifying the integrity of the data to be updated. The cloud storage platform uses updateDataID to update the dataID based on the URLs and generates new storage address URLs' and new data hash blockHashs'.

[0130] (5) The cloud storage platform stores the new storage address URLs' and the new data hash blockHashs' into the blockchain smart contract;

[0131] (6) The blockchain smart contract triggers the identifier update instruction, performs RecordCode update, organizes a new RecordCode', keeps the short identifier shortRecord unchanged, organizes and constructs a new long identifier completeRecord' based on the long identifier completeRecord, and updates RecordCode' and writes it to the blockchain state database.

[0132] (7) The blockchain returns a short record of food safety data shortRecord=dataOwnerPk|dataID and an update completion identifier updateState=true to the first user, indicating that the data update is complete.

[0133] 3. Data Acquisition Protocol.

[0134] The second user submits a data acquisition request and provides their user identity identifier and the identifier of the requested data. The blockchain performs layered parsing of the secondary identifier code to obtain the data storage identifiers for each sub-data segment of the requested data. Based on the storage identifiers, the sub-data is downloaded from the cloud and its integrity is verified using digital hashes. After successful verification, data aggregation is performed, and the requested food safety data results are returned to the second user. Figure 6 As shown, the specific steps are as follows:

[0135] (1) Data Request: Users submit data recovery requests through the data retrieval interface.

[0136]

[0137] In this embodiment of the application, a data recovery request can be submitted through a data acquisition interface. The request parameters include the function call identifier "DataAcquire" and the input parameter group dataOwnerCert, dataID, and acquireDataID. Among them, acquireDataID represents the data name that the first user has given to the shared food safety data, and the other meanings are the same as those in Table 1.

[0138] (2) The metadata management smart contract receives the parameter Transaction, identifies the request category "DataAcquire", and initiates an identifier resolution transaction;

[0139] (3) The metadata management smart contract triggers the identifier resolution instruction, obtains the long identifier according to the identifier resolution protocol (MPP), and queries the blockchain state database;

[0140] (4) The blockchain smart contract function parses the short identifier shortRecord corresponding to the long identifier completeRecord organized according to the identifier registration protocol (MRP) in the state database to obtain dataURLs, dataHashs and basic file information basicInfos = {dataType, dataSize, blockNum}.

[0141] (5) The blockchain transmits dataURLs and dataHashs to the cloud storage platform and retrieves the specified shared data according to dataInfos;

[0142] (6) After the cloud storage platform downloads and verifies the data, it organizes the shared data according to the basicInfos requirements and returns it to the user who applied for food safety data. It returns acquireDataID and data acquisition completion identifier acquireState=true, indicating that the food safety data acquisition is complete.

[0143] 4. Data deletion agreement.

[0144] The first user submits a data deletion request and provides their user identity and the identifier of the data to be deleted. The blockchain parses the secondary identifier hierarchically according to the encoding rules and executes the shared data deletion operation based on the shared metadata information obtained from the parsing. First, a multi-cloud data deletion operation is performed on the food safety data stored in the cloud pointed to by the parsed address, and then the blockchain secondary encoding identifier is deleted; as shown in Figure 7, the specific steps are as follows:

[0145] (1) Data sharing users submit data deletion requests through the data deletion interface:

[0146]

[0147] In this embodiment of the application, a data deletion request can be submitted through the data deletion interface. The request parameters include the function call identifier "DataDelete" and the input parameter groups dataID and dataOwnerCert.

[0148] (2) The metadata management smart contract receives the parameter Transaction, identifies the request category "DataDelete", and initiates an identifier parsing transaction;

[0149] (3) The metadata management smart contract triggers the identifier resolution instruction, obtains the long identifier according to the identifier resolution protocol (MPP), and queries the blockchain state database;

[0150] (4) The blockchain smart contract function parses the RecordCode in the state database according to the Marker Registration Protocol (MRP) to obtain the long and short secondary identifiers and get the data storage address dataURLs.

[0151] (5) The blockchain transmits dataURLs to the cloud storage platform to guide the deletion of specified food safety data;

[0152] (6) The multi-cloud storage platform deletes the corresponding data in the URL according to dataURLs until the corresponding data in dataURLs is completely deleted;

[0153] (7) After deletion, the multi-cloud storage platform sends a message to the blockchain smart contract that the data deletion is complete, rawDataDelState = true;

[0154] (8) After the blockchain smart contract receives rawDataDelState=true, it triggers the identifier registration instruction and performs the identifier registration work according to the identifier registration protocol (MRP);

[0155] (9) The blockchain identifier registration module clears completeRecord and shortRecord sequentially according to MRP until RecordCode is empty.

[0156] (10) The blockchain returns a data deletion completion identifier deleteState=true to the first user, indicating that the data deletion is complete.

[0157] The food safety big data sharing and management method based on the cloud-chain fusion mechanism proposed in this application involves distributed storage of food safety big data across multiple clouds. A storage allocation strategy is used to construct sparse and uniform storage of the segmented sub-data across multiple clouds. Complete subsets of shared food safety data are obtained only through data aggregation across multiple clouds. Furthermore, a unified encoding system is constructed between the distributed storage data and the blockchain, based on shared metadata, using an identifier encoding and parsing protocol. Clients provide user operations such as data storage, updating, querying, and retrieval for food safety data sources to multiple participants. This solves the problems of inefficient collaborative management and low security of shared data in related technologies, achieving efficient and reliable food safety big data sharing and management.

[0158] Secondly, with reference to the accompanying drawings, a food safety big data sharing management system based on the cloud-chain fusion mechanism proposed in the embodiments of this application is described.

[0159] Figure 8 This is a block diagram of a food safety big data sharing management system under the cloud-chain fusion mechanism in an embodiment of this application.

[0160] like Figure 8 As shown, the food safety big data sharing management system 10 under the cloud-chain integration mechanism includes: a first receiving module 100, a generating module 200, and a data management module 300.

[0161] The first receiving module 100 is used to receive the sharing application and food safety data to be shared, user identification, available storage cloud list and sharing policy provided by the first user.

[0162] The generation module 200 is used to generate a second-level code identifier for the first user based on the second-level code identifier generation rules, taking the food safety data to be shared, the user's identity identifier, the list of available storage clouds, and the sharing policy; and

[0163] The data management module 300 is used to store the food safety data to be shared on a multi-cloud storage terminal based on the first user's secondary code identifier, sharing policy and available storage cloud list, and to share the first user's food safety data according to the data acquisition request when it receives a data acquisition request from a second user.

[0164] Optionally, in some embodiments, before obtaining the food safety data of the first user requesting to share the data, the data management module 300 is further configured to:

[0165] Based on the secondary coding identifier generation rules, the data acquisition application is parsed to obtain the second user identity identifier and the data storage identifiers of each sub-data of the data to be acquired.

[0166] Based on the data storage identifiers of each sub-data of the data to be acquired, the data is downloaded from the multi-cloud storage terminal by addressing and downloading, and the sub-data of the data to be acquired is obtained.

[0167] The integrity of each sub-data of the data to be acquired is verified based on the digital hash. After the verification is successful, the data is aggregated to obtain the data to be acquired and then shared with the second user.

[0168] Optionally, in some embodiments, the food safety big data sharing management system 10 under the cloud-chain fusion mechanism described above further includes:

[0169] The second receiving module is used to receive the user identity identifier to be deleted and the food safety data to be deleted provided by the first user;

[0170] The acquisition module is used to parse the user identity identifier to be deleted and the food safety data to be deleted based on the secondary coding identifier generation rules, and obtain the cloud-shared data with address pointers;

[0171] The deletion module is used to delete the cloud-shared data with the address pointed to from the multi-cloud storage terminal, and at the same time delete the second-level code identifier of the first user.

[0172] Optionally, in some embodiments, the food safety big data sharing management system 10 under the cloud-chain fusion mechanism described above further includes:

[0173] The third receiving module is used to receive new food safety data and the first user's identity certificate provided by the first user.

[0174] The replacement module is used to replace food safety data with new food safety data based on the rules for generating secondary code identifiers.

[0175] Optionally, in some embodiments, the generation module 200 is further configured to:

[0176] Receive the identifier registration request sent by the first user;

[0177] Based on the secondary coding identifier generation rules and identifier registration requests, the food safety data to be shared, user identity identifiers, available storage cloud lists, and sharing policies are registered with identifiers.

[0178] Extract the user's identity identifier and the food safety data identifier to be shared from the registered data, construct a short identifier, construct a long identifier from the remaining data, and then send the short identifier to the first user.

[0179] It should be noted that the foregoing explanation of the embodiment of the food safety big data sharing management method under the cloud-chain fusion mechanism also applies to the food safety big data sharing management system under the cloud-chain fusion mechanism of this embodiment, and will not be repeated here.

[0180] The food safety big data sharing management system based on the cloud-chain fusion mechanism proposed in this application implements multi-cloud distributed storage of food safety big data. A storage allocation strategy is used to construct sparse and uniform storage of the segmented sub-data across multiple clouds. Complete subsets of shared food safety data are obtained only through multi-cloud data aggregation. Furthermore, a unified encoding system is constructed between the multi-cloud distributed storage data and the blockchain, based on shared metadata, using an identifier encoding and parsing protocol. Clients provide user operations such as data storage, updating, querying, and retrieval for food safety data sources to multiple participants. This solves the problems of inefficient collaborative management and low security of shared data in related technologies, achieving efficient and reliable food safety big data sharing management.

[0181] Figure 9 A schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include:

[0182] The memory 901, the processor 902, and the computer program stored on the memory 901 and capable of running on the processor 902.

[0183] When the processor 902 executes the program, it implements the food safety big data sharing and management method under the cloud-chain fusion mechanism provided in the above embodiments.

[0184] Furthermore, electronic devices also include:

[0185] Communication interface 903 is used for communication between memory 901 and processor 902.

[0186] The memory 901 is used to store computer programs that can run on the processor 902.

[0187] The memory 901 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0188] If the memory 901, processor 902, and communication interface 903 are implemented independently, then the communication interface 903, memory 901, and processor 902 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 9 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0189] Optionally, in a specific implementation, if the memory 901, processor 902, and communication interface 903 are integrated on a single chip, then the memory 901, processor 902, and communication interface 903 can communicate with each other through an internal interface.

[0190] The processor 902 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0191] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the food safety big data sharing and management method under the cloud-chain fusion mechanism described above.

[0192] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0193] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0194] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0195] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0196] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0197] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0198] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0199] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A method for sharing and managing food safety big data under a cloud-chain fusion mechanism, characterized in that, Includes the following steps: Receive the sharing request and food safety data to be shared, user identification, list of available storage clouds, and sharing policy provided by the first user; Based on the secondary coding identifier generation rules, the food safety data to be shared, user identity identifier, available storage cloud list and sharing strategy are used to generate the secondary coding identifier of the first user; as well as Based on the first user's secondary code identifier, the sharing strategy, and the list of available storage clouds, the food safety data to be shared is stored in a multi-cloud storage terminal, and when a data acquisition request from a second user is received, the food safety data of the first user is shared according to the data acquisition request. Food safety big data is distributed across multiple clouds, and a storage allocation strategy is used to construct sparse and uniform storage of the sub-data after data segmentation across multiple clouds. Before sharing the first user's food safety data according to the data acquisition application, the process further includes: parsing the data acquisition application based on the secondary coding identifier generation rule to obtain the second user's identity identifier and the data storage identifiers of each sub-data of the data to be acquired; downloading the data from the multi-cloud storage terminal according to the data storage identifiers of each sub-data of the data to be acquired to obtain each sub-data of the data to be acquired; verifying the data integrity of each sub-data of the data to be acquired according to the digital hash, and performing data aggregation after the verification is passed to obtain the data to be acquired, and sharing the data to be acquired with the second user; The step of generating a second-level coded identifier for the first user based on the second-level coded identifier generation rules includes: receiving an identifier registration request sent by the first user; registering identifiers for the food safety data to be shared, user identity identifier, available storage cloud list, and sharing policy based on the second-level coded identifier generation rules and the identifier registration request; extracting the user identity identifier and the food safety data identifier to be shared from the registered data, constructing a short identifier, constructing a long identifier from the remaining data, and sending the short identifier to the first user. The long identifier is a set of shared metadata describing food safety data, including: basic data attribute field, data sharing strategy field, data addressing information field, data verification information field, and extensible field. Together, they constitute the shared metadata. Among them, the basic data attribute field describes the size and type of food safety data files; the data sharing strategy field describes the data storage period and the amount of data redundancy; the data addressing information field describes the storage address information of each sub-data in multiple clouds; the data verification information field describes the numerical hash and storage version number information of each sub-data; and the extensible field contains other attribute information that users need to add, which can be empty.

2. The method according to claim 1, characterized in that, The aforementioned food safety big data sharing and management method under the cloud-chain integration mechanism also includes: Receive the user identity identifier to be deleted and the food safety data to be deleted provided by the first user; Based on the secondary coding identifier generation rules, the user identity identifier to be deleted and the food safety data to be deleted are parsed to obtain cloud-shared data with address pointers; While deleting the cloud-shared data with the address it points to from the multi-cloud storage terminal, the second-level code identifier of the first user is also deleted.

3. The method according to claim 1, characterized in that, The aforementioned food safety big data sharing and management method under the cloud-chain integration mechanism also includes: Receive new food safety data and the first user's identity certificate provided by the first user; Based on the aforementioned secondary coding identifier generation rules, the new food safety data replaces the existing food safety data.

4. A food safety big data sharing and management system based on a cloud-chain integration mechanism, characterized in that, include: The first receiving module is used to receive the sharing request and food safety data to be shared, user identification, available storage cloud list and sharing policy provided by the first user; The generation module is used to generate a second-level code identifier for the first user based on the second-level code identifier generation rules, the food safety data to be shared, the user identity identifier, the list of available storage clouds, and the sharing strategy. as well as The data management module is used to store the food safety data to be shared in a multi-cloud storage terminal based on the second-level code identifier of the first user, the sharing strategy, and the list of available storage clouds; and to share the food safety data of the first user according to the data acquisition request when a data acquisition request is received from the second user; to perform distributed storage of food safety big data across multiple clouds, and to construct sparse and uniform storage of the sub-data after data segmentation across multiple clouds through a storage allocation strategy; Before sharing the first user's food safety data according to the data acquisition application, the data management module is further configured to: parse the data acquisition application based on the secondary coding identifier generation rule to obtain the second user's identity identifier and the data storage identifiers of each sub-data of the data to be acquired; Based on the data storage identifiers of each sub-data of the data to be acquired, the data is downloaded from the multi-cloud storage terminal to obtain each sub-data of the data to be acquired. The integrity of each sub-data item of the data to be acquired is verified based on the numerical hash. After successful verification, data aggregation is performed to obtain the data to be acquired, and the data to be acquired is shared with the second user. The generation module is further configured to: receive an identifier registration request sent by the first user; register identifiers for the food safety data to be shared, the user identity identifier, the available storage cloud list, and the sharing policy based on the secondary encoding identifier generation rules and the identifier registration request; extract the user identity identifier and the food safety data identifier to be shared from the registered data, construct a short identifier, construct a long identifier from the remaining data, and send the short identifier to the first user. The long identifier is a set of shared metadata describing food safety data, including: basic data attribute field, data sharing strategy field, data addressing information field, data verification information field, and extensible field. Together, they constitute the shared metadata. Among them, the basic data attribute field describes the size and type of food safety data files; the data sharing strategy field describes the data storage period and the amount of data redundancy; the data addressing information field describes the storage address information of each sub-data in multiple clouds; the data verification information field describes the numerical hash and storage version number information of each sub-data; and the extensible field contains other attribute information that users need to add, which can be empty.

5. The system according to claim 4, characterized in that, The aforementioned food safety big data sharing and management system under the cloud-chain integration mechanism also includes: The second receiving module is used to receive the user identity identifier to be deleted and the food safety data to be deleted provided by the first user; The acquisition module is used to parse the user identity identifier to be deleted and the food safety data to be deleted based on the secondary coding identifier generation rules, and obtain cloud-shared data with address pointers; The deletion module is used to delete the cloud-shared data with the address pointing to it from the multi-cloud storage terminal, and at the same time delete the second-level code identifier of the first user.

6. The system according to claim 4, characterized in that, The aforementioned food safety big data sharing and management system under the cloud-chain integration mechanism includes: The third receiving module is used to receive new food safety data and the first user's identity certificate provided by the first user. The replacement module is used to replace the food safety data with the new food safety data based on the secondary coding identifier generation rules.

7. An electronic device, characterized in that, include: The system includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the food safety big data sharing and management method under the cloud-chain fusion mechanism as described in any one of claims 1-3.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the food safety big data sharing and management method under the cloud-chain fusion mechanism as described in any one of claims 1-3.

Images