Blockchain-based queue data sharing, evidence storage and auditing method and system

Abstract

The application discloses a kind of queue data sharing storage evidence auditing method and system based on blockchain, for queue data sharing storage evidence method and system, design storage evidence logic, clear description complex belonging relationship change in the whole process of queue data sharing, including the belonging relationship of agency and queue, agency and research project, research project and queue, research project and analysis, analysis and queue, etc., ensure the reliability of queue data sharing process, while reducing storage overhead including queue storage evidence, variable standardization storage evidence, research project storage evidence and analysis storage evidence;For queue data sharing auditing method and system, each data flow process in queue is audited efficiently, by establishing local link information database and research object persistence MPT, realize the credibility of audit result while protecting research object data privacy.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, specifically relating to a blockchain-based queue data sharing, evidence storage, and auditing method and system. Background Technology

[0002] Compared to traditional single-cohort studies, cross-cohort collaborative studies can more fully leverage the advantages of large cohorts, providing more precise evidence to support disease prevention and treatment. Cross-cohort collaborative studies need to address the issue of secure data sharing within the cohorts, ensuring the security of sensitive data. This is primarily reflected in making the data sharing process traceable and auditable.

[0003] Existing technical solutions rely on databases and their log files. Database vendors typically provide database auditing functions, which can audit all operations in the database, such as additions, modifications, and deletions. Auditors can trace these operations through audit logs. Database security auditing systems can provide real-time alerts and the ability to trace and analyze security incidents, helping auditors to promptly detect and handle database security events. Database firewalls can block malicious database operations and audit and record them. Log management tools can collect, store, and analyze database operation logs, facilitating operation auditing and the detection and response to security incidents. However, these database-dependent methods can only block and warn against high-risk data deletion and data export operations, or prevent potentially dangerous database operations by auditing database operations such as operation commands and return value sizes. In other words, they can only protect the security, integrity, and reliability of the queue's source data, but cannot audit the collaborative research process of the queue data in a granular manner.

[0004] The conventional approach uses databases to record operational information generated during collaborative research to serve as evidence for traceability and auditing. However, because the shared collaborative research process involves multiple layers, including institutions, operators, cohorts, variables, research projects, and analyses, this method results in numerous and complex data files, incurring significant audit overhead and making it difficult to quickly correlate and obtain audit information. Furthermore, database log files are at risk of being tampered with, compromising the authenticity of audit results.

[0005] Blockchain is a decentralized technology that can be applied to peer-to-peer (P2P) networks to track and manage the state of distributed systems. In a blockchain, each peer entity can see all transactions and state changes within the system, and a consensus algorithm ensures the correctness and legitimacy of each transaction. Once a transaction is written to the blockchain, it is permanently stored there, and other peer entities can also see the transaction's state. Therefore, blockchain ensures eventual consistency in processing, immutability of records, and the authenticity and reliability of data stored on the blockchain.

[0006] Blockchain stores transaction information and contract states. Transaction information includes the account addresses of both parties and the transaction content, while contract states are stored on blocks in the form of a state tree. Currently, blockchain primarily traces transaction operations through account addresses, which is suitable for auditing from the perspective of the account holder (operator) and is feasible for scenarios with simple transaction content. However, collaborative research processes involving queued data sharing require auditing from the perspective of the research object's data. Although the blockchain system stores operational information, the sheer volume of transaction data necessitates auditors to meticulously examine each transaction, requiring significant time and effort for analysis and resulting in poor interactivity.

[0007] Blockchain auditing benefits from its open and transparent nature, allowing for the traceability of all on-chain data. However, collaborative research involving queue data sharing requires the protection of sensitive data within the queue. Records of certain processes can provide opportunities for peer-to-peer analysis within the blockchain, posing a privacy risk. Furthermore, blockchain transactions are limited in size, while collaborative research involving queue data sharing involves massive amounts of data and increasingly numerous operations, making it difficult to accurately and comprehensively record the entire lifecycle of personal data, thus posing further challenges to auditing. Summary of the Invention

[0008] In view of the above, the purpose of this invention is to provide a blockchain-based queue data sharing and auditing method and system to solve the problems of low reliability and low auditing efficiency of traditional evidence storage, and to achieve fast auditing and protect sensitive queue data while ensuring auditing accuracy.

[0009] To achieve the above-mentioned objectives, embodiments of the present invention provide a blockchain-based queue data sharing and notarization method, including queue notarization, variable standardization notarization, research project notarization, and analysis notarization.

[0010] The queue notarization is performed when the queue administrator registers a new queue. After the queue administrator registers the queue on the cloud server, the basic information of the queue and the basic information of the queue variables are recorded in the queue list and queue variable table on the blockchain by calling the queue contract. The queue is associated with the organization to which the queue administrator belongs, and the queue is associated with the queue variables.

[0011] The variable standardization and notarization are performed when the queue administrator standardizes the queue variables. The queue administrator performs standardization processing on the local end. After standardization, the description of the variable and the changes and mappings of its value range are recorded in the queue variable table by calling the queue contract of the blockchain. The standardization of the variable processes the queue data and marks it as an important event to be pushed on the blockchain.

[0012] The research project notarization is carried out when researchers create new research projects and screen research subjects. After researchers create new research projects on the cloud server, the basic information of the research projects is recorded in the research project table on the blockchain by calling the research project contract on the blockchain. The research projects are associated with the institutions to which the researchers belong.

[0013] The analysis and evidence storage are performed when researchers create and update analyses. Researchers preprocess the data in the queues on the cloud server, mapping queue variables from multiple queues to an analysis variable. The information of the analysis variable is recorded in the analysis variable table on the blockchain by calling the blockchain's analysis contract.

[0014] Preferably, for the preservation of research project records, researchers screen research subjects according to the required cohort variables and enroll them in the research project, including the following steps:

