CN113064764B

CN113064764B - Method and apparatus for executing blocks in a blockchain system

Info

Publication number: CN113064764B
Application number: CN202110419704.2A
Authority: CN
Inventors: 郑子彬; 徐泉清; 郑沛霖; 闫莺; 张辉
Original assignee: Alipay Hangzhou Information Technology Co Ltd; Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2021-04-19
Filing date: 2021-04-19
Publication date: 2023-10-27
Anticipated expiration: 2041-04-19
Also published as: CN113064764A

Abstract

The embodiments of the present specification provide a method and apparatus for executing a block in a blockchain system, the blockchain system including a first slice including a first node therein, the method being performed by the first node, including: receiving first information from the second fragments in the process of executing a first block, wherein the first information indicates a first transaction which is executed in error in n transactions belonging to the first block, and the first information is sent by the second fragments after the first cross-fragment sub-transaction corresponding to the first transaction fails to be executed, and the first cross-fragment sub-transaction is a cross-fragment sub-transaction belonging to a second block in the second fragments; re-executing the plurality of transactions of the n transactions after the first transaction is removed.

Description

Method and apparatus for executing blocks in a blockchain system

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technology, and more particularly, to a method and apparatus for executing blocks in a blockchain system.

Background

The blockchain is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like, is essentially a shared database, stores data or information in the shared database, and has the characteristics of difficult tampering, decentralization and the like. The blockchain technology has great application potential in the scenes of finance, public welfare, judicial, transaction and the like.

One important factor currently limiting the large-scale floor-standing application of blockchain technology is performance, which mainly includes throughput, which can be measured generally by transaction number per second (Transaction Per Second, abbreviated TPS). Various schemes have been proposed by developers to attempt to improve the throughput of a block, a process called "capacity expansion". Blockchain slicing is a scheme used to expand blockchains. The basic idea of blockchain slicing is to divide nodes in a blockchain network into a number of relatively independent subnetworks, each of which constitutes a blockchain, a subnetwork, i.e. a slice (card). The throughput of the whole network can be improved through parallel processing of a plurality of fragments.

In blockchain systems that include slices, execution of a transaction in one slice may result in sub-transactions that are executed across slices, in which case execution of the transaction and execution of its sub-transactions need to satisfy transaction atomicity, i.e., both must succeed or fail at the same time, without allowing for intermediate state execution results. To address this problem, atomicity of transactions in a block is guaranteed in a sharding scheme by introducing a 2-phase client driven "lock/unlock" protocol. In another slicing scheme, an atomic concept similar to a flexible transaction is proposed, that is, the atomic characteristic of the transaction is reflected after the transaction is completely executed for a period of time. In addition, two-phase commit is performed by the committee coordinator in yet another sharding scheme, thereby solving the atomicity problem of blockchain transactions.

Disclosure of Invention

Embodiments of the present disclosure are directed to a more efficient solution to executing blocks to more efficiently address the atomicity of transactions.

To achieve the above object, one aspect of the present specification provides a method of executing a block in a blockchain system, the blockchain system including a first slice including a first node therein, and a second slice, the method being performed by the first node, including:

receiving first information from the second fragments in the process of executing a first block, wherein the first information indicates a first transaction which is executed in error in n transactions belonging to the first block, and the first information is sent by the second fragments after the first cross-fragment sub-transaction corresponding to the first transaction fails to be executed, and the first cross-fragment sub-transaction is a cross-fragment sub-transaction belonging to a second block in the second fragments;

re-executing the plurality of transactions of the n transactions after the first transaction is removed.

Another aspect of the present specification provides an apparatus for executing a block in a blockchain system, the blockchain system including a first slice including a first node therein, the apparatus deployed at the first node, comprising:

a receiving unit, configured to receive, in a process of executing a first block, first information from the second slice, where the first information indicates a first transaction that is performed in error among n transactions belonging to the first block, where the first information is sent by the second slice after a failure in performing a first cross-slice sub-transaction corresponding to the first transaction, and the first cross-slice sub-transaction is a cross-slice sub-transaction belonging to a second block in the second slice;

and the re-executing unit is used for re-executing a plurality of transactions after the first transaction is removed in the n transactions.

Another aspect of the present description provides a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform any of the methods described above.

Another aspect of the present description provides a computing device comprising a memory having executable code stored therein and a processor that, when executing the executable code, performs any of the methods described above.

