Cross-fragment transaction processing method for medical data sharing

Abstract

The invention discloses a medical data sharing-oriented cross-fragment transaction processing method, which is applied to a medical data sharing block chain, the medical data sharing block chain at least comprises beacon nodes located in different fragments, and the method comprises the following steps: a first beacon node located in a sender fragment, a second beacon node located in the sender fragment, and a third beacon node located in the sender fragment; the received cross-fragment transaction is broadcasted to a second beacon node in a fragment of the receiver, the first beacon node splits the cross-fragment transaction into a first on-chip transaction, and the second beacon node splits the cross-fragment transaction into a second on-chip transaction; the first beacon node generates a first transaction snapshot and sends the first transaction snapshot to the second beacon node when receiving the first block data, and the second beacon node performs consistency verification according to the first transaction snapshot and sends a message that cross-fragment transaction processing is completed to the client when the consistency verification is passed. According to the invention, the atomicity and sharing efficiency of cross-fragment transactions can be improved at the same time under the evidence storage traceability scene of medical data sharing.

Description

Technical Field

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

[0002] With the continuous development of blockchain technology, its application in the field of medical data sharing is becoming more and more extensive. However, traditional blockchain technology has scalability problems when processing large-scale medical data, which are manifested in low throughput, high latency and high storage pressure. In order to solve these problems, sharding technology was introduced into the blockchain system to improve its scalability. Sharding technology divides the blockchain network into multiple independent shards, each of which is responsible for processing part of the transactions, thereby achieving parallel processing and higher throughput. However, sharding technology divides different data into different shards, which in turn introduces cross-shard transactions. Cross-shard transactions involve interactive processing of data between multiple shards.

[0003] Existing research on cross-shard transaction mechanisms involves more scenarios of asset transfer, and less scenarios of evidence tracing such as medical data sharing. The requirements for transaction efficiency, atomicity, etc. are different from those for data sharing evidence tracing. Transfer transactions require complex mechanisms such as asset locking, ownership transfer, and abnormal rollback processing, while evidence transactions usually have simpler logic and do not involve complex verification links. Before entering the transaction pool, the transaction structure meets the protocol requirements and has a legal signature. As long as the transaction is successfully broadcast and recorded in the block according to the consensus mechanism of the blockchain, it can be considered completed, so the possibility of failure is low. However, evidence transactions have high requirements for sharing efficiency and transaction atomicity (in the blockchain, transaction atomicity means that a transaction is either fully executed and recorded on the blockchain, or not executed at all), and the existing cross-shard transaction mechanism still has limitations in meeting these two requirements at the same time.

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

[0005] The embodiments of this specification provide a cross-shard transaction processing method for medical data sharing to solve the problem that the existing cross-shard transaction mechanism cannot improve the sharing efficiency and transaction atomicity at the same time in the evidence storage and traceability scenarios of medical data sharing.

[0006] In a first aspect, an embodiment of this specification provides a cross-shard transaction processing method for medical data sharing, which is applied to a medical data sharing blockchain, wherein the medical data sharing blockchain includes at least beacon nodes located in different shards, and the method includes:

[0007] The first beacon node in the sender shard broadcasts the cross-shard transaction received from the client to the second beacon node in the receiver shard, the first beacon node splits the cross-shard transaction into a first intra-shard transaction for the sender shard, and the second beacon node splits the cross-shard transaction into a second intra-shard transaction for the receiver shard;

[0008] When the first beacon node receives the first block data generated according to the updated first intra-shard transaction, it generates a first transaction snapshot and sends the first transaction snapshot to the second beacon node. The second beacon node performs consistency verification according to the first transaction snapshot. When the consistency verification passes, it sends a message to the client indicating that the cross-shard transaction processing is completed.

[0009] In some embodiments, the medical data sharing blockchain further includes committee nodes located in different shards, and accordingly, the method further includes:

[0010] The first beacon node broadcasts the first in-chip transaction to a first committee node in a sender shard, and the second beacon node broadcasts the second in-chip transaction to a second committee node in a receiver shard;

[0011] After receiving the first in-chip transaction, the first committee node adds the first in-chip transaction to the first transaction pool in the sending shard, and after receiving the second in-chip transaction, the second committee node adds the second in-chip transaction to the second transaction pool in the receiving shard.

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

[0013] The first committee node performs consensus verification on the first in-chip transaction in the first transaction pool and updates the first in-chip transaction after consensus verification, and the second committee node performs consensus verification on the second in-chip transaction in the second transaction pool and updates the second in-chip transaction after consensus verification.

[0014] In some embodiments, the consensus verification of the first in-chip transaction and the consensus verification of the second in-chip transaction are performed in parallel; and / or,

[0015] The updating of the first in-chip transaction and the updating of the second in-chip transaction are performed in parallel.

