A block validity verification method for blockchain sharding system

Abstract

A block validity verification method for a blockchain sharding system, the blockchain sharding system comprising a plurality of shards, each shard generating a new block based on transaction requirements and reaching a consensus within the shard to generate verification evidence of the block, the method comprising the following steps: randomly selecting 2 times a preset number of shards other than the shard where the block is located in the blockchain sharding system to form a verification shard set; using each shard in the verification shard set to verify the block, and broadcasting the verification result to other shards; and determining that the block and the shard where it is located are successfully verified when at least half of the shards in the verification shard set verify that the block is valid.

Description

Technical Field

[0001] The present invention relates to the field of blockchain, specifically, to the technical field of blockchain scalability research, and more specifically, to a block validity verification method for a blockchain sharding system, a cross-shard transaction method based on a blockchain sharding system, and a fault-tolerant blockchain sharding system. Background Art

[0002] Since its emergence in 2008, blockchain has attracted extensive attention from academia and industry due to its decentralization, security, and immutability. At present, blockchain technology has been widely used in various fields, providing a reliable infrastructure for online payment, supply chain finance, and other decentralized applications. However, most of the actual applications of blockchain are still limited to functional applications with low performance requirements such as storage and traceability. For performance-oriented applications, the current performance of blockchain of dozens of transactions per second is difficult to meet their needs. The low transaction processing performance of blockchain has seriously restricted the actual implementation of blockchain technology. The current mainstream blockchain architecture can only process 7-10 transactions per second, which is an order of magnitude lower than the processing capacity of hundreds of thousands per second of traditional centralized applications such as Alipay and WeChat.

[0003] Sharding technology is a key technology to improve the transaction processing capabilities of blockchain. It greatly improves the throughput level of blockchain by increasing the degree of parallelism of the system and changing the linear transaction processing mode under a single chain.

[0004] In 2016, Loi Luu proposed the Elastico sharding scheme at the CCS'16 conference. In this scheme, when the system starts to process a new batch of transactions, the blockchain nodes will be randomly assigned to each shard by a secure random algorithm to form a shard consensus committee. At the same time, the transaction set will be assigned to different shards for processing according to the prefix of the transaction hash. Each shard processes transactions in parallel and generates blocks independently. Finally, a shard collects the blocks generated by each shard, aggregates the states of different shards as the starting state of the next round of transaction processing, and starts the next round of system cycle. Since different shards in the system use parallel processing when processing transactions, the processing performance of the blockchain can be doubled. However, in the Elastico sharding scheme, nodes need to be reallocated after each round of block generation, and finally all the blocks generated in each round need to be aggregated together again. This process takes a lot of time, so its final transaction processing speed is only 40 transactions per second.

[0005] In the Ominiledger protocol proposed in 2018, the solution improves the transaction processing throughput of shards by optimizing the overall architecture of blockchain shards. The Ominiledger protocol optimizes the node allocation and rotation mechanism in Elastico, and proposes an efficient node random algorithm. In addition, it does not need to rotate nodes after each block like in Elastico, and adopts the cuckoo rule of rotating a small number of nodes at a fixed time. At the same time, Ominiledger implements state sharding, that is, the states between each shard are completely independent, and the nodes do not need to re-converge the states of each shard. For cross-shard transactions, the Ominiledger protocol also proposes a cross-shard transaction processing mechanism, and realizes data interaction and transaction settlement between each shard through cross-shard transactions. In order to ensure that the shard status can be correctly updated between different shards, the system requires that each shard must ensure its security. Therefore, it stipulates that the proportion of Byzantine nodes (malicious nodes) in the system is less than 1 / 4, and each shard maintains a scale of more than 600 consensus nodes to ensure that the number of Byzantine nodes in each shard is less than 1 / 3 (the safety threshold of the Byzantine fault-tolerant consensus algorithm), thereby ensuring that the Byzantine consensus algorithm between each shard node can operate normally and the system state is correct. In the same year, Mahdi Zamani proposed the RappidChain protocol, which optimizes the random allocation algorithm of nodes, the transmission method of cross-shard information, and the consensus method of shards. The RappidChain protocol introduces synchronous consensus into the sharding algorithm, reduces the safety threshold of malicious nodes in each shard to 1 / 2, thereby increasing the global Byzantine node ratio requirement from less than 1 / 4 to less than 1 / 3. Finally, at the same security level, the scale of its consensus nodes can be safely reduced to more than 200, improving the overall throughput level of the system. In 2019, Hung Dang proposed introducing TEE into the blockchain sharding algorithm at the SIGMOD'19 conference, which greatly improved the consensus security of the blockchain. The TEE trusted execution environment avoids the ambiguous attack of Byzantine nodes and increases the proportion of Byzantine nodes that can be tolerated in each shard to 1 / 2. This greatly reduces the consensus scale of nodes in the shard while ensuring that the global Byzantine nodes are less than 1 / 4. The two methods mentioned above can tolerate a small number of node errors in the shard.