According to the block execution scheme provided by the embodiment of the specification, by carrying out state rollback and block playback on the error transaction, efficient error transaction rejection is realized, transaction atomicity in the block execution process is ensured, in addition, by carrying out fragment broadcasting on the error transaction information among the mutually trusted nodes of each fragment, efficient broadcasting on the error transaction information is provided, and the block execution efficiency in a block chain system is improved.

Drawings

The embodiments of the present specification may be further clarified by describing the embodiments of the present specification with reference to the accompanying drawings:

FIG. 1 illustrates an architecture diagram of a blockchain system in accordance with an embodiment;

FIG. 2 is a schematic diagram illustrating a process of executing blocks in a blockchain system in accordance with embodiments of the present disclosure;

FIG. 3 is a schematic diagram of another process for executing blocks in a blockchain system in accordance with embodiments of the present disclosure;

FIG. 4 is a flowchart of a method for executing blocks in a blockchain system provided by embodiments of the present disclosure;

fig. 5 shows a device architecture diagram of executing blocks in a blockchain system in accordance with embodiments of the present description.

Detailed Description

Embodiments of the present specification will be described below with reference to the accompanying drawings.

As previously mentioned, the slicing technique aims to improve the throughput of the block. Specifically, the slicing technique can be divided into three kinds according to different slicing mechanisms: network sharding, transaction sharding (transaction sharding), state sharding (state sharding). Network slicing is the most basic one, including dividing the entire blockchain network into multiple sub-networks, i.e., multiple slices. In this way, multiple tiles in a blockchain network may process different transactions in the network in parallel. The transaction segmentation is to distribute the transaction to different segments according to a certain rule, thereby achieving the purpose of parallel processing. The precondition for transaction fragmentation is that network fragmentation is first performed. The key to state slicing is to separate the whole memory area, so that different slices store the states of different accounts, and each slice is only responsible for storing the world state of a part of the accounts, rather than the world state of all the accounts of the memory area block chain system. State slicing can solve the problem of the bottleneck of the energy storage capacity. The solution provided in the embodiment of the present disclosure may be applied to state slicing, and it may be understood that the solution in the embodiment of the present disclosure may also be applied to other types of slicing.

The blockchain network is divided into a plurality of slices, and then the processing of cross-slice services is involved, so that the transaction atomicity problem exists. The embodiments of the present disclosure provide a scheme for executing blocks, in which blocks are re-executed after block error transactions are removed by broadcasting in slices, so that transaction atomicity is ensured. Hereinafter, a block execution scheme provided by the embodiments of the present specification will be described taking the block chain system according to the embodiments of the present specification as an example, which is illustrated in fig. 1.

FIG. 1 illustrates a block chain system architecture diagram according to one embodiment. As shown in fig. 1, the blockchain system may include a slice 1, a slice 2, and a slice 3 (not shown in fig. 1), where a plurality of nodes of mutual trust of different slices may form a set, and the set may include 3 nodes respectively belonging to 3 slices, where the nodes may be implemented as any apparatus, server, or device cluster having computing, processing capabilities, and so on. Wherein, a blockchain can be built by a node in the same slice, specifically, for example, a blockchain 1 can be built by nodes 1A, 1B and 1C in slice 1, a blockchain 2 can be built by nodes 2A, 2B and 2C in slice 2, and a blockchain 3 can be built by nodes 3A, 3B and 3C in slice 3. A consensus is made between the participant nodes within each slice. For example, the blockchain system may be a federated chain system, where federated party a, federated party B, federated party C, and federated party D may be included, each federated party being a collection of multiple nodes that include the mutual trust of different shards as described above. It is to be appreciated that fig. 1 is merely exemplary showing three shards and four federated parties, and that virtually any number of shards and federated parties may be included in a blockchain system. The following description will take an example of a federated chain system, and it is to be understood that the present embodiments are not limited to application to federated chain systems, but may be applied to any blockchain system.

In the blockchain system shown in fig. 1, a plurality of nodes included in one federation party, each belonging to a different shard, may be connected through an intranet of the federation party, for example. When one of the fragments in the system needs to send a cross-fragment sub-transaction to the other fragment, cross-fragment communication can be performed in the nodes of the two fragments of one alliance party, so that a faster communication speed can be provided. In addition, because the nodes included by one alliance party trust each other, the identity verification is not needed in the cross-fragment communication process, so that the processing efficiency of the system can be further improved.

