Distributed cross-piece data query method and device oriented to medical data sharing

Abstract

The invention discloses a medical data sharing-oriented distributed cross-fragment data query method and device, the method is applied to a super node in a fragment block chain, the weight of the super node is greater than a preset weight threshold, and the super node stores local information. The method comprises the following steps: when a message that a data migration request of a queried user is successfully processed is received, updating local information; receiving a data query request sent by a query user, wherein the data query request carries an account identifier of a queried user; positioning a target fragment in a fragment block chain according to the account identifier by using the updated local information, and forwarding the data query request to the target fragment; and receiving a data query result which is fed back by the target fragment and aims at the data query request. The method can be applied to a medical data sharing fragmentation block chain scene, and distributed cross-fragmentation data query is effectively realized with relatively low overhead and relatively high query efficiency.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a distributed cross-shard data query method and device for medical data sharing. Background Art

[0002] Sharding blockchain is an extension technology of blockchain, which aims to improve the scalability of blockchain. The core idea of ​​sharding blockchain is to split the blockchain network into multiple parallel processing parts, so that each shard is only responsible for processing specific transaction data or smart contracts, thereby reducing the burden on the overall network.

[0003] In a sharded blockchain, the core issue of data query is how to determine which shard a piece of data belongs to. Since each node in each shard only stores the complete data in its own shard, it is usually difficult for consensus nodes to confirm which shard a piece of data is located in. If the data held by each shard is synchronized across the entire network, a large amount of network bandwidth will be occupied, resulting in reduced blockchain performance.

[0004] The sharded blockchain scenario for medical data sharing or the blockchain scenario for medical data sharing is a consortium chain with an access mechanism, which is more secure than the public chain. In the sharded blockchain scenario for medical data sharing, the blockchain nodes in a city are regarded as a shard, and the migration of account data across shards is common. The existing sharded blockchain data query method needs to search each shard one by one, and the query overhead is large. Although the top-level shard node (the node responsible for managing and coordinating the operation of each shard) can reduce the query overhead, its maintenance overhead of the data structure is high, and additional network consensus is required to support account migration to cause changes in account ownership. The query efficiency is low and it cannot be applied to the sharded blockchain scenario for medical data sharing.

[0005] To address the above problems, no effective solution has been proposed yet. Summary of the invention

[0006] The embodiments of this specification provide a distributed cross-shard data query method and device for medical data sharing to solve the problem that the prior art cannot effectively implement distributed cross-shard data query with lower overhead and higher query efficiency in a sharded blockchain scenario for medical data sharing.

[0007] In a first aspect, an embodiment of the present specification provides a distributed cross-shard data query method for medical data sharing, which is applied to a super node in a sharded blockchain, wherein the weight of the super node is greater than a preset weight threshold, and the super node stores local information, and the method includes:

[0008] Upon receiving a message that the data migration request of the queried user is successfully processed, updating the local information;

[0009] Receiving a data query request sent by a querying user, wherein the data query request carries an account identifier of the queried user;

[0010] Using the updated local information, according to the account identifier, locate the target shard in the shard blockchain and forward the data query request to the target shard;

[0011] Receive a data query result for the data query request fed back by the target shard.

[0012] In some embodiments, the super node is determined in the following manner:

[0013] Obtain the hardware resource data of each node in the sharded blockchain;

[0014] Determine the weight of each node according to the hardware resource data;

[0015] The weight is compared with a preset weight threshold, and a node whose weight is greater than the preset threshold is selected from the comparison result as a super node.

[0016] In some embodiments, the method further comprises:

[0017] Receive a data registration request of the queried user on the first shard, where the data registration request carries the registration address information of the queried user and the account identifier of the queried user;

[0018] According to the registered address information, query whether there is a matching shard matching the registered address information in other shards except the first shard;

[0019] If not, a registration permission message is sent to the first shard and a mapping relationship between the account identifier and the first shard is stored in local information, where the local information includes a hash table or a Bloom filter.

[0020] In some embodiments, the method further comprises:

[0021] If so, a registration prohibition message is sent to the first shard, and a mapping relationship between the account identifier and the matching shard is stored in the local information.

[0022] In some embodiments, the method further comprises:

[0023] When no message is received that the data migration request of the queried user is successfully processed, the target shard in the shard blockchain is located according to the account identifier using local information.

[0024] In some embodiments, upon receiving a message that the data migration request of the queried user is successfully processed, updating the local information includes:

[0025] Receiving a data migration request sent by a queried user, wherein the data migration request includes migrating from a first shard to a second shard;

[0026] Check whether a migration success message sent by the second shard has been received;

[0027] If not, a migration permission message is sent to the first shard, and when a migration success message is received from the second shard, the migration success message is used as a message indicating that the data migration request of the queried user has been successfully processed, and the mapping relationship between the account identifier and the second shard is stored in the local information.

[0028] In some embodiments, the updated local information includes an updated hash table or an updated Bloom filter, the updated hash table includes updated key-value pairs, the key in the key-value pair is the account identifier of the queried user, and the value is the corresponding second shard, the updated Bloom filter includes multiple updated hash functions, each updated hash function is used to calculate each hash value of the account corresponding to the account identifier on the second shard, and ensure that each hash value is the first value.

[0029] In some embodiments, using the updated local information to locate a target shard in the sharded blockchain according to the queried user identifier includes:

[0030] When the updated local information includes an updated hash table, searching the hash table for a key matching the account identifier according to the account identifier, determining a value corresponding to the key value, and using the second shard corresponding to the value as the target shard;

[0031] When the updated local information includes the updated Bloom filter, the account identifier is traversed through the Bloom filters in each shard, and the hash functions in the Bloom filter are used to calculate the hash values ​​corresponding to the account identifier in each shard, and the shard corresponding to each hash value when the first value is taken is determined as the target shard.

[0032] In a second aspect, the embodiments of this specification also provide a distributed cross-shard data query device for medical data sharing, which is applied to a super node in a sharded blockchain, wherein the weight of the super node is greater than a preset weight threshold, and the super node stores local information, and the device includes:

[0033] A local information updating module, used to update local information upon receiving a message that a data migration request of a queried user is successfully processed;