[0006] In addition, Dr. Wang Jiaping proposed the monoxide protocol at the NSDI'19 conference. By binding the computing power of different shards together, nodes can simultaneously reach consensus on multiple shards and produce blocks. This sharding method can achieve the sharing of computing power, and the computing power of each shard can be equal to the computing power of the entire network. In theory, the computing power required to attack a single shard requires up to 50% of the computing power of the entire network, which greatly improves the security of each shard. However, this improvement is limited by the actual performance of the nodes. In essence, to achieve theoretical security guarantees, all nodes still need to run all shard consensus protocols, that is, to produce blocks on multiple shards at the same time, which puts a great burden on the processing performance, storage, and communication overhead of the nodes.

[0007] In the existing scheme, the general process of blockchain sharding is basically as follows: through a certain random algorithm, a certain scale of shard consensus nodes are randomly selected from the global node pool; the shard nodes in each shard run the consensus protocol to process various transaction information received by the shard; to avoid node corruption, the consensus nodes in each shard are regularly updated and rotated. However, the existing sharding schemes all have the same problem, that is, the system cannot tolerate any shard being controlled by a malicious attacker, that is, the shard is not fault-tolerant. In the current sharding protocol, the security of the system is achieved by ensuring the security of all shards. Under this assumption, the shards trust each other. For example, for cross-shard transactions, after the source shard processes the pre-processing part of the cross-shard transaction, it will generate a Merkle tree path proof in the Merkle tree of the block included in the transaction, and send the transaction and the proof to the destination shard. After receiving the transaction, the destination shard will only check whether it is included in a block of the source shard by checking the Merkle tree path or signature information of the transaction. As long as it exists in the source shard block, the destination shard will consider the cross-shard transaction to be valid, and since its preamble has been correctly executed in the source shard, the destination shard will execute the postamble of the transaction. Therefore, if a shard is controlled by a malicious attacker, the entire system will be paralyzed. Malicious attackers can maliciously change the local state and generate a large number of illegal cross-shard transactions in an untrusted state, causing other shards to incorrectly update the shard state, thereby causing the entire system to fail. Therefore, the current sharding system must ensure that the number of malicious attackers in all shards is within a safe range to ensure the security of the entire system.

[0008] However, this intolerant security mechanism severely limits the transaction processing capabilities of the blockchain system. In order to avoid shard errors (i.e. being controlled by malicious attackers), blockchain systems often require each shard to maintain a large number of consensus nodes. Furthermore, as the number of shards increases, the scale of shard consensus nodes also needs to grow linearly to ensure system security. For example, assuming that the probability of each shard being controlled by a malicious attacker is p, as the system security increases (1-p) n In order to ensure security, we can only reduce the size of the error probability p, and then each shard needs to maintain a larger number of consensus nodes to ensure that the probability p of each shard being maliciously controlled is small enough. Taking Omniledger as an example, a 10-shard system requires each shard to maintain at least 650 consensus nodes to ensure the overall security of the system. Even if the RapidChain protocol adopts a synchronous Byzantine consensus protocol that can tolerate a higher proportion of Byzantine nodes, it must maintain a consensus node scale of more than 200 per shard at a scale of 10 shards, and the node scale increases linearly with the increase in the number of shards. However, due to the limitations of the Byzantine consensus protocol, as the number of consensus nodes increases, its consensus efficiency will be greatly reduced. Such a large scale of consensus nodes means lower transaction processing capabilities and extremely high message complexity. In the existing consensus protocol, the scale of hundreds of consensus nodes will lead to very slow consensus efficiency, and can only process two or three hundred transactions per second at most, which seriously limits the transaction processing capabilities of the shards. Therefore, whether from the processing power of a single shard or the parallel scale of the system's shards, the security mechanism of the current sharding solution severely limits the performance level and scalability of the system.

[0009] In summary, the existing blockchain sharding technology has the following main disadvantages:

[0010] 1. Although the existing blockchain sharding technology can tolerate a small number of node errors in the shards, the security of the entire blockchain system still relies heavily on the premise that all shards are secure. It lacks tolerance for malicious situations in a small number of shards. Once a shard fails, the illegal cross-shard transactions it generates will cause the entire blockchain system to paralyze.

[0011] 2. In the existing blockchain sharding technology, each shard must maintain a large number of consensus nodes to ensure that the shard will not make mistakes. However, too many consensus nodes in a shard will limit the consensus efficiency. Excessive message complexity will limit the transaction processing level of the shard, limiting the overall throughput level of the blockchain shard. Summary of the invention