[0016] In some embodiments, the medical data sharing blockchain further includes block production nodes located in different shards, and accordingly, the method further includes:

[0017] The first block producing node in the sender shard generates first block data according to the updated first intra-shard transaction, and sends the first block data to the first beacon node;

[0018] The second block producing node in the receiving shard generates second block data according to the updated second intra-shard transaction, and sends the second block data to the second beacon node.

[0019] In some embodiments, when receiving the second block data, the second beacon node generates a second transaction snapshot; accordingly, the second beacon node performs consistency verification according to the first transaction snapshot, including:

[0020] The second beacon node performs consistency verification according to the first transaction snapshot and the second transaction snapshot, wherein the consistency verification includes verifying whether the blockchain heights to which the first transaction snapshot and the second transaction snapshot belong are consistent.

[0021] In some embodiments, the first transaction snapshot includes a plurality of first transaction snapshots, and accordingly, the second beacon node performs consistency verification according to the first transaction snapshot, further comprising:

[0022] Extracting corresponding block headers from the plurality of first transaction snapshots, and verifying the block headers;

[0023] When the verification is passed, the second beacon node performs consistency verification according to any transaction snapshot among the multiple first transaction snapshots;

[0024] When the verification fails, the second beacon node selects a first transaction snapshot whose reception time is less than a preset time threshold from multiple first transaction snapshots for consistency verification.

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

[0026] When the consistency verification fails and exceeds the preset block height, the second beacon node sends a message to the client indicating that the cross-shard transaction processing has failed, and initiates a rollback transaction request to the sending shard where the first beacon node is located, so that the first beacon node can receive the cross-shard transaction again.

[0027] On the second aspect, an embodiment of the present specification also provides an electronic device, including a memory and a processor, wherein the processor and the memory are communicatively connected to each other, the memory stores computer instructions, and the processor implements the steps of the above-mentioned cross-shard transaction processing method for medical data sharing by executing the computer instructions.

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

[0029] The embodiment of this specification provides a cross-shard transaction processing method for medical data sharing, which is applied to a medical data sharing blockchain, and the medical data sharing blockchain includes at least beacon nodes located in different shards. The first beacon node located in the sender shard broadcasts the cross-shard transaction received from the client to the second beacon node in the receiver shard, and the first beacon node disassembles the cross-shard transaction into a first intra-shard transaction for the sender shard, and the second beacon node disassembles the cross-shard transaction into a second intra-shard transaction for the receiver shard. When the first beacon node receives the first block data generated according to the updated first intra-shard transaction, it generates a first transaction snapshot and sends the first transaction snapshot to the second beacon node, and the second beacon node performs consistency verification according to the first transaction snapshot. When the consistency verification passes, it sends a message to the client that the cross-shard transaction processing is completed. This method is suitable for cross-shard transaction mechanisms in evidence traceability scenarios such as medical data sharing, and can improve data sharing efficiency and transaction atomicity at the same time. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] 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:

[0031] Figure 1 It is a flowchart of a cross-shard transaction processing method for medical data sharing provided in an embodiment of this specification;

[0032] Figure 2 This is a schematic diagram of cross-shard transactions provided by the embodiments of this specification;

[0033] Figure 3 It is a schematic diagram of the cross-shard transaction processing process provided by the embodiments of this specification;

[0034] Figure 4 It is a schematic diagram of transaction snapshot synchronization provided by the embodiment of this specification;

[0035] Figure 5 It is a schematic diagram of the structure of a computer device provided in an embodiment of this specification. DETAILED DESCRIPTION

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

[0037] As mentioned above, existing research on cross-shard transaction mechanisms involves more scenarios such as asset transfer and less scenarios such as evidence storage and traceability, such as medical data sharing. Evidence storage transactions have high requirements for sharing efficiency and transaction atomicity, while existing cross-shard transaction mechanisms still have limitations in meeting both requirements at the same time.

[0038] For example: the split transaction method splits the cross-shard transaction into two or more independent intra-shard transactions. Although it improves performance, it is difficult to guarantee transaction atomicity, and the abnormal rollback processing procedure is complicated. The relay transaction method initiates a relay transaction after the intra-shard transaction of the shard where the transfer account is located is completed, and the cross-shard transaction information is sent to the receiving shard, and then the receiving shard completes the intra-shard transaction to achieve the final atomicity. However, in theory, the execution of the receiving shard transaction is difficult to monitor and control, and the final atomicity cannot be guaranteed. In addition, due to the serial execution of intra-shard transactions and relay transactions, the transaction is not parallel enough, resulting in increased transaction confirmation delays. The two-phase commit method, before processing cross-shard transactions, a coordinator waits for other shards to be ready, which requires multiple rounds of consensus. It is currently the more commonly used cross-shard transaction mechanism in sharded blockchains. However, its cross-shard transaction serial execution and multiple rounds of consensus lead to increased transaction confirmation delays, and the coordinator single point failure problem also needs to be paid attention to. The deterministic sorting method cancels the coordinator role in the two-phase commit. It is based on the sorting lock mechanism and uses the concurrency control of locks to ensure the atomicity and serializability of transactions, and ensures the isolation of transactions by locking transactions in a specific transaction order. When facing high-conflict scenarios, a large number of conflicting transactions (including cross-shard transactions) will be blocked due to network congestion or insufficient computing resources. Some transactions will be terminated because cross-shard transactions have not been successfully submitted for a long time, and the abnormal rollback processing procedure is complicated.

