A Cross-Shard Transaction Processing Method for Medical Data Sharing

Abstract

The present invention discloses a cross-shard transaction processing method for medical data sharing, which is applied to a medical data sharing blockchain. The medical data sharing blockchain at least includes beacon nodes located in different shards. The method includes: a first beacon node located in a sender shard broadcasts a received cross-shard transaction to a second beacon node in a receiver shard. The first beacon node disassembles the cross-shard transaction into first in-shard transactions, and the second beacon node disassembles the cross-shard transaction into second in-shard transactions. When the first beacon node receives first block data, it generates a first transaction snapshot and sends the first transaction snapshot to the second beacon node. The second beacon node performs consistency verification based on the first transaction snapshot. When the consistency verification passes, it sends a message indicating that the cross-shard transaction processing is completed to the client. The present invention can improve the atomicity and sharing efficiency of cross-shard transactions simultaneously in scenarios such as the deposit tracing 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 increasingly widespread. However, traditional blockchain technology has scalability problems when dealing with large-scale medical data, specifically manifested as low throughput, high latency, and large storage pressure. To solve these problems, sharding technology has been introduced into the blockchain system to improve its scalability. Sharding technology divides the blockchain network into multiple independent shards, and each shard is responsible for processing part of the transactions, thereby achieving parallel processing and higher throughput. However, sharding technology introduces cross-shard transactions because different data is divided into different shards, and cross-shard transactions involve the interactive processing of data between multiple shards.

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

[0004] In response to 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 both sharing efficiency and transaction atomicity in the evidence storage and traceability scenarios of medical data sharing.

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

[0007] The first beacon node located in the sender's shard broadcasts the cross-shard transaction received from the client to the second beacon node in the receiver's shard. The first beacon node disassembles the cross-shard transaction into the first in-shard transaction for the sender's shard, and the second beacon node disassembles the cross-shard transaction into the second in-shard transaction for the receiver's shard;

[0008] When the first beacon node receives the first block data generated according to the updated first in-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 based on the first transaction snapshot. When the consistency verification passes, it sends a message indicating that the cross-shard transaction processing is completed to the client.

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

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

[0011] After receiving the first in-shard transaction, the first committee node adds the first in-shard transaction to the first transaction pool in the sender's shard. After receiving the second in-shard transaction, the second committee node adds the second in-shard transaction to the second transaction pool in the receiver's shard.

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

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

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

[0015] The update of the first in-shard transaction and the update of the second in-shard transaction are executed in parallel.

[0016] In some embodiments, the medical data sharing blockchain further includes block-producing nodes located in different shards. 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] In a third aspect, an embodiment of this specification further provides 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 cross-shard transaction processing method for medical data sharing are implemented.

[0029] 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. The medical data sharing blockchain at least includes beacon nodes located in different shards. A first beacon node located in the sending shard broadcasts a cross-shard transaction received from a client to a second beacon node in the receiving shard. The first beacon node disassembles the cross-shard transaction into a first intra-shard transaction for the sending shard, and the second beacon node disassembles the cross-shard transaction into a second intra-shard transaction for the receiving shard. When the first beacon node receives 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 indicating that the cross-shard transaction processing is completed to the client. This method is suitable for the cross-shard transaction mechanism in scenarios such as medical data sharing for evidence storage and traceability, and can improve both data sharing efficiency and transaction atomicity. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings. In the drawings:

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

[0032] Figure 2 is a schematic diagram of a cross-shard transaction provided by an embodiment of this specification;

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

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

[0035] Figure 5 is a schematic diagram of the structure of a computer device provided by an embodiment of this specification. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0036] 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 accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of this specification.

[0037] As mentioned above, the existing research on cross-shard transaction mechanisms mainly involves asset transfer scenarios and rarely involves scenarios such as medical data sharing for evidence storage and traceability. Evidence storage transactions have high requirements for sharing efficiency and transaction atomicity, while the existing cross-shard transaction mechanisms still have limitations in meeting these two requirements simultaneously.

