A blockchain system sharding consensus method, device and electronic equipment

Abstract

Embodiments of the present disclosure disclose a blockchain system sharding consensus method, device, electronic equipment and readable medium. The method comprises: a sharding coordination module performs a sharding operation on a blockchain system, including determining transaction addresses, blockchain nodes and public addresses corresponding to each shard, and determining master nodes from blockchain nodes included in each shard; nodes of each shard perform in-shard consensus among nodes of the shard using an in-shard consensus algorithm of the shard for a transaction request received by the nodes of the shard, the transaction request including only a transaction address and a public address corresponding to the shard, and write an in-shard block in the case of successful in-shard consensus; and master nodes of each shard perform inter-shard consensus among master nodes of each shard using an inter-shard consensus algorithm for a transaction request received by the master nodes of each shard, the transaction request including public addresses corresponding to two or more shards, and write an inter-shard block in the case of successful inter-shard consensus. The consensus method of the embodiments of the present disclosure improves consensus efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of blockchain technology, and in particular to sharding consensus methods, apparatuses, electronic devices and readable media for blockchain systems. Background Technology

[0002] In current conventional blockchain architectures, the common model is a replica state machine, where each node stores consistent data such as transactions and states. This architecture has certain performance limitations, including longer global consensus time, which affects transaction processing efficiency; and increased storage resource requirements due to each node storing data.

[0003] The basic idea behind blockchain sharding is to divide the nodes in the blockchain network into several relatively independent shards. Different transactions are executed within each shard, and the number of nodes in each shard is relatively small, which can improve consensus efficiency and theoretically lead to a significant performance improvement. However, after sharding, it is difficult to limit a transaction to a single shard. Cross-shard transactions involving multiple shards introduce multiple cross-shard communications, increasing communication costs. Moreover, consensus and transactions between shards often need to be performed sequentially, affecting the efficiency of consensus and transactions. For example, in the UTXO (Unspent Transaction Output) model, a transaction may include multiple transaction inputs and outputs, potentially involving multiple shards, thus requiring cross-shard communication. If a transaction involves too many cross-shards, the cost of shard communication may offset the performance improvement brought by sharding. Furthermore, with transactions from different shards proceeding sequentially, some shard consensuses rely on the execution results of other shards, failing to improve consensus efficiency. Therefore, sharding increases system complexity without providing better performance. In extreme cases, when most transactions involve multiple shards, sharding can even degrade system performance. Summary of the Invention

[0004] This disclosure provides a blockchain system sharding consensus method, apparatus, electronic device, and readable medium, which can improve the sharding consensus efficiency of the blockchain system.

[0005] To achieve the above technical objectives, the embodiments of this disclosure adopt the following technical solutions:

[0006] In a first aspect, embodiments of this disclosure provide a sharding consensus method for a blockchain system, the blockchain system including a sharding coordination module and multiple blockchain nodes, the method comprising:

[0007] The sharding coordination module performs sharding operations on the blockchain system, including determining the transaction addresses, blockchain nodes, and public addresses corresponding to each shard, and determining the master node from the blockchain nodes included in each shard.

[0008] For transaction requests received that only include the transaction address and public address corresponding to this segment, the nodes of each segment use the segment's intra-segment consensus algorithm to achieve intra-segment consensus. If the intra-segment consensus is successful, the transaction request that has completed the intra-segment consensus is written into the intra-segment block.

[0009] For transaction requests that include public addresses corresponding to two or more shards, the master nodes of each shard use an inter-shard consensus algorithm to achieve inter-shard consensus among the master nodes of each shard. If the inter-shard consensus is successful, the transaction request that has completed the inter-shard consensus is written into the inter-shard block.

[0010] In some possible implementations, before intra-shard consensus and inter-shard consensus are performed, each shard node performs transaction conversion for transaction requests that include transaction addresses corresponding to two or more shards.

[0011] In some possible implementations, the hash values ​​of intra-shard blocks in each shard are consensused among the master nodes of each shard, and if the inter-shard consensus is successful, the hash value of the completed inter-shard consensus is written into the inter-shard block.

[0012] In some possible implementations, the sharding coordination module includes a verifiable random function module that performs one or more of the following operations: determining the transaction address, blockchain node, public address, and master node of each shard.

[0013] In some possible implementations, when a new transaction address is added to the blockchain system, the sharding coordination module assigns the new transaction address to an existing shard.

[0014] In some possible implementations, when a new node is added to the blockchain system, the sharding coordination module assigns the new node to an existing shard. After the new node determines its shard affiliation, it synchronizes the blocks within its shard.

[0015] In some possible implementations, the common address of each shard is the address of the shard master node.

[0016] Secondly, embodiments of this disclosure provide a blockchain system, which includes a sharding coordination module and multiple blockchain nodes, wherein:

[0017] The sharding coordination module is configured to perform sharding operations on the blockchain system, including determining the transaction address, blockchain node, and public address corresponding to each shard, and determining the master node from the blockchain nodes included in each shard.

[0018] Each shard node is configured to perform intra-shard consensus using the intra-shard consensus algorithm of the shard when a transaction request that only includes the transaction address and public address corresponding to the shard is received. If the intra-shard consensus is successful, the transaction request that has completed the intra-shard consensus is written into the intra-shard block.

[0019] Each shard's master node is configured to perform inter-shard consensus using an inter-shard consensus algorithm when receiving transaction requests that include public addresses corresponding to two or more shards. If the inter-shard consensus is successful, the transaction request that has completed the inter-shard consensus will be written into the inter-shard block.

[0020] Thirdly, embodiments of this application provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the blockchain system sharding consensus method as described in the first aspect.

[0021] Fourthly, embodiments of this application provide a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the blockchain system sharding consensus method as described in the first aspect.

