A Security Protection Method for a Sharded Blockchain System

Abstract

The present invention discloses a method for protecting the security of a sharded blockchain system, wherein the sharded blockchain system consists of 1 core shard and multiple ordinary shards. Each node in the ordinary shards can store the historical blocks of other shards in addition to storing the historical blocks of its own shard. When a single shard in the system is bribed, the bribed shard cannot give a legitimate verification result for the transactions it is responsible for verifying. At this time, those honest nodes that store the historical blocks of the bribed shard can submit a report on the verification result of a certain transaction to the core shard. The core shard confirms the validity of the report, and the system rewards or punishes the nodes that submit the report according to whether the report is valid. By allowing nodes to additionally store the historical blocks outside their own shards, the present invention enables nodes to have the ability to supervise and report bribed shards, which can solve the problems of illegal transactions being added to the blockchain and legal transactions failing to be added to the blockchain, and changes the sharding route of existing sharding systems that rely on random allocation and periodic rotation of nodes to ensure security.

Description

Technical Field

[0001] The present invention belongs to the technical field of blockchain, and more specifically, relates to a method for protecting the security of a sharded blockchain system. Background Art

[0002] Blockchain is an emerging distributed database. After all data and operations are consensus among nodes, they are packaged into continuously generated blocks, and each node in the system needs to store all blocks. An attacker needs to control most nodes in the system, which is very difficult to achieve. Therefore, blockchain has the characteristic of being immutable.

[0003] Since each node needs to store all blocks, the transaction concurrency ability in the traditional blockchain system is limited and cannot meet the rapidly growing network data processing requirements. Therefore, a sharded blockchain solution is proposed, which divides nodes into multiple shards. Different shards generate blocks in parallel, improving the throughput and scalability of the system and reducing the storage pressure on a single node. However, after the blockchain is sharded, the number of nodes in a single shard decreases. A relatively small number of malicious nodes can control a certain shard, and the transactions verified by this shard will not give legal verification results, resulting in the loss of availability of the sharded blockchain system.

[0004] In a Chinese invention patent authorized on May 20, 2022, with the authorization announcement number CN113242553B and the invention name "A Method for Detecting Malicious Nodes Based on Blockchain Sharding", a reputation model updated periodically is proposed. The credibility of the node is evaluated according to the behavior performance of the server, and the number of malicious nodes in each shard of the system is estimated during the evaluation process. Combining with other algorithms, the maximum value of the number of shards under the premise of system security is calculated, and then the shards are merged or reorganized to ensure the security and reliability of the shards.

[0005] However, existing sharded blockchain systems, such as Omniledger, RapidChain, etc., rely on the random assignment and periodic rotation of nodes to prevent the collusion of malicious nodes to control a certain shard. Since the random assignment of nodes cannot guarantee that malicious nodes can be evenly distributed among all shards, the overall security threshold of existing sharded blockchains must be less than the security threshold within the shard, otherwise a single shard will be controlled, leading to the unavailability of the system. Summary of the Invention

[0006] The purpose of the present invention is to overcome the deficiencies of the prior art and provide a method for protecting the security of a sharded blockchain system, so that the overall security of the sharded blockchain can be greater than or equal to the security threshold within the shard, thereby obtaining higher security protection for the sharded system.

[0007] To achieve the above invention objective, the method for protecting the security of the sharded blockchain system of the present invention is characterized by including the following steps:

[0008] (1) In addition to storing the historical blocks of its own shard, each node can additionally store one or more historical blocks saved by other shard nodes, so that the node can supervise the transaction verification results of other shards;

[0009] (2) Before the start of each round of consensus, the core shard sends the transactions that each ordinary shard is responsible for verifying to each ordinary shard. In addition, the core shard also sends the set of all transactions that need to be verified in this round of consensus to all ordinary shards. In this way, each node in each ordinary shard can verify the part of the transactions it is responsible for verifying, and at the same time, it can also supervise the transaction verification results in the historical blocks of other ordinary shards it stores additionally according to the set of transactions that need to be verified in this round of consensus;