[0039] In order to solve the above problems, the embodiment of this specification provides a cross-shard transaction processing method for medical data sharing, which is applied to the medical data sharing blockchain, and the medical data sharing blockchain includes at least beacon nodes located in different shards. The first beacon node located in the sender shard broadcasts the cross-shard transaction received from the client to the second beacon node in the receiver shard, and the first beacon node disassembles the cross-shard transaction into the first intra-shard transaction for the sender shard, and the second beacon node disassembles the cross-shard transaction into the second intra-shard transaction for the receiver shard. When the first beacon node receives the first block data generated according to the updated first intra-shard transaction, it generates a first transaction snapshot and sends the first transaction snapshot to the second beacon node. The second beacon node performs consistency verification according to the first transaction snapshot, and when the consistency verification passes, it sends a message to the client that the cross-shard transaction processing is completed. This method is suitable for the cross-shard transaction mechanism of evidence traceability scenarios such as medical data sharing, which can improve data sharing efficiency and transaction atomicity at the same time.

[0040] It should be noted that the medical data sharing blockchain is a blockchain used to store and share medical data. According to the different sharing scopes of the on-chain data, the medical data sharing blockchain can be divided into three types: medical institution private chain, regional institution alliance chain, and public medical chain. Among them, the medical institution private chain is operated by a single medical institution, and the data stored on the blockchain belongs to the medical institution. The blockchain infrastructure of the regional institution alliance chain and the data stored on the chain are shared by multiple medical institutions and other relevant organizations or individuals in the region. The blockchain platform of the public medical chain and the data stored on the chain are open to the public. The nodes on the medical data sharing blockchain are mainly institutional nodes, which must undergo strict registration and review before they can enter the network. Individual users generally rely on institutional nodes to apply for sharing services.

[0041] According to the different forms of data on the chain, the medical data sharing blockchain can be divided into three types: original medical data chain, encrypted medical data chain, and medical data hash chain. Among them, the original medical data chain stores the shared medical data plaintext directly on the blockchain, and all users on the chain can access all medical data stored on the blockchain. The encrypted medical data chain stores the shared medical data ciphertext on the blockchain. The medical data is encrypted by a secure asymmetric encryption algorithm using the public key of the receiver. The ciphertext and the sender's public key and the receiver's public key are packaged into the transaction and broadcast to the network. Only users with the corresponding private key can decrypt the record. The medical data hash chain stores the shared medical data hash value on the blockchain. Medical institutions are responsible for generating and storing medical data on their systems, while calculating the hash value of the newly generated medical data and broadcasting it to the blockchain network. In addition, the chain also stores relevant information such as access rights and access logs.

[0042] Except for special instructions, the medical data sharing blockchain used in the present invention refers to a specific type of blockchain, namely "public medical chain and medical data hash chain". Due to the large volume of medical data and the large amount of personal sensitive information involved, the method of storing the shared medical data hash value on the chain and encrypting the medical data details before transmitting it off the chain is generally adopted. The nodes of the medical data sharing blockchain are generally institutional nodes. After strict registration and review, the node scale of a provincial region may reach hundreds or thousands. Communication between nodes is mainly through health and medical special networks, financial special networks, judicial special networks or other Internet dedicated line access methods. Transactions are mainly high-frequency data sharing services, and the main data on the chain are medical data and related data hashes, encrypted medical data summaries, data sharing behavior records, etc. In terms of security, targeted authorization review, attribute encryption and other measures will be further taken on the basis of the national secret algorithm.

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

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

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

[0046] The following will introduce a cross-shard transaction processing method for medical data sharing provided by an embodiment of this specification in conjunction with the accompanying drawings.

[0047] Figure 1It is a flowchart of a cross-shard transaction processing method for medical data sharing provided by 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 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 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, refer to Figure 1 As shown, the method can be applied to a medical data sharing blockchain, wherein the medical data sharing blockchain includes at least beacon nodes located in different shards, and the method may include the following contents.

[0048] S101: The first beacon node in the sender shard broadcasts the cross-shard transaction received from the client to the second beacon node in the receiver shard, the first beacon node splits the cross-shard transaction into a first intra-shard transaction for the sender shard, and the second beacon node splits the cross-shard transaction into a second intra-shard transaction for the receiver shard;