[0038] For example: The split transaction method splits a cross-shard transaction into two or more independent intra-shard transactions. Although it improves performance, it is difficult to ensure transaction atomicity, and the exception rollback handling procedure is complex. The relay transaction method initiates a relay transaction after the intra-shard transaction in the shard where the transfer account is located is completed, sends the cross-shard transaction information to the receiving shard, and then the receiving shard completes the intra-shard transaction to achieve final atomicity. However, theoretically, it is difficult to monitor and control the execution of the receiving shard transaction, and the final atomicity cannot be guaranteed. Moreover, since the intra-shard transaction and the relay transaction are executed serially, the transaction parallelism is insufficient, resulting in an increase in transaction confirmation delay. The two-phase commit method, before processing a cross-shard transaction, a coordinator waits for other shards to be ready, which requires multiple rounds of consensus and is a relatively common cross-shard transaction mechanism in current sharded blockchains. However, its serial execution of cross-shard transactions and multiple rounds of consensus lead to an increase in transaction confirmation delay, and the single-point failure problem of the coordinator also needs attention. The deterministic sorting method cancels the coordinator role in the two-phase commit. Based on the sorting lock mechanism, it uses locked concurrent control to ensure the atomicity and serializability of transactions, and ensures transaction isolation by a specific transaction locking 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, and some transactions will abort because the cross-shard transaction fails to be successfully submitted for a long time, and the exception rollback handling procedure is complex.

[0039] To solve the above problems, 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. The medical data sharing blockchain includes at least beacon nodes located in different shards. A first beacon node located in the sender's shard broadcasts a cross-shard transaction received from a client to a second beacon node in the receiver's shard. The first beacon node disassembles the cross-shard transaction into a first intra-shard transaction for the sender's shard, and the second beacon node disassembles the cross-shard transaction into a second intra-shard transaction for the receiver's shard. When the first beacon node receives the first block data generated based on 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 based on the first transaction snapshot. When the consistency verification passes, it sends a message indicating that the cross-shard transaction processing is completed to the client. This method is suitable for the cross-shard transaction mechanism in scenarios such as medical data sharing for evidence preservation and traceability, and can improve both data sharing efficiency and transaction atomicity.

[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 data on the chain, the medical data sharing blockchain can be divided into three types: the private chain of medical institutions, the consortium chain of regional institutions, and the public medical chain. Among them, the private chain of medical institutions is operated by a single medical institution, and the data stored on the blockchain belongs to the medical institution. The blockchain infrastructure and the data stored on the chain of the consortium chain of regional institutions are shared by multiple medical institutions and other relevant organizations or individuals within the region. The blockchain platform and the data stored on the chain of the public medical chain are open to the public. The nodes on the medical data sharing blockchain are mainly institutional nodes, and they need to go through strict registration and review to access the network. Individual users generally rely on institutional nodes to apply for sharing services.

[0041] According to the different forms of the data on the chain, the medical data sharing blockchain can also be divided into three types: the original medical data chain, the encrypted medical data chain, and the medical data hash chain. Among them, the original medical data chain directly stores the plaintext of the shared medical data on the blockchain, and all users on the chain can access all the medical data stored on the blockchain. The encrypted medical data chain stores the ciphertext of the shared medical data on the blockchain. The medical data is encrypted by a secure asymmetric encryption algorithm using the public key of the receiver. The ciphertext, as well as the public key of the sender and the public key of the receiver, are packaged into a transaction and broadcast to the network, and only users with the corresponding private key can decrypt the record. The medical data hash chain stores the hash value of the shared medical data on the blockchain. The medical institution is responsible for generating and storing the medical data on its system, and at the same time calculates the hash value of the newly generated medical data and broadcasts it to the blockchain network. In addition, this chain also stores relevant information such as access permissions and access logs.

[0042] Unless otherwise specified, the medical data sharing blockchain applied 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 involvement of a large amount of personal sensitive information, generally, the hash values of the shared medical data are stored on the chain, and the detailed medical data is transmitted off-chain after encryption. The nodes of the medical data sharing blockchain are generally institutional nodes, which are strictly registered and audited to access the network. The scale of nodes in a provincial region may reach hundreds or thousands. The communication between nodes mainly accesses through the health and family planning private network, the financial private network, the judicial private network or other Internet dedicated line access methods. The transactions are mainly high-frequency data sharing services. The data uploaded to the chain mainly includes medical data and related data hashes, encrypted medical data summaries, data sharing behavior records, etc. In terms of security, on the basis of national cryptographic algorithms, targeted authorization audits, attribute encryption and other measures will be further taken.

[0043] It should be noted that the terms "first", "second", etc. in the description and claims of this application are used to distinguish similar objects, and do not necessarily describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances, so as to implement the embodiments of this application described here.

[0044] It should also be noted that the information and data related to users involved in the embodiments of the description of this application are all information and data authorized by users or fully authorized by relevant parties. And the processing of relevant data, such as collection, storage, use, processing, transmission, provision, disclosure and application, etc., all comply with relevant laws, regulations and standards, take necessary confidentiality measures, do not violate public order and good customs, 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 by the embodiments of this specification can be applied to an electronic device, and the electronic device can refer to an electronic device with data calculation, processing and storage capabilities. The electronic device can be a terminal such as a PC (Personal Computer, personal computer), a tablet computer, a smart phone, a wearable device, a smart 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 providing cloud computing services.

[0046] Next, a cross-shard transaction processing method for medical data sharing provided by the embodiments of this specification will be introduced with reference to the accompanying drawings.

[0047] Figure 1It is a schematic flowchart of a cross-shard transaction processing method provided by an embodiment of this specification for medical data sharing. Although this specification provides method operation steps or device structures as shown in the following embodiments or drawings, based on routine or non-creative labor, more or fewer operation steps or module units may be included in the method or device, or some may be combined. In 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 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, in an environment with parallel processors or multi-threaded processing, or even including a distributed processing environment or a server cluster environment). Specifically, when implementing, refer to Figure 1 As shown, the method can be applied to a medical data sharing blockchain, and the medical data sharing blockchain at least includes beacon nodes located in different shards. The method may include the following content.

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