[0015] (1) Researchers select queue variables, and the cloud server sends the filtering conditions of the queue variables to the local end;

[0016] (2) The local end receives the screening criteria and selects the cohort research subjects that need to be included in the group according to the screening criteria;

[0017] (3) The local end records the enrolled cohort research subjects in the local database. The recorded information includes a linked information table and a persistent MPT. The linked information table records the latest enrollment information of all cohort research subjects, and the persistent MPT records the historical enrollment information of all cohort research subjects. The linked information table updates the enrollment information of the cohort research subjects in the research project, and the MPT updates the enrollment information of all cohort research subjects in the current research project.

[0018] (4) The local end sends the updated root hash value in the MPT and the number of enrolled research objects in the queue to the cloud server.

[0019] (5) After receiving all the messages returned by the local end, the cloud server records the queues and queue variables used in the research project, as well as the relevant information of the research object, in the research project contract on the blockchain. The queues and queue variables used will be matched with the research project contract and the queue list and queue variable table. The process of screening and enrolling the research object processed the data and marked it as an important event on the chain.

[0020] Preferably, for analysis and evidence storage, researchers create new analyses, and the basic information of the analysis is recorded in the analysis table on the blockchain by calling the analysis contract on the blockchain. The analysis is associated with the research project and belongs to the current research project. Then, researchers select the analysis type, analysis variables, and analysis methods to perform analysis processing and obtain analysis results. This analysis process and analysis results are recorded in the analysis contract on the blockchain. The queue used for analysis calls the analysis contract to match the queue list. The analysis process processes the data in the queue and obtains the results, which are marked as important events on the chain and pushed.

[0021] Preferably, queue storage and variable standardization storage on the blockchain are signed by the queue administrator of the operation, and research project storage and analysis storage are signed by the researchers of the operation.

[0022] Preferably, after an important event marked on the chain is pushed, the cloud server receives and parses it, and stores it in a cloud database table.

[0023] To achieve the above-mentioned objectives, the embodiments also provide a blockchain-based queue data sharing and evidence storage system, including a cloud server and a local server. The cloud server includes blockchain services and cloud services provided by blockchain nodes, providing queue evidence storage services for queue administrators, research project evidence storage services and analysis evidence storage services for researchers. The blockchain services include a queue evidence storage module, a research project evidence storage module, and an analysis evidence storage module, and the cloud services include an important event storage module.

[0024] The queue notarization module is used to notarize queue registration information and queue variable information on the blockchain. Specifically, it is implemented through the application layer, logic layer and storage layer, including: the application layer is responsible for implementing the visual operation of the queue interface, including filling in and viewing queue registration information and queue variable information; the logic layer calls the queue contract; and the storage layer stores the queue contract, queue list and queue variable table on the blockchain.

[0025] The research project notarization module is used to notarize research project creation information and research object enrollment information on the blockchain. Specifically, it is implemented through the application layer, logic layer and storage layer, including: the application layer is responsible for implementing the visual operation of the research project interface, including filling in research project information to create a research project, viewing and modifying research project information; the logic layer calls the research project contract; and the storage layer stores the research project contract and research project table on the blockchain.

[0026] The analysis and evidence storage module is used to store information, analysis variable information, and analysis process results on the blockchain. Specifically, it is implemented through the application layer, logic layer, and storage layer. The application layer is responsible for implementing the visualization operation of the analysis interface, including filling in analysis information to create analysis and analysis variables, variable normalization, variable preprocessing, viewing and updating analysis; the logic layer calls the analysis contract; and the storage layer stores the analysis contract, analysis table, and analysis variable table on the blockchain.

[0027] The important event storage module is used to receive and update important events pushed by the blockchain on the cloud server side. Specifically, it is implemented through a logic layer and a storage layer, including: the logic layer receives events, parses different events, and stores them in the event table of the cloud database; the storage layer stores the event table of the cloud database.

[0028] Preferably, each local terminal includes blockchain services and local services provided by the blockchain node, providing the queue administrator with variable standardization and evidence storage services and research subject enrollment information storage services, wherein the blockchain service includes a variable standardization and evidence storage module, and the local service includes a research subject enrollment information storage module;

[0029] The variable standardization and notarization module is used to perform variable standardization and notarization on the blockchain. Specifically, it is implemented through the application layer, logic layer and storage layer, including: the application layer is responsible for the visual operation of the variable standardization interface, the logic layer calls the queue contract, and the storage layer stores the queue contract and queue variable table on the blockchain.

[0030] The research subject enrollment information storage module is used to maintain the enrollment information of the research subjects in the queue on the local end when the research project enrolls research subjects. Specifically, it is implemented through a logic layer and a storage layer, including: the logic layer receives the screening conditions from the cloud server, updates the enrolled research subjects and associated research project information to the link information table and persistent MPT on the local end, and returns the updated MPT root hash and the number of enrolled research subjects to the cloud server. The storage layer stores the link information table and persistent MPT.

[0031] To achieve the above-mentioned objectives, the embodiments also provide a blockchain-based queue data sharing auditing method. This sharing auditing method is based on the evidence storage results of the above-mentioned queue data sharing evidence storage method, including auditing of the joint research process of research object data and auditing of the reliability of linked data of research objects.

[0032] The joint research process audit of the research object data is conducted by the queue administrator when auditing the data flow of the research objects in the queue through the cloud server, and includes the following steps:

[0033] (1) The cloud server sends queue auditing requirements to the local server;

[0034] (2) The local end returns the research object ID in the queue to the cloud server according to the queue audit requirements;

[0035] (3) The queue administrator selects the specific research object ID based on the research objects returned by the local end, and the cloud server sends the specific research object ID to the local end;

