Transaction processing method and blockchain

Abstract

A transaction processing method. The method can be applied to a blockchain. The blockchain may comprise: a first slice and a second slice. A first key is stored in the first slice, and a second key is stored in the second slice. The method may comprise: a first slice obtains a first transaction and a second transaction, the first transaction comprising a first key and a second key; the first slice forwards the first transaction to a second slice, packages the first transaction and the second transaction into a first block pertaining to the first slice, verifies the second transaction in the first block, and verifies the first transaction in the first block in collaboration with the second slice; and the second slice receives the first transaction forwarded by the first slice, packages the first transaction into a second block pertaining to the second slice, and verifies the first transaction in the second block in collaboration with the first slice. The method can improve the expansibility of a blockchain.

Description

A transaction processing method and blockchain Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a transaction processing method and blockchain. Background Art

[0002] Blockchain is a novel application model for computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. A blockchain is a distributed ledger composed of sequentially linked data blocks in chronological order, cryptographically guaranteed to be tamper-proof and unforgeable. Due to its decentralized, tamper-proof, and autonomous nature, blockchain is gaining increasing attention and application. However, blockchain currently suffers from poor scalability, making improving its scalability a pressing technical challenge.

[0003] Summary of the Invention

[0004] This application provides a transaction processing method, blockchain, node, computer storage medium and computer program product, which can improve the scalability of blockchain.

[0005] In a first aspect, the present application provides a transaction processing method that can be applied to a blockchain. The blockchain may include a first shard and a second shard. The first shard stores a first key, and the second shard stores a second key.

[0006] The method may include: a first shard obtains a first transaction and a second transaction, the first transaction including a first key and a second key; the first shard forwards the first transaction to a second shard, and packages the first transaction and the second transaction into a first block belonging to the first shard, verifies the second transaction in the first block, and cooperates with the second shard to verify the first transaction in the first block; the second shard receives the first transaction forwarded from the first shard, and packages the first transaction into a second block belonging to the second shard, and cooperates with the first shard to verify the first transaction in the second block.

[0007] In this way, each shard in the blockchain can have an independent consensus cluster and independent ledger node. The consensus cluster in a shard can forward transactions to other shards and package transactions related to the shard into blocks, which are then distributed to the ledger nodes in that shard. After receiving the blocks sent by the consensus cluster in its shard, the ledger nodes in the shard can verify the transactions within the blocks. When the keys contained in a transaction are stored on different shards, the different shards can collaborate on cross-shard verification of the transaction. This allows each shard to process only its own transactions. Furthermore, since each shard has its own independent consensus cluster, the transaction ordering service in the blockchain can be infinitely scaled horizontally. This approach achieves sharding of the blockchain at both the network and state levels, improving its scalability. For example, when a client submits a transaction to the first shard, the first shard will receive the client's transaction.

[0008] In one possible implementation, a blockchain includes a first endorsing node and a second endorsing node. A first transaction includes a first endorsement result, which includes a first key and a second key. A second transaction includes a second endorsement result, which includes the first key. The first transaction is obtained by a first client processing the first endorsement result and submitted by the first client to the first shard. The second transaction is obtained by a second client processing the second endorsement result and submitted by the second client to the first shard. Exemplarily, the first endorsing node may be, but is not limited to, the same as the second endorsing node; and the first client may be, but is not limited to, the same as the second client.

[0009] Before the first shard obtains the first transaction and the second transaction, the method may further include: the first endorsement node receives the first transaction request submitted by the first client, generates a first transaction read-write set based on the status data in the first shard and the status data in the second shard; and signs the first transaction read-write set to obtain a first endorsement result, and sends the first endorsement result to the first client, wherein the first transaction request is used to request an update of the first key and the second key; the second endorsement node receives the second transaction request submitted by the second client, generates a second transaction read-write set based on the status data in the first shard; and signs the second transaction read-write set to obtain a second endorsement result, and sends the second endorsement result to the second client, wherein the first transaction request is used to request an update of the first key. In this way, through cross-shard endorsement, one endorsement node can endorse a transaction involving different shards, thereby improving transaction processing efficiency. For example, when a transaction request requests the update of multiple different keys, the endorsing node can read the status data on these shards from the shards storing these keys respectively, and then update the corresponding keys based on the read status data to generate a transaction read-write set.

[0010] In a possible implementation, the first endorsement node and the second endorsement node are both nodes in the first shard, or at least one of the first endorsement node and the second endorsement node is a node other than a node in the first shard.

[0011] In one possible implementation, the blockchain is a consortium chain, which includes a first organization and a second organization. In the first shard, the result of the verification of the first transaction by the nodes affiliated with the first organization is a first result. In the second shard, the result of the verification of the first transaction by the nodes affiliated with the first organization is a second result. In the first shard, the result of the verification of the first transaction by the nodes affiliated with the second organization is a third result. In the second shard, the result of the verification of the first transaction by the nodes affiliated with the second organization is a fourth result. Exemplarily, the first result can be understood as the verification result of the first transaction by the nodes in the first organization in the first shard; the second result can be understood as the verification result of the first transaction by the nodes in the first organization in the second shard; the third result can be understood as the verification result of the first transaction by the nodes in the second organization in the first shard; and the fourth result can be understood as the verification result of the first transaction by the nodes in the second organization in the second shard.

[0012] The first shard and the second shard collaborate to verify the first transaction, which may include: the first shard sends a first result to the first coordination node, the second shard sends a second result to the first coordination node, the first shard and the second shard both receive a fifth result from the first coordination node, the fifth result is a verification result of the first result and the second result, the node in the first shard belonging to the first organization processes the first transaction based on the fifth result, the node in the second shard belonging to the first organization processes the first transaction based on the fifth result, and the first coordination node is a node other than the nodes in the first shard and the second shard; the first shard sends a third result to the second coordination node, the second shard sends a fourth result to the second coordination node, the first shard and the second shard both receive a sixth result from the second coordination node, the sixth result is a verification result of the third result and the fourth result, the node in the first shard belonging to the second organization processes the first transaction based on the sixth result, the node in the second shard belonging to the second organization processes the first transaction based on the sixth result, and the second coordination node is a node other than the nodes in the first shard and the second shard.

[0013] In this way, when the blockchain is a consortium chain, each organization has a coordination node. When cross-shard transaction verification is required, the cross-shard transaction verification can be performed within the organization through the coordination node within the organization, thus overcoming the cross-organization trust issue.

[0014] In one possible implementation, the blockchain is a consortium chain, which includes a first organization and a second organization. In the first shard, the result of the verification of the first transaction by the nodes affiliated with the first organization is a first result. In the second shard, the result of the verification of the first transaction by the nodes affiliated with the first organization is a second result. In the first shard, the result of the verification of the first transaction by the nodes affiliated with the second organization is a third result. In the second shard, the result of the verification of the first transaction by the nodes affiliated with the second organization is a fourth result. Exemplarily, the first result can be understood as the verification result of the first transaction by the nodes in the first organization in the first shard; the second result can be understood as the verification result of the first transaction by the nodes in the first organization in the second shard; the third result can be understood as the verification result of the first transaction by the nodes in the second organization in the first shard; and the fourth result can be understood as the verification result of the first transaction by the nodes in the second organization in the second shard.

[0015] The first shard and the second shard collaborate to verify the first transaction, which may include: the first shard sends the first result to the node in the second shard belonging to the first organization; the node in the second shard belonging to the first organization verifies the first result and the second result to obtain a fifth result; the second shard sends the fifth result to the node in the first shard belonging to the first organization; the node in the first shard belonging to the first organization processes the first transaction based on the fifth result, and the node in the second shard belonging to the first organization processes the first transaction based on the fifth result; the first shard sends the third result to the node in the second shard belonging to the second organization; the node in the second shard belonging to the second organization verifies the third result and the fourth result to obtain a sixth result; the second shard sends the sixth result to the node in the first shard belonging to the second organization; the node in the first shard belonging to the second organization processes the first transaction based on the sixth result, and the node in the second shard belonging to the second organization processes the first transaction based on the sixth result. For example, in the second shard, the node that verifies the first result and the second result can be understood as the coordination node in the first organization; the node that verifies the third result and the fourth result can be understood as the coordination node in the second organization.

[0016] In this way, when the blockchain is a consortium chain, each organization has a coordination node. When cross-shard transaction verification is required, the cross-shard transaction verification can be performed within the organization through the coordination node within the organization, thus overcoming the cross-organization trust issue.

[0017] In one possible implementation, the blockchain is a consortium chain, which includes a first organization and a second organization. In the first shard, the result of the verification of the first transaction by the nodes affiliated with the first organization is a first result. In the second shard, the result of the verification of the first transaction by the nodes affiliated with the first organization is a second result. In the first shard, the result of the verification of the first transaction by the nodes affiliated with the second organization is a third result. In the second shard, the result of the verification of the first transaction by the nodes affiliated with the second organization is a fourth result. Exemplarily, the first result can be understood as the verification result of the first transaction by the nodes in the first organization in the first shard; the second result can be understood as the verification result of the first transaction by the nodes in the first organization in the second shard; the third result can be understood as the verification result of the first transaction by the nodes in the second organization in the first shard; and the fourth result can be understood as the verification result of the first transaction by the nodes in the second organization in the second shard.

[0018] The first shard and the second shard collaborate to verify the first transaction, which may include: the first shard sends a first result to the coordination node, the second shard sends a second result to the coordination node, the first shard and the second shard both receive a fifth result from the coordination node, the fifth result being a verification result of the first and second results, the node in the first shard belonging to the first organization processes the first transaction based on the fifth result, and the node in the second shard belonging to the first organization processes the first transaction based on the fifth result, the first coordination node being a node other than the nodes in the first and second shards; the first shard sends a third result to the node in the second shard belonging to the second organization; the node in the second shard belonging to the second organization verifies the third result and the fourth result to obtain a sixth result; the second shard sends the sixth result to the node in the first shard belonging to the second organization; the node in the first shard belonging to the second organization processes the first transaction based on the sixth result, and the node in the second shard belonging to the second organization processes the first transaction based on the sixth result. Exemplarily, in the second shard, the node that verifies the third and fourth results can be understood as the coordination node in the second organization. Exemplarily, the first shard and the second shard collaborate to verify the first transaction, which can be understood as cross-shard transaction verification.

[0019] In this way, when the blockchain is a consortium chain, each organization has a coordination node. When cross-shard transaction verification is required, the cross-shard transaction verification can be performed within the organization through the coordination node within the organization, thus overcoming the cross-organization trust issue.

[0020] In one possible implementation, the blockchain includes a first deadlock resolution node and a second deadlock resolution node. The first deadlock resolution node belongs to a first organization, and the second deadlock resolution node belongs to a second organization. In other words, if the blockchain is a consortium chain, each organization in the consortium chain has a deadlock resolution node.

[0021] At this time, the method may further include: when the first target node obtains any one of the first result and the second result but does not obtain the other within the first time period, the first deadlock resolution node constructs a dependency graph related to the first transaction and in a convergent state, wherein the first target node is used to verify the first result and the second result, and the dependency graph includes at least one transaction that makes the first transaction unverifiable; when the second target node obtains any one of the third result and the fourth result but does not obtain the other within the first time period, the second deadlock resolution node constructs a dependency graph, and the second target node is used to verify the third result and the fourth result. Exemplarily, the first target node and the second target node can both be referred to as coordination nodes.

[0022] In this way, when a deadlock occurs, the deadlock resolution nodes in different organizations can construct the same dependency graph, so that the subsequent deadlock resolution results of different organizations are consistent.

[0023] In one possible implementation, the method further includes: a first deadlock resolution node marking at least one transaction included in the dependency graph constructed by the first deadlock resolution node as invalid based on a first rule; and a second deadlock resolution node marking at least one transaction included in the dependency graph constructed by the second deadlock resolution node as invalid based on the first rule. In this way, different deadlock resolution nodes use the same deadlock resolution rule, ensuring consistent deadlock resolution results across different organizations and thus guaranteeing transaction atomicity.