[0049] S102: When the first beacon node receives the first block data generated according to the updated first intra-shard transaction, it generates a first transaction snapshot and sends the first transaction snapshot to the second beacon node. The second beacon node performs consistency verification according to the first transaction snapshot. When the consistency verification passes, it sends a message to the client indicating that the cross-shard transaction processing is completed.

[0050] Based on the above embodiments, beacon nodes with special cross-shard functions are set in each shard of the medical data sharing blockchain, which can decouple the cross-shard transaction process and split the cross-shard transaction into two intra-shard transactions (i.e., the first intra-shard transaction for the sender shard and the second intra-shard transaction for the receiver shard mentioned above). At the same time, the beacon node can generate corresponding transaction snapshots based on the corresponding block data, and synchronize transaction snapshots to the shards involved as needed, which can realize the inspection and recording of the atomicity of cross-shard transactions, and effectively reduce the state data transmission delay and storage pressure.

[0051] In some embodiments, the above-mentioned medical data sharing blockchain may include beacon nodes, committee nodes, and block nodes located in different shards. Both beacon nodes and block nodes can be voted by multiple committee nodes, and the voting selection method can be set according to actual needs. This specification does not specifically limit this. For example, beacon nodes can be selected from hardware performance (such as: CPU, memory, storage, etc.) and network performance (such as: stability, speed, etc.).

[0052] Among them, beacon nodes are: in each shard, a certain number of nodes are selected as beacon nodes, which are responsible for key cross-shard communication and coordination. The main task of the beacon node is to synchronize transaction blocks from other shards to ensure the consistency of the execution status of cross-shard transactions. In cross-shard transactions, the beacon node will synchronize the status updates of each shard to the entire network, so that all shards can understand the latest status changes of other shards. In addition, the beacon node also provides external verification services to ensure the correctness and security of cross-shard transactions and status synchronization, and to ensure the overall consistency and collaborative work of the system.

[0053] Committee nodes are responsible for transaction verification, block packaging, consensus and data storage in the shard, ensuring the legitimacy of transactions and the consistency of the ledger. They verify and confirm blocks through the consensus protocol in the shard to ensure the security and tamper-proofness of blockchain data. At the same time, regular committee nodes also assist beacon nodes in processing cross-shard transactions, forward cross-shard transaction requests, and update the status in the shard after the cross-shard transaction is completed, ensuring the atomicity of cross-shard transactions and the overall consistency of the system.

[0054] The block-producing node is a node selected from the committee nodes in the shard and is responsible for generating new blocks. It is selected from the committee through a weighted random algorithm to prevent malicious manipulation of the node. It collects transactions, packages valid transactions into blocks, calculates the validity of the blocks and submits them to the committee. Submits the block for verification by the committee and writes it to the chain after passing. Block-producing nodes usually need to have more powerful hardware performance and network speed to ensure fast block generation and data dissemination.

[0055] In some embodiments, the client sends a cross-shard transaction to the beacon node (Beacon node, i.e., the first beacon node) in the shard where it is located (i.e., the sender shard of the cross-shard transaction mentioned above). After receiving the cross-shard transaction, the first beacon node will broadcast the shard involved in the cross-shard transaction (i.e., the receiver shard of the cross-shard transaction mentioned above) to the beacon node of the corresponding shard (i.e., the second beacon node mentioned above). At the same time, the first beacon node can split the cross-shard transaction into the first intra-shard transaction for the sender, and the second beacon node can split the cross-shard transaction into the second intra-shard transaction for the receiver to shorten the delay of cross-shard transaction processing. After that, when the first block data is generated, the first beacon node generates a first transaction snapshot based on the first block data and sends it to the second beacon node. The second beacon node can perform consistency verification based on the first transaction snapshot to ensure the atomicity of the cross-shard transaction. After the consistency verification is passed, the cross-shard transaction processing is completed. At this time, a message that the cross-shard transaction processing is completed can be sent to the client to inform the client that the cross-shard processing has been completed.

[0056] In some embodiments, the medical data sharing blockchain may further include committee nodes located in different shards. Accordingly, after the first beacon node in the above S101 decomposes the cross-shard transaction into a first intra-shard transaction for the sender shard, and the second beacon node decomposes the cross-shard transaction into a second intra-shard transaction for the receiver shard, in specific implementation, the following may also be included:

[0057] The first beacon node broadcasts the first in-chip transaction to a first committee node in a sender shard, and the second beacon node broadcasts the second in-chip transaction to a second committee node in a receiver shard;

[0058] After receiving the first in-chip transaction, the first committee node adds the first in-chip transaction to the first transaction pool in the sending shard, and after receiving the second in-chip transaction, the second committee node adds the second in-chip transaction to the second transaction pool in the receiving shard.