[0012] Therefore, the purpose of the present invention is to overcome the defects of the above-mentioned prior art and provide a block validity verification method for a blockchain sharding system, a cross-shard transaction method based on a blockchain sharding system, and a fault-tolerant blockchain sharding system.

[0013] According to a first aspect of the present invention, there is provided a method for verifying the validity of a block in a blockchain sharding system, wherein the blockchain sharding system comprises a plurality of shards, each shard generates a new block based on transaction requirements and reaches a consensus within the shard to generate verification evidence of the block, and the method comprises the following steps: randomly selecting 2 times a preset number of shards other than the shard where the block is located in the blockchain sharding system to form a verification shard set; using each shard in the verification shard set to verify the block, and broadcasting the verification result to other shards; and determining that the block and the shard where it is located are successfully verified when at least half of the shards in the verification shard set verify that the block is valid.

[0014] In some embodiments of the present invention, each shard in the verification shard set verifies the block to be verified in the following manner: obtain the block to be verified and its verification evidence, and verify the validity of the block state; after the validity of the block state is verified, execute the transaction information on the block and update the block state, and determine whether an error is reported during the transaction execution; when no error is reported during the transaction execution, verify whether the updated block state of the block is consistent with the state information recorded in the block itself; when the above three verification contents are all passed, the verification of the block to be verified is considered valid, otherwise the block to be verified is considered to be erroneous, and the verification validity or error results are broadcast to all shards in the blockchain sharding system.

[0015] Preferably, the block verification evidence is generated in the following manner: in response to transaction requirements, the shard generates a new block; the shard collects account status information involved in the block execution transaction process, and generates block verification evidence through a locally maintained account status tree; the shard reaches a consensus on the generated block and block verification evidence.

[0016] Preferably, the preset number is a number greater than or equal to 1 and less than or equal to a number within the range of the number of shards in the blockchain sharding system, and the preset number is used to indicate the maximum number of malicious shards that the blockchain sharding system can tolerate.

[0017] In some embodiments of the present invention, blocks are divided into blocks in a prepared state, blocks in a pre-submitted state, and blocks in a submitted state according to whether they are verified and the verification results. The blocks in a prepared state refer to blocks newly generated by the shard, and are blocks that have only reached consensus within the shard and have not been verified by other shards; the blocks in a pre-submitted state refer to blocks in a prepared state that have passed validity verification; and the blocks in a submitted state refer to blocks in a pre-submitted state whose preceding blocks are all in a submitted state.

[0018] According to a second aspect of the present invention, a cross-shard transaction method based on a blockchain sharding system is provided, which is used to execute a cross-shard transaction initiated by a source shard block to a destination shard, and the method comprises: S1, the source shard generates a new block and block verification evidence corresponding to the cross-shard transaction sent to the destination shard; S2, the validity of the block in step S1 is verified by the method described in the first aspect of the present invention to obtain the state of the block; S3, for the block that has successfully verified and entered the submission state in step S2, verify whether its verification evidence is consistent with the information corresponding to its transaction root, if it is consistent, execute the cross-shard transaction initiated by the block, if it is inconsistent, terminate the transaction; S4, initiate a rotation mechanism for the block that failed to be verified in step S2, including rotating out the shard where the block is located and the shard containing its subsequent cross-shard transactions, and rolling back each shard in the sharding system to the state that passed the most recent verification, and regenerating a new verification shard set to re-verify the block that failed to be verified until it is successfully verified to re-execute the transaction.

[0019] In some embodiments of the present invention, the rotation mechanism means that the intra-shard and cross-shard transactions of the shard being rotated out are suspended and its right to serve as a validating shard for other shards is revoked until it is successfully revalidated.

[0020] According to a third aspect of the present invention, a fault-tolerant blockchain sharding system is provided, wherein the blockchain sharding system comprises multiple shards, each shard generates a new block based on transaction requirements and reaches a consensus within the shard to generate verification evidence of the block, and the blockchain sharding system adopts the method described in the second aspect of the present invention to perform cross-shard transactions.

[0021] Compared with the prior art, the advantages of the present invention are:

[0022] 1. The fault-tolerant mechanism of blockchain sharding is realized by cross-validation based on the status between shards, so that the blockchain sharding system can still work normally when a small number of shards fail.

[0023] 2. Reduce the scale of shard consensus nodes through the fault-tolerant mechanism of sharding, improve sharding performance, increase the degree of system parallelism, and improve the overall throughput level of the blockchain system from multiple dimensions. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The embodiments of the present invention are further described below with reference to the accompanying drawings, in which:

[0025] Figure 1 A schematic diagram of a blockchain fault-tolerant sharding mechanism according to an embodiment of the present invention;

[0026] Figure 2A schematic diagram of a cross-shard transaction method based on a blockchain sharding system according to an embodiment of the present invention;