[0024] In one possible implementation, the first deadlock resolution node is a node in the first shard belonging to the first organization, or a node in the second shard belonging to the first organization, or a node outside the first shard and the second shard and belonging to the first organization.

[0025] The second deadlock resolution node is a node in the first shard belonging to the second organization, or a node in the second shard belonging to the second organization, or a node outside the first shard and the second shard and belonging to the second organization.

[0026] In one possible implementation, the blockchain is a consortium chain, which includes a first organization and a second organization. The first shard includes a first master node and a second master node. The first master node belongs to the first organization, and the second master node belongs to the second organization.

[0027] At this time, the method may also include: the first master node monitors the nodes in the second shard belonging to the first organization, and selects a third master node from the second shard, and the third master node belongs to the first organization; the second master node monitors the nodes in the second shard belonging to the second organization, and selects a fourth master node from the second shard, and the fourth master node belongs to the second organization; the third master node monitors the nodes in the first shard belonging to the first organization, and when an abnormality occurs in the first master node, selects a fifth master node from the first shard, and the fifth master node belongs to the first organization; the fourth master node monitors the nodes in the first shard belonging to the second organization, and when an abnormality occurs in the second master node, selects a sixth master node from the first shard, and the sixth master node belongs to the second organization.

[0028] This uses a round-robin sentinel mechanism to elect a leader, but without adding additional sentinel clusters. Instead, the master node in one organization in an adjacent shard acts as a sentinel for the nodes in that organization in the other shard, monitoring them. The sentinel master node then randomly selects or assigns a node from the corresponding organization in the other shard as the master. This simplifies the shard leader election process, allowing all shards to recover as long as at least one shard master node remains operational.

[0029] In one possible implementation, blockchain sharding is based on code edited by blockchain administrators. This allows blockchain administrators to quickly shard the blockchain based on their needs, simplifying the sharding process and increasing the flexibility and freedom of blockchain sharding.

[0030] In a second aspect, the present application provides a transaction processing method that can be applied to an endorsement node in a blockchain. The blockchain includes: a first shard and a second shard, wherein a first key is stored in the first shard and a second key is stored in the second shard. The method may include: receiving a transaction request from a client, wherein the transaction request is used to request an update of the first key and the second key; generating a transaction read-write set based on the status data in the first shard and the status data in the second shard; signing the transaction read-write set to obtain an endorsement result; and sending the endorsement result to the client. In this way, through cross-shard endorsement, an endorsement node can endorse a transaction involving different shards, thereby improving transaction processing efficiency. For example, when a transaction request is to request an update of multiple different keys, the endorsement node can read the status data on these shards from the shards storing these keys respectively, and then update the corresponding keys based on the read status data to generate a transaction read-write set.

[0031] On the third aspect, the present application provides a blockchain, which includes: a first shard and a second shard, wherein a first key is stored in the first shard and a second key is stored in the second shard. The first shard is responsible for obtaining the first transaction and the second transaction, and the first transaction contains the first key and the second key. The first shard is also responsible for forwarding the first transaction to the second shard, and packaging the first transaction and the second transaction into a first block belonging to the first shard, and verifying the second transaction in the first block, and cooperating with the second shard to verify the first transaction in the first block. The second shard is responsible for receiving the first transaction forwarded from the first shard, and packaging the first transaction into a second block belonging to the second shard, and cooperating with the first shard to verify the first transaction in the second block.

[0032] In one possible implementation, the blockchain includes a first endorsement node and a second endorsement node. The first transaction includes a first endorsement result, which includes a first key and a second key. The second transaction includes a second endorsement result, which includes the first key. The first transaction is obtained by processing the first endorsement result by a first client and submitted to the first shard by the first client. The second transaction is obtained by processing the second endorsement result by a second client and submitted to the first shard by the second client.

[0033] Before the first shard obtains the first and second transactions, the first endorsing node is responsible for receiving the first transaction request submitted by the first client, generating the first transaction read-write set based on the state data in the first shard and the state data in the second shard, and signing the first transaction read-write set to obtain a first endorsement result, and sending the first endorsement result to the first client, where the first transaction request is used to request an update of the first key and the second key. Before the first shard obtains the first and second transactions, the second endorsing node is responsible for receiving the second transaction request submitted by the second client, generating the second transaction read-write set based on the state data in the first shard, and signing the second transaction read-write set to obtain a second endorsement result, and sending the second endorsement result to the second client, where the first transaction request is used to request an update of the first key.

[0034] In a possible implementation, the first endorsement node and the second endorsement node are both nodes in the first shard, or at least one of the first endorsement node and the second endorsement node is a node other than a node in the first shard.

[0035] In one possible implementation, the blockchain is a consortium chain, which includes a first organization and a second organization. In a first shard, the result of the verification of the first transaction by the node affiliated with the first organization is a first result. In a second shard, the result of the verification of the first transaction by the node affiliated with the first organization is a second result. In the first shard, the result of the verification of the first transaction by the node affiliated with the second organization is a third result. In the second shard, the result of the verification of the first transaction by the node affiliated with the second organization is a fourth result.

[0036] When the first shard and the second shard collaborate to verify the first transaction: the first shard is responsible for sending the first result to the first coordination node, the second shard is responsible for sending the second result to the first coordination node, and the first shard and the second shard are both responsible for receiving the fifth result from the first coordination node, where the fifth result is a verification result of the first and second results. The nodes in the first shard that belong to the first organization are responsible for processing the first transaction based on the fifth result, and the nodes in the second shard that belong to the first organization are responsible for processing the first transaction based on the fifth result. The first coordination node is a node other than the nodes in the first and second shards; the first shard is responsible for sending the third result to the second coordination node, and the second shard is responsible for sending the fourth result to the second coordination node. The first shard and the second shard are both responsible for receiving the sixth result from the second coordination node, where the sixth result is a verification result of the third and fourth results. The nodes in the first shard that belong to the second organization are responsible for processing the first transaction based on the sixth result, and the nodes in the second shard that belong to the second organization are responsible for processing the first transaction based on the sixth result. The second coordination node is a node other than the nodes in the first and second shards.

[0037] In one possible implementation, the blockchain is a consortium chain, which includes a first organization and a second organization. In a first shard, the result of the verification of the first transaction by the node affiliated with the first organization is a first result. In a second shard, the result of the verification of the first transaction by the node affiliated with the first organization is a second result. In the first shard, the result of the verification of the first transaction by the node affiliated with the second organization is a third result. In the second shard, the result of the verification of the first transaction by the node affiliated with the second organization is a fourth result.

[0038] When the first shard and the second shard collaborate to verify the first transaction: the first shard is responsible for sending the first result to the node in the second shard belonging to the first organization; the node in the second shard belonging to the first organization is responsible for verifying the first result and the second result to obtain a fifth result; the second shard is responsible for sending the fifth result to the node in the first shard belonging to the first organization; the node in the first shard belonging to the first organization is responsible for processing the first transaction based on the fifth result, and the node in the second shard belonging to the first organization is responsible for processing the first transaction based on the fifth result; the first shard is responsible for sending the third result to the node in the second shard belonging to the second organization; the node in the second shard belonging to the second organization is responsible for verifying the third result and the fourth result to obtain a sixth result; the second shard is responsible for sending the sixth result to the node in the first shard belonging to the second organization; the node in the first shard belonging to the second organization is responsible for processing the first transaction based on the sixth result, and the node in the second shard belonging to the second organization is responsible for processing the first transaction based on the sixth result.

[0039] In one possible implementation, the blockchain is a consortium chain, which includes a first organization and a second organization. In a first shard, the result of the verification of the first transaction by the node affiliated with the first organization is a first result. In a second shard, the result of the verification of the first transaction by the node affiliated with the first organization is a second result. In the first shard, the result of the verification of the first transaction by the node affiliated with the second organization is a third result. In the second shard, the result of the verification of the first transaction by the node affiliated with the second organization is a fourth result.

[0040] When the first shard and the second shard collaborate to verify the first transaction: the first shard is responsible for sending the first result to the coordination node, the second shard is responsible for sending the second result to the coordination node, and both the first shard and the second shard are responsible for receiving the fifth result from the coordination node. The fifth result is a verification result of the first and second results. The nodes in the first shard belonging to the first organization are responsible for processing the first transaction based on the fifth result, and the nodes in the second shard belonging to the first organization are responsible for processing the first transaction based on the fifth result. The first coordination node is a node other than the nodes in the first and second shards; the first shard is responsible for sending the third result to the nodes in the second shard belonging to the second organization; the nodes in the second shard belonging to the second organization are responsible for verifying the third result and the fourth result to obtain a sixth result; the second shard is responsible for sending the sixth result to the nodes in the first shard belonging to the second organization; the nodes in the first shard belonging to the second organization are responsible for processing the first transaction based on the sixth result, and the nodes in the second shard belonging to the second organization are responsible for processing the first transaction based on the sixth result.

[0041] In one possible implementation, the blockchain includes a first deadlock resolution node and a second deadlock resolution node, where the first deadlock resolution node belongs to a first organization and the second deadlock resolution node belongs to a second organization.

[0042] When the first target node obtains any one of the first result and the second result but fails to obtain the other within the first time period, the first deadlock resolution node is responsible for constructing a dependency graph related to the first transaction and in a convergent state, wherein the first target node is used to verify the first result and the second result, and the dependency graph contains at least one transaction that makes the first transaction unverifiable; when the second target node obtains any one of the third result and the fourth result but fails to obtain the other within the first time period, the second deadlock resolution node is responsible for constructing the dependency graph, and the second target node is used to verify the third result and the fourth result.

[0043] In one possible implementation, the first deadlock resolution node is further responsible for marking at least one transaction included in the dependency graph constructed by the first deadlock resolution node as invalid based on the first rule. The second deadlock resolution node is further responsible for marking at least one transaction included in the dependency graph constructed by the second deadlock resolution node as invalid based on the first rule.

[0044] In one possible implementation, the first deadlock-resolution node is a node in the first shard belonging to the first organization, or a node in the second shard belonging to the first organization, or a node outside the first and second shards and belonging to the first organization. The second deadlock-resolution node is a node in the first shard belonging to the second organization, or a node in the second shard belonging to the second organization, or a node outside the first and second shards and belonging to the second organization.

[0045] In one possible implementation, the blockchain is a consortium chain, which includes a first organization and a second organization. The first shard includes a first master node and a second master node. The first master node belongs to the first organization, and the second master node belongs to the second organization.

[0046] The first master node is responsible for monitoring the nodes in the second shard belonging to the first organization, and selecting the third master node from the second shard, which belongs to the first organization; the second master node is responsible for monitoring the nodes in the second shard belonging to the second organization, and selecting the fourth master node from the second shard, which belongs to the second organization; the third master node is responsible for monitoring the nodes in the first shard belonging to the first organization, and if an abnormality occurs in the first master node, select the fifth master node from the first shard, which belongs to the first organization; the fourth master node is responsible for monitoring the nodes in the first shard belonging to the second organization, and if an abnormality occurs in the second master node, select the sixth master node from the first shard, which belongs to the second organization.

[0047] In one possible implementation, sharding in a blockchain is based on code divisions edited by the administrators of the blockchain.

[0048] In a fourth aspect, the present application provides a node deployed in a blockchain. The blockchain includes a first shard and a second shard, wherein the first shard stores a first key and the second shard stores a second key. The node includes a communication module responsible for receiving transaction requests from clients, wherein the transaction requests are used to request updates to the first and second keys; a processing module responsible for generating a transaction read-write set based on the status data in the first shard and the status data in the second shard; and signing the transaction read-write set to obtain an endorsement result; and a communication module responsible for sending the endorsement result to the client.

[0049] In a fifth aspect, the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method described in the first aspect or the third aspect.

[0050] In a sixth aspect, the present application provides a computer program product, which, when executed on a processor, enables the processor to execute the method described in the first aspect or the third aspect.