[0059] In some embodiments, the first intra-slice transaction is added to a first transaction pool in a sender slice, and the second intra-slice transaction is added to a second transaction pool in a receiver slice. After that, in a specific implementation, the following may also be included:

[0060] The first committee node performs consensus verification on the first in-chip transaction in the first transaction pool and updates the first in-chip transaction after consensus verification, and the second committee node performs consensus verification on the second in-chip transaction in the second transaction pool and updates the second in-chip transaction after consensus verification.

[0061] In some embodiments, the consensus verification of the first in-chip transaction and the consensus verification of the second in-chip transaction are performed in parallel; and / or,

[0062] The updating of the first intra-chip transaction and the updating of the second intra-chip transaction are executed in parallel.

[0063] In some embodiments, after the first beacon node splits the cross-shard transaction into the first intra-shard transaction, and the second beacon node splits the cross-shard transaction into the second intra-shard transaction, the split intra-shard transaction can be broadcast to the node (i.e., committee node) where the corresponding shard is located, that is, the first intra-shard transaction can be broadcast to the first committee node, and the second intra-shard transaction can be broadcast to the second committee node. After receiving the corresponding intra-shard transaction, the corresponding committee node will add it to the corresponding transaction pool, that is, the first intra-shard transaction can be added to the first transaction pool in the sender shard, and the second intra-shard transaction can be added to the second transaction pool in the receiver shard. After that, the transaction can be executed normally according to the transaction packaging rules of the node to obtain the transaction processing result, wherein the execution of the transaction involves consensus verification, updating the transaction account data of the intra-shard transaction, and the transaction processing result is the result after the transaction account data is updated. That is, the first intra-chip transaction can be verified by consensus (in the blockchain, consensus on transactions refers to the process in which multiple nodes in the blockchain reach a consensus on the validity and order of transactions), and then the transaction account data of the first intra-chip transaction (such as transaction account status, account balance, etc.) can be updated, and the second intra-chip transaction can be verified by consensus, and then the transaction account data of the second intra-chip transaction can be updated. Among them, the first intra-chip transaction and the second intra-chip transaction are processed in parallel, that is, the consensus verification and update processes are executed in parallel.

[0064] Batch processing can be achieved by adding the corresponding intra-shard transactions to the corresponding transaction pool and then processing them. At the same time, the intra-shard transactions in the transaction pool can be processed sequentially according to the priority status of the transaction, which further optimizes the latency and improves the response speed of the blockchain system to high-priority transactions. By processing in parallel and independently without waiting for the processing results of the other party, the processing efficiency of cross-shard transactions can be effectively improved.

[0065] In some embodiments, the medical data sharing blockchain may further include block generation nodes located in different shards. Accordingly, before generating the first transaction snapshot in S102, the specific implementation may further include:

[0066] The first block producing node in the sender shard generates first block data according to the updated first intra-shard transaction, and sends the first block data to the first beacon node;

[0067] The second block producing node in the receiving shard generates second block data according to the updated second intra-shard transaction, and sends the second block data to the second beacon node.

[0068] In some embodiments, the second beacon node in S102 generates a second transaction snapshot when receiving the second block data; accordingly, the second beacon node in S102 performs consistency verification according to the first transaction snapshot, including:

[0069] The second beacon node performs consistency verification according to the first transaction snapshot and the second transaction snapshot, wherein the consistency verification includes verifying whether the blockchain heights to which the first transaction snapshot and the second transaction snapshot belong are consistent.

[0070] In some embodiments, the first block-producing node in the sender shard can obtain the processing result of the first committee node after executing the first intra-chip transaction from the first transaction pool, that is, the updated first intra-chip transaction, and then package it into a new block, that is, generate the first block data, and then link it to the end of the blockchain to achieve the chain operation. Similarly, the second block-producing node in the receiver shard can obtain the processing result of the second committee node after executing the second intra-chip transaction from the second transaction pool, that is, the updated second intra-chip transaction, and then package it into a new block, that is, generate the second block data, and then link it to the end of the blockchain to achieve the chain operation. The first beacon node can monitor the chain status of transactions in the sender shard, and can generate a first transaction snapshot or a first data snapshot (a set of folded and compressed block information) when the first block data is generated. The first transaction snapshot involves the chain status of the first intra-chip transaction, and then send the first transaction snapshot to the second beacon node.

[0071] The second beacon node can monitor the transaction chain status of the receiving shard, and can generate a second transaction snapshot or a second data snapshot when the second block data is generated. The second transaction snapshot involves the chain status of the transaction in the second shard. Afterwards, the second beacon node performs consistency verification based on the first transaction snapshot and the second transaction snapshot, that is, verifies whether the blockchain heights to which the first transaction snapshot and the second transaction snapshot belong are consistent, that is, whether they are chained at the same height, so as to judge the processing status of cross-shard transactions.

