A distributed cross-shard data query method and device for medical data sharing

Abstract

The present invention discloses a distributed cross-shard data query method and device for medical data sharing. The method is applied to a supernode in a sharded blockchain, wherein the supernode has a weight greater than a preset weight threshold and stores local information. The method comprises: updating local information upon receiving a message indicating that a data migration request of a queried user has been successfully processed; receiving a data query request from the querying user, wherein the data query request carries the account identifier of the queried user; using the updated local information, based on the account identifier, to locate a target shard in the sharded blockchain and forward the data query request to the target shard; and receiving a data query result for the data query request from the target shard. The present invention can be applied in sharded blockchain scenarios for medical data sharing, effectively implementing distributed cross-shard data queries with low overhead and 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 is a blockchain expansion technology designed to improve its scalability. The core idea behind sharding is to split the blockchain network into multiple, parallel processing segments, enabling each shard to process only specific transaction data or smart contracts, thereby reducing the overall network burden.

[0003] In a sharded blockchain, the core issue for data queries is determining which shard a piece of data belongs to. Because each shard's nodes typically store only the complete data for their own shard, it's often difficult for consensus nodes to determine the specific shard where a piece of data resides. Synchronizing the data held by every shard across the entire network would consume significant network bandwidth, degrading blockchain performance.

[0004] Sharded blockchain scenarios for medical data sharing, or blockchain scenarios for medical data sharing, are consortium chains with access mechanisms, offering higher security than public blockchains. In these scenarios, blockchain nodes within a city are considered a shard, and cross-shard account data migration is common. Existing methods for querying data on sharded blockchains require searching each shard individually, resulting in high query overhead. While top-level shard nodes (those responsible for managing and coordinating the operations of each shard) can reduce query overhead, they incur high data structure maintenance overhead and require additional network consensus to support account migrations and changes in account ownership. This results in low query efficiency and is unsuitable for sharded blockchain scenarios for medical data sharing.

[0005] To address the above issues, no effective solutions have been proposed so far. 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 existing technology cannot effectively implement distributed cross-shard data query with low overhead and high query efficiency in a sharded blockchain scenario for medical data sharing.

[0007] In a first aspect, 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, wherein the weight of the super node is greater than a preset weight threshold, and the super node stores local information. The method includes:

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

[0009] Receive 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 sharded 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 as follows:

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

[0014] Determining the weight of each node based on the hardware resource data;

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

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

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

[0018] According to the registered address information, query whether there is a matching shard that matches 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 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 indicating that the data migration request of the queried user has been 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 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.