[0051] It can be understood that the beneficial effects of the third to sixth aspects mentioned above can be found in the relevant descriptions of the first and second aspects mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] FIG1 is a schematic diagram of an architecture for expanding a blockchain network based on state sharding provided in an embodiment of the present application;

[0053] FIG2 is a schematic diagram of a system architecture of a blockchain provided in an embodiment of the present application;

[0054] FIG3 is a schematic diagram of the structure of a blockchain provided in an embodiment of the present application;

[0055] FIG4 is a schematic diagram of the structure of another blockchain provided in an embodiment of the present application;

[0056] FIG5 is a schematic diagram of a working process of a blockchain provided by an embodiment of the present application;

[0057] FIG6 is a schematic diagram of the working process of another blockchain provided in an embodiment of the present application;

[0058] FIG7 is a schematic diagram of cross-shard transaction verification in a blockchain provided by an embodiment of the present application;

[0059] FIG8 is a schematic diagram of another cross-shard transaction verification in a blockchain provided by an embodiment of the present application;

[0060] FIG9 is a schematic diagram of a process of constructing a dependency graph in a blockchain provided by an embodiment of the present application;

[0061] FIG10 is a schematic diagram of a process for constructing a dependency graph in another blockchain provided in an embodiment of the present application;

[0062] FIG11 is a schematic diagram of a process for constructing a dependency graph in another blockchain provided in an embodiment of the present application;

[0063] Figure 12 is a schematic diagram of a sentinel leader election mechanism in a blockchain provided in an embodiment of the present application. DETAILED DESCRIPTION

[0064] The term "and / or" as used herein describes an association between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. The symbol " / " as used herein indicates that the related objects are in an "or" relationship, for example, A / B means either A or B.

[0065] The terms "first" and "second" in this specification and claims are used to distinguish different objects rather than to describe a specific order of objects. For example, "first response message" and "second response message" are used to distinguish different response messages rather than to describe a specific order of response messages.

[0066] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0067] In the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more, for example, multiple processing units means two or more processing units, etc.; multiple elements means two or more elements, etc.

[0068] First, some technical terms involved in the embodiments of this application are introduced.

[0069] (1) Blockchain

[0070] Blockchain is a distributed ledger composed of sequentially linked data blocks in chronological order, ensuring immutability and non-forgeability through cryptographic means. Broadly speaking, blockchain is an infrastructure platform that utilizes consensus algorithms to generate and update data, cryptography to ensure data security and immutability, and automated scripts to form smart contracts for programming and manipulation of data.

[0071] (2) Alliance Chain

[0072] A consortium blockchain is a distributed ledger system based on blockchain technology. Its participants are a group of organizations that have established a trusting and cooperative relationship. Unlike public blockchains, consortium chains have a limited number of participants and are jointly managed and maintained. Organizations in a consortium chain are businesses, government agencies, public organizations, and other entities participating in the blockchain business network. Each node in a consortium chain belongs to a specific organization.

[0073] (3) Nodes in the blockchain

[0074] A node in a blockchain can be any device, server, or equipment cluster with computing and processing capabilities.

[0075] (4) Endorsement Node

[0076] An endorsement node is a node in a blockchain that undertakes endorsement tasks. In a blockchain, there can be one or more endorsement nodes. In a consortium blockchain, each organization in the consortium chain has one or more endorsement nodes. For example, an endorsement task may include simulating the execution of a transaction proposal and then endorsing it.

[0077] (5) Ledger Node

[0078] Ledger nodes are primarily responsible for maintaining and storing the blockchain's ledger. In a blockchain, each ledger node holds a complete copy of the blockchain ledger, which contains multiple blocks and their corresponding state information. Some ledger nodes can also serve as endorsements within the blockchain; these nodes are also referred to as endorsing nodes. For example, ledger nodes can also be referred to as "nodes."

[0079] (6) Consensus Node

[0080] Consensus nodes are nodes in a blockchain that participate in the consensus algorithm. In a blockchain, consensus nodes are primarily responsible for executing the consensus algorithm to reach agreement on the transactions included in a new block and their order. A consensus algorithm is a protocol or mechanism that ensures all nodes agree on a consensus proposal, thereby maintaining the consistency of the entire blockchain. Consensus algorithms can include proof-of-work (PoW), proof-of-stake (PoS), proof-of-stake with delegated proof-of-stake (PoS with DPoS), and Byzantine fault tolerance (BFT).

[0081] (7) Master and Slave Nodes in the Blockchain

[0082] Both master nodes and slave nodes in a blockchain can be ledger nodes. The master node is primarily responsible for coordinating cross-shard transactions. Slave nodes are primarily responsible for synchronizing coordination results from the master node. For example, when Shards 1 and 2 require cross-shard verification of transaction T, the master node in Shard 1 can send the verification result of Shard 1 on transaction T to the coordinating node, and the master node in Shard 2 can send the verification result of Shard 2 on transaction T to the coordinating node. The coordinating node verifies these two verification results and sends them to the master nodes in Shards 1 and 2, respectively. The master node in Shard 1 can then synchronize the results it receives from the coordinating node to the slave nodes in Shard 1; similarly, the master node in Shard 2 can synchronize the results it receives from the coordinating node to the slave nodes in Shard 2.

[0083] (8) Block

[0084] In blockchain, a block refers to a data structure consisting of multiple transactions packaged together. A block consists of two parts: a block header and a block body. The block header includes the hash value of the previous block header, the timestamp of the block generation, the transaction root, the receipt root, and the state root. The transaction root is the root hash value of the transaction tree consisting of the multiple transactions included in the block; the receipt root is the root hash value of the receipt tree consisting of the receipts for these multiple transactions; and the state root is the root hash value of the state tree corresponding to the block.

[0085] (9) Smart Contracts

[0086] A smart contract is a contract on the blockchain that can be triggered by transactions. Smart contracts can be defined in code. Invoking a smart contract in Ethereum involves initiating a transaction to the smart contract address, enabling each node in the Ethereum network to execute the smart contract code in a distributed manner. It should be noted that in addition to user-created smart contracts, smart contracts can also be set up by the system in the genesis block. These contracts are generally referred to as system contracts. Generally, system contracts can set certain blockchain data structures, parameters, properties, and methods. Furthermore, accounts with system administrator privileges can create or modify system-level contracts (referred to as system contracts). These system contracts can be used to add data structures for different business operations to the blockchain.

[0087] (10) Sorting Service

[0088] The sorting service is a distributed cluster that is responsible for sorting transactions and reaching global consensus by running a consensus algorithm.

[0089] (11) Transaction read and write set

[0090] The transaction read-write set is a set of read and write data key values ​​generated by transactions in the blockchain after executing the business logic of the smart contract. The transaction read-write set can include a read set and a write set. The read set contains the key version, and the write set contains the latest value of the key. The key version is a unique identifier that makes each key non-repeated. There are many ways to implement it, such as using a monotonically increasing numerical representation. For example, an example of a read set can be<read key=“key1”,version=“1”> In this example, the key read is key1, and the version of key1 is 1; the example of write set can be<write key=“key1”,value=“V1”> , in this example, the latest value of key1 is V1.

[0091] (12) State data within a shard in the blockchain

[0092] Each blockchain shard has its own independent state data. Each shard records the value and version of the key it is responsible for, contract status, asset ownership, and other information. This state data changes continuously as new blocks are added to each shard. Within a shard's state data, the key, its version, and its value form a tuple (k, ver, val). In this tuple, k represents the key, ver represents the key version, and val represents the key value.

[0093] (12) Coordinator

[0094] The coordinator is used to ensure the atomicity of cross-shard transactions. Each transaction can have a different coordinator based on the coordinator selection rules. The coordinator can be hosted by the blockchain business node or a separate node. For example, the coordinator can also be called a "coordinating node."

[0095] (13) Deadlock Resolver

[0096] The deadlock handler is used to detect and resolve deadlocks between cross-shard transactions. This task is typically handled by the master node of a particular shard, but can also be handled by other nodes. For example, the deadlock handler is also referred to as the "deadlock resolution node."

[0097] (14) Transactions in the blockchain

[0098] A blockchain transaction refers to a unit of work that is executed and recorded within the blockchain. A transaction typically includes a sender (From), a receiver (To), and a data field (Data). In the case of a transfer, the From field indicates the address of the account initiating the transaction (i.e., initiating a transfer to another account), the To field indicates the address of the account receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0099] Next, the technical solution provided by this application is introduced.

[0100] Currently, a significant factor limiting the large-scale application of blockchain technology is performance, specifically throughput, which is generally measured by transactions per second (TPS). Developers have proposed various solutions to increase throughput, a process known as "scaling." Scaling technologies can be categorized as on-chain and off-chain. On-chain scaling typically includes block size expansion, Segregated Witness (SegWit), sharding, and consensus layer improvements. Off-chain scaling typically involves state channels, sidechains, and off-chain computation.

[0101] Sharding technology is a solution for on-chain capacity expansion. The concept of sharding originates from the database field, originally referring to the horizontal partitioning of database data (assigning different rows of a table to different partitions). Each shard is stored on a separate database server instance to distribute the load. The basic idea of ​​blockchain sharding is to divide the nodes in the blockchain network into several relatively independent sub-networks, each containing a subset of nodes. A sub-network is also known as a shard. A single shard can handle its own transactions or even store only a portion of the network state. With multiple shards processing transactions in parallel, the throughput of the entire blockchain network can theoretically increase.

[0102] Sharding technology can be categorized into three types based on different sharding mechanisms: network sharding, transaction sharding, and state sharding. Network sharding is a commonly used sharding method. For example, it divides the entire blockchain network into multiple subnetworks, or shards. Transaction sharding distributes transactions to different shards based on certain rules, assigning transactions to the same shard for processing. State sharding partitions the entire storage area, allowing different shards to store different portions. Each node is responsible for storing only its own shard data, rather than the entire blockchain state. State sharding can address storage bottlenecks. State sharding distributes blockchain data across multiple nodes, allowing each node to store only the data from one shard, thereby increasing the storage capacity of the entire blockchain network. Furthermore, different shards can process their own shard data in parallel, improving data processing speed and concurrency. Therefore, state sharding not only expands the storage capacity of a blockchain network, but also increases its throughput.

[0103] For example, Figure 1 illustrates an architecture for scaling a blockchain network based on state sharding. As shown in Figure 1, the blockchain network may include an ordering service cluster and two shards. Of course, the blockchain network can also be divided into three or more shards, which is not a limitation here. The ordering service cluster primarily consists of consensus nodes, also referred to as a "consensus cluster." Each shard includes at least one ledger node, and different shards store different keys. In Figure 1, three different clients submit transactions to the ordering service cluster. The ordering service cluster executes and / or orders these transactions, and packages them into blocks. When packaging blocks, the ordering service cluster divides transactions involving different shards into subblocks based on the shards involved, and then sends the corresponding subblocks to the corresponding shards. When a transaction involves multiple shards, the transaction is packaged into different subblocks and sent to the corresponding shards. For example, the transaction submitted by Client 1 in Figure 1 involves both Shard 1 and Shard 2. Therefore, the transaction is packaged into two blocks and sent to Shard 1 and Shard 2. Furthermore, when a transaction involves multiple shards, different shards can simultaneously verify the transaction, i.e., perform cross-shard transaction verification. For example, when a shard stores the key included in a transaction, the transaction is considered to involve that shard. While this sharding architecture can expand the storage capacity of the blockchain network, it uses a global ordering consensus, which sorts all transactions through a single ordering service cluster. This makes the ordering service unscalable, and therefore has an upper limit on its performance. This shortcoming can lead to bottlenecks in blockchain performance.

[0104] In view of this, an embodiment of the present application provides a blockchain, which includes multiple shards, each of which has a sorting service cluster (that is, each shard contains a consensus cluster) and at least one ledger node. When a client submits a transaction, it can submit it to any shard, and different shards only process transactions involving themselves. When a transaction obtained by a shard does not involve itself, the shard can forward the transaction to the shard involved in the transaction, so that the specific transaction can be sorted and processed by the sorting service cluster in the specific shard. In this blockchain, each shard has an independent sorting service cluster (that is, it has an independent consensus cluster), so its sorting service performance can theoretically be infinitely expanded horizontally.