[0072] In some embodiments, the first transaction snapshot in S102 may include multiple ones. Accordingly, the second beacon node in S102 performs consistency verification according to the first transaction snapshot. In specific implementation, the following steps may also be included:

[0073] Extracting corresponding block headers from the plurality of first transaction snapshots, and verifying the block headers;

[0074] When the verification is passed, the second beacon node performs consistency verification according to any transaction snapshot among the multiple first transaction snapshots;

[0075] When the verification fails, the second beacon node selects a first transaction snapshot whose reception time is less than a preset time threshold from multiple first transaction snapshots for consistency verification.

[0076] In some embodiments, there may be more than one beacon node in a shard, such as: the first beacon node in the sender shard may include multiple, each first beacon node can generate a first transaction snapshot, that is, the number of first transaction snapshots can also be multiple. Under normal circumstances, the data snapshots generated by multiple beacon nodes from the same block are the same. In the process of consistency verification by the second beacon node, the block header to which it belongs can be extracted from multiple first transaction snapshots (the block header is an important component of each block in the blockchain, which stores the header information of the block, including the hash value of the previous block, the hash value of the current block body, and the timestamp, etc.), and then VRF verification (VRF is a verifiable random function, and its verification process is to use the VRF function to calculate and obtain an output result) to ensure data consistency. When the verification is passed, it means that multiple first transaction snapshots are from the same block. At this time, the second beacon node can select any transaction snapshot (any transaction snapshot) from multiple first transaction snapshots for consistency verification. When the verification fails, the first transaction snapshot (i.e., the latest received transaction snapshot) whose receiving time is less than the preset time threshold can be selected from multiple first transaction snapshots for consistency verification to ensure that the transaction snapshot is generated based on the latest block data. The preset time threshold can be set according to actual needs, and this specification does not specifically limit this.

[0077] In some embodiments, after the second beacon node in S102 performs consistency verification according to the first transaction snapshot, the specific implementation may further include:

[0078] When the consistency verification fails and exceeds the preset block height, the second beacon node sends a message to the client indicating that the cross-shard transaction processing has failed, and initiates a rollback transaction request to the sending shard where the first beacon node is located, so that the first beacon node can receive the cross-shard transaction again.

[0079] In some embodiments, when the consistency verification fails and exceeds a preset block height (a certain block height, which is set according to actual needs and is not specifically limited in this specification), it means that one of the intra-shard transactions has been uploaded to the chain, while the other intra-shard transaction has been unable to be uploaded to the chain, that is, the cross-shard transaction execution has failed. The second beacon node can send a message to the client indicating that the cross-shard transaction processing has failed, and initiate a rollback transaction request to the sending shard where the first beacon node is located (that is, return to the state where the cross-shard transaction has not been executed), so that the first beacon node re-receives the cross-shard transaction and re-processes the cross-shard transaction based on the above steps. This specification will not go into details.

[0080] If the consistency verification fails and the block height does not exceed the preset block height, it means that the cross-shard transaction has not been processed. You can continue to process the cross-shard transaction and then upload the transaction to the chain until the preset block height is exceeded. If the consistency verification passes, it means that the cross-shard transaction is processed and the transactions in both shards are uploaded to the chain at the same height.

[0081] By decoupling cross-shard transactions into two synchronous intra-shard transactions through beacon nodes, the efficiency of cross-shard transactions can be improved. At the same time, the data snapshot synchronization mechanism can ensure the atomicity of cross-shard transactions and ensure that intra-shard transactions can be processed in a timely manner, which is suitable for medical data sharing scenarios.

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

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

[0084] In a specific implementation scenario, see Figure 2 , Figure 3 As shown, the cross-shard transaction processing method for medical data sharing is explained.

[0085] There is a beacon node in each shard, which is elected by the consensus committee. Cross-shard transactions are initiated by the client and involve the status update of two shards, namely Figure 2 Shard A (Shard A, the shard where sender A1 is located) and Shard B (Shard B, the shard where receiver B1 is located). The client will send a cross-shard transaction AB to the beacon node A2 (Beacon node) in the sender A1 shard, such as Figure 2 After receiving the cross-shard transaction AB, the beacon node will broadcast the cross-shard transaction to the beacon node of the corresponding shard according to the shard involved in the transaction. That is, beacon node A2 in shard A broadcasts the cross-shard transaction AB to beacon node B2 in shard B.