[0049] S102: When the first beacon node receives the first block data generated based on 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 based on the first transaction snapshot. When the consistency verification passes, it sends a message indicating that the cross-shard transaction processing is completed to the client.

[0050] Based on the above embodiments, by setting beacon nodes with special cross-shard functions in each shard of the medical data sharing blockchain, the cross-shard transaction process can be decoupled, and the cross-shard transaction can be disassembled into two intra-shard transactions (that is, the first intra-shard transaction for the sender's shard and the second intra-shard transaction for the receiver's shard) mentioned above. At the same time, the beacon node can generate corresponding transaction snapshots based on the corresponding block data and synchronize the transaction snapshots to the involved shards as needed, which can achieve the atomicity check and recording of cross-shard transactions, effectively reducing 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, block-producing nodes, etc. located in different shards. The beacon nodes and block-producing nodes can both be elected by multiple committee nodes. The voting selection method can be set according to actual needs, and this specification does not make specific limitations in this regard. For example, beacon nodes can be selected from aspects such as hardware performance (such as CPU, memory, storage, etc.) and network performance (such as stability, speed, etc.).

[0052] Among them, the beacon node is: in each shard, a certain number of nodes are selected as beacon nodes, which are responsible for key cross-shard communication and coordination work. 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 state updates of each shard to the entire network, so that all shards can understand the latest state changes of other shards. In addition, the beacon node also provides verification services externally to ensure the correctness and security of cross-shard transactions and state synchronization, and to guarantee the overall consistency and collaborative work of the system.

[0053] The committee node is: mainly responsible for core responsibilities such as transaction verification, block packaging, consensus reaching, and data storage within the shard to ensure the legality of transactions within the shard and the consistency of the ledger. They verify and confirm blocks through the consensus protocol within the shard to ensure the security and anti-tampering of blockchain data. At the same time, regular committee nodes also assist beacon nodes in processing cross-shard transactions, forwarding cross-shard transaction requests, and updating the state within the shard after cross-shard transactions are completed to ensure the atomicity of cross-shard transactions and the overall consistency of the system.

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