[0036] (4) The local end returns the information of all research projects enrolled by the specific research subject ID to the cloud server based on the local link information table;

[0037] (5) The cloud server displays the audit results, the basic information of the queue where the specific research object ID is located, as well as the information and standardized information of the queue variables, the research project information of the specific research object ID, the basic information of the analysis that meets the conditions, and the analysis parameters, analysis variable information and analysis results of the analysis.

[0038] The reliability audit of the research object link data is used to ensure the reliability of the link information table, thereby guaranteeing the accuracy of the audit results of the joint research process. It is performed locally by the queue administrator and includes the following steps:

[0039] (1) The local end obtains the MPT root hash of the queue grouped into the research project on the blockchain based on the research project information;

[0040] (2) Query the enrollment status of research subjects based on the MPT root hash and the persistent MPT stored locally in the queue;

[0041] (3) Whether the inclusion of audit research subjects is consistent with the information in the linked information table.

[0042] To achieve the above-mentioned objectives, this invention also provides a blockchain-based queue data sharing audit system. The sharing audit system is implemented based on the aforementioned shared evidence storage system and includes a cloud server and a local server. The cloud server includes a blockchain node to provide queue administrators with auditing of the joint research process of research object data, including a sharing audit module. Each local server contains a blockchain node to provide queue administrators with auditing of the reliability of linked research object data, including a data reliability audit module.

[0043] The shared audit module is used to conduct a process-oriented audit of the joint research process for each research object's data, displaying details of important data flow events. Specifically, it is implemented through the application layer, logic layer, and storage layer, including: the application layer is responsible for implementing the visual operation of the audit interface, including selecting research objects, research projects, analysis, analysis processes, and specific events; the logic layer distributes audit requests to local terminals, and then filters, statistically analyzes, and displays the results based on the selected conditions; the storage layer stores queue contracts, research project contracts, analysis contracts, queue lists, queue variable tables, research project tables, analysis variable tables, analysis tables, and event tables in the cloud database on the blockchain.

[0044] The data reliability audit module is used to audit the reliability of the research object link information maintained locally, ensuring the accuracy of the audit results. Specifically, it is implemented through a logic layer and a storage layer, including: the logic layer obtains the MPT root hash stored on the blockchain and queries the persistent MPT stored locally, compares it with the information in the link information table, and performs an update operation; the storage layer stores the research object contracts on the blockchain as well as the local link information table and persistent MPT.

[0045] Compared with the prior art, the beneficial effects of the present invention include at least the following:

[0046] This invention provides a blockchain-based method and system for queue data sharing and notarization. The notarization logic clearly describes the complex ownership changes throughout the entire queue data sharing process, including the ownership relationships between institutions and queues, institutions and research projects, research projects and queues, research projects and analyses, and analyses and queues. This ensures the reliability of the queue data sharing process while reducing storage overhead. This invention also provides a blockchain-based method and system for auditing queue data sharing. It efficiently audits each data flow process in the queue by establishing a locally linked information database and a persistent MPT (Multi-Level Testing) for research subjects, thus protecting the data privacy of research subjects while ensuring the credibility of the audit results. Attached Figure Description

[0047] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 This is a flowchart of a blockchain-based queue data sharing and evidence storage method provided in the embodiment;

[0049] Figure 2 This is a flowchart of the blockchain-based research object inclusion and evidence storage process provided in the embodiment;

[0050] Figure 3 This is a schematic diagram of the persistent MPT evidence storage for the enrollment of research subjects provided in the embodiment;

[0051] Figure 4 This is a structural diagram of a blockchain-based queue data sharing and storage system provided in the embodiment.

[0052] Figure 5 This is an architecture diagram of a blockchain-based queue data sharing and evidence storage system provided in the embodiment.

[0053] Figure 6 This is another architecture diagram of the blockchain-based queue data sharing and evidence storage system provided in the embodiment;

[0054] Figure 7 This is a flowchart of the joint research process auditing of research object data based on blockchain, provided in the embodiment.

[0055] Figure 8 This is a flowchart of a blockchain-based research object link data reliability audit provided in the embodiment;

[0056] Figure 9 This is an architecture diagram of a blockchain-based queue data sharing auditing system provided in the embodiment;

[0057] Figure 10 This is another architecture diagram of the blockchain-based queue data sharing auditing system provided in the embodiment. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and do not limit the scope of protection of this invention.

[0059] To address the auditing needs of joint queue research, this invention provides a blockchain-based method and system for queue data sharing and notarization, and offers a queue data sharing auditing method and system based on the notarization results, specifically for queue research objects. The terminology specifically involved in the joint queue data sharing research process is described below:

[0060] Queue Administrator: The person in charge of managing the queue has direct access control over the queue and has the obligation to protect the queue's security.

[0061] Researchers: Individuals who use queues for collaborative research, including queue administrators, who require authorization from the queue administrator to access the queues, and who have analytical research needs;

[0062] Cloud server side: Computers or other devices that provide cloud services and provide the main queue data sharing services;

[0063] Local end: The computer or other device that stores the queues and provides the necessary local queue processing services.

[0064] Example 1

[0065] Joint research on queue data sharing first requires queue administrators to share queue information, such as... Figure 1 As shown, this process sharing evidence storage method includes queue evidence storage and variable standardization evidence storage. Researchers can conduct joint research on shared queue information. This process sharing evidence storage method includes research project evidence storage and analysis evidence storage. The following is a detailed explanation of each part of the evidence storage.

[0066] In Example 1, queue notarization is performed when the queue administrator registers a new queue. After the queue administrator registers the queue on the cloud server, the basic information of the queue and the basic information of the queue variables are recorded in the queue list and queue variable table on the blockchain by calling the queue contract. The queue is associated with the organization to which the queue administrator belongs, and the queue is associated with the queue variables.