[0027] Figure 3 Schematic diagram of the process of generating blocks and block verification evidence in an example shard A according to an embodiment of the present invention;

[0028] Figure 4 A flowchart of a verification process of a block generated by an example shard A by an example shard B according to an embodiment of the present invention;

[0029] Figure 5 The figure is a flowchart of a cross-shard transaction process in which an example shard A generates a block and sends it to an example shard D according to an embodiment of the present invention. DETAILED DESCRIPTION

[0030] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail by specific embodiments below. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0031] In order to better understand the present invention, the technical concept of the present invention is introduced below.

[0032] Since the relevant knowledge involved in the blockchain is all known technology, the present invention only briefly describes the content involved in realizing blockchain sharding. As mentioned in the background technology, the security guarantee of the existing blockchain sharding technology is heavily dependent on the premise that all shards are safe, and lacks tolerance for malicious situations in a small number of shards. Once a shard goes wrong, the illegal cross-shard transactions generated by it will cause the entire blockchain system to be paralyzed. At the same time, in the existing blockchain sharding technology, each shard must maintain a large number of consensus nodes to ensure that the shard will not go wrong, but too many consensus nodes in the shard will limit the consensus efficiency, especially when the message complexity is too high, it will limit the transaction processing level of the shard, which is mainly manifested in limiting the overall throughput level of the blockchain shard, resulting in inefficient transaction processing performance of the entire blockchain sharding system. Based on this, the present invention proposes a block-based stateless verification scheme, which specifies multiple verification shards for each shard to verify its validity, so that any shard can verify whether the specific block state transition of the shard is correct and complies with the set rules without the status data of other shards, and identify malicious shards and limit the transaction capabilities of malicious shards and the ability to verify other shards through consensus voting between blockchain shards, thereby eliminating the impact of a small number of malicious shards on the overall system in the block verification results, thereby forming a cross-verification mechanism for the status between shards, realizing the discovery of erroneous shards and the system's fault tolerance performance for a small number of malicious shards. In addition, based on the dependency relationship between blocks, the present invention proposes a verification traceability of the entire blockchain sharding system and a distributed verification of the calling relationships between all shards. By aggregating the verification results of all shards and the dependencies between blocks, the real-time valid state set of shards in the entire system is obtained to achieve the correct update of the system state, and the system errors are controlled within a small number of erroneous shards to achieve the control of the error state. This mechanism can ultimately achieve that even if a small number of shards are maliciously controlled, the system can still work normally and recover from errors, thereby achieving the purpose of reducing the scale of shard consensus nodes to improve the throughput level of the entire blockchain system, thereby realizing a fault-tolerant blockchain sharding system solution.

[0033] The present invention is described in detail below with reference to the accompanying drawings and embodiments.

[0034] The following is an explanation of the relevant professional terms and symbol definitions in the blockchain sharding technology involved in the present invention.

[0035] 1. Account

[0036] Account status: the user's status information, including basic information such as balance and sent transactions.

[0037] Account private key: A 256-bit (32-byte) string generated by the secp256k1 curve.

[0038] Account public key: A 512-bit (64-byte) string obtained by mapping the account private key through the Elliptic Curve Digital Signature Algorithm (ECDSA).

[0039] Account address: The last 160 bits (20 bytes) of the hash value of the account public key obtained by the Keccak-256 algorithm are used to index each account and identify the account in the transaction. The first two bits are used to identify the shard information.

[0040] 2. Affairs

[0041] Transaction: a transaction, which is an operation to change the account status in this architecture, including fields such as source address, destination address, transfer amount, transaction sequence number, etc., among which:

[0042] Source address / destination address: the sender and receiver account addresses.

[0043] Source shard / destination shard: the shards where the sender and the receiver are located, which can be calculated from the source address / destination address. If the source shard and the destination shard are different, it is a cross-shard transaction. In the present invention, the execution of cross-shard transactions will adopt a two-stage protocol, that is, first executed on the source shard (called the pre-order transaction) and then executed on the destination shard (called the post-order transaction).

[0044] Transfer amount: The amount of funds transferred from the source address to the destination address.

[0045] Transaction sequence number: the transaction number initiated by the source address.

[0046] Transaction Proof: It is empty by default and is filled in by the block-producing node to prove that the predecessor transaction of the cross-shard transaction has been executed in the destination block of the source shard, including: the source shard block hash; the Merkle tree proof of the transaction, that is, the calculation path of the Merkle tree, which is used to prove that the block contains the predecessor transaction of this transaction.

[0047] 3. Block