[0055] In some embodiments, the client will send a cross-shard transaction to the beacon node (i.e., the first beacon node mentioned above) in its shard (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 shards involved in the cross-shard transaction (i.e., the receiver shard of the cross-shard transaction mentioned above) to the beacon nodes of the corresponding shards (i.e., the second beacon nodes mentioned above). At the same time, the first beacon node can disassemble the cross-shard transaction into the first intra-shard transaction for the sender, and the second beacon node disassembles the cross-shard transaction into the second intra-shard transaction for the receiver, so as to shorten the latency of cross-shard transaction processing. After that, when the first block data is generated, the first beacon node generates a first transaction snapshot according to 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 passes, the cross-shard transaction processing is completed. At this time, a message indicating 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 above-mentioned medical data sharing blockchain may further include committee nodes located in different shards. Correspondingly, after the first beacon node in the above-mentioned S101 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, in specific implementation, it may further include:

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

[0058] After receiving the first intra-shard transaction, the first committee node adds the first intra-shard transaction to the first transaction pool in the sender shard. After receiving the second intra-shard transaction, the second committee node adds the second intra-shard transaction to the second transaction pool in the receiver shard.

[0059] In some embodiments, after adding the first intra-shard transaction to the first transaction pool in the sender shard and adding the second intra-shard transaction to the second transaction pool in the receiver shard, in specific implementation, it may further include:

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

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

[0062] The update of the first in-shard transaction and the update of the second in-shard transaction are executed in parallel.

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

[0064] By adding the corresponding in-shard transactions to the corresponding transaction pools and then processing them, batch processing can be achieved. At the same time, according to the priority status of the transactions, the in-shard transactions in the transaction pools can be processed sequentially, further optimizing the latency and improving the response speed of the blockchain system to high-priority transactions. Through parallel and independent processing, 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 above-mentioned medical data sharing blockchain may further include block-producing nodes located in different shards. Correspondingly, before generating the first transaction snapshot in S102, in specific implementation, it may further include:

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

[0067] The second out-block node in the recipient shard generates second block data based on the updated second intra-shard transactions, and sends the second block data to the second beacon node.

[0068] In some embodiments, when the second beacon node in S102 above receives the second block data, it generates a second transaction snapshot; correspondingly, the second beacon node in S102 above performs consistency verification based on the first transaction snapshot, including:

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

[0070] In some embodiments, the first out-block node in the sender shard can obtain the processing result after the first committee node executes the first intra-shard transactions from the first transaction pool, that is, the updated first intra-shard transactions, and then package them into a new block, that is, generate first block data, and then link it to the tail of the blockchain to achieve the on-chain operation. Similarly, the second out-block node in the recipient shard can obtain the processing result after the second committee node executes the second intra-shard transactions from the second transaction pool, that is, the updated second intra-shard transactions, and then package them into a new block, that is, generate second block data, and then link it to the tail of the blockchain to achieve the on-chain operation. The first beacon node can monitor the on-chain situation 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 on-chain situation of the first intra-shard transactions, and then sends the first transaction snapshot to the second beacon node.

[0071] The second beacon node can monitor the on-chain situation of transactions in the recipient 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 on-chain situation of the second intra-shard transactions. After that, 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 the same, that is, whether they are on-chain at the same height, so as to judge the processing situation of cross-shard transactions.

[0072] In some embodiments, there may be multiple first transaction snapshots in S102 above. Correspondingly, when the second beacon node in S102 above performs consistency verification based on the first transaction snapshot, in specific implementation, it may further include:

[0073] Extract the block headers to which they belong from multiple first transaction snapshots, and verify the block headers.

[0074] When the verification is passed, the second beacon node performs consistency verification based on any one of the multiple first transaction snapshots;

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

[0076] In some embodiments, there can be more than one beacon node in a shard. For example, there can be multiple first beacon nodes in the sender shard, and each first beacon node can generate a first transaction snapshot, that is, the number of first transaction snapshots can also be multiple. Normally, the data snapshots generated by multiple beacon nodes from the same block are the same. During the process of the second beacon node performing consistency verification, the block headers to which they belong can be extracted from the multiple first transaction snapshots first (the block header is an important part of each block in the blockchain, storing 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 can be performed (VRF is a verifiable random function, and its verification process is to calculate using the VRF function to obtain an output result) to ensure data consistency. When the verification is passed, it means that the multiple first transaction snapshots all come from the same block. At this time, the second beacon node can select any one of the multiple first transaction snapshots (any transaction snapshot) for consistency verification. When the verification fails, a first transaction snapshot with a reception time less than the preset time threshold (that is, the latest received transaction snapshot) can be selected from the multiple first transaction snapshots for consistency verification to ensure that the transaction snapshot is generated based on the latest block data. Among them, the preset time threshold can be set according to actual needs, and this specification does not make specific limitations on this.

[0077] In some embodiments, after the second beacon node in S102 performs consistency verification based on the first transaction snapshot, in specific implementation, it can further include:

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

[0079] In some embodiments, when the consistency verification fails and the preset block height is exceeded (a certain block height, which is specifically set according to actual requirements and is not specifically limited in this specification), it means that one of the in-chip transactions has been chained, while the other in-chip transaction cannot be chained for a long time, that is, the cross-shard transaction execution fails. The second beacon node can send a message indicating the failure of cross-shard transaction processing to the client, 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 can receive the cross-shard transaction again and process the cross-shard transaction based on the above steps again. This is not elaborated in this specification.

[0080] When the consistency verification fails and the preset block height is not exceeded, it means that the cross-shard transaction has not been processed completely, and the cross-shard transaction can be continued to be processed, and then the transaction can be chained, etc., until the preset block height is exceeded. When the consistency verification passes, it means that the cross-shard transaction has been processed completely, and both of the two in-chip transactions are chained at the same height.

[0081] Decoupling the cross-shard transaction into two synchronous in-chip transactions through the beacon node can improve the efficiency of the cross-shard transaction. At the same time, adopting the data snapshot synchronization mechanism can ensure the atomicity of the cross-shard transaction, ensure that the in-chip transaction can be processed in time, and is applicable to the medical data sharing scenario.

[0082] Each embodiment in this specification is described in a progressive manner. The same or similar parts among the embodiments can be referred to each other, and the key points of each embodiment are the differences from other embodiments. Specifically, reference can be made to the description of the relevant processing related embodiments above, and details will not be repeated here.

[0083] The above is an explanation of this method. However, it should be noted that this specific embodiment is only for better explaining this application and describes 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 executed in a different order from that in the embodiment and still achieve the desired result. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be beneficial.

[0084] In a specific implementation scenario, refer to Figure 2 、 Figure 3 as shown, the cross-shard transaction processing method for medical data sharing is described.

[0085] There is a beacon node in each shard, and the beacon node is elected by the consensus committee. The cross-shard transaction is initiated by the client, and the cross-shard transaction involves the state update of two shards, that is,Figure 2 Shard A (the shard where sender A1 is located) and Shard B (the shard where receiver B1 is located) in Figure 2 Shard A in . After receiving the cross-shard transaction AB, the beacon node broadcasts the cross-shard transaction to the beacon nodes of the corresponding shards according to the shards involved in the transaction. That is, the beacon node A2 in Shard A broadcasts the cross-shard transaction AB to the beacon node B2 in Shard B.

[0086] Meanwhile, 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 in converts the cross-shard transaction AB into an intra-shard transaction A12 (intra-shard transaction for Shard A), and the beacon node B2 in Shard B converts the cross-shard transaction AB into an intra-shard transaction B12 (intra-shard transaction for Shard B). Then, the intra-shard transaction is broadcast to the nodes in the corresponding shard, that is, the corresponding committee nodes. After receiving the intra-shard transaction, the nodes in the corresponding shard will add the intra-shard transaction to the transaction pool, execute the transaction normally according to the transaction packaging rules of the nodes, and feedback the processing result (confirm) to the beacon node in this shard, that is, Figure 3 Shard A in feedbacks the intra-shard transaction processing result A123 to the beacon node A2 of Shard A, and Shard B feedbacks the intra-shard transaction processing result B123 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 with each other to ensure data consistency. That is, the beacon nodes in Shard A will send multiple transaction snapshots generated to the beacon nodes in Shard B.

[0087] The beacon nodes in Shard A and the beacon nodes 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 transaction has not been completed, and the cross-shard transaction processing will continue to wait; 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 a first target beacon node, a second target beacon node, and a third target beacon node, and Shard B has a fourth target beacon node, a fifth target beacon node, and a sixth target beacon node. The shard where the user is located is Shard A, and a cross-shard transaction is sent to the first target beacon node of Shard A (to any beacon node of Shard A) (such as: sharing medical data from Shard A to Shard B, Shard B receives the shared data and chains it, Shard A records the event of sharing data to Shard B. The original cross-shard transaction needs to be chained on Shard A and Shard B respectively. This cross-shard transaction belongs to the type of deposit certificate 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 the event of data sharing), and 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 the shared data, and the shared data is consensus-chained).

[0089] Broadcast the intra-shard transaction A12 to the shard nodes where Shard A is located, and broadcast the intra-shard transaction B12 to the shard nodes where Shard B is located. The shard nodes where Shard A is located add the intra-shard transaction A12 to the transaction pool and execute the transaction normally according to the transaction packaging rules of the nodes (for example: executing the transaction means updating the status data corresponding to the transaction account, such as saving contribution data, updating the 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 chaining situation of transactions in the current Shard A and generates transaction snapshots to send 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 transactions are chained at the same height. If they are inconsistent and do not exceed the preset block height, it means that the cross-shard has not been completed and executed, and the cross-shard transaction processing continues to wait; 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, dedicated beacon nodes are deployed, and these nodes regularly synchronize the latest cross-shard transaction snapshots of their respective shards. In this way, the consistency of the state is ensured among different shards in the network, avoiding data inconsistency problems caused by shard isolation. The data snapshot mechanism is as follows Figure 4 As shown, when the beacon node A2 in shard A where the sender A1 is located can obtain 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 state data in a timely manner, ensuring the correctness and traceability of cross-shard operations.

[0092] The embodiments of this specification also provide a computer device, which can be specifically referred to Figure 5 to the schematic structural diagram of the computer device composed of a cross-shard transaction processing method for medical data sharing provided in the embodiments of this specification. 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 instructions executable by the processor. When the processor 52 executes the instructions, it implements the steps of the cross-shard transaction processing method for medical data sharing described in any of the above embodiments.

[0093] In this embodiment, the input device may specifically be one of the main devices for information exchange between users and computer systems. 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 raw data and programs for processing these data into the computer. The input device can also obtain data transmitted from other modules, units, and devices. The processor can be implemented in any suitable manner. For example, the processor may take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program code (such as software or firmware) executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, etc. 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 without a physical form but with a storage function 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 implemented by the computer device can be explained in comparison with other embodiments, and will not be elaborated here.

[0095] In the embodiments of this specification, a computer storage medium for a cross-shard transaction processing method for medical data sharing is also provided. 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 above storage medium includes, but is not limited to, a random access memory (RAM), a read-only memory (ROM), a cache, a hard disk drive (HDD), or a memory card. The memory can be used to store computer program instructions. The network communication unit can be set according to the standards specified by the communication protocol and is used for the interface of network connection communication.

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

[0098] 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 among many execution orders of steps and does not represent the only execution order. When the actual device or client product is executed, it can be executed in the order of the method shown in the embodiments or the drawings or in parallel (for example, in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment). The term "including", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, product or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, product or device. Without further limitation, there is no exclusion of additional identical or equivalent elements in the process, method, product or device including the said elements. The words "first", "second", etc. are used to denote names and do not denote any particular order.

[0099] Those skilled in the art also know that, in addition to implementing the controller in the form of pure computer-readable program code, it is entirely possible to logically program the method steps so that the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. to achieve the same functions. Therefore, such a controller can be regarded as a hardware component, and the devices included therein for implementing various functions can also be regarded as the structures within the hardware component. Or even, the devices for implementing various functions can be regarded as either software modules for implementing the method or structures within the hardware component.

[0100] This specification can 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 can also be practiced in a distributed computing environment, where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.

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

[0102] The various embodiments in this specification are described in a progressive manner. For the same or similar parts among the various embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. This specification can be used in numerous 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, and so on.

[0103] Although this specification is depicted through embodiments, those of ordinary skill in the art know that this specification has many variations without departing from the spirit of this specification, and it is hoped that the appended claims will cover these variations without departing from the spirit of this 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, committee nodes, and block 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 receiving the first block data generated according to the updated first in-chip transaction, the first beacon node 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 and the generated second transaction snapshot. When the consistency verification passes, the second beacon node sends a message to the client indicating that the cross-shard transaction processing is completed; wherein, the first beacon node broadcasts the first in-chip transaction to the first committee node located in the sender shard, and the first committee node performs consensus verification on the first in-chip transaction and updates the first in-chip transaction after consensus verification; the first block-producing node located in the sender shard generates the first block data according to the updated first in-chip transaction, and sends the first block data to the first beacon node.

2. The method according to claim 1, characterized in that The method further comprises: The second beacon node broadcasts the second in-shard transaction to a second committee node located in the receiving 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 method further comprises: 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, and 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