[0034] A query request receiving module, used to receive a data query request sent by a querying user, wherein the data query request carries an account identifier of the queried user;

[0035] A positioning module, configured to use the updated local information to locate a target shard node in the shard blockchain according to the account identifier and forward the data query request to the target shard node;

[0036] A feedback module is used to receive the data query result fed back by the target shard for the data query request.

[0037] In a third aspect, the embodiments of this specification also provide a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the steps of the above-mentioned distributed cross-slice data query method for medical data sharing.

[0038] The embodiments of this specification provide a distributed cross-shard data query method and device for medical data sharing, the method is applied to a super node in a sharded blockchain, the weight of the super node is greater than a preset weight threshold, and the super node stores local information. First, upon receiving a message that the data migration request of the queried user is successfully processed, the local information is updated. Then, a data query request sent by the querying user is received, and the data query request carries the account identifier of the queried user. Then, using the updated local information, according to the account identifier, the target shard in the sharded blockchain is located and the data query request is forwarded to the target shard. Finally, the data query result for the data query request fed back by the target shard is received. In the embodiments of this specification, the super node can update its own local information upon receiving a message that the data migration request of the queried user is successfully processed, without the need to use additional network consensus to support the change of account ownership caused by account migration. When receiving a data query request sent by a query user, the updated local information can be used to locate the target shard in the sharded blockchain according to the account identifier of the queried user carried in the data query request, and then the data query request can be forwarded to the target shard, so that the target shard performs data query and then feeds back the data query result to the super node, which can effectively reduce data query overhead and improve data query efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the prior art descriptions. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0040] Figure 1 It is a flowchart of a distributed cross-slice data query method for medical data sharing provided in an embodiment of this specification;

[0041] Figure 2 is an example diagram of a Bloom filter provided in an embodiment of this specification;

[0042] Figure 3 It is a flowchart of a distributed cross-slice data query method for medical data sharing provided in an embodiment of this specification;

[0043] Figure 4 This is an overall interactive schematic diagram of distributed cross-slice data query for medical data sharing provided by an embodiment of this specification;

[0044] Figure 5 This is a schematic diagram of the structure of a distributed cross-slice data query device for medical data sharing provided in an embodiment of this specification;

[0045] Figure 6 It is a schematic diagram of the structural composition of an electronic device provided in an embodiment of this specification. DETAILED DESCRIPTION

[0046] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0047] ‌Blockchain is a decentralized distributed ledger technology that uses cryptography, consensus mechanisms, and network protocols to ensure the security, transparency, and immutability of data. Each block contains a set of transaction records, and blocks are linked together through cryptographic hashes to form a chain.

[0048] Sharding blockchain is an extension technology of blockchain, which aims to improve the scalability of blockchain. In traditional blockchain, all nodes participate in the verification and recording of all transactions, but as the network grows, performance and processing power gradually become bottlenecks. Sharding technology divides the entire network into multiple small shards, each of which independently processes a part of transactions and smart contracts, thereby reducing the load on a single node and improving throughput and network efficiency. The core idea of ​​sharding blockchain is to split the blockchain network into multiple parallel processing parts, so that each shard is only responsible for processing specific transaction data or smart contracts, thereby reducing the burden on the overall network. Different shards can exchange data and information through cross-shard protocols. Sharding technology improves blockchain performance while still maintaining the decentralized characteristics, and is one of the effective ways to solve the blockchain scalability problem.

[0049] In a sharded blockchain system, the core issue of data query is how to determine which shard a piece of data belongs to. Since in a sharded blockchain system, each node of each shard often only stores the complete data in its own shard, it is usually difficult for consensus nodes to confirm which shard a piece of data is located in. If the data held by each shard is synchronized across the entire network, a large amount of network bandwidth will be occupied, resulting in reduced blockchain performance.

[0050] Some traditional sharded blockchains (such as Monoxide) use a mapping mechanism to map data to a specific shard (in this type of blockchain, account data is generally mapped). For example, Monoxide uses the last few digits of the account address as the mapping key. If there are N shards in the blockchain network, then this account will belong to the shard with the shard ID = key%N. Although this solution can solve the data query problem in the sharded blockchain system, this static partitioning solution that relies on hashing is prone to cause uneven load on the sharded blockchain, which in turn leads to a decrease in the performance of the sharded blockchain. In addition, Monoxide is not compatible with the sharded blockchain scenario of medical data sharing or the blockchain scenario of medical data sharing. This consensus mechanism cannot be applied to the medical data sharing blockchain. For example, in the sharded blockchain scenario of medical data sharing, a blockchain node in a city is often regarded as a shard. However, a patient's account is generally calculated by Hash (patient name + patient ID card), so it is difficult for the patient to be partitioned into the correct shard through a random hash result. This static partitioning method that relies on the account address is not suitable for the sharded blockchain scenario of medical data sharing.

[0051] In addition, some solutions, such as using top-level shard nodes (nodes responsible for managing and coordinating the operation of each shard) for data query, although the top-level shard nodes can reduce query overhead, the overhead of maintaining the data structure is high, and additional network consensus is required to support account migration resulting in changes in account ownership. The query efficiency is low and cannot be applied to the sharded blockchain scenario of medical data sharing.

[0052] In order to solve the above problems, the embodiments of this specification provide a distributed cross-shard data query method for medical data sharing, which is applied to a super node in a sharded blockchain, the weight of the super node is greater than a preset weight threshold, and the super node stores local information. First, upon receiving a message that the data migration request of the queried user is successfully processed, the local information is updated. Then, a data query request sent by the querying user is received, and the data query request carries the account identifier of the queried user. Then, using the updated local information, according to the account identifier, the target shard in the sharded blockchain is located and the data query request is forwarded to the target shard. Finally, the data query result for the data query request fed back by the target shard is received.

[0053] Through the above solution, the data query problem in the sharded blockchain scenario of medical data sharing can be solved, and it can be effectively determined which shard a certain data belongs to. There is no need to use additional network consensus to support account migration that leads to changes in account ownership. The query overhead is low and the query efficiency is high.