[0105] For example, Figure 2 shows a schematic diagram of the system architecture of a blockchain provided by an embodiment of the present application. As shown in Figure 2, the system architecture of the blockchain mainly includes: application layer, interface layer, sharding extension layer, core function layer and infrastructure layer.

[0106] The application layer primarily refers to applications or services built on top of the blockchain infrastructure. The application layer can leverage smart contract functionality to implement automated business logic and contract execution.

[0107] The interface layer is mainly used to provide an interface for users to interact with the blockchain, process data, and perform business operations.

[0108] The sharding extension layer primarily provides services for sharding blockchains to achieve scalability. Exemplary services provided by the sharding extension layer include sharding strategy management, shard management, cross-shard distribution, intra-shard processing, and cross-shard coordination.

[0109] The sharding strategy management function primarily provides users with sharding methods to predefine and manage the mapping between transaction keys and shards. The sharding strategy management function offers the following methods: a) The default method, which uses the transaction key as input to generate a hash value. This hash value is used to assign each transaction to the shard corresponding to the transaction key for processing. b) A custom method, which allows administrators to flexibly predefine the mapping between transaction keys and shards based on specific transaction logic. Based on this predefined mapping between keys and shards, transactions can be assigned to the shard corresponding to the transaction key for processing. For example, the sharding strategy management function allows blockchain administrators to implement sharding using custom code.

[0110] Shard management primarily provides capabilities for creating, deploying, and deleting shards. Shard creation involves configuring the number of shards to create and the number of nodes within each shard. Shard deployment involves configuring and initializing the peer-to-peer network, consensus mechanism, storage services, smart contracts, and contract execution environment for each shard. Shard deletion involves operations such as deleting shards, migrating data across shards, and reclaiming resources. In other words, shard management enables management of nodes within a shard and scaling shards.

[0111] The cross-shard distribution function primarily provides cross-shard data exchange, transaction distribution, and data verification exchange capabilities. Providing data exchange refers to the ability to obtain the state data required for transactions across shards during the endorsement phase. Providing transaction distribution refers to the ability to distribute transactions to the corresponding shards for processing during the consensus phase. Providing data verification exchange refers to the ability to obtain cross-shard state data verification records during the verification phase.

[0112] The intra-shard processing function is mainly responsible for intra-shard transaction execution, block consensus, data verification, data synchronization and data storage.

[0113] Cross-shard coordination is primarily responsible for providing cross-shard transaction verification capabilities. After sharding a blockchain, cross-shard transaction verification needs to be considered between shards. A coordination mechanism is needed between participating shards to facilitate atomic transaction commits and rollbacks to ensure data consistency. Therefore, cross-shard coordination requires the following capabilities: a) a decentralized coordinator and b) an atomic commit protocol. Regarding the decentralized coordinator, distributed ledger technology, especially consortium blockchains, differs from traditional distributed transaction processing systems in that a centralized coordinator cannot coordinate cross-shard transactions on behalf of all participants. Due to trust issues across organizations, each participant requires its own coordinator to assist in transaction coordination. Therefore, each participant can either deploy a dedicated coordinator for all shards or temporarily select a node from within a shard to serve as the coordinator for cross-shard transactions. Regarding the atomic commit protocol, to maintain the atomicity and consistency of the state data involved in cross-shard transactions, the coordination mechanism requires an atomic commit protocol to ensure the complete commit or rollback of cross-shard transactions. For example, the two-phase commit protocol is an atomic commit protocol that is suitable for a variety of use cases and can be used in many cases of temporary system failures.

[0114] The core functional layer is primarily used to provide the core services of the blockchain. For example, core services may include consensus mechanism services, ledger record services, cryptographic services, smart contract services, summary services, digital signature services, and timing services.

[0115] The infrastructure layer is mainly used to provide the resource environment required for blockchain operation.

[0116] Next, based on the system architecture of the blockchain shown in Figure 2, the structure of the blockchain provided in the embodiment of the present application is introduced.

[0117] For example, FIG3 shows a schematic diagram of the structure of a blockchain provided by an embodiment of the present application. As shown in FIG3 , the blockchain may include: multiple consensus clusters and multiple ledger nodes, and the blockchain network is divided into multiple shards, with different keys stored in different shards. For example, shard 1 may store key 1, shard 2 may store key 2, shard n may store key n, and so on. Each consensus cluster contains multiple consensus nodes. Different consensus clusters are deployed in different shards, that is, each shard has an independent consensus cluster. In addition, each shard has at least one ledger node. The consensus cluster in a shard can be responsible for packaging a transaction submitted by a client into a block and sending the block to the ledger node in the shard when the key included in the transaction is stored in the shard; and for forwarding the transaction to a shard that stores the key included in the transaction, such as forwarding it to a consensus cluster in another shard, when the key included in the transaction submitted by the client is not stored in the shard. For example, if key1 is stored in shard 1 and key2 is stored in shard 2, then when a client submits a transaction to shard 1 and the transaction only includes key1, the consensus cluster in shard 1 can package the transaction into a block and forward it to the ledger node in shard 1. When a client submits a transaction to shard 1 and the transaction only includes key2, the consensus cluster in shard 1 can forward the transaction to shard 2. When a client submits a transaction to shard 1 and the transaction only includes keys 1 and 2, the consensus cluster in shard 1 can package the transaction into a block and forward it to the ledger node in shard 1, and then forward it to shard 2. After receiving the block sent by the consensus cluster in the shard, the ledger node in the shard can process the transactions in the block, such as verifying the transactions in the block, updating the state data in the shard, etc. For example, the shards in a blockchain can be divided based on code edited by the blockchain administrator.

[0118] In Figure 3, within a shard, different nodes can interact and communicate through, but are not limited to, peer-to-peer (P2P) communication. Different shards, and master nodes within each shard, can also interact and communicate through P2P communication to achieve cross-shard interaction and communication. The nodes in each shard can be any device, server, or cluster of devices with computing and processing capabilities. Nodes in a shard can generate the same state within that shard by executing the same transaction, and each node in a shard can store the same state database. Nodes in different shards can generate different states within the corresponding shard by executing different transactions, and nodes in different shards can store different state databases.

[0119] For example, FIG4 shows a schematic diagram of the structure of another blockchain provided by an embodiment of the present application. In FIG4 , the blockchain is a consortium chain. As shown in FIG4 , the consortium chain is also divided into multiple shards, with different keys stored in different shards, and each shard has an independent consensus cluster. In addition, each shard contains ledger nodes belonging to multiple different organizations. In a consortium chain, the consensus cluster in a shard can distribute its packaged blocks to the ledger nodes within each organization contained in the shard. Similar to the blockchain shown in FIG3 , in the consortium chain shown in FIG4 , the consensus cluster in a shard can be responsible for packaging the transaction submitted by the client into a block and sending the block to the ledger node in the shard when the key contained in the transaction is stored in the shard; and for forwarding the transaction to the shard that stores the key contained in the transaction, such as forwarding it to the consensus cluster in another shard, when the key contained in the transaction submitted by the client is not stored in the shard.

[0120] To facilitate understanding of the blockchain structure shown in Figures 3 and 4, the following describes the blockchain's operation under the "execute-order-validate (EOV)" architecture. It should be understood that the operation of blockchains under other architectures (such as the "OV architecture") can be referenced to the operation of blockchains under the EOV architecture described here, and will not be further elaborated here.

[0121] For example, Figure 5 illustrates a schematic diagram of the blockchain operation process provided by an embodiment of the present application. In Figure 5, shard 1 stores key1 of client 1, and the transaction initiated by client 1 does not involve other shards (i.e., the transaction does not include keys other than key1), for example, a transaction involving a certificate. As shown in Figure 5 (A), client 1 can initiate a transaction request to an endorsing node in the blockchain. This transaction request represents an update request for key1. Since this transaction request is only for an update of key1, the transaction corresponding to this transaction request does not involve other shards. Therefore, the endorsing node can read the state data in shard 1 and pre-execute the update operation for key1 to generate a transaction read-write set. In other words, the endorsing node can generate a transaction read-write set based on the state data in shard 1. Both the read set and the write set of this transaction read-write set include key1. The endorsing node can then sign the generated transaction read-write set and send the signed transaction read-write set to client 1. For example, the signed transaction read / write set can also be referred to as the "endorsement result." This endorsement result includes key1. Client 1 can then package the endorsement result returned by the endorsing node into a transaction and send it to Shard 1. Shard 1 then receives the transaction. The consensus cluster in Shard 1 can then parse the transaction and determine that it only contains key1. Since the transaction does not contain other keys, the consensus cluster in Shard 1 does not need to forward the transaction. Instead, the consensus cluster in Shard 1 can package the transaction into a block and distribute the block to the ledger nodes in Shard 1. After receiving the block, the ledger nodes in Shard 1 can verify the transactions in the block. This verification involves first verifying the signatures and endorsement policies of the block and transaction. Once these verifications are successful, the client verifies whether the version of key1 in the read set within the transaction read / write set is consistent with the version of key1 stored in Shard 1. If they are consistent, the transaction is considered valid. If not, the transaction is considered invalid. Afterwards, the ledger node submits the verified transaction. That is, if the transaction is determined to be valid, the shard status data will be updated based on the write set in the transaction read-write set. If the transaction is determined to be invalid, the shard status data will not be updated based on the write set in the transaction read-write set, but the illegal transaction can be recorded in their respective databases. At the same time, the ledger node can store the block in the blockchain associated with shard 1. At this time, the new block B is added to the blockchain. i+2. Exemplarily, when the transaction is determined to be valid, the value of key1 in shard 1's state data can be updated to the value in the write set, and the version of key1 can be updated. For example, if the version of key1 before the update was 1, the version of key1 after the update can be 2. Exemplarily, in Figure 5 (A), when the blockchain is a consortium chain, the endorsement node communicating with client1 can belong to the organization to which client1, which initiated the transaction proposal, belongs. In addition, the endorsement node communicating with client1 can be divided into shard 1 or other shards, and this is not limited here. In some embodiments, the actions performed by nodes in a shard can be understood as actions performed by the shard. For example, the verification of transactions in a block by a ledger node in a shard can be understood as the verification of transactions in the block by the shard. In some embodiments, shard 1 can be referred to as the first shard, shard 2 can be referred to as the second shard, key1 can be referred to as the first key, and key2 can be referred to as the second key.

[0122] Alternatively, as shown in Figure 5(B), client 1 can also package the endorsement results returned by the endorsing node into a transaction and send it to another shard, such as Shard 2. The consensus cluster in Shard 2 can then analyze the transaction and determine that it only contains key 1. Therefore, Shard 2 can forward the transaction to Shard 1 without processing it. Finally, the transaction can be processed in Shard 1, as described in Figure 5(A) and will not be repeated here. In some embodiments, when using the OV architecture, client 1 initiates a transaction directly to the shard without proposing a transaction to the endorsing node. In this case, the consensus cluster in the shard can analyze the transaction based on shard rules to determine the shard involved and choose whether to execute it itself or forward it to another shard. In some embodiments, the endorsing node described in Figure 5 can be a node in Shard 1 or a node in another shard, without limitation.