It will be appreciated that the schemes provided by the embodiments of the present disclosure are not limited to use with the blockchain system shown in fig. 1, but may be applied to any blockchain system including shards.

FIG. 2 is a block diagram illustrating a process of executing blocks in a blockchain system according to an embodiment of the present disclosure. While each node included in federation party a is described in fig. 2 as representing a respective shard, it is to be understood that the process of executing blocks by the plurality of shards shown in fig. 2 is not limited to being executed by a plurality of nodes in one federation party, but may be executed by any other node in each shard.

As shown in fig. 2, in the process of executing a block, the nodes 1A to 3A simultaneously execute blocks of the same height, each of which belongs to a slice. For example, node 1A performs a tile 1 of height M (i.e., tile 1 tile M), while node 2A performs a tile 2 of height M (i.e., tile 2 tile M), and node 3A performs a tile 3 of height M (i.e., tile 3 tile M).

The slices 1 to 3 simultaneously execute respective blocks having the same height may be to ensure atomicity of execution results of sub-transactions of transactions including cross-slice transactions in different slices. Specifically, each of the slices 1, 2, and 3 first starts to execute a respective generation block (hereinafter referred to as block 0), and each slice is stored in the respective generation block after being respectively identified, where the generation block generally includes configuration information, such as a slice node included in the slice, an IP address, a port number, a public key list of each slice node, an identification of an identified node in the slice, and the like. After executing the creation block, slice 1, slice 2, and slice 3 begin executing the respective block 1. Specifically, after determining a plurality of transactions belonging to the block 1 and the execution order of the plurality of transactions by the consensus, each of the blocks 1, 2, and 3 starts executing the plurality of transactions in the commonly-known respective block 1. Wherein fragment 1 may have generated a cross-fragment sub-transaction to be performed by fragment 2 during the execution of the transaction. If the transaction corresponds to execution of a transaction, fragment 1 can determine that the corresponding transaction was executed successfully after determining that execution of the transaction across fragment sub-transactions was successful. Accordingly, fragment 1 can determine that execution of multiple transactions in block 1 is successful upon determining that execution of the cross-fragment sub-transactions sent to all other fragment nodes is successful. Wherein, in the above and following description, "transaction" is used to denote a plurality of transactions belonging to a block commonly recognized in a shard, and "cross-shard sub-transaction" is used to denote a sub-transaction generated by executing a transaction or cross-shard sub-transaction.

Similarly, node 2A and node 3A may send cross-fragment sub-transactions to other nodes in federation party a, and likewise determine that multiple transactions in block 1 of its corresponding fragment are successfully executed if it is determined that the cross-fragment sub-transactions sent to all other nodes are successfully executed. Therefore, in order to ensure the execution correctness of the transaction in each partitioned block 1, the nodes 1A to 3A wait for all the nodes in the federation party a to finish executing the cross-partitioned sub-transactions, and start the following operations after determining that the cross-partitioned sub-transactions are executed successfully: the world state of the tile to which it belongs is updated, that is, the world state of the tile to which it belongs corresponding to the block 1 is stored, the block 1 of the tile to which it belongs (that is, the block and the block header of the block 1) is generated, and the block 1 is stored, so that the execution of the block 1 of the tile to which it belongs is ended, and the atomicity of the transaction in the block 1 of each tile is ensured.

Each of the nodes 1A to 3A starts executing the block 2 after determining that all the nodes end executing the block 1, and so on, each of the nodes 1A to 3A starts executing the block 3 after determining that all the nodes end executing the block 2. Thus, execution of blocks between nodes 1A-3A (i.e., different slices) is synchronized, each node having the same block height at the same time.

It will be appreciated that although in fig. 2, the nodes 1A to 3A are shown to simultaneously execute the blocks of the same height and to which each belongs, the embodiments of the present specification are not limited thereto, and the embodiments of the present specification may also be combined with other techniques for ensuring transaction atomicity, in which different slices may execute blocks of different heights, that is, the nodes 1A to 3A may execute blocks of different heights at the same time.

