Storage system based on hybrid multi-permission blockchain and ipfs pathological data

Abstract

The embodiment of the application provides a kind of based on mixed multi-privilege block chain and IPFS pathological data's storage system, belong to pathological data storage technical field.The storage system includes off-chain storage layer, the off-chain storage layer includes distributed file system, and the distributed file system is used to store large capacity digital pathological section;Storage chain layer, the storage chain layer includes block chain, and the block chain is used to store structured pathological information;The mode of cooperation storage of the distributed file system in the off-chain storage layer and the block chain in the storage chain layer can meet the characteristics of the multi-source heterogeneous nature of pathological data, reduce the storage pressure, using the mode of block chain storage, can be decentralized, effectively avoid the problem that centralized storage is vulnerable to single-point attack, improve the privacy protection and efficient use of data.

Description

Technical Field

[0001] This invention relates to the field of pathological data storage technology, and more specifically to a storage system for pathological data based on hybrid multi-permission blockchain and IPFS. Background Technology

[0002] Digital pathology refers to the application of computers and networks in the field of pathology. It is a technology that organically combines modern digital systems with traditional optical magnification devices. It involves acquiring high-resolution digital images through scanning with a fully automated microscope or optical magnification system, and then using a computer to automatically perform high-precision, multi-field seamless stitching and processing of the images to obtain high-quality visual data for application in various areas of pathology.

[0003] In recent years, the rapid development of technologies such as cloud computing, big data, and artificial intelligence has had a significant impact on the medical field, driving the advancement of medical informatization. Pathology, as a crucial research discipline in medicine, plays a primary role in the pathological examination and diagnosis of patients during their visits. Its main processes include biopsy, preparation of biopsy sections, staining and freezing of sections, and immunohistochemistry. This complex series of procedures generates corresponding pathological data, which pathologists use to provide diagnostic results. Pathological data is a vital component of medical data, encompassing not only text-based pathology reports but also laboratory and imaging data, exhibiting greater heterogeneity compared to other purely text-based medical data.

[0004] Due to uneven resource allocation among medical institutions and the high cost of cross-regional medical treatment, some medical institutions are addressing these issues through remote diagnosis. Remote diagnosis organically combines medicine with advanced computer and communication technologies, enabling lower-level hospitals to request remote assisted diagnosis from higher-level or even same-level hospitals. This not only solves the problem of uneven distribution of pathological resources between different levels of hospitals but also reduces the cost of repeated examinations during cross-regional medical treatment. Simultaneously, remote diagnostic data can be quickly provided to patients, and typical cases can be shared for direct online learning, contributing to the training of medical professionals and scientific research, truly realizing the goal of technology bringing benefits to the healthcare industry.

[0005] Currently, most pathological data is stored centrally and accessed via cloud servers. Cloud-based pathological data storage and sharing relies on a central server; if this central server is attacked or malicious, data leaks can occur, posing significant security risks.

[0006] In the process of realizing this invention, the inventors of this application discovered that the above-mentioned solutions in the prior art have significant security risks, such as data leakage. Summary of the Invention

[0007] The purpose of this invention is to provide a storage system for pathological data based on a hybrid multi-authority blockchain and IPFS, which can effectively reduce the risk of security vulnerabilities such as data leakage.

[0008] To achieve the above objectives, embodiments of the present invention provide a storage system for pathological data based on a hybrid multi-permission blockchain and IPFS, comprising:

[0009] An off-chain storage layer, which includes a distributed file system for storing large-capacity digital pathological slides;

[0010] A storage chain layer, the storage chain layer including a blockchain, the blockchain being used to store structured pathological information;

[0011] The shared chain layer includes multiple access levels, which are used to obtain pathological data in the storage chain layer according to different user levels and share the data. The off-chain storage layer, the storage chain layer, and the shared chain layer are interconnected through smart contracts.

[0012] Through the above technical solutions, the storage system for pathological data based on hybrid multi-permission blockchain and IPFS provided by this invention can meet the characteristics of multi-source heterogeneity of pathological data by using a distributed file system in the off-chain storage layer and a blockchain in the storage chain layer to store data, thereby reducing storage pressure. The blockchain storage method can decentralize and effectively avoid the problem that centralized storage is vulnerable to single point of attack, thereby improving data privacy protection and efficient use.

[0013] Other features and advantages of the embodiments of the present invention will be described in detail in the following detailed description section. Attached Figure Description

[0014] The accompanying drawings are provided to further illustrate embodiments of the present invention and form part of the specification. They are used together with the following detailed description to explain the embodiments of the present invention, but do not constitute a limitation thereof. In the drawings:

[0015] Figure 1 This is a schematic diagram of the structure of a storage system for pathological data based on a hybrid multi-permission blockchain and IPFS according to an embodiment of the present invention;

[0016] Figure 2 This is a schematic diagram of the system model architecture of a storage system for pathological data based on a hybrid multi-permission blockchain and IPFS, according to an embodiment of the present invention.

[0017] Figure 3 This is a schematic diagram of the interaction process in a storage system for pathological data based on a hybrid multi-permission blockchain and IPFS, according to an embodiment of the present invention.

[0018] Figure 4 This is an access flowchart of a pathological data storage system based on a hybrid multi-permission blockchain and IPFS according to an embodiment of the present invention;

[0019] Figure 5 This is a flowchart of a shared process in a storage system for pathological data based on a hybrid multi-permission blockchain and IPFS, according to an embodiment of the present invention.