[0123] For example, Figure 6 illustrates a schematic diagram of the operation process of another blockchain provided by an embodiment of the present application. In Figure 6, different keys are stored in different shards, and key1 of user A corresponding to client 1 is stored in shard 1, while key2 of user B is stored in shard 2. A transaction initiated by client 1 includes key1 and key2, for example, a transfer transaction. As shown in Figure 6, when user A transfers money to user B, client 1 can initiate a transaction request to an endorsing node in shard 1 (or, of course, an endorsing node in another shard). This transaction request can be used to represent an update request for key1 and key2. After receiving the transaction request, the endorsing node in shard 1 can parse the transaction request to determine that operations on key1 and key2 are required. At this point, the endorsing node can read the state data in shard 1 and the state data in shard 2, respectively, and pre-execute the update operations on key1 and key2 to generate a transaction read-write set. In other words, the endorsing node can generate a transaction read-write set based on the state data in shard 1 and the state data in shard 2. Both the read and write sets of this transaction read / write set include key1 and key2. When reading the state data in shard 2, the endorsing node in shard 1 may, but is not limited to, communicate with the endorsing node in shard 2 to obtain the state data. Subsequently, the endorsing node in shard 1 may sign the generated transaction read / write set and send the signed transaction read / write set to client 1. For example, the signed transaction read / write set may also be referred to as an "endorsement result." This endorsement result includes key1 and key2. Client 1 may then package the endorsement result returned by the endorsing node into a transaction and send it to shard 1. Shard 1 then receives the transaction. The consensus cluster in shard 1 then analyzes the transaction and determines that key1 and key2 are included in the transaction. The consensus cluster in shard 1 may then forward the transaction to shard 2. The consensus cluster in shard 1 may also package the transaction into a block. Afterwards, the consensus cluster in Shard 1 can distribute the blocks it generates to the ledger nodes in Shard 1. Shard 2 can receive transactions forwarded from Shard 1 and, through the consensus cluster in Shard 2, package the transactions into blocks. Afterwards, the consensus cluster in Shard 2 can distribute the blocks it generates to the ledger nodes in Shard 2. It should be understood that in Figure 6, when client 1 sends a transaction, it can also send the transaction to shards other than Shard 1. Then, shards other than Shard 1 forward the transaction to Shard 1 and / or Shard 2. See the description in (B) of Figure 4 above for details, which will not be repeated here.

[0124] After receiving a new block, the ledger nodes in Shard 1 and Shard 2 can verify the transactions in their respective blocks. This verification involves first verifying the signatures and endorsement policies of the block and transaction. Once these verifications are successful, the nodes then verify whether the key1 included in the transaction is consistent with the version of key1 stored in Shard 1, and also verify whether the version of key2 is consistent with the version of key2 stored in Shard 2. Because this transfer transaction includes key1 and key2, the ledger nodes in Shard 1 and Shard 2 need to perform cross-shard verification when verifying this transaction to ensure the atomicity of the transaction, that is, to ensure the consistency and integrity of the transaction. In other words, when a transaction includes key1 and key2, Shard 1 and Shard 2 need to collaboratively verify the transaction.

[0125] When Shard 1 and Shard 2 collaborate on transaction verification, if the blockchain structure is as shown in Figure 3, Shard 1 and Shard 2 can collaborate on cross-shard transaction verification using a two-phase commit protocol (2PC). Specifically, a ledger node in Shard 1 (such as a master node) can send its verification result for key1 to the coordinating node. Simultaneously, a ledger node in Shard 2 can send its verification result for key2 to the coordinating node. In other words, Shard 1 can send its verification result for key1 to the coordinating node, and Shard 2 can send its verification result for key2 to the coordinating node. For example, a shard's verification result for a key in a transaction can be understood as the shard's verification result for the transaction. The coordinating node can be, but is not limited to, a node in the blockchain. The coordinating node can then aggregate and verify these two verification results. If the key1 verification result indicates that the version of key1 included in the transaction is consistent with the version of key1 stored in Shard 1, and the key2 verification result indicates that the version of key2 included in the transaction is consistent with the version of key2 stored in Shard 2, then the coordinator node may consider the transaction valid and send the verification result indicating the validity of the transaction to the ledger nodes in Shard 1 and Shard 2, respectively. If the key1 verification result indicates that the version of key1 included in the transaction is inconsistent with the version of key1 stored in Shard 1, and / or the key2 verification result indicates that the version of key2 included in the transaction is inconsistent with the version of key2 stored in Shard 2, then the coordinator node may consider the transaction invalid and send the verification result indicating the invalidity of the transaction to the ledger nodes in Shard 1 and Shard 2, respectively. After receiving the verification result returned by the coordinator node, the ledger node in Shard 1 can synchronize the verification result to the other ledger nodes in Shard 1. Afterwards, the ledger nodes in shard 1 can submit legal transactions. That is, if the transaction is determined to be valid, the state data of the shard will be updated based on the write set in the transaction read-write set. If the transaction is determined to be invalid, the state data of the shard will not be updated based on the transaction read-write set in the transaction, but the illegal transaction can be recorded in their respective databases. At the same time, the ledger nodes can store the block in the blockchain. At this time, the new block B is added to the blockchain. i+2. For example, when the transaction is determined to be valid, the value of key1 in the state data of shard 1 can be updated to the value of key1 in the write set, and the version of key1 can be updated, and the value of key2 in the state data of shard 1 can be updated to the value of key2 in the write set, and the version of key2 can be updated. Similarly, after the ledger node in shard 2 obtains the verification result returned by the coordination node, it can also synchronize the verification result to other ledger nodes in shard 2. Afterwards, the ledger node in shard 2 can submit a legal transaction, that is, if the transaction is determined to be valid, the state data of the shard will be updated based on the write set in the transaction read-write set in the transaction; if the transaction is determined to be invalid, the state data of the shard will not be updated based on the transaction read-write set in the transaction, but the illegal transaction can be recorded in their respective databases. At the same time, the ledger node can store the block in the blockchain. At this time, the new block B is added to the blockchain. j+2 . Exemplarily, when the transaction is determined to be valid, the value of key1 in the state data of shard 2 can be updated to the value of key1 in the write set, and the version of key1 can be updated, and the value of key2 in the state data of shard 2 can be updated to the value of key2 in the write set, and the version of key2 can be updated. In some embodiments, the coordination node can also be a node in shard 1 or shard 2. When the coordination node is a node in shard 1, since the nodes in shard 1 can themselves know the verification results of key1, the nodes in shard 1 will no longer need to send data to the coordination node, and at the same time, the coordination node does not need to return the verification results to the nodes in shard 1.

[0126] When Shards 1 and 2 collaborate to verify transactions, if the blockchain structure is as shown in Figure 4, trust between nodes from different organizations in a consortium chain is difficult to ensure. If cross-shard transaction verification is performed using 2PC, it becomes difficult to determine which organization will serve as the coordinator, creating cross-organizational trust issues. Therefore, the use of 2PC in consortium chains has limitations. Furthermore, in consortium chain scenarios, a coordination chain can be introduced to address cross-shard transaction atomicity issues. This coordination chain is trusted by all organizations in the consortium chain. While this approach can address cross-shard coordination in consortium chain scenarios, the introduction of a new coordination chain incurs additional resource overhead. Therefore, embodiments of the present application provide another solution for addressing cross-shard transaction atomicity in consortium chains. This solution primarily performs cross-shard transaction verification within each organization in the consortium chain. Each organization has a coordination node. This coordination node within an organization allows cross-shard transaction verification to be performed within that organization, thus overcoming cross-organizational trust issues. The coordination node of each organization can be a node in the shard participating in cross-shard transaction verification, a node in another shard, or a third-party node. There is no limitation here.

[0127] Specifically, when the blockchain structure is as shown in Figure 4, within any shard in the consortium chain, each organization has a node that is a master node. For example, referring to Figure 7(A), in Figure 7(A), key1 is stored in shard 1, key2 is stored in shard 2, and key3 is stored in shard 3. Nodes 1-1 to 1-9 belong to organization 1, and nodes 2-1 to 2-9 belong to organization 2. Furthermore, node 1-1 in shard 1 is a master node, and node 2-1 is also a master node; node 1-4 in shard 2 is a master node, and node 2-4 is also a master node; node 1-7 in shard 3 is a master node, and node 2-7 is also a master node. Furthermore, when cross-shard transaction verification is required, nodes within the same organization in different shards can perform cross-shard transaction verification through the coordination node within the node's organization, thus overcoming the cross-organization trust issue. Specifically, referring to Figure 7 , in (B) of Figure 7 , when a transaction includes key1, key2, and key3, master node 1-1 in shard 1 can send its verification result for key1 to coordinating node 11 in organization 1. Master nodes 1-4 in shard 2 can send their verification result for key1 to coordinating node 11 in organization 1. Master nodes 1-7 in shard 3 can also send their verification result for key1 to coordinating node 11 in organization 1. Coordinating node 11 can aggregate the verification results sent by shards 1, 2, and 3 and verify these three verification results to obtain a verification result, which indicates whether the transaction is valid. Coordinating node 11 can then return the verification results to master node 1-1 in shard 1, master node 1-4 in shard 2, and master node 1-7 in shard 3, respectively. In this way, cross-shard transaction verification is completed within organization 1. After obtaining the verification results, the master nodes in the shards can synchronize the verification results with other nodes in the shard belonging to organization 1.

[0128] Similarly, master node 2-1 in shard 1 can send its verification result for key1 to coordinating node 21 in organization 2. Master node 2-4 in shard 2 can send its verification result for key1 to coordinating node 21 in organization 2. Master node 2-7 in shard 3 can also send its verification result for key1 to coordinating node 21 in organization 2. Coordinating node 21 can aggregate the verification results sent by shards 1, 2, and 3 and verify these three verification results to obtain a verification result, which indicates whether the transaction is valid. Coordinating node 21 can then return the verification results to master node 2-1 in shard 1, master node 2-4 in shard 2, and master node 2-7 in shard 3, respectively. In this way, cross-shard transaction verification is completed within organization 2. After obtaining the verification results, the master nodes in the shards can synchronize them with other nodes in organization 2 in the shard.

[0129] It should be noted that the coordinating node in Figure 7(B) is a node independent of Shard 1, Shard 2, and Shard 3, for example, a node in another shard or a third-party node. In some embodiments, the coordinating node can also be a node in a shard that participates in cross-shard transaction verification. In this case, when performing cross-shard transaction verification, the shard where the coordinating node is located does not need to send its key verification results to the coordinating node, and the coordinating node does not need to send verification results to its own shard. For example, referring to Figure 7(C), node 1-1 in Shard 1 is the coordinating node in Organization 1, and node 2-1 in Shard 1 is the coordinating node in Organization 2. In Figure 7(C), when performing cross-shard verification on a transaction containing key1, key2, and key3, master node 1-4 in Shard 2 can send its key1 verification results to node 1-1 in Shard 1, and master node 1-7 in Shard 3 can also send its key1 verification results to node 1-1 in Shard 1. Since node 1-1 in shard 1 has already verified key1, it can obtain its own verification result for key1. Next, node 1-1 in shard 1 can aggregate its own verification result for key1 with the verification results sent by shards 2 and 3, and verify these three results to obtain a verification result, which indicates whether the transaction is valid. Node 1-1 in shard 1 can then return the verification result to master nodes 1-4 in shard 2 and master nodes 1-7 in shard 3, respectively. This completes cross-shard transaction verification within organization 1. Simultaneously, node 1-1 in shard 1 can synchronize the verification result with other nodes in shard 1 belonging to organization 1. After receiving the verification result, the master node in shard 2 can synchronize it with other nodes in shard 2 belonging to organization 1. After receiving the verification result, the master node in shard 3 can synchronize it with other nodes in shard 3 belonging to organization 1. The process of performing cross-shard transaction verification within Organization 2 can refer to the process of performing cross-shard transactions within Organization 1 and will not be repeated here. In some embodiments, when performing cross-shard transaction verification, if there are multiple coordinating nodes involved, some of the coordinating nodes can be nodes in shards other than the shard participating in the cross-shard transaction verification, while another part of the coordinating nodes can be nodes in the shard participating in the cross-shard transaction verification. For example, referring to Figure 8, when performing cross-shard transaction verification in Organization 1, the coordinating node can be a node independent of Shard 1, Shard 2, and Shard 3. When performing cross-shard transaction verification in Organization 2, the coordinating node can be Node 2-1 in Shard 1.It should be understood that the verification process shown in Figure 8 is drawn based on Figure 7 and can be understood as a cross-shard transaction verification method obtained by combining (B) and (C) of Figure 7. For the relevant introduction to the nodes and cross-shard transaction verification process in Figure 8, please refer to the description in Figure 7, which will not be repeated here. It should be understood that Figures 7 and 8 are introduced based on the inclusion of three different keys in a transaction. When a transaction includes two different keys, four different keys, or other different numbers of keys, the process of different shards coordinating to verify the transaction can be referred to the relevant description in Figures 7 and 8, which will not be repeated here.