[0022] The first aspect of the technical solution provided by the embodiments of this disclosure brings at least the following beneficial effects: the sharding coordination module performs sharding operations on the blockchain system, including determining the transaction address, blockchain node, and public address corresponding to each shard, and determining the master node from the blockchain nodes included in each shard; for transaction requests that only include the transaction address and public address corresponding to the current shard, the nodes of each shard perform intra-shard consensus using the intra-shard consensus algorithm of the current shard, and write the transaction request that has completed intra-shard consensus into the intra-shard block if the intra-shard consensus is successful; for transaction requests that include public addresses corresponding to two or more shards, the master nodes of each shard perform inter-shard consensus using an inter-shard consensus algorithm, and write the transaction request that has completed inter-shard consensus into the inter-shard block if the inter-shard consensus is successful. The embodiments of this disclosure achieve synchronous consensus across different shards by sharding the blockchain; simultaneously, since a public address is set in each shard, a transaction in one shard does not need to rely on the execution results of other shards, thereby improving consensus efficiency.

[0023] It should be noted that the technical effects of any of the implementation methods in the second to fourth aspects can be found in the technical effects of the corresponding implementation methods in the first aspect, and will not be repeated here.

[0024] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings of the embodiments of this disclosure will be briefly described below. Clearly, the drawings described below only relate to some embodiments of this disclosure and are not intended to limit the scope of this disclosure.

[0026] Figure 1 A schematic diagram of a blockchain sharding consensus system according to some embodiments of the present disclosure is shown;

[0027] Figure 2 A schematic diagram of the on-chip structure of a blockchain sharding consensus system according to some embodiments of the present disclosure is shown;

[0028] Figure 3 A schematic diagram of the inter-chip block structure according to some embodiments of the present disclosure is shown;

[0029] Figure 4 This diagram illustrates a transaction transition across shards in a blockchain system according to some embodiments of this disclosure;

[0030] Figure 5 A flowchart illustrating a transaction method for cross-shard transactions in a blockchain system according to some embodiments of this disclosure is shown.

[0031] Figure 6 This diagram illustrates transaction backflow for cross-shard transactions in a blockchain system according to some embodiments of this disclosure;

[0032] Figure 7 A schematic diagram illustrating the main steps of a cross-shard transaction method for a blockchain system according to some embodiments of this disclosure is shown.

[0033] Figure 8 A schematic diagram illustrating the main steps of a blockchain system sharding consensus method according to at least one embodiment of the present disclosure is shown.

[0034] Figure 9 A schematic diagram of the main modules of a cross-sharding transaction apparatus according to at least one embodiment of the present disclosure is shown;

[0035] Figure 10 A schematic diagram of an electronic device according to at least one embodiment of the present disclosure is shown;

[0036] Figure 11 A schematic diagram of a readable storage medium according to at least one embodiment of the present disclosure is shown. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the described embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0038] Note that the examples described below are merely specific examples and are not intended to limit the embodiments of this disclosure to the specific shapes, hardware, connections, operations, values, conditions, data, sequences, etc., shown and described. Those skilled in the art can utilize the concepts of this disclosure to construct further embodiments not mentioned herein by reading this specification.

[0039] The terminology used in this disclosure is that which is currently widely used in the art in consideration of the functionality of this disclosure; however, these terms may vary depending on the intent, precedent, or new technology of those skilled in the art. Furthermore, specific terms may be chosen by the applicant, and in such cases, their detailed meanings will be described in the detailed description of this disclosure. Therefore, the terminology used in this specification should not be construed as simple names, but rather based on the meaning of the terms and the overall description of this disclosure.

[0040] To better understand the embodiments of this disclosure, the relevant terms involved in this disclosure will first be defined and explained.

[0041] Blockchain: refers to a chain-like data structure that combines data blocks sequentially in chronological order, and is a distributed ledger that is cryptographically guaranteed to be immutable and unforgeable. Essentially, it is a decentralized database. The blockchains referred to in this disclosure include public blockchains, consortium blockchains, private blockchains, and permissioned blockchains.

[0042] UTXO (Unspent Transaction Output): This refers to unspent transaction outputs. In the UTXO model, transactions are not based on account balances, but rather on recording and transferring value through transaction outputs and inputs. A UTXO is a data structure containing transaction data and corresponding executable code; all UTXO entries constitute the "ledger."

[0043] VRF (Verifiable Random Function) is a cryptographic primitive that combines randomness and verifiability. A VRF allows a user with a private key to generate a random number, and other users can use the corresponding public key to verify that the random number was indeed generated by that private key, while the specific value of the random number cannot be predicted.

[0044] It should be noted that the technical solutions in this disclosure, including the collection, updating, analysis, processing, use, transmission, and storage of user personal information, all comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. Necessary measures are taken to prevent unauthorized access to user personal information data and to safeguard user personal information security, network security, and national security.

[0045] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0046] Blockchain architecture typically employs a replica state machine model, where each node stores consistent transaction and state data. This architecture suffers from low consensus efficiency, impacting transaction performance and increasing system resource consumption. Theoretically, sharding the nodes in the blockchain network could reduce the number of consensus nodes, improve consensus efficiency, and enhance system performance. However, real-world transactions are highly complex. A typical UTXO transaction may involve multiple inputs and outputs, which may belong to a single shard or multiple shards. If belonging to a single shard, the transaction can be completed through intra-shard consensus, improving efficiency. If belonging to multiple shards, consensus on the next shard often requires the execution result of one shard, impacting transaction efficiency. Furthermore, the transmission of each consensus result increases the cost of cross-shard communication, further affecting system performance.

[0047] Therefore, embodiments of this disclosure provide a blockchain system sharding consensus method, apparatus, electronic device, and readable medium, which can improve the sharding consensus efficiency of the blockchain system.