[0048] Block header: a brief index information of the block, including: the previous block hash, that is, the hash value of the previous block of this shard; the block height, that is, the number of blocks in this shard, used to index the block; the transaction root, that is, the hash value of the root node of the Merkle tree composed of the transaction set contained in this block; the state root, that is, the hash value of the root node of the Merkle tree composed of the latest state after the execution of this block; the hash value of this block, used to index the block; the block verification evidence hash, that is, the hash value of the block verification evidence; the dependent block, which refers to the source block of the corresponding cross-shard transaction, which may contain a collection of many blocks, such as a cross-shard transaction Tx A It means transferring from shard B to shard A. (Block in shard B) Packed transaction Tx A The preamble of (Block in Shard A) Execute transaction Tx A The subsequent part, then Included in The dependent blocks; the dependent block hash value refers to which blocks the cross-shard transactions in the subsequent stages executed in this shard come from; others.

[0049] Transaction set: all transactions executed in this block, including intra-shard transactions of this shard and cross-shard transactions of other shards. For cross-shard transactions in subsequent stages of execution, the node will record them in the dependent block hash value in the block header.

[0050] 4. Block Verification Evidence

[0051] Block Hash: The block hash of the block to which the block verification evidence corresponds.

[0052] Account status: Account status information that is read or modified during block execution.

[0053] State Proof: It is used to verify whether the account status is correct. It can be verified by using methods such as Merkle tree path, but is not limited to, the state root in the block header.

[0054] The symbol definitions involved in the relevant examples in the embodiments of the present invention are shown in Table 1. Table 1 shows the relevant definitions of example slice A, and other slices refer to example slice A.

[0055] Table 1

[0056]

[0057]

[0058] The following is an introduction to the discovery mechanism of the error state of the shards in the blockchain sharding system involved in the present invention. In the initial stage of the blockchain sharding system and the process of verifying the rotation of the shard set, the system uses the shard random number generation algorithm to randomly generate a system-wide unified seed seed. The system randomly generates the verification relationship between the shards in this round based on the seed. Each shard randomly selects the remaining 2 times f shard The number of shards is used as the verification shard set, and each verification shard verifies all blocks generated by the verification shard in this round. For example, shard A randomly selects shard B as the verification shard in round t, then each block generated by shard A in round t All need to be sent to shard B, which is verified by the consensus node in shard B and broadcasted to the entire system, using signatures to prove its validity. Since each shard only stores its own state information and does not store the state information of other shards, the present invention proposes a stateless block verification algorithm to verify blocks. The verification shard does not need to know the state information of the shard to be verified, but can also verify whether the state conversion of its block is correct and complies with the relevant conversion rules. The verification algorithm verifies the block state. Is it in status Executed on the basis The correct state obtained by state transition. In the stateless block verification algorithm described above, the block verification evidence The specific information included is flexibly designed and determined according to different verification algorithms and actual needs. The verification algorithm of the evidence in the present invention includes but is not limited to the Merkle tree verification algorithm, the state tree subtree verification algorithm, the zero-knowledge proof verification algorithm, and the related state verification algorithm based on the cryptographic mechanism.

[0059] The shards in the verification shard set verify the verification block in the following way: obtain the block to be verified and its verification evidence, verify the validity of the block state, that is, verify Is it from the previous block? The status information after execution, that is After the validity of the block state is verified, the transaction information is executed on the block and the block state is updated, that is, in the minimum state Next execution Transaction information in And update according to the same rules Right now And determine whether there is an error in the transaction execution; when there is no error in the transaction execution, verify whether the block status after the block update is consistent with the status information recorded in the block itself, that is, When all three of the above verifications are passed, the block to be verified is considered valid. Otherwise, the block to be verified is considered to be wrong, and the verification result is broadcast to all shards in the blockchain sharding system. Among them, the minimum state refers to the state set involved in the block (change query) during the block execution, and does not include states unrelated to the block execution. In addition, since the shard that generates the block must recognize the block by default, even if there is only f shar The shards are successfully verified, plus the shard that generates the block, which is equivalent to 2f shar +1 shard has f shar +1 agrees with this block, which is a majority, so when a shard block is f shardWhen all shards are verified to be valid, the shard is considered to be verified successfully. shard When +1 shard verification fails, the shard is considered to have failed verification.

[0060] The following is an introduction to the control and recovery mechanism of the error state of the shards in the blockchain sharding system involved in the present invention. The error state discovery mechanism of the blockchain shards described above verifies whether the block state transition is correct and complies with the transition rules and whether the updated block state is consistent with the state recorded in the block root itself. However, since its predecessor block does not participate in the verification, it cannot be guaranteed that the minimum state of the block itself is correct. Therefore, the verification result is actually based on the premise that the predecessor block of the block to be verified is correct. When it comes to cross-shard transactions, for example When shard C initiates a cross-shard transaction to shard A, and There is a certain dependency between them, and the method of the present invention is essentially based on the assumption that and If correct, verify In summary, the present invention constructs the dependency relationship between blocks into a dependency network, and proposes a method for managing the block status based on this dependency relationship to control the error state area of ​​the blockchain shard.