[0130] In the blockchain described above, each shard independently packages transactions into blocks, which involves sorting transactions. Therefore, various reasons (such as differences in forwarding order between shards, network latency, and differences in consensus order within shards) can cause cross-shard transaction ordering to vary across shards. When cross-shard transaction verification is required, a shard internally verifies the key in a transaction, transmits the verification result to the corresponding coordinating node for verification, and then waits for the coordinating node to return the verification result. When two or more transactions have dependencies (for example, multiple transactions involving the same key), if these transactions are ordered differently across shards, they may loop through the shards awaiting verification, resulting in a deadlock and at least one deadlock loop.

[0131] For example, consider a transfer transaction, as shown in Figure 9 (A). User 1's key1 is stored on shard 1, and user 2's key2 is stored on shard 2. If the total balance in user 1's wallet is 120 yuan, and user 1 makes two transfers to user 2, the first for 100 yuan (hereinafter referred to as transaction T1) and the second for 50 yuan (hereinafter referred to as transaction T2). If the order of these two transactions on shard 1 is "transaction T1 first, transaction T2 last," the order of these two transactions on shard 2 is "transaction T2 first, transaction T1 last." Because both transactions T1 and T2 involve both user 1's account and user 2's account, these two transactions have a dependency relationship. On shard 1, transaction T2 depends on transaction T1; on shard 2, transaction T1 depends on transaction T2. ​​Due to the atomicity of transactions, identical transactions on different shards also have dependencies. In Figure 9 (A), after completing the verification of key1 contained in T1, shard 1 will transmit the verification result to the corresponding coordination node and wait for the verification result returned by the coordination node; after completing the verification of key2 contained in T2, shard 2 will transmit the verification result to the corresponding coordination node and wait for the verification result returned by the coordination node. Because shard 1 cannot verify key1 in transaction T2 before obtaining the verification result returned by the coordination node; and shard 2 cannot verify key2 in transaction T1 before obtaining the verification result returned by the coordination node. Afterwards, as shown in Figure 9 (B), shard 1 will wait for the verification result of key2 in transaction T1 in shard 2, while shard 2 will wait for the verification result of key1 in transaction T2 in shard 1. This will cause the two to wait in a loop, thus forming a deadlock.

[0132] After a deadlock occurs, these dependent transactions form a loop (the "deadlock loop"). The deadlock can only be resolved by opening the deadlock loop, such as by marking a transaction in the deadlock loop as invalid. For example, let's continue with the aforementioned example of user A transferring two transactions to user B, the first for 100 yuan and the second for 50 yuan. While the two shards are waiting for each other, invalidating one of the transactions allows both shards to verify the same transaction simultaneously, thus resolving the deadlock.

[0133] In the case of a consortium blockchain, if each organization independently resolves a deadlock, it may be difficult to ensure consistent resolution results for each organization, and thus, the final state data for each organization cannot be guaranteed. Therefore, embodiments of the present application provide a deadlock resolution solution for consortium blockchains. In this solution, when a transaction in a shard fails to receive a verification result from the coordinating node for a certain period of time, or when the coordinating node fails to receive a verification result for a transaction in a certain shard for a certain period of time, a deadlock detection task can be triggered by a timer or other means. Any node in the consortium chain can assume the deadlock detection task. A node that assumes the deadlock resolution task can be referred to as a "deadlock resolution node." Furthermore, each organization in the consortium chain has at least one deadlock resolution node. For a given organization, any node in that organization can serve as a deadlock resolution node. After receiving the deadlock detection task, the deadlock resolution node can collect transactions from the organization corresponding to the deadlock resolution node, or collect transaction identifiers, etc. Any data that can represent the transaction can be collected, without limitation. The deadlock-resolving node then constructs a converged dependency graph based on the collected dependencies between transactions. For example, convergence can be understood as the dependency graph reaching a stable state, meaning that no new transactions will be added to the dependency graph. This dependency graph is associated with a cross-shard transaction to be verified. For example, if transaction T1 requires cross-shard verification, and a coordinating node fails to obtain the verification result for transaction T1 from organization 1 in a particular shard within a certain period of time, the deadlock-resolving node associated with organization 1 in that shard can construct a converged dependency graph associated with transaction T1. Finally, the deadlock-resolving node can delete transactions that cause deadlock loops from the converged dependency graph and mark them as invalid until all deadlock loops are resolved. For example, nodes in the dependency graph can be transactions, transaction identifiers, or other data that can represent transactions, without limitation. In other words, the transactions included in the dependency graph can be actual transactions, transaction identifiers, or other data that can represent transactions. After all deadlock loops are eliminated, the corresponding shard can obtain the verification results transmitted by the corresponding coordination node and continue to verify the transaction. In this embodiment, to ensure the consistency of deadlock resolution results among different organizations, the same deadlock resolution rules can be used across different organizations. Because the order in which different organizations verify transactions within a shard is the same, the convergent waiting graphs constructed by different organizations should also be the same. Therefore, using the same deadlock resolution rules can ensure the consistency of subsequent deadlock resolution results.In some embodiments, since the deadlock resolution operation often requires the failure of many transactions, and the benefits will be different each time the transactions are selected are different, in order to maximize the benefits, the transaction with the largest number of transactions involved in the deadlock loop can be marked as invalid each time.

[0134] For example, as shown in Figure 10 (A), continuing with the transfer transaction example, user 1 transfers to user 2, user 2 transfers to user 3, and user 3 transfers to user 1. The transaction initiated by user 1 is TxAB, the transaction initiated by user 2 is TxBC, and the transaction initiated by user 3 is TxCA. Shards 1, 2, and 3 all include organizations 1 and 2. Assume that user 1's key 1 is stored on shard 1, user 2's key 2 is stored on shard 2, and user 3's key 3 is stored on shard 3. At this point, the transactions on shard 1 are TxAB and TxCA, the transactions on shard 2 are TxAB and TxBC, and the transactions on shard 3 are TxBC and TxCA. The order of transactions in shard 1 is: TxAB first, TxCA last; the order of transactions in shard 2 is: TxBC first, TxAB last; and the order of transactions in shard 3 is: TxCA first, TxBC last. Each organization within a shard must independently verify each transaction within that shard. In Shard 1, after Organization 1 and Organization 2 each complete verification of key1 in TxAB, Organization 1 sends the verification result to Organization 1's coordinating node, and Organization 2 sends the verification result to Organization 2's coordinating node. At this point, both Organization 1 and Organization 2 in Shard 1 will wait for feedback from their respective coordinating nodes. In Shard 2, after both Organization 1 and Organization 2 each complete verification of key2 in TxBC, Organization 1 sends the verification result to Organization 1's coordinating node, and Organization 2 sends the verification result to Organization 2's coordinating node. At this point, both Organization 1 and Organization 2 in Shard 2 will wait for feedback from their respective coordinating nodes. In Shard 3, after both Organization 1 and Organization 2 each complete verification of key3 in TxCA, Organization 1 sends the verification result to Organization 1's coordinating node, and Organization 2 sends the verification result to Organization 2's coordinating node. At this point, both Organization 1 and Organization 2 in Shard 3 will wait for the corresponding coordination node to feedback the verification results.

[0135] However, in Figure 10 (A), TxAB, the first transaction requiring cross-shard verification between Organization 1 and Organization 2 on Shard 1, and TxBC, the first transaction requiring cross-shard verification between Organization 1 and Organization 2 on Shard 2, involve the same key (i.e., user 2's key2). Therefore, there is a dependency between these two transactions. Therefore, TxAB verified by each organization on Shard 1 will all wait for TxBC to complete cross-shard transaction verification. TxBC, the first transaction requiring cross-shard verification between Organization 1 and Organization 2 on Shard 2, and TxCA, the first transaction requiring cross-shard verification between Organization 1 and Organization 2 on Shard 3, involve the same key (i.e., user 3's key3). Therefore, there is a dependency between these two transactions. Therefore, TxBC verified by each organization on Shard 2 will all wait for TxCA to complete cross-shard transaction verification. The first TxCA that requires cross-shard transaction verification between Organization 1 and Organization 2 on Shard 3 and the first TxAB that requires cross-shard transaction verification between Organization 1 and Organization 2 on Shard 1 involve the same key (i.e., key 1 of User 1). Therefore, there is a dependency between these two transactions, so the TxCA verified by each organization on Shard 3 will all wait for TxAB to complete the cross-shard transaction verification. In this way, in each organization in the shard, TxAB, TxBC, and TxCA will wait in a loop, forming a deadlock loop in each organization as shown in Figure 10 (B). It can be seen from the deadlock loops corresponding to the two organizations shown in Figure 10 (B) that the deadlock loops corresponding to the two organizations are the same, so the deadlock resolution nodes of the two organizations perform the same deadlock resolution rules to ensure that the deadlock resolution results between the organizations are consistent.

[0136] It should be understood that Figure 10 only illustrates a scenario involving three transactions. In practice, there may be more transactions involved, resulting in multiple deadlock loops, all directly or indirectly connected to each other. These deadlock loops thus form a dependency graph. When this dependency graph converges, the deadlock-resolving node can perform a deadlock-resolving operation on the dependency graph. Furthermore, once a deadlock loop is constructed, the dependency graph converges, at which point it contains only one deadlock loop.

[0137] Furthermore, Figure 10 only describes one method for constructing a dependency graph. Dependency graphs can also be constructed using other methods. For example, as shown in Figure 11 (A), continuing with the transfer transaction example, user 1 transfers to user 2, user 2 transfers to user 3, and user 3 transfers to user 1. The transaction initiated by user 1 is TxAB, the transaction initiated by user 2 is TxBC, and the transaction initiated by user 3 is TxCA. Assume that user 1's key key1 is stored on shard 1, user 2's key2 is stored on shard 2, and user 3's key3 is stored on shard 3. At this point, the transactions on shard 1 are TxAB and TxCA, the transactions on shard 2 are TxAB and TxBC, and the transactions on shard 3 are TxBC and TxCA. The order of transactions in shard 1 is: TxAB first, TxCA last; the order of transactions in shard 2 is: TxBC first, TxAB last; and the order of transactions in shard 3 is: TxCA first, TxBC last. If the deadlock detection task is triggered at this time, the deadlock resolution node can collect the order and corresponding transactions in shards 1, 2, and 3 respectively when executing the deadlock detection task. Then, the deadlock resolution node can take the first transaction in shard 1 that requires cross-shard verification (i.e., transaction TxAB) as the target (of course, transactions in other shards can also be selected as targets) and search for the target in other shards. Since there is transaction TxAB in shard 1, the deadlock resolution node can identify all transactions after transaction TxAB in shard 2 as having a dependency relationship with transaction TxAB, and connect these transactions in sequence to construct a dependency graph. Since there are only transactions TxAB and TxBC in shard 2, the constructed dependency graph can be as shown in (B) of Figure 11. Then, the deadlock resolution node takes the first transaction in shard 2 that requires cross-shard verification (i.e., transaction TxBC) as the target and search for the target in other shards. Since there is transaction TxBC in shard 3, the deadlock-solving node can identify all transactions after transaction TxBC in shard 3 as having a dependency relationship with transaction TxBC, and add these transactions in sequence to the dependency graph constructed in the previous stage, that is, construct the dependency graph shown in (C) of Figure 11. Next, the deadlock-solving node takes the first transaction in shard 3 that requires cross-shard verification (i.e., transaction TxCA) as the target and searches for the target in other shards. Since there is transaction TxCA in shard 1, the deadlock-solving node can identify all transactions after transaction TxCA in shard 1 as having a dependency relationship with transaction TxCA, and add these transactions in sequence to the dependency graph constructed in the previous stage, that is, construct the dependency graph shown in (D) of Figure 11. In this way, a convergent dependency graph is constructed.