[0054] It should be noted that the terms "first", "second", etc. in the specification and claims of this application are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so as to describe the embodiments of the present application described herein.

[0055] It can be understood that the above method provided in the embodiments of this specification can be applied to electronic devices, and the electronic devices can refer to electronic devices with data calculation, processing and storage capabilities. The electronic device can be a terminal such as a PC (Personal Computer), a tablet computer, a smart phone, a wearable device, an intelligent robot, etc.; it can also be a server. Among them, the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud computing services.

[0056] It should also be noted that the user-related information and data involved in the embodiments of the specification of this application are all information and data authorized by the user or fully authorized by relevant parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with relevant laws, regulations and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entrances for users or relevant parties to choose to authorize or refuse.

[0057] A distributed cross-shard data query method for medical data sharing provided in an embodiment of this specification will be introduced below in conjunction with the accompanying drawings.

[0058] Figure 1It is a flow chart of a distributed cross-slice data query method for medical data sharing provided in an embodiment of this specification. Although this specification provides method operation steps or device structures as shown in the following embodiments or drawings, the method or device may include more or fewer operation steps or module units after partial merger based on routine or no creative labor. In the steps or structures that do not logically have a necessary causal relationship, the execution order of these steps or the module structure of the device is not limited to the execution order or module structure shown in the embodiments or drawings of this specification. When the method or module structure described is applied in an actual device, server or terminal product, it can be executed sequentially or in parallel according to the method or module structure shown in the embodiments or drawings (for example, in an environment of parallel processors or multi-threaded processing, or even including distributed processing, server cluster implementation environment). For specific implementation, refer to Figure 1 As shown, the method is applied to a super node in a sharded blockchain, the weight of the super node is greater than a preset weight threshold, the super node stores local information, and the method may include the following content.

[0059] S101: upon receiving a message that a data migration request of a queried user is successfully processed, updating local information;

[0060] S102: receiving a data query request sent by a querying user, wherein the data query request carries an account identifier of the queried user;

[0061] S103: Using the updated local information and according to the account identifier, locate the target shard in the shard blockchain and forward the data query request to the target shard;

[0062] S104: Receive a data query result for the data query request fed back by the target shard.

[0063] Based on the above embodiments, a super node is designed in the sharded blockchain, whose weight is greater than the preset weight threshold and stores local information. The shard where the account identifier of the queried user in the data query request is located or belongs can be located based on the local information, and then the data query request is forwarded to the shard for data query, thereby achieving efficient data query, and the local information can be continuously updated according to the data migration situation, without the need for additional network consensus to support the change of account ownership caused by account migration, the overhead of maintaining the data structure is low, and the data query overhead is also low, which can be applied to the sharded blockchain scenario of medical data sharing.

[0064] Specifically, when a super node receives a message that the data migration request of the queried user has been successfully processed, it can update its own local information without using additional network consensus to support the change of account ownership caused by account migration. When receiving a data query request sent by a querying user, the updated local information can be used to locate the target shard in the sharded blockchain according to the account identifier of the queried user carried in the data query request, and then the data query request can be forwarded to the target shard, so that the target shard performs data query (specifically, the node on the target shard performs data query work) and then feedbacks the data query results to the super node, which can effectively reduce data query overhead and improve data query efficiency.

[0065] In some embodiments, the super nodes may be determined in the following manner:

[0066] Obtain the hardware resource data of each node in the sharded blockchain;

[0067] Determine the weight of each node according to the hardware resource data;

[0068] The weight is compared with a preset weight threshold, and a node whose weight is greater than the preset threshold is selected from the comparison result as a super node.

[0069] Specifically, in the sharded blockchain scenario of medical data sharing or the blockchain scenario of medical data sharing, the super node is generally a node in the sharded blockchain with higher storage capacity and better network performance. A super node can be more than just a node, but also a consensus group, a committee, etc. In the past, when designing committees, sharded blockchains often focused on the security of the committees, and avoided the situation where the committees did evil by constantly disrupting and reorganizing. However, the constant reorganization caused by this method will bring about considerable consensus overhead and delay, which not only affects the user experience, but also degrades the performance of the blockchain.

[0070] The present invention designs super nodes based on the access security of the medical data sharing blockchain itself and the business characteristics of data query. When selecting or designing super nodes, priority is given to nodes with better hardware resources (since this scenario is a consortium chain, super nodes should be nodes with larger weights in the consortium chain). They have better storage conditions and network environments. When facing query requests from various users or consensus nodes, super nodes can respond faster, thereby effectively improving data query efficiency. Among them, the weight of each node can be determined based on the hardware resource data of each node, and then each weight is compared with the preset weight threshold, so that the node with a weight greater than the preset threshold is selected from the comparison result as the super node (that is, the node with a larger weight is used as the super node). Among them, the preset weight threshold can be set according to actual needs, and this specification does not make specific restrictions on this.

[0071] In some embodiments, the supernode can act as a request relay, using its own local information to quickly locate the shard where the cross-shard data is stored, and forward the data query request to that shard. According to the needs of different scenarios, the local information stored in the supernode can be dynamically modified to achieve a trade-off between supernode performance and query request efficiency.

[0072] In some embodiments, the above-mentioned local information may refer to a hash table or Bloom filter stored inside the super node, and the hash table or Bloom filter may be two different data structures. It may be selected according to the performance data of the super node (such as memory, network), such as: for a super node with sufficient memory resources and scarce network resources, it may store a hash table, which may accurately locate the specific shard of each data, and for a message, it has only one transfer request, which is relatively friendly to the network. For a super node with sufficient network resources and tight memory, it may store a Bloom filter, which may have false positives, which means that a request may need to be sent to multiple parties, but the Bloom filter occupies very little memory, which is suitable for super nodes with smaller memory. It may also be possible to try to use Bloom filters and hash tables based on the characteristics of the data stored in the super node, and based on the amount of data, the size of the memory space, etc., to strike a balance between query efficiency and memory usage.