[0010] (3) In each round of consensus, after each ordinary shard reaches an in-shard consensus on the transactions it is responsible for verifying, it returns the verification results to the core shard. If an honest node in the ordinary shard raises an objection to the verification result of a transaction in the shard, the node reports the transaction to the core shard;

[0011] (4) The core shard collects the verification results of each ordinary shard on the transactions it is responsible for, and the reporting information of the reporting nodes on the transactions they supervise. If the two pieces of information are consistent, it proceeds to step (5); otherwise, it proceeds to step (6);

[0012] (5) The core shard generates several blocks for this round of consensus, and then distributes the blocks to the ordinary shards, that is, each ordinary shard receives one block; the core shard also sends the hash of all blocks in this round to each ordinary shard, that is, each ordinary shard has the hash of all historical blocks. In addition, the core shard also sends the set of transactions that have not been packed into the blocks to each ordinary shard. If a node believes that a transaction that has not been packed into the block is legal based on the blocks it stores additionally, it sends the reporting information to the core shard;

[0013] (6) The core shard checks the reporting information and determines whether the block is legal by verifying the hash of the block provided in the reporting information. If the block is legal, it generates accusation information based on the reporting information and sends it to the reported shard; if the block is illegal, it determines that the reporting node's report fails and proceeds to step (8);

[0014] (7) After receiving the accusation information, the reported shard can package the information proving the legality of the transaction as refutation information and send it to the core shard. The core shard, based on the refutation information, requests blocks from other nodes that can verify the refutation information. If the verification result supports the refutation information, it is determined that the reported shard has not been bribed and the reporting node's report fails; if the verification result does not support the refutation information, it is determined that the reported shard has been bribed and the reporting node's report succeeds;

[0015] (8) The core shard processes the reporting node and the reported shard according to the reporting result. If the reporting node's report succeeds, the reporting node is rewarded and the reported shard is reorganized; if the reporting node's report fails, the reporting node is punished.

[0016] The blockchain system consists of multiple shards, including 1 core shard and multiple ordinary shards. Each shard contains multiple nodes, and each node can only belong to one shard.

[0017] All historical blocks in the blockchain system are separately stored in different ordinary shards, that is, different ordinary shards are responsible for storing non-repetitive historical blocks. Nodes within an ordinary shard can, in addition to storing the historical blocks of its own shard, also store the historical blocks of other ordinary shards. During the transaction verification process, nodes within an ordinary shard can, in addition to verifying the part of the transactions that its own shard is responsible for verifying, also supervise the verification of the transactions it stores additionally.

[0018] The core shard is responsible for collecting the set of transactions to be verified for this round of consensus, sending the part of the transactions that each ordinary shard is responsible for verifying to each ordinary shard, then collecting the verification results of the ordinary shards and the reporting information of the nodes, and based on the verification results of the ordinary shards and the handling results of the reports, packaging the transactions determined to be legal into several blocks and handing them over to the ordinary shards for storage.

[0019] The functional modules of a node include: node identity module, storage module, transaction verification module, intra-shard consensus module, reporting generation module, reporting verification module, reporting refutation module, reporting adjudication module, and reward and punishment module.

[0020] Node identity module: Stores the public and private keys of this node and the public keys of other nodes. All information sent by the node must be signed by the node identity module using the private key of this node; the node identity module can also confirm the source of the message through the public keys of other nodes and the signature verification algorithm.

[0021] Storage module: Used to store the blocks of this shard, the blocks of other shards stored additionally, and the hashes of all historical blocks, etc.

[0022] Transaction verification module: Used to collect the unverified transaction information that can be verified in this shard and verify whether the transaction is legal based on the content stored in the storage module.

[0023] In-chip consensus module: used to reach a consensus among in-chip nodes on the transaction verification results.