[0138] In this embodiment, in the structure of the alliance chain shown in Figures 4 or 7 above, the nodes in different organizations in each shard can select the master node in the organization through a consensus algorithm (such as Paxos, Raft, ZAB, etc.). Although this method can select the master node, for an organization in a shard, it requires that the number of nodes belonging to the organization in the shard be more than 3 nodes, which makes the master selection scenario too narrow, and too many nodes will cost more. In view of this, an embodiment of the present application provides a master selection scheme. In this master selection scheme, a circular sentinel mechanism is mainly used to select the master, but no additional sentinel cluster is added. Instead, the master node in an organization in an adjacent shard serves as a sentinel for the node in the organization in another shard, monitors the nodes in the other shard, and the master node serving as the sentinel randomly selects or assigns a node as the master node for the node in the corresponding organization in the other shard. In addition, the master node that serves as a sentinel can also re-select or assign a node from the corresponding organization in the shard as the master node if an abnormality occurs in the master node of the corresponding organization in another shard (for example, when it goes down). For example: when the master node of Organization 1 in Shard 1 serves as the sentinel of the node in Organization 1 in Shard 2, if the master node in Organization 1 in Shard 2 goes down, the master node of Organization 1 in Shard 1 can re-select a node in Organization 1 in Shard 2 as the master node. When all shards adopt this master election mechanism, a sentinel ring can be obtained. For example, as shown in Figure 12, there are 3 shards in a consortium chain. Shard 1 contains nodes 1-1, 1-2, and 1-3 belonging to Organization 1, Shard 2 contains nodes 1-4 and 1-5 belonging to Organization 1, and Shard 3 contains nodes 1-6 belonging to Organization 1. At this point, nodes 1-6 in shard 3 can act as sentinels for nodes belonging to organization 1 in shard 1, and designate node 1-1 as the organization's master node in shard 1. Node 1-1 in shard 1 can act as a sentinel for nodes belonging to organization 1 in shard 2, and designate node 1-4 as the organization's master node in shard 2. Node 1-4 in shard 2 can act as a sentinel for nodes belonging to organization 1 in shard 3, and designate node 1-6 as the organization's master node in shard 3. Furthermore, in Figure 12, when node 1-6 detects that node 1-1 is down, it can designate node 1-2 as the master node, or node 1-3 as the master node. In this way, within an organization in a shard, as long as at least one node remains up, all shards can be re-elected as masters. In addition, under this circular sentinel mechanism, when an organization does not have a master node in all shards, the nodes belonging to the organization in any shard can use the consensus algorithm to select a master node. After that, the selected master node can serve as the sentinel of the next shard of the shard.In some embodiments, when the blockchain is a public chain, the Sentinel Master Election mechanism described above can also be used. In this case, the master node in one shard can serve as a Sentinel in another shard. For details, please refer to the above description and will not be repeated here. It should be understood that Figure 12 is an example of the nodes contained in one organization in three shards. When the number of shards and / or the number of organizations is other, the Sentinel Master Election mechanism can refer to the description in Figure 12 and will not be repeated here.

[0139] It should be noted that the blockchain operation process described above is based on a single transaction as an example. When there are multiple transactions, the blockchain operation process provided by the embodiments of this application can refer to the single transaction operation process described above and will not be further described here. Furthermore, when there are multiple transactions, these multiple transactions can be submitted to a shard via a single client or via multiple different clients, depending on the specific circumstances and not limited here. Furthermore, when there are multiple transactions and these multiple transactions are submitted to a shard by a single client, the client can submit transaction requests related to these multiple transactions to a single endorsement node or to different endorsement nodes, without limitation here. Furthermore, when there are multiple transactions and these multiple transactions are submitted to a shard by different clients, these different clients can submit their respective transaction requests to a single endorsement node or to different endorsement nodes, without limitation here. Of course, different clients can submit transactions to the same shard or to different shards, depending on the specific circumstances and not limited here. It should be understood that when cross-shard transaction verification is required between different shards, these shards will collaborate to perform cross-shard verification.

[0140] The above is an introduction to the blockchain provided by the embodiment of the present application. Based on the above content, the embodiment of the present application also provides a node. The node can be deployed in the blockchain described above. Exemplarily, the blockchain includes: a first shard and a second shard, the first shard stores a first key, and the second shard stores a second key. Among them, the node can be the endorsement node described above. The node may include a communication module and a processing module. Among them, the communication module is mainly responsible for receiving transaction requests from the client, and the transaction request is used to request an update of the first key and the second key. The processing module is mainly responsible for generating a transaction read-write set based on the status data in the first shard and the status data in the second shard; and, signing the transaction read-write set to obtain an endorsement result. In addition, the communication module can also be responsible for sending the endorsement result to the client.

[0141] Based on the method in the above embodiment, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method in the above embodiment.

[0142] Based on the method in the above embodiment, an embodiment of the present application provides a computer program product. When the computer program product runs on a processor, the processor executes the method in the above embodiment.

[0143] It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0144] The method steps in the embodiments of the present application can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0145] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted via the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state drive (SSD)).

[0146] It will be understood that the various numerical numbers involved in the embodiments of the present application are merely distinctions for the convenience of description and are not intended to limit the scope of the embodiments of the present application.

Claims

1. A transaction processing method, characterized in that: Applied to a blockchain, the blockchain comprising: a first shard and a second shard, the first shard storing a first key, the second shard storing a second key; The method comprises: The first shard obtains a first transaction and a second transaction, where the first transaction includes the first key and the second key; The first shard forwards the first transaction to the second shard, and packages the first transaction and the second transaction into a first block belonging to the first shard, verifies the second transaction in the first block, and cooperates with the second shard to verify the first transaction in the first block; The second shard receives the first transaction forwarded from the first shard, packages the first transaction into a second block belonging to the second shard, and cooperates with the first shard to verify the first transaction in the second block.

2. The method according to claim 1, characterized in that The blockchain includes a first endorsement node and a second endorsement node, the first transaction includes a first endorsement result, the first endorsement result includes the first key and the second key, the second transaction includes a second endorsement result, the second endorsement result includes the first key, the first transaction is obtained by processing the first endorsement result by a first client, and is submitted to the first shard by the first client, and the second transaction is obtained by processing the second endorsement result by a second client, and is submitted to the first shard by the second client; Before the first shard acquires the first transaction and the second transaction, the method further includes: The first endorsement node receives the first transaction request submitted by the first client, generates a first transaction read-write set based on the state data in the first shard and the state data in the second shard; and signs the first transaction read-write set to obtain the first endorsement result, and sends the first endorsement result to the first client, wherein the first transaction request is used to request an update of the first key and the second key; The second endorsement node receives a second transaction request submitted from the second client, generates a second transaction read-write set based on the status data in the first shard, and signs the second transaction read-write set to obtain the second endorsement result, and sends the second endorsement result to the second client, wherein the first transaction request is used to request an update of the first key.

3. The method according to claim 2, characterized in that The first endorsing node and the second endorsing node are both nodes in the first shard, or at least one of the first endorsing node and the second endorsing node is a node other than a node in the first shard.

4. The method according to any one of claims 1 to 3, characterized in that: The blockchain is a consortium chain, the consortium chain includes a first organization and a second organization, in the first shard, a result of verifying the first transaction by a node affiliated with the first organization is a first result, in the second shard, a result of verifying the first transaction by a node affiliated with the first organization is a second result, in the first shard, a result of verifying the first transaction by a node affiliated with the second organization is a third result, and in the second shard, a result of verifying the first transaction by a node affiliated with the second organization is a fourth result; The first shard and the second shard cooperate to verify the first transaction, including: The first shard sends the first result to the first coordination node, the second shard sends the second result to the first coordination node, the first shard and the second shard both receive a fifth result from the first coordination node, the fifth result is a verification result of the first result and the second result, the node in the first shard belonging to the first organization processes the first transaction based on the fifth result, the node in the second shard belonging to the first organization processes the first transaction based on the fifth result, and the first coordination node is a node other than the nodes in the first shard and the second shard; The first shard sends the third result to the second coordination node, the second shard sends the fourth result to the second coordination node, the first shard and the second shard both receive the sixth result from the second coordination node, the sixth result is a verification result of the third result and the fourth result, the node in the first shard belonging to the second organization processes the first transaction based on the sixth result, the node in the second shard belonging to the second organization processes the first transaction based on the sixth result, and the second coordination node is a node other than the nodes in the first shard and the second shard.

5. The method according to any one of claims 1 to 3, characterized in that: The blockchain is a consortium chain, the consortium chain includes a first organization and a second organization, in the first shard, a result of verifying the first transaction by a node affiliated with the first organization is a first result, in the second shard, a result of verifying the first transaction by a node affiliated with the first organization is a second result, in the first shard, a result of verifying the first transaction by a node affiliated with the second organization is a third result, and in the second shard, a result of verifying the first transaction by a node affiliated with the second organization is a fourth result; The first shard and the second shard cooperate to verify the first transaction, including: The first shard sends the first result to the node in the second shard that belongs to the first organization; the node in the second shard that belongs to the first organization verifies the first result and the second result to obtain a fifth result; the second shard sends the fifth result to the node in the first shard that belongs to the first organization; the node in the first shard that belongs to the first organization processes the first transaction based on the fifth result, and the node in the second shard that belongs to the first organization processes the first transaction based on the fifth result; The first shard sends the third result to the node in the second shard belonging to the second organization; the node in the second shard belonging to the second organization verifies the third result and the fourth result to obtain a sixth result; the second shard sends the sixth result to the node in the first shard belonging to the second organization; the node in the first shard belonging to the second organization processes the first transaction based on the sixth result, and the node in the second shard belonging to the second organization processes the first transaction based on the sixth result.

6. The method according to any one of claims 1 to 3, characterized in that: The blockchain is a consortium chain, the consortium chain includes a first organization and a second organization, in the first shard, a result of verifying the first transaction by a node affiliated with the first organization is a first result, in the second shard, a result of verifying the first transaction by a node affiliated with the first organization is a second result, in the first shard, a result of verifying the first transaction by a node affiliated with the second organization is a third result, and in the second shard, a result of verifying the first transaction by a node affiliated with the second organization is a fourth result; The first shard and the second shard cooperate to verify the first transaction, including: The first shard sends the first result to the coordination node, the second shard sends the second result to the coordination node, the first shard and the second shard both receive a fifth result from the coordination node, the fifth result is a verification result of the first result and the second result, the node in the first shard belonging to the first organization processes the first transaction based on the fifth result, the node in the second shard belonging to the first organization processes the first transaction based on the fifth result, and the first coordination node is a node other than the nodes in the first shard and the second shard; The first shard sends the third result to the node in the second shard belonging to the second organization; the node in the second shard belonging to the second organization verifies the third result and the fourth result to obtain a sixth result; the second shard sends the sixth result to the node in the first shard belonging to the second organization; the node in the first shard belonging to the second organization processes the first transaction based on the sixth result, and the node in the second shard belonging to the second organization processes the first transaction based on the sixth result.

7. The method according to any one of claims 4 to 6, characterized in that: The blockchain includes a first deadlock resolution node and a second deadlock resolution node, the first deadlock resolution node belongs to the first organization, and the second deadlock resolution node belongs to the second organization; The method further comprises: When the first target node obtains any one of the first result and the second result but fails to obtain the other within a first time period, the first deadlock resolution node constructs a dependency graph related to the first transaction and in a convergent state, wherein the first target node is used to verify the first result and the second result, and the dependency graph contains at least one transaction that makes the first transaction unverifiable; When the second target node obtains any one of the third result and the fourth result but fails to obtain the other within the first time period, the second deadlock resolution node constructs the dependency graph, and the second target node is used to verify the third result and the fourth result.