As can be seen from the above description, in the blockchain system including a plurality of slices provided in the embodiments of the present specification, a process of executing a block includes a plurality of steps performed in the following order: each slice basically determines a plurality of transactions belonging to a block (for example, a block M) at the same height through consensus, each slice respectively executes a plurality of transactions belonging to the block M, executes a plurality of cross-slice sub-transactions from other slices, and after determining that each slice completes execution of the cross-slice sub-transactions and does not generate new cross-slice sub-transactions, each slice updates world state based on state information corresponding to the execution results of the plurality of transactions and the plurality of cross-slice sub-transactions, namely, stores world state corresponding to the block M, generates a block and a block header of the block M, and stores the block M. It will be appreciated that in the event that each tile does not generate a cross-tile sub-transaction in performing a plurality of transactions belonging to tile M, the process of performing the tile will not include the process of performing a cross-tile sub-transaction described above.

Specifically, as shown in fig. 2, taking each node in the federation party a to execute the block M as an example, after the slices 1, 2 and 3 respectively determine n transactions belonging to the respective block M through consensus, the node 1A, 2A and 3A respectively start to execute n transactions belonging to the block M corresponding to the slices (as shown by the rectangular box labeled "n" in fig. 2, the execution process of the transaction or the transaction sub-transaction across the slices is shown by the same rectangular box), and the execution process of the n transactions can be regarded as the 1 st round transaction execution process in the execution process of the block M. It should be understood that, although the example in fig. 2 shows that the node 1A, the node 2A, and the node 3A respectively execute n transactions belonging to the tile 1 tile M, the tile 2 tile M, and the tile 3 tile M in the execution process of the 1 st round of transactions, the embodiment of the present disclosure is not limited thereto, and the number of transactions belonging to the tile 1 tile M, the tile 2 tile M, and the tile 3 tile M may be respectively set by the tile 1, the tile 2 tile M, and the tile 3, and the number of transactions may be unequal. It will be appreciated that tile 1 tile M represents a tile of height M in tile 1, tile 2 tile M represents a tile of height M in tile 2, and so on, and thus tile 1 tile M, tile 2 tile M, and tile 3 tile M represent different tiles.

After the 1 st round of transaction execution process of the block M is executed, each slice respectively generates one or more cross-slice sub-transactions, and the cross-slice sub-transactions are respectively sent to the nodes of the corresponding slice. For example, after performing n transactions, node 1A generates one or more cross-fragment sub-transactions corresponding to fragment 2 and sends these cross-fragment sub-transactions to node 2A, generates one or more cross-fragment sub-transactions corresponding to fragment 3, and sends this write cross-fragment sub-transaction to node 3A. Node 2A and node 3A also similarly communicate across slices. Finally, node 1A receives q cross-chip sub-transactions altogether, e.g., from node 2A and node 3A, and performs the q cross-chip sub-transactions, node 2A receives M cross-chip sub-transactions altogether, e.g., from node 1A and node 3A, and performs the M cross-chip sub-transactions, and node 3A receives p cross-chip sub-transactions altogether, e.g., from node 1A and node 2A, and performs the p cross-chip sub-transactions, which may be regarded as the 2 nd round of transaction execution process of each node in the process of executing block M, as shown in fig. 2. Meanwhile, each node may generate a new cross-fragment sub-transaction when completing the 2 nd round of transaction execution process, and may send the newly generated cross-fragment sub-transaction to the corresponding node, so that the node starts a new round of transaction execution process.

The cross-fragment sub-transaction is a transaction generated in the process of executing the block, specifically, the sub-transaction generated in the process of executing a plurality of transactions belonging to the block and needing to be executed across fragments, or the sub-transaction generated in the process of executing the cross-fragment sub-transaction and needing to be executed across fragments. The cross-fragment sub-transaction includes, for example, an operation instruction to instruct an operation corresponding to the operation instruction to be performed in a corresponding fragment. The sub-transaction may be of the same form as the transaction, i.e., including a send account, a receive account, a data field, etc. In the case where the sub-transaction is sent between multiple mutually trusted nodes comprised by the same federation partner, there is no need to verify the sub-transaction between the multiple nodes, and therefore the sub-transaction may not include a digital signature. Where the blockchain system includes state shards, the cross-shard sub-transactions are used to query or alter the state (i.e., world state) of the accounts in the corresponding shards, which may be queried or altered, for example, by invoking contracts in the corresponding shards. In one embodiment, the hash value of the corresponding original transaction may be included in the cross-fragment sub-transaction. In another embodiment, corresponding execution round information may be included in the cross-fragment sub-transaction, which may, for example, indicate a round of transaction execution processes that generated the cross-fragment sub-transaction.