[0061] According to one embodiment of the present invention, the blocks in the blockchain sharding system of the present invention are divided into blocks in the prepare state, blocks in the pre-commit state and blocks in the commit state according to whether they are verified or not and the verification results, wherein: the blocks in the prepare state refer to blocks newly generated by the shard, and are only blocks that have reached consensus within the shard and have not been verified by other shards; the blocks in the pre-commit state are blocks in the prepare state that have passed the validity verification, that is, a block in the prepare state is successfully f shardThe verification of each shard is successful, which proves that its state transition is correct; the block in the committed state refers to a block in the pre-committed state whose preceding blocks are all in the committed state, that is, a block in the pre-committed state can enter the committed state only when its preceding blocks have all entered the committed state. At this time, it is proved that the state information in the block is correct and credible. It should be noted that in the field of blockchain, it is stipulated that the first block (genesis block) in each shard is credible across the entire network, and it is directly in the committed state. For cross-shard transactions, normal shards will only execute cross-shard transactions sent by blocks in the committed state. For cross-shard transactions sent from other states, they will not be executed until their source blocks enter the committed state. Through this restriction, the erroneous state will be limited to a few erroneous shards without affecting other shards. For example, in the attached Figure 1 In the example of blockchain sharding shown, if the A1 block in shard A is verified incorrectly, then the A1 block will never enter the pre-commit state. Even if the A2 and A3 blocks are verified by the other shards and enter the pre-commit state, they cannot enter the commit state due to the restriction of A1, and the cross-shard transactions contained therein will not be executed by other shards. Therefore, the error area can be controlled within shard A, so that the error will not spread to other shards.

[0062] When a block fails to be verified, that is, there is f in the verification shard set shard +1 verification shard broadcasts the error information of the block to be verified in the entire blockchain system. The blockchain shard system will trigger a shard consensus node rotation mechanism, including: rotating out the shard where the block is located and the shard containing its subsequent cross-shard transactions, and rolling back each shard in the shard system to the state of the most recent verification, and regenerating a new set of verification shards to re-verify the blocks that failed to be verified until they are successfully verified to re-execute the transaction. It should be noted that the rotation mechanism means that the intra-shard transactions and cross-shard transactions of the shard that has been rotated out are all terminated and its right to serve as a verification shard for other shards is revoked until it is successfully re-verified, and finally completing the transaction rollback and error recovery to ensure the normal operation of the system.

[0063] Based on a fault-tolerant blockchain sharding system, such as Figure 2 As shown, the cross-shard transaction includes: S1, the source shard generates a new block and block verification evidence corresponding to the cross-shard transaction sent to the destination shard; S2, the validity of the block in step S1 is verified by the method described above to obtain the state of the block; S3, for the block that has been successfully verified and entered the committed state in step S2, its verification evidence is verified to be consistent with the information corresponding to its transaction root. If they are consistent, the cross-shard transaction initiated by the block is executed, and if they are inconsistent, the transaction is terminated; S4, a rotation mechanism is initiated for the block that failed to be verified in step S2.

[0064] In order to better understand the operating mechanism of the fault-tolerant blockchain sharding system, the present invention is described below with specific drawings and examples. Assuming that the fault-tolerant blockchain sharding system includes four shards (shard A, shard B, shard C, and shard D), the specific workflow of the sharding system is described by taking the scenario of the system conducting transactions as an example.

[0065] like Figure 3 As shown in the figure, the block verification evidence generation process of Shard A includes:

[0066] Step A1: Shard A generates a new block And generate verification evidence for the block.

[0067] Step A1.1, Shard A counts and collects the account status information involved in the execution of the block, and returns the original state before execution (i.e. ) is added to the block verification evidence of this block.

[0068] Step A1.2, taking the Merkle tree verification path as an example, Shard A will rely on the locally maintained account state tree to generate blocks Status proof of account status.

[0069] Step A1.3: The leader of shard A writes the hash of the block verification evidence into the block and Reach a consensus.

[0070] like Figure 4 As shown in the figure, the verification process of Shard B for the block generated by Shard A includes:

[0071] Step B1: Shard A generates a new block And generate verification evidence for the block.

[0072] Step B1.1: The leader of shard A writes the hash of the block verification evidence into the block and Reach a consensus.

[0073] Step B1.2, Shard A sends the block and its verification evidence is sent to Shard B.

[0074] Step B2: Shard B receives the block After the verification evidence is obtained, determine whether the hash of the verification evidence matches the block The block verification evidence hash in the block header of is consistent. If it is inconsistent, shard A is required to resend the block verification evidence.