[0024] Report generation module: used to detect illegal transaction verification results and file reports. Specifically, it includes: verifying the transaction verification results given by other shards based on the blocks of other shards stored additionally by the nodes, and sending the report information to the core shard after detecting errors.

[0025] The report information consists of the reported object, the reported content, the evidence block, and the signature. The reported object refers to the shard whose verification result for a certain transaction is different from that of the reporting node; the reported content refers to the verification result for a certain transaction; the evidence block refers to the block stored additionally by the reporting node that can prove that the verification result given by a certain shard is illegal; the signature means that the reporting node should sign on the report information. After the report information is verified, the core shard will trace the reporting node according to the signature, so as to give rewards or punishments to the reporting node.

[0026] Report verification module: used to help nodes verify whether the reported content is reliable. Specifically, it includes: judging the authenticity of the evidence, judging whether the reported content is true, and generating accusation information and sending it to the reported shard.

[0027] Report refutation module: used to generate refutation information and send it to the core shard when a shard becomes the reported shard by searching the blocks where the relevant information in the reported transaction is located.

[0028] Report adjudication module: used to help the core shard obtain the judgment result of the report correctness based on the report information, the refutation information, and the verification results of these information, and call the reward and punishment module to form special reward and punishment transactions, broadcast them to each shard, and supervise the execution of the rewards and punishments.

[0029] Reward and punishment module: rewards and punishes the reporting nodes and the reported shards.

[0030] The object of the present invention is achieved as follows:

[0031] The existing sharded blockchains can only ensure the security of the sharding system through random allocation of nodes and regular rotation of nodes within shards, which requires the overall security threshold of the system to be less than the in-shard security threshold. The present invention proposes a method for protecting the security of a sharded blockchain system. By allowing each node to additionally store the historical blocks of other shards, this method enables the node to have the ability to supervise and report the transaction verification results of other shards. While solving the problems of illegal transactions being added to the chain and legitimate transactions failing to be added to the chain, it changes the sharding route of existing sharding systems that rely on random allocation and periodic rotation of nodes to ensure system security. The node reporting mechanism proposed by the present invention can make the overall security of the sharded blockchain greater than or equal to the in-shard security threshold, thereby obtaining higher protection for the security of the sharding system.

[0032] The present invention proposes a method for protecting the security of a sharded blockchain system, which has the following beneficial effects:

[0033] 1. The present invention allows each node to additionally store one or more historical blocks saved by other shard nodes in addition to saving the historical blocks of its own shard, enabling the node to supervise the transaction verification results of other shards. The node reporting mechanism proposed by the present invention realizes for the first time on the sharded blockchain that the overall security of the system can be greater than or equal to the in-shard security threshold, achieving higher protection for the security of the sharding system.

[0034] 2. The security protection method proposed by the present invention still retains the advantages of the sharded blockchain, that is, each node only stores a part of all the blocks in the system, the number of blocks stored by each node is still much smaller than the total number of blocks in the system, and the storage cost of the node is still relatively low. Therefore, the system still has good scalability. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 It is a schematic diagram of the system composition of a method for protecting the security of a sharded blockchain system provided by the present invention;

[0036] Figure 2 It is a schematic diagram of the node module of a method for protecting the security of a sharded blockchain system provided by the present invention;

[0037] Figure 3 It is a schematic diagram of a method for protecting the security of a sharded blockchain system provided by the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0038] The following describes the specific implementation manners of the present invention with reference to the drawings, so that those skilled in the art can better understand the present invention. It should be particularly noted that in the following description, when the detailed description of known functions and designs may dilute the main content of the present invention, these descriptions will be omitted here.

[0039] In order to solve the problem that the current sharded blockchain can only achieve random allocation of nodes in the system by periodically reorganizing shards, which leads to the overall security threshold of the system must be less than the in-shard security threshold, the present invention proposes a method for protecting the security of a sharded blockchain system. By allowing nodes to additionally store historical blocks of other shards, the present invention enables nodes to have the ability to monitor and report bribed shards. While solving the problems of illegal transactions being included in the blockchain and legitimate transactions not being included in the blockchain, it changes the sharding route of existing sharded systems that rely on random allocation and periodic rotation of nodes to ensure system security.