That is, the execution of the block by each node may include a multi-round transaction execution process, wherein a cross-fragment communication process may be included after one round of transaction execution process, the cross-fragment communication process may send a cross-fragment sub-transaction across fragments, such that the node receiving the cross-fragment sub-transaction performs the next round of transaction execution process to execute the cross-fragment sub-transaction, and the multi-round transaction execution processes executed by each node are also substantially synchronized.

FIG. 3 is a schematic diagram illustrating another process of executing blocks in a blockchain system in accordance with the embodiments of the present disclosure. As shown in fig. 3, it is assumed that the node 1A fails to perform a certain sub-transaction sub-Tx 1 among them when performing the i-th round of transaction execution process of the block M, where the sub-transaction sub-Tx 1 includes a hash value of the transaction Tx1, that is, the sub-transaction sub-Tx 1 corresponds to the transaction Tx1, for example, the sub-transaction sub-Tx 1 is a cross-slice sub-transaction corresponding to the slice 1 generated by the node 2A after performing the transaction Tx 1. The node 1A sends the information that the transaction Tx1 is an error transaction through the slice broadcasting to the node 2A and the node 3A, so that the node 1A, the node 2A and the node 3A perform block playback, that is, roll back the state information, and re-perform the block M. Wherein the node 2A will re-execute the plurality of transactions belonging to the block M after rejecting the transaction Tx1 from the plurality of transactions belonging to the block M, thereby realizing transaction atomicity.

Wherein node 1A may fail to perform sub-transaction sub-Tx 1 across the shards in various situations, e.g., transaction Tx1 is a transfer transaction, in which case no account in shard 1 needs to be transferred to, so that node 1A will determine that sub-Tx 1 fails to perform; in another case, some businesses set an upper limit on daily transaction amount, and when node 1A determines that the transaction amount to the transfer-in account has reached the upper limit when executing SubTx1, then node 1A may determine that execution of SubTx1 has failed. The subttx 1, for example, invokes an intelligent contract deployed in the slice 1, in which other conditions to be satisfied are set, and when the node 1A determines that any preset condition is not satisfied in the process of executing the subttx 1, it may determine that execution of the subttx 1 fails.

FIG. 4 is a flowchart of a method for executing blocks in a blockchain system provided by embodiments of the present description, the method performed by the blockchain system including the shards, including the steps of:

step S401, a slice of the block chain system receives error transaction information from other slices in the process of executing the block; in step S403, the tile re-executes the multiple transactions after the error-removed transaction of the tile. The method of fig. 4 will be described below in conjunction with fig. 3.

First, in step S401, one slice of the blockchain system receives error transaction information from other slices in the process of executing a block.

Referring to fig. 3, the node 1A may perform the slice broadcasting immediately after determining that the sub transaction sub Tx1 fails to perform during the i-th round of transaction of the execution block M, or may perform the slice broadcasting after performing the i-th round of transaction, in which case the node 1A may determine a plurality of error transactions (including the transaction Tx 1) and perform the slice broadcasting on the information of the plurality of error transactions, so that more efficient rejection of the error transactions may be achieved.

The node 1A may broadcast a data packet including the erroneous transaction information when performing the slice broadcasting. In one embodiment, the data packet includes, for example, at least a hash value of each error transaction. In another embodiment, the data packet may include, for example, the fields and their field values as shown in table 1.

TABLE 1

Fields	Field value
		Block num (block height)	M
ErrorCount (number of error transactions)	1
		ErrorTx[](Hash value array of error transaction)	0x1756…
PacketID (transaction execution process round)	i
		FromSuard (Start fragment)	Slicing 1
ToShard (target slice)

The data packet includes a BlockNum field for indicating the height of the block corresponding to the data packet. In the case of a fragmented delay of reception of a data packet due to network delay, by including a block height in the data packet, an erroneous transaction of a block preceding in time can be processed first. In addition, since the transaction hash value may be identical under different encryption schemes, especially in the case where the transaction does not have a nonce value, the distinction can be made by the block height when broadcasting an erroneous transaction hash value.

An error count field is included in the data packet to indicate the number of erroneous transactions in the data packet, so that by setting the element length of the hash value array to a fixed length when the data packet is compressed, it is not necessary to use a separator process between the respective erroneous transaction hash values, and the decompression process can be accelerated.

The ErrorTx [ ] field is an array of hash values for the error transaction, whose array element length is determined by a particular hash value algorithm, typically 256 bits are available.