[0073] In some embodiments, there may be more than one super node. When there are multiple super nodes, the query pressure can be balanced to avoid "single point pressure overload". In addition, users can send data query requests to a super node to query the shard where the data is located. If the super node does evil, the user will receive wrong data, but because the blockchain has "authenticity", users can identify whether the wrong data is forged. When the user finds that the data is forged, he can also send data query requests to other super nodes to try to obtain the correct data. In addition, in order to prevent malicious users from launching double-spending attacks and creating multiple accounts at the same time, the response of the super node often requires multiple nodes to negotiate together. In order to prevent individual super nodes from colluding with each other and maliciously organizing normal user applications, when there are multiple super nodes, decisions can be made together, or the leader node of the shard can send the same request to multiple super nodes at the same time.

[0074] In some embodiments, before the above S101, in specific implementation, the following steps may also be included:

[0075] Receive a data registration request of the queried user on the first shard, where the data registration request carries the registration address information of the queried user and the account identifier of the queried user;

[0076] According to the registered address information, query whether there is a matching shard matching the registered address information in other shards except the first shard;

[0077] If not, a registration permission message is sent to the first shard and a mapping relationship between the account identifier and the first shard is stored in local information, where the local information includes a hash table or a Bloom filter.

[0078] In some embodiments, after querying whether there is a matching shard matching the registered address information in other shards except the first shard, the specific implementation may further include:

[0079] If so, a registration prohibition message is sent to the first shard, and a mapping relationship between the account identifier and the matching shard is stored in the local information.

[0080] Specifically, the first shard mentioned above can be any shard to which the user sends a data registration request. The matching shard mentioned above is a shard that matches the registration address information, indicating that the user has registered an account in the shard. The data registration request mentioned above can be an account data registration request. If the first shard receives a registration permission message sent by the super node, it will store the account data registered by the user locally in the first shard. At the same time, after the super node sends a registration permission message to the first shard, it will establish and store the mapping relationship between the account identifier and the first shard in the local information. If the first shard receives a registration prohibition message sent by the super node, it indicates that the user has registered an account in the matching shard, and the first shard will not store the user's account data locally. At the same time, after the super node sends a registration prohibition message to the first shard, it will establish and store the mapping relationship between the account identifier and the matching shard in the local information.

[0081] The specific registration process is as follows:

[0082] The user first sends a data registration request to a shard (i.e., the first shard mentioned above). This request contains the account registration address formed by the user's public key (i.e., the registration address information mentioned above), which can be used to uniquely identify a user's data. After receiving the data registration request, the leader node of the shard will forward the data registration request to the super node. The leader node of the shard wants to assign this account to its own shard. After receiving the data registration request from the shard, the super node will query locally whether the account already exists in other shards (e.g., it can query the user's registration address information to prevent the user from creating multiple accounts with the same address in multiple shards). If the account already exists in other shards, the super node will reply a "negative" message (i.e., the registration prohibition message mentioned above) to the leader node of the shard. If the account is indeed a newly added account, the super node will reply a "positive" message (i.e., the registration permission message mentioned above) and establish a mapping relationship between the account identifier of the account and the shard locally. The corresponding account can be located through the account identifier, and the corresponding shard can be located through the mapping relationship. The shard stores the registered account data. In addition, after receiving the message, the shard node will reply to the user with a message that the account was successfully created or a message that the account was failed based on the feedback from the super node.

[0083] The local information may include a hash table or a Bloom filter. When the local information is a hash table, the mapping relationship between the account identifier and the first shard may be a key-value pair stored in the hash table, wherein the account identifier is the key corresponding to the key-value pair, and the first shard is the value corresponding to the key-value pair. The mapping relationship between the account identifier and the matching shard may be another key-value pair stored in the hash table, wherein the account identifier is the key corresponding to the key-value pair, and the matching shard is the value corresponding to the key-value pair. For example:

[0084] Assume that the account identifier is represented by A, the first shard is represented by 1, and the matching shard is represented by 2. The key-value pairs or mapping relationships stored in the hash table are {{'A', 1}, {'A', 2}}.

[0085] When the local information is a Bloom filter, the mapping relationship between the account identifier and the first shard can be a Bloom filter located in the first shard, and the multiple hash functions (such as K1, K2, K3) therein calculate the hash value of the account corresponding to the account identifier and all take the first value (such as 1), indicating that the account may exist in the first shard. The mapping relationship between the account identifier and the matching shard can be a Bloom filter located in the matching shard, and the multiple hash functions (such as K1, K2, K3) therein calculate the hash value of the account corresponding to the account identifier and all take the first value (such as 1), indicating that the account may exist in the matching shard.

[0086] In some embodiments, before the above S101, in specific implementation, the following steps may also be included:

[0087] Determine whether a message is received indicating that the data migration request of the queried user is successfully processed.

[0088] In some embodiments, after receiving a message that the data migration request of the queried user has been successfully processed, the specific implementation may further include:

[0089] When no message is received that the data migration request of the queried user is successfully processed, the target shard in the shard blockchain is located according to the account identifier using local information.

[0090] Specifically, if the super node does not receive a message that the data migration request of the queried user has been successfully processed, it indicates that the account migration has not occurred at this time. The data query process for account migration that has not occurred is as follows:

[0091] After receiving the data query request sent by the query user, the target shard in the shard blockchain can be located using local information according to the account identifier of the queried user carried in the data query request. For example:

[0092] Taking a hash table as an example, suppose there are three key-value pairs stored in the hash table, {{'A', 1}, {'B', 2}, {'C', 3}}, where 'A', 'B', 'C' represent the corresponding accounts A, B, and C, respectively, and 1, 2, and 3 represent the corresponding shards 1, shard 2, and shard 3, respectively. If the account identifier carried in the data query request sent by the user is A, that is, the account data (such as account balance, etc.) of account A is queried, the super node can forward the data query request to shard 1 according to the hash table to query the account data of account A. The hash table records which shard the account data of each account is located in.

[0093] Taking Bloom filter as an example, assuming there are 4 shards in the sharded blockchain system, then there are 4 Bloom filters in the system, namely Figure 2a, b, c, d in the ith Bloom filter corresponds to the ith shard (i∈[1,4]), and each Bloom filter can have three hash functions (K1, K2, K3, K=3). If the account identifier carried in the data query request sent by the user is A, that is, to query the account data of account A (such as account balance, etc.), the super node can make the following judgment on the Bloom filter: If account A is in the ith Bloom filter of the ith shard, then the hash results (such as hash values) calculated by the three hash functions all take the first value (such as 1), which means that account A may exist in the ith shard. On the contrary, if the hash result calculated by any hash function takes the second value (such as 0), then account A must not be in the ith shard. Therefore, the super node can forward the data query request to the shard that meets the conditions to query the account data of account A.

[0094] That is, assuming:

[0095] BloomFilter_i(K1(A))==1 and BloomFilter_i(K2(A))==1 and BloomFilter_i(K3(A)) ==1, then account A may exist in the i-th shard, and the super node will forward a data query request to the i-th shard. The super node will traverse these four Bloom filters in turn and forward them once for each shard that meets the conditions. This solution will have a certain degree of redundancy, but it is within an acceptable range.

[0096] In some embodiments, when receiving a message that the data migration request of the queried user is successfully processed in S101, updating the local information may include:

[0097] Receiving a data migration request sent by a queried user, wherein the data migration request includes migrating from a first shard to a second shard;

[0098] Check whether a migration success message sent by the second shard has been received;

[0099] If not, a migration permission message is sent to the first shard, and when a migration success message is received from the second shard, the migration success message is used as a message indicating that the data migration request of the queried user has been successfully processed, and the mapping relationship between the account identifier and the second shard is stored in the local information.

[0100] Specifically, in a sharded blockchain scenario for sharing medical data or a blockchain scenario for sharing medical data, there may be a situation where the queried user wants to migrate account data from one shard to another. In order to reduce the overhead of maintaining the data structure, the local information of the super node can be updated during the account migration process, that is, the hash table or Bloom filter stored in the super node can be updated.

[0101] The specific migration and update process is as follows:

[0102] The queried user can send a data migration request to the leader node of shard 1 where his account is located. The data migration request is to migrate the account data from one shard 1 (the shard before migration, i.e. the first shard mentioned above) to another shard 2 (the shard after migration, i.e. the second shard mentioned above). The leader node of shard 1 will send the data migration request sent by the queried user to the super node. The super node will first check whether it has received the migration success message sent by shard 2. If it has, it means that the account data has been migrated from shard 1 to shard 2. If it has not, it means that the account data has not yet been migrated from shard 1 to shard 2. At this time, the super node can send a migration permission message to shard 1, that is, to allow the account data to be migrated from shard 1 to shard 2. After shard 2 synchronizes the account data of the account, it will send a migration success message to the super node, indicating that the account data has been migrated. After receiving the migration success message from shard 2, the super node will change the shard 1 to which the account belongs to to shard 2, so that the migration of the account data of an account is considered complete. At the same time, the super node will establish and store the mapping relationship between the account ID of the account and the migrated second shard in the local information. For example:

[0103] Taking the hash table as an example, {'A', 1} is updated to: {'A', 2}, which means that the account data of account A is migrated from shard 1 to shard 2, and the shard 1 to which account A belongs is changed to shard 2.

[0104] Taking the Bloom filter as an example, the three hash functions of the Bloom filter in shard 1 calculate the hash results of account A with values ​​of 1. The update is: the three hash functions of the Bloom filter in shard 1 calculate the hash results of account A with values ​​of not all 1, but the three hash functions of the Bloom filter in shard 2 calculate the hash results of account A with values ​​of 1. This means that shard 1 to which account A belongs has changed to shard 2, and account data of account A may be stored in shard 2.

[0105] In some embodiments, the updated local information in the above S103 may include an updated hash table or an updated Bloom filter, the updated hash table includes an updated key-value pair, the key in the key-value pair is the account identifier of the queried user, and the value is the corresponding second shard, the updated Bloom filter includes multiple updated hash functions, each updated hash function is used to calculate each hash value of the account corresponding to the account identifier on the second shard, and ensure that each hash value is the first value.

[0106] Specifically, the key-value pair before the update may be {'A', 1} in the above example, and the key-value pair after the update may be {'A', 2} in the above example, that is, the key is the account identifier (such as: A), and the value is updated from the first shard 1 to the second shard 2. The updated Bloom filter may be the above example, wherein the values ​​of each hash value calculated by each updated hash function for the account identifier corresponding to the account in the second shard are all 1 (that is, the first value mentioned above), and the values ​​of each hash value calculated for the account identifier corresponding to the account in the first shard are not all 1.

[0107] In some embodiments, the above S103 uses the updated local information to locate the target shard in the sharded blockchain according to the queried user identifier. In specific implementation, it may include:

[0108] When the updated local information includes an updated hash table, searching the hash table for a key matching the account identifier according to the account identifier, determining a value corresponding to the key value, and using the second shard corresponding to the value as the target shard;

[0109] When the updated local information includes the updated Bloom filter, the account identifier is traversed through the Bloom filters in each shard, and the hash functions in the Bloom filter are used to calculate the hash values ​​corresponding to the account identifier in each shard, and the shard corresponding to each hash value when the first value is taken is determined as the target shard.

[0110] Specifically, when the local information is a hash table, the updated local information may include the updated hash table, and the corresponding key in the multiple key-value pairs in the hash table may be searched according to the account identifier (such as A), and then the value corresponding to the key may be determined, and the migrated second shard corresponding to the value may be used as the target shard, and the data query request may be forwarded to the target shard later. For example:

[0111] The account data of account A is migrated from shard 1 to shard 2. The shard 1 to which account A belongs is changed to shard 2. The hash table is updated from the original {{'A', 1}, {'B', 2}, {'C', 3}} to {{'A', 2}, {'B', 2}, {'C',3}}. The account identifier A can be used to find the corresponding key 'A' in the hash table, and then the corresponding value is determined to be 2, that is, shard 2 is used as the target shard. The target shard is the shard that stores the account data of account A.

[0112] When the local information is a Bloom filter, correspondingly, the updated local information may include the updated Bloom filter, and the data query request may be traversed through the Bloom filters in each shard, that is, the account identifier is traversed through the Bloom filters in each shard, and each hash function in the Bloom filter is used to calculate each hash value corresponding to the account identifier in each shard, and the shard corresponding to each hash value when all the hash values ​​take the first value is determined as the target shard. For example:

[0113] The account data of account A is migrated from shard 1 to shard 2. The updated hash functions in the updated Bloom filter calculate the hash values ​​of the account ID corresponding to the account in the second shard as 1, but the hash values ​​of the account ID corresponding to the account in the first shard are not all 1. When traversing the account ID, if the calculated hash values ​​are all 1, that is, the corresponding shard may contain account data of account A, the shard (including the second shard) corresponding to the hash values ​​taking the first value is used as the target shard.

[0114] In some embodiments, the data query request may also carry a data identifier, and the target shard may be located based on the account identifier in the data query request using local information or updated local information. After locating the target shard, the target shard may accurately and quickly query the account data corresponding to the corresponding account (e.g., the balance data of account A) based on the account identifier and the data identifier (e.g., the identifier corresponding to the balance).

[0115] In some embodiments, the hash table may be replaced with different data structures according to different scenarios to achieve better time and space utilization, which is not specifically limited in this specification.

[0116] The present specification also provides a flow chart of a distributed cross-shard data query method for medical data sharing, which is applied to each shard in a sharded blockchain. Figure 3 As shown, the distributed cross-shard data query method for medical data sharing may include the following specific steps.

[0117] S301: receiving a data registration request from a queried user and sending the data registration request to a super node, wherein the data registration request carries the registration address information and the account identifier of the queried user;

[0118] S302: upon receiving a registration permission message sent by the super node, allowing the queried user to register and storing the account data registered by the queried user;

[0119] S303: receiving a data query request sent by a super node, wherein the data query request carries an account identifier and a data identifier of a user to be queried;

[0120] S304: searching for account data of the corresponding account according to the account identifier and the data identifier, generating a data query result, and feeding back the data query result for the data query request to the super node;

[0121] S305: When receiving a data migration request sent by the queried user, send the data migration request to the super node, where the data migration request includes migration from the first shard to the second shard;

[0122] S306: upon receiving a migration permission message sent by the super node, migrate the data from the first shard to the second shard, and send a migration success message to the super node based on the second shard, wherein the second shard stores account data of an account corresponding to the account identifier.

[0123] For the detailed description of the above steps S301-S306, please refer to the previous description, and this specification will not repeat them here.

[0124] The embodiments of this specification also provide a distributed cross-shard data query method for medical data sharing, which is applied to a sharded blockchain system and involves interactions between clients, super nodes, and shards. Figure 4 As shown, the specific query process is as follows.

[0125] 1. The client sends a query request to the super node (i.e. the data query request mentioned above). The query request is processed by the super node.

[0126] 2. The super node initiates a query to a specific shard. The super node sends a query request to the specified shard based on its local information (the local information here refers to the hash table or Bloom filter used by the super node. The super node can store information (information about which shard the data is located in) in different data structures based on its own memory and network performance).

[0127] 3. A specific shard in the sharded blockchain network receives the query request, performs the query locally on the shard node, and sends the query results to the super node.

[0128] 4. The super node returns the result to the client.

[0129] In a specific implementation scenario, the processes of account registration (step 1-step 2), query (step 3-step 4), account migration (step 5), and query after account migration (step 6-step 7) are exemplified.

[0130] Step 1: First, user x (the queried user) initiates an account registration request, which sends the request information to shard 1.

[0131] Step 2: Shard 1 forwards the registration request of user x to the super node. Then, the super node assigns user x to Shard 1, and then updates its local hash table (or Bloom filter) to locate the data corresponding to user x in Shard 1.

[0132] Step 3: Next, user y (query user) wants to query the balance of user x. User y needs to send his query request to the super node. After receiving the query request, the super node forwards the request to the corresponding one (or more) shards according to its local hash table (or Bloom filter).

[0133] Step 4: Shard 1 receives the query request. Since Shard 1 stores the account information of user x, it returns the balance of user x to the super node. The super node then informs user y of the result.

[0134] Step 5: User x wants to migrate to another shard 2. At this time, user x initiates a migration request. If the request is successfully processed, the super node will update the local hash table (or Bloom filter) and locate the data corresponding to user x in shard 2.

[0135] Step 6: After the migration is completed, user y wants to query the balance of user x again. User y sends a new query request to the super node again. After receiving the query request, the super node forwards the request to the corresponding one (or more) shards according to its local hash table (or Bloom filter).

[0136] Step 7: Shard 2 receives the query request. Since user x has already migrated to Shard 2, it returns the balance of user x to the super node. The super node then informs user y of the result.

[0137] Among them, the blockchain in the present invention belongs to the medical alliance chain. Generally, the role that initiates the query (user y) is the insurance agency, medical institution and other roles that have been registered and allowed in the blockchain. As long as they are allowed to enter the blockchain system, they can initiate a query, and the unforgeability of the query is guaranteed by the private key of user y. The role being queried (user x) is a customer who has purchased insurance business. The super node can accurately and efficiently determine which shard the account may exist in based on its locally maintained data structure (such as hash table or Bloom filter).

[0138] Through the above scheme, part of the responsibility of "storing all shard information" can be divided to certain nodes with stronger performance, striving to achieve both the storage of required data and the unnecessary storage of shard information. It can be applied in the sharded blockchain scenario of medical data sharing, effectively realizing distributed cross-shard data query with lower overhead and higher query efficiency.

[0139] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. For details, please refer to the description of the above-mentioned related processing related embodiments, and no further description is given here.

[0140] The above is an explanation of the present invention, however, it is worth noting that the specific embodiment is only for the purpose of better illustrating the present application and describing a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0141] Although this specification provides examples such as the following embodiments or the attached Figure 5 The method operation steps or device structure shown, but based on routine or no creative labor, the method or device may include more or fewer operation steps or module units after partial merger. In the steps or structures that do not logically have a necessary causal relationship, the execution order of these steps or the module structure of the device is not limited to the execution order or module structure shown in the embodiments of this specification or the drawings. When the method or module structure described is applied to an actual device, server or terminal product, it can be executed sequentially or in parallel according to the method or module structure shown in the embodiments or the drawings (for example, a parallel processor or multi-threaded processing environment, or even a distributed processing, server cluster implementation environment). Based on the above-mentioned distributed cross-shard data query method for medical data sharing, the embodiments of this specification also propose an embodiment of a distributed cross-shard data query device for medical data sharing, which is applied to a super node in a sharded blockchain, the weight of the super node is greater than a preset weight threshold, and the super node stores local information. As Figure 5 As shown, the device may specifically include the following modules:

[0142] The local information updating module 501 may be specifically configured to update the local information upon receiving a message that the data migration request of the queried user is successfully processed;

[0143] The query request receiving module 502 may be specifically configured to receive a data query request sent by a querying user, wherein the data query request carries an account identifier of the queried user;

[0144] The positioning module 503 may be specifically configured to use the updated local information to locate the target shard node in the shard blockchain according to the account identifier and forward the data query request to the target shard node;

[0145] The feedback module 504 may be specifically configured to receive a data query result for the data query request fed back by the target shard.

[0146] In some embodiments, the super node is determined as follows: hardware resource data of each node in the sharded blockchain is obtained; the weight of each node is determined based on the hardware resource data; the weight is compared with a preset weight threshold, and a node with a weight greater than the preset threshold is selected from the comparison result as a super node.

[0147] In some embodiments, before the above-mentioned local information update module 501, it can also be specifically used to receive a data registration request of the queried user on the first shard, and the data registration request carries the registration address information of the queried user and the account identifier of the queried user; according to the registration address information, query whether there is a matching shard matching the registration address information in other shards except the first shard; if not, send a registration permission message to the first shard and store the mapping relationship between the account identifier and the first shard in the local information, and the local information includes a hash table or a Bloom filter.

[0148] In some embodiments, before the local information updating module 501, it can also be used to send a registration prohibition message to the first shard, and store the mapping relationship between the account identifier and the matching shard in the local information.