[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 that matches 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, embodiments of this specification further 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, configured to update local information upon receiving a message that a data migration request of a queried user has been successfully processed;

[0034] A query request receiving module, 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;

[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] The feedback module is used to receive the data query result fed back by the target shard for the data query request.

[0037] On the third aspect, the embodiments of this specification also provide a computer-readable storage medium on which computer program instructions are stored. When the computer program instructions are executed by a processor, the steps of the above-mentioned distributed cross-shard data query method for medical data sharing are implemented.

[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 has been 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, the target shard in the sharded blockchain is located according to the account identifier 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 has been successfully processed, without the need to use additional network consensus to support the change in 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 the data query and then feeds back the data query results to the super node, which can effectively reduce the data query overhead and improve the 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 the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0040] Figure 1 This is a flow chart of a distributed cross-shard data query method for medical data sharing provided by an embodiment of this specification;

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

[0042] Figure 3 This is a flow chart of a distributed cross-shard data query method for medical data sharing provided by an embodiment of this specification;

[0043] Figure 4 This is a schematic diagram of the overall interaction of distributed cross-shard data query for medical data sharing provided by the embodiments of this specification;

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

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

[0046] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall 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 data security, transparency, and immutability. Each block contains a set of transaction records, and blocks are linked together through cryptographic hashes to form a chain.

[0048] Sharded blockchain is a blockchain expansion technology designed to improve scalability. In traditional blockchains, all nodes participate in the verification and recording of all transactions. However, as the network grows, performance and processing power gradually become bottlenecks. Sharding technology, on the other hand, divides the entire network into multiple smaller shards, each independently processing a portion of transactions and smart contracts. This reduces the load on individual nodes, improving throughput and network efficiency. The core concept of sharded blockchain is to split the blockchain network into multiple parallel processing sections, so that each shard is responsible for processing only specific transaction data or smart contracts, thereby reducing the burden on the overall network. Data and information can be exchanged between different shards using cross-shard protocols. Sharding technology improves blockchain performance while maintaining decentralization, making it an effective solution to blockchain scalability issues.

[0049] In a sharded blockchain system, the core issue of data querying is determining which shard a piece of data belongs to. Because each shard's nodes typically store only the complete data within their own shard, it's often difficult for consensus nodes to determine the specific shard where a piece of data resides. Synchronizing the data held by every shard across the entire network would consume significant network bandwidth, degrading blockchain performance.

[0050] Some traditional sharded blockchains, such as Monoxide, use a mapping mechanism to map data to specific shards (typically, account data in these blockchains). For example, Monoxide uses the last few digits of an account's address as the mapping key. If there are N shards in the blockchain network, then the account will be assigned to the shard with the shard ID number shardID = key%N. While this solution can address data query issues in sharded blockchain systems, this static hashing scheme can easily lead to uneven load on the sharded blockchain, which in turn degrades performance. Furthermore, Monoxide is incompatible with sharded blockchains for medical data sharing, and its consensus mechanism cannot be applied to these scenarios. For example, in sharded blockchains for medical data sharing, blockchain nodes within a city are often considered a shard. However, a patient's account is typically calculated using a hash (patient name + ID card), making it difficult to assign a patient to the correct shard based on a random hash. This static hashing scheme, which relies on account addresses, is unsuitable for sharded blockchains for 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 top-level shard nodes can reduce query overhead, the overhead of maintaining data structures is high, and additional network consensus is required to support account migrations that lead to changes in account ownership. The query efficiency is low and cannot be applied to sharded blockchain scenarios for 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, wherein 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 has been 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] The above solution can solve the data query problem in the sharded blockchain scenario of medical data sharing, and can effectively determine which shard a piece of data belongs to. There is no need to use additional network consensus to support account migration and change of account ownership. The query overhead is low and the query efficiency is high.

[0054] It should be noted that the terms "first," "second," and the like 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 precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, for the purposes of describing the embodiments of this application.

[0055] It is understood that the methods described in the embodiments of this specification can be applied to electronic devices, which can refer to electronic devices capable of data calculation, processing, and storage. Such electronic devices can be terminals such as PCs (personal computers), tablets, smartphones, wearable devices, and intelligent robots; they can also be servers. The server can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server providing 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 the 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] The following will introduce a distributed cross-shard data query method for medical data sharing provided by the embodiments of this specification 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 the method operation steps or device structure 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 where there is no necessary causal relationship logically, 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 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 embodiment or drawings (for example, a parallel processor or multi-threaded processing environment, or even a distributed processing, server cluster implementation environment). For specific implementation, please 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, and the super node stores local information. The method may include the following content.

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

[0060] S102: Receive 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 sharded 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 a preset weight threshold and stores local information. The super node can locate the shard where the account identifier of the queried user in the data query request is located or belongs based on the local information, and then forward the data query request 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. It can be applied to the sharded blockchain scenario of medical data sharing.

[0064] Specifically, upon receiving a message that a data migration request from a queried user has been successfully processed, the supernode can update its local information, eliminating the need for additional network consensus to support changes in account ownership caused by account migration. Upon receiving a data query request from a querying user, the supernode can use this updated local information to locate the target shard in the sharded blockchain based on the account identifier of the queried user carried in the request. The supernode then forwards the query request to the target shard, allowing the target shard to perform the data query (specifically, the nodes on the target shard perform the data query) and then feedback the query results to the supernode. This effectively reduces data query overhead and improves data query efficiency.