[0067] Specifically, queue-based evidence storage includes the following steps:

[0068] Step a-1: The queue administrator fills in the queue name, the queue leading unit, the queue address, the main research purpose of the queue, and other basic information about the queue variables.

[0069] In step a-2, the cloud server calls the queue contract to store the basic information of the queue in the queue list. The queue list associates the queue with the queue leader unit through the organization field and stores the basic information of the queue variables in the queue variable table. The queue variable table associates the queue variables with the queue through the queue ID field. The transaction generated by the notarization is signed by the queue administrator's blockchain account.

[0070] In Example 1, variable standardization and notarization are performed when the queue administrator standardizes the queue variables. The queue administrator performs standardization processing on the local end. The description of the standardized variables and the changes and mappings of their value ranges are recorded in the queue variable table by calling the queue contract of the blockchain. The standardization of variables processes the queue data and marks it as an important event to be pushed on the blockchain.

[0071] Specifically, variable standardization and notarization involves the following steps:

[0072] Step b-1: The queue administrator standardizes the variables according to a certain standard and performs value range processing and mapping on the queue data;

[0073] Step b-2: The local end calls the queue contract to store the standardized results of the queue variables in the queue variable table. This is done by adding fields to the original queue variables to associate them with the queue variables, including the standard description of the variables, the processing of the variable value range and mapping rules, etc. This process generates contract events as important events and pushes them. The transactions generated by the storage are signed by the queue administrator's blockchain account.

[0074] In Example 1, the research project notarization is performed when researchers create new research projects and select research subjects. After researchers create new research projects on the cloud server, the basic information of the research projects is recorded in the research project table on the blockchain by calling the research project contract on the blockchain. The research projects are associated with the institutions to which the researchers belong.

[0075] Specifically, the research project documentation process includes the following steps:

[0076] Step c-1: Researchers fill in basic information about the research project, such as the project name, purpose, and background.

[0077] Step c-2: The cloud server calls the research project contract to store the basic information of the research project in the research project table. The research project table associates the research project with the institution to which the researcher belongs through the institution field. The transaction generated by the notarization is signed by the researcher's blockchain account.

[0078] Step c-3: Researchers screen research subjects according to the required cohort variables and enroll them into the research project;

[0079] Step c-4: The cloud server calls the research project contract to store the research object enrollment information, such as queues, queue variables, and research object information, in the research project contract. This process matches the queue list and queue variable table with the stored queue and queue variable information to ensure the authenticity of the queues and queue variables, and generates contract events as important events and pushes them. The transactions generated by the storage are signed by the researchers' blockchain accounts.

[0080] To protect sensitive data in the research project documentation, step c-3 requires processing of the research subject information, such as... Figure 2 As shown, the specific steps include:

[0081] Step c-3-1: Researchers select cohort variables and list the selection criteria for research subjects;

[0082] Step c-3-2: The cloud server sends the variable filtering conditions to the local end of each variable.

[0083] Step c-3-3: The local end receives the screening criteria and selects research subjects that meet the criteria.

[0084] Step c-3-4: Generate a link information table and store the enrollment information of the persistent study subjects MPT on the local end;

[0085] To protect the privacy of research participants while ensuring the authenticity of enrollment, the local end does not directly return information such as the IDs of the selected research participants. Instead, it generates a persistent MPT (Multi-Party Data Sheet) containing the root hash and the number of enrolled research participants, and saves it accordingly. The persistent MPT structure is as follows: Figure 3 As shown, the persistent MPT does not record information about research projects, but only records the inclusion status of research subjects, storing the research subject ID and inclusion / non-inclusion key-value pairs for all research subjects in the queue. If a research subject in the queue was included in a previous research project but not in the current research project, or if the current research project changes its inclusion criteria, causing this research subject to be deleted from the current research project, then the persistent MPT will update the record of the current research subject's inclusion status, changing it from "yes" to "no," and obtaining a new root hash. To meet auditing requirements, a linked information table is generated locally in the queue, containing fields such as research subject ID, research project ID, and inclusion time, associating research subjects with the research projects they were previously included in.

[0086] Step c-3-5: The local end sends the updated MPT root hash and the number of enrolled study subjects to the cloud server.

[0087] Step c-3-6: The cloud server receives all messages returned by the local end.

[0088] In Example 1, the analysis and evidence storage are performed when researchers create and update the analysis. Researchers preprocess the data in the queue on the cloud server and map the queue variables of multiple queues to an analysis variable. The information of the analysis variable is recorded in the analysis variable table on the blockchain by calling the analysis contract of the blockchain.

[0089] Specifically, the analysis of evidence includes the following steps:

[0090] In step d-1, the researchers normalized the queue variables of multiple queues into a single analysis variable and handled anomalies and missing values.

[0091] Step d-2: The cloud server calls the analysis contract to store the basic information of the analysis variables in the analysis variable table. The analysis variable table associates the analysis variables with the research projects through the research project ID field. The research project table is called to match the stored research projects to ensure the authenticity of the research projects. The transaction generated by the storage is signed by the researcher's blockchain account.

[0092] Step d-3: Researchers fill in basic information about the analysis, such as the analysis name, and select the analysis type, analysis variables, analysis methods, and other parameters to perform analysis and obtain the analysis results.

[0093] Step d-4: The cloud server calls the analysis contract to store basic analysis information in the analysis table. The analysis table associates the analysis with the research project through the research project ID field. The analysis process results are stored in the analysis contract. The queue list, analysis table, and analysis variable table are matched with the stored relevant information to ensure the authenticity of the queue, analysis, and analysis variables. Contract events are generated and pushed. The transactions generated by the notarization are signed by the researcher's blockchain account.