[0048] Figure 1 A schematic diagram of a blockchain sharding consensus system 100 according to some embodiments of this disclosure is shown. This system 100 supports transaction operations such as transfers, but does not involve sharding of contract states; that is, UTXO-type cryptocurrencies do not have contract states and only support operations such as transfers. It should be noted that, generally speaking, transactions cannot be split when contract states are involved. The sharding consensus system 100 (i.e., the blockchain system) includes a sharding coordination module 110 and multiple shards (e.g.,... Figure 1The blockchain includes shards A (120), B (130), C (140), and D (150), each comprising four nodes. Nodes are the basic building blocks of a blockchain system, capable of running consensus algorithms and storing transaction and block information. In the embodiments of this disclosure, nodes within each shard can perform intra-shard consensus; the consensus algorithm used is not limited, and the consensus algorithms for different shards can be the same or different; the block production speed of each shard can also be the same or different. This disclosure is merely an example, illustratively listing four shards and four nodes within each shard; the actual number of shards and the number of nodes within each shard are not limited, and the number of nodes within each shard can also be different. Nodes can connect via private channels. It is understood that private channel connections can use various network communication protocols, such as TCP connections; for security reasons, IPSec leased lines can also be used.

[0049] The sharded consensus system 100 includes multiple users, who interact with the system by connecting to any node of the sharded consensus system 100. Each user possesses their own transaction address (or public key) for conducting transactions. For the UTXO model:

[0050] ----Input: Transaction input: UTXO structure, which is the output of the transaction indexed to the previous transaction.

[0051] ----Output: Transaction output: UTXO structure, including transaction address and amount.

[0052] The sharded consensus system 100 includes both node sharding and sharding of transaction addresses corresponding to different users during sharding initialization. For example, the initial number of users in each shard can be determined first. That is, in the initial stage, each shard has an initial fixed number of users as users (transaction addresses) within that shard. Transactions by users (transaction addresses) within a shard are considered intra-shard transactions. Users can send transaction requests to any node simultaneously. After receiving a transaction request, the node will inspect it. Taking a transaction with a single transaction input and a single transaction output as an example, if the node detects that the transaction input of the transaction request is not in its own shard, it will forward it to the corresponding shard; if both the transaction input and the transaction output are in the same shard, it is a transaction within that shard; if the transaction input is in the same shard but the transaction output is not, it is a cross-shard transaction. Therefore, after sharding, a single shard can process transactions related to the transaction addresses of that shard. For cross-shard transactions, transaction conversion is required first.

[0053] During the transaction conversion process, one or more public addresses need to be set in each shard (the public address referred to in this disclosure is the unified address of the shard, that is, all users in the shard use this unified public address to complete the transaction. When there is only one public address, all transaction addresses that need to conduct cross-shard transactions within the shard will transact with this public address. When there are multiple public addresses, the transaction addresses of this shard can be grouped, with each group corresponding to a different public address; or transactions at different times can correspond to different public addresses, or other methods in the art that can achieve group correspondence can be used for grouping). This public address serves as the intermediate address for completing the transaction and transacts with the transaction input or transaction output. The setting of the public address for each shard is very flexible. It can be the address of the shard leader node, or any one or more public addresses specified within the shard. If the address of the shard leader node is used as the public address, it is no longer necessary to specify it separately and complete consensus in the blockchain system. Especially when the shard is adjusted, it can be changed along with the leader node. Therefore, using the address of the shard leader node as the public address is more convenient. If the public address is one or more public addresses determined within a shard, it can be maintained by the inter-shard ledger, thus achieving independent decoupling from the master node within the shard, and the setting of the public address will be more flexible.

[0054] As mentioned earlier, based on the differences in transaction inputs and outputs during the transaction process, transactions can be divided into two types:

[0055] This shard transaction means that both the transaction input and output are entirely within this shard. In this case, if a user or a node from another shard (if a user sends a transaction request to a node in another shard, that node can forward it to a node in this shard) sends a transaction request to any node in this shard, the transaction request can be consensus-driven within this shard.

[0056] Cross-shard transactions refer to transactions whose inputs and / or outputs include addresses outside the current shard. In this case, the transaction needs to be converted into multiple sub-transactions, including: intra-shard input transactions, inter-shard transactions, and intra-shard output transactions. Intra-shard input transactions are between each transaction input and the first public address of its respective shard; intra-shard output transactions are between each transaction output and the second public address of its respective shard; and inter-shard transactions are between the first and second public addresses. It is understood that a single transaction can include multiple transaction inputs and multiple transaction outputs, and these inputs and outputs can reside in different shards. Therefore, the first public address mentioned in this disclosure includes all public addresses of the shards containing each transaction input, and the second public address also includes all public addresses of the shards containing each transaction output; that is, the terms "first" and "second" are not intended to limit their number.

[0057] The fragmentation coordination module 110 includes a VRF module 111, an inter-fragment consensus algorithm 112, a fragmentation management module 113, and a fragmentation network routing module 114. Figure 1 In the blockchain system example, there are four shards, each containing four nodes. The shards in the blockchain system can be allocated by the VRF module 111 of the shard coordination module 110, and the number of nodes in each shard is not limited. The initialization function of the VRF module 111 can include:

[0058] ----Initialize node sharding. The VRF module 111 is used to randomly shard transaction addresses and nodes in the blockchain system, and the results of this random sharding can be verified. For public blockchains with a large number of nodes that are not mutually trusting, random sharding and verification of its randomness are necessary. However, for permissioned blockchains with a smaller number of nodes, and where each node is somewhat trustworthy, random sharding using the VRF module 111 can be omitted, and pre-configured sharding can be used as an alternative.

[0059] ----Initialize transaction addresses. Use VRF module 111 to fragment transaction addresses corresponding to different users, that is, determine which fragment a transaction address corresponding to a different user belongs to, and within which fragment in which in-fragment transactions can be performed.

[0060] ---- Randomly select the master node. All nodes in the blockchain system simultaneously support both inter-shard consensus algorithm 112 and intra-shard consensus algorithm 162. Figure 2 This means that all nodes have the same functionality. Therefore, any node can potentially serve as the master node within a shard and as the master node between shards. The VRF module 111 can randomly select the master node within each shard as the master node for intra-shard consensus. The master node within each shard participates in inter-shard consensus; when a transaction is written to the inter-shard consensus ledger composed of all master nodes, all other master nodes will receive it. The VRF module 111 can also randomly select the inter-shard consensus master node from among the master nodes of each shard. Communication between inter-shard master nodes can be achieved through inter-shard consensus or through inter-shard network channels (such as P2P networks).

[0061] ----Determine the public address. Use the VRF module 111 to determine one or more public addresses from the transaction addresses corresponding to each shard. The public address can be the address of the master node of each shard.

[0062] The generation and updating of the master node for inter-slice consensus is determined by the specific consensus algorithm. This disclosure does not limit the specific consensus algorithms for intra-slice consensus and inter-slice consensus (for example, BFT (Byzantine Fault Tolerance) consensus algorithm, CFT (Crash Fault Tolerance) consensus algorithm, etc. can be used), nor does it limit intra-slice consensus algorithm 162 and inter-slice consensus algorithm 112 to be consistent. In the embodiments of this disclosure, it is preferred that inter-slice consensus uses a rotating master node, while intra-slice consensus uses a fixed master node, because intra-slice consensus requires the master node to synchronize transactions to inter-slice in real time. If its master node is not fixed, a faster synchronization frequency is required. Therefore, a fixed master node can reduce the synchronization frequency requirement. However, it is understood that if the synchronization frequency is high, the master node of intra-slice consensus can also be adjusted or changed.

[0063] Once the VRF module 111 completes its initialization, it generally does not make overall changes to the shards, nor does it provide the option for nodes to switch directly from one shard to another while simultaneously migrating data. Adjustments to node shards are achieved through node addition and removal; that is, it supports adding and removing nodes, indirectly completing the switch between shards. For example, if a node leaves a shard and joins a new shard, for both shards, it is simply a matter of one node leaving or joining, without establishing any association between them.

[0064] Therefore, when a new transaction address is added to the blockchain system, the sharding coordination module 110 can assign the new transaction address to an existing shard; when a new node is added to the blockchain system, the sharding coordination module 110 assigns the new node to an existing shard. After the new node determines its shard assignment, it synchronizes the blocks within its shard to conduct subsequent intra-shard consensus.

[0065] Sharding management module 113 manages the sharding status of the blockchain sharding consensus system 100, including the nodes, transaction addresses, and current master node of each shard. When sharding changes, it updates the information promptly and synchronizes it with other shards. For example, when the master node of a shard is adjusted, it updates the latest sharding information and synchronizes it to the sharding network router 114. Sharding management module 113 may also include public address management, supporting shard registration and updates. If the ledger supports smart contracts, smart contracts on the inter-shard ledger that have undergone inter-shard consensus can also be used for management. Sharding network router 114 communicates between the master nodes of each shard to achieve inter-shard consensus.

[0066] Figure 2Taking shard A 120 as an example, a schematic diagram of the intra-shard structure of a blockchain sharding consensus system according to some embodiments of this disclosure is shown. This shard exemplarily includes four nodes: node A-1 121, node A-1 122, node A-1 123, and node A-1 124. Each node is a replica state machine model, meaning that the node functions and stored data are identical. Each node internally includes a transaction pool model and a storage module. The transaction pool model comprises two parts, responsible for intra-shard transaction processing 121-1 and inter-shard transaction conversion 121-2, respectively. The storage module also comprises two parts: intra-shard data storage 121-3 and inter-shard data storage 121-4.

[0067] Within a node, in addition to the transaction pool model and storage module, an intra-shard coordination module A 125 is further abstracted (i.e., each node includes this intra-shard coordination module A 125), which includes a synchronization inter-shard coordination module 161 that synchronizes inter-shard information with the shard network routing 114, an intra-shard consensus algorithm 162, a shard master node information module 163 that can support storing and updating the latest master node information, and a transaction monitoring module 164 that is responsible for monitoring transaction requests within the shard.

[0068] Figure 3 A schematic diagram of an inter-shard block structure 300 according to some embodiments of this disclosure is shown. The intra-shard blocks formed after intra-shard consensus are the conventional block structure of a blockchain system and will not be described in detail here. The inter-shard block structure 300 includes a block header 310 and a block body 320. The block body further includes a cross-shard transaction list 321 and a list of the latest block hashes within the shard 322. Sharding technology increases throughput by dividing the network into multiple smaller shards. Since each shard has a small number of nodes, an attacker can control a shard at a low cost, and security is compromised to some extent. In other words, due to sharding, the number of nodes within each shard is small, resulting in relatively low security. For example, if a shard has only 4 nodes, breaching 3 or more nodes can completely control the shard. After breaching, shard transaction records can be forged from scratch. Therefore, it is necessary to confirm the results of blocks within a shard with other shards to improve transaction security. However, storing all records of blocks within each shard would require significant storage space. Therefore, a more efficient approach is to store the hash values ​​of the blocks within each shard, forming a list of the latest block hashes within each shard. This list provides a unified proof between shards, supporting data verification for any potential intra-shard data needs. Thus, the hash values ​​of the blocks within each shard can be used for inter-shard consensus among the master nodes of each shard, and if inter-shard consensus is successful, the transaction request completing the inter-shard consensus is written into the inter-shard block.

[0069] Additionally, it is understandable that for inter-shard blocks formed after inter-shard consensus, the number of hash values ​​of each shard included in the latest block hash list 322 within a shard may differ because the block generation speed of each shard and the block generation speed of inter-shard blocks may be different during the shard consensus process of the blockchain system.

[0070] Figure 4 This diagram illustrates a transaction transformation process for cross-shard transactions in a blockchain system according to some embodiments of this disclosure. A node in shard A receives a transaction request to transfer the transaction addresses of two users, U1 and U2, within shard A to the transaction addresses of two users, U3 and U4, in shard B. Since the transaction input and output of this request belong to different shards, this transaction request is a cross-shard transaction A-1. Cross-shard transactions require transaction transformation, intra-shard consensus among different shards, and inter-shard consensus among the master nodes of each shard. For cross-shard transaction A-1, it forms two intra-shard transactions a-1 (i.e., input intra-shard transaction) and b-1 (i.e., output intra-shard transaction), and one inter-shard transaction A-2. The input intra-shard transaction a-1 is a transaction in which the transaction addresses (transaction inputs) of users U1 and U2 are transferred to the first public address of shard A (e.g., the transaction address of master node N1 of shard A). The inter-shard transaction A-2 is a transaction in which the first public address of shard A is transferred to the second public address of shard B (e.g., the transaction address of master node N2 of shard B). The b-1 transaction is a transaction in which the second public address of shard B is transferred to the transaction addresses (transaction outputs) of users U3 and U4.

[0071] After the transaction transformation is completed, inter-shard transaction A-2 achieves inter-shard consistency through inter-shard consensus, while the two intra-shard transactions a-1 and b-1 can each achieve intra-shard consistency through intra-shard consensus. It should be noted that the transformed intra-shard transaction b-1 can be sent to shard B via inter-shard consensus or an inter-shard network channel, or it can be sent from a node in shard A to a node in shard B via a private channel between nodes. Inter-shard transaction A-2 can be sent to the master node N1 of shard A via a private channel. When sent via a private channel or an inter-shard network channel, the three transformed transactions can undergo consensus in parallel, greatly improving consensus efficiency.

[0072] To ensure the atomicity of cross-shard transactions, the transaction is successful if intra-shard transaction b-1 achieves intra-shard consensus.

[0073] This shows that intra-shard consensus includes two scenarios: First, if both the transaction input and output of a transaction request originate from the current shard (both are transaction addresses within the current shard), intra-shard consensus can be directly performed to complete the transaction. Second, if the transaction input or output of a transaction request is not within the current shard, transaction transformation is performed. In the transformed transaction, the receiver or sender is the public address of the current shard, and the other party is the transaction address of the current shard. Therefore, nodes in each shard can perform intra-shard consensus among nodes within the current shard using the shard's intra-shard consensus algorithm for transaction requests that only include the transaction address and public address corresponding to the current shard. If intra-shard consensus is successful, the completed transaction request is written into the intra-shard block.

[0074] Inter-shard consensus only includes one scenario: the converted inter-shard transaction. The transaction request of this inter-shard transaction includes the public addresses corresponding to two or more shards. Inter-shard consensus is achieved between the master nodes of each shard using the inter-shard consensus algorithm. If the inter-shard consensus is successful, the transaction request that has completed the inter-shard consensus is written into the inter-shard block.

[0075] Figure 5 A flowchart of a transaction method 500 for cross-shard transactions in a blockchain system according to some embodiments of this disclosure is shown. Before proceeding with transaction method 500, system initialization is first completed, i.e., sharding is performed using the VRF module 111 (sharding can also be performed using other methods, such as pre-configuring sharding in the case of a permissioned blockchain), determining the nodes of each shard; synchronizing shard information and master node information within each shard; initializing the number of users, i.e., initially determining the number of users within each shard and the transaction addresses corresponding to the users; if the public address is not the address corresponding to the master node, the public address of each shard needs to be further determined. After initialization is completed, users can conduct transactions through this blockchain system. The specific transaction steps are as follows:

[0076] Step S501: Taking the first node (e.g., node A-1121) of the first shard (e.g., shard A120) of the blockchain system as an example, it receives a transaction request. The transaction request includes transaction inputs and outputs indexed to UTXOs (hereinafter referred to as "UTXO transaction inputs" and "UTXO transaction outputs"). The sender of the transaction request can be a user or a node of another shard. If the transaction request comes from a node of another shard, it is generally because the node of that other shard received a transaction request and, after judgment, determined that the transaction input of the transaction request does not belong to a user of its own shard. Therefore, it sends the request to the first node of the first shard through a private channel, inter-shard consensus, or inter-shard network channel. Understandably, if nodes in other shards know which shard the transaction input of a UTXO belongs to, they can directly transfer it to the corresponding shard via a private channel. If, due to network latency or other reasons, nodes in other shards do not know which shard the transaction input of a UTXO belongs to, they can synchronize to each shard through inter-shard consensus or inter-shard network channels. Each shard checks whether the transaction input includes the UTXO, and the shard containing the transaction input of the UTXO executes the subsequent transactions. In this embodiment, the first node of the first shard executes the subsequent steps.

[0077] In step S502, the first node determines whether the first shard is the shard containing all or part of the transaction inputs of the UTXOs. Generally, if the transaction request comes from a node in another shard, since the other shard nodes have already made their determinations, the first shard is usually the shard containing all or part of the transaction inputs of the UTXOs. It is understandable that due to network communication issues, other shard nodes may also make transmission errors. Therefore, the first node can also first determine whether the first shard is the shard containing the transaction inputs for transaction requests sent by other shard nodes. If the determination is negative, it can forward the request to the shard containing the transaction inputs or send a transaction failure notification to the node that sent the transaction request. If the transaction request comes from a user, it is generally necessary to make a determination first. If it is determined that the first shard is not the shard containing the transaction inputs of the UTXOs, the first node will forward the transaction request to the shard containing the transaction inputs or send a transaction failure notification to the user who sent the transaction request.

[0078] If the first node determines that the first shard is only the shard containing the transaction inputs of some UTXOs, it means that the transaction is a cross-shard transaction, and then proceeds to step S504. If the first node determines that the first shard is the shard containing the transaction inputs of all UTXOs, then further judgment is needed for the transaction, and step S503 is executed.

[0079] In step S503, the first node continues to determine whether the first shard is entirely the shard where the transaction output is located. If so, it means that all the transaction inputs and outputs involved in the transaction request belong to the first shard, and the transaction is an intra-shard transaction in the first shard. Intra-shard consensus can be performed in the first shard (step S504') to complete the transaction. If not, step S504 is executed.

[0080] Step S504: The first node performs transaction conversion. Before conversion, the shards containing each transaction input and output are determined. That is, before intra-shard consensus and inter-shard consensus, nodes in each shard perform transaction conversion for transaction requests that include transaction addresses corresponding to two or more shards. For example, a transaction's input shards include shard A 120 (whose public address is public address A) and shard B 130 (whose public address is public address B), where shard A 120 is the first shard and shard B 130 is the second shard. The transaction output shards include shard C 140 (whose public address is public address C) and shard D 150 (whose public address is public address D), where shard C 140 is the third shard and shard D 150 is the fourth shard. It should be noted that in the embodiments of this disclosure, the second, third, and fourth shards may each include one or more shards, and each has a public address. The multiple sub-transactions converted by the transaction request include: input intra-shard transactions (step S505), inter-shard transactions (step S506), and output intra-shard transactions (step S507). Input intra-shard transactions are transactions between the transaction input and the first public address of the shard in which it resides (i.e., the first intra-shard transaction where the transaction input in shard A 120 is transferred to public address A and the second intra-shard transaction where the transaction input in shard B 130 is transferred to public address B). Output intra-shard transactions are transactions between the transaction output and the second public address of the shard in which it resides (i.e., the third intra-shard transaction where public address C is transferred to the transaction output in shard C 140 and the fourth intra-shard transaction where public address D is transferred to the transaction output in shard D 150). Inter-shard transactions are transactions between the first public address and the second public address (i.e., transactions transferred from public address A and public address B to public address C and public address D). Understandably, before performing transaction conversion, node A can determine the shard where other transaction inputs are located (i.e., shard B 130 in this embodiment) and the shard where transaction outputs are located (i.e., shard C 140 and shard D 150 in this embodiment) based on the information managed and synchronized to each shard by shard management module 113, and can determine the common address of each shard to perform transaction conversion.

[0081] In other words, Figure 5The process of jumping from step S502 to step S504 differs somewhat from the process of continuing to step S504 from step S503. When jumping from step S502 to step S504, shard A 120 is the shard containing a portion of the transaction inputs. During transaction conversion, it is necessary to determine the second shard (i.e., shard B 130 in this embodiment) containing the remaining portion of the transaction inputs. Therefore, the input intra-shard transaction also includes the second intra-shard transaction, which is the transaction between the transaction inputs included in shard B 130 and the public address B. The first node sends the second intra-shard transaction to enable intra-shard consensus in the second shard. However, in the process of continuing to step S504 from step S503, the first shard is the shard containing all transaction inputs; in this case, it is only necessary to determine all the shards containing the transaction outputs.

[0082] The converted output intra-shard transactions are sent to the target shard via private channels, inter-shard consensus, or inter-shard network channels. It's understandable that using inter-shard consensus for transmission means each master node will store relevant information, resulting in some redundant storage.

[0083] Based on transaction transformation, it can be understood that in cross-shard transactions, after the first node initiates a proposal, it performs intra-shard consensus on all or part of the input intra-shard transactions and sends inter-shard transactions and output intra-shard transactions. This allows inter-shard transactions to achieve inter-shard consensus among the master nodes of each shard, and output intra-shard transactions to achieve intra-shard consensus in the shard where the transaction output is located. Furthermore, it should be noted that in one or more embodiments of this disclosure, the receipt or forwarding of transaction requests, the sending of transaction failure notifications, the sending of inter-shard transactions, the sending of output intra-shard transactions, and the sending of second intra-shard transactions can all be implemented through one or more of private channels, inter-shard consensus, and inter-shard network channels.

[0084] Step S508: If the transaction is successful, the transaction is completed; if the transaction fails, a rollback transaction is constructed (step S509'). Preferably, to ensure the atomicity of the transaction, if the output intra-slice transaction achieves intra-slice consensus, the transaction request in the original slice (i.e., slice A 120 in this embodiment) is determined to have a successful final transaction result; if the output intra-slice transaction fails to achieve intra-slice consensus, and the input intra-slice transaction and / or inter-slice transaction achieve consensus, a rollback transaction is constructed for the input intra-slice transaction and / or inter-slice transaction that has achieved consensus, thereby rolling back the state update caused by the transaction.

[0085] Figure 6This diagram illustrates a transaction rollback diagram for cross-shard transactions in a blockchain system according to some embodiments of this disclosure. For cross-shard transaction A-1, after transaction conversion, three transactions are formed: intra-shard transaction a-1, intra-shard transaction b-1, and inter-shard transaction A-2. If intra-shard transaction b-1 succeeds, then cross-shard transaction A-1 succeeds; if intra-shard transaction b-1 fails, but intra-shard transaction a-1 and inter-shard transaction A-2 have reached consensus, then corresponding rollback transactions need to be constructed, namely intra-shard rollback transaction a-2 and inter-shard rollback transaction B-1, to revert the state update caused by the previous transactions to the original state. Specifically, intra-shard rollback transaction a-2 is a transaction from the first public address of shard A (e.g., the transaction address of shard A's master node N1) to the transaction addresses of users U1 and U2; inter-shard rollback transaction B-1 is a transaction from the second public address of shard B (e.g., the transaction address of shard B's master node N2) to the first public address of shard A. Understandably, for transactions where no consensus has been reached, there is no need to construct a backoff transaction.

[0086] Figure 7 A schematic diagram illustrating the main steps of a cross-shard transaction method 700 for a blockchain system according to some embodiments of the present disclosure is shown. The blockchain system includes at least two shards, each shard including a master node. The master nodes of each shard perform inter-shard consensus, and the nodes within each shard perform intra-shard consensus. The cross-shard transaction method 700 for the blockchain system includes:

[0087] Step S701: The first node of the first shard of the blockchain system receives a transaction request, wherein the transaction request includes transaction inputs and transaction outputs indexed to UTXOs;

[0088] Step S702: The first node performs transaction conversion, converting the transaction request into multiple sub-transactions, including: input intra-shard transaction, inter-shard transaction, and output intra-shard transaction. The input intra-shard transaction is the transaction between the transaction input and the first public address of the shard where it is located. The output intra-shard transaction is the transaction between the transaction output and the second public address of the shard where it is located. The inter-shard transaction is the transaction between the first public address and the second public address. The first shard is the shard in the blockchain system where all or part of the transaction inputs are located.

[0089] In step S703, the first node initiates a proposal to achieve intra-shard consensus on all or part of the input intra-shard transactions in the first shard, and sends inter-shard transactions and output intra-shard transactions so that inter-shard transactions can achieve inter-shard consensus among the master nodes of each shard, and output intra-shard transactions can achieve intra-shard consensus in the shard where the transaction output is located.

[0090] Figure 8A schematic diagram illustrating the main steps of a blockchain system sharding consensus method 800 according to at least one embodiment of the present disclosure is shown. The blockchain system includes a sharding coordination module 110 and multiple blockchain nodes. The blockchain system sharding consensus method 800 includes:

[0091] The sharding coordination module 110 performs sharding operations on the blockchain system, including determining the transaction address, blockchain node and public address corresponding to each shard, and determining the master node from the blockchain nodes included in each shard.

[0092] For transaction requests received that only include the transaction address and public address corresponding to this segment, the nodes of each segment use the segment's intra-segment consensus algorithm to achieve intra-segment consensus. If the intra-segment consensus is successful, the transaction request that has completed the intra-segment consensus is written into the intra-segment block.

[0093] For transaction requests that include public addresses corresponding to two or more shards, the master nodes of each shard use an inter-shard consensus algorithm to achieve inter-shard consensus among the master nodes of each shard. If the inter-shard consensus is successful, the transaction request that has completed the inter-shard consensus is written into the inter-shard block.

[0094] It should be noted that, in addition to inter-shard consensus, the master node of each shard also participates in the intra-shard consensus process as a node within the shard.

[0095] Figure 9 A schematic diagram of the main modules of a cross-shard transaction device 900 for a blockchain system according to at least one embodiment of the present disclosure is shown. The blockchain system includes at least two shards, each shard including a master node. The master nodes of each shard perform inter-shard consensus, and the nodes within each shard perform intra-shard consensus. The cross-shard transaction device 900 is disposed at the first node of the first shard of the blockchain system and includes:

[0096] The transceiver module 910 is configured to receive transaction requests, wherein the transaction request includes transaction inputs and transaction outputs of the UTXO;

[0097] The transaction conversion module 920 is configured to perform transaction conversion, converting a transaction request into multiple sub-transactions, including: input intra-segment transactions, inter-segment transactions, and output intra-segment transactions. The input intra-segment transactions are transactions between the transaction input and the first public address of the segment in which it resides. The output intra-segment transactions are transactions between the transaction output and the second public address of the segment in which it resides. The inter-segment transactions are transactions between the first public address and the second public address. The first segment is the segment in the blockchain system where all or part of the transaction inputs reside.

[0098] The transaction execution module 930 is configured to initiate a proposal and conduct intra-segment consensus on all or part of the input intra-segment transactions in the first segment.

[0099] The transceiver module 910 is further configured to send inter-segment transactions and output intra-segment transactions, so that inter-segment transactions can achieve inter-segment consensus among the master nodes of each segment, and intra-segment transactions can achieve intra-segment consensus in the segment where the transaction is output.

[0100] It should be noted that the above application scenarios are merely exemplary, intended to describe one or more aspects of this disclosure in specific scenarios. However, these aspects are not essential, and various modifications can be made to the application scenario. It is readily understood that the specific application scenarios described in this disclosure are not limited.

[0101] At least some embodiments of this disclosure also provide an electronic device. Figure 10 A schematic diagram of an electronic device 1000 according to at least one embodiment of the present disclosure is shown.

[0102] like Figure 10 As shown, the electronic device 1000 includes one or more processors 1010 and a memory 1020. The memory 1020 includes one or more computer program modules 1021. The one or more computer program modules 1021 are stored in the memory 1020 and configured to be executed by the processor 1010. These computer program modules 1021 include instructions for executing a blockchain system sharding consensus method 800 and its additional aspects according to at least one embodiment of the present disclosure. When executed by the processor 1010, they can perform one or more steps of the blockchain system sharding consensus method 800 and its additional aspects according to at least one embodiment of the present disclosure. The memory 1020 and the processor 1010 can be interconnected via a bus system and / or other forms of connection mechanisms (not shown). For example, the bus can be a Peripheral Component Interconnect Standard (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc.

[0103] For example, processor 1010 may be a central processing unit (CPU), a digital signal processor (DSP), or other processing unit with data processing capabilities and / or program execution capabilities, such as a field-programmable gate array (FPGA). Processor 1010 may be a general-purpose processor or a special-purpose processor, capable of controlling other components in electronic device 1000 to perform desired functions.

[0104] Exemplarily, memory 1020 may include any combination of one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), USB memory, flash memory, etc. One or more computer program modules 1021 may be stored on the computer-readable storage medium, and processor 1010 may run one or more computer program modules 1021 to implement various functions of electronic device 1000. The computer program modules include multiple computer-executable instructions. Various application programs and various data, as well as various data used and / or generated by the application programs, may also be stored in the computer-readable storage medium.

[0105] For example, electronic device 1000 may also include input devices such as touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, and gyroscopes; output devices such as liquid crystal displays, speakers, and vibrators; storage devices such as magnetic tapes and hard disks (HDDs or SDDs); and communication devices such as network interface cards like LAN cards and modems. The communication devices allow electronic device 1000 to communicate wirelessly or wiredly with other devices to exchange data and perform communication processing via networks such as the Internet. A drive is connected to the I / O interface as needed. Removable storage media, such as disks, optical disks, magneto-optical disks, and semiconductor memories, are installed on the drive as needed so that computer programs read from them can be installed into the storage device as required.

[0106] For example, the electronic device 1000 may further include a peripheral interface (not shown in the figure). This peripheral interface can be of various types, such as a USB interface, a Lightning interface, etc. The communication device can communicate wirelessly with networks and other devices, such as the Internet, intranets and / or wireless networks such as cellular telephone networks, wireless local area networks (LANs) and / or metropolitan area networks (MANs). Wireless communication can use any of a variety of communication standards, protocols, and technologies, including but not limited to Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), Wideband Code Division Multiple Access (W-CDMA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Bluetooth, Wi-Fi (e.g., based on IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, and / or IEEE 802.11n standards), Voice over Internet Protocol (VoIP), Wi-MAX, protocols for email, instant messaging, and / or Short Message Service (SMS), or any other suitable communication protocol.

[0107] The electronic device 1000 may be a system-on-a-chip (SOC) or a device including the SOC. For example, it may be any device such as a mobile phone, tablet computer, laptop computer, e-reader, game console, television, digital photo frame, navigator, home appliance, communication base station, industrial controller, server, etc. It may also be any combination of data processing device and hardware. The embodiments of this disclosure do not limit this. The specific functions and technical effects of the electronic device 1000 can be referred to the description above of the blockchain system sharding consensus method 800 and its additional aspects according to at least one embodiment of this disclosure, and will not be repeated here.

[0108] Figure 11 A schematic diagram of a readable storage medium 1100 according to at least one embodiment of the present disclosure is shown.

[0109] like Figure 11 As shown, a computer program 1110 is stored on a readable storage medium 1100, which is a computer-readable storage medium. When the computer program 1110 is executed by a processor, it performs one or more steps of the blockchain system sharding consensus method 800 and its additional aspects as described above.

[0110] For example, when the program code is read by a computer, the computer can execute the program code stored in the computer storage medium to perform one or more steps to implement, for example, the blockchain system sharding consensus method 800 and its additional aspects according to at least one embodiment of the present disclosure.

[0111] For example, the readable storage medium may include a memory card of a smartphone, a storage component of a tablet computer, a hard disk of a personal computer, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), flash memory, and other readable storage media or any combination thereof. The readable storage medium 1100 may be a non-transitory readable storage medium.

[0112] At least some of the embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other.

[0113] It should be noted that, in this disclosure, relational terms such as "first," "second," etc., are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0114] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved; that is, the preceding or following operations are not necessarily executed precisely in sequence. Instead, various steps may be processed in reverse order or simultaneously as needed. Furthermore, other operations may be added to these processes, or one or more operations may be removed from these processes.

[0115] The units described in the embodiments of this disclosure can be implemented in software or hardware. The described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0116] The following points should be noted regarding this disclosure:

[0117] (1) The accompanying drawings of the embodiments of this disclosure only involve the structures involved in the embodiments of this disclosure. Other structures can be referred to the general design.

[0118] (2) Where there is no conflict, the embodiments of this disclosure and the features in the embodiments can be combined with each other to obtain new embodiments.

[0119] The above description is merely an exemplary embodiment of this disclosure and is not intended to limit the scope of protection of this disclosure, which is determined by the appended claims.

Claims

1. A sharding consensus method for a blockchain system, characterized in that, The blockchain system includes a sharding coordination module and multiple blockchain nodes, and the method includes: The sharding coordination module performs sharding operations on the blockchain system, including determining the transaction address, blockchain node, and public address corresponding to each shard, and determining the master node from the blockchain nodes included in each shard. For each shard, when a transaction request is received that includes only the transaction address and public address corresponding to its shard, the nodes of that shard shall use the intra-shard consensus algorithm of that shard to achieve intra-shard consensus. If the intra-shard consensus is successful, the transaction request that has completed the intra-shard consensus shall be written into the intra-shard block. For transaction requests that include public addresses corresponding to two or more shards, the master nodes of each shard shall use an inter-shard consensus algorithm to achieve inter-shard consensus among the master nodes of each shard, and write the transaction request that has completed the inter-shard consensus into the inter-shard block if the inter-shard consensus is successful. The hash values ​​of the intra-shard blocks in each shard are consensused among the master nodes of each shard, and if the inter-shard consensus is successful, the hash values ​​of the completed inter-shard consensus are written into the inter-shard block.