[0075] Step B2.1, determine the block Whether the signature information complies with the on-chip consensus rules and whether consensus is reached in Shard A. If the verification fails, Shard A is required to resend the block information.

[0076] Step B2.2, determine the block In the block header, the previous block (i.e. ) is correct. If the verification fails, the block is broadcast to the entire network. Error message.

[0077] Step B2.3, Shard B adds the account status in the block verification evidence to the local memory and verifies whether it is consistent with the status proof. The state root in the account state corresponds to the state root in the account state. That is, whether the Merkle tree root constructed based on the state verification evidence and the account state is consistent with The Merkle tree root of the account is the same before the transaction is executed. If the verification fails, the block is broadcast to the entire network. Error message.

[0078] Step B2.4: Shard B executes in the local memory based on the same transaction processing principle and order In the transaction set, verify whether there is any error information or missing status in the transaction execution, and update the status information of Shard A account in memory according to the execution result. If there is an error execution, the block will be broadcast to the whole network. Error message.

[0079] Step B2.5: Shard B verifies whether the Merkle root it constructed is consistent with the A shard account status based on the status proof and the updated A shard account status. The state root is consistent, that is, verify whether the two are in the same account state after the transaction is executed. If the verification is inconsistent, the block is broadcast to the entire network Error message.

[0080] Step B3, Shard B verifies the block If successful, the block will be broadcast to the entire network Correct message.

[0081] Figure 5 The figure shows the cross-shard transaction process in which shard A generates a block and sends it to shard D, where shards B and C act as verification shards to verify the block generated by shard A. The process includes:

[0082] Step C1: Shard A generates a new block And generate verification evidence for the block.

[0083] Step C1.1, Shard A to Block And block verification evidence to reach consensus, block Enter the ready state.

[0084] Step C1.2, Shard A to Block And the block verification evidence is sent to Shard B and Shard C for verification.

[0085] Step C1.3, Shard A sends the block Cross-shard transaction Tx in the previous stage executed in A , Generate a transaction proof (Merkel tree verification path) based on the transaction Merkle tree of the block, write it into the transaction field, and send Tx A To fragment D.

[0086] Step C2: Shard B / Shard C receives the block After the proof, verification is performed, and if the verification passes, it is broadcast to the entire network Verify the correct information, otherwise broadcast Validation error message.

[0087] Step C3, fragment D receives fragment B or fragment C Verify the information. If one of them is verified correctly, go to step C3.1. Otherwise, if both are verified incorrectly, the transaction Tx will be abandoned. A , the transaction execution process ends and the system enters step C4.

[0088] Step C3.1, Block Enter the pre-submit state and wait for its dependent blocks and All blocks enter the committed state. If the dependent block enters the committed state, execute step C3.2. If the previous state is wrong, the transaction Tx is abandoned. A , the transaction execution process ends and the system enters step C4.

[0089] Step C3.2, Verify Tx A Whether the relevant transaction proof information in If they are consistent, the relevant transactions are executed and consensus is reached. Otherwise, the transaction Tx is abandoned. A , the transaction execution is completed.

[0090] In step C4, the blockchain sharding system initiates a rotation mechanism to replace the consensus node of the shard to which the error block belongs and rolls back the error state.

[0091] It can be seen from the steps of the above embodiment that the present invention achieves the purpose of adding a fault tolerance mechanism to the blockchain sharding system. In order to better illustrate the effect of the present invention, the performance of the blockchain sharding system before and after adding a fault tolerance mechanism is compared and described below. Assuming that each shard can tolerate 1 / 3 of the number of malicious attackers, and the proportion of malicious attackers in the global environment is 1 / 4, m represents the scale of consensus nodes in each shard, and n represents the number of shards, then the probability of a shard going wrong (being controlled by a malicious attacker) is:

[0092]

[0093] The error probability of the entire system before fault tolerance is:

[0094] P system =1-(1-P shar ) n ≈nP shard

[0095] The error probability of the entire system after fault tolerance is:

[0096]

[0097] Under the same parameter conditions, the error probability of the entire system is significantly reduced compared to before fault tolerance. Under the same security level, the internal shard after fault tolerance can be further relaxed, so a smaller shard consensus node scale m can be used, which also means that the system will have a higher transaction processing level. In summary, the shard fault tolerance mechanism can effectively reduce the shard's requirements for the consensus node scale to improve the shard's transaction processing capabilities. The specific effects are shown in Table 2. By tolerating a small number of shard errors, the transaction processing capacity of each shard can be effectively improved by at least 1-2 times.

[0098] Table 2

[0099]

[0100] Compared with the prior art, the advantages of the present invention are:

[0101] 1. The fault-tolerant mechanism of blockchain sharding is realized by cross-validation based on the status between shards, so that the blockchain sharding system can still work normally when a small number of shards fail.