[0149] In some embodiments, after the above-mentioned local information update module 501, it can also be used to locate the target shard in the shard blockchain based on the account identifier using the local information when no message is received that the data migration request of the queried user is successfully processed.

[0150] In some embodiments, the above-mentioned local information update module 501 can be specifically used to receive a data migration request sent by the queried user, and the data migration request includes migrating from the first shard to the second shard; querying whether the migration success message sent by the second shard has been received; if not, sending a migration permission message to the first shard and when receiving the migration success message sent by the second shard, using the migration success message as a message that the data migration request of the queried user has been successfully processed, and storing the mapping relationship between the account identifier and the second shard in the local information.

[0151] In some embodiments, the updated local information in the above-mentioned positioning module 503 includes an updated hash table or an updated Bloom filter, the updated hash table includes an updated key-value pair, the key in the key-value pair is the account identifier of the queried user, and the value is the corresponding second shard, the updated Bloom filter includes multiple updated hash functions, each updated hash function is used to calculate each hash value of the account corresponding to the account identifier on the second shard, and ensure that the value of each hash value is the first value.

[0152] In some embodiments, the above-mentioned positioning module 503 can be specifically used to search for a key matching the account identifier in the hash table according to the account identifier when the updated local information includes an updated hash table, and determine the value corresponding to the key value, and use the second shard corresponding to the value as the target shard; when the updated local information includes an updated Bloom filter, the account identifier is traversed through the Bloom filters in each shard, and each hash function in the Bloom filter is used to calculate each hash value corresponding to the account corresponding to the account identifier in each shard, and the shard corresponding to each hash value when all the hash values ​​take the first value is determined as the target shard.

[0153] It can be seen from the above that a distributed cross-shard data query device for medical data sharing provided in the embodiments of this specification can be applied in a sharded blockchain scenario for medical data sharing, and can effectively implement distributed cross-shard data query with lower overhead and higher query efficiency.

[0154] The embodiments of this specification also provide an electronic device based on the above-mentioned distributed cross-shard data query method for medical data sharing, including a processor and a memory for storing processor executable programs / instructions. The processor can perform the following steps according to the programs / instructions when implemented: upon receiving a message that the data migration request of the queried user is successfully processed, update local information; receive a data query request sent by the querying user, the data query request carries the account identifier of the queried user; using the updated local information, according to the account identifier, locate the target shard in the shard blockchain and forward the data query request to the target shard; receive the data query result for the data query request fed back by the target shard.

[0155] In order to complete the above instructions more accurately, refer to Figure 6 As shown, the embodiment of this specification also provides another specific electronic device, wherein the electronic device includes a network communication port 601, a processor 602 and a memory 603, and the above structures are connected through internal cables so that each structure can perform specific data interaction.

[0156] The network communication port 601 may be used to update local information upon receiving a message that a data migration request of a queried user is successfully processed;

[0157] The processor 602 may be specifically configured to receive a data query request sent by a querying user, the data query request carrying an account identifier of the queried user; using the updated local information, according to the account identifier, locating a target shard in the sharded blockchain and forwarding the data query request to the target shard; and receiving a data query result for the data query request fed back by the target shard;

[0158] The memory 603 may be specifically used to store corresponding instruction programs.

[0159] In this embodiment, the network communication port 601 can be a virtual port that is bound to different communication protocols so that different data can be sent or received. For example, the network communication port can be a port responsible for web data communication, a port responsible for FTP data communication, or a port responsible for email data communication. In addition, the network communication port can also be a physical communication interface or communication chip. For example, it can be a wireless mobile network communication chip, such as GSM, CDMA, etc.; it can also be a Wifi chip; it can also be a Bluetooth chip.

[0160] In this embodiment, the processor 602 may be implemented in any appropriate manner. For example, the processor may take the form of a microprocessor or a processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) executable by the (micro)processor, a logic gate, a switch, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, etc. This specification does not limit this.

[0161] In this embodiment, the memory 603 may include multiple levels. In a digital system, anything that can store binary data can be a memory; in an integrated circuit, a circuit with a storage function but no physical form is also called a memory, such as RAM, FIFO, etc.; in a system, a storage device with a physical form is also called a memory, such as a memory stick, TF card, etc.