The PacketID field indicates the round of the transaction execution process to which the packet corresponds. In distributed broadcasting in a fragmented environment, the order in which messages arrive may be out of order due to network delays, etc., to ensure consistency of execution by including turns of the transaction execution process in the data packet. For example, assuming that the node 2A simultaneously receives a packet corresponding to the i-th round from the node 1A and a packet corresponding to the i+1-th round from the node 3A, the node 2A may perform block playback based on the packet of the i-th round according to the round information.

The from card field indicates the start slice of the data packet, i.e. the slice that sends the data packet, and in a traffic scenario with high security, the field value of the field may be the digital signature of the node that sends the slice of the data packet for the data packet.

The tosard field indicates the target fragment of the packet, i.e., the fragment to which the packet is to be broadcast. This field value leave empty may indicate that the target tile is all but the starting tile (i.e., tile 1).

It will be appreciated that the content of the data packet is not limited to that shown in table 1, and the fields included in the data packet of the slice broadcast may be set as needed in the blockchain system.

In order to simplify the cost of the cross-slice communication, only the hash value of the original transaction is generally included in the cross-slice sub-transaction, and the source slice of the original transaction is not included, so that the node 1A cannot learn the source slice of the corresponding error transaction after the execution of the cross-slice sub-transaction (such as sub tx 1) fails, and thus cannot determine the target slice of the error transaction. In this case, the node 1A may leave the tosard field empty to send the data packet to the node 2A and the node 3A, respectively, and the node 2A and the node 3A may determine whether each error transaction in the transaction packet is a transaction in the block M of the belonging slice based on the hash value of the transaction included in the block M of the belonging slice of the local record, respectively.

Node 2A, e.g., segment 2 of the blockchain system (i.e., segment 2), receives a broadcast packet from node 1A, e.g., from segment 1, during execution of block M, that includes the hash value of transaction Tx1 to indicate that transaction Tx1 is an erroneous transaction. The node 2A may thus determine that the transaction Tx1 is one of the plurality of transactions belonging to the tile 2 block M based on the locally recorded hash values of the plurality of transactions belonging to the tile 2 block M. After the above determination, the node 2A may suspend execution of the block M locally, or may suspend execution of the block M after completion of the ith round of transaction execution process, buffer the data packet received from the node 1A after suspension of execution of the block M, and wait to determine whether the node 3A transmits the data packet including the erroneous transaction information.

The node 3A, upon receiving the same data packet from the node 1A, may determine that the transaction Tx1 is not a transaction among the plurality of transactions belonging to the tile 3 block M, and may determine whether there is a case in which the execution of the sub-transaction fails after the i-th round of transaction execution process is completed. In the case where it is determined that there is a sub-transaction execution failure, similarly to the node 1A, data packets including error transaction information are transmitted to the node 1A and the node 2A, respectively, and in the case where it is determined that there is no sub-transaction execution failure, the node 1A and the node 2A may be notified, respectively.

In step S403, the tile re-executes the plurality of transactions after the error-removed transaction for the tile.

In the following, the node 2A of the slice 2 will be described as an example, and it will be understood that other nodes in the slice 2, and the execution of this step by other slices, may be described with reference to the process of executing this step by the node 2A of the slice 2.

Referring to fig. 3, the node 2A performs the operation of block playback after receiving the above-described data packet from the node 1A, or the node 2A may perform the operation of block playback after receiving the data packet including the error transaction information from both the node 1A and the node 2A, or the node 2A may perform the operation of block playback after receiving the data packet from the node 1A and receiving the information that no error transaction has occurred from the node 2A. The latter two cases may enable block playback after as many erroneous transactions as possible are found, providing more efficient culling of erroneous transactions.

After starting the block playback, first, the node 2A performs a 1' round transaction execution process, i.e., rolls back the state to the world state corresponding to the tile 2 block M-1, and executes a plurality of transactions belonging to the tile 2 block M after the error-removed transaction based on the world state corresponding to the tile 2 block M-1. For example, the node 2A receives data packets including error transaction information from both the node 1A and the node 3A, where the two data packets may both include the i-th round information, and the node 2A determines that k error transactions corresponding to the tile 2 block M are shared according to the two data packets, so that the node 2A eliminates the k transactions from the initial n transactions belonging to the tile 2 block M, and re-executes the n-k transactions after the elimination in the 1' round of transaction execution process. Wherein, when executing the n-k transactions, since the n-k transactions have been digitally signed during the execution of the 1 st round of transactions, there is no need to again digitally sign the n-k transactions during the re-execution.