2. The method according to claim 1, characterized in that, Before the intra-shard consensus and inter-shard consensus are performed, each shard node performs transaction conversion for transaction requests that include transaction addresses corresponding to two or more shards.

3. The method according to claim 1, characterized in that, The sharding coordination module includes a verifiable random function module, which performs one or more of the following operations: determining the transaction address, the blockchain node, the public address, and the master node of each shard.

4. The method according to claim 1 or 3, characterized in that, When a new transaction address is added to the blockchain system, the sharding coordination module assigns the new transaction address to an existing shard.

5. The method according to claim 1 or 3, characterized in that, When a new node is added to the blockchain system, the sharding coordination module assigns the new node to an existing shard. After the new node determines its shard affiliation, it synchronizes the blocks within its shard.

6. The method according to claim 1, characterized in that, The common address of each shard is the address of the master node of each shard.

7. A blockchain system, characterized in that, The blockchain system includes a sharding coordination module and multiple blockchain nodes, wherein: The sharding coordination module is configured to perform sharding operations on the blockchain system, including determining the transaction address, blockchain node, and public address corresponding to each shard, and determining the master node from the blockchain nodes included in each shard. Each node in the shard is configured to perform intra-shard consensus using the intra-shard consensus algorithm of the shard when a transaction request that includes only the transaction address and public address corresponding to the shard is received. If the intra-shard consensus is successful, the transaction request that has completed the intra-shard consensus is written into the intra-shard block. The master nodes of each shard are configured to perform inter-shard consensus using an inter-shard consensus algorithm when a transaction request that includes public addresses corresponding to two or more shards is received. If the inter-shard consensus is successful, the transaction request that has completed the inter-shard consensus is written into the inter-shard block. The master nodes of each shard are further configured to perform inter-shard consensus on the hash values ​​of the intra-shard blocks of each shard among the master nodes of each shard, and write the hash values ​​of the completed inter-shard consensus into the inter-shard block if the inter-shard consensus is successful.

8. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-6.

9. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-6.

Images