[0086] At the same time, after receiving the original cross-shard transaction, the beacon node converts the cross-shard transaction into an intra-shard transaction, that is, Figure 3 The beacon node A2 in shard A converts the cross-shard transaction AB into an intra-shard transaction A12 (for the intra-shard transaction of shard A), and the beacon node B2 in shard B converts the cross-shard transaction AB into an intra-shard transaction B12 (for the intra-shard transaction of shard B). Then, the intra-shard transaction is broadcast to the nodes of the shard, that is, the corresponding committee nodes. After the nodes of the shard receive the intra-shard transaction, they will add the intra-shard transaction to the transaction pool, execute the transaction normally according to the transaction packaging rules of the node, and feedback the processing result (confirm) to the beacon node in the shard, that is Figure 3 Shard A in the shard will feed back the transaction processing result A123 within the shard to the beacon node A2 of shard A, and shard B will feed back the transaction processing result B123 within the shard to the beacon node B2 of shard B. The beacon nodes between different shards will share or synchronize the transaction consensus results within the shards to ensure data consistency. That is, the beacon node in shard A will generate multiple transaction snapshots and send them to the beacon node in shard B.

[0087] The beacon node in Shard A and the beacon node in Shard B will compare and verify the received transaction snapshots. If they are inconsistent and do not exceed the preset block height, it means that the cross-shard execution has not been completed, and they will continue to wait for the processing of the cross-shard transaction; if they are inconsistent and exceed a certain block height, the beacon node will initiate a rollback transaction within the shard and return to the state where the cross-shard transaction has not been executed; if they are consistent, the cross-shard transaction processing is completed.

[0088] Specifically, for example: Shard A has the first target beacon node, the second target beacon node, and the third target beacon node, and Shard B has the fourth target beacon node, the fifth target beacon node, and the sixth target beacon node. The user is in Shard A, and sends a cross-shard transaction to the first target beacon node of Shard A (to any beacon node of Shard A) (e.g., sharing medical data from Shard A to Shard B, Shard B receiving the shared data on the chain, Shard A recording the event of data sharing to Shard B, the original cross-shard transaction needs to be on the chain in Shard A and Shard B respectively, and the cross-shard transaction belongs to the evidence type transaction). The first target beacon node broadcasts the cross-shard transaction to the fourth target beacon node of Shard B. At the same time, after receiving the cross-shard transaction, the first target beacon node will convert it into an intra-shard transaction A12 for Shard A (for example: the intra-shard transaction for Shard A records data sharing events). After receiving the cross-shard transaction, the fourth target beacon node will convert it into an intra-shard transaction B12 for Shard B (for example: the intra-shard transaction for Shard B contains shared data, and consensus is reached on the shared data on the chain).

[0089] Broadcast the intra-slice transaction A12 to the shard node where Shard A is located, and broadcast the intra-slice transaction B12 to the shard node where Shard B is located. The shard node where Shard A is located adds the intra-slice transaction A12 to the transaction pool, and executes the transaction normally according to the transaction packaging rules of the node (for example: executing the transaction means updating the status data corresponding to the transaction account, such as saving contribution data, updating account balance, etc.), and the processing result is fed back to the first target beacon node of Shard A. The first target beacon node generates multiple transaction snapshots and shares them with the fourth target beacon node (for example: the first target beacon node in Shard A monitors the chain status of the transactions in the current Shard A, generates transaction snapshots and sends them to the fourth target beacon node).

[0090] The fourth target beacon node receives multiple transaction snapshots sent by the first target beacon node, and compares and verifies them with multiple transaction snapshots generated by itself to verify whether the transaction is on the same chain at the same height. If they are inconsistent and do not exceed the preset block height, it means that the cross-shard execution has not been completed, and the cross-shard transaction will continue to be processed; if they are inconsistent and exceed a certain block height, the beacon node will initiate a rollback transaction within the shard and return to the state where the cross-shard transaction has not been executed; if they are consistent, the cross-shard transaction processing is completed.

[0091] In each shard, a dedicated beacon node is deployed, and these nodes will regularly synchronize the latest cross-shard transaction snapshots of their respective shards. In this way, the consistency of the states between the shards in the network is ensured, avoiding data inconsistency problems caused by shard isolation. Figure 4 As shown, when the beacon node A2 in shard A where sender A1 is located obtains the latest block data from block Q1, it generates a cross-shard transaction snapshot K and then sends it to the beacon node B2 in shard B. In this way, when cross-shard transactions or smart contract executions are involved, other shards can obtain the required latest status data in a timely manner, ensuring the correctness and traceability of cross-shard operations.

[0092] This specification also provides a computer device, which can be found in Figure 5 The computer device structure diagram of a cross-shard transaction processing method for medical data sharing provided in an embodiment of this specification is shown, and the computer device may specifically include an input device 51, a processor 52, and a memory 53. Among them, the memory 53 is used to store processor executable instructions. When the processor 52 executes the instructions, the steps of the cross-shard transaction processing method for medical data sharing described in any of the above embodiments are implemented.