[0065] In some embodiments, the super nodes may be determined as follows:

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

[0067] Determining the weight of each node based on the hardware resource data;

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

[0069] Specifically, in sharded blockchain scenarios for medical data sharing, supernodes are typically nodes in the sharded blockchain with high storage capacity and good network performance. A supernode can be more than just a single node; it can also represent a consensus group, a committee, and so on. Previous sharded blockchain committee designs have often focused on committee security, preventing malicious behavior through constant reshuffling and reorganization. However, this constant reorganization leads to significant consensus overhead and latency, which not only impacts user experience but also degrades blockchain performance.

[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 higher 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 more quickly, 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 a preset weight threshold, so that the node with a weight greater than the preset threshold is selected from the comparison results as a super node (that is, the node with a higher weight is selected as the super node). Among them, the preset weight threshold can be set according to actual needs, and this specification does not specifically limit this.

[0071] In some embodiments, a supernode can act as a request relay, leveraging its own local information to quickly locate the shard where cross-shard data resides and forwarding data query requests to that shard. The local information stored within a supernode can be dynamically modified to meet the needs of different scenarios, thereby achieving a balance between supernode performance and query request efficiency.

[0072] In some embodiments, the local information described above may refer to a hash table or Bloom filter stored within a supernode. These two data structures can be different. Selection can be based on the supernode's performance data (e.g., memory, network). For example, a supernode with ample memory resources but scarce network resources can store a hash table. This hash table can accurately locate the specific shard of each piece of data, requiring only one relay request for a single message, which is more network-friendly. A supernode with ample network resources but limited memory can store a Bloom filter. While Bloom filters can have false positives, meaning a single request may need to be sent to multiple parties, they consume very little memory and are therefore suitable for supernodes with limited memory. Alternatively, a Bloom filter and a hash table can be used based on the characteristics of the data stored in the supernode, taking into account factors such as the amount of data and memory space available, to achieve 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 acts maliciously, the user will receive wrong data, but because the blockchain has "authentication", the user 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, they can make decisions 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, the specific implementation may also include:

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

[0076] According to the registered address information, query whether there is a matching shard that matches 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 shards other than 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 local information.

[0080] Specifically, the above-mentioned first shard can be any shard to which the user sends a data registration request. The above-mentioned matching shard is the shard that matches the registration address information, indicating that the user has already registered an account in the shard. The above-mentioned data registration request 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, indicating that the user has already registered an account in the matching shard, 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] A user first sends a data registration request to a shard (the first shard mentioned above). This request includes the account registration address formed by the user's public key (the registration address information mentioned above), which uniquely identifies the user's data. After receiving the data registration request, the shard's leader node forwards it to the supernode. The shard's leader node intends to assign the account to its own shard. Upon receiving the data registration request from the shard, the supernode locally queries whether the account already exists in other shards (for example, it can use the user's registration address information to prevent users from creating multiple accounts with the same address across multiple shards). If the account already exists in another shard, the supernode responds with a "deny" message (the registration prohibition message mentioned above) to the shard's leader node. If the account is indeed newly added, the supernode responds with a "yes" message (the registration permission message mentioned above) and locally establishes a mapping between the account identifier and the shard. The account identifier can be used to locate the corresponding account, and the mapping can be used to locate the corresponding shard, which stores the previously registered account data. In addition, after receiving the message, the sharding node will also reply to the user with a message that the account creation was successful or 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, where the hash values calculated by multiple hash functions (e.g., K1, K2, K3) for the account identifier corresponding to the account all take the first value (e.g., 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, where the hash values calculated by multiple hash functions (e.g., K1, K2, K3) for the account identifier corresponding to the account all take the first value (e.g., 1), indicating that the account may exist in the matching shard.

[0086] In some embodiments, before the above S101, the specific implementation may also include:

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

[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 indicating 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 accounts that have not been migrated is as follows:

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

[0092] For example, let's assume a hash table stores three key-value pairs: {{'A', 1}, {'B', 2}, {'C', 3}}, where 'A', 'B', and 'C' represent accounts A, B, and C, respectively, and 1, 2, and 3 represent shards 1, 2, and 3, respectively. If a user sends a data query request with the account identifier "A," requesting account A's account data (e.g., balance), the supernode can forward the request to shard 1 based on the hash table to retrieve account A's account data. The hash table records the specific shard where each account's account data resides.

[0093] Taking Bloom filter as an example, assuming there are 4 shards in the sharded blockchain system, there will be 4 Bloom filters in the system, namely Figure 2In the example, a, b, c, and d in [1, 4], the i-th Bloom filter corresponds to the i-th shard (i∈[1,4]). Each Bloom filter can have three hash functions (K1, K2, K3, where K=3). If a user sends a data query request with the account identifier A, requesting account A's account data (such as account balance), the supernode can make the following judgment on the Bloom filter: If account A is in the i-th Bloom filter of the i-th shard, then the hash results (such as hash values) calculated by the three hash functions all take the first value (such as 1), indicating that account A is likely in the i-th shard. Conversely, if any hash function's hash result takes the second value (such as 0), then account A is definitely not in the i-th shard. Therefore, the supernode can forward the data query request to the shard that meets the conditions to query account A's account data.

[0094] That is, assuming:

[0095] If BloomFilter_i(K1(A))==1, BloomFilter_i(K2(A))==1, and BloomFilter_i(K3(A))==1, then account A likely exists in the i-th shard. The supernode forwards a data query request to the i-th shard. The supernode traverses these four Bloom filters in turn, forwarding the request once to each shard that meets the criteria. This solution has some redundancy, but it is acceptable.

[0096] In some embodiments, upon 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 medical data sharing or a blockchain scenario for medical data sharing, the queried user may want 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 user being queried can send a data migration request to the leader node of Shard 1, where their account resides. This data migration request migrates the account data from Shard 1 (the shard before migration, the first shard mentioned above) to Shard 2 (the shard after migration, the second shard mentioned above). Shard 1's leader node will then send the data migration request sent by the queried user to the supernode. The supernode will first check whether it has received a migration success message from Shard 2. If it has, it indicates that the account data has been migrated from Shard 1 to Shard 2. If it has not, it indicates that the account data has not yet been migrated from Shard 1 to Shard 2. In this case, the supernode can send a migration permission message to Shard 1, allowing the migration of the account data from Shard 1 to Shard 2. After Shard 2 completes the synchronization of the account data, it will send a migration success message to the supernode, indicating that the migration is complete. Upon receiving the migration success message from Shard 2, the supernode will change the account's affiliation from Shard 1 to Shard 2, thus completing the migration of the account data. 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 not all 1, but the three hash functions of the Bloom filter in shard 2 calculate the hash results of account A with values 1. This means that shard 1 to which account A belongs has changed to shard 2, and account A's account data 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 the value of each hash value is the first value.

[0106] Specifically, the key-value pair before the update can be {'A', 1} in the above example, and the key-value pair after the update can 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 can be the one in the above example, wherein the values of each hash value calculated by each updated hash function for the account corresponding to the account identifier 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 corresponding to the account identifier in the first shard are not all 1.

[0107] In some embodiments, the above S103 utilizes the updated local information and locates the target shard in the sharded blockchain according to the queried user identifier. In specific implementation, the following steps may be included:

[0108] When the updated local information includes an updated hash table, searching the hash table for a key that matches 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. The corresponding key in the multiple key-value pairs in the hash table can be found based on the account identifier (e.g., A), and the value corresponding to the key can be determined. The migrated second shard corresponding to the value is used as the target shard, and the data query request can be forwarded to the target shard later. For example:

[0111] Account A's account data is migrated from Shard 1 to Shard 2. Shard 1 now belongs to Shard 2. The hash table is updated from {{'A', 1}, {'B', 2}, {'C', 3}} to {{'A', 2}, {'B', 2}, {'C', 3}}. Account ID A can be used to find the corresponding key 'A' in the hash table. The corresponding value is 2, and Shard 2 is selected as the target shard. The target shard is the shard storing Account A's account data.

[0112] When the local information is a Bloom filter, the updated local information may include the updated Bloom filter. The data query request may be passed through the Bloom filters in each shard, that is, the account identifier is passed through the Bloom filters in each shard, and the hash values corresponding to the account identifier in each shard are calculated using the hash functions in the Bloom filter. The shard corresponding to each hash value when the first value is taken is determined as the target shard. For example:

[0113] Account A's account data has been migrated from Shard 1 to Shard 2. The updated hash functions in the updated Bloom filter calculate all hash values for the account ID corresponding to the account on the second shard to be 1. However, the hash values for the account ID corresponding to the account on the first shard are not all 1. When traversing the account IDs, if all the calculated hash values are 1, that means the corresponding shard may contain account data for Account A. The shard corresponding to the hash value that all takes the first value (including the second shard) is used as the target shard.

[0114] In some embodiments, the data query request may also include a data identifier. Local information or updated local information may be used to locate the target shard based on the account identifier in the data query request. After locating the target shard, the target shard can 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 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 embodiment of this 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 the 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: Receive a data registration request from a user to be queried and send the data registration request to a super node. The data registration request carries the registration address information and account ID of the user to be queried;

[0118] S302: upon receiving the 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: Receive a data query request sent by the super node, where the data query request carries the account identifier and data identifier of the user being 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: Upon receiving a data migration request sent by the queried user, sending the data migration request to the super node, wherein the data migration request includes migrating from the first shard to the second shard;

[0122] S306: Upon receiving the 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, where the second shard stores account data of the 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 go into details 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 (i.e. the data query request mentioned above) to the super node. The query request is processed by the super node.

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

[0127] 3. A specific shard in the sharded blockchain network receives the query request, performs the query locally on that 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] In step 2, Shard 1 forwards the registration request from user x to the supernode. The supernode then assigns user x to Shard 1 and updates its local hash table (or Bloom filter) to locate the data corresponding to user x in Shard 1.

[0132] In step 3, user Y (the querying user) wants to check the balance of user X. User Y sends their query request to the supernode. After receiving the query request, the supernode forwards the request to the corresponding shard (or shards) based on its local hash table (or Bloom filter).

[0133] In step 4, Shard 1 receives the query request. Since Shard 1 stores user X's account information, it returns user X's balance to the supernode. The supernode then informs user Y of the result.

[0134] In 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 complete, user Y wants to query user X's balance again. User Y sends a new query request to the supernode. After receiving the query request, the supernode forwards the request to the corresponding shard (or shards) based on its local hash table (or Bloom filter).

[0136] In step 7, Shard 2 receives the query request. Since user x has already migrated to Shard 2, it returns user x's balance to the supernode. The supernode then informs user y of the result.

[0137] The blockchain in this invention is a consortium blockchain for healthcare. The user initiating a query (user Y) is typically an insurance company or medical institution that has registered and been granted access to the blockchain. Once they have been granted access to the blockchain system, they can initiate queries, and the query's unforgeability is guaranteed by user Y's private key. The user being queried (user X) is a customer who has purchased insurance. Supernodes, using their locally maintained data structures (such as hash tables or Bloom filters), can accurately and efficiently determine which shard an account may reside on.

[0138] This solution allows for the partial distribution of the responsibility for storing all shard information to certain high-performance nodes, enabling the storage of required data without requiring the storage of shard information. This solution can be applied in sharded blockchain scenarios for medical data sharing, effectively enabling distributed cross-shard data queries with low overhead and high query efficiency.

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

[0140] The above describes the present invention. However, it is worth noting that this specific embodiment is only intended to better illustrate the present application and to describe specific embodiments of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described 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 shown or the sequential order 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 examples or the accompanying 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 necessary causal relationships, 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 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 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 embodiment of this specification also proposes 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 fed back by the target shard for the data query request.

[0146] In some embodiments, the super node is determined as follows: hardware resource data of each node in the sharded blockchain is obtained; based on the hardware resource data, the weight of each node is determined; 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 from 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; based on the registration address information, query whether there is a matching shard that matches 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 use local information to locate the target shard in the sharded blockchain according to the account identifier when no message is received that the data migration request of the queried user has been 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, when the updated local information includes an updated hash table, search for a key in the hash table that matches the account identifier based on the account identifier, 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, traverse the account identifier through the Bloom filters in each shard, use the various hash functions in the Bloom filter to calculate the various hash values corresponding to the account corresponding to the account identifier in each shard, and determine the shard corresponding to the first value when each hash value is taken as the target shard.

[0153] As can be seen from the above, a distributed cross-shard data query device for medical data sharing provided in the embodiments of this specification can be applied in sharded blockchain scenarios for medical data sharing, and effectively implement distributed cross-shard data queries 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. When the processor is specifically implemented, it can perform the following steps according to the program / instructions: 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 carrying the account identifier of the queried user; using the updated local information, according to the account identifier, locate the target shard in the sharded 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 the data migration request of the queried user has been 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, based on the account identifier, to locate a target shard in the sharded blockchain and forward 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, thereby being capable of sending or receiving different data. 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. Furthermore, 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 or CDMA; it can also be a Wi-Fi chip; or it can be a Bluetooth chip.

[0160] In this embodiment, the processor 602 can be implemented in any suitable manner. For example, the processor can take the form of a microprocessor or a processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, an application-specific integrated circuit (ASIC), a programmable logic controller, an embedded microcontroller, etc. This specification is not intended to 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 that has 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, which, when executed, implements: 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, random access memory (RAM), read-only memory (ROM), cache, hard disk drive (HDD), or memory card. The memory can be used to store computer program instructions. The network communication unit can be an interface configured in accordance with a standard specified by a communication protocol and used for network connection and communication.

[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 repeated here.

[0165] Although this specification provides method operation steps as described in the embodiments or flowcharts, 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 steps among many, and does not represent the only execution order. When the device or client product is actually executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, product or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, product or device. Without further restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or device including the elements. Words such as first, second, etc. are used to indicate names and do not indicate any particular order.

[0166] Those skilled in the art will also appreciate that, in addition to implementing the controller in pure computer-readable program code, it is entirely possible to implement the same functionality by logically programming the method steps in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, embedded microcontrollers, and the like. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered structures within the hardware component. Alternatively, the devices for implementing various functions can be considered both software modules implementing the method and structures within the hardware component.

[0167] This specification may be described in the general context of computer-executable instructions, such as program modules, executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, classes, and the like 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 communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media, including storage devices.

[0168] As can be seen from the above description of the embodiments, those skilled in the art will clearly understand that this specification can be implemented using software plus a necessary general-purpose hardware platform. Based on this understanding, the technical solution of this specification can essentially be embodied in the form of a software product. This computer software product can be stored in a storage medium such as ROM / RAM, a magnetic disk, or an optical disk, and includes a number of instructions for enabling a computer device (such as a personal computer, mobile terminal, server, or network device) to execute the methods described in various embodiments or portions of the embodiments of this specification.

[0169] The various embodiments in this specification are described in a progressive manner. References to the common or similar parts of the various embodiments are sufficient. Each embodiment focuses on the differences from the other embodiments. This specification can be used in a variety of general-purpose or specialized computer system environments or configurations. For example, personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable electronic devices, network PCs, minicomputers, mainframe computers, and distributed computing environments that include any of the above systems or devices.

[0170] Although the present specification has been described with reference to the embodiments, persons skilled in the art will appreciate that there are many variations to the present specification without departing from the spirit of the present specification, and it is intended that the appended claims encompass such 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 super node having a weight greater than a preset weight threshold, the super node storing local information, the method comprising: Upon receiving a message that the data migration request of the queried user has been successfully processed, updating the local information; Receive a data query request sent by a querying user, wherein the data query request carries an account identifier of the queried user; Utilizing 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; wherein the updated local information includes an updated hash table or an updated Bloom filter, and the updated local information stores a mapping relationship between the account identifier and the migrated second shard; locating the target shard in the sharded blockchain includes: when the updated local information includes the updated Bloom filter, traversing the account identifier through the Bloom filters in the first shard and the second shard, utilizing each hash function in the Bloom filter to calculate each hash value of the account corresponding to the account identifier in the first shard, and calculating each hash value of the account corresponding to the account identifier in the second shard; when not all hash values of the first shard are the first value, and all hash values of the second shard are the first value, using the second shard as the target shard; Receive a data query result for the data query request fed back by the target shard; The method further comprises: When no message is received that the data migration request of the queried user has been successfully processed, the target shard in the sharded blockchain is located based on the account identifier using local information; the local information includes a hash table or a Bloom filter, and the local information stores a mapping relationship between the account identifier and the first shard or a mapping relationship between the account identifier and the matching shard that matches the registration address information. The first shard is any shard to which the queried user issued a data registration request or a shard before migration, and the data registration request carries the registration address information of the queried user.

2. The method according to claim 1, characterized in that The super nodes are determined in the following manner: Obtain hardware resource data for each node in the sharded blockchain; Determining the weight of each node 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.

3. The method according to claim 1, characterized in that The method further comprises: Receive a data registration request from the queried user on the first shard, where the data registration request also carries an account identifier of the queried user; According to the registered address information, query whether there is a matching shard that matches 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.

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 local information.

5. The method according to claim 1, wherein Upon 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.

6. The method according to claim 1, characterized in that 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 the value of each hash value is the first value.

7. The method according to claim 6, characterized in that The method of using the updated local information and locating a target shard in the sharded blockchain according to the queried user identifier includes: When the updated local information includes an updated hash table, a key matching the account identifier in the hash table is searched according to the account identifier, a value corresponding to the key value is determined, and a second shard corresponding to the value is used as a target shard.

8. A distributed cross-shard data query device for medical data sharing, characterized in that: 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, the device comprising: A local information updating module, configured to update local information upon receiving a message that a data migration request of a queried user has been successfully processed; A query request receiving module, 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; A positioning module is configured to use the updated local information to locate the target shard node in the sharded blockchain according to the account identifier and forward the data query request to the target shard node; wherein the updated local information includes an updated hash table or an updated Bloom filter, and the updated local information stores a mapping relationship between the account identifier and the migrated second shard; the positioning of the target shard in the sharded blockchain includes: when the updated local information includes the updated Bloom filter, traversing the account identifier through the Bloom filters in the first shard and the second shard, using each hash function in the Bloom filter to calculate each hash value of the account corresponding to the account identifier in the first shard, and calculating each hash value of the account corresponding to the account identifier in the second shard; when the values of the hash values of the first shard are not all the first values, and the values of the hash values of the second shard are all the first values, using the second shard as the target shard; A feedback module is used to receive the data query result fed back by the target shard for the data query request; Wherein, the device further comprises: When no message is received that the data migration request of the queried user has been successfully processed, the target shard in the sharded blockchain is located based on the account identifier using local information; the local information includes a hash table or a Bloom filter, and the local information stores a mapping relationship between the account identifier and the first shard or a mapping relationship between the account identifier and the matching shard that matches the registration address information. The first shard is any shard to which the queried user issued a data registration request or a shard before migration, and the data registration request carries the registration address information of the queried user.

9. 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 7 are implemented.

Images