8. The method according to claim 7, characterized in that The method further comprises: The first deadlock resolution node marks at least one transaction included in the dependency graph constructed by the first deadlock resolution node as invalid based on the first rule; The second deadlock resolution node marks at least one transaction included in the dependency graph constructed by the second deadlock resolution node as invalid based on the first rule.

9. The method according to claim 7 or 8, characterized in that: The first deadlock resolution node is a node in the first shard that belongs to the first organization, or a node in the second shard that belongs to the first organization, or a node outside the first shard and the second shard that belongs to the first organization; The second deadlock resolution node is a node in the first shard that belongs to the second organization, or a node in the second shard that belongs to the second organization, or a node outside the first shard and the second shard and that belongs to the second organization.

10. The method according to any one of claims 1 to 9, characterized in that: The blockchain is a consortium chain, the consortium chain includes a first organization and a second organization, the first shard includes a first master node and a second master node, the first master node belongs to the first organization, and the second master node belongs to the second organization; The method further comprises: The first master node monitors the nodes in the second shard belonging to the first organization, and selects a third master node from the second shard, where the third master node belongs to the first organization; The second master node monitors the nodes in the second shard belonging to the second organization, and selects a fourth master node from the second shard, where the fourth master node belongs to the second organization; The third master node monitors the nodes in the first shard that belong to the first organization, and selects a fifth master node from the first shard when an abnormality occurs in the first master node, the fifth master node belonging to the first organization; The fourth master node monitors the nodes in the first shard that belong to the second organization, and if an abnormality occurs in the second master node, selects a sixth master node from the first shard, and the sixth master node belongs to the second organization.

11. The method according to any one of claims 1 to 10, characterized in that: The shards in the blockchain are divided based on the code edited by the administrators of the blockchain.

12. A transaction processing method, characterized in that: An endorsement node applied to a blockchain, wherein the blockchain includes: a first shard and a second shard, wherein the first shard stores a first key, and the second shard stores a second key; The method comprises: receiving a transaction request from a client, wherein the transaction request is used to request an update of the first key and the second key; Generate a transaction read-write set based on the state data in the first shard and the state data in the second shard; Sign the transaction read-write set to obtain the endorsement result; Sending the endorsement result to the client.

13. A blockchain, characterized in that: The blockchain includes: a first shard and a second shard, wherein the first shard stores a first key, and the second shard stores a second key; The first shard is responsible for obtaining the first transaction and the second transaction, and the first transaction includes the first key and the second key; The first shard is also responsible for forwarding the first transaction to the second shard, and packaging the first transaction and the second transaction into a first block belonging to the first shard, and verifying the second transaction in the first block, and cooperating with the second shard to verify the first transaction in the first block; The second shard is responsible for receiving the first transaction forwarded from the first shard, packaging the first transaction into a second block belonging to the second shard, and cooperating with the first shard to verify the first transaction in the second block.

14. The blockchain according to claim 13, characterized in that: The blockchain includes a first endorsement node and a second endorsement node, the first transaction includes a first endorsement result, the first endorsement result includes the first key and the second key, the second transaction includes a second endorsement result, the second endorsement result includes the first key, the first transaction is obtained by processing the first endorsement result by a first client, and is submitted to the first shard by the first client, and the second transaction is obtained by processing the second endorsement result by a second client, and is submitted to the first shard by the second client; Before the first shard obtains the first transaction and the second transaction, The first endorsement node is responsible for receiving the first transaction request submitted by the first client, generating a first transaction read-write set based on the state data in the first shard and the state data in the second shard; and signing the first transaction read-write set to obtain the first endorsement result, and sending the first endorsement result to the first client, wherein the first transaction request is used to request an update of the first key and the second key; Before the first shard obtains the first transaction and the second transaction, the second endorsement node is responsible for receiving the second transaction request submitted by the second client, generating a second transaction read-write set based on the status data in the first shard; and signing the second transaction read-write set to obtain the second endorsement result, and sending the second endorsement result to the second client, wherein the first transaction request is used to request an update of the first key.

15. The blockchain according to claim 14, characterized in that: The first endorsing node and the second endorsing node are both nodes in the first shard, or at least one of the first endorsing node and the second endorsing node is a node other than a node in the first shard.

16. The blockchain according to any one of claims 13 to 15, characterized in that: The blockchain is a consortium chain, the consortium chain includes a first organization and a second organization, in the first shard, a result of verifying the first transaction by a node affiliated with the first organization is a first result, in the second shard, a result of verifying the first transaction by a node affiliated with the first organization is a second result, in the first shard, a result of verifying the first transaction by a node affiliated with the second organization is a third result, and in the second shard, a result of verifying the first transaction by a node affiliated with the second organization is a fourth result; When the first shard and the second shard jointly verify the first transaction: The first shard is responsible for sending the first result to the first coordination node, the second shard is responsible for sending the second result to the first coordination node, the first shard and the second shard are both responsible for receiving the fifth result from the first coordination node, the fifth result is a verification result of the first result and the second result, the node in the first shard belonging to the first organization is responsible for processing the first transaction based on the fifth result, the node in the second shard belonging to the first organization is responsible for processing the first transaction based on the fifth result, and the first coordination node is a node other than the nodes in the first shard and the second shard; The first shard is responsible for sending the third result to the second coordination node, the second shard is responsible for sending the fourth result to the second coordination node, the first shard and the second shard are both responsible for receiving the sixth result from the second coordination node, the sixth result is a verification result of the third result and the fourth result, the node in the first shard belonging to the second organization is responsible for processing the first transaction based on the sixth result, the node in the second shard belonging to the second organization is responsible for processing the first transaction based on the sixth result, and the second coordination node is a node other than the nodes in the first shard and the second shard.

17. The blockchain according to any one of claims 13 to 15, characterized in that: The blockchain is a consortium chain, the consortium chain includes a first organization and a second organization, in the first shard, a result of verifying the first transaction by a node affiliated with the first organization is a first result, in the second shard, a result of verifying the first transaction by a node affiliated with the first organization is a second result, in the first shard, a result of verifying the first transaction by a node affiliated with the second organization is a third result, and in the second shard, a result of verifying the first transaction by a node affiliated with the second organization is a fourth result; When the first shard and the second shard jointly verify the first transaction: The first shard is responsible for sending the first result to the node in the second shard that belongs to the first organization; The node in the second shard belonging to the first organization is responsible for verifying the first result and the second result to obtain a fifth result; The second shard is responsible for sending the fifth result to the node in the first shard that belongs to the first organization; The node in the first shard belonging to the first organization is responsible for processing the first transaction based on the fifth result, and the node in the second shard belonging to the first organization is responsible for processing the first transaction based on the fifth result; The first shard is responsible for sending the third result to the node in the second shard that belongs to the second organization; The node in the second shard belonging to the second organization is responsible for verifying the third result and the fourth result to obtain a sixth result; The second shard is responsible for sending the sixth result to the node belonging to the second organization in the first shard; The nodes in the first shard belonging to the second organization are responsible for processing the first transaction based on the sixth result, and the nodes in the second shard belonging to the second organization are responsible for processing the first transaction based on the sixth result.

18. The blockchain according to any one of claims 13 to 15, characterized in that: The blockchain is a consortium chain, the consortium chain includes a first organization and a second organization, in the first shard, a result of verifying the first transaction by a node affiliated with the first organization is a first result, in the second shard, a result of verifying the first transaction by a node affiliated with the first organization is a second result, in the first shard, a result of verifying the first transaction by a node affiliated with the second organization is a third result, and in the second shard, a result of verifying the first transaction by a node affiliated with the second organization is a fourth result; When the first shard and the second shard jointly verify the first transaction: The first shard is responsible for sending the first result to the coordination node, the second shard is responsible for sending the second result to the coordination node, the first shard and the second shard are both responsible for receiving a fifth result from the coordination node, the fifth result is a verification result of the first result and the second result, the node in the first shard belonging to the first organization is responsible for processing the first transaction based on the fifth result, the node in the second shard belonging to the first organization is responsible for processing the first transaction based on the fifth result, and the first coordination node is a node other than the nodes in the first shard and the second shard; The first shard is responsible for sending the third result to the node in the second shard that belongs to the second organization; The node in the second shard belonging to the second organization is responsible for verifying the third result and the fourth result to obtain a sixth result; The second shard is responsible for sending the sixth result to the node belonging to the second organization in the first shard; The nodes in the first shard belonging to the second organization are responsible for processing the first transaction based on the sixth result, and the nodes in the second shard belonging to the second organization are responsible for processing the first transaction based on the sixth result.

19. The blockchain according to any one of claims 16 to 18, characterized in that: The blockchain includes a first deadlock resolution node and a second deadlock resolution node, the first deadlock resolution node belongs to the first organization, and the second deadlock resolution node belongs to the second organization; When the first target node obtains any one of the first result and the second result but fails to obtain the other within a first time period, the first deadlock resolution node is responsible for constructing a dependency graph related to the first transaction and in a convergent state, wherein the first target node is used to verify the first result and the second result, and the dependency graph contains at least one transaction that makes the first transaction unverifiable; When the second target node obtains any one of the third result and the fourth result but fails to obtain the other one within the first time period, the second deadlock resolution node is responsible for constructing the dependency graph, and the second target node is used to verify the third result and the fourth result.

20. The blockchain according to claim 19, characterized in that: The first deadlock resolution node is further responsible for marking at least one transaction included in the dependency graph constructed by the first deadlock resolution node as invalid based on the first rule; The second deadlock resolution node is also responsible for marking at least one transaction included in the dependency graph constructed by the second deadlock resolution node as invalid based on the first rule.

21. The blockchain according to claim 19 or 20, characterized in that: The first deadlock resolution node is a node in the first shard that belongs to the first organization, or a node in the second shard that belongs to the first organization, or a node outside the first shard and the second shard that belongs to the first organization; The second deadlock resolution node is a node in the first shard that belongs to the second organization, or a node in the second shard that belongs to the second organization, or a node outside the first shard and the second shard and that belongs to the second organization.

22. The blockchain according to any one of claims 13-21, characterized in that: The blockchain is a consortium chain, the consortium chain includes a first organization and a second organization, the first shard includes a first master node and a second master node, the first master node belongs to the first organization, and the second master node belongs to the second organization; The first master node is responsible for monitoring the nodes in the second shard belonging to the first organization, and selecting a third master node from the second shard, where the third master node belongs to the first organization; The second master node is responsible for monitoring the nodes in the second shard belonging to the second organization, and selecting a fourth master node from the second shard, the fourth master node belonging to the second organization; The third master node is responsible for monitoring the nodes in the first shard that belong to the first organization, and in the event that an abnormality occurs in the first master node, selecting a fifth master node from the first shard, the fifth master node belonging to the first organization; The fourth master node is responsible for monitoring the nodes in the first shard that belong to the second organization, and in the event of an abnormality in the second master node, selecting a sixth master node from the first shard, the sixth master node belonging to the second organization.

23. The blockchain according to any one of claims 13-22, characterized in that: The shards in the blockchain are divided based on the code edited by the administrators of the blockchain.

24. A node, characterized in that: Deployed in a blockchain, the blockchain comprising: a first shard and a second shard, the first shard storing a first key, and the second shard storing a second key; The nodes include: A communication module, responsible for receiving a transaction request from a client, wherein the transaction request is used to request an update of the first key and the second key; A processing module, responsible for generating a transaction read-write set based on the state data in the first shard and the state data in the second shard; and signing the transaction read-write set to obtain an endorsement result; The communication module is also responsible for sending the endorsement result to the client.

25. A computer-readable storage medium storing a computer program, wherein when the computer program is executed on a processor, the processor executes the method according to any one of claims 1 to 11, or executes the method according to claim 12.

26. A computer program product, characterized in that When the computer program product runs on a processor, the processor is enabled to execute the method according to any one of claims 1 to 11, or the method according to claim 12.

Images