As shown in fig. 3, in the 1 st round of transaction execution process, if the node 1A and/or the node 3A does not receive the error transaction information from other slices, the node 1A and/or the node 3A does not need to re-execute the multiple transactions of the corresponding slice block M, but in the 1 st round of transaction execution process, since it receives a new cross-slice sub-transaction from the node 2A, the 2 nd round of transaction execution process needs to be re-executed based on the state information corresponding to the original 1 st round of transaction execution process. The state information corresponding to the 1 st round of transaction execution process comprises a record of the value of the written variable in the 1 st round of transaction execution process. If node 1A and/or node 3A also receives error transaction information from other shards, it performs the same process as node 2A.

During the 2' round of transaction execution after the block playback, as shown in fig. 3, if neither node 1A nor node 3A re-executes the plurality of transactions belonging to the corresponding tile M, the cross-tile sub-transactions that node 2A needs to execute during the 2' round of transaction execution are unchanged, and therefore, node 2A does not need to re-execute during the 2' round of transaction execution.

Through the block playback process, the block is re-executed after the error transaction is removed, so that the transaction atomicity is ensured in the process of executing the block. After the block playback, if the execution failure of the sub-transactions across the partitions occurs again, the block playback may be performed again until all the error transactions included in the block are eliminated.

It should be understood that, although each slice is shown to perform the block playback after the error transaction is found during the execution of a certain round of transaction of the block M, the embodiment of the present disclosure is not limited thereto, and for example, each slice may buffer the error transaction information after the error transaction is found during the execution of a certain round of transaction, and send the data packet including the information of the error transaction to the other slices after the execution of the block M for performing the block playback.

Fig. 5 illustrates a block diagram of an apparatus for executing a block in a blockchain system including a first slice including a first node therein and a second slice for executing the block execution method illustrated in fig. 4, the apparatus deployed at the first node, according to an embodiment of the present disclosure, including:

a receiving unit 51, configured to receive, in a process of executing a first block, first information from the second slice, where the first information indicates a first transaction that is performed in error among n transactions belonging to the first block, where the first information is sent by the second slice after a failure in performing a first cross-slice sub-transaction corresponding to the first transaction, and the first cross-slice sub-transaction is a cross-slice sub-transaction belonging to a second block in the second slice;

the re-executing unit 52 is configured to re-execute a plurality of transactions, of the n transactions, after the first transaction is removed.

In one embodiment, the first node and a second node in the second shard are mutually trusted nodes, and the first node receiving first information from the second shard includes the first node receiving first information from the second node.

In one embodiment, the blockchain system includes a federated chain system, the first node and the second node belonging to the same federated member.

In one embodiment, the identification of the first transaction is included in a first cross-fragment sub-transaction.

In one embodiment, the apparatus further comprises: a generating unit 53, configured to generate a plurality of second cross-slice sub-transactions corresponding to the second slice after re-executing the plurality of transactions belonging to the first block, and send the plurality of second cross-slice sub-transactions to the second slice, so that the second slice executes the plurality of second cross-slice sub-transactions based on first state information, where the first state information is generated by the second slice by executing the plurality of transactions belonging to the second block.

In one embodiment, the blockchain system includes a plurality of second slices, and the re-executing unit is specifically configured to re-execute, after determining that the first information is received from all of the second slices, a plurality of transactions after removing the first transactions included in all of the first information from the n transactions.

In one embodiment, the plurality of first information includes the same round information indicating a round of a transaction execution process included in an execution process of a second block corresponding to the first cross-fragment sub-transaction.

In one embodiment, the first cross-segment sub-transaction is a cross-segment sub-transaction during a first round of transaction execution belonging to a second block in the second segment, and the first information is sent by the second segment after completion of the first round of transaction execution.

In one embodiment, the re-executing unit is specifically configured to re-execute the plurality of transactions after the first transaction is removed from the n transactions based on a world state of a previous block of the first block.

It should be understood that the description of "first," "second," etc. herein is merely for simplicity of description and does not have other limiting effect on the similar concepts.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments.

The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Those of ordinary skill would further appreciate that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, in computer software, or in a combination of the two, and that the elements and steps of the examples have been generally described in terms of function in the foregoing description to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Those of ordinary skill in the art may implement the described functionality using different approaches for each particular application, but such implementation is not considered to be beyond the scope of the present application. The software modules may be disposed in Random Access Memory (RAM), memory, read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