[0020] Figure 6 This is a flowchart of pathological data encryption and decryption in a pathological data storage system based on hybrid multi-permission blockchain and IPFS, according to an embodiment of the present invention;

[0021] Figure 7 This is a flowchart illustrating the calculation of secondary ciphertext for requesters and owners in a storage system for pathological data based on a hybrid multi-permission blockchain and IPFS, according to an embodiment of the present invention.

[0022] Figure 8 This is a flowchart illustrating an equivalence test between a requester and an owner in a storage system for pathological data based on a hybrid multi-permission blockchain and IPFS, according to an embodiment of the present invention.

[0023] Figure 9 This is a flowchart illustrating the process of a requester decrypting the owner's pathological data in a storage system based on a hybrid multi-permission blockchain and IPFS pathological data, according to an embodiment of the present invention.

[0024] Figure 10 This is a flowchart illustrating the decryption of pathological data by the owner in a pathological data storage system based on a hybrid multi-permission blockchain and IPFS according to an embodiment of the present invention.

[0025] Figure 11 This is a schematic diagram of network initialization during chaincode testing of a storage system for pathological data based on a hybrid multi-permission blockchain and IPFS, according to an embodiment of the present invention.

[0026] Figure 12 This is a schematic diagram of smart contract testing in chaincode testing of a storage system for pathological data based on a hybrid multi-permission blockchain and IPFS, according to an embodiment of the present invention.

[0027] Figure 13This is a schematic diagram comparing the query operation sending rate and throughput in a storage system for pathological data based on a hybrid multi-permission blockchain and IPFS, according to an embodiment of the present invention.

[0028] Figure 14 This is a schematic diagram comparing the latency of various query operations in a storage system based on hybrid multi-permission blockchain and IPFS pathological data according to an embodiment of the present invention.

[0029] Figure 15 This is a schematic diagram comparing the transmission rate and throughput of transfer operations in a storage system for pathological data based on a hybrid multi-permission blockchain and IPFS, according to an embodiment of the present invention.

[0030] Figure 16 This is a schematic diagram comparing the latency of various transfer parameters in a storage system based on hybrid multi-permission blockchain and IPFS pathological data according to an embodiment of the present invention.

[0031] Explanation of reference numerals in the attached figures

[0032] 01. Shared Chain Layer 02. Storage Chain Layer

[0033] 03. Off-chain storage layer Detailed Implementation

[0034] The specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit the scope of the present invention.

[0035] Figure 1 This is a schematic diagram of the structure of a storage system for pathological data based on a hybrid multi-authority blockchain and IPFS, according to an embodiment of the present invention. Figure 1 The storage system may include an off-chain storage layer 03, a storage chain layer 02, and a shared chain layer 01. Specifically, the off-chain storage layer 03 may include a distributed file system, the storage chain layer 02 may include a blockchain, and the shared chain layer 01 may include multiple access levels.

[0036] A distributed file system is used to store large-capacity digital pathology slides, while a blockchain is used to store structured pathology information. Shared chain layer 01 is used to access and share pathology data from storage chain layer 02 based on different user levels. Off-chain storage layer 03, storage chain layer 02, and shared chain layer 01 are interconnected via smart contracts. Specifically, shared chain layer 01 and storage chain layer 02 can be referred to as a multi-level blockchain.

[0037] The off-chain storage layer 03 primarily stores large-capacity digital pathology slides through the distributed file system IPFS. When a slide is stored on IPFS, its address is returned. This slice address (sliceAddress) is inserted into the structured pathology information, allowing users to access IPFS and retrieve digital pathology slides via the slice address. Specifically, this method alleviates the pressure on the blockchain caused by large-capacity slide files. The storage chain layer 02 mainly stores structured pathology information, such as patient name, gender, and ID number. Specifically, this storage chain layer 02 stores pathology data in the blockchain through smart contracts, recording each data operation as a transaction. These transaction records are immutable, and historical data is traceable. The shared chain layer 01, based on the data requester's keywords, transfers matching pathology data from the storage chain layer 02 to the shared chain layer 01 for data sharing. Specifically, the shared chain layer 01 can include multiple access levels, corresponding to multiple access permissions, to restrict access functions for different requesters.

[0038] Traditional pathological data often employs centralized storage, accessing relevant pathological data via cloud servers. However, this approach poses significant security risks, as the central server is vulnerable to attack or malicious activity, leading to data leakage. This embodiment of the invention utilizes a distributed file system (IPFS) combined with blockchain for storage, adapting to the heterogeneous nature of multi-source case data and reducing storage pressure on the system. Furthermore, employing multiple decentralized blockchain storage methods effectively avoids the vulnerability of centralized storage to single points of attack, enhancing data privacy protection and efficient data utilization.

[0039] In this embodiment of the invention, the pathological data contains keywords such as patient privacy, which need to be distinguished during encryption or re-encryption to prevent the sharing of private data. Specifically, the invention standardizes the pathological data fields, as shown in Table 1.

[0040] Table 1

[0041]

[0042] Specifically, information involving patient privacy is set as privacy fields in Table 1. The structure can be designed on the Hyperledger Fabric platform based on standardized pathology data. The pathology ID is the primary key, uniquely representing a single instance of pathology data for that patient. HistoryItem represents the current patient's historical records. Blockchain's traceability feature allows for tracing historical records via transaction numbers.

[0043] In this embodiment of the invention, such as Figure 1 As shown, the number of access levels for shared chain layer 01 can include level 1 users, level 2 users, and level 3 users. Specifically, level 1 users have the highest access level, level 2 users have the next highest access level, and level 3 users have the lowest access level.