[0094] like Figure 4 As shown, the record of the above-mentioned joint research process on the blockchain can be briefly divided into two parts. One part stores the basic object information of the process, including queues, queue variables, research projects, analyses, and analysis variables, separately through table contracts. The other part stores the relevant logic involved in the sharing process, including queue registration, creation of queue variables, creation of research projects, inclusion of research objects, creation of analysis variables, and creation of analyses, through logic contracts, including queue contracts, research project contracts, and analysis contracts. At the same time, it maintains the association information with the table, which can describe the entire process of queue data sharing, link the evidence of multiple operations together, and reduce the redundancy of evidence storage.

[0095] Example 2

[0096] Example 2 provides a blockchain-based queue data sharing and evidence storage system. The queue data sharing and evidence storage method provided in Example 1 is implemented based on this system, such as... Figure 5 As shown, the system includes a cloud server and multiple local terminals, with the cloud server and local terminals communicating to complete system service functions. The cloud server includes blockchain services and cloud services provided by blockchain nodes, offering queue notarization services to queue administrators, research project notarization services to researchers, and analysis notarization services. Specifically, the blockchain services include queue notarization modules, research project notarization modules, and analysis notarization modules; the cloud services include an important event storage module. Each local terminal includes blockchain services and local services provided by blockchain nodes, offering variable standardization notarization services and research subject enrollment information storage services to queue administrators. The blockchain services include a variable standardization notarization module, and the local services include a research subject enrollment information storage module.

[0097] like Figure 6 As shown, the blockchain-based queue data sharing and evidence storage system implements the functions of each module through the application layer, logic layer, and storage layer. The following section provides a detailed explanation of the system's functions in conjunction with the application layer, logic layer, and storage layer, and according to each module.

[0098] In Example 2, the queue notarization module on the cloud server is mainly used by queue administrators to notarize queue registration information and queue variable information on the blockchain. At the application layer, the queue notarization module provides queue administrators with visual services for queue registration and queue variable registration, including filling in and viewing queue information. After the queue administrator completes the basic information of the queue (name, leading unit, address, main research purpose, etc.) and clicks confirm, the queue notarization module calls the queue contract at the logic layer, storing the basic queue information and queue variable information in the queue list and queue variable table on the blockchain at the storage layer. It also maintains a copy of the association information between the queue and queue variables in the queue contract for querying variables within the queue.

[0099] In Example 2, the research project notarization module on the cloud server is mainly used by researchers to notarize research project creation information and research project enrollment information on the blockchain. The research project module provides researchers with visual services for creating research projects and enrolling research subjects at the application layer, including filling in research project information, viewing and modifying research project information, and filtering variables and enrolling subjects. After researchers complete the basic information of the research project, such as the project name, purpose, and background, and click confirm, the research project notarization module calls the research project contract at the logic layer, storing the basic research project information in the research project table on the blockchain at the storage layer. After researchers complete the screening and enrollment of research subjects, the research project notarization module calls the research project contract at the logic layer, recording the research subject enrollment information, such as queues, queue variables, and research subject information, in the research project contract.

[0100] In Example 2, the cloud server-side analysis and evidence storage module is mainly used by queue administrators to store analysis creation information, analysis variable information, and analysis process results on the blockchain. At the application layer, the analysis and evidence storage module provides researchers with a visual service for creating analysis variables and analyses, including filling in analysis information, variable normalization, variable preprocessing, and viewing and updating the analysis. After researchers normalize the analysis variables, the analysis and evidence storage module calls the analysis contract at the logic layer, storing the analysis variable information in an analysis table on the blockchain in the storage layer. It also maintains a link between the research project and the analysis variables in the analysis contract for querying analysis variables within the research project. After researchers complete the basic analysis information, such as the analysis name, and select the analysis type, analysis variables, analysis methods, and other parameters for analysis processing, the analysis and evidence storage module calls the analysis contract at the logic layer, storing the basic analysis information in an analysis table on the blockchain in the storage layer. The analysis process results are recorded in the analysis contract, which also maintains a link between the research project and the analysis for querying analysis within the research project.

[0101] In Example 2, the critical event storage module on the cloud server side is mainly used to receive and update critical events pushed from the blockchain on the cloud server side. The critical event storage module receives events pushed by contracts invoked by other modules at the logic layer, parses them using the corresponding contract's interface for different events, and then stores them in the cloud database event table in the storage layer. Since an unparsed copy of the event is also stored on the blockchain, the critical event storage module can verify and update the events in the cloud database event table based on the events on the blockchain, ensuring the reliability of the data in the database event table.

[0102] In Example 2, the local variable standardization and notarization module is mainly used by queue administrators to perform variable standardization and notarization on the blockchain. At the application layer, this module provides queue administrators with visual services for variable standardization, such as standard variable selection and mapping rule addition. After the queue administrator standardizes the variables according to a certain standard, the module calls the queue contract at the logic layer and stores the standardized results in the queue variable table on the blockchain at the storage layer, corresponding to the queue variables.

[0103] In Example 2, the local research subject enrollment information storage module is mainly used to maintain the research subject enrollment information locally in the queue when research projects enroll research subjects. The module receives the filtering conditions from the cloud server at the logic layer, updates the information of the enrolled research subjects and associated research projects to the local linked information table and persistent MPT in the storage layer, and returns the updated MPT root hash and the number of enrolled research subjects to the cloud server.

[0104] Example 3

[0105] Example 3 provides a blockchain-based queue data sharing auditing method. This sharing auditing method is based on the queue data sharing notarization method and system notarization results provided in Examples 1 and 2. It is used by queue administrators to audit the joint research of queue research object data, including auditing the joint research process of research object data and auditing the reliability of linked data of research objects.

[0106] like Figure 7 As shown, the joint research process audit of research object data is conducted by the queue administrator when auditing the data flow of research objects in the queue through the cloud server, and includes the following steps:

[0107] Step e-1: The cloud server sends the queue audit request to the local endpoints. After the queue administrator starts the audit, the cloud server sends the audit service request to all local endpoints that the queue administrator has permission to access.

[0108] Step e-2: The local terminal returns the research object IDs in the queue to the cloud server. The local terminal with queue administrator privileges receives the audit request, determines that the permissions meet the audit requirements, and then returns the research object IDs in the queue.

[0109] In step e-3, the queue administrator selects the specific research object to be audited based on the research objects returned in step e-2, and the cloud server sends the specific research object ID to the local end. The queue administrator can view all research object IDs, filter research objects by filtering queues and other conditions, and select the specific research object to be audited. The cloud server then sends the specific research object ID to the local end of its respective queue.

[0110] Step e-4: The local end returns all research project information for the research subject's enrollment to the cloud server. After receiving the specific research subject ID, the local end filters and returns the research project ID for that research subject's enrollment and the corresponding enrollment and exit times based on the local connection information table.

[0111] Step e-5: The cloud server processes and displays the audit results. The cloud server retrieves and displays the basic information of the cohort to which the research subject belongs, as well as the information on cohort variables and standardized information, from the blockchain. Based on the research project details, the cloud server retrieves and displays the research project information for which the research subject was enrolled from the blockchain. The cloud server filters events in the cloud database table and retrieves and displays the basic information of analyses that meet the criteria based on the event hash from the blockchain. For each analysis, the cloud server retrieves and displays the analysis parameters, analysis variable information, and analysis results from the blockchain.

[0112] While push events stored in the blockchain can be used for filtering, auditing requires receiving and traversing all events, then parsing different events and filtering them based on their content. This process is very costly. Therefore, using a cloud database event table to record the necessary event hashes and filtering information, and then retrieving the corresponding event details from the blockchain, can improve auditing efficiency.

[0113] The accuracy of the joint research process for queue research object data audited by the queue administrator depends on the reliability of the link information stored locally. Therefore, the queue administrator needs to audit the reliability of the research object link data.

[0114] like Figure 8 As shown, the reliability audit of research object link data is used to ensure the reliability of the link information table, thereby guaranteeing the accuracy of the audit results of the joint research process. It is performed locally by the queue administrator and includes the following steps:

[0115] Step f-1: The local end retrieves the MPT root hash of the research project to which the queue belongs from the blockchain based on the research project information. After the queue administrator begins auditing, the local end iterates through all research projects and retrieves all MPT root hashes of the queue under that research project.

[0116] Step f-2: Query the enrollment status of research objects based on the MPT root hash and the persistent MPT stored locally in the queue. An MPT root hash records the current enrollment status of the queue. The persistent MPT uses the MPT root hash to trace back to the current status and perform fast queries. By traversing all MPT root hashes, the complete enrollment status of all research objects can be queried.

[0117] Step f-3: Audit whether the enrollment information of the research subjects is consistent with the linked information table. After obtaining the enrollment information of all research subjects, determine whether the information currently stored in the linked information table is correct. If an error is found, update the linked information table.

[0118] Although the persistent MPT root hash of the research object stored in the blockchain and the persistent MPT on the local end can reliably audit the joint research process of the research object, the audit requires traversing all the entry events of all research projects and parsing the MPT to query the entry status of the research object. The audit overhead is very large. Therefore, the linked information table is used to perform fast audit and reliability audit to improve the audit efficiency.

[0119] Example 4

[0120] Example 4 provides a blockchain-based queue data sharing auditing system. This sharing auditing system is implemented based on the shared evidence storage method and system provided in Examples 1 and 2, such as... Figure 9 As shown, it includes a cloud server and multiple local terminals, and the cloud server and local terminals communicate to complete system service functions. The cloud server includes a blockchain node to provide queue administrators with auditing of the joint research process of research object data, including a shared audit module. Each local terminal includes a blockchain node to provide queue administrators with auditing of the reliability of linked research object data, including a data reliability audit module.

[0121] like Figure 10 As shown, the blockchain-based queue data sharing auditing system implements the functions of each module through the application layer, logic layer, and storage layer. The following section provides a detailed explanation of the system's functions in conjunction with the application layer, logic layer, and storage layer, and according to each module.

[0122] In Example 4, the shared audit module on the cloud server is mainly used for process-oriented auditing of the joint research process for each research object's data, displaying details of important data flow events. At the application layer, the shared audit module provides queue administrators with visualization services for selecting audit content, displaying shared processes, and showing event details. These services include selecting research objects, research projects, analyses, analysis processes, specific events, process displays, and event details displays. After the queue administrator enters the audit page, the shared audit module distributes the audit request to the local terminal at the logic layer and displays all research objects in queues that the queue administrator has permission to access after receiving the return value. The queue administrator filters and clicks on the research objects to be audited. At the logic layer, the shared audit module calls various contracts and event filtering functions to obtain and display the basic information of the queue, the basic information of the queue variables, and the standardized information of the research object in the queue list and queue variable table on the storage layer blockchain. The default audit criteria are the first research project in which the research subject was enrolled, and all analytical events using that research subject in the first analysis under that research project. The shared audit module retrieves basic research project and analysis information from the research project table and analysis table on the storage layer blockchain, as well as event information from the event table in the cloud, to display the workflow. It also retrieves the event details of the first analytical event on the blockchain based on the event hash, and displays the event details, including analysis parameters, analysis variables, and analysis results, in conjunction with the analysis contract and analysis variable table on the blockchain. After viewing the workflow and events, the queue administrator can change the audit criteria, select other research projects to retrieve analyses under those projects, click on an analysis to access the entire analysis workflow, and click on an event within the workflow to access the details of that event.