The foregoing description of the embodiments has been provided for the purpose of illustrating the general principles of the application, and is not meant to limit the scope of the application, but to limit the application to the particular embodiments, and any modifications, equivalents, improvements, etc. that fall within the spirit and principles of the application are intended to be included within the scope of the application.

Claims

1. A method of executing a block in a blockchain system, the blockchain system including a first slice including a first node therein and a second slice, the method performed by the first node comprising:

2. The method of claim 1, wherein the first node and a second node in the second shard are mutually trusted nodes, the first node receiving first information from the second shard comprising the first node receiving first information from the second node.

3. The method of claim 2, wherein the blockchain system includes a coalition chain system, the first node and the second node belonging to the same coalition member.

4. The method of claim 1 or 2, wherein the first cross-fragment sub-transaction includes an identification of the first transaction.

5. The method of claim 1 or 2, further comprising:

after re-executing the plurality of transactions belonging to the first block, generating a plurality of second cross-tile sub-transactions corresponding to the second tile, and sending the plurality of second cross-tile sub-transactions to the second tile, such that the second tile executes the plurality of second cross-tile sub-transactions based on first state information generated by the second tile by executing the plurality of transactions belonging to the second block.

6. The method of claim 1 or 2, the blockchain system including a plurality of second shards, the re-executing the plurality of transactions after the first transaction is removed from the n transactions including re-executing the plurality of transactions after the first transaction is removed from all of the first information from all of the n transactions after determining that first information is received from all of the second shards.

7. The method of claim 6, wherein the plurality of first information includes the same round information indicating rounds of transaction execution included in execution of the corresponding second chunk of the first cross-fragment sub-transaction.

8. The method of claim 1 or 2, wherein the first cross-fragment sub-transaction is a cross-fragment sub-transaction of the second fragment performed during a first round of transaction execution of a second block, the first information being sent by the second fragment after completion of the first round of transaction execution.

9. The method of claim 1 or 2, wherein re-executing the plurality of n transactions after the first transaction is removed comprises re-executing the plurality of n transactions after the first transaction is removed based on a world state of a previous tile of the first tile.

10. The method of claim 1, wherein the re-executing the plurality of the n transactions after the first transaction is removed does not include a verification of a digital signature of the transaction.

11. An apparatus for executing a block in a blockchain system, the blockchain system including a first shard and a second shard, the first shard including a first node therein, the apparatus disposed at the first node, comprising:

12. The apparatus of claim 11, wherein the first node and a second node in the second shard are mutually trusted nodes, the first node receiving first information from the second shard comprising the first node receiving first information from the second node.

13. The apparatus of claim 12, wherein the blockchain system comprises a coalition chain system, the first node and the second node belonging to the same coalition member.

14. The apparatus of claim 11 or 12, wherein the first cross-fragment sub-transaction includes an identification of the first transaction.

15. The apparatus of claim 11 or 12, further comprising:

and the generating unit is used for generating a plurality of second cross-slice sub-transactions corresponding to the second slice after re-executing the plurality of transactions belonging to the first block, and sending the plurality of second cross-slice sub-transactions to the second slice so that the second slice executes the plurality of second cross-slice sub-transactions based on first state information, wherein the first state information is generated by the second slice through executing the plurality of transactions belonging to the second block.

16. The apparatus according to claim 11 or 12, the blockchain system comprising a plurality of second slices, the re-execution unit being specifically configured to re-execute a plurality of transactions of the n transactions after removing a first transaction included in all of the first information after determining that the first information is received from all of the second slices.

17. The apparatus of claim 16, wherein the plurality of first information comprises identical round information indicating rounds of transaction execution included in execution of a corresponding second chunk of the first cross-fragment sub-transaction.

18. The apparatus of claim 11 or 12, wherein the first cross-segment sub-transaction is a cross-segment sub-transaction of the second segment that is performed during a first round of transaction execution of a second block, the first information being sent by the second segment after completion of the first round of transaction execution.

19. The apparatus according to claim 11 or 12, wherein the re-execution unit is specifically configured to re-execute a plurality of transactions of the n transactions after the first transaction is removed based on a world state of a previous tile of the first tile.

20. A computer readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of any of claims 1-10.

21. A computing device comprising a memory having executable code stored therein and a processor, which when executing the executable code, implements the method of any of claims 1-10.