[0162] The embodiments of this specification also provide a computer storage medium based on the above-mentioned distributed cross-shard data query method for medical data sharing, wherein the computer storage medium stores a computer program / instruction, and when the computer program / instruction is executed, it realizes: updating local information upon receiving a message that the data migration request of the queried user is successfully processed; receiving a data query request sent by the querying user, wherein the data query request carries the account identifier of the queried user; using the updated local information, according to the account identifier, locating the target shard in the sharded blockchain and forwarding the data query request to the target shard; and receiving the data query result for the data query request fed back by the target shard.

[0163] In this embodiment, the storage medium includes but is not limited to a random access memory (RAM), a read-only memory (ROM), a cache, a hard disk (HDD) or a memory card. The memory may be used to store computer program instructions. The network communication unit may be an interface for network connection communication set in accordance with the standard specified by the communication protocol.

[0164] In this embodiment, the functions and effects specifically implemented by the program instructions stored in the computer storage medium can be explained in comparison with other implementations and will not be described in detail here.

[0165] Although the present specification provides method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only order of execution. When the device or client product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The terms "include", "include" or any other variant thereof are intended to cover non-exclusive inclusion, so that the process, method, product or device including a series of elements includes not only those elements, but also other elements that are not explicitly listed, or also includes elements inherent to such a process, method, product or device. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or device including the elements. The words first, second, etc. are used to represent the name, and do not represent any particular order.

[0166] Those skilled in the art also know that, in addition to implementing the controller in a purely computer-readable program code, the controller can be made to implement the same function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered as a hardware component, and the devices for implementing various functions included therein can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules for implementing the method and structures within the hardware component.

[0167] This specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, classes, etc. that perform specific tasks or implement specific abstract data types. This specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media including storage devices.

[0168] Through the description of the above embodiments, it can be known that those skilled in the art can clearly understand that the present specification can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solution of the present specification can essentially be embodied in the form of a software product, which can be stored in a storage medium such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a mobile terminal, a server, or a network device, etc.) to execute the methods described in each embodiment of the present specification or some parts of the embodiments.

[0169] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. This specification can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld devices or portable devices, tablet devices, multi-processor systems, microprocessor-based systems, set-top boxes, programmable electronic devices, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, etc.

[0170] Although the present specification is described through embodiments, persons skilled in the art will appreciate that there are many variations of the present specification without departing from the spirit of the present specification, and it is intended that the appended claims include these variations without departing from the spirit of the present specification.

Claims

1. A distributed cross-shard data query method for medical data sharing, characterized in that: Applied to a super node in a sharded blockchain, the weight of the super node is greater than a preset weight threshold, the super node stores local information, and the method includes: Upon receiving a message that the data migration request of the queried user is successfully processed, updating the local information; Receiving a data query request sent by a querying user, wherein the data query request carries an account identifier of the queried user; Using the updated local information, according to the account identifier, locate the target shard in the shard blockchain and forward the data query request to the target shard; Receive a data query result for the data query request fed back by the target shard.

2. The method according to claim 1, characterized in that The super nodes are determined in the following manner: Obtain the hardware resource data of each node in the sharded blockchain; Determine the weight of each node according to the hardware resource data; The weight is compared with a preset weight threshold, and a node whose weight is greater than the preset threshold is selected from the comparison result as a super node.

3. The method according to claim 1, characterized in that The method further comprises: Receive a data registration request of the queried user on the first shard, where the data registration request carries the registration address information of the queried user and the account identifier of the queried user; According to the registered address information, query whether there is a matching shard matching the registered address information in other shards except the first shard; If not, a registration permission message is sent to the first shard and a mapping relationship between the account identifier and the first shard is stored in local information, where the local information includes a hash table or a Bloom filter.

4. The method according to claim 3, characterized in that The method further comprises: If so, a registration prohibition message is sent to the first shard, and a mapping relationship between the account identifier and the matching shard is stored in the local information.

5. The method according to claim 1, characterized in that The method further comprises: When no message is received that the data migration request of the queried user is successfully processed, the target shard in the shard blockchain is located according to the account identifier using local information.

6. The method according to claim 1, characterized in that When receiving a message that the data migration request of the queried user is successfully processed, updating the local information includes: Receiving a data migration request sent by a queried user, wherein the data migration request includes migrating from a first shard to a second shard; Check whether a migration success message sent by the second shard has been received; If not, a migration permission message is sent to the first shard, and when a migration success message is received from the second shard, the migration success message is used as a message indicating that the data migration request of the queried user has been successfully processed, and the mapping relationship between the account identifier and the second shard is stored in the local information.

7. The method according to claim 1, characterized in that The updated local information includes an updated hash table or an updated Bloom filter, the updated hash table includes an updated key-value pair, the key in the key-value pair is the account identifier of the queried user, and the value is the corresponding second shard, the updated Bloom filter includes multiple updated hash functions, each updated hash function is used to calculate each hash value of the account corresponding to the account identifier on the second shard, and ensure that each hash value is the first value.

8. The method according to claim 7, characterized in that The using the updated local information and locating the target shard in the shard blockchain according to the queried user identifier includes: When the updated local information includes an updated hash table, searching the hash table for a key matching the account identifier according to the account identifier, determining a value corresponding to the key value, and using the second shard corresponding to the value as the target shard; When the updated local information includes the updated Bloom filter, the account identifier is traversed through the Bloom filters in each shard, and the hash functions in the Bloom filter are used to calculate the hash values ​​corresponding to the account identifier in each shard, and the shard corresponding to each hash value when the first value is taken is determined as the target shard.

9. A distributed cross-slice data query device for medical data sharing, characterized in that: A super node applied to a sharded blockchain, wherein the weight of the super node is greater than a preset weight threshold, and the super node stores local information, and the device comprises: A local information updating module, used to update local information upon receiving a message that a data migration request of a queried user is successfully processed; A query request receiving module, used to receive a data query request sent by a querying user, wherein the data query request carries an account identifier of the queried user; A positioning module, configured to use the updated local information to locate a target shard node in the shard blockchain according to the account identifier and forward the data query request to the target shard node; A feedback module is used to receive the data query result fed back by the target shard for the data query request.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the computer program instructions are executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.

Images