[0123] In Example 4, the local data reliability audit module is mainly used to audit the reliability of the research object link information maintained locally, ensuring the accuracy of the audit results. The queue administrator can select research objects to audit their link information. The data reliability audit module calls the entry status audit function at the logic layer, traverses and obtains the MPT root hash of all research projects in the research project contract on the blockchain in the storage layer for the queue entry, and then traverses and queries the persistent MPT stored locally in the storage layer to obtain the entry status of the research object. After comparing it with the information in the locally stored link information table, the audit result is returned, and the link information table can be updated.

[0124] The specific embodiments described above illustrate the technical solution and beneficial effects of the present invention in detail. It should be understood that the above description is only the most preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, additions, and equivalent substitutions made within the scope of the principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A blockchain-based queue data sharing and evidence storage method, characterized in that, This includes cohort-based evidence storage, variable standardization evidence storage, research project evidence storage, and analysis evidence storage; The queue notarization is performed when the queue administrator registers a new queue. After the queue administrator registers the queue on the cloud server, the basic information of the queue and the basic information of the queue variables are recorded in the queue list and queue variable table on the blockchain by calling the queue contract. The queue is associated with the organization to which the queue administrator belongs, and the queue is associated with the queue variables. The variable standardization and notarization are performed when the queue administrator standardizes the queue variables. The queue administrator performs standardization processing on the local end. After standardization, the description of the variable and the changes and mappings of its value range are recorded in the queue variable table by calling the queue contract of the blockchain. The standardization of the variable processes the queue data and marks it as an important event to be pushed on the blockchain. The research project notarization is carried out when researchers create new research projects and screen research subjects. After researchers create new research projects on the cloud server, the basic information of the research projects is recorded in the research project table on the blockchain by calling the research project contract on the blockchain. The research projects are associated with the institutions to which the researchers belong. The analysis and evidence storage are performed when researchers create and update analyses. Researchers preprocess the data in the queues on the cloud server, mapping queue variables from multiple queues to a single analysis variable. The information of the analysis variable is recorded in the analysis variable table on the blockchain by calling the blockchain's analysis contract. For research project evidence storage, researchers select research subjects based on the required queue variables and include them in the research project, including the following steps: (1) Researchers select queue variables, and the cloud server sends the filtering conditions of the queue variables to the local end; (2) The local end receives the screening criteria and selects the cohort of research subjects that need to be included in the group according to the screening criteria; (3) The local end records the enrolled cohort research subjects in the local database. The recorded information includes a link information table and a persistent MPT. The link information table records the latest enrollment information of all cohort research subjects, and the persistent MPT records the historical enrollment information of all cohort research subjects. The link information table updates the enrollment information of the cohort research subjects in the research project, and the MPT updates the enrollment information of all cohort research subjects in the current research project. (4) The local end sends the updated root hash value in the MPT and the number of enrolled research objects in the queue to the cloud server. (5) After receiving all the messages returned by the local end, the cloud server records the queues and queue variables used in the research project and the relevant information of the research object in the research project contract on the blockchain; the queues and queue variables used will call the research project contract to match the queue list and queue variable table; the process of the research object screening and grouping process processes the data and marks it as an important event push on the chain.

2. The blockchain-based queue data sharing and evidence storage method according to claim 1, characterized in that, For analysis and evidence preservation, researchers create new analyses. The basic information of the analysis is recorded in the analysis table on the blockchain by calling the analysis contract. The analysis is associated with the research project and belongs to the current research project. Then, researchers select the analysis type, analysis variables, and analysis methods to process the data and obtain the analysis results. This analysis process and results are recorded in the analysis contract on the blockchain. The queue used for the analysis calls the analysis contract to match the queue list. The analysis process processes the data in the queue and obtains the results, which are marked as important events and pushed on the chain.

3. The blockchain-based queue data sharing and evidence storage method according to claim 1 or 2, characterized in that, On the blockchain, queue-based and variable standardization notarization are signed by the queue administrator of the operation, while research project notarization and analysis notarization are signed by the researchers of the operation.

4. The blockchain-based queue data sharing and evidence storage method according to claim 1 or 2, characterized in that, After important events marked on the blockchain are pushed, the cloud server receives and parses them, and saves them in the cloud database table.

5. A blockchain-based queue data sharing and evidence storage system, characterized in that, It includes a cloud server and a local terminal. The cloud server includes blockchain services and cloud services provided by blockchain nodes, providing queue storage services for queue administrators, research project storage services and analysis storage services for researchers. The blockchain services include queue storage modules, research project storage modules and analysis storage modules, and the cloud services include important event storage modules. The queue notarization module is used to notarize queue registration information and queue variable information on the blockchain. Specifically, it is implemented through the application layer, logic layer and storage layer, including: the application layer is responsible for implementing the visual operation of the queue interface, including filling in and viewing queue registration information and queue variable information; the logic layer calls the queue contract; and the storage layer stores the queue contract, queue list and queue variable table on the blockchain. The research project notarization module is used to notarize research project creation information and research object enrollment information on the blockchain. Specifically, it is implemented through the application layer, logic layer and storage layer, including: the application layer is responsible for implementing the visual operation of the research project interface, including filling in research project information to create a research project, viewing and modifying research project information; the logic layer calls the research project contract; and the storage layer stores the research project contract and research project table on the blockchain. Research project documentation involves researchers screening research subjects based on required cohort variables and enrolling them in the research project, including the following steps: (1) Researchers select queue variables, and the cloud server sends the filtering conditions of the queue variables to the local end; (2) The local end receives the screening criteria and selects the cohort of research subjects that need to be included in the group according to the screening criteria; (3) The local end records the enrolled cohort research subjects in the local database. The recorded information includes a link information table and a persistent MPT. The link information table records the latest enrollment information of all cohort research subjects, and the persistent MPT records the historical enrollment information of all cohort research subjects. The link information table updates the enrollment information of the cohort research subjects in the research project, and the MPT updates the enrollment information of all cohort research subjects in the current research project. (4) The local end sends the updated root hash value in the MPT and the number of enrolled research objects in the queue to the cloud server. (5) After receiving all the messages returned by the local end, the cloud server records the queues and queue variables used in the research project and the relevant information of the research object in the research project contract on the blockchain; the queues and queue variables used will call the research project contract to match the queue list and queue variable table; the process of the research object screening and group entry process processes the data and is marked as an important event push on the chain; The analysis and evidence storage module is used to store information, analysis variable information, and analysis process results on the blockchain. Specifically, it is implemented through the application layer, logic layer, and storage layer. The application layer is responsible for implementing the visualization operation of the analysis interface, including filling in analysis information to create analysis and analysis variables, variable normalization, variable preprocessing, viewing and updating analysis; the logic layer calls the analysis contract; and the storage layer stores the analysis contract, analysis table, and analysis variable table on the blockchain. The important event storage module is used to receive and update important events pushed by the blockchain on the cloud server side. Specifically, it is implemented through a logic layer and a storage layer, including: the logic layer receives events, parses different events, and stores them in the event table of the cloud database; the storage layer stores the event table of the cloud database.