[0040] To better describe the above technical solution, the above technical solution will be described in detail below in conjunction with the accompanying drawings of the specification and specific implementation manners.

[0041] Embodiment 1

[0042] In this embodiment, we take a sharded blockchain system as an example. Assume that there are 10,000 server nodes in the system, and 100 nodes are selected to form a core shard. The core shard randomly groups the remaining 9,900 nodes, with 100 nodes in each group to form 99 ordinary shards. All historical blocks in the system are stored in different shards respectively, that is, the blocks stored in different shards do not overlap. As Figure 1 shown, all nodes can additionally store historical blocks of other shards. During the transaction verification process, PBFT consensus is adopted within each shard. In addition to verifying the part of transactions that each shard is responsible for verifying, all nodes can also monitor the verification of the transactions they additionally store.

[0043] A server entity in the system represents a node in the sharded blockchain. As Figure 2 shown, the functional modules of the node include:

[0044] Node identity module: Stores the public and private keys of this node and the public keys of other nodes. All information sent by the node must be signed by the private key of this node through the node identity module; the node identity module can also confirm the source of the message through the public keys of other nodes and signature verification algorithms.

[0045] Storage module: Used to store the blocks of this shard, the blocks of other shards additionally stored, and the hashes of all historical blocks, etc.

[0046] Transaction verification module: Used to collect the information of unverified transactions that can be verified in this shard, and verify whether the transactions are legal based on the content stored in the storage module.

[0047] In-shard consensus module: Used to reach a consensus among in-shard nodes on the transaction verification results.

[0048] Report generation module: used to detect illegal transaction verification results and file reports. Specifically, it includes: verifying the transaction verification results given by other shards based on the blocks of other shards stored additionally by the node, and sending the report information to the core shard after detecting errors.

[0049] Report verification module: used to help nodes verify the reliability of reported content. Specifically, it includes: judging the authenticity of evidence, judging whether the reported content is true, so as to generate accusation information and send it to the reported shard.

[0050] Report refutation module: used to generate refutation information and send it to the core shard by searching for the blocks where relevant information in the reported transaction is located when a shard becomes the reported shard.

[0051] Report adjudication module: used to help the core shard obtain the judgment result of the report's correctness based on the report information, refutation information, and the verification results of these information, call the reward and punishment module to form special reward and punishment transactions, broadcast them to each shard, and supervise the execution of rewards and punishments.

[0052] Reward and punishment module: rewards and punishes the reporting nodes and the reported shards.

[0053] As Figure 3 shown, in this embodiment, the implementation of the method for protecting the security of the sharded blockchain system of the present invention includes the following steps:

[0054] (1) In addition to saving the historical blocks of its own shard, each node can additionally store one or more historical blocks saved by other shard nodes, so that the node can supervise the transaction verification results of other shards;

[0055] (2) Before each round of consensus starts, the core shard sends the transactions that each ordinary shard is responsible for verifying to each ordinary shard. In addition, the core shard also sends the set of all transactions that need to be verified in this round of consensus to all ordinary shards. In this way, each node in each ordinary shard can verify the part of the transactions it is responsible for verifying, and at the same time, it can also supervise the transaction verification results in the historical blocks of other ordinary shards stored additionally by it according to the set of transactions that need to be verified in this round of consensus;

[0056] (3) In each round of consensus, after each ordinary shard reaches consensus on the transactions it is responsible for verifying within the shard, it returns the verification results to the core shard. If an honest node in the ordinary shard raises an objection to the verification result of one transaction in the shard, the node reports the transaction to the core shard;

[0057] (4) The core shard collects the verification results of each ordinary shard for the transactions it is responsible for, as well as the reporting information of the reporting nodes for the transactions they supervise. If the two types of information are consistent, proceed to step (5); otherwise, proceed to step (6).