[0044] Level 1 users are typically super administrators. These users belong to one organization within a consortium blockchain (multiple organizations, each with its own member nodes, forming a consortium). They possess the highest privileges, allowing them to access and read all data (including users' private data) and control the allocation of operational permissions to other roles (defining other users in the system into different levels, excluding Level 1 users). To prevent malicious nodes, Level 1 users must reach a consensus within their organization before performing write operations. Similarly, in scenarios such as electing Level 1 users, consensus must still be reached through voting within the organization to complete the corresponding operations.

[0045] Level 2 users are typically members of collaborating organizations (such as various medical institutions and research institutions within the network). These users belong to the same organization and have Level 2 access permissions, allowing them to access anonymized data and have the right to use and share that data. However, sharing is limited to within the organization and cannot be shared with others outside the organization. With the approval of Level 1 users, data can be downloaded to their local machines.

[0046] Level 3 users are typically registered and authenticated individuals belonging to the same organization and possessing Level 3 access permissions. If this user is the patient themselves, they can access their own pathology data after verifying their identity. Accessing other users' information requires authorization from the patient or approval from a higher-level user consensus before sharing the corresponding anonymized information. However, these users cannot download other people's information to their local devices.

[0047] In this embodiment of the invention, a corresponding system model architecture was designed for a storage system / model based on hybrid multi-permission blockchain and IPFS pathological data, taking into account the business scenario of pathology. For example... Figure 2 As shown, the system model is divided into a data resource layer, a data storage layer, a data access layer, and a data application layer, which respectively demonstrate the entire lifecycle of acquisition, storage, access, and application.

[0048] Data Resource Layer: Primarily used to generate pathological data. This includes data from medical records, imaging data, data generated by diagnostic equipment, and data obtained by pathologists through clinical diagnosis. The pathological data in this layer is not limited to a single medical institution; within the consortium blockchain, different medical institutions belong to different consortium organizations, and the pathological data in the data resource layer contains data from all these organizations. Because different institutions use different data standards, standardization is required before storage. Standardization includes tasks such as integrating text fields and extracting imaging data.

[0049] Data Storage Layer: This layer corresponds to the core solution in this chapter, based on a three-layer pathological data storage model using a hybrid multi-permission blockchain and IPFS. This layer stores standardized pathological data in a hierarchical manner: structured pathological text is stored on the blockchain, while large-capacity digital pathological slides are stored in IPFS, with the index serving as a field in the structured pathological text. Through the integration of blockchain and IPFS technologies, distributed data storage is achieved, improving data storage efficiency.

[0050] Data Access Layer: This layer first authenticates the user's identity. Unregistered users register and are authenticated through Fabric-CA. Fabric-CA classifies users based on their identity, granting different permissions to different users. The first step of this layer is user management, assigning different levels of permissions to different types of users (where grade1 > grade2 > grade3), specifically corresponding to the content described in the user permission classification section. After user authentication, the second step of this layer is access control. Different users have different access policies, using a policy set: Policy = {grade1, grade2, grade3} (where grade1 > grade2 > grade3). After access control verification, the corresponding smart contracts can be invoked to access data in the data storage layer according to the access policy restrictions. Different access policies have limited scope for smart contract invocation; read and write permissions are controlled by the access policy.

[0051] Data Application Layer: This layer primarily showcases the application value of pathological data within the entire system model. Depending on the scenario, pathological data can be applied to numerous aspects such as clinical diagnosis, remote consultation, and scientific research services. Furthermore, in addition to basic smart contracts, more detailed business-specific smart contracts can be written to serve the data application layer based on its specific needs.

[0052] Specifically, the interaction process between users of different levels and the three-tier storage model for pathological data, which combines multi-permission blockchain and IPFS, during the registration, authentication, storage, and access steps can be described as follows: Figure 3 As shown.

[0053] In this embodiment of the invention, Hyperledger Fabric, a consortium blockchain, is selected as the experimental platform to realize distributed storage of structured pathology data and related data state operations. Since consortium blockchains only allow members of specific groups and a limited number of third parties to participate, they are very suitable for multi-institutional scenarios in pathology practice. The specific experimental environment configuration is shown in Table 2 below.

[0054] Table 2 Experimental Environment Configuration

[0055]

[0056] In this embodiment of the invention, the experiment is divided into two parts. The first part mainly describes the process of setting up the consortium blockchain environment and starting the network. The second part mainly describes calling smart contracts to perform various state operations on pathological data on the blockchain, realizing its distributed storage and querying. Specifically:

[0057] Part 1: Underlying Design and Environment Setup

[0058] Step 1: After installing Docker, Docker-Compose, and other prerequisite software, pull the Hyperledger Fabric image. Execute the script files in Fabric-Samples to generate certificates and keys for the nodes in the organization, and generate the files required for service startup and channel configuration. These certificate and key pairs will take effect when the container runs. This experiment uses two organizations and six nodes to fulfill the requirements of the solution.

[0059] Step 2: Instantiate Fabric-SDK. Fabric provides different SDKs. In this experiment, we use FabricSDK-Go. After configuring the corresponding parameters, create a channel and add nodes to the channel. Connect the Peer node and Orderer node together to achieve data isolation inside and outside the channel.

[0060] Step 3: Next, install and instantiate the chaincode for the relevant pathological data operations. After instantiation, create a channel client, then begin installing the chaincode. Once installation is successful, instantiate the chaincode. After instantiation, create the channel client, and use the client to call the chaincode to query or execute transactions.

[0061] Part Two: Chaincode Testing

[0062] After completing the network setup, the chaincode was tested. In the test instance, two pathology datasets were initialized, and operations such as querying, updating, and deleting were performed on them. This can be achieved as follows: Figure 11 As shown,

[0063] Figure 11 Each transaction in the blockchain corresponds to a specific event and transaction number, ensuring traceability and immutability. The results show that the smart contract tested correctly and successfully completed operations such as storing, querying, updating, and deleting pathological data. Figure 12 As shown.

[0064] In this embodiment of the invention, Hyperledger Caliper was used to test the platform's performance. Multiple rounds of testing were conducted with transaction volumes of 100, 250, 500, 750, and 1000, removing the maximum and minimum values ​​and taking the average of 30 results for each item. The test items mainly included transaction throughput and latency, etc. The test results are as follows: Figure 13 As shown Figure 16 shown. Specifically, Figure 14 and Figure 16 The three interlocking pillars represent the maximum delay, minimum delay, and average delay, respectively.

[0065] according to Figure 13 It can be seen that although the sending rate and throughput of query operations corresponding to different transaction volumes show a fluctuating trend, the amplitude is very small, basically remaining at around 100 TPS. This indicates that within a certain range, the time for querying transactions is stable, and the platform has good stability. Figure 14 As can be seen, the latency of query operations gradually increases with the increase in transaction volume, but it remains within 0.05 seconds, which is negligible in actual operation. Therefore, within a certain range of query volume, the latency caused by queries will not affect the overall operation of the platform. Figure 15 The transmission speed and throughput of the data transfer operation were demonstrated. As the transaction volume increased from 100 to 1000, the transmission rate and throughput remained relatively stable at around 40-50 TPS. Figure 16 The transmission operation latency was shown, with the maximum latency remaining between 0.2s and 0.3s, the minimum latency all below 0.05s, and the average latency between 0.1s and 0.15s. This indicates that the platform performance is relatively stable and meets the usage requirements of certain scenarios.

[0066] In this embodiment of the invention, in the above experiment, pathological data is stored in a blockchain, inaccessible to users performing blockchain and tissue authentication. Data summaries are stored on-chain using hash operations and Merkle trees. This on-chain / off-chain storage structure improves blockchain performance while preventing pathological data from being directly published on the network. Each block on the blockchain stores the hash value of the previous block and is linked in a chain. This characteristic makes every transaction on the blockchain transparent, traceable, and tamper-proof, because if any part is modified, the hash values ​​on all blocks will change. The above experiment uses the Byzantine Fault Tolerance (PBFT) algorithm as the consensus mechanism in the underlying blockchain. Unlike the PoW algorithm, it does not require a large amount of computing power to avoid "51% attacks." In the PBFT algorithm, as long as the number of malicious nodes in the system is not greater than that of normal nodes, the data will not be tampered with. Since each node in the blockchain environment stores a backup of the pathological data, even if a single node fails, it will not affect the overall operation of the blockchain network. Secondly, every transaction on the blockchain is completed through the underlying consensus mechanism, so even if there are malicious nodes, they cannot disrupt the stability of the network or complete malicious transactions.

[0067] In this embodiment of the invention, the most fundamental characteristic of the three-layer pathological data storage model based on hybrid multi-authority blockchain and IPFS is its distributed nature. Unlike traditional distributed storage that directly uses blockchain, this model combines blockchain with IPFS technology. On-chain storage of structured pathological data and transaction records is achieved, while off-chain storage utilizes a distributed file system to store large volumes of digital pathological slides. This significantly reduces the storage pressure on blocks while maintaining a distributed approach. While achieving multi-level distributed storage, the three-layer pathological data storage model based on hybrid multi-authority blockchain and IPFS considers storage and sharing as two separate businesses on two chains. Therefore, a storage chain and a sharing chain are designed. The storage chain stores complete structured pathological data. The sharing chain extracts shared data that meets specific requirements based on conditions and shares it with different users. It also updates the data within the sharing chain over a period of time, improving the efficiency and flexibility of sharing. Considering user permissions, the three-layer pathological data storage model based on hybrid multi-authority blockchain and IPFS designs different levels for the sharing chain for different users, achieving fine-grained access control over pathological data. Furthermore, sensitive information and operations require consensus within the organization to be implemented, effectively controlling user permissions and protecting data privacy.

[0068] In this embodiment of the invention, the storage model / system of the present invention utilizes the distributed characteristics of blockchain and IPFS to achieve the goal of secure storage of pathological data. Simultaneously, the blockchain's underlying consensus mechanism ensures transaction security, and smart contracts ensure the stable execution of data state operations. Pathological data is not entirely stored on the chain; instead, structured text and transaction records are stored on the blockchain, while large-capacity digital pathological slides are stored on IPFS, and addresses are stored on the blockchain. Transactions generate block header hashes through hash functions. Hash functions are one-way and collision-resistant; once a transaction is tampered with, a different hash value is obtained, and the chain structure leads to a chain reaction. The characteristics of the blockchain ensure the integrity of pathological data and the immutability of transactions. Users are divided into three levels based on their user status, with different access control permissions designed to ensure that the highest-level user can access complete pathological data, but their operations are also subject to the consensus of other users of the same level within the organization. Second-level users cannot access sensitive data, and the lowest-level user has access to the data but cannot obtain it. This effectively controls permissions while protecting the privacy of patient data.

[0069] In this embodiment of the invention, regarding block security, assuming an attacker attempts to launch a spoofing attack on the data in a block, the characteristics of the blockchain require its block generation speed to be greater than the block generation speed of the nodes elected by the consensus mechanism. The probability of a successful attack can be approximated as a gambler's bankruptcy problem. Assuming the probability of the node elected by the consensus mechanism calculating the next block is r, the probability of the attacker calculating the next block is ω, and the number of blocks the attacker needs to create to complete the spoofing attack is n, then the probability of the attacker's successful attack is ω. n It can be as shown in formula (18),

[0070]

[0071] According to formula (18), as the number of transactions increases and blocks are continuously generated, the value of n will become larger and larger, and the probability of an attacker successfully attacking will increase. n It exhibits an exponential downward trend. Furthermore, the Hyperledger Fabric network contains a large number of nodes, some of which have extremely high computing power, making the probability of an attacker succeeding essentially zero, thus preventing any attack on the blocks.

[0072] In this embodiment of the invention, when a requester needs to access the pathological data of the data owner, it is necessary to determine their access level and user level. Specifically, the determination process can be as follows: Figure 4 As shown. Specifically, in Figure 4 In this context, the access process to the storage system may include:

[0073] In step S10, the requester's access request is obtained, which includes the access level and access operation. The requester can initiate an access request through API shared chain 01.

[0074] In step S11, the user level of the requester is obtained.

[0075] In step S12, it is determined whether the user's level is lower than the access level. The access level is also known as the access permission.

[0076] In step S13, if the user's level is determined to be lower than the access level, the access request is deemed to have failed. Here, "lower than" refers to the level of access privileges; for example, level 3 is lower than level 2, and level 2 is lower than level 1, not level 1 lower than level 2, or level 2 lower than level 3.

[0077] In step S14, if the user level is determined to be equal to or higher than the access level, it is determined whether the access operation is a read operation.

[0078] In step S15, if the access operation is determined to be a read operation, the data to be queried is sent to the requester.

[0079] In step S16, if the access operation is determined not to be a read operation, it is then determined whether the access operation is a valid operation. If the access operation is not a read operation, it is a write operation, and a consensus mechanism is needed to decide whether to approve the operation, i.e., to determine whether the access operation is a valid operation.

[0080] In step S17, if the access operation is determined to be a valid operation, the access operation is executed.

[0081] In step S18, if the access operation is determined to be invalid, the access request is deemed to have failed.

[0082] In steps S10 to S18, for each requester's access request, it is necessary to first determine whether the requester's user level is lower than the access level; if so, the access fails. If the requester's user level is higher than or equal to the access level, it is further determined whether the access operation is a read operation. If the access operation is a read operation, it is directly sent to the requester; if the access operation is a write operation, its legality must also be determined. This method can perform operations with corresponding permissions based on the user's level, thereby protecting data security and enabling effective hierarchical management.

[0083] In this embodiment of the invention, smart contracts serve as the core of blockchain business control implementation. The invention discloses four types of smart contracts. Specifically, the four types of smart contracts may include a pathology data storage contract, a pathology data query contract, a pathology data update contract, and a pathology data deletion contract. Specifically, Hyperledger Fabric provides corresponding APIs for operations on ledger data status. Various operations on the ledger status, such as querying and modifying read / write operations, can be implemented by calling these interfaces.

[0084] In this embodiment of the invention, Hyperledger provides a corresponding API for pathological data storage contracts: the PutState method. This operation stores the corresponding value in the distributed ledger based on a specified key. Based on this API, the present invention designs a smart contract PutPlg to realize the storage of pathological data. The specific contract content is as follows.

[0085] PutPlg

[0086]

[0087]

[0088] In this embodiment of the invention, Hyperledger provides a corresponding API for pathology data query contracts: the GetState method. This operation can retrieve the corresponding data state based on a specified key. Based on this API, the present invention designs a smart contract GetPlgInfo, which queries the corresponding pathology data using the primary key pathology ID. The specific contract content is shown below.

[0089] GetPlgInfo

[0090]

[0091]

[0092] In this embodiment of the invention, for pathology data update contracts, Hyperledger does not have a direct API for updating data. However, the update operation can be completed by first querying and retrieving the data, modifying the corresponding fields, and then saving it. This invention designs a contract `UpdatePlg`, which first queries the corresponding data using the case ID. After a successful query, the corresponding fields can be modified, and the data can be saved to complete the pathology data update. The contract then returns a success or failure message. The specific contract content is shown below.

[0093] UpdatePlg

[0094]

[0095] In this embodiment of the invention, Hyperledger provides a corresponding API for the pathology data deletion contract: the DelState method. This operation deletes the value in the ledger based on the input key. Based on this API, the invention designs a smart contract DelPlg, which deletes the corresponding pathology data using the primary key case ID. The specific contract content is shown below.

[0096] DelPlg

[0097]

[0098] In this embodiment of the invention, different access strategies are applied to different types of customers. Therefore, corresponding access strategies are designed to ensure that different users have different permissions, thereby achieving secure access to pathological data. The scheme includes a tuple User_Tuple and two access algorithms, Read and Write.

[0099] The User_Tuple contains two fields: ID and Grade. ID uniquely identifies the user, Grade represents the user level, and Policy represents the access policy (as shown in the user tuple structure design below). Read and Write correspond to read and write operations, respectively, and different users have different permissions for read and write.

[0100] User tuple structure design

[0101]

[0102] A grade set `Grade = {grade1, grade2, grade3}` is used to assign different grades to different user types (where `grade1` > `grade2` > `grade3`). Different access policies are then applied to each grade, with the specific policies corresponding to the `Read` table.

[0103] Read

[0104]

[0105]

[0106] The main idea of ​​the Read algorithm is to match corresponding operations based on the user's level. Level 1 and Level 2 users do not need any further judgment and can directly obtain the pathology data with the corresponding permissions. Level 3 users first need to determine whether the user is the patient by checking whether the caseId matches the id. The patient can directly obtain the data, while non-patients can obtain anonymized data if authorized.

[0107] The main idea of ​​the Write algorithm is to determine whether a write operation is allowed based on the user's level and the consensus result. A write operation can only be completed if the user belongs to a first-level user organization and a consensus has been reached within that organization. Specifically, the Write algorithm corresponds to the Write table.

[0108] Write

[0109]

[0110] In this embodiment of the invention, the storage system may further include an encryption / decryption module, which is used to perform encryption and decryption steps during pathology data retrieval / sharing. Specifically, the encryption / decryption steps may be as follows: Figure 5 As shown. Specifically, in Figure 5 In this process, this step may include:

[0111] In step S20, pathological data from various medical institutions are acquired.

[0112] In step S21, the pathological data is encrypted using the user's public key to form ciphertext and uploaded to the off-chain storage layer 03 or the storage chain layer 02.

[0113] In step S22, the requester's sharing request is obtained.

[0114] In step S23, it is determined whether a sharing request has been obtained.

[0115] In step S24, if a sharing request is obtained, secure sharing is performed based on the sharing request and the owner's pathological data.

[0116] In steps SS20 to S24, the pathology data of each medical institution is encrypted and stored as ciphertext in off-chain storage layer 03 or storage chain layer 02. Simultaneously, a sharing request from the system is obtained, and secure sharing is achieved by combining the content of the sharing request with the ciphertext of the owner's pathology data. This sharing method is secure, reliable, and simple to operate.

[0117] In this embodiment of the invention, to further improve the security and reliability of the shared data between the requester and the owner, it is necessary to encrypt and decrypt the pathological data transmission between the requester and the owner. Specifically, the encryption and decryption process can be as follows: Figure 6 As shown. Specifically, in Figure 6 In this context, the method may include:

[0118] In step S240, common parameters are obtained. The generation of common parameters may include: first selecting two bilinear pairing groups (G, G') of prime order q. T ), where (G,G T (e.g., G×G→G)T Five secure hash functions are selected: H1, H2, H3, H4, and H5. A group element g ∈ G is also selected. The plaintext m-space is assumed to be... To obtain the common parameters, that is, to output the global common parameters (q, G, G). T ,g,H1,H2,H3,H4,H5,l,l1).

[0119] In step S241, public-private key pairs are generated for the requester and owner respectively based on the public parameters. A random number is selected. The algorithm generates public-private key pairs for authenticated users i and j. as well as

[0120] In step S242, the secondary ciphertext of the requester and owner is obtained based on the requester's public key, the owner's public key, and public parameters. The specific calculation steps for the secondary ciphertext may include, for example... Figure 7 The steps shown are as follows:

[0121] In step S2420, partial ciphertexts of the requester's and owner's secondary ciphertexts are calculated according to formula (1) respectively.

[0122]

[0123] Among them, C A,1 This is the first part of the ciphertext, PK. A Let A = {i,j}, where A is the public key of the requester or owner, i is the owner, and A is the requester when A is i. H1 is a hash function, and... Let {0,1} be a finite field of integers modulo q (excluding 0). l Let m be a bit string of length l, and m be the plaintext. l and l1 are the lengths, C A,2 The second part of the ciphertext, H2, is a hash function, and H2:G T →{0,1} l C A,3 The third part of the ciphertext, H3, is a hash function, and H3: G×{0,1} * →G,{0,1} * Let w be a bit string of arbitrary length, and C be a conditional parameter for re-encryption. A,4 The fourth part is the ciphertext, where H4 is the hash function, and H4: G×{0,1} l ×G→G,C A,5 The fifth part is the ciphertext, H5 is the hash function, and H5:G T →G,(G,G TLet G be a pairwise bilinear pairing group of two prime numbers q, satisfying e: G×G→G T Let g be a group element of a bilinear pairwise group, θ be the encryption parameter, and θ∈G, C A,6 This is the sixth part of the ciphertext, C A,7 This is the seventh level-one ciphertext, where r, r1, r2, and r3 are random numbers, and r = H1(m, r1), Let l be a bit string of length l-l1, and || be the string concatenation operation. For XOR operation, e is the bilinear pairing operation.

[0124] In step S2421, the secondary ciphertexts for the requester and the owner are calculated according to formula (2) respectively.

[0125] C A =(C A,1 C A,2 C A,3 C A,4 C A,5 C A,6 C A,7 (2)

[0126] Among them, C A This is the second-level encrypted text for the requester or owner. Specifically, the requester's second-level encrypted text may include the keywords they searched for, while the owner's second-level encrypted text is the pathological data related to those keywords.

[0127] In step S243, the authorization trapdoors of the requester and owner are obtained based on the secondary ciphertext of the requester and owner. Specifically, the owner's authorization trapdoor... Authorization trap for the requester

[0128] In step S244, an equivalence test is performed based on the authorization trapdoors of the requester and the owner. The equivalence test step for the ciphertexts of the requester and the owner may include, for example... Figure 8 The steps shown are as follows:

[0129] In step S2440, the test parameters for the requester and the owner are obtained according to formula (3).

[0130]

[0131] Among them, V A For test parameters of the requester or owner, td A This is an authorization trap for the requester or owner, and x A It is a random number, and

[0132] In step S2441, an equivalence test is performed based on the test parameters of the requester and the owner. Specifically, it is necessary to determine whether the equation shown in formula (7) holds true.

[0133] e(C i,5 V j )=e(C j,5 V i (7)

[0134] If equation (7) above holds true, the algorithm returns 1; otherwise, it returns ⊥, where V i V is the test parameter for the owner. j The test parameters are for the requester. Specifically, the ciphertext equivalence test between the requester and the owner is to determine whether they contain the same message.

[0135] In step S245, it is determined whether the equality test is successful. This means determining whether equation (6) is true.

[0136] In step S246, if the equivalence test is successful, the re-encryption key is obtained. The method for obtaining the re-encryption key may include calculating it according to formula (4).

[0137]

[0138] Where rk is the re-encryption key, rk1 is the first encryption parameter, rk2 is the second encryption parameter, and pk is the third encryption parameter. j Let be the requester's public key, and s be a re-encrypted random number.

[0139] In step S247, the owner's secondary ciphertext is re-encrypted using the re-encryption key to form primary ciphertext, which is then sent to the requester. The step of re-encrypting the owner's secondary ciphertext to form primary ciphertext may include: given the re-encryption key and the owner's secondary ciphertext, determining whether the equation in formula (8) holds true.

[0140]

[0141] If equation (8) does not hold, return to ⊥; if equation (8) holds, calculate the partial ciphertext of the first-level ciphertext according to formula (9).

[0142]

[0143] Where C′1 is a portion of the first-level ciphertext. Finally, the first-level ciphertext C is output. i→j =(C′1,C i,2 ).

[0144] In step S248, the primary ciphertext is decrypted using the requester's private key to obtain the owner's pathological data. The decryption of the primary ciphertext involves two parts: one is the requester's decryption, where the requester uses their private key sk. j Decrypting the first-level ciphertext that has been re-encrypted; one method is decryption by the owner, who uses their private key sk. i For its own secondary ciphertext C i The decryption process, specifically the decryption steps, may include: Figure 9 and Figure 10 The steps shown are as follows:

[0145] In step S2480, the first-level ciphertext is decrypted according to formula (5).

[0146]

[0147] Among them, C′1 and C i,2 Level 1 ciphertext C i→j The parameters in the file. Specifically, here is the requester's private key sk. j Decrypt the re-encrypted first-level ciphertext.

[0148] In step S2481, the first judgment formula is obtained according to formula (6).

[0149]

[0150] In step S2482, it is determined whether the equation of the first judgment formula is true.

[0151] In step S2483, if the equation of the first judgment formula is true, the owner's pathological data is output. Specifically, if the equation of formula (6) is true, it indicates that the data transmission was not tampered with, authentication was successful, and the plaintext m in formula (5) can be output. Here, plaintext m is the owner's pathological data. Otherwise, if the equation is not true, the process returns ⊥.

[0152] In step S2484, the owner's secondary ciphertext is decrypted according to formula (10).

[0153]

[0154] Specifically, here the owner uses their own private key sk. i For its own secondary ciphertext C i Decryption.

[0155] In step S2485, the second judgment formula is obtained according to formula (11).

[0156]

[0157] In step S2486, it is determined whether the equation of the second formula is true.

[0158] In step S2487, if the equation of the second formula is true, the owner's pathological data is output. If the second formula is true, it indicates that the data transmission was not tampered with, the owner's identity verification was successful, and the owner can decrypt their secondary ciphertext using their private key to obtain their plaintext m, which is the owner's pathological data. Otherwise, if the equation is false, return ⊥.

[0159] In steps S240 to S248, global public parameters are first obtained, and public-private key pairs (public key and private key) are generated for the requester and owner respectively based on these parameters. Then, the plaintext of the requester and the plaintext of the owner are encrypted using their respective public keys to obtain secondary ciphertext. A corresponding authorization trapdoor is generated based on the secondary ciphertext, and finally, an equivalence test is performed by combining the respective secondary ciphertexts and the authorization trapdoor. After the ciphertext equivalence test between the requester and the owner (i.e., a successful match), a re-encryption key is obtained, and the owner's secondary ciphertext is re-encrypted using this key to generate primary ciphertext. Finally, the requester decrypts the primary ciphertext using their private key to obtain the owner's pathological data; similarly, the owner can decrypt their secondary ciphertext using their private key to obtain their own pathological data. This re-encryption method, combined with blockchain and IPFS storage structures, improves the flexibility and security of data sharing, ensuring the entire sharing process is secure, transparent, and traceable.

[0160] In this embodiment of the invention, to ensure the correctness of the ciphertext equivalence test design for the requester and the owner, formula (3) is derived and calculated to ensure the correctness of formula (4). The proof process is as follows:

[0161] The owner's test parameters are transformed, and the transformation process is shown in formulas (12) and (13).

[0162]

[0163]

[0164] Formula (7) can be derived from the bilinear pairing property, thus completing the proof.

[0165] In this embodiment of the present invention, in order to verify the correctness of the re-encrypted ciphertext and ensure that the re-encrypted ciphertext is the same as the original ciphertext and can be decrypted by the requester using the key, the verification ciphertext can also be calculated according to formulas (14) to (16).

[0166]

[0167] Among them, C2 ′ To verify the ciphertext, C2 ′ To verify a portion of the ciphertext. To verify C1 in the re-encrypted first-level ciphertext. ′ And verify the C1 in the ciphertext ′ Whether they are equal, we will now derive and calculate based on formula (17).

[0168]

[0169] Q.E.D.

[0170] Through the above technical solutions, the storage system for pathological data based on hybrid multi-permission blockchain and IPFS provided by the present invention can meet the characteristics of multi-source heterogeneity of pathological data by using the distributed file system in the off-chain storage layer 03 and the blockchain in the storage chain layer 02 for storage, thereby reducing storage pressure. The blockchain storage method can be decentralized, effectively avoiding the problem that centralized storage is vulnerable to single point of attack, and improving the privacy protection and efficient use of data.

[0171] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0172] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A storage system for pathological data based on hybrid multi-permission blockchain and IPFS, characterized in that, include: An off-chain storage layer, which includes a distributed file system for storing large-capacity digital pathological slides; A storage chain layer, the storage chain layer including a blockchain, the blockchain being used to store structured pathological information; The shared chain layer includes multiple access levels, which are used to obtain pathological data in the storage chain layer according to different user levels and share the data. The off-chain storage layer, the storage chain layer and the shared chain layer are interconnected through smart contracts. The access levels of the shared chain layer include Level 1 users, Level 2 users, and Level 3 users. When a Level 1 user performs a write operation, updates sensitive information, or organizes node elections, consensus must be reached through voting among nodes within the alliance organization. The storage system further includes an encryption / decryption module, which is used to perform: Obtain pathology data from various medical institutions; The pathological data is encrypted using the user's public key to form ciphertext and uploaded to the off-chain storage layer or the storage chain layer; Get the requester's shared request; Upon receiving the sharing request, secure sharing is performed based on the sharing request and the owner's pathological data, including: Retrieve common parameters; Generate public-private key pairs for the requester and the owner based on the public parameters respectively; Based on the requester's public key, the owner's public key, and the public parameters, the secondary ciphertext of the requester and the owner is obtained, including: Calculate the partial ciphertexts of the second-level ciphertexts of the requester and the owner respectively according to formula (1). ，（1） in, This is the first part of the ciphertext. The public key of the requester or the owner. ,exist Pick At that time, the owner was in Pick The person making the request is at that time. It is a hash function, and , Modulus is prime A finite field of integers, For length is bit strings, It is plain text, and , and For length size, This is the second part of the ciphertext. It is a hash function, and , This is the third part of the ciphertext. It is a hash function, and , For bit strings of any length, For re-encryption conditional parameters, This is the fourth part of the ciphertext. It is a hash function, and , This is the fifth part of the ciphertext. It is a hash function, and , Two prime numbers of order 2 A bilinear pairing group that satisfies , For the group elements of the bilinear pairing group, For encrypted parameters, and , This is the sixth part of the ciphertext. This is the seventh part of the ciphertext. , , and It is a random number, and , , , For length is bit strings, For string concatenation operations, For XOR operation, For bilinear pairing operations, the secondary ciphertexts of the requester and the owner are calculated respectively according to formula (2). ，（2） in, This is a secondary ciphertext of the requester or the owner; The authorization trapdoor of the requester and the owner is obtained based on the second-level ciphertext of the requester and the owner; An equivalence test is performed based on the authorization trapdoors of the requester and the owner, including: The test parameters for the requester and owner are obtained according to formula (3). ，（3） in, Test parameters for the requester or owner. This is an authorization trap for the requester or owner, and , e represents the bilinear pairing operation. It is a random number, and An equivalence test is performed based on the test parameters of the requester and the owner. Specifically, it is necessary to determine whether the equation shown in formula (7) holds true. ，（7） in Test parameters for the owner, For the requester's test parameters, specifically, the ciphertext equivalence test between the requester and the owner is to determine whether the two have the same message; Determine whether the equality test was successful; If the equality test is found to be a successful match, the re-encryption key is obtained; The owner's secondary ciphertext is re-encrypted using the re-encryption key to form primary ciphertext, which is then sent to the requester. The primary ciphertext is decrypted using the requester's private key to obtain the owner's pathological data.

2. The storage system according to claim 1, characterized in that, Retrieving and sharing pathological data from the storage chain layer based on different user levels includes: Obtain the access request from the requester, the access request including the access level and access operation; Obtain the user level of the requester; Determine whether the user level is lower than the access level; If the user's level is determined to be lower than the access level, the access request is deemed to have failed. If the user level is determined to be higher than or equal to the access level, it is determined whether the access operation is a read operation; If the access operation is determined to be a read operation, the data to be queried is sent to the requester; If it is determined that the access operation is not a read operation, it is determined whether the access operation is a legal operation; If the access operation is determined to be a valid operation, the access operation is executed. If the access operation is determined to be invalid, the access request is deemed to have failed.

3. The storage system according to claim 1, characterized in that, The smart contracts include a pathology data storage contract, a pathology data query contract, a pathology data update contract, and a pathology data deletion contract.

4. The storage system according to claim 1, characterized in that, Obtaining the re-encryption key includes: Calculate the re-encryption key according to formula (4). ，（4） in, The re-encryption key, This is the first layer of encryption parameters. This is the second layer of encryption parameter. The public key of the requester. It is a re-encrypted random number, and .

5. The storage system according to claim 1, characterized in that, Decrypting the re-encrypted ciphertext using the requester's private key to obtain the owner's pathological data includes: The first-level ciphertext is decrypted according to formula (5). ，（5） in, and These are the parameters in the first-level ciphertext; The first judgment formula is obtained according to formula (6). ，（6） Determine whether the equation in the first judgment formula is true; If the equation of the first judgment formula is true, the pathological data of the owner is output.

Images