6. The blockchain-based queue data sharing and evidence storage system according to claim 5, characterized in that, Each local terminal includes blockchain services and local services provided by the blockchain node, providing the queue administrator with variable standardization and evidence storage services and research subject enrollment information storage services. The blockchain service includes a variable standardization and evidence storage module, and the local service includes a research subject enrollment information storage module. The variable standardization and notarization module is used to perform variable standardization and notarization on the blockchain. Specifically, it is implemented through the application layer, logic layer and storage layer, including: the application layer is responsible for the visual operation of the variable standardization interface, the logic layer calls the queue contract, and the storage layer stores the queue contract and queue variable table on the blockchain. The research object enrollment information storage module is used to maintain the enrollment information of the research object queue on the local end when the research project enrolls the research object queue. Specifically, it is implemented through a logic layer and a storage layer, including: the logic layer receives the screening conditions from the cloud server, updates the enrolled research object queue and the associated research project information to the link information table and persistent MPT on the local end, and returns the updated MPT root hash and the number of enrolled research objects to the cloud server. The storage layer stores the link information table and persistent MPT. Among them, the persistent MPT does not record information about the research project, but only records the enrollment status of the research subjects, storing the research subject ID and enrollment key-value pairs of all research subjects in the queue. The link information table contains fields such as study subject ID, study project ID, and enrollment time, which associates study subjects with the study projects they have previously enrolled in.

7. A blockchain-based queue data sharing auditing method, characterized in that, The shared auditing method is based on the evidence storage results of the queue data sharing evidence storage method according to any one of claims 1-4, including joint research process audit of research object data and reliability audit of linked data of research objects; The joint research process audit of the research object data is conducted by the queue administrator when auditing the data flow of the research objects in the queue through the cloud server, and includes the following steps: (1) The cloud server sends queue auditing requirements to the local server; (2) The local end returns the research object ID in the queue to the cloud server according to the queue audit requirements; (3) The queue administrator selects the specific research object ID based on the research objects returned by the local end, and the cloud server sends the specific research object ID to the local end; (4) The local end returns the information of all research projects enrolled by the specific research subject ID to the cloud server based on the local link information table; (5) The cloud server displays the audit results, the cloud server displays the basic information of the queue where the specific research object ID is located, as well as the information and standardized information of the queue variables, the cloud server displays the research project information of the specific research object ID, the cloud server displays the basic information of the analysis that meets the conditions, and the cloud server displays the analysis parameters, analysis variable information and analysis results of the analysis. The reliability audit of the research object link data is used to ensure the reliability of the link information table, thereby guaranteeing the accuracy of the audit results of the joint research process. It is performed locally by the queue administrator and includes the following steps: (1) The local end obtains the MPT root hash of the queue grouped into the research project on the blockchain based on the research project information; (2) Query the enrollment status of research subjects based on the MPT root hash and the persistent MPT stored locally in the queue; (3) Whether the inclusion of audit research subjects is consistent with the information in the linked information table.

8. A blockchain-based queue data sharing auditing system, characterized in that, The shared audit system is implemented based on the shared evidence storage system of claim 5 or 6, including a cloud server and a local terminal. The cloud server includes a blockchain node to provide queue administrators with audit of the joint research process of research object data, including a shared audit module. Each local terminal contains a blockchain node to provide queue administrators with audit of the reliability of research object linked data, including a data reliability audit module. The shared audit module is used to conduct a process-oriented audit of the joint research process for each research object's data, displaying details of important data flow events. Specifically, it is implemented through the application layer, logic layer, and storage layer, including: the application layer is responsible for implementing the visual operation of the audit interface, including selecting research objects, research projects, analysis, analysis processes, and specific events; the logic layer distributes audit requests to local terminals, and then filters, statistically analyzes, and displays the results based on the selected conditions; the storage layer stores queue contracts, research project contracts, analysis contracts, queue lists, queue variable tables, research project tables, analysis variable tables, analysis tables, and event tables in the cloud database on the blockchain. The data reliability audit module is used to audit the reliability of the research object link information maintained locally, ensuring the accuracy of the audit results. Specifically, it is implemented through a logic layer and a storage layer, including: the logic layer obtains the MPT root hash stored on the blockchain and queries the persistent MPT stored locally, compares it with the information in the link information table, and performs an update operation; the storage layer stores the research object contracts on the blockchain as well as the local link information table and persistent MPT.

Images