[0058] (5) The core shard generates several blocks for the consensus of this round, and then distributes the blocks to the ordinary shards, that is, each ordinary shard receives one block; the core shard also sends the hash of all blocks in this round to each ordinary shard, that is, each ordinary shard has the hash of all historical blocks. In addition, the core shard also sends the set of transactions that have not been packed into blocks to each ordinary shard. If a node believes that a transaction that has not been packed into a block is legal based on the blocks it stores additionally, it sends the reporting information to the core shard.

[0059] (6) The core shard checks the reporting information and determines whether the block is legal by verifying the hash of the block provided in the reporting information. If the block is legal, it generates accusation information based on the reporting information and sends it to the reported shard; if the block is illegal, it determines that the reporting node has failed in reporting and proceeds to step (8).

[0060] (7) After receiving the accusation information, the reported shard can package the information proving the legality of the transaction into a rebuttal message and send it to the core shard. The core shard requests other nodes to verify the rebuttal message based on the rebuttal message. If more than 1 / 2 of the nodes support the rebuttal message, it is determined that the reported shard has not been bribed and the reporting node has failed in reporting; if the number of nodes supporting the rebuttal message is less than 1 / 2, it is determined that the reported shard has been bribed and the reporting node has succeeded in reporting. Since PBFT consensus is used within the shard, the in-shard security threshold is 1 / 3, and the overall security threshold of the system can reach 1 / 2.

[0061] (8) The core shard processes the reporting node and the reported shard according to the reporting result. If the reporting node has succeeded in reporting, it rewards the reporting node and reorganizes the reported shard; if the reporting node has failed in reporting, it punishes the reporting node.

[0062] Although the above describes the illustrative specific embodiments of the present invention for the convenience of those skilled in the art to understand the present invention, it should be clear that the present invention is not limited to the scope of the specific embodiments. For those of ordinary skill in the art, as long as various changes are within the spirit and scope of the present invention defined and determined by the appended claims, these changes are obvious, and all inventions created using the concept of the present invention are within the scope of protection.

Claims

1. A method for protecting the security of a sharded blockchain system, characterized in that, it includes the following steps: (1) In addition to saving the historical blocks of its own shard, each node can additionally store one or more historical blocks saved by other shard nodes, so that the node can supervise the transaction verification results of other shards; (2) Before each round of consensus starts, the core shard sends the transactions that each ordinary shard is responsible for verifying to each ordinary shard. In addition, the core shard also sends the set of all transactions that need to be verified in this round of consensus to all ordinary shards. In this way, each node in each ordinary shard can verify the part of the transactions it is responsible for verifying, and at the same time, according to the set of transactions that need to be verified in this round of consensus, it can supervise the transaction verification results in the historical blocks of other ordinary shards that it stores additionally; (3) In each round of consensus, after each ordinary shard reaches an in-shard consensus on the transactions it is responsible for verifying, it returns the verification results to the core shard; if an honest node in the ordinary shard raises an objection to the verification result of a transaction in the shard, the node reports the transaction to the core shard; (4) The core shard collects the verification results of each ordinary shard on the transactions it is responsible for, and the reporting information of the reporting nodes on the transactions they supervise. If the verification results, reporting information, and content are consistent, it enters step (5); otherwise, it enters step (6); (5) The core shard generates several blocks for this round of consensus, and then distributes the blocks to the ordinary shards, that is, each ordinary shard receives a block; The core shard also sends the hash of all blocks in this round to each ordinary shard, that is, each ordinary shard has the hash of all historical blocks; in addition, the core shard also sends the set of transactions that have not been packaged into blocks to each ordinary shard. If a node believes that a transaction that has not been packaged into a block is legal based on the blocks it stores additionally, it sends the reporting information to the core shard; (6) The core shard checks the reporting information, and judges whether the block is legal by verifying the hash of the block provided in the reporting information; If the block is legal, it generates accusation information based on the reporting information and sends it to the reported shard, and enters step (7); if the block is illegal, it judges that the reporting node's report fails, and enters step (8); (7) After receiving the accusation information, the reported shard can package the information proving the legality of the transaction into a rebuttal message and send it to the core shard. The core shard requests blocks from other nodes that can verify the rebuttal message according to the rebuttal message; If the verification result supports the rebuttal message, it judges that the reported shard has not been bribed and the reporting node's report fails; if the verification result does not support the rebuttal message, it judges that the reported shard has been bribed and the reporting node's report is successful; (8) The core shard processes the reporting node and the reported shard according to the reporting result; If the reporting node's report is successful, it rewards the reporting node and reorganizes the reported shard; if the reporting node's report fails, it punishes the reporting node; The blockchain system consists of multiple shards, including 1 core shard and multiple ordinary shards. Each shard contains multiple nodes, and each node can only belong to one shard; All historical blocks in the blockchain system are separately stored in different ordinary shards, that is, the historical blocks stored by different ordinary shards do not overlap. Nodes within an ordinary shard can, in addition to storing the historical blocks of its own shard, also store the historical blocks of other ordinary shards; during the transaction verification process, nodes within an ordinary shard can, in addition to verifying the part of the transactions that its own shard is responsible for verifying, also supervise the verification of the transactions it stores additionally. The core shard is responsible for collecting the set of transactions to be verified for this round of consensus, sending the part of the transactions that each ordinary shard is responsible for verifying to each ordinary shard, and then collecting the verification results of the ordinary shards and the reporting information of the nodes. Based on the verification results of the ordinary shards and the handling results of the reports, it packages the transactions judged to be legal into several blocks and hands them over to the ordinary shards for storage.