[0102] 2. Reduce the scale of shard consensus nodes through the fault-tolerant mechanism of sharding, improve sharding performance, increase the degree of system parallelism, and improve the overall throughput level of the blockchain system from multiple dimensions.

[0103] It should be noted that although the above describes the various steps in a specific order, it does not mean that the various steps must be executed in the above specific order. In fact, some of these steps can be executed concurrently or even in a different order as long as the required functions can be achieved.

[0104] The present invention may be a system, a method and / or a computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for causing a processor to implement various aspects of the present invention.

[0105] Computer readable storage medium can be a tangible device that keeps and stores the instructions used by the instruction execution device. Computer readable storage medium can include, for example, but is not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. More specific examples (non-exhaustive list) of computer readable storage medium include: portable computer disk, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanical encoding device, such as a punch card or a convex structure in a groove on which instructions are stored, and any suitable combination thereof.

[0106] The embodiments of the present invention have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or technical improvements in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A block validity verification method for a blockchain sharding system, wherein the blockchain sharding system includes multiple shards, each shard generates a new block based on transaction requirements and reaches a consensus within the shard to generate verification evidence of the block, characterized in that: The method comprises the following steps: Randomly select 2 times the preset number of shards in the blockchain sharding system except the shard where the block is located to form a verification shard set; Each shard in the verification shard set is used to verify the block, and the verification result is broadcast to other shards; each shard in the verification shard set verifies the verification block as follows: Obtain the block to be verified and its verification evidence, and verify the validity of the block status; wherein, the block verification evidence is generated in the following manner: in response to transaction requirements, the shard generates a new block; the shard collects the account status information involved in the block execution transaction process, and generates the block verification evidence through the locally dimensioned account status tree; the shard reaches a consensus on the generated block and block verification evidence; After the validity of the block status is verified, the transaction information is executed on the block and the block status is updated, and it is determined whether an error is reported during the transaction execution; When the transaction is executed without error, verify whether the block status after the block update is consistent with the status information recorded in the block itself; When all three verifications are passed, the block to be verified is considered valid, otherwise it is considered an error, and the verification result is broadcast to all shards in the blockchain sharding system; The block and its shard are considered to be successfully verified when at least half of the shards in the verification shard set verify that the block is valid.

2. The method according to claim 1, characterized in that: The preset number is a number greater than or equal to 1 and less than or equal to the number of shards in the blockchain sharding system. The preset number is used to indicate the maximum number of malicious shards that the blockchain sharding system can tolerate.

3. The method according to claim 1, characterized in that Blocks are divided into blocks in preparation state, blocks in pre-commitment state, and blocks in submission state according to whether they are verified or not and the verification results. The blocks in preparation state refer to blocks newly generated by the shards, and are only consensus-reached within the shard and have not been verified by other shards; the blocks in pre-commitment state refer to blocks in preparation state that have passed validity verification; the blocks in submission state refer to blocks in pre-commitment state whose preceding blocks are all in submission state.

4. A cross-shard transaction method based on a blockchain sharding system, used to execute a cross-shard transaction initiated by a source shard block to a destination shard, characterized in that: The method comprises: S1. The source shard generates a new block and block verification evidence corresponding to the cross-shard transaction sent to the destination shard; S2. Verify the validity of the block in step S1 by using the method described in any one of claims 1 to 3 to obtain the status of the block; S3. For the block that has been successfully verified and entered the committed state in step S2, verify whether its verification evidence is consistent with the information corresponding to its transaction root. If they are consistent, execute the cross-shard transaction initiated by the block; if they are inconsistent, terminate the transaction.

5. The method according to claim 4, characterized in that The method further comprises: S4. Initiate a rotation mechanism for the block that failed verification in step S2, including rotating out the shard where the block is located and the shard containing its subsequent cross-shard transactions, and rolling back each shard in the shard system to the state where it passed the most recent verification. At the same time, regenerate a new set of verification shards to re-verify the block that failed verification until it is successfully verified and re-execute the transaction.

6. The method according to claim 5, characterized in that The rotation mechanism means that the intra-shard and cross-shard transactions of the shard that is rotated out are suspended and its right to serve as a verification shard for other shards is revoked until it is successfully re-verified.

7. A fault-tolerant blockchain sharding system, comprising a plurality of shards, each of which generates a new block based on transaction requirements and reaches a consensus within the shard to generate verification evidence of the block, characterized in that: The blockchain sharding system adopts the method described in any one of claims 4-6 to perform cross-shard transactions.

8. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and the computer program can be executed by a processor to implement the steps of any method described in claims 1-3 or 4-6.

9. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the electronic device to implement the steps of the method as described in any one of claims 1-3 or 4-6.

Images