[0093] In this embodiment, the input device may specifically be one of the main devices for information exchange between the user and the computer system. The input device may include a keyboard, a mouse, a camera, a scanner, a light pen, a handwriting input board, a voice input device, etc.; the input device is used to input the original data and the program for processing these numbers into the computer. The input device can also obtain and receive data transmitted from other modules, units, and devices. The processor can be implemented in any appropriate manner. For example, the processor can take the form of a computer-readable medium, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, etc., such as a microprocessor or a processor and a computer-readable program code (such as software or firmware) that can be executed by the (micro) processor. The memory may specifically be a memory device used to store information in modern information technology. The memory 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 without a physical form is also called a memory, such as a RAM, a FIFO, etc.; in a system, a storage device with a physical form is also called a memory, such as a memory stick, a TF card, etc.

[0094] In this embodiment, the functions and effects specifically realized by the computer device can be explained in comparison with other embodiments and will not be described in detail here.

[0095] The present specification also provides a computer storage medium for a cross-shard transaction processing method for medical data sharing, wherein the computer storage medium stores computer program instructions, and when the computer program instructions are executed, the steps of the cross-shard transaction processing method for medical data sharing described in any of the above embodiments are implemented.

[0096] 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 can be used to store computer program instructions. The network communication unit can be an interface for network connection communication set in accordance with the standard specified by the communication protocol.

[0097] 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 embodiments and will not be repeated here.

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

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

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

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

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

[0103] 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 cross-shard transaction processing method for medical data sharing, characterized in that: Applied to a medical data sharing blockchain, the medical data sharing blockchain includes at least beacon nodes located in different shards, and the method includes: The first beacon node in the sender shard broadcasts the cross-shard transaction received from the client to the second beacon node in the receiver shard, the first beacon node splits the cross-shard transaction into a first intra-shard transaction for the sender shard, and the second beacon node splits the cross-shard transaction into a second intra-shard transaction for the receiver shard; When the first beacon node receives the first block data generated according to the updated first intra-shard transaction, it generates a first transaction snapshot and sends the first transaction snapshot to the second beacon node. The second beacon node performs consistency verification according to the first transaction snapshot. When the consistency verification passes, it sends a message to the client indicating that the cross-shard transaction processing is completed.

2. The method according to claim 1, characterized in that The medical data sharing blockchain also includes committee nodes located in different shards. Accordingly, the method further includes: The first beacon node broadcasts the first in-chip transaction to a first committee node in a sender shard, and the second beacon node broadcasts the second in-chip transaction to a second committee node in a receiver shard; After receiving the first in-chip transaction, the first committee node adds the first in-chip transaction to the first transaction pool in the sending shard, and after receiving the second in-chip transaction, the second committee node adds the second in-chip transaction to the second transaction pool in the receiving shard.

3. The method according to claim 2, characterized in that The method further comprises: The first committee node performs consensus verification on the first in-chip transaction in the first transaction pool and updates the first in-chip transaction after consensus verification, and the second committee node performs consensus verification on the second in-chip transaction in the second transaction pool and updates the second in-chip transaction after consensus verification.

4. The method according to claim 3, characterized in that The consensus verification of the first in-chip transaction and the consensus verification of the second in-chip transaction are performed in parallel; and / or, The updating of the first in-chip transaction and the updating of the second in-chip transaction are performed in parallel.

5. The method according to claim 1, characterized in that The medical data sharing blockchain also includes block production nodes located in different shards. Accordingly, the method further includes: The first block producing node in the sender shard generates first block data according to the updated first intra-shard transaction, and sends the first block data to the first beacon node; The second block producing node in the receiving shard generates second block data according to the updated second intra-shard transaction, and sends the second block data to the second beacon node.

6. The method according to claim 5, characterized in that When receiving the second block data, the second beacon node generates a second transaction snapshot; accordingly, the second beacon node performs consistency verification according to the first transaction snapshot, including: The second beacon node performs consistency verification according to the first transaction snapshot and the second transaction snapshot, wherein the consistency verification includes verifying whether the blockchain heights to which the first transaction snapshot and the second transaction snapshot belong are consistent.

7. The method according to claim 1, characterized in that The first transaction snapshot includes a plurality of items. Accordingly, the second beacon node performs consistency verification according to the first transaction snapshot, further comprising: Extracting corresponding block headers from the plurality of first transaction snapshots, and verifying the block headers; When the verification is passed, the second beacon node performs consistency verification according to any transaction snapshot among the multiple first transaction snapshots; When the verification fails, the second beacon node selects a first transaction snapshot whose reception time is less than a preset time threshold from multiple first transaction snapshots for consistency verification.

8. The method according to claim 1, characterized in that: The method further comprises: When the consistency verification fails and exceeds the preset block height, the second beacon node sends a message to the client indicating that the cross-shard transaction processing has failed, and initiates a rollback transaction request to the sending shard where the first beacon node is located, so that the first beacon node can receive the cross-shard transaction again.

9. An electronic device, characterized in that: include: A memory and a processor, wherein the processor and the memory are communicatively connected to each other, the memory stores computer instructions, and the processor implements the steps of the method according to any one of claims 1 to 8 by executing the computer instructions.

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