2. The method for protecting the security of the sharded blockchain system according to claim 1, characterized in that, The functional modules of the node include: a node identity module, a storage module, a transaction verification module, an in-shard consensus module, a reporting generation module, a reporting verification module, a reporting refutation module, a reporting adjudication module, and a reward and punishment module; Node identity module: Stores the public and private keys of this node and the public keys of other nodes. All information sent by the node must be signed by the node identity module using the private key of this node; the node identity module can also confirm the source of the message through the public keys of other nodes and the signature verification algorithm. Storage module: Used to store the blocks of this shard, the blocks of other shards stored additionally, and the hashes of all historical blocks; Transaction verification module: Used to collect the information of the unverified transactions that can be verified in this shard, and verify whether the transactions are legal based on the content stored in the storage module; In-shard consensus module: Used to reach a consensus among the nodes within the shard on the transaction verification results; Reporting generation module: Used to discover illegal transaction verification results and file a report; specifically including: verifying the transaction verification results given by other shards based on the blocks of other shards stored additionally by the node, and sending the reporting information to the core shard after discovering an error; Reporting verification module: Used to help the node verify whether the reporting content is reliable; specifically including: judging the authenticity of the evidence and whether the reporting content is true, so as to generate an accusation message and send it to the reported shard; Reporting refutation module: Used when a shard becomes the reported shard, generates a refutation message by searching for the relevant information in the blocks of the reported transactions and sends it to the core shard; Reporting adjudication module: Used to help the core shard obtain a judgment result on the correctness of the report based on the reporting information, the refutation information, and the verification results of these information, call the reward and punishment module to form special reward and punishment transactions, broadcast them to each shard, and supervise the execution of the rewards and punishments; Reward and punishment module: Rewards and punishes the reporting nodes and the reported shards.

3. The method for protecting the security of the sharded blockchain system according to claim 2, characterized in that, The reported information consists of a reported object, reported content, an evidence block, and a signature; the reported object refers to a shard whose verification result for a certain transaction is different from that of the reporting node; the reported content refers to the verification result for a certain transaction; the evidence block refers to a block that is additionally stored by the reporting node and can prove that the verification result given by a shard is illegal; the signature means that the reporting node should sign the reported information, and after the reported information is verified, the core shard will trace the reporting node based on the signature, so as to give rewards or punishments